Decision-theoretic treatment systems and methods

Abstract

In some embodiments, a method of dynamically adapting treatments to patient risk preferences includes receiving analyte risk preferences of a patient and personalizing an analyte-value utility model for the patient based on the analyte risk preferences, where the personalized analyte-value utility model describes variation in analyte-value utility across a range of analyte values. The method also includes receiving, for each prospective treatment of one or more prospective treatments, one or more predicted analyte values of the patient for the prospective treatment and determining a prediction uncertainty associated with the one or more predicted analyte values.

Description

DECISION-THEORETIC TREATMENT SYSTEMS AND METHODSCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to and benefit of U.S. Provisional Patent Application No. 63 / 739,431 filed December 27, 2024, which application is hereby expressly incorporated by reference herein in its entirety as if fully set forth below and for all applicable purposes.INTRODUCTION

[0002] Diabetes is a metabolic condition affecting hundreds of millions of people. For these people, monitoring blood glucose levels and regulating those levels to be within an acceptable range is important not only to mitigate long-term issues such as heart disease and vision loss, but also to avoid the effects of hyperglycemia and hypoglycemia. Maintaining blood glucose levels within an acceptable range can be challenging, as glucose levels are almost constantly changing over time and in response to everyday events, such as eating or exercising. Advances in medical technologies have enabled development of various systems for monitoring analytes such as blood glucose, including continuous analyte monitoring (CAM) systems such as continuous glucose monitoring (CGM) systems, which measure and record glucose concentrations in substantially real-time. CAM systems are important tools for users of these systems to ensure that measured analyte values are within the acceptable range.SUMMARY

[0003] In some embodiments, one general aspect includes a system for dynamically adapting treatments to patient risk preferences. The system includes one or more memories having executable instructions. The system also includes one or more processors in data communication with the one or more memories and configured to execute the executable instructions to receive analyte risk preferences of a patient and personalize an analyte-value utility model for the patient based on the analyte risk preferences, where the personalized analyte-value utility model describes variation in analyte-value utility across a range of analyte values. The one or more processors are further configured to execute the executable instructions to receive, for each prospective treatment of one or more prospective treatments, one or more predicted analyte values of the patient for the prospective treatment. The one or more processors are further configured to execute the executableinstructions to determine, for each prospective treatment of the one or more prospective treatments, a prediction uncertainty associated with the one or more predicted analyte values.

[0004] In some embodiments, another general aspect includes a method of dynamically adapting treatments to patient risk preferences. The method includes receiving analyte risk preferences of a patient. The method also includes personalizing an analyte-value utility model for the patient based on the analyte risk preferences, where the personalized analyte-value utility model describes variation in analyte-value utility across a range of analyte values. The method also includes receiving, for each prospective treatment of one or more prospective treatments, one or more predicted analyte values of the patient for the prospective treatment. The method also includes determining, for each prospective treatment of the one or more prospective treatments, a prediction uncertainty associated with the one or more predicted analyte values.

[0005] In some embodiments, another general aspect includes a computer-program product. The computer-program product includes a non-transitory computer-usable medium having computer-readable program code embodied therein. The computer-readable program code is adapted to be executed to implement a method of dynamically adapting treatments to patient risk preferences. The method includes receiving analyte risk preferences of a patient. The method also includes personalizing an analyte-value utility model for the patient based on the analyte risk preferences, where the personalized analyte-value utility model describes variation in analytevalue utility across a range of analyte values. The method also includes receiving, for each prospective treatment of one or more prospective treatments, one or more predicted analyte values of the patient for the prospective treatment. The method also includes determining, for each prospective treatment of the one or more prospective treatments, a prediction uncertainty associated with the one or more predicted analyte values.BRIEF DESCRIPTION OF THE DRAWINGS

[0006] FIG. 1A illustrates an example of a therapy management system, in accordance with certain embodiments.

[0007] FIG. IB illustrates an example analyte sensor system including an example continuous analyte sensor(s) with sensor electronics, in accordance with certain embodiments.

[0008] FIG. 2 illustrates example inputs and example outputs that are generated based on the inputs, in accordance with certain embodiments.

[0009] FIG. 3 illustrates an example of a process for decision-theoretic automation and decision support for a patient, in accordance with certain embodiments.

[0010] FIG. 4 illustrates an example of a process for configuring an analyte-value utility model, in accordance with certain embodiments.

[0011] FIG. 5 illustrates an example of a process for computing, presenting and / or implementing risk-optimal treatments, in accordance with certain embodiments.

[0012] FIG. 6 illustrates an example of a hurricane track, in accordance with certain embodiments.

[0013] FIG. 7 illustrates an example of updating a model of prediction uncertainty, in accordance with certain embodiments.

[0014] FIG. 8 illustrates an example of a process for decision-theoretic automation and decision support for a patient in diabetes treatment context, in accordance with certain embodiments.

[0015] FIG. 9 is a block diagram depicting a computer system configured for decision-theoretic automation and decision support, in accordance with certain embodiments.

[0016] FIG. 10 shows an example of an Interactive Glucose Prediction Interface.DETAILED DESCRIPTION

[0017] People with diabetes (PwD) live with significant uncertainty every time they make a self-treatment decision, such as a decision to administer insulin or ingest carbohydrates. For example, treatment decisions may be made, in part, based on predicted glucose values, such as a prediction of hypoglycemia or hyperglycemia within a defined period of time. Predicted glucose values are not always accurate, for example, due to user physiology, environment (e g., stress), and / or behavior (e g., meals, activity, etc.).

[0018] Current predictive glucose reports / alerts do not clearly define, estimate, or otherwise indicate uncertainty around predictive glucose measurements. This lack of knowledge with regard to prediction uncertainty can cause the patient and / or automated dosing systems to make treatmentdecisions that are ineffective, overly aggressive, and / or that arbitrarily discount the value of the predicted glucose values. In general, current automation and decision support tools do not explicitly acknowledge uncertainty about future glucose values and, therefore, are not adaptable to individual risk preferences.

[0019] Further to the above, patient-specific lifestyle factors may make different ranges of glucose values more useful (e.g., more desirable) to different patients. Some factors may be relatively constant for a patient, such as which glucose values or ranges produce anxiety in the patient, while others may be more sporadic, such as the patient’s desire for uninterrupted sleep the night before an important event. Current automation and decision support tools, however, are generally unable to effectively capture such information, let alone use the information to adapt treatment determinations and decisions.

[0020] In an example, in some aspects, a general risk tolerance for different glucose levels may vary widely across different patients but remain relatively constant for an individual patient. For instance, glucose values below 120 mg / dL may cause great anxiety in one patient but not in another. In some aspects, certain patients may be expectedly risk adverse, and prone to anxiety, for example, due to greater than typical sensitivity to therapeutic agents for reducing glucose levels (e.g., insulin administration). Reducing patient anxiety would be beneficial to patient health and wellness. Conventional automation and decision support tools, however, are not generally able to adapt treatment determinations and decisions based on the patient’s individual risk tolerance and an understanding of the uncertainty in predictive glucose levels (e.g., an understanding of risk and a distribution of predictive error).

[0021] In another example, in some aspects, there may be periodic variations in a patient’s risk tolerance. For example, the patient may have a meeting, activity, performance, or other event the next day and want to prioritize sleep the night before the event. Accordingly, it may be especially important to the patient that they not be awaken by a low glucose alert and a corresponding need to administer insulin. In such a scenario, the patient may be willing to accept a risk tradeoff of higher glucose values that night in exchange for virtually eliminating a risk of being awaken during sleep. Conventional automation and decision support tools, however, typically determine treatments without regard to any variations in the patient’ s risk tolerance and any variability unique to the patient.

[0022] In response to the above problems, in certain aspects described herein, a therapy management engine can implement decision-theoretic methods and systems for automation and decision support that explicitly reason about future analyte-value uncertainty and are adaptable to a patient or other user's risk preferences. For example, the therapy management engine can configure an analyte-value utility model for the patient. In certain aspects, the therapy management engine can personalize the analyte-value utility model by assigning utility values to individual subranges of analyte values according to the patient’s analyte risk preferences. In some aspects, the personalization can be represented via a personalized utility function.

[0023] In an example, in certain aspects, the therapy management engine can continuously update a model of prediction uncertainty for analyte values based on a personalized distribution of prediction errors for the patient. The model of prediction uncertainty can be, for example, a neural network that learns uncertainty (e.g., prediction error), in a personalized fashion, for one or more prediction methodologies utilized by the system for the patient.

[0024] In another example, in certain aspects, the therapy management engine can continuously allow the user to provide side knowledge about future analyte values and / or new risk perspectives about future multi-analyte values, whether permanent or temporary. The side knowledge may be used to permanently or temporarily reconfigure the multi-analyte-value utility model.

[0025] In another example, in certain aspects, the therapy management engine can continuously evaluate posterior distributions of future analyte values over one or more time horizons. For example, the therapy management engine can determine prediction uncertainty. The prediction uncertainty can be demonstrated in a structure that represents or otherwise describes a degree to which prediction uncertainty changes (e.g., increases) relative to the time horizons. Such a graphical illustration may be periodically referred to herein as a “hurricane track.” In some aspects, a hurricane track can take the form of a graphical representation that can be presented, for example, to a patient or other user. In certain aspects, the therapy management engine can compute, present, and / or implement risk-optimal treatments as needed based on predicted analyte values, prediction uncertainty associated with the predicted analyte values, and / or a personalized utility of analyte values. In addition, or alternatively, the hurricane track can take into account contextual information, such as therapeutic actions taken by a patient (e.g. for a diabetes treatment context,insulin administered or carbohydrates ingested), user physiology, environment (e.g., stress), and / or behavior (e.g., meals, activity, etc.).

[0026] Advantageously, in certain aspects, various solutions described here can provide better and clearer data to a patient or other user, such as utility values from a personalized utility model, indications of uncertainty of predicted analyte values, etc. Such data can increase user involvement in analyte control and, moreover, can improve a patient’s time in range. Further, in certain aspects, various solutions described herein can enable improved and personalized treatment of the patient, since risk-optimal treatment can be determined based on the patient’s own risk tolerance, which tolerance can be updated or temporarily changed. Additionally, in certain aspects, various solutions described herein can inform treatment and / or initiate treatment based on personalized expected utility of different treatments. The treatment can include, for example, administering medicament in some cases (e.g., insulin in implementations that treat diabetes).

[0027] The techniques described herein for decision-theoretic automation and support are described more fully herein with respect to FIGS. 1 A-B and 2-9 below. Note that although certain aspects herein are periodically described with respect to the management of diabetes, a continuous glucose monitoring (CGM) system, a CGM application, and the transmission of analyte measurements related thereto, the protocols and techniques described herein are similarly applicable to any type of health management system that includes any type of analyte sensor (e.g., lactate sensor, ketone sensor, etc ), any type of health management application, and / or transmission of any type of analyte data. For example, a lactate sensor may be used to monitor for events indicative of sepsis based on lactate thresholds, or a ketone sensor may be used to monitor for ketoacidosis based on ketone thresholds. In other examples, a lactate sensor may be used to assess metabolic rates, insulin sensitivity, and / or an intensity of physical activity. Additionally, note that, hereinafter, although certain aspects described herein may periodically refer to a single analyte, multiple analyte sensors (e.g., multiple sensors for different analytes), or multi-analyte sensors (e.g., a single sensor usable for multiple analytes), may be used to measure values of multiple analytes.

[0028] As used herein, the term “continuous” refers to action taken in a fully continuous, semi-continuous, or periodic manner. For example, as used herein, continuous analyte monitoring refers to monitoring one or more analytes in a fully continuous, semi-continuous, periodic manner, whichresults in a data stream of analyte values over time. A data stream of analyte values over time is what allows for meaningful data and insights to be derived using the algorithms described herein for decision-theoretic automation and decision support. In other words, single point-in-time measurements collected as a result of a patient visiting their health care professional every few months results in sporadic data points (e.g., that are, at best, months apart in timing) that cannot form the basis of any meaningful data or insight to be derived. As such, without the continuous analyte monitoring system of the embodiments herein, it is simply impossible to continuously perform decision-theoretic automation and decision support, as described herein.

[0029] Further, the data stream of analyte values collected over time, with the continuous analyte monitoring system presented herein, include real-time analyte values, which allows for deriving meaningful data and insight in real-time using the systems and algorithms described herein. The derived real-time data and insight in turn allows for decision-theoretic automation and decision support. Real-time analyte values herein refer to analyte values that become available and actionable within seconds or minutes of being produced as a result of at least one sensor electronics module of the continuous analyte monitoring system (1) converting sensor current(s) (i.e., analog electrical signals) generated by the continuous analyte sensor(s) into sensor count values, (2) calibrating the count values to generate at least glucose and / or other analyte concentration values using calibration techniques described herein to account for the sensitivity of the continuous analyte sensor(s), and (3) transmitting measured glucose and / or other analyte concentration data, including glucose and / or other analyte concentration values, to a display device via wireless connection.

[0030] For example, the at least one sensor electronics module may be configured to sample the analog electrical signals at a particular sampling period (or rate), such as every 1 second (1 Hz), 5 seconds, 10 seconds, 30 seconds, 1 minute, 3 minutes, 5 minutes, etc., and to transmit the measured glucose and / or other analyte concentration data to a display device at a particular transmission period (or rate), which may be the same as (or longer than) the sampling period, such as every 1 minute (0.016 Hz), 5 minutes, 10 minutes, etc.

[0031] The real-time analyte data that is continuously generated by the continuous analyte monitoring system described herein, therefore, allows the therapy management system herein to perform decision-theoretic automation and decision support, in real-time, which is technicallyimpossible to perform using existing or conventional techniques or systems. Further, because of the real-time nature of this data, it is also humanly impossible to continuously process a real-time data stream of analyte values over time to derive meaningful data and insight using the algorithms and systems described herein to perform decision-theoretic automation and decision support. In other words, deriving meaningful data and insight from a stream of real-time data that is continuously generated, processed, calibrated, and analyzed, using the algorithms and systems described herein, is not a task that can be mentally performed. For example, executing the algorithms described for decision-theoretic automation and decision support, in real-time and on a continuous basis, which would involve using a stream of real-time data that is continuously generated by a patient’s continuous analyte monitoring system and / or significantly large amount of population data (e.g., hundreds or thousands of data points for each one of thousands or millions of patients in the patient population), is not a task that can be mentally performed, especially in real-time at times.

[0032] Further, certain embodiments herein are directed to a technical solution to a technical problem associated with analyte sensor systems. In particular, each analyte sensor system that is manufactured by a sensor manufacturer might perform slightly differently. As such, there might be inconsistencies between sensors and the measurements they generate once in use. Accordingly, certain embodiments herein are directed to determining the performance of an analyte sensor system during a manufacturing calibration process (in vitro), which includes quantifying certain sensor operating parameters, such as a calibration slope (also known as calibration sensitivity), a calibration baseline, etc.

[0033] Generally, calibration sensitivity refers to the amount of electrical current produced by an analyte sensor of an analyte sensor system when immersed in a predetermined amount of a measured analyte. The amount of electrical current may be expressed in units of picoAmps (pA) or counts. The amount of measured analyte may be expressed as a concentration level in units of milligrams per deciliter (mg / dL), and the calibration sensitivity may be expressed in units of pA / (mg / dL) or counts / (mg / dL). The calibration baseline refers to the amount of electrical current produced by the analyte sensor when no analyte is detected, and may be expressed in units of pA or counts.

[0034] The calibration sensitivity, calibration baseline, and other information related to the sensitivity profde for the analyte sensor system may be programmed into the sensor electronics module of the analyte sensor system during the manufacturing process, and then used to convert the analyte sensor electrical signals into measured analyte concentration levels. For example, the calibration slope (calibration sensitivity) may be used to predict an initial in vivo sensitivity (Mo) and a final in vivo sensitivity (Mf), which are programmed into the sensor electronics module and used to convert the analyte sensor electrical signals into measured analyte concentration levels.

[0035] In certain embodiments, during in vivo use, the sensor electronics module of an analyte sensor system samples the analog electrical signals produced by the analyte sensor to generate analyte sensor count values, and then determines the measured analyte concentration levels based on the analyte sensor count values, the initial in vivo sensitivity (Mo), and the final in vivo sensitivity (Mf). For example, measured analyte concentration levels may be determined using a sensitivity function M(t) that is based on the initial in vivo sensitivity (Mo) and the final in vivo sensitivity (Mr). The sensitivity function M(t) may expressed in several different ways, such as a simple correction factor that is not dependent on elapsed time (ti) of in vivo use, a linear relationship between sensitivity and time (ti), an exponential relationship between sensitivity and time (ti), etc. Equation 1 presents one technique for determining a measured analyte concentration level (ACL) from an analyte sensor count value (count) at a time ti:ACL = count / M(ti) Eq. 1 A calibration baseline (baseline) may also be used to determine a measured analyte concentration level (ACL) from an analyte sensor count value (count) at a time ti, and Equation 2 presents one technique:ACL = (count - baseline) / M(ti) Eq. 2

[0036] FIG. 1A illustrates an example of a therapy management system 100 for decision-theoretic automation and decision support, in accordance with certain embodiments of the disclosure. The therapy management system 100 may be utilized for generating and presenting information related to user health, for example, using various user interfaces associated with system 100. Each user of system 100, such as user 102, may interact with a mobile health application, such as mobile health application (“application”) 106 (e.g., a diabetes intervention application that provides therapy management guidance), and / or a health monitoring device, suchas an analyte sensor system 104 (e.g., a glucose monitoring system). User 102, in certain embodiments, may be the patient or, in some cases, the patient’s caregiver. In the embodiments described herein, the user is assumed to be the patient for simplicity only, but is not so limited. As shown, system 100 may include an analyte sensor system 104, a display device 107 that executes application 106, a therapy management engine 112, and a user database 110.

[0037] Analyte sensor system 104 may be configured to generate time-series data, such as analyte measurements (e.g., sensor data), for the user 102, e.g., on a continuous basis, and transmit the analyte measurements to the display device 107 for use by application 106. In some embodiments, the analyte sensor system 104 may transmit the analyte measurements to the display device 107 through a wireless connection (e.g., Bluetooth connection). In certain embodiments, display device 107 is a smart phone. However, in certain embodiments, display device 107 may instead be any other type of computing device such as a laptop computer, a smartwatch, a tablet, or any other computing device capable of executing application 106.

[0038] Note that, while in certain examples the analyte sensor system 104 is assumed to be a glucose monitoring system, analyte sensor system 104 may operate to monitor one or more additional or alternative analytes. As discussed, the term “analyte” as used herein is a broad term, and is to be given its ordinary and customary meaning to a person of ordinary skill in the art (and is not to be limited to a special or customized meaning), and refers without limitation to a substance or chemical constituent in the body or a biological sample (e.g., bodily fluids, including, blood, serum, plasma, interstitial fluid, cerebral spinal fluid, lymph fluid, ocular fluid, saliva, oral fluid, urine, excretions, or exudates).

[0039] Analytes can include naturally occurring substances, artificial substances, metabolites, and / or reaction products. In some embodiments, the analyte measured and used by the devices and methods described herein may include albumin, alkaline phosphatase, alanine transaminase, aspartate aminotransferase, bilirubin, blood urea nitrogen, calcium, CO2, chloride, creatinine, glucose, gamma-glutamyl transpeptidase, hematocrit, lactate, lactate dehydrogenase, magnesium, oxygen, pH, phosphorus, potassium, ketones, sodium, total protein, uric acid, metabolic markers, and / or drugs.

[0040] Other analytes are contemplated as well, including but not limited to acetaminophen, dopamine, ephedrine, terbutaline, ascorbate, uric acid, oxygen, d-amino acid oxidase, plasmaamine oxidase, xanthine oxidase, NADPH oxidase, alcohol oxidase, alcohol dehydrogenase, pyruvate dehydrogenase, diols, Ros, NO, bilirubin, cholesterol, triglycerides, gentisic acid, ibuprophen, L-Dopa, methyl dopa, salicylates, tetracycline, tolazamide, tolbutamide, acarboxyprothrombin; acyl carnitine; adenine phosphoribosyl transferase; adenosine deaminase; albumin; alpha-fetoprotein; amino acid profiles (arginine (Krebs cycle), histidine / urocanic acid, homocysteine, phenylalanine / tyrosine, tryptophan); andrenostenedione; antipyrine; arabinitol enantiomers; arginase; benzoylecgonine (cocaine); biotinidase; biopterin; c-reactive protein; carnitine; carnosinase; CD4; ceruloplasmin; chenodeoxycholic acid; chloroquine; cholesterol; cholinesterase; conjugated 1-0 hydroxy-cholic acid; cortisol; creatine kinase; creatine kinase MM isoenzyme; cyclosporin A; d-penicillamine; de-ethylchloroquine; dehydroepiandrosterone sulfate; DNA (acetylator polymorphism, alcohol dehydrogenase, alpha 1 -antitrypsin, cystic fibrosis, Duchenne / Becker muscular dystrophy, glucose-6-phosphate dehydrogenase, hemoglobin A, hemoglobin S, hemoglobin C, hemoglobin D, hemoglobin E, hemoglobin F, D-Punjab, betathalassemia, hepatitis B virus, HCMV, HIV-1, HTLV-1, Leber hereditary optic neuropathy, MCAD, RNA, PKU, Plasmodium vivax, sexual differentiation, 21 -deoxy cortisol); desbutylhalofantrine; dihydropteridine reductase; diptheria / tetanus antitoxin; erythrocyte arginase; erythrocyte protoporphyrin; esterase D; fatty acids / acylglycines; free 0-human chorionic gonadotropin; free erythrocyte porphyrin; free thyroxine (FT4); free tri-iodothyronine (FT3); fumarylacetoacetase; galactose / gal-1 -phosphate; galactose- 1 -phosphate uridyltransferase; gentamicin; glucose-6-phosphate dehydrogenase; glutathione; glutathione perioxidase; glycocholic acid; glycosylated hemoglobin; halofantrine; hemoglobin variants; hexosaminidase A; human erythrocyte carbonic anhydrase I; 17-alpha-hydroxyprogesterone; hypoxanthine phosphoribosyl transferase; immunoreactive trypsin; lactate; lead; lipoproteins ((a), B / A-l, 0); lysozyme; mefloquine; netilmicin; phenobarbitone; phenyloin; phytanic / pristanic acid; progesterone; prolactin; prolidase; purine nucleoside phosphorylase; quinine; reverse triiodothyronine (rT3); selenium; serum pancreatic lipase; sissomicin; somatomedin C; specific antibodies (adenovirus, anti-nuclear antibody, anti-zeta antibody, arbovirus, Aujeszky's disease virus, dengue virus, Dracunculus medinensis, Echinococcus granulosus, Entamoeba histolytica, enterovirus, Giardia duodenalisa, Helicobacter pylori, hepatitis B virus, herpes virus, HIV-1, IgE (atopic disease), 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, Trepenoma pallidium, Trypanosoma cruzi / rangeli, vesicular stomatis virus, Wuchereria bancrofti, yellow fever virus); specific antigens (hepatitis B virus, HIV-1); succinyl acetone; sulfadoxine; theophylline; thyrotropin (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. Salts, sugar, protein, fat, vitamins, and hormones naturally occurring in blood or interstitial fluids can also constitute analytes in certain embodiments.

[0041] The analyte can be naturally present in the biological fluid, for example, a metabolic product, a hormone, an antigen, an antibody, and the like. Alternatively, the analyte can be introduced into the body, for example, a contrast agent for imaging, a radioisotope, a chemical agent, a fluorocarbon-based synthetic blood, or a drug or pharmaceutical composition, including but not limited to insulin; ethanol; cannabis (marijuana, tetrahydrocannabinol, hashish); inhalants (nitrous oxide, amyl nitrite, butyl nitrite, chlorohydrocarbons, hydrocarbons); cocaine (crack cocaine); stimulants (amphetamines, methamphetamines, Ritalin, Cylert, Preludin, Didrex, PreState, Voranil, Sandrex, Plegine); depressants (barbituates, methaqualone, tranquilizers such as Valium, Librium, Miltown, Serax, Equanil, Tranxene); hallucinogens (phencyclidine, lysergic acid, mescaline, peyote, psilocybin); narcotics (heroin, codeine, morphine, opium, meperidine, Percocet, Percodan, Tussionex, Fentanyl, Darvon, Talwin, Lomotil); designer drugs (analogs of fentanyl, meperidine, amphetamines, methamphetamines, and phencyclidine, for example, Ecstasy); anabolic steroids; and nicotine. The metabolic products of drugs and pharmaceutical compositions are also contemplated analytes. Analytes such as neurochemicals and other chemicals generated within the body can also be analyzed, such as ascorbic acid, uric acid, dopamine, noradrenaline, 3-methoxytyramine (3MT), 3,4-dihydroxyphenylacetic acid (DOPAC), homovanillic acid (HVA), 5 -hydroxy tryptamine (5HT), histamine, Advanced Glycation End Products (AGEs) and 5-hydroxyindoleacetic acid (FH1AA).

[0042] Application 106 may be a mobile health application that is configured to receive and analyze time-series data, including analyte measurements, from the analyte sensor system 104 and / or other devices, as described in greater detail relative to FIGS. IB and 2. In some embodiments, application 106 may transmit analyte measurements received from the analyte sensor system 104 to a user database 110 (and / or the therapy management engine 112), and theuser database 110 (and / or the therapy management engine 112) may store the analyte measurements in a user profile 118 of user 102 for processing and analysis, for example, by the therapy management engine 112. In some embodiments, application 106 may store the analyte measurements in a user profile 118 of user 102 locally for processing and analysis, for example, by the therapy management engine 112.

[0043] In certain embodiments, therapy management engine 112 refers to a set of software instructions with one or more software modules, including a data analysis module (DAM) 111. In some embodiments, therapy management engine 112 executes entirely on one or more computing devices in a private or a public cloud. In some other embodiments, therapy management engine 112 executes partially on one or more local devices, such as display device 107 (e.g., via application 106) and / or analyte sensor system 104, and partially on one or more computing devices in a private or a public cloud. In some other embodiments, therapy management engine 112 executes entirely on one or more local devices, such as display device 107 (e.g., via application 106) and / or analyte sensor system 104.

[0044] In certain embodiments, DAM 111 of therapy management 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 outputs 130 (also referred to herein as “metrics data”). Inputs 127 may be stored in the user profile 118 in the user database 110. DAM 111 can fetch inputs 127 from the user database 110 and compute a plurality of outputs 130 which can then be stored as application data 126 in the user profile 118. Such outputs 130 may include health-related metrics.

[0045] In certain embodiments, application 106 is configured to take as input information relating to user 102 and store the information in a user profile 118 for user 102 in user database 110. For example, application 106 may obtain and record user 102’s demographic info 119, disease progression info 121, and / or medication info 122 in user profile 118. In certain embodiments, demographic info 119 may include one or more of the user’s age, body mass index (BMI), ethnicity, gender, etc. In certain embodiments, disease progression info 121 may include information about the user 102’s disease, such as, for diabetes, whether the user is Type I, Type II, pre-diabetes, or whether the user has gestational diabetes. In certain embodiments, disease progression info 121 also includes the length of time since diagnosis, the level of disease control,level of compliance with disease management therapy, predicted pancreatic function, other types of diagnosis (e.g., heart disease, obesity) or measures of health (e.g., heart rate, exercise, stress, sleep, etc.), and / or the like. In certain embodiments, medication info 122 may include information about the amount and type of medication taken by user 102, such as insulin or non-insulin diabetes medications and / or non-diabetes medication taken by user 102.

[0046] In certain embodiments, application 106 may obtain demographic info 119, disease progression info 121, and / or medication info 122 from the user 102 in the form of user input or from other sources. In certain embodiments, as some of this information changes, application 106 may receive updates from the user 102 or from other sources. In certain embodiments, user profde 118 associated with the user 102, as well as other user profdes associated with other users are stored in a user database 110, which is accessible to application 106, as well as to the therapy management engine 112, over one or more networks (not shown).

[0047] In certain embodiments, application 106 collects inputs 127 through user 102 input and / or a plurality of other sources, including analyte sensor system 104, other applications running on display device 107, and / or one or more other sensors and devices. In certain embodiments, such sensors and devices include one or more of, but are not limited to, an insulin pump, other types of analyte sensors, sensors or devices provided by display device 107 (e.g., accelerometer, camera, global positioning system (GPS), 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 certain embodiments, user profde 118 also stores application configuration information indicating the current configuration of application 106, including its features and settings.

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

[0049] User database 110 may include other user profiles 118 associated with a plurality of other users served by therapy management system 100. More particularly, similar to the operationsperformed with respect to the user 102, the operations performed with respect to these other users may utilize an analyte monitoring system, such as analyte sensor system 104, and also interact with the same application 106, copies of which execute on the respective display devices of the other users 102. For such users, user profdes 118 are similarly created and stored in user database 110.

[0050] FIG. IB is a diagram 150 conceptually illustrating an example continuous analyte sensor system 104 including example continuous analyte sensor(s) with sensor electronics, in accordance with certain aspects of the present disclosure. For example, system 104 may be configured to continuously monitor one or more analytes of a patient, in accordance with certain aspects of the present disclosure.

[0051] Continuous analyte sensor system 104 in the illustrated embodiment includes sensor electronics module 138 and one or more continuous analyte sensor(s) 140 (individually referred to herein as continuous analyte sensor 140 and collectively referred to herein as continuous analyte sensors 140) associated with sensor electronics module 138. Sensor electronics module 138 may be in wireless communication (e.g., directly or indirectly) with one or more of display devices 107a, 107b, 107c, and 107d. In certain embodiments, sensor electronics module 138 may also be in wireless communication (e.g., directly or indirectly) with one or more medical devices, such as medical devices 108 (individually referred to herein as medical device 108 and collectively referred to herein as medical devices 108), and / or one or more other non-analyte sensors 142 (individually referred to herein as non-analyte sensor 142 and collectively referred to herein as non-analyte sensor 142).

[0052] In certain embodiments, a continuous analyte sensor 140 may comprise one or more sensors for detecting and / or measuring analyte(s). The continuous analyte sensor 140 may be a multi-analyte sensor configured to continuously measure two or more analytes or a single analyte sensor configured to continuously measure a single analyte as a non-invasive device, a subcutaneous device, a transcutaneous device, a transdermal device, and / or an intravascular device. In certain embodiments, the continuous analyte sensor 140 may be configured to continuously measure analyte levels of a patient using one or more techniques, such as enzymatic techniques, chemical techniques, physical techniques, electrochemical techniques, spectrophotometric techniques, polarimetric techniques, calorimetric techniques, iontophoretictechniques, radiometric techniques, immunochemical techniques, and the like. The term “continuous,” as used herein, can mean fully continuous, semi-continuous, periodic, etc. In certain aspects, the continuous analyte sensor 140 provides a data stream indicative of the concentration of one or more analytes in the patient. The data stream may include raw data signals, which are then converted into a calibrated and / or filtered data stream used to provide estimated analyte value(s) to the patient.

[0053] In certain embodiments, the continuous analyte sensor 140 may be a multi-analyte sensor, configured to continuously measure multiple analytes in a patient’s body. For example, in certain embodiments, the continuous multi-analyte sensor 140 may be a single sensor configured to measure lactate, glucose, ketones (e.g., 3-beta-hydroxybutyrate, acetoacetate, acetone, etc.), glycerol, and / or free fatty acids in the patient’s body.

[0054] In certain embodiments, one or more multi-analyte sensors may be used in combination with one or more single analyte sensors. As an illustrative example, a multi-analyte sensor may be configured to continuously measure lactate and glucose and may, in some cases, be used in combination with an analyte sensor configured to measure only ketones or only potassium. Information from each of the multi-analyte sensor(s) and single analyte sensor(s) may be combined to provide therapy management support using methods described herein. In further embodiments, other non-contact and or periodic or semi-continuous, but temporally limited, measurements for physiological information may be integrated into the system such as by including weight scale information or non-contact heart rate monitoring from a sensor pad under the patient while in a chair or bed, through an infra-red camera detecting temperature and / or blood flow patterns of the patient, and / or through a visual camera with machine vision for height, weight, or other parameter estimation without physical contact.

[0055] In certain embodiments, the continuous analyte sensor(s) 140 may comprise a percutaneous wire that has a proximal portion coupled to the sensor electronics module 138 and a distal portion with several electrodes, such as a measurement electrode and a reference electrode. The measurement (or working) electrode may be coated, covered, treated, embedded, etc., with one or more chemical molecules that react with a particular analyte, and the reference electrode may provide a reference electrical voltage. The measurement electrode may generate the analog electrical signal, which is conveyed along a conductor that extends from the measurementelectrode to the proximal portion of the percutaneous wire that is coupled to the sensor electronics module 138. After the continuous analyte monitoring system 104 has been applied to epidermis of the patient, continuous analyte sensor(s) 140 penetrates the epidermis, and the distal portion extends into the dermis and / or subcutaneous tissue under epidermis. Other configurations of continuous analyte sensor(s) 140 may also be used, such as a multi-analyte sensor that includes multiple measurement electrodes, each generating an analog electrical signal that represents the concentration levels of a particular analyte.

[0056] Generally, a single-analyte sensor generates an analog electrical signal that is proportional to the concentration level of a particular analyte. Similarly, each multi-analyte sensor generates multiple analog electrical signals, and each analog electrical signal is proportional to the concentration level of a particular analyte. As an illustrative example, continuous analyte sensor 140 may include a single-analyte sensor configured to measure lactate concentration levels, and another single-analyte sensor configured to measure glucose concentration levels of the patient. As another illustrative example, continuous analyte sensor(s) 140 may include a single-analyte sensor configured to measure glucose concentration levels, and one or more multi-analyte sensors configured to measure lactate concentration levels, ketone concentration levels, creatinine concentration levels, etc. As yet another illustrative example, continuous analyte sensor(s) 140 may include a multi-analyte sensor configured to measure lactate concentration levels, glucose concentration levels, ketone concentration levels, creatinine concentration levels, etc. Accordingly, continuous analyte sensor(s) 140 is configured to generate at least one analog electrical signal that is proportional to the concentration level of a particular analyte, and sensor electronics module 138 is configured to convert the analog electrical signal into an analyte sensor count values, calibrate the analyte sensor count values based on the sensitivity profile of the continuous analyte sensor(s) 140 to generate measured analyte concentration levels, and transmit the measured analyte concentration level data, including the measured analyte concentration levels, to a display device, such as display devices 107b, 107c, and / or 107d, via a wireless connection. For example, sensor electronics module 138 may be configured to sample the analog electrical signal at a particular sampling period (or rate), such as every 1 second (1 Hz), 5 seconds, 10 seconds, 30 seconds, 1 minute, 3 minutes, 5 minutes, etc., and to transmit the measured analyte concentration data to the display device at a particular transmission period (or rate), which may be the same as (or longer than) the sampling period, such as every 1 minute (0.016 Hz), 5 minutes,10 minutes, 30 minutes, at the conclusion of the wear period, etc. Depending on the sampling and transmission periods, the measured analyte concentration data transmitted to the display device include at least one measured analyte concentration level having an associated time tag, sequence number, etc.

[0057] In certain embodiments, continuous analyte sensor(s) 140 may incorporate a thermocouple within, or alongside, the percutaneous wire to provide an analog temperature signal to the sensor electronics module 138, which may be used to correct the analog electrical signal or the measured analyte data for temperature. In other embodiments, the thermocouple may be incorporated into the sensor electronics module 138 above the adhesive pad, or, alternatively, the thermocouple may contact the epidermis of the patient through openings in the adhesive pad.

[0058] In certain embodiments, the sensor electronics module 138 includes, inter alia, processor 133, storage element or memory 134, wireless transmitter / receiver (transceiver) 136, one or more antennas coupled to wireless transceiver 136, analog electrical signal processing circuitry, analog to-digital (A / D) signal processing circuitry, digital signal processing circuitry, a power source for continuous analyte sensor(s) 140 (such as a potentiostat), etc.

[0059] Processor 133 may be a general -purpose or application-specific microprocessor, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc., that executes instructions to perform control, computation, input / output, etc. functions for the sensor electronics module 138. Processor 133 may include a single integrated circuit, such as a micro processing device, or multiple integrated circuit devices and / or circuit boards working in cooperation to accomplish the appropriate functionality. In certain embodiments, processor 133, memory 134, wireless transceiver 136, the A / D signal processing circuitry, and the digital signal processing circuitry may be combined into a system-on-chip (SoC).

[0060] Generally, processor 133 may be configured to sample the analog electrical signal using the A / D signal processing circuitry at regular intervals (such as the sampling instant or period) to generate analyte sensor count values based on the analog electrical signals produced by the continuous analyte sensor(s) 140, calibrate the analyte sensor count values based on the sensitivity profile of the continuous analyte sensor(s) 140 to generate measured analyte concentration levels, and generate measured analyte data from the measured analyte concentration levels, generate sensor data packages that include, inter alia, the measured analyte concentration level data.Processor 133 may store the measured analyte concentration level data in memory 134, and generate the sensor data packages at regular intervals (such as the transmission period) for transmission by wireless transceiver 136 to a display device, such as display devices 107b, 107c, 107d, and / or 107a. Processor 133 may also add additional data to the sensor data packages, such as supplemental sensor information that includes a sensor identifier, a sensor status, temperatures that correspond to the measured analyte data, etc. The sensor data packages are then wirelessly transmitted over a wireless connection to the display device. In certain embodiments, the wireless connection is a Bluetooth or Bluetooth Low Energy (BLE) connection. In such embodiments, the sensor data packages are transmitted in the form of Bluetooth or BLE data packets to the display device

[0061] In various embodiments, memory 134 may include volatile and nonvolatile medium. For example, memory 134 may include combinations of random access memory (RAM), dynamic RAM (DRAM), static RAM (SRAM), read only memory (ROM), flash memory, cache memory, and / or any other type of non-transitory computer-readable medium. Memory 134 may store one or more analyte sensor system applications, modules, instruction sets, etc. for execution by processor 133, such as instructions to generate measured analyte data from the analyte sensor count values, etc.

[0062] Memory 134 may also store certain sensor operating parameters 135, such as a calibration slope (or calibration sensitivity), a calibration baseline, etc. In particular, the calibration sensitivity, calibration baseline, and other information related to the sensitivity profile for the sensor electronics module 138 may be programmed into the sensor electronics module 138 during the manufacturing process, and then used to convert the analyte sensor electrical signals into measured analyte concentration levels. For example, as discussed above, the calibration slope may be used to predict an initial in vivo sensitivity (Mo) and a final in vivo sensitivity (Mf), which are stored in memory 134 and used to convert the analyte sensor electrical signals into measured analyte concentration levels. In certain embodiments, calibration sensitivity (Mcc) 146 and / or calibration baseline 147 may be stored in memory 134.

[0063] In certain embodiments, sensor electronics module 138 includes electronic circuitry associated with measuring and processing the continuous analyte sensor data, including prospective algorithms associated with processing and calibration of the sensor data. Sensorelectronics module 138 can be physically connected to continuous analyte sensor(s) 140 and can be integral with (non-releasably attached to) or releasably attachable to continuous analyte sensor(s) 140. Sensor electronics module 138 may include hardware, firmware, and / or software that enable measurement of levels of analyte(s) via continuous analyte sensor(s) 140. For example, sensor electronics module 138 can include a potentiostat, a power source for providing power to the sensor, other components useful for signal processing and data storage, and a telemetry module for transmitting data from the sensor electronics module to, e.g., one or more display devices. Electronics can be affixed to a printed circuit board (PCB), or the like, and can take a variety of forms. For example, the electronics can take the form of an integrated circuit (IC), such as an Application-Specific Integrated Circuit (ASIC), a microcontroller, and / or a processor.

[0064] Display devices 107b, 107c, 107d, and / or 107a are configured for displaying displayable sensor data, including analyte data, which may be transmitted by sensor electronics module 138. Each of display devices 107b, 107c, 107d, or 107a may include a display such as a touchscreen display 109b, 109c, 109d, and / or 109a for displaying sensor data to a patient and / or for receiving inputs from the patient. For example, a graphical user interface (GUI) may be presented to the patient for such purposes. In certain embodiments, the display devices may include other types of user interfaces such as a voice user interface instead of, or in addition to, a touchscreen display for communicating sensor data to the patient of the display device and / or for receiving patient inputs. Display devices 107a, 107b, 107c, and 107d may be examples of display device 107 illustrated in FIG. 1 used to display sensor data to a patient of the system of FIG. 1 and / or to receive input from the patient.

[0065] In certain embodiments, one, some, or all of the display devices are configured to display or otherwise communicate (e.g., verbalize) the sensor data as it is communicated from the sensor electronics module (e.g., in a customized data package that is transmitted to display devices based on their respective preferences), without any additional prospective processing required for calibration and real-time display of the sensor data.

[0066] The plurality of display devices may include a custom display device specially designed for displaying certain types of displayable sensor data associated with analyte data received from sensor electronics module. In certain embodiments, the plurality of display devices may be configured for providing alerts / alarms based on the displayable sensor data. Display device107b is an example of such a custom device. In certain embodiments, one of the plurality of display devices is a smartphone, such as display device 107c which represents a mobile phone, using a commercially available operating system (OS), and configured to display a graphical representation of the continuous sensor data (e.g., including current and historic data). Other display devices can include other hand-held devices, such as display device 107d which represents a tablet, display device 107a which represents a smart watch or fitness tracker, medical device 108 (e.g., an insulin delivery device or a blood glucose meter), and / or a desktop or laptop computer (not shown).

[0067] Because different display devices provide different user interfaces, content of the data packages (e.g., amount, format, and / or type of data to be displayed, alarms, and the like) can be customized (e.g., programmed differently by the manufacture and / or by an end user, such as the patient) for each particular display device. Accordingly, in certain embodiments, a plurality of different display devices can be in direct wireless communication with a sensor electronics module (e.g., such as an on-skin sensor electronics module 138 that is physically connected to continuous analyte sensor(s) 140) during a sensor session to enable a plurality of different types and / or levels of display and / or functionality associated with the displayable sensor data.

[0068] As mentioned, sensor electronics module 138 may be in communication with a medical device 108. Medical device 108 may be a passive device in some example embodiments of the disclosure. For example, medical device 108 may be an insulin pump for administering insulin to a patient. For a variety of reasons, it may be desirable for such an insulin pump to receive and track lactate, glucose, ketones, glycerol and free fatty acid values transmitted from continuous analyte sensor systems 104, where continuous analyte sensor 140 is configured to measure lactate, glucose, ketones, glycerol, and / or free fatty acids.

[0069] Further, as mentioned, sensor electronics module 138 may also be in communication with other non-analyte sensors 142. Non-analyte sensors 142 may include, but are not limited to, an altimeter sensor, an accelerometer sensor, a global positioning system (GPS) sensor, a temperature sensor, a respiration rate sensor, etc. Non-analyte sensors 142 may also include monitors such as heart rate monitors, blood pressure monitors, pulse oximeters, caloric intake monitors, indirect calorimetry devices, continuous positive airway pressure machines, and medicament delivery devices. One or more of these non-analyte sensors 142 may provide data totherapy management engine 112 described further below. Tn some aspects, a patient may manually provide some of the data for processing by the therapy management engine 112 of FIG. 1.

[0070] In certain embodiments, non-analyte sensors 142 may further include sensors for measuring skin temperature, core temperature, sweat rate, and / or sweat composition.

[0071] In certain embodiments, the non-analyte sensors 142 may be combined in any other configuration, such as, for example, combined with one or more continuous analyte sensors 140. As an illustrative example, a non-analyte sensor, e.g., a temperature sensor, may be combined with a continuous glucose sensor 140 to form a glucose / temperature sensor used to transmit sensor data to the sensor electronics module 138 using common communication circuitry. As another illustrative example, a non-analyte sensor, e.g., a temperature sensor, may be combined with a multi-analyte sensor 140 configured to measure lactate and glucose to form a lactate / glucose / temperature sensor used to transmit sensor data to the sensor electronics module 138 using common communication circuitry.

[0072] In certain embodiments, a wireless access point (WAP) may be used to couple one or more of continuous analyte sensor system 104, the plurality of display devices, medical device(s) 108, and / or non-analyte sensor(s) 142 to one another. For example, such WAP may provide WiFi and / or cellular connectivity among these devices. Near Field Communication (NFC) and or Bluetooth may also be used among devices depicted in diagram 150 of FIG. IB.

[0073] FIG. 2 illustrates example inputs and example metrics that are generated based on the inputs in accordance with certain embodiments of the disclosure. In particular, FIG. 2 illustrates example inputs 127 on the left, application 106 and therapy management engine 112, with DAM 111, in the middle, and example outputs 130 on the right. In certain embodiments, application 106 may obtain inputs 127, in the form of time-series data, through one or more channels (e.g., continuous analyte sensor(s) 140, non-analyte sensor(s) 142, various applications executing on display device 107, etc.). Inputs 127 may be further processed by DAM 111 to output a plurality of metrics, such as outputs 130. Further, inputs (e.g., inputs 127) and metrics (e.g., outputs 130) may be used by the DAM 111 and / or any computing device in the system 100 to perform various processes. Any of inputs 127 may be used for computing any of outputs 130. In certain embodiments, each one of outputs 130 may correspond to one or more values, e.g., discrete numerical values, ranges, or qualitative values (high / medium / low or stable / unstable). In someembodiments, some or all of outputs 130 may include time-series data and / or be provided in the form of time-series data.

[0074] In certain embodiments, inputs 127 include food consumption information. Food consumption information may include information about one or more of meals, snacks, and / or beverages, such as one or more of the size, content (carbohydrate, fat, protein, etc.), sequence of consumption, and time of consumption. In certain embodiments, food consumption may be provided by the user through manual entry, by providing a photograph through an application that is configured to recognize food types and quantities, and / or by scanning a bar code or menu. In various examples, meal size may be manually entered as one or more of calories, quantity (e.g., 'three cookies'), menu items (e.g., 'Royale with Cheese'), and / or food exchanges (1 fruit, 1 dairy). In some examples, meals may also be entered with the user's typical items or combinations for this time or setting (e.g., workday breakfast at home, weekend brunch at restaurant). In some examples, meal information may be received via a convenient user interface provided by application 106.

[0075] In certain embodiments, inputs 127 include activity information. Activity information may be provided, for example, the one or more non-analyte sensors 142 of FIG. IB. In certain embodiments, activity information may additionally be provided through manual input by user 102. Activity information may include, for example, a time series for each of heart rate, activity minutes, step count, floors climbed, location information (e.g., GPS data), calories burned, sleep duration and / or quality, activity level (e.g., light, medium, or heavy), and / or similar information. In addition, or alternatively, the activity information can include one or more time series for recorded activities of one or more defined activity types (e.g., walk, run, sprint, swim, weightlift etc.), where each activity is associated with a duration and / or time period.

[0076] In certain embodiments, inputs 127 include patient statistics, such as one or more of age, height, weight, body mass index, body composition (e.g., % body fat), stature, build, or other information. Patient statistics may be provided through a user interface, by interfacing with an electronic source such as an electronic medical record, and / or from measurement devices. The measurement devices may include one or more of a wireless, e.g., Bluetooth-enabled, weight scale and / or camera, which may, for example, communicate with the display device 107 to provide patient data.

[0077] In certain embodiments, inputs 127 include information relating to the user’s medication intake. For example, the user’s medication intake may include the user’s insulin delivery. Such information may be received, via a wireless connection on a smart pen, via user input, and / or from an insulin pump (e.g., medical device 108). Insulin delivery information may include one or more of insulin volume, time of delivery, etc. Other configurations, such as insulin action time or duration of insulin action, may also be received as inputs.

[0078] In certain embodiments, inputs 127 include physiological information received from non-analyte sensor(s) 142 , which may detect one or more of heart rate, respiration, oxygen saturation, body temperature, etc. (e g., to detect illness, stress levels, etc.). In certain embodiments, inputs 127 include time, such as time of day, or time from a real-time clock.

[0079] In certain embodiments, inputs 127 include analyte data, which may be provided as input from analyte sensor system 104, for example, in any of the ways described with respect to FIG. 1A. An example of analyte data is glucose data, which may be provided and / or stored as a time series corresponding to time-stamped glucose measurements over time. Other types of analyte data, such as ketone data, potassium data, lactate data, etc., may similarly be provided and / or stored as a time series.

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

[0081] In certain embodiments, outputs 130 generated, determined, or computed by DAM 111 include an activity level metric. The activity level metric may indicate a level of activity of the user. In certain embodiments, the activity level metric may be determined, for example based on input from an activity sensor or other physiologic sensors. In certain embodiments, the activity level metric may be calculated by DAM 111 based on one or more of inputs 127, such as one ormore of activity information, physiological information, analyte data, time, user input, etc. Activity level may indicate whether the user is exercising, at rest, sleeping, etc.

[0082] In certain embodiments, outputs 130 generated, determined, or computed by DAM 111 include an insulin resistance metric (also referred to herein as an “insulin resistance”). The insulin resistance metric may be determined using historical data, real-time data, or a combination thereof, and may, for example, be based upon one or more inputs 127, such as one or more of food consumption information, blood glucose information, insulin delivery information, the resulting glucose levels, etc. In certain embodiments, the insulin on board metric may be determined using insulin delivery information, and / or known or learned (e.g., from patient data) insulin time action profiles, which may account for both basal metabolic rate (e g., update of insulin to maintain operation of the body) and insulin usage driven by activity or food consumption.

[0083] In certain embodiments, outputs 130 generated, determined, or computed by DAM 111 include a meal state metric. The meal state metric may indicate the state the user is in with respect to food consumption. For example, the meal state may indicate whether the user is in one of a fasting state, pre-meal state, eating state, post-meal response state, or stable state. In certain embodiments, the meal state may also indicate nourishment on board, e.g., meals, snacks, or beverages consumed, and may be determined, for example from food consumption information, time of meal information, and / or digestive rate information, which may be correlated to food type, quantity, and / or sequence (e.g., which food / beverage was eaten first.).

[0084] In certain embodiments, outputs 130 generated, determined, or computed by DAM 111 include health and sickness metrics. Health and sickness metrics may be determined, for example, based on one or more of user input (e.g., pregnancy information or known sickness information), from non-analyte sensor(s) 142, such as physiologic sensors (e.g., temperature), activity sensors, or a combination thereof. In certain embodiments, based on the values of the health and sickness metrics, for example, the user’s state may be defined as being one or more of healthy, ill, rested, or exhausted. In certain embodiments, health and sickness metric may indicate the user’s heart rate, stress level, etc.

[0085] In certain embodiments, outputs 130 generated, determined, or computed by DAM 111 include analyte level metrics. Analyte level metrics may be determined from analyte data (e.g., glucose measurements obtained from analyte sensor system 104). In some examples, an analytelevel metric may also be determined, for example, based upon historical information about analyte levels in particular situations, e.g., given a combination of food consumption, insulin, and / or activity. An analyte level metric may include a rate of change of the analyte, time in range, time spent below a threshold level, time spent above a threshold level, or the like. In certain embodiments, an analyte trend may be determined based on the analyte level over a certain period of time. As described above, example analytes may include glucose, ketones, lactate, potassium and others described herein.

[0086] In certain embodiments, outputs 130 generated, determined, or computed by DAM 111 include a disease stage. For example disease stages for Type II diabetics may include a pre-diabetic stage, an oral treatment stage, and a basal insulin treatment stage. In certain embodiments, degree of glycemic control (not shown) may also be determined as an outcome metric, and may be based, for example, on one or more of glucose levels, variation in glucose level, or insulin dosing patterns.

[0087] In certain embodiments, outputs 130 generated, determined, or computed by DAM 111 include clinical metrics. Clinical metrics generally indicate a clinical state a user is in with respect to one or more conditions of the user, such as diabetes. For example, in the case of diabetes, clinical metrics may be determined based on glycemic measurements, including one or more of A1C, trends in A1C, time in range, time spent below a threshold level, time spent above a threshold level, and / or other metrics derived from glucose values. In certain embodiments, clinical metrics may also include one or more of estimated A1C, glycemic variability, hypoglycemia, and / or health indicator (time magnitude out of target zone).

[0088] FIG. 3 illustrates an example of a process 300 for decision-theoretic automation and decision support for a patient, in accordance with certain embodiments. In some aspects, the process 300, or certain blocks thereof, can execute continuously (e.g., fully continuously, semi-continuously, periodically, etc.). In addition, or alternatively, the process 300 can represent an arrangement of related functions performed by the therapy management engine 112 that can each performed separately. In addition, or alternatively, the process 300 and / or the blocks thereof can be executed on-demand, upon initial use of the analyte sensor system 104, etc.

[0089] In some embodiments, the process 300 can be executed, for example, by the therapy management engine 112 of FIGS. 1A-B and 2. In addition, or alternatively, the process 300 can be executed, for example, by the analyte sensor system 104 of FIGS. 1A-B. In addition, oralternatively, the process 300 can be executed, for example, by the application 106 of FIGS. 1 A-B and 2. In addition, or alternatively, the process 300 can be executed generally by any of the display devices 107 of FIGS. 1A-B and 2. Although any number of systems, in whole or in part, can implement the process 300, to simplify discussion, the process 300 will be described generically in relation to the therapy management engine 112 of FIGS. 1 A-B and 2.

[0090] At block 302, the therapy management engine 112 configures an analyte-value utility model for the patient (e.g., shown as analyte-value utility model 942 in FIG. 9). For example, the block 302 can include eliciting, from the patient or other user, analyte risk preferences (e.g., at initial configuration time) to form a utility function whose future expected value may facilitate characterization of an optimal treatment for the patient. In certain aspects, the analyte-value utility model can define a utility of analyte values in a way that is meaningful for the patient. The analytevalue utility model can accept, as input, for example, one or more predicted glucose or analyte values and a quantification of prediction uncertainty to produce expected utility. In some aspects, as discussed previously, the analyte-value utility model can relate to values of multiple analytes. For simplicity of description, however, examples will be described relative to values of a single analyte such as glucose. An example of the configuration of the analyte-value utility model will be described in greater detail relative to FIG. 4.

[0091] At block 304, the therapy management engine 112 continuously updates a model of prediction uncertainty (e.g., shown as model 944 in FIG. 9). The model of prediction uncertainty can be, for example, a neural network that learns uncertainty (e.g., prediction error) for one or more prediction methodologies utilized by the system. In some aspects, the other predication methodologies can be external to the therapy management engine 112. In certain aspects, the block 304 can include, for example, continuously updating distributions that describe uncertainty about factors such as user physiology, user environment, user behavior, and unmodeled uncertainty (e.g., variation not explained by uncertainty about physiology, environment, and / or behavior). In an example, updating the model of prediction uncertainty can include retrospectively collecting a sample of predictions and corresponding errors for the patient, classifying the prediction errors according to a metabolic state of the patient at a time of prediction (e.g., for multiple timehorizons), constructing one or more empirical distributions of prediction error that are conditional on one or more metabolic states of the patient, and creating a representation of the distributions, for example, in the form of a deep learning approximation architecture.

[0092] At block 306, the therapy management engine 112 can continuously allow reconfiguration of the analyte-value utility model, for example, based on user input from the patient or other user. In some aspects, the user input can include side knowledge about an influence on future analyte values, such as knowledge about future activities (e.g., a 30-minute swim or run expected to begin at 2 pm), meals (e.g., plans to eat cheeseburger at noon), and / or the like. In addition, or alternatively, in some aspects, the user input can relate to a risk tolerance of the patient. In an example, the user input can represent a change to the patient’s general risk tolerance (e.g., glucose levels below 120 mg / dL are no longer a source of considerable anxiety for the patient). In an another example, the user input can relate to a new or temporary risk perspective, such as an indication of a temporary objective or priority (e.g., maximize sleep quality), an indication of a future event that temporarily impacts the patient’s risk tolerance, etc. For example, the user may have meeting, activity, performance, or other event the next day and want to prioritize sleep the night before. An example of functionality that can occur, for example, as part of reconfiguring the analyte-value utility model, will be discussed relative to FIG. 4.

[0093] At block 308, the therapy management engine 112 continuously evaluates posterior distributions of future analyte values over a time window, such as one or more time horizons. For example, the block 308 can include generating one or more hurricane tracks relative to each of the time horizons. As discussed previously, the hurricane tracks can each be a structure that represents or otherwise describes a degree to which prediction uncertainty changes (e.g., increases) over the course of a given time horizon.

[0094] In some aspects, the block 308 can include generating multiple hurricane tracks for each of the time horizons based on the occurrence of different treatment scenarios, such as different prospective treatments or combinations thereof. The prospective treatments can include, for example, medicament delivery, physical activity, meal intake, and / or the like. In various aspects, the prospective treatments can vary in type (e.g., medicament delivery, activity, meal intake), amount (e.g., dosage of medicament such as insulin, duration of activity, amount of carbohydrates), timing, and / or in other ways. Examples of a hurricane track will be discussed relative to FIGS. 6 and 7.

[0095] At block 310, the therapy management engine 112 computes, presents and / or implements risk-optimal treatments. In some aspects, the block 310 can be triggered, for example,at any time a treatment decision is to be made. For example, in a diabetes treatment context, the block 310 can be triggered, for example, at a time of an insulin bolus calculation, at bed time, in response to being triggered by the patient or other user (e.g., in response to a request for advice to avoid hypoglycemia or hyperglycemia), and / or the like. In certain aspects, the block 310 can include computing treatments (e.g., doses of medicament, amount of physical activity, or the like) that optimize expected utility according to the analyte-value utility model. An example of functionality that can be performed at the block 310 will be discussed relative to FIG. 5

[0096] At block 312, the therapy management engine 112 continuously assesses an extent to which the analyte-value utility model is consistent with treatment decisions made by the patient. For example, if the patient consistently doses more or less than a determined optimal dose, the therapy management engine 112 can update the analyte-value utility model to reflect the patient’s actions. For example, in a diabetes treatment context, if the patient consistently does more insulin than a determined risk-optimal dose of insulin, the therapy management engine 112 can adjust the analyte-value utility model to attribute higher utility to lower glucose values. In addition, or alternatively, the therapy management engine 112 can notify the patient or other user about inconsistencies between risk-optimal doses determined via the analyte-value utility model and actual doses administered to the patient.

[0097] At block 314, the therapy management engine 112 executes retrospective analysis to improve a health outcome of the patient, such as a glycemic outcome of the patient. The retrospective analysis can include, for example, adjusting parameters, such as utility values in the analyte-value utility model, generating one or more reports, and / or the like.

[0098] FIG. 4 illustrates an example of a process 400 for configuring an analyte-value utility model, in accordance with certain embodiments. In some aspects, the process 400 can execute as all or part of the block 302 of FIG. 3, for example, as part of initial configuration of the analytevalue utility model. In some aspects, the process 400 can execute as all or part of the block 306, for example, as part reconfiguration of the analyte-value utility model. In addition, or alternatively, the process 400 and / or the blocks thereof can be executed on-demand or in another suitable scenario.

[0099] In some embodiments, the process 400 can be executed, for example, by the therapy management engine 112 of FIGS. 1A-B and 2. In addition, or alternatively, the process 400 canbe executed, for example, by the analyte sensor system 104 of FIGS. 1A-B. In addition, or alternatively, the process 400 can be executed, for example, by the application 106 of FIGS. 1A-B and 2. In addition, or alternatively, the process 400 can be executed generally by any of the display devices 107 of FIGS. 1A-B and 2. Although any number of systems, in whole or in part, can implement the process 400, to simplify discussion, the process 400 will be described generically in relation to the therapy management engine 112 of FIGS. 1A-B and 2.

[0100] At block 402, the therapy management engine 112 receives analyte risk preferences for the patient. The analyte risk preferences can indicate, for the patient, a utility of analyte values across a range of analyte values. In some aspects, the analyte risk preferences can be specified, for example, by the patient or other user selecting a mode that assigns predefined utility values to individual subranges of analyte values. In some aspects, healthcare professionals or experienced users can directly or indirectly draw a shape of a utility function.

[0101] In some aspects, the analyte risk preferences can indicate how the patient’s general risk tolerance varies across a range of analyte levels. For example, for a patient that becomes anxious with analyte values below a certain level (e.g., glucose levels below 120 mg / dL), the analyte risk preference may specify a greater than typical utility to analyte values above that level (e.g., glucose levels above 120 mg / dL). In some aspects, the analyte risk preferences can represent a temporary change in the user’s risk tolerance. For example, the patient or other user can select a “SLEEP PRIORITY MODE” in anticipation of an important event the next day. In the “SLEEP PRIORITY MODE,” for example, higher analyte values may be assigned a greater than typical utility (e.g., for values above 140).

[0102] At block 404, the therapy management engine 112 personalizes an analyte-value utility model based on the analyte risk preferences. For example, the therapy management engine 112 can assign utility values to individual subranges of analyte values according to the analyte risk preferences. For example, higher values can indicate higher value to the user. In this way, the personalized analyte-value utility model can describe variation in analyte-value utility across a range of analyte values. The personalization can be temporary (e.g., to accommodate a one-time event) or ongoing (e.g., in the case analyte risk preferences representing the user’s general risk tolerance). After block 404, the process 400 ends.

[0103] FIG. 5 illustrates an example of a process 500 for computing, presenting and / or implementing risk-optimal treatments, in accordance with certain embodiments. In some aspects, the process 500 can execute as all or part of the block 310 of FIG. 3. In addition, or alternatively, the process 500 and / or the blocks thereof can be executed on-demand or in another suitable scenario.

[0104] In some embodiments, the process 500 can be executed, for example, by the therapy management engine 112 of FIGS. 1A-B and 2. In addition, or alternatively, the process 500 can be executed, for example, by the analyte sensor system 104 of FIGS. 1A-B. In addition, or alternatively, the process 500 can be executed, for example, by the application 106 of FIGS. 1A-B and 2. In addition, or alternatively, the process 500 can be executed generally by any of the display devices 107 of FIGS. 1A-B and 2. Although any number of systems, in whole or in part, can implement the process 500, to simplify discussion, the process 500 will be described generically in relation to the therapy management engine 112 of FIGS. 1A-B and 2.

[0105] At block 502, for each of one or more prospective treatments, the therapy management engine 112 receives predicted analyte values for a time horizon. The predicted analyte values can be received, for example, form an external prediction model. As discussed previously, the one or more prospective treatments can include, for example, medicament delivery, physical activity, meal intake, and / or the like. In various aspects, the prospective treatments can vary in type (e.g., medicament delivery, physical activity, or meal intake), amount (e.g., dosage of medicament such as insulin, duration of physical activity, amount of carbohydrates), timing, and / or in other ways.

[0106] At block 504, for each of the one or more prospective treatments, the therapy management engine 112 determines a prediction uncertainty associated with the predicted analyte values. The block 504 can include using the model of prediction uncertainty discussed relative to the block 304 of FIG. 3. In cases where the one or more prospective treatments include a plurality of prospective treatments, the block 504 can include, for example, determining the prediction uncertainty for each of the plurality of prospective treatments. For example, the therapy management engine 112 can receive, access, or generate one or more hurricane tracks that demonstrate the uncertainty, as discussed relative to the block 304 of FIG. 3. Examples of a hurricane track will be discussed relative to FIGS. 6 and 7.

[0107] At block 506, for each of the one or more prospective treatments, the therapy management engine 112 determines an expected utility of the prospective treatment using, for example, the analyte-value utility model discussed relative to FIG. 3. At block 508, the therapy management engine 112 determines a risk-optimal treatment for the patient based on the analytevalue utility model. The risk-optimal treatment can be, for example, the prospective treatment with the greatest expected utility.

[0108] At block 510, the therapy management engine 112 presents information related to the risk-optimal treatment and / or the each of the one or more prospective treatments. For example, the therapy management can display to the patient or other user, or cause to be displayed to the patient or other user, information indicating the risk-optimal treatment. In some aspects, the risk-optimal treatment can be indicated in relation to its expected utility. In some aspects, the block 510 can include displaying each of the one or more prospective treatments in relation to their expected utility.

[0109] In some aspects, the block 510 can include displaying and / or describing the risk-optimal treatment and / or any other prospective treatments in terms of certainty equivalents. The certainty equivalents can describe a treatment in comparison or relation to another analyte-value scenario. For example, a prompt to the patient or other user can state, “According to your risk preferences and based on the uncertainty of the situation, the expected utility of this risk-optimal dose is equivalent to (1) a constant blood glucose at a value of 110 or (2) 70% time in range and 5% time below range over the next 8 hours.” In addition, or alternatively, the block 510 can include displaying hurricane tracks similar to those discussed previously.

[0110] At block 512, the therapy management engine 112 causes administration of a treatment. The block 512 can include, for example, instructing medicament delivery (e.g., an instruction to an insulin pump or smart pen). In some aspects, the therapy management engine 112 can automatically instruct medicament delivery based on the risk-optimal treatment. Alternatively, in some aspects, the therapy management engine 112 can instruct medicament delivery based on user input that is responsive to the presented information. The treatment may be, for example, the risk-optimal treatment, another of the prospective treatment(s), or a different treatment selected by the user based on a review of the presented information. In some aspects, the block 512 can be omitted(e g., if no medicament delivery determined, if treatment delivery is not permitted by settings or and / or the patient’s devices, etc.). After block 512, the process 500 ends.[OHl] FIG. 6 illustrates an example of a hurricane track 602 relative to expected glucose values, as discussed above relative to FIGS. 3 and 5, in accordance with certain embodiments. In the example of FIG. 6, the hurricane track 602 is based on a prospective treatment in the form of a bolus 610 and predicted glucose values 604.

[0112] FIG. 6 further illustrates an example of a personalized analyte-value utility model 606 in comparison to a non-personalized analyte-value utility model 608. The non-personalized analyte-value utility model 608 can be based on, for example, population values for expected utility of different glucose values. The personalized analyte-value utility model 606 can be based on analyte risk preferences, for example, as discussed above relative to FIGS. 3 and 4. In the illustrated embodiment, the personalized analyte-value utility model 606, as compared to the nonpersonalized analyte-value utility model 608, associates higher utility with higher glucose values (e.g., as a result of a general risk intolerance for low glucose values or a temporary desire virtually eliminating a need to treat hypoglycemia).

[0113] FIG. 7 illustrates an example of updating a model of prediction uncertainty as discussed, for example, relative to the block 304 of FIG. 3, in accordance with certain embodiments. In the example of FIG. 7, a hurricane track 702A is shown in relation to actual or measured analyte values 704 that are subsequently observed, for example, by the therapy management engine 112. Accordingly, the therapy management engine 112 can generate an ideal hurricane track 702B based on the actual or measured analyte values 704 and update the model of prediction uncertainty based thereon.

[0114] FIG. 8 illustrates an example of a process 800 for decision-theoretic automation and decision support for a patient in diabetes treatment context. More particularly, in certain aspects, the process 800 illustrates an application of the process 300 to a scenario of providing treatment advice in a bedtime scenario, for example, to avoid overnight hypoglycemia and / or hyperglycemia. In some aspects, the process 800, or certain blocks thereof, can execute continuously (e.g., fully continuously, semi-continuously, periodically, etc.). In addition, or alternatively, the process 800 can represent an arrangement of related functions performed by the therapy management engine112 that can each performed separately. In addition, or alternatively, the process 800 and / or the blocks thereof can be executed on-demand, upon initial use of the analyte sensor system 104, etc.

[0115] In some embodiments, the process 800 can be executed, for example, by the therapy management engine 112 of FIGS. 1A-B and 2. In addition, or alternatively, the process 800 can be executed, for example, by the analyte sensor system 104 of FIGS. 1A-B. In addition, or alternatively, the process 800 can be executed, for example, by the application 106 of FIGS. 1A-B and 2. In addition, or alternatively, the process 800 can be executed generally by any of the display devices 107 of FIGS. 1A-B and 2. Although any number of systems, in whole or in part, can implement the process 800, to simplify discussion, the process 800 will be described generically in relation to the therapy management engine 112 of FIGS. 1 A-B and 2.

[0116] At block 802, the therapy management engine 112 configures a glucose-value utility model for the patient, for example, as generally discussed relative to the block 302 of FIG. 3. The block 802 can include, for example, eliciting blood glucose risk preferences (e.g., at initial configuration time) to form a glucose-value utility model, such as a glucose-value utility function. For example, the therapy management engine 112, through a graphical display (e.g., on the display device 107), can allow the patient or other user to specify a utility of one or more ranges of glucose values over an anticipated timeframe of sleep. In an example, utility can be specified as a percentage of time in range during sleep. In another example, utility can be specified as a normalized integral of a nonlinear weighting applied to blood glucose over a timeframe of sleep, where weighted values are approach zero as blood glucose approaches or drops below a lower threshold. Other examples will be apparent to one skilled in the art after a detailed review of the present disclosure.

[0117] At block 804, the therapy management engine 112 continuously updates a model of prediction uncertainty for glucose values, for example, as generally discussed relative to the block 304 of FIG. 3. For example, if actual or measured blood glucose values are consistently rated as low likelihood, the therapy management engine 112 can adjust one or more parameters of the model of prediction uncertainty to achieve more consistency, for example, in the fashion shown relative to FIG. 7. In addition, or alternatively, the therapy management engine 112 can continuously optimize training of the model of prediction uncertainty.

[0118] At block 806, the therapy management engine 112 continually allows the user to reconfigure the glucose-value utility model, for example, by providing user input about future glucose values and / or new risk perspectives, as generally discussed relative to the block 306 of FIG. 3. In some aspects, the therapy management engine 112 can allow the patient or other user to announce temporary risk preferences related to sleep. For example, the therapy management engine 112 can allow the patient or other user to specify that uninterrupted sleep tonight is prioritized, such that higher numerical values of utility are associated with higher-than-normal blood glucose vales, and closer-to-zero utilities are associated with blood glucose values approaching hypoglycemia (e.g., blood glucose values below a predetermined threshold associated with hypoglycemia).

[0119] At block 808, the therapy management engine 112 continuously evaluates posterior distributions of future glucose values on one or more time horizons, for example, as generally discussed relative to the block 308 of FIG. 3.

[0120] At block 810, the therapy management engine 112 computes, presents, and / or implements a risk-optimal treatment, for example, as generally discussed relative to the block 310 of FIG. 3. In general, the block 810 can include executing any of the functionality discussed above relative to the block 310 of FIG. 3 and / or the process 500 of FIG. 5. For example, the therapy management engine 112 can determine a bolus recommendation that maximizes an expected utility of blood glucose over an expected duration of sleep based on the glucose-value utility model. Continuing this example, in certain aspects, the therapy management engine 112 can present information related to the determined bolus, as discussed previously relative to the block 510 of FIG. 5.

[0121] At block 812, the therapy management engine 112 continuously assesses an extent to which the glucose-value utility model is consistent with treatment decisions made by the patient, as generally discussed relative to the block 312 of FIG. 3. At block 814, the therapy management engine 112 executes retrospective analysis to improve a glycemic outcome of the patient, as generally discussed relative to the block 314 of FIG. 3.

[0122] It should be appreciated that, although the process 800 is described in the context of bedtime advice, in certain aspects, a similar process can be executed at any decision point for diabetes-related treatment. For example, a process similar to the process 800 of FIG. 8 can beexecuted at or around a time of any insulin bolus calculation, at or around a time of meal intake, at or around of time of physical activity, on-demand responsive to a request from a patient or other user (e.g., a request for a recommended treatment to avoid hyperglycemia or hypoglycemia), at other times where treatment is being considered, when optimizing therapy for the patient (e.g., optimization of multiple daily injection therapy, insulin therapy using an insulin pump, automated insulin dosing, etc.), combinations of the foregoing and / or the like.

[0123] In some embodiments, the system enables real-time, interactive simulation of future estimated glucose values (EGVs). The system can include an interactive user interface and a predictive modeling engine configured to forecast future glucose values while representing the uncertainty associated with those predictions. For example, the system can receive continuous glucose monitoring (CGM) data and, optionally, additional inputs such as insulin dosing, carbohydrate intake, physical activity, stress levels, etc. These inputs can be processed by a predictive model, which may utilize statistical, machine learning, or hybrid approaches to estimate future glucose trajectories over a selected time horizon.

[0124] The predictive model can generate not only a point estimate of future glucose values but also a probabilistic distribution for each future time point. This distribution reflects the model’ s confidence in its predictions and incorporates sources of uncertainty arising from user physiology, behavioral variability, and / or other unmodeled factors. In some implementations, the system can compute, for each time increment, a range of possible glucose values and quantify the degree of uncertainty, for example, by calculating prediction intervals or credible intervals.

[0125] The predictive model is designed to be flexible and comprehensive, trained on CGM data and optionally incorporating additional inputs such as insulin dosing, carbohydrate intake, physical activity, and / or stress levels. By integrating these diverse data sources, the model can more accurately reflect the complex physiological and behavioral factors that influence glucose dynamics. This multi-factor integration enables precise and individualized forecasts of the user's glucose levels.

[0126] In some implementations, the system can display future glucose trajectories with a time-dependent uncertainty band, visually resembling a fan or cone. The width of this band at any given time point reflects the degree of uncertainty in the prediction, which is influenced by factors such as user physiology, behavior, and / or other unmodeled variability. This approach providesusers with an intuitive understanding of the reliability of forecasts, helping them to better assess risk and make decisions considering the uncertainty of the predicted glucose levels.

[0127] In some implementations, the system can include a decision-theoretic approach to insulin dosing. For example, the system can elicit user-specific blood glucose risk preferences to construct a utility function, which quantifies the desirability of different glucose outcomes. The system can continuously update probabilistic models of user physiology and behavior, evaluate posterior distributions of future blood glucose, and compute risk-optimal insulin doses by maximizing expected utility. This method allows for personalized, risk-aware dosing recommendations that adapt to the user’s evolving preferences and circumstances.

[0128] In some implementations, users can provide ongoing feedback, such as side knowledge about future blood glucose or new risk perspectives, which the system incorporates to refine its predictions and utility function parameters. The system can also monitor the consistency between the user’s stated preferences and actual decisions, notify the user of any discrepancies and update its models to better align with observed behavior. This continuous adaptation ensures that the decision-support tool remains responsive to the user’s needs and preferences over time.

[0129] In some implementations, the system can include mechanisms for retrospective analysis and adjustment of its automation or decision-support parameters. It can generate reports on glycemic outcomes and use historical data to improve future performance. This feedback loop supports ongoing optimization of diabetes management strategies, contributing to better long-term health outcomes.

[0130] FIG. 10 shows an exemplary embodiment of an Interactive Glucose Prediction Interface 1000 designed to assist users in managing their blood glucose levels. The interface can include a glucose graph 1010 displaying a trace of historical and current glucose levels as well as the predicted glucose trajectory over time. On this exemplary graph, a solid line represents collected actual glucose levels, including a current glucose level, over a time period. The dotted line represents predicted future glucose levels based on current glucose data (or glucose trend data) and optionally other input data, such as insulin dosing, carbohydrate intake, physical activity, and / or stress levels. Surrounding the predicted glucose levels is a shaded region forming a fan or cone shape, for example, which indicates an uncertainty band of the predicted glucose levels. The width of this band at each time point visually communicates the degree of uncertainty in theprediction of the glucose levels, with wider sections indicating greater uncertainty further into the future. In this example, a horizontal dashed line indicates a threshold for hypoglycemia, providing a visual reference for low glucose risk. This threshold can be set (e.g., by the user or health care provider) to indicate when predicted values or uncertainty bands approach or cross critical limits.

[0131] In this example, the interface includes a Bolus Control Panel 1020. This panel can display the recommended insulin bolus dose based on the user's current and predicted glucose levels (e.g., shown numerically), and provide means to interactively adjust the recommended insulin dose (e.g., via a slider). As the user modifies the insulin dose, the predicted glucose trajectory and the associated uncertainty band update in real time to reflect the adjusted inputs.

[0132] Additionally, in this example, the interface includes a Meal Intake Panel 1030. This panel allows the user to input meal information (e.g., carb intake), to be considered in the prediction of glucose levels. This allows users to assess the impact of meal intake (and insulin doses) on predicted glucose levels.

[0133] The Interactive Glucose Prediction Interface shown in Figure 10 is merely exemplary and can, for example, include other inputs, such as insulin dosing, physical activity, and / or stress levels, to interactively present predicted glucose levels and associated uncertainties.

[0134] FIG. 9 is a block diagram depicting a computer system 900 configured for decision-theoretic automation and decision support, for example, according to certain embodiments disclosed herein. Although depicted as a single physical device, in embodiments, the computer system 900 may be implemented using virtual device(s), and / or across a number of devices, such as in a cloud environment and / or via separate modules of portable or cloud devices. As illustrated, the computer system 900 includes a processor 905, a memory 910, a storage 915, a network interface 925, and one or more I / O interfaces 920. In the illustrated embodiment, the processor 905 retrieves and executes programming instructions stored in the memory 910, as well as stores and retrieves application data residing in the storage 915. The processor 905 is generally representative of a single CPU and / or GPU, multiple CPUs and / or GPUs, a single CPU and / or GPU having multiple processing cores, and the like.

[0135] The memory 910 is generally included to be representative of a random access memory (RAM). The storage 915 may be any combination of disk drives, flash-based storage devices, and the like, and may include fixed and / or removable storage devices, such as fixed disk drives,removable memory cards, caches, optical storage, network attached storage (NAS), or storage area networks (SAN).

[0136] In some embodiments, the I / O devices 935 (such as keyboards, monitors, etc.) can be connected via the I / O interface(s) 920. Further, via the network interface 925, the computer system 900 can be communicatively coupled with one or more other devices and components, such as the user database 110. In certain embodiments, the computer system 900 is communicatively coupled with other devices via a network, which may include the Internet, local network(s), and the like. The network may include wired connections, wireless connections, or a combination of wired and wireless connections. As illustrated, the processor 905, memory 910, storage 915, network interface(s) 925, and the I / O interface(s) 920 are communicatively coupled by one or more interconnects 930. In certain embodiments, the computer system 900 is representative of the display device 107 associated with the user. In certain embodiments, as discussed above, the display device 107 can include the user’s laptop, computer, smartphone, and the like. In another embodiment, the computer system 900 is a server executing in a cloud environment.

[0137] In the illustrated embodiment, the storage 915 includes the user profde 118, analytevalue utility model 942, and a model 944 of prediction uncertainty. The analyte-value utility model 942 can correspond, for example, to any of the analyte-value utility models discussed above relative to FIGS. 3-8. The model 944 of prediction uncertainty can correspond to any of the models of prediction uncertainty discussed above relative to FIGS. 3-8. The memory 910 includes the therapy management engine 112. The therapy management engine 112 can be executed by the computer system 900 to perform operations, for example, of the process 300 of FIG. 3, the process 400 of FIG. 4, the process 500 of FIG. 5, and / or the process 800 of FIG. 8.Example Clauses

[0138] Implementation examples are described in the following numbered clauses:

[0139] Clause 1: A system for dynamically adapting treatments to patient risk preferences, comprising: one or more memories comprising executable instructions; and one or more processors in data communication with the one or more memories and configured to execute the executable instructions to: receive analyte risk preferences of a patient; personalize an analytevalue utility model for the patient based on the analyte risk preferences, wherein the personalized analyte-value utility model describes variation in analyte-value utility across a range of analytevalues; receive, for each prospective treatment of one or more prospective treatments, one or more predicted analyte values of the patient for the prospective treatment; and determine, for each prospective treatment of the one or more prospective treatments, a prediction uncertainty associated with the one or more predicted analyte values.

[0140] Clause 2: The system of Clause 1, wherein the analyte risk preferences indicate the variation in analyte-value utility across the range of analyte values, indicate how a risk tolerance of the patient varies across a range of analyte values, or represent a temporary change in a risk tolerance of the patient.

[0141] Clause 3: The system of Clause 1, wherein the analyte risk preferences indicate the variation in analyte-value utility across the range of analyte values.

[0142] Clause 4: The system of Clause 3, wherein the personalization comprises assigning utility values to one or more subranges of the range of analyte values according to the analytevalue utility of the analyte values.

[0143] Clause 5: The system of Clause 1, wherein the analyte risk preferences indicate how a risk tolerance of the patient varies across a range of analyte values.

[0144] Clause 6: The system of Clause 1, wherein the analyte risk preferences represent a temporary change in a risk tolerance of the patient.

[0145] Clause 7: The system of Clause 1, wherein the one or more prospective treatments comprise at least one of medicament, meal intake, or activity.

[0146] Clause 8: The system of Clause 1, wherein the one or more prospective treatments comprise a plurality of prospective treatments that vary in at least one of type, amount, or timing.

[0147] Clause 9: The system of Clause 1, wherein, for at least one prospective treatment of the one or more prospective treatments, the determination of the prediction uncertainty comprises generating a structure that describes a degree to which the prediction uncertainty changes relative to one or more time horizons.

[0148] Clause 10: The system of Clause 1, wherein the one or more processors are further configured to execute the executable instructions to determine a treatment for the patient based on the personalized analyte-value utility model, the one or more predicted analyte values for each ofthe one or more prospective treatments, and the determined prediction uncertainty for each of the one or more prospective treatments.

[0149] Clause 11: The system of Clause 10, wherein the one or more processors are further configured to execute the executable instructions to determine an expected utility of each of the one or more prospective treatments using the personalized analyte-value utility model, and wherein the determination of the treatment is further based on the determined expected utility of each of the one or more prospective treatments.

[0150] Clause 12: The system of Clause 11, wherein the one or more prospective treatments comprise a plurality of prospective treatments and the determined treatment is the prospective treatment of the plurality of prospective treatments with the greatest expected utility.

[0151] Clause 13: The system of Clause 10, wherein the one or more processors are further configured to execute the executable instructions to present information related to the determined treatment, wherein the presentation comprises indicating the determined treatment to the patient in relation to an expected utility of the determined treatment, describing the expected utility of the determined treatment in relation to an analyte-value scenario, and / or, for the determined treatment, displaying a structure that describes a degree to which the prediction uncertainty changes relative to one or more time horizons.

[0152] Clause 14: The system of Clause 10, wherein the one or more processors are further configured to execute the executable instructions to present information related to the determined treatment.

[0153] Clause 15: The system of Clause 14, wherein the presentation comprises indicating the determined treatment to the patient in relation to an expected utility of the determined treatment.

[0154] Clause 16: The system of Clause 15, wherein the presentation comprises describing the expected utility of the determined treatment in relation to an analyte-value scenario.

[0155] Clause 17: The system of Clause 14, wherein the presentation comprises, for the determined treatment, displaying a structure that describes a degree to which the prediction uncertainty changes relative to one or more time horizons.

[0156] Clause 18: The system of Clause 10, wherein the determined treatment comprises medicament and the one or more processors are further configured to execute the executable instructions to instruct a medicament delivery device based on the determined treatment.

[0157] Clause 19: The system of Clause 1, wherein the one or more processors are further configured to execute the executable instructions to update a model of prediction uncertainty, the update comprising: retrospectively collecting a sample of predictions and corresponding prediction errors for the patient; classifying each of the corresponding prediction errors according to a metabolic state of the patient at a time of the corresponding prediction; and constructing one or more empirical distributions of prediction error that are conditional on one or more metabolic states of the patient.

[0158] Clause 20: The system of Clause 1, wherein the one or more processors are further configured to: receive user input relative to at least one of an influence on future analyte values or a risk tolerance of the patient; and reconfigure the analyte-value utility model based on the user input.

[0159] Clause 21: A method of dynamically adapting treatments to patient risk preferences, the method comprising: receiving analyte risk preferences of a patient; personalizing an analytevalue utility model for the patient based on the analyte risk preferences, wherein the personalized analyte-value utility model describes variation in analyte-value utility across a range of analyte values; receiving, for each prospective treatment of one or more prospective treatments, one or more predicted analyte values of the patient for the prospective treatment; and determining, for each prospective treatment of the one or more prospective treatments, a prediction uncertainty associated with the one or more predicted analyte values.

[0160] Clause 22: The method of Clause 21, wherein the analyte risk preferences indicate the variation in analyte-value utility across the range of analyte values, indicate how a risk tolerance of the patient varies across a range of analyte values, or represent a temporary change in a risk tolerance of the patient.

[0161] Clause 23: The method of Clause 21, wherein the analyte risk preferences indicate the variation in analyte-value utility across the range of analyte values.

[0162] Clause 24: The method of Clause 23, wherein the personalizing comprises assigning utility values to one or more subranges of the range of analyte values according to the analytevalue utility of the analyte values.

[0163] Clause 25: The method of Clause 21, wherein the analyte risk preferences indicate how a risk tolerance of the patient varies across a range of analyte values.

[0164] Clause 26: The method of Clause 21, wherein the analyte risk preferences represent a temporary change in a risk tolerance of the patient.

[0165] Clause 27: The method of Clause 21, wherein the one or more prospective treatments comprise at least one of medicament, meal intake, or activity.

[0166] Clause 28: The method of Clause 21, wherein the one or more prospective treatments comprise a plurality of prospective treatments that vary in at least one of type, amount, or timing.

[0167] Clause 29: The method of Clause 21, wherein, for at least one prospective treatment of the one or more prospective treatments, the determining the prediction uncertainty comprises generating a structure that describes a degree to which the prediction uncertainty changes relative to one or more time horizons.

[0168] Clause 30: The method of Clause 21, further comprising determining a treatment for the patient based on the personalized analyte-value utility model, the one or more predicted analyte values for each of the one or more prospective treatments, and the determined prediction uncertainty for each of the one or more prospective treatments.

[0169] Clause 31: The method of Clause 30, further comprising determining an expected utility of each of the one or more prospective treatments using the personalized analyte-value utility model, and wherein the determining the treatment is further based on the determined expected utility of each of the one or more prospective treatments.

[0170] Clause 32: The method of Clause 31, wherein the one or more prospective treatments comprise a plurality of prospective treatments and the determined treatment is the prospective treatment of the plurality of prospective treatments with the greatest expected utility.

[0171] Clause 33: The method of Clause 30, the method further comprising presenting information related to the determined treatment, wherein the presenting comprises indicating the determined treatment to the patient in relation to an expected utility of the determined treatment,describing the expected utility of the determined treatment in relation to an analyte-value scenario, and / or, for the determined treatment, displaying a structure that describes a degree to which the prediction uncertainty changes relative to one or more time horizons.

[0172] Clause 34: The method of Clause 30, further comprising presenting information related to the determined treatment.

[0173] Clause 35: The method of Clause 34, wherein the presenting comprises indicating the determined treatment to the patient in relation to an expected utility of the determined treatment.

[0174] Clause 36: The method of Clause 35, wherein the presenting comprises describing the expected utility of the determined treatment in relation to an analyte-value scenario.

[0175] Clause 37: The method of Clause 34, wherein the presenting comprises, for the determined treatment, displaying a structure that describes a degree to which the prediction uncertainty changes relative to one or more time horizons.

[0176] Clause 38: The method of Clause 30, wherein the determined treatment comprises medicament and the method further comprises instructing a medicament delivery device based on the determined treatment.

[0177] Clause 39: The method of Clause 21, further comprising update a model of prediction uncertainty, the updating comprising: retrospectively collecting a sample of predictions and corresponding prediction errors for the patient; classifying each of the corresponding prediction errors according to a metabolic state of the patient at a time of the corresponding prediction; and constructing one or more empirical distributions of prediction error that are conditional on one or more metabolic states of the patient.

[0178] Clause 40: The method of Clause 21, further comprising: receiving user input relative to at least one of an influence on future analyte values or a risk tolerance of the patient; and reconfiguring the analyte-value utility model based on the user input.

[0179] Clause 41: A computer-program product comprising a non-transitory computer-usable medium having computer-readable program code embodied therein, the computer-readable program code adapted to be executed to implement a method comprising: receiving analyte risk preferences of a patient; personalizing an analyte-value utility model for the patient based on the analyte risk preferences, wherein the personalized analyte-value utility model describes variationin analyte-value utility across a range of analyte values; receiving, for each prospective treatment of one or more prospective treatments, one or more predicted analyte values of the patient for the prospective treatment; and determining, for each prospective treatment of the one or more prospective treatments, a prediction uncertainty associated with the one or more predicted analyte values.

[0180] Clause 42: An apparatus, comprising: at least one memory comprising executable instructions; and at least one processor configured to execute the executable instructions and cause the apparatus to perform a method in accordance with any combination of Clauses 21-40.

[0181] Clause 43: An apparatus, comprising means for performing a method in accordance with any combination of Clauses 21-40.

[0182] Clause 44: A non-transitory computer-readable medium comprising executable instructions that, when executed by at least one processor of an apparatus, cause the apparatus to perform a method in accordance with any combination of Clauses 21-40.

[0183] Clause 45: A computer program product embodied on a computer-readable storage medium comprising code for performing a method in accordance with any combination of Clauses 21-40.Additional Considerations

[0184] Each of these non-limiting examples can stand on its own or can be combined in various permutations or combinations with one or more of the other examples.

[0185] The above detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show, by way of illustration, specific embodiments in which the invention can be practiced. These embodiments are also referred to herein as “examples.” Such examples can include elements in addition to those shown or described. However, the present inventors also contemplate examples in which only those elements shown or described are provided. Moreover, the present inventors also contemplate examples using any combination or permutation of those elements shown or described (or one or more aspects thereof), either 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.

[0186] In the event of inconsistent usages between this document and any documents so incorporated by reference, the usage in this document controls.

[0187] In this document, the terms “a” or “an” are used, as is common in patent documents, to include one or more than one, independent of any other instances or usages of “at least one” or “one or more.” In this document, the term “or” is used to refer to a nonexclusive 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 following claims, the terms “including” and “comprising” are open-ended, that is, a system, device, article, composition, formulation, or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall within the scope of that claim. Moreover, in the following claims, the terms “first,” “second,” and “third,” etc. are used merely as labels, and are not intended to impose numerical requirements on their objects.

[0188] Method examples described herein can be machine or computer-implemented at least in part. Some examples can include a computer-readable medium or machine-readable medium encoded with instructions operable to configure an electronic device to perform methods as described in the above examples. An implementation of such methods can include code, such as microcode, assembly language code, a higher-level language code, or the like. Such code can include computer readable instructions for performing various methods. The code may form portions of computer program products. Further, in an example, the code can be tangibly stored on one or more volatile, non-transitory, or non-volatile tangible computer-readable media, such as during execution or at other times. Examples of these tangible computer-readable media can include, but are not limited to, hard disks, removable magnetic disks, removable optical disks (e.g., compact disks and digital video disks), magnetic cassettes, memory cards or sticks, random access memories (RAMs), read only memories (ROMs), and the like.

[0189] The above description is intended to be illustrative, and not restrictive. For example, the above-described examples (or one or more aspects thereof) may be used in combination with each other. Other embodiments can be used, such as by one of ordinary skill in the art upon reviewing the above description. The Abstract is provided to comply with 37 C.F.R. § 1.72(b), to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with theunderstanding that it will not be used to interpret or limit the scope or meaning of the claims. Also, in the above Detailed Description, various features may be grouped together to streamline the disclosure. This should not be interpreted as intending that an unclaimed disclosed feature is essential to any claim. Rather, inventive subject matter may lie in less than all features of a particular disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description as examples or embodiments, with each claim standing on its own as a separate embodiment, and it is contemplated that such embodiments can be combined with each other in various combinations or permutations. The scope of the invention should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

1. CLAIMS1. A system for dynamically adapting treatments to patient risk preferences, comprising:one or more memories comprising executable instructions; andone or more processors in data communication with the one or more memories and configured to execute the executable instructions to:receive analyte risk preferences of a patient;personalize an analyte-value utility model for the patient based on the analyte risk preferences, wherein the personalized analyte-value utility model describes variation in analytevalue utility across a range of analyte values;receive, for each prospective treatment of one or more prospective treatments, one or more predicted analyte values of the patient for the prospective treatment; and determine, for each prospective treatment of the one or more prospective treatments, a prediction uncertainty associated with the one or more predicted analyte values.

2. The system of claim 1, wherein the analyte risk preferences indicate the variation in analyte-value utility across the range of analyte values, indicate how a risk tolerance of the patient varies across a range of analyte values, or represent a temporary change in a risk tolerance of the patient.

3. The system of claim 2, wherein the personalization comprises assigning utility values to one or more subranges of the range of analyte values according to the analyte-value utility of the analyte values.

4. The system of claim 1, wherein the one or more prospective treatments comprise at least one of medicament, meal intake, or activity.

5. The system of claim 1, wherein the one or more prospective treatments comprise a plurality of prospective treatments that vary in at least one of type, amount, or timing.

6. The system of claim 1 , wherein, for at least one prospective treatment of the one or more prospective treatments, the determination of the prediction uncertainty comprises generating a structure that describes a degree to which the prediction uncertainty changes relative to one or more time horizons.

7. The system of claim 1, wherein the one or more processors are further configured to execute the executable instructions to determine a treatment for the patient based on the personalized analyte-value utility model, the one or more predicted analyte values for each of the one or more prospective treatments, and the determined prediction uncertainty for each of the one or more prospective treatments.

8. The system of claim 7, wherein the one or more processors are further configured to execute the executable instructions to determine an expected utility of each of the one or more prospective treatments using the personalized analyte-value utility model, and wherein the determination of the treatment is further based on the determined expected utility of each of the one or more prospective treatments.

9. The system of claim 8, wherein the one or more prospective treatments comprise a plurality of prospective treatments and the determined treatment is the prospective treatment of the plurality of prospective treatments with the greatest expected utility.

10. The system of claim 7, wherein the one or more processors are further configured to execute the executable instructions to present information related to the determined treatment, wherein the presentation comprises indicating the determined treatment to the patient in relation to an expected utility of the determined treatment, describing the expected utility of the determined treatment in relation to an analyte-value scenario, and / or, for the determined treatment, displaying a structure that describes a degree to which the prediction uncertainty changes relative to one or more time horizons.

11. The system of claim 7, wherein the determined treatment comprises medicament and the one or more processors are further configured to execute the executable instructions to instruct a medicament delivery device based on the determined treatment.

12. The system of claim 1, wherein the one or more processors are further configured to execute the executable instructions to update a model of prediction uncertainty, the update comprising:retrospectively collecting a sample of predictions and corresponding prediction errors for the patient;classifying each of the corresponding prediction errors according to a metabolic state of the patient at a time of the corresponding prediction; andconstructing one or more empirical distributions of prediction error that are conditional on one or more metabolic states of the patient.

13. The system of claim 1, wherein the one or more processors are further configured to:receive user input relative to at least one of an influence on future analyte values or a risk tolerance of the patient; andreconfigure the analyte-value utility model based on the user input.

14. A method of dynamically adapting treatments to patient risk preferences, the method comprising:receiving analyte risk preferences of a patient;personalizing an analyte-value utility model for the patient based on the analyte risk preferences, wherein the personalized analyte-value utility model describes variation in analytevalue utility across a range of analyte values;receiving, for each prospective treatment of one or more prospective treatments, one or more predicted analyte values of the patient for the prospective treatment; anddetermining, for each prospective treatment of the one or more prospective treatments, a prediction uncertainty associated with the one or more predicted analyte values.

15. A computer-program product comprising a non-transitory computer-usable medium having computer-readable program code embodied therein, the computer-readable program code adapted to be executed to implement a method comprising:receiving analyte risk preferences of a patient;personalizing an analyte-value utility model for the patient based on the analyte risk preferences, wherein the personalized analyte-value utility model describes variation in analytevalue utility across a range of analyte values;receiving, for each prospective treatment of one or more prospective treatments, one or more predicted analyte values of the patient for the prospective treatment; anddetermining, for each prospective treatment of the one or more prospective treatments, a prediction uncertainty associated with the one or more predicted analyte values.

Images