Diabetic ketoacidosis risk detection and mitigation

Abstract

In an embodiment, a system for mitigating diabetic ketoacidosis (DKA) risk for a patient in real-time includes a continuous glucose monitoring (CGM) system configured to generate one or more glucose measurements associated with a cunent glucose level of a patient over a period, one or more memories including executable instructions, and one or more processors in data communication with the one or more memories. The one or more processors are configured to execute the executable instructions to receive glucose measurements for the patient from the CGM system, receive insulin data for the patient, evaluate criteria associated with DKA using first information related to the glucose measurements and second information related to the insulin data, detect a risk of DKA for the patient responsive to a combination of the first information and the second information satisfying the criteria associated with DKA, and alert the patient based on the detected risk.

Description

Dexcom Ref. No.: 0960-PCT01DIABETIC KETOACIDOSIS RISK DETECTION AND MITIGATIONCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to and benefit of U.S. Provisional Patent Application No. 63 / 739,448 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 relating to the production or use of insulin by the body. Insulin is a hormone that allows the body to use glucose for energy, or store glucose as fat.

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

[0004] When the body does not produce enough insulin, or when the body is unable to effectively use insulin that is present, blood sugar levels can elevate beyond the normal range (or cuglyccmia). The state of having a higher than normal blood sugar level is called “hyperglycemia.” Chronic hyperglycemia can lead to a number of health problems, such as cardiovascular disease, cataract and other eye problems, nerve damage (neuropathy), liver disease, kidney damage, and amputation. Hyperglycemia can also lead to acute problems, such as diabetic ketoacidosis (DKA) — a state in which the blood becomes excessively acidic due to elevation in ketones bodies (e.g., acetone, acetoacetate, P-hydroxybutyrate), which are produced as a consequence of the metabolic process of gluconeogenesis. The state of having lower than normal blood glucose levels is called “hypoglycemia.” Severe hypoglycemia can lead to acute crises that can result in seizures or death.

[0005] Diabetes conditions arc sometimes referred to as “Type 1” and “Type 2.” A Type 1 diabetes patient is typically able to use insulin when it is present, but the body is unable to produce sufficient amounts of insulin on its own, because of reduced function of the insulin-producing betaDexcom Ref. No.: 0960-PCT01cells of the pancreas. A Type 2 diabetes patient may produce sufficient quantities of insulin, but the patient has become “insulin resistant” due to a reduced sensitivity to insulin at the cellular level. The result is that even though insulin is present in the body, the insulin is not sufficient or is ineffectively used by the patient's cells to effectively uptake glucose, thereby resulting in chronically elevated levels of glucose in the blood and / or interstitial fluid. A diabetes patient can receive insulin to manage blood glucose levels. Insulin can be received, for example, through a manual injection with a needle. Wearable insulin pumps are also available. Diet and exercise also affect blood glucose levels.SUMMARY

[0006] In some embodiments, one general aspect includes a system for mitigating diabetic ketoacidosis (DKA) risk for a patient in real-time. The system includes a continuous glucose monitoring (CGM) system configured to generate one or more glucose measurements associated with a current glucose level of a patient over a period. The system also includes one or more memories including 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 glucose measurements for the patient from the CGM system, receive insulin data for the patient, evaluate criteria associated with DKA using first information related to the glucose measurements and second information related to the insulin data. The one or more processors are further configured to detect a risk of DKA for the patient responsive to a combination of the first information and the second information satisfying the criteria associated with DKA. The one or more processors are further configured to alert the patient based on the detected risk.

[0007] In some embodiments, another general aspect includes a method of mitigating diabetic ketoacidosis (DKA) risk for a patient in real-time. The method is executed by one or more processors and includes receiving glucose measurements for the patient from a continuous glucose monitoring (CGM) system. The method also includes receiving insulin data for the patient from an insulin delivery device. The method also includes evaluating criteria associated with DKA using first information related to the glucose measurements and second information related to the insulin data. The method also includes detecting a risk of DKA for the patient responsive to a combinationDexcom Ref. No.: 0960-PCT01of the first information and the second information satisfying the criteria associated with DKA. The method also includes alerting the patient based on the detected risk.

[0008] In some embodiments, another general aspect includes a system for mitigating diabetic ketoacidosis (DKA) risk for a patient in real-time. The system includes a continuous glucose monitoring (CGM) system configured to generate one or more glucose measurements associated with a current glucose level of a patient over a period. The system also includes one or more memories including 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 glucose measurements for the patient from the CGM system and evaluate criteria associated with DKA using information related to the glucose measurements. The one or more processors are further configured to detect a risk of DKA for the patient responsive to the information related to the glucose measurements satisfying the criteria associated with DKA. The one or more processors are further configured to alert the patient based on the detected risk.

[0009] In some embodiments, another general aspect includes a method of mitigating diabetic ketoacidosis (DKA) risk for a patient. The method includes receiving glucose measurements for the patient from a continuous glucose monitoring (CGM) system. The method also includes evaluating criteria associated with DKA using information related to the glucose measurements. The method also includes detecting a risk of DKA for the patient responsive to the information related to the glucose measurements satisfying the criteria associated with DKA. The method also includes alerting the patient based on the detected risk.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] So that the manner in which the above-recited features of the present disclosure can be understood in detail, a more particular description, briefly summarized above, may be had by reference to aspects, some of which are illustrated in the drawings. It is to be noted, however, that the appended drawings illustrate only certain typical aspects of this disclosure and are therefore not to be considered limiting of its scope, for the description may admit to other equally effective aspects.

[0011] FIG. 1 illustrates aspects of an example health management system that may be used in connection with implementing certain embodiments of the present disclosure.Dexcom Ref. No.: 0960-PCT01

[0012] FIG. 2 is a diagram conceptually illustrating an example of a continuous analyte monitoring system including an example of a continuous analyte scnsor(s) with sensor electronics, according to certain embodiments disclosed herein.

[0013] FIG. 3 illustrates example inputs and example metrics that are calculated based on the inputs for use by the health management system of FIG. 1, according to certain embodiments disclosed herein.

[0014] FIG. 4 is a flow diagram illustrating an example method for providing therapy management using analyte data, according to certain embodiments disclosed herein.

[0015] FIG. 5 is a flow diagram illustrating an example method for detecting and mitigating diabetic ketoacidosis (DKA) risk in real-time, according to certain embodiments disclosed herein.

[0016] FIG. 6 is a flow diagram illustrating an example method for detecting and mitigating DKA risk in real-time based on continuous glucose monitoring (CGM) data, according to certain embodiments disclosed herein.

[0017] FIG. 7 is a flow diagram illustrating an example method for detecting and mitigating DKA risk based on CGM data in combination with other data about a patient, according to certain embodiments disclosed herein.

[0018] FIG. 8 illustrates a receiver operating characteristic (ROC) curve for an example in which logistic regression is based only on CGM data, according to certain embodiments disclosed herein.

[0019] FIG. 9 illustrates an ROC curve for an example in which logistic regression is based on CGM data in combination with weight and age data, according to certain embodiments disclosed herein.

[0020] FIG. 10 illustrates an ROC curve for an example in which DKA risk detection utilizes CGM data in combination with total daily insulin, according to certain embodiments disclosed herein.

[0021] FIGS. 11A-C illustrate examples of evaluating DKA risk, according to certain embodiments disclosed herein.Dexcom Ref. No.: 0960-PCT01

[0022] FIG. 12 is a block diagram depicting a computing device configured for DKA detection and mitigation, according to certain embodiments disclosed herein.

[0023] To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. It is contemplated that elements disclosed in one aspect may be beneficially utilized on other aspects without specific recitation.DETAILED DESCRIPTION

[0024] Patients with diabetes who are on intensive insulin therapy are generally at an increased risk for diabetic ketoacidosis (DKA), a life-threatening condition requiring clinical intervention. Possible root causes may include, for example, insufficient insulin dosing (e.g., due to unsteadiness in insulin therapy, technical faults in insulin delivery, etc.), compromised insulin effectiveness, illness, hormonal changes, diet restrictions, and / or dehydration. Although clear criteria exist for diagnosing DKA, by the time awareness, detection and diagnosis of DKA is complete for a given patient, the patient is already in a highly acute medical state. In general, what is lacking are effective tools for detecting DKA risk early and for cueing the patient to address root causes of DKA before the situation becomes acute.

[0025] In response to the above problems, a therapy management engine may be provided that can perform personalized DKA risk detection and mitigation. In certain aspects, the therapy management engine can configure DKA risk detection and mitigation according to a patient’s selection of data input types. The data input types can include, for example, configuration inputs provided by the patient, such as physiological characteristics, biometric data, demographic data, anthropomorphic data, menstrual cycle information, DKA history, illness history, and / or the like. In addition, or alternatively, the data input types can include runtime inputs provide by one or more sensors or medical devices, such as glucose measurements, insulin data (e.g., insulin on board), body temperature, and / or the like.

[0026] In certain aspects, the therapy management engine can execute personalized DKA risk detection by evaluating DKA risk criteria, for example, based on the data input types selected by the patient. In some aspects, the DKA risk criteria can relate to glucose measurements generated by a continuous glucose monitoring (CGM) system and / or data derived therefrom (e.g., rate ofDexcom Ref. No.: 0960-PCT01change), sometimes referred to herein as CGM data. In addition, or alternatively, the DKA risk criteria can relate to a combination of CGM data and other available data about a patient, such as one or more additional runtime inputs and / or one or more configuration inputs as discussed above. In an example, the DKA risk criteria can relate to a combination of CGM data and insulin data, for example, from an insulin pump, smart pen, and / or user data entry. In another example, the DKA risk criteria can relate to a combination of CGM data and demographic data and / or anthropomorphic data.

[0027] In certain aspects, the therapy management engine can determine a root cause of a detected DKA risk, for example, by evaluating other runtime data and / or other available data about the patient. For example, in some aspects, insulin data can be used to determine a root cause of a DKA risk detected based on glucose measurements. In an example, if glucose levels are high for a given time period during which no insulin was delivered, it may be determined that the root cause is a lack of insulin administration. In another example, if glucose levels are high for a given period of time during which insulin was delivered, the amount of insulin delivered can be analyzed to evaluate potential root causes such as, for example, the correctness of the dose, the effectiveness of the insulin, and / or pump obstruction.

[0028] In certain aspects, the therapy management engine can generate a DKA-related recommendation based on a determined root cause, such as therapy and / or educational recommendation. In an example, for an insulin-related root cause, the therapy management engine can recommend that the patient dose insulin, use a fresh or different insulin, and / or or check insulin equipment. In another example, for an illness-related root cause, the therapy management engine can recommend that the patient seek medical attention. In another example, for a dehydration root cause, the therapy management engine can recommend that the patient drink water.

[0029] As used herein, the term “continuous” analyte monitoring refers to monitoring one or more analytes in a fully continuous, semi-continuous, periodic manner, which results in a data stream of analyte values over time. A data stream of analyte values over time is what allows for meaningful data and insight to be derived using the algorithms described herein for detecting and mitigating DKA risk. 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 orDexcom Ref. No.: 0960-PCT01insight to be derived. As such, without the continuous analyte monitoring system of the embodiments herein, it is simply impossible to continuously detect and mitigate DKA risk over time, a, as described herein.

[0030] 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 detecting and mitigating DKA risk as described herein. 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.

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

[0032] 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 detect and mitigate DKA risk, in real-time, which is technically impossible 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 detect and mitigate DKA risk. In other words, deriving meaningful data and insight from a stream of real-time data that is continuously generated, processed, calibrated, and analyzed, usingDexcom Ref. No.: 0960-PCT01the algorithms and systems described herein, is not a task that can be mentally performed. For example, executing the algorithms described in relation to FIGS. 4-7 in real-time and on a continuous basis, which would involve using a stream of real-time data that is continuously generated by a host’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 hosts in the host population) is not a task that can be mentally performed, especially in real-time at times.

[0033] 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 different. 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.

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

[0035] The calibration sensitivity, calibration baseline, and other information related to the sensitivity profile 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.Dexcom Ref. No.: 0960-PCT01

[0036] 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 (Mf). 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) I M(ti) Eq. 2

[0037] FIG. 1 illustrates an example health management system 100 for providing treatment recommendations, in relation to users 102 (individually referred to herein as a user and collectively referred to herein as users), using a continuous analyte monitoring system 104, including one or more analyte sensors. A user 102, in certain embodiments, may be the patient or, in some cases, the patient’s caregiver. In certain embodiments, health management system 100 includes continuous analyte monitoring system 104, a display device 107 that executes application 106, a therapy management engine 114, a user database 110, a historical records database 112, a training server system 140, and a therapy management engine 114, each of which is described in more detail below.

[0038] The term “analyte” as used herein is a broad term used in its ordinary sense, including, without limitation, to refer to a substance or chemical constituent in a biological fluid (for example, blood, interstitial fluid, cerebral spinal fluid, lymph fluid, saliva, mucus, or urine) that can be analyzed. Analytes can include naturally occurring substances, artificial substances,Dexcom Ref. No.: 0960-PCT01pharmacologic agents, metabolites, ions, blood gasses, hormones, neurotransmitters, vitamins, minerals, peptides, proteins, enzymes, pathogens, toxins, substances of abuse, and / or reaction products. Analytes for measurement by the devices and methods may include, but may not be limited to, ketone, glucose, potassium, acarboxyprothrombin; acylcamitine; adenine phosphoribosyl transferase; adenosine deaminase; albumin; alpha-fetoprotein; amino acid profiles (arginine (Krebs cycle), histidine / urocanic acid, homocysteine, phenylalanine / tyrosine, tryptophan); androstenedione; antipyrine; arabinitol enantiomers; arginase; benzoylecgonine (cocaine); biotinidase; biopterin; c-reactive protein; carnitine; carnosinase; CD4; ceruloplasmin; chenodeoxycholic acid; chloroquine; cholesterol; cholinesterase; conjugated 1-0 hydroxy-cholic acid; cortisol; creatine kinase; creatine kinase MM isoenzyme; cyclosporin A; cystatin C; d-penicillamine; de-ethylchloroquine; dehydroepiandrosterone sulfate; DNA (acetylator polymorphism, alcohol dehydrogenase, alpha 1 -antitrypsin, glucose-6-phosphate dehydrogenase, hemoglobin A, hemoglobin S, hemoglobin C, hemoglobin D, hemoglobin E, hemoglobin F, D-Punjab, hepatitis B virus, HCMV, HIV-1, HTLV-1, MCAD, RNA, PKU, Plasmodium vivax, 21-deoxycortisol); desbutylhalofantrine; dihydropteridine reductase; diptheria / tetanus antitoxin; erythrocyte arginase; erythrocyte protoporphyrin; esterase D; fatty acids / acylglycines; free p-human chorionic gonadotropin; free erythrocyte porphyrin; free thyroxine (FT4); free triiodothyronine (FT3); fumarylacetoacetase; galactose / gal-1 -phosphate; galactose- 1 -phosphate uridyltransferase; gentamicin; gluco se-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, 3); lysozyme; mefloquine; netilmicin; phenobarbitone; phenytoin; phytanic / pristanic acid; progesterone; prolactin; prolidase; purine nucleoside phosphorylase; quinine; reverse triiodothyronine (rT3); selenium; serum pancreatic lipase; sisomicin; somatomedin C; specific antibodies recognizing any one or more of the following that may include (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 vims, herpes virus, HIV-1, IgE (atopic disease), influenza virus, Leishmania donovani, leptospira, measles / mumps / rubella, Mycobacterium leprae, Mycoplasma pneumoniae, Myoglobin, Onchocerca volvulus, parainfluenza vims, Plasmodium falciparum,Dexcom Ref. No.: 0960-PCT01poliovirus, Pseudomonas aeruginosa, respiratory syncytial vims, rickettsia (scrub typhus), Schistosoma mansoni, Toxoplasma gondii, Trcpcnoma pallidium, Trypanosoma cruzi / rangcli, vesicular stomatis vims, Wuchereria bancrofti, yellow fever virus); specific antigens (hepatitis B vims, HIV-1); succinylacetone; sulfadoxine; theophylline; thyrotropin (TSH); thyroxine (T4); thyroxine-binding globulin; trace elements; transferrin; UDP-galactose-4-epimerase; urea; uroporphyrinogen I synthase; vitamin A; 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 implementations. Ions are a charged atoms or compounds that may include the following (sodium, potassium, calcium, chloride, nitrogen, or bicarbonate, for example). The analyte can be naturally present in the biological fluid, for example, a metabolic product, a hormone, an antigen, an antibody, an ion and the like. Alternatively, the analyte can be introduced into the body or exogenous, for example, a contrast agent for imaging, a radioisotope, a chemical agent, a fluorocarbon-based synthetic blood, a challenge agent analyte (e.g., introduced for the purpose of measuring the increase and or decrease in rate of change in concentration of the challenge agent analyte or other analytes in response to the introduced challenge agent analyte), or a drug or pharmaceutical composition, including but not limited to exogenous insulin; glucagon, 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 (barbiturates, 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, for example, ascorbic acid, uric acid, dopamine, noradrenaline, 3-methoxytyramine (3MT), 3,4-Dihydroxyphenylacetic acid (DOPAC), Homovanillic acid (HVA), 5-Hydroxy tryptamine (5HT), and 5-Hydroxyindoleacetic acid (FHIAA), and intermediaries in the Citric Acid Cycle.Dexcom Ref. No.: 0960-PCT01

[0039] While the analytes that are measured and analyzed hy the devices and methods described herein include glucose, other analytes listed, but not limited to, above may also be considered and measured by, for example, continuous analyte monitoring system 104.

[0040] In certain embodiments, continuous analyte monitoring system 104 is configured to continuously measure one or more analytes and transmit the analyte measurements to an electric medical records (EMR) system (not shown in FIG. 1). An EMR system is a software platform which allows for the electronic entry, storage, and maintenance of digital medical data. An EMR system is generally used throughout hospitals and / or other caregiver facilities to document clinical information on patients over long periods. EMR systems organize and present data in ways that assist clinicians with, for example, interpreting health conditions and providing ongoing care, scheduling, billing, and follow up. Data contained in an EMR system may also be used to create reports for clinical care and / or disease management for a patient. In certain embodiments, the EMR may be in communication with therapy management engine 114 (e.g., via a network) for performing the techniques described herein. In other embodiments, an EMR may be mined for population-level health statistics, health economics, and the generation of clinical evidence or assessment of healthcare outcomes. In particular, as described herein, therapy management engine 114 may obtain data associated with a user, use the obtained data as input into one or more trained model(s), and output a prediction. In some cases, the EMR may provide the data to therapy management engine 114 to be used as input into one or more models, e.g., ML models. Further, in some cases, therapy management engine 114, after making a prediction, may provide the output prediction to the EMR.

[0041] In certain embodiments, continuous analyte monitoring system 104 is configured to continuously measure one or more analytes and transmit the analyte measurements to display device 107 for use by application 106. In some embodiments, the continuous analyte monitoring system 104 may primarily function as a monitoring device by pairing with the display device 107 and transmitting analyte measurements to the display device 107 in a continuous or semi-continuous manner. In other embodiments, the continuous analyte monitoring system 104 may primarily function as a diagnostic device that is configured to store and log the analyte measurements. In such embodiments, the data log stored by the continuous analyte monitoring system 104 may be transmitted to a remote service (e.g., a cloud server) without the involvementDexcom Ref. No.: 0960-PCT01of the display device 107. In such embodiments, the continuous analyte monitoring system 104 may be equipped with a mobile internet of things (loT) interface (e.g., LTE, Cat-Mi, NB-IoT, etc.), a cellular radio (e.g., 3G, 4G, LTE, 5G, 6G, etc.), or other means to directly communicate the analyte measurements in the data log to the remote server.

[0042] In some embodiments, continuous analyte monitoring system 104 transmits the analyte measurements to display device 107 through a wireless connection (e.g., Bluetooth connection). In certain embodiments, display device 107 is a smart phone. However, in certain other embodiments, display device 107 may instead be any other type of computing device, such as a laptop computer, a smart watch, a tablet, or any other computing device capable of executing application 106. In some embodiments, continuous analyte monitoring system 104 and / or analyte sensor application 106 transmit the analyte measurements to one or more other individuals having an interest in the health of the patient (e.g., a family member or physician for real-time treatment and care of the patient). Continuous analyte monitoring system 104 may be described in more detail with respect to FIG. 2.

[0043] Application 106 is a mobile health application that is configured to receive and analyze analyte measurements from continuous analyte monitoring system 104. In particular, application 106 stores information about a user, including the user’s analyte measurements, in a user profile 118 associated with the user for processing and analysis, as well as for use by therapy management engine 114 to provide therapy management recommendations or guidance to the user.

[0044] Therapy management engine 114 refers to a set of software instructions with one or more software modules, including data analysis module (DAM) 116. In certain embodiments, therapy management engine 114 executes entirely on one or more computing devices in a private or a public cloud. In such embodiments, application 106 communicates with therapy management engine 114 over a network (e.g., Internet). In some other embodiments, therapy management engine 114 executes partially on one or more local devices, such as display device 107, and partially on one or more computing devices in a private or a public cloud. In some other embodiments, therapy management engine 114 executes entirely on one or more local devices, such as display device 107. As discussed in more detail herein, therapy management engine 114 may provide therapy management recommendations to the user via application 106. TherapyDexcom Ref. No.: 0960-PCT01management engine 114 provides therapy management recommendations based on information included in user profile 118.

[0045] User profile 118 may include information collected about the user from application 106. For example, application 106 provides a set of inputs 128, including the analyte measurements received from continuous analyte monitoring system 104, that are stored in user profile 118. In certain embodiments, inputs 128 provided by application 106 include other data in addition to analyte measurements received from continuous analyte monitoring system 104. For example, application 106 may obtain additional inputs 128 through manual user input, one or more other non-analyte sensors or devices, other applications executing on display device 107, etc. Nonanalyte sensors and devices include one or more of, but are not limited to, an insulin pump, a smart pen for administering insulin, an electrocardiogram (ECG) sensor or heart rate monitor, a blood pressure sensor, a respiratory sensor, a thermometer, an oxygenated hemoglobin sensor (spCE), an activity tracker, a peritoneal dialysis machine, a hemodialysis machine, sensors or devices provided by display device 107 (e.g., accelerometer, inclinometer, gyroscope, camera, global positioning system (GPS), heart rate monitor, etc.) or other user accessories (e.g., a smart watch), or any other sensors or devices that provide relevant information about the user. Inputs 128 of user profile 118 provided by application 106 are described in further detail below with respect to FIG.3.

[0046] DAM 116 of therapy management engine 114 is configured to process the set of inputs 128 to determine one or more metrics 130. Metrics 130, discussed in more detail below with respect to FIG. 3, may, at least in some cases, be generally indicative of the health or state of a user, such as one or more of the user’s physiological state, trends associated with the health or state of a user, etc. In certain embodiments, metrics 130 may then be used by therapy management engine 114 as input for providing guidance to a user. As shown, metrics 130 are also stored in user profile 118.

[0047] User profile 118 also includes demographic information 120, disease info 122, and / or medication information 124 (e.g., type of medication, brand of medication, dosage, frequency of administration). In certain embodiments, such information may be provided through user input or obtained from certain data stores (e.g., electronic medical records (EMRs), etc.). In certain embodiments, demographic info 120 may include one or more of the user’s age, body mass indexDexcom Ref. No.: 0960-PCT01(BMT), ethnicity, gender, etc. Tn certain embodiments, disease info 122 may include information about a condition of a user, such as whether the user has been previously diagnosed with or experienced diabetes, a stage (if known) on a progression from pre-diabetic to a complete lack of insulin production, DKA, diagnosis of other co-morbidities, etc., or had a history of DKA, hyperglycemia, hypoglycemia, co-morbidities, etc. In certain embodiments, information about a user’s condition may also include the length of time since diagnosis, the level of control, level of compliance with condition management therapy, 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 addition, or alternatively, the disease info 122 may include lab information (e.g., lab work or lab results from EMRs, etc.)

[0048] In certain embodiments, medication information 124 may include information about the amount, frequency, and type of a medication taken by a user. In certain embodiments, the amount, frequency, and type of a medication taken by a user is time-stamped and correlated with the user’s analyte levels, thereby indicating the impact the amount, frequency, and type of the medication had on the user’s analyte levels. In certain embodiments, medication information 124 may include information about the prescribed dosage / frequency and the consumption of one or more inhibitors (e.g., sodium glucose cotransporter 2 (SGLT2)). Further, medication information 124 may include SGLT2 inhibitor action curves, and / or pharmacokinetic and / or pharmacodynamic properties to determine medication effectiveness, etc. Inhibitors may be prescribed to a patient for the purpose of treating diabetes. The user 102 may be prescribed inhibitors to help control blood glucose levels by blocking absorption of glucose by the body.

[0049] As described in more detail below, health management system 100 may be configured to use medication info 124 to determine an inhibitor effectiveness or an optimal inhibitor dosage and frequency to be prescribed to different users. In particular, health management system 100 may be configured to identify one or more optimal prescriptions based on the health of the patient when one or more medications are prescribed, as well as the condition(s) of the patient to be treated.

[0050] In certain embodiments, the medication information 124 may include information about consumption of other drugs for the control of blood glucose. For example, the medication information 124 may include metformin, thiazolidinediones, sulfonylureas, GFP-1 receptorDexcom Ref. No.: 0960-PCT01agonists, glucagon, and / or insulin action curves, pharmacokinetic and / or pharmacodynamic properties, dosage, and frequency. The medication information 124 may include information manually provided by the user and / or information provided by an automated insulin delivery (AID) device.

[0051] In certain embodiments, user profile 118 is dynamic because at least part of the information that is stored in user profile 118 may be revised over time and / or new information may be added to user profile 118 by therapy management engine 114 and / or application 106. Accordingly, information in user profile 118 stored in user database 110 provides an up-to-date repository of information related to a user.

[0052] User database 110, in some embodiments, refers to a storage server that operates in a public or private cloud. User database 110 may be implemented as any type of datastore, such as relational databases, non-relational databases, key-value datastores, 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.

[0053] The user database 110 may include user profiles 118 associated with a plurality of users who similarly interact with application 106 executing on the display devices 107 of the other users. User profiles stored in user database 110 may be accessible to not only application 10 but therapy management engine 114 as well. User profiles in the user database 110 may be accessible to the application 106 and the therapy management engine 114 over one or more networks (not shown). As described above, the therapy management engine 114, and more specifically the DAM 116 of the therapy management engine 114, can fetch inputs 128 from the user database 110 and compute a plurality of metrics 130 which can then be stored as application data 126 in the user profile 118, and / or used in population data and statistics as may be required or desired to be used by the application.

[0054] In certain embodiments, the user profiles 118 stored in user database 110 may also be stored in a historical records database 112. The user profiles 118 stored in the historical records database 112 may provide a repository of up-to-date information and historical information for each user of the application 106. Thus, the historical records database 112 essentially provides allDexcom Ref. No.: 0960-PCT01data related to each user of the application 106, where data is stored according to an associated timestamp. The timestamp associated with information stored in the historical records database 112 may identify, for example, when information related to a user has been obtained and / or updated.

[0055] Further, the historical records database 112 may maintain time series data collected for users over a period of time, including for users who use the continuous analyte monitoring system 104 and the application 106. For example, analyte data for a user who has used the continuous analyte monitoring system 104 and the application 106 for a period of five years may have time series analyte data, associated with the user, maintained over the five-year period.

[0056] Further, in certain embodiments, the historical records database 112 may also include data for one or more patients who are not users of the continuous analyte monitoring system 104 and / or the application 106. For example, the historical records database 112 may include information (e.g., user profile(s)) related to one or more patients analyzed by, for example, a healthcare physician, or the like, and not previously treated for blood glucose control, as well as information (e.g., user profile(s)) related to one or more patients who were analyzed by, for example, a healthcare physician, or the like, and were previously treated for blood glucose control. Data stored in the historical records database 112 may be referred to herein as population data, which could include hundreds or thousands of data points for each one of thousands or millions of hosts in the host population. In other words, data stored in historical records database 112 and used in certain embodiments described herein could include gigabytes, terabytes, petabytes, exabytes, etc. of data.

[0057] Data related to each patient stored in the historical records database 112 may provide time series data collected over the disease lifetime of the patient. For example, the data may include information about the patient prior to being diagnosed and information associated with the patient during the lifetime of the treatment, including information related to level of treatment required, as well as information related to other diseases or conditions, such as DKA, adverse events (e.g., hypoglycemia, hypoglycemia, dysglycemia), diabetes, heart conditions and diseases, or similar diseases or other relevant co-morbidities. Such information may indicate symptoms of the patient, physiological states of the patient, ketone levels of the patient (e.g., from ketone tests), glucose levels of the patient, states / conditions of one or more organs of the patient, habits of the patientDexcom Ref. No.: 0960-PCT01(e.g., activity levels, food consumption, etc.), medication prescribed, etc., throughout the lifetime of the treatment.

[0058] Although depicted as separate databases for conceptual clarity, in some embodiments, the user database 110 and the historical records database 112 may operate as a single database. In other words, the historical and current data related to users of the continuous analyte monitoring system 104 and the application 106, as well as historical data related to patients that were not previously users of the continuous analyte monitoring system 104 and the application 106, may be stored in a single database. The single database may be a storage server that operates in a public or private cloud or in another arrangement.

[0059] As mentioned previously, the health management system 100 is configured to provide a treatment recommendation for a user using the continuous analyte monitoring system 104 including one or more analyte sensors. In certain embodiments, the continuous analyte monitoring system 104 includes, at least a continuous glucose monitor (CGM). In certain embodiments, the therapy management engine 114 is configured to provide real-time and / or non-real-time therapy management based on glucose levels to the user and / or others, including but not limited to, healthcare providers, family members of the user, caregivers of the user, researchers, artificial intelligence (Al) engines, and / or other individuals, systems, and / or groups supporting care or learning from the data. In particular, the therapy management engine 114 may be used to collect information associated with a user in the user profile 118, to perform analytics thereon for recommending treatments (e.g., recommending an optimal dosage of inhibitors) and / or predicting onset of DKA within a certain time period. The therapy management engine 114 may also be used to collect information for pharmaceutical research to develop new therapies or more efficacious therapies. The user profile 118 may be accessible to the therapy management engine 114 over one or more networks (not shown) for performing such analytics.

[0060] In certain embodiments, the health management system 100 is designed to predict the risk or likelihood of, or the presence and / or severity of, DKA in real-time (including near realtime) or within a specified period of time for a patient. In certain embodiments, to enable such prediction, the therapy management engine 114 is configured to collect information associated with a user in the user profile 118 stored in the user database 110, to perform analytics thereon for: (1) automatically detecting and classifying blood glucose levels; (2) assessing the risk or diseaseDexcom Ref. No.: 0960-PCT01stage of DKA; and / or (3) assessing the effectiveness of the current treatment and other potential treatment dosages and frequencies.

[0061] In certain embodiments, the therapy management engine 114 may utilize one or more trained machine learning models capable of determining the probability of the presence and / or occurrence of DKA and / or treatment recommendation for a user based on information provided by user profile 118. In the illustrated embodiment of FIG. 1, the therapy management engine 114 may utilize trained machine learning model(s) provided by a training server system 140. Although depicted as a separate server for conceptual clarity, in some embodiments, the training server system 140 and the therapy management engine 114 may operate as a single server. That is, the model may be trained and used by a single server (e.g., a local device, a microprocessor, etc.) or may be trained by one or more servers and deployed for use on one or more other servers. In certain embodiments, the model may be trained on one or many virtual machines (VMs) running, at least partially, on one or many physical servers in relational and or non-relational database formats.

[0062] The training server system 140 is configured to train the machine learning model(s) using training data, which may include data (e.g., from user profiles) associated with one or more patients (e.g., users or non-users of continuous analyte monitoring system 104 and / or application 106) previously treated for control of blood glucose, as well as patients not treated for control of blood glucose (e.g., healthy patients). The training data may be stored in the historical records database 112 and may be accessible to the training server system 140 over one or more networks (not shown) for training the machine learning model(s). The training data may also, in some cases, include user-specific data for a user over time.

[0063] In some embodiments, the training data refers to a dataset that has been featurized and labeled. For example, the dataset may include a plurality of data records, each including information corresponding to a different user profile stored in the user database 110, where each data record is featurized and labeled. In machine learning and pattern recognition, a feature is an individual measurable property or characteristic. Generally, the features that best characterize the patterns in the data are selected to create predictive machine learning models. Data labeling is the process of adding one or more meaningful and informative labels to provide context to the data for learning by the machine learning model.Dexcom Ref. No.: 0960-PCT01

[0064] As an example, each relevant characteristic of a user, which is reflected in a corresponding data record, may be a feature used in training the machine learning model. Such features may include age, gender, weight, height, body mass index, any therapies currently taken, when a therapy was last applied (e.g., insulin bolus), how much of a therapy was applied (e.g., units of insulin) change (e.g., delta) in analyte levels (e.g., glucose levels) from a first timestamp to a second timestamp, change (e.g., delta) in blood glucose from a first timestamp to a second timestamp, change (e.g., delta) in analyte thresholds (e.g., glucose thresholds) of a user under treatment for blood glucose control from a first timestamp to a subsequent timestamp, the derivative of the measured linear system of analyte measurement (e.g., glucose measurement) at a point at a specific timestamp, and / or the difference in derivatives to determine rates of change in the slope of the increase or decrease in analyte values (e.g., glucose values), etc. In addition, the data record may be labeled with an indication as to a DKA diagnosis, an assigned severity, and / or an identified risk of DKA, prescription information (e.g., dosage and frequency of consumption) for one or more SGLT-2 inhibitors, associated with a patient of the user profile.

[0065] The model(s) are then trained by the training server system 140 using the featurized and labeled training data. In particular, the features of each data record may be used as input into the machine learning model(s), and the generated output may be compared to label(s) associated with the corresponding data record. The model(s) may compute a loss based on the difference between the generated output and the provided label(s). This loss is then used to modify the internal parameters or weights of the model. By iteratively processing each data record corresponding to each historical patient, in certain embodiments, the model(s) may be iteratively refined, and the loss minimized, to generate, within a prescribed level of confidence, treatment recommendations (e.g., an optimal dosage / frequency of taking inhibitors) and predictions associated with DKA risk, presence, progression, improvement (e.g., regression), and severity in a patient. Further, in certain other embodiments, by iteratively processing each data record corresponding to each historical patient, in certain embodiments, the model(s) may be iteratively refined to generate accurate treatment recommendations and predictions of the risk and / or presence of DKA. Note that although certain embodiments herein are described in relation to providing treatment recommendations for reducing the risk of DKA and predictions of the risk and / or presence of DKA, the embodiments described herein are similarly applicable to providing treatmentDexcom Ref. No.: 0960-PCT01recommendations for reducing the risk of any type of ketoacidosis and also providing predictions of the risk and / or presence of any type of ketoacidosis.

[0066] As illustrated in FIG. 1, the training server system 140 deploys these trained model(s) to the therapy management engine 114 for use during runtime. For example, the therapy management engine 114 may obtain the user profile 118 associated with a user, use information in the user profile 118 as input into the trained model(s), and output a treatment recommendation and / or DKA prediction. The treatment recommendation may be indicative of an efficacy of a current treatment based on the medication info 124, the analyte data, and the like. In some embodiments, the treatment recommendation includes a modification to an existing treatment or a recommendation for an alternative treatment based on the efficacy of a current treatment. For example, the treatment recommendation may include a change to a current dosage and / or frequency, a change in medication type, or a notice to consult a healthcare provider, etc.

[0067] The therapy management engine 114 may provide a prediction which may be indicative of the presence and / or severity of DKA for the user in real-time or within a certain time (e.g., shown as the output 144 in FIG. 1). The output 144 generated by the therapy management engine 114 may also provide one or more recommendations for treatment based on the predictions. The output 144 may be provided to the user (e.g., through application 106), to a user’s caretaker (e.g., a parent, a relative, a guardian, a teacher, a nurse, etc.), to a user’ s physician, or any other individual that has an interest in the wellbeing of the user for purposes of improving the user’s health, such as, in some cases by effectuating the recommended treatment.

[0068] In certain embodiments, the user’s own data is used to personalize the one or more models that are initially trained based on population data. For example, a model (e.g., trained using population data) may be deployed for use by therapy management engine 114 to provide a treatment recommendation and / or predict the presence and / or severity of DKA for a specific user. In some embodiments, sometime after making a prediction using the model, the therapy management engine 114 may be configured to ask the user, or a caretaker, physician, etc., whether the medication info 124 should be updated based on the recommended change in treatment. In other embodiments, the therapy management engine 114 may provide a query as to whether the predicted presence and / or severity of DKA was confirmed by, e.g., other diagnostic methods (e.g., fingerstick test strips for blood ketones, breath ketone measurement, test strips for urinaryDexcom Ref. No.: 0960-PCT01ketones), and / or therapy management engine 114 may use one or more diagnostic tests to confirm the diagnosis. In some cases, the user’s answer and / or results from the diagnostic tcst(s) performed may deny the presence of DKA. Accordingly, the model may continue to be retrained and / or personalized using updated medication info 124, the user’s answer, the user’s test results, and / or physiological parameters of the user. While specific examples are given, other data may also be used as input into the model to personalize the model for the user.

[0069] In certain embodiments, the output 144 generated by the therapy management engine 114 may be stored in the user profile 118. In certain embodiments, the output 144 may be patientspecific treatment recommendations, treatment efficacy, identification of one or more indicators of DKA, and the like. For example, in certain embodiments, the output 144 may be a treatment recommendation for an update in medication, medication dosage, medication frequency of use, prediction as to the presence and / or severity of DKA in a user, and the like. In certain embodiments, the output 144 may be a prediction as to the risk of the onset of DKA. In certain embodiments, the output 144 may be a prediction as to the risk of a user having hyperglycemia and / or hypoglycemia. In certain embodiments, the output 144 may be a prediction as to a mortality risk of the patient. In certain embodiments, the output 144 may be patient- specific treatment decisions or recommendations for glucose control for the patient. In specific embodiments, the output 144 may be a recommendation relating to the use of an inhibitor (e.g., SGLT2), a recommendation relating to the use of insulin, etc.

[0070] In some embodiments, the output 144 stored in the user profile 118 may be continuously updated by the therapy management engine 114. Accordingly, previous diagnoses and / or physiological parameters of the user associated with blood glucose control, originally stored as the outputs 144 in the user profile 118 in the user database 110 and then passed to the historical records database 112, may provide an indication of the effectiveness of the current treatment or may provide a likelihood of onset of DKA in a user in a given time period. Additionally, previous diagnoses and / or physiological parameters of the user associated with how well medication was tolerated and / or how efficacious a certain type / dose / frequency of administration of the medication was, originally stored as the outputs 144 in the user profile 118 in the user database 110 and then passed to the historical records database 112, may provide an indication of the effectiveness of the current treatment or may provide a likelihood of onset of DKA in a user in a given time period.Dexcom Ref. No.: 0960-PCT01

[0071] In certain embodiments, a user’s own historical data may be used to provide therapy management and insight around the user’s blood glucose control and / or condition onset. For example, a user’s historical data may be used by an algorithm as a baseline to indicate improvements or deterioration in the user’s condition. As an illustrative example, a user’s data from two weeks prior may be used as a baseline that can be compared with the user’ s current data to identify an improvement or deterioration in glucose levels of the user and, thereby, whether the risk associated with a future DKA event has increased or decreased. In certain embodiments, the user’s own historical data may be used by the training server system 140 to train a personalized model that may further be able to predict the presence and / or severity of DKA, optimal treatments for reducing the predicted presence and / or severity of DKA, and / or improvement / deterioration in the user’s ketone and / or glucose data based on the user’s recent pattern of data (e.g., exercise data, ketone test data, food consumption data, etc.).

[0072] In certain embodiments, the model may be trained to provide lifestyle recommendations, exercise recommendations, food intake recommendations, and other types of therapy management recommendations to help the user improve treatment or prevent onset and / or progression of DKA based on the user’s historical data, including how different types of medication, food, and treatment (e.g., medication type, dosage, frequency) have impacted the user’s analyte levels in the past. In certain embodiments, the model may be trained to predict the underlying cause of certain improvements or deteriorations in the patient’s analyte levels. For example, the application 106 may display a user interface with a graph that shows the patient’s analyte levels or a score thereof with trend lines and indicate, e.g., retrospectively, what caused the change in analyte levels at certain points in time (e.g., administration of insulin, administration of SGLT2, etc.).

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

[0074] Generally, real-time or continuous measurements of analyte levels, rates of change, trends, clearance rates, and / or other analyte data, as measured in interstitial fluid or blood by aDexcom Ref. No.: 0960-PCT01continuous analyte monitoring system, can be used to provide treatment recommendations to the user. Such data can indicate a change in analyte levels indicative of a treatment that is less than ideal. Therefore, continuous analyte monitoring may provide earlier, and / or improved treatment recommendations, such as improving the titration of pharmacologic agents with narrow therapeutic windows or evolving pharmacokinetic profiles. Some embodiments may provide screening, diagnosis, prognosis, and / or staging of DKA as compared to conventional diagnostics.

[0075] In certain embodiments, clinical indicators may be used to determine whether a continuous analyte monitoring system, e.g., the continuous analyte monitoring system 104, may be needed to assess an efficacy of a treatment or to assess a risk, likelihood, presence, and / or stage of DKA in a patient. Tn one example, such clinical indicators include glucose measurements, lactate measurements, dissolved oxygen measurements, ion measurements, blood pressure measurements, renal metrics, hydration measurements, physical activity metrics, sleep metrics, heart rate, respiration rate, core temperature, nutrition information, etc. Analytes and other information may generally indicate a needed optimization of a medication dosage and / or frequency or may indicate the presence, risk, or likelihood of DKA.

[0076] In yet another example, clinical indicators may include prescribed or taken medications. For a patient taking certain medications associated with blood glucose control, or medication associated with increased likelihood of DKA, it may be desirable to monitor for DKA. For example, a patient on a medication known to be a factor in the occurrence of DKA may use a continuous analyte monitor to optimize the medication or predict DKA, which may have been, at least partially, caused by the medication.

[0077] In yet another example, clinical indicators may include an assessment of patient adherence to treatment. A comparison of a prescribed treatment to an actual treatment to quantify how well a patient is complying with the prescribed treatment may allow for a more accurate assessment of the efficacy of the prescribed treatment. The comparison may be useful to healthcare providers to further adjust treatment or provide additional treatment instruction / education to the patient. The comparison may also be of interest to healthcare insurers and / or healthcare payers with respect to reimbursement or other considerations (e.g., rewards, discounts, etc.).

[0078] In yet another example, clinical indicators may include comorbidities often associated with, and / or increasing the risk of, DKA. Comorbidities associated with DKA may includeDexcom Ref. No.: 0960-PCT01cardiovascular disease, chronic kidney disease, liver disease (e.g., NAFLD, NASH), obesity, activity level, diet, hypertension, hyperlipidemia, etc.

[0079] In certain embodiments, continuous analyte monitoring system 104 may be utilized as a short-term diagnostic tool to monitor a new or updated medication type, dosage, and / or frequency for patient reaction, assessing how well the medication is tolerated, and any negative results (e.g., DKA). For example, a triggering action (e.g., triggering while wearing an analyte sensor), may indicate utility for a patient to wear an analyte sensor (continuous or non-continuous) for a short time period to provide monitoring for patient response to inhibitors and / or for monitoring for DKA in the patient. In one instance, a patient may wear a short-term continuous or non-continuous analyte sensor for a given period after starting a new medication regimen. In another instance, a patient may wear a short-term continuous or non-continuous analyte sensor periodically (e.g., every 4 weeks) to monitor efficacy of the new medication and provide recommendations for further changes or optimizations to the treatment. In yet another instance, a patient may wear a short-term continuous or non-continuous analyte sensor to predict a likelihood of DKA. In certain scenarios, data from the analyte sensor can be presented directly to the user. In other diagnostic scenarios, the analyte sensor can be operated in data logging mode, thereby blinding the user to analyte data while allowing the physician to review said data at a later time.

[0080] In some embodiments, the continuous analyte monitoring system 104 may be utilized as a long-term diagnostic tool (i.e., greater than 14 days) to monitor patient response and further update the treatment recommendations. Monitoring the patient may also be useful in ongoing prediction and alerts for onset of DKA. For example, a patient at high risk for DKA and / or adverse events may utilize a continuous analyte sensor to continually provide insight into the efficacy of the currently prescribed treatment, recommend further updates to the treatment, or predict DKA for days, weeks, months, etc.

[0081] As shown in FIG. 2, the continuous analyte monitoring system 104 in the illustrated embodiment includes a sensor electronics module 204 and one or more continuous analyte sensor(s) 202 (individually referred to herein as the continuous analyte sensor 202 and collectively referred to herein as the continuous analyte sensors 202) associated with a sensor electronics module 204. The sensor electronics module 204 may be in wireless communication (e.g., directly or indirectly) with one or more display devices 210, 220, 230, and 240. In certain embodiments,Dexcom Ref. No.: 0960-PCT01the sensor electronics module 204 may also be in wireless communication (e.g., directly or indirectly) with one or more medical devices 208 (individually referred to herein as the medical device 208 and collectively referred to herein as the medical devices 208), and / or one or more other non-analyte sensors 206 (individually referred to herein as the non-analyte sensor 206 and collectively referred to herein as the non-analyte sensor 206). In other embodiments, including, but not limited to, diagnostic implementations, the sensor electronics module may be operated independently (e.g., unpaired with a display device) and queried at the end of a wear session to wirelessly transfer data logged during a session to a local device or Cloud database for future review, retrieval, or execution of further analytics.

[0082] In certain embodiments, a continuous analyte sensor 202 may comprise a sensor for detecting and / or measuring analyte(s). The continuous analyte sensor 202 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, a dermal device, an intradermal device, a subdermal device, implanted device, and / or an intravascular device. In certain embodiments, the continuous analyte sensor 202 may be configured to continuously measure analyte levels of a user using one or more measurement techniques, such as enzymatic, immunometric, aptameric, amperometric, voltametric, potentiometric, impedimetric, conductimetric, conductometric, capacitive, chemical, physical, electrochemical, spectrophotometric, polarimetric, calorimetric, iontophoretic, radiometric, immunochemical, optical, ion-selective and the like. In certain aspects, the continuous analyte sensor 202 provides a data stream indicative of the concentration of one or more analytes in the user. The data stream may include raw data signals which may be converted into a calibrated and / or filtered data stream used to provide estimated analyte value(s) to the user.

[0083] In certain embodiments, the continuous analyte sensor 202 may be a multi-analyte sensor configured to continuously measure multiple analytes in a user’s body. For example, in certain embodiments, the continuous multi-analyte sensor 202 may be a single sensor configured to measure glucose and / or other analytes circulating in the user’s body.

[0084] 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 glucose and one or more other analytes and may, in someDexcom Ref. No.: 0960-PCT01cases, be used in combination with one or more other analyte sensors configured to measure only, for example, lactate levels, oxygen levels, hydration levels or hormone levels. In various embodiments, a multi-analyte sensor can include a single body-worn wearable or two distinct body-worn wearables. Information from each of the multi-analyte sensor(s) and single analyte sensor(s) may be combined to provide treatment therapy management using methods described herein.

[0085] In certain embodiments, the continuous analyte sensor(s) 202 may comprise a percutaneous wire that has a proximal portion coupled to the sensor electronics module 204 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 measurement electrode to the proximal portion of the percutaneous wire that is coupled to the sensor electronics module 204. After the continuous analyte monitoring system 104 has been applied to epidermis of the patient, continuous analyte sensor(s) 202 penetrates the epidermis, and the distal portion extends into the dermis and / or subcutaneous tissue under epidermis. Other configurations of continuous analyte sensor(s) 202 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.

[0086] 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 202 may include a single-analyte sensor configured to measure glucose concentration levels, and another single-analyte sensor configured to measure lactate concentration levels of the patient. As another illustrative example, continuous analyte sensor(s) 202 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, creatinine concentration levels, etc. As yet another illustrative example, continuous analyte sensor(s) 202 may include a multi-analyte sensorDexcom Ref. No.: 0960-PCT01configured to measure glucose concentration levels, lactate concentration levels, creatinine concentration levels, etc. Accordingly, continuous analyte scnsor(s) 202 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 204 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) 202 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 210, 220, and / or 230, via a wireless connection. For example, sensor electronics module 204 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.

[0087] In certain embodiments, continuous analyte sensor(s) 202 may incorporate a thermocouple within, or alongside, the percutaneous wire to provide an analog temperature signal to the sensor electronics module 204, 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 204 above the adhesive pad, or, alternatively, the thermocouple may contact the epidermis of the patient through openings in the adhesive pad.

[0088] In certain embodiments, the sensor electronics module 204 includes, inter alia, processor 233, storage element or memory 234, wireless transmitter / receiver (transceiver) 236, one or more antennas coupled to wireless transceiver 236, 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) 202 (such as a potentiostat), etc.

[0089] Processor 233 may be a general-purpose or application- specific microprocessor, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc., thatDexcom Ref. No.: 0960-PCT01executes instructions to perform control, computation, input / output, etc. functions for the sensor electronics module 204. Processor 233 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 233, memory 234, wireless transceiver 236, the A / D signal processing circuitry, and the digital signal processing circuitry may be combined into a system-on-chip (SoC).

[0090] Generally, processor 233 may be configured to sample the analog electrical signal using the A / D signal processing circuitry at regular intervals (such as the sampling period) to generate analyte sensor count values based on the analog electrical signals produced by the continuous analyte sensor(s) 202, calibrate the analyte sensor count values based on the sensitivity profile of the continuous analyte sensor(s) 202 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 233 may store the measured analyte concentration level data in memory 234, and generate the sensor data packages at regular intervals (such as the transmission period) for transmission by wireless transceiver 236 to a display device, such as display devices 210, 220, 230, and / or 240. Processor 233 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

[0091] In various embodiments, memory 234 may include volatile and nonvolatile medium. For example, memory 234 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 234 may store one or more analyte sensor system applications, modules, instruction sets, etc. for execution by processor 233, such as instructions to generate measured analyte data from the analyte sensor count values, etc.Dexcom Ref. No.: 0960-PCT01

[0092] Memory 234 may also store certain sensor operating parameters 235, 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 204 may be programmed into the sensor electronics module 204 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 234 and used to convert the analyte sensor electrical signals into measured analyte concentration levels. In certain embodiments, calibration sensitivity (Mcc) 246 and / or calibration baseline 247 may be stored in memory 234.

[0093] In certain embodiments, the sensor electronics module 204 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. The sensor electronics module 204 can be physically connected to the continuous analyte sensor(s) 202 and can be integral with (non-releasably attached to) or releasably attachable to the continuous analyte sensor(s) 202. The sensor electronics module 204 may include hardware, firmware, and / or software that enables measurement of levels of analyte(s) via a continuous analyte sensor(s) 202. For example, the sensor electronics module 204 can include an electrochemical analog front end (e.g., potentiostat, galvanostat, impedance measurement device), a power source for providing power to the sensor, a microprocessor for executing an embedded data processing or algorithmic routine, other components useful for signal processing and data storage, and a telemetry module for transmitting data from the sensor electronics module to one or more display devices or a centralized data repository. Electronics can be affixed to a printed circuit board (PCB), flexible PCB (flexPCB), 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 field-programmable gate array (FPGA), a system-on-a-chip (SoC), a microcontroller, and / or a processor.

[0094] In some embodiments, the display devices 210, 220, 230, and / or 240 are configured for displaying displayable sensor data, including analyte data, which may be transmitted by the sensor electronics module 204. Each of the display devices 210, 220, 230, or 240 can include a displayDexcom Ref. No.: 0960-PCT01such as a touchscreen display 212, 222, 232, or 242 for displaying sensor data to a user and / or receiving inputs from the user. For example, a graphical user interface (GUI) may be presented to the user for such purposes. In some embodiments, the display devices 210, 220, 230, and 240 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 user of the display device and / or receiving user inputs. The display devices 210, 220, 230, and 240 may be examples of the display device 107 illustrated in FIG. 1 used to display sensor data to a user of FIG. 1 and / or receive input from the user.

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

[0096] The plurality of display devices may include a custom display device specially designed for displaying certain types of display able 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 / notifications based on the displayable sensor data. The display device 210 is an example of such a custom device. In some embodiments, one of the plurality of display devices is a smartphone, such as the display device 220 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 the display device 230 which represents a tablet, the display device 240 which represents a smart watch, the medical device 208 (e.g., an insulin delivery device or a blood glucose meter), and / or a desktop or laptop computer (not shown).

[0097] Because different display devices provide different user interfaces, the 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) 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 204 that is physically connected to continuous analyte sensor(s)Dexcom Ref. No.: 0960-PCT01202) 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. In certain embodiments, the type of alarms customized for each particular display device, the number of alarms customized for each particular display device, the timing of alarms customized for each particular display device, and / or the threshold levels configured for each of the alarms (e.g., for triggering) are based on the output 144 (e.g., as mentioned, the output 144 may be indicative of the current health of a user, the state of a user’s glucose levels, current treatment recommended to a user, and / or physiological parameters of a user) stored in the user profile 118 for each user.

[0098] As mentioned, the sensor electronics module 204 may be in communication with a medical device 208. The medical device 208 may be a passive device in some example embodiments of the disclosure. For example, the medical device 208 may be an insulin pump for administering insulin to a user. For a variety of reasons, it may be desirable for such an insulin pump to receive and track glucose values transmitted from the continuous analyte monitoring system 104, where the continuous analyte sensor 202 is configured to measure glucose. In addition, or alternatively, the medical device 208 may be a smart pen for administering insulin to the user.

[0099] Further, as mentioned, the sensor electronics module 204 may also be in communication with other non-analyte sensors 206. The non-analyte sensors 206 may include, but are not limited to, an altimeter sensor, an accelerometer sensor, a temperature sensor, a respiration rate sensor, a sweat sensor, etc. The non-analyte sensors 206 may also include monitors such as heart rate monitors, ECG monitors, blood pressure monitors, pulse oximeters, caloric intake, and medicament delivery devices. The non-analyte sensors 206 may also include data systems for measuring non-patient specific phenomena such as time, ambient pressure, or ambient temperature which could include an atmospheric pressure sensor, an external air temperature sensor or a clock, timer, or other time measure of when the sensor was first inserted or a measure of sensor life remaining compared to insertion time could be used as calibration or other data inputs for an algorithmic model. One or more of these non-analyte sensors 206 may provide data to the therapy management engine 114 described further below. In some aspects, a user may manually provide some of the data for processing by the training server system 140 and / or the therapy management engine 114 of FIG. 1.Dexcom Ref. No.: 0960-PCT01

[0100] In certain embodiments, a wireless access point (WAP) may be used to couple one or more of the continuous analyte monitoring system 104, the plurality of display devices, the medical device(s) 208, and / or the non-analyte sensor(s) 206 to one another. For example, the WAP may provide Wi-Fi, cellular-, and / or loT (e.g., NB-IoT, LTE Cat-Mi) connectivity among these devices. Near Field Communication (NFC) and / or Bluetooth may also be used among devices depicted in the diagram 200 of FIG. 2.

[0101] FIG. 3 illustrates a diagram 300 of example inputs and example metrics that are calculated based on the inputs for use by the health management system of FIG. 1, according to some embodiments disclosed herein. In particular, FIG. 3 provides a more detailed illustration of example inputs and example metrics introduced in FIG. 1.

[0102] FIG. 3 shows example inputs 128 on the left, the application 106 and the therapy management engine 114 including the DAM 116 in the middle, and metrics 130 on the right. In certain embodiments, each one of the metrics 130 may correspond to one or more values, e.g., discrete numerical values, ranges, or qualitative values (high / medium / low, stable / unstable, rate of change, points of inflection, etc.). The application 106 obtains the inputs 128 through one or more channels (e.g., manual user input, sensors / monitors, other applications executing on the display device 107, EMRs, etc.). As mentioned previously, in certain embodiments, the inputs 128 may be processed by the DAM 116 and / or the therapy management engine 114 to output the metrics 130. The inputs and metrics 130 may be used by the therapy management engine 114 to provide therapy management to the user. For example, the inputs 128 and the metrics 130 may be used by the training server system 140 to train and deploy one or more machine learning models for use by the therapy management engine 114 for providing therapy management around treatment of the patient.

[0103] In certain embodiments, starting with the inputs 128, 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 (milligrams (mg) of sodium, potassium, carbohydrate, fat, protein, etc.), sequence of consumption, and time of consumption. In certain embodiments, food consumption may be provided by a user through manual entry, by providing a photograph through an application that is configured to recognize food types and quantities, by scanning a bar-code or menu, and / or intemogating an NFC / RFID tag integrated into the packaging of the food item. In variousDexcom Ref. No.: 0960-PCT01examples, meal size may be manually entered as one or more of calories, quantity (e.g., “three cookies”), menu items (e.g., “Royalc with Cheese”), and / or food exchanges (e.g., 1 fruit, 1 dairy). In some examples, meal information may be received via a convenient user interface provided by the application 106. In some examples, meal information may be provided via one or more other applications synchronized with the application 106, such as one or more other mobile health applications executed by the display device 107. In such examples, the synchronized applications may include, e.g., an electronic food diary application or photograph application.

[0104] In certain embodiments, food consumption information entered by a user may relate to nutrients consumed by the user. Consumption may include any natural or designed food or beverage. Food consumption information entered by a user may also be related to analytes, including any of the other analytes described herein.

[0105] In certain embodiments, exercise information is also provided as an input. Exercise information may be any information surrounding activities, such as activities requiring physical exertion by the user. For example, exercise information may range from information related to low intensity (e.g., walking a few steps) and high intensity (e.g., five mile run) physical exertion or it could take the form of a wattage (e.g., stationary cycle), speed (e.g., GPS-enabled smartwatch), and / or resistance (e.g., elliptical machine) over a specified time interval. In certain embodiments, exercise information may be provided, for example, by an accelerometer sensor or a heart rate monitor on a wearable device such as a watch, fitness tracker, and / or patch. In certain embodiments, exercise information may also be provided through manual user input, through workout machinery, and / or through a surrogate sensor and prediction algorithm measuring changes to heart rate (or other cardiac metrics). When predicting that a user is exercising based on his / her sensor data, the user may be asked to confirm if exercise is occurring, what type of exercise, and or the level of strenuous exertion being used during the exercise over a specific period. This data may be used to train the system to learn about the user’s exercise patterns to reduce the need for confirmation questions as time progresses. Other analytes and sensor data may also be included in this training set, including analytes and other measured elements described herein including temporal elements, such as time and day.

[0106] In certain embodiments, user statistics, such as one or more of age, height, weight, BMI, body composition (e.g., % body fat), stature, build, or other information may also beDexcom Ref. No.: 0960-PCT01provided as an input. In certain embodiments, user statistics are provided through a user interface, by interfacing with an electronic source such as an electronic medical record, and / or from measurement devices. In certain embodiments, the measurement devices 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 user data.

[0107] In certain embodiments, treatment information is also provided as an input. Treatment information may include information about the type, dosage, and / or timing of when one or more medications (e.g., SGLT2, insulin, glucagon, sulfonylurea, metformin, GLP-1) are to be taken by the user. As mentioned herein, the treatment information may include information about one or more inhibitors, one or more drugs known to reduce blood glucose levels, one or more drugs known to affect ketone, and / or one or more medications for treating one or more symptoms of acute or chronic conditions and diseases the user may have. The treatment information may include information regarding different lifestyle habits, surgical procedures, and / or other non-invasive procedures recommended by the user’s physician. For example, the user’s physician may recommend a user increase / decrease their carbohydrate intake, exercise for a minimum of thirty minutes a day, or increase an insulin dosage or other medication to maintain, improve, and / or reduce hyper- and / or hypoglycemic episodes, etc. As another example, a healthcare professional may recommend that a user engage in at-home treatment and / or treatment at a clinic. The treatment information may also indicate a patient’s adherence to the prescribed type, dosage, and / or timing of medications. For example, the treatment / medication information may indicate whether and when exactly and with what dosage / type the medication was taken.

[0108] In certain embodiments, analyte sensor data may also be provided as input, for example, through the continuous analyte monitoring system 104. In certain embodiments, analyte sensor data may include glucose data measured by at least a glucose sensor (or multi-analyte sensor configured to measure at least glucose) that is a part of continuous analyte monitoring system 104.

[0109] In certain embodiments, input may also be received from one or more non-analyte sensors, such as the non-analyte sensors 206 described with respect to FIG. 2. Input from the non-analyte sensors 206 may include information related to a heart rate, heart rate variability (e.g., the variance in time between the beats of the heart), ECG data, a respiration rate, oxygen saturation, a blood pressure, or a body temperature (e.g. to detect illness, physical activity, etc.) of a user. InDexcom Ref. No.: 0960-PCT01certain embodiments, electromagnetic sensors may also detect low-power radio frequency (RF) fields emitted from objects or tools touching or near the object, which may provide information about user activity or location.

[0110] In some embodiments, the non-analyte sensors 206 may include an embedded scanner / reader to detect medication related information (e.g., type, brand, dosage, frequency). Examples of a scanner may include a reader configured to detect near-field communication (NFC) and / or radio frequency identification (RFID) information provided by a corresponding active or passive tag provided within the medication packaging or otherwise accompanying the medication. Another example of a scanner may be a barcode, QR, or other optical scanner capable of accessing information associated with a visual pattern provided on the packaging or otherwise associated with the medication.

[0111] In certain embodiments, input received from non-analyte sensors may include input relating to a user’s insulin delivery. In particular, input related to the user’s insulin delivery may be received, via a wireless connection on a smart pen, via user input, and / or from an insulin pump. Insulin delivery information may include one or more of insulin manufacturer, insulin dosage, insulin formulation, insulin volume, basal vs bolus dose, intended pharmacokinetic profile (e.g., short-acting, long-acting), number of units of insulin delivered, time of delivery, etc. Other parameters, such as insulin action time or duration of insulin action, may also be received as inputs.

[0112] In certain embodiments, ketone test data may also be provided as input, for example, by a patient or other user. The ketone test data may include ketone levels resulting from, for example, fingerstick test strips for blood ketones, breath ketone measurement, test strips for urinary ketones, etc.

[0113] In certain embodiments, time may also be provided as an input, such as time of day, UTC time or time from a real-time clock. Said real-time clock may be provided externally (synchronized to a server via a Wi-Fi, cellular-, or Bluetooth wireless connection) or may be embedded as an integrated real-time clock (RTC) circuit within the wearable I sensor electronics. For example, in certain embodiments, input analyte data may be timestamped to indicate a date and time when the analyte measurement was taken for the user.Dexcom Ref. No.: 0960-PCT01

[0114] User input of any of the above-mentioned inputs 128 may be through a user interface, such a user interface of the display device 107 of FIG. 1.

[0115] As described above, in certain embodiments, the DAM 116 and / or the therapy management engine (e.g., using one or more trained models) determines or computes the user’s metrics 130 based on the inputs 128. An example list of the metrics 130 is shown in FIG. 3.

[0116] In certain embodiments, glucose levels may be determined from sensor data. For example, glucose levels refer to time-stamped glucose measurements or values that are continuously generated and stored over time.

[0117] In certain other embodiments, the DAM 116 may use glucose levels measured over a period of time where the user is (i.c., GPS coordinates), at least for a subset of the period of time, engaging in exercise and / or consuming nutrients and / or an external condition exists that would affect the glucose levels. In such embodiments, the DAM 116 may, in some examples, first identify which measured analyte values are not to be used for calculating the baseline by identifying which analyte values have been affected by an external event, such as the consumption of food, exercise, medication, or other perturbation that would disrupt the capture of an analyte baseline measurement. The DAM 116 may then exclude such measurements when calculating the analyte baseline of the user. In some other examples, the DAM 116 may calculate the analyte baseline by first determining a percentage of the number of analyte values measured during this time period that represent the lowest analyte values measured. The DAM 116 may then take an average of such analyte values to determine the analyte baseline level.

[0118] In certain embodiments, an absolute maximum analyte level (e.g., glucose) may be determined from sensor data, health / sickness metrics (e.g., described in more detail below), and / or other condition metrics. The absolute maximum analyte level represents a user’s maximum analyte level determined to be safe over a period of time (e.g., hourly, weekly, daily, etc.). In certain embodiments, the absolute maximum analyte level may be consistent across all users. In certain other embodiments, each patient may have a different absolute maximum analyte level. In certain embodiments, the absolute maximum analyte level per patient may change over time. For example, a user may be initially assigned an absolute maximum analyte level based on clinical input. This assigned absolute maximum analyte level may be adjusted over time based on other sensor data,Dexcom Ref. No.: 0960-PCT01comorbidities, etc. for the patient. Minimum analyte values may be determined in a similar manner.

[0119] In certain embodiments, analyte thresholds other than an absolute maximum and / or minimum analyte level of a user may be determined from sensor data (e.g., glucose measurements obtained from a continuous sensor of continuous analyte monitoring system 104), health / sickness metrics (e.g., described in more detail below), and / or other condition metrics. Such analyte thresholds may represent, e.g., the maximum or minimum analyte levels determined to be safe during certain activities, which may vary across different activities. For example, because exercise is known to affect glucose levels, the maximum and / or minimum glucose thresholds for a user during exercise may be different than maximum and / or minimum glucose thresholds for the user during other activities.

[0120] In certain embodiments, analyte level rates of change may be determined from the sensor data (e.g., glucose measurements obtained from the continuous analyte monitoring system 104 over time). For example, a glucose level rate of change refers to a rate that indicates how one or more time-stamped glucose measurements or values change in relation to one or more other time-stamped glucose measurements or values. Glucose level rates of change may be determined over one or more seconds, minutes, hours, days, etc.

[0121] In certain embodiments, determined analyte level rates of change may be marked as “increasing rapidly” or “decreasing rapidly”. As used herein, “rapidly” may describe analyte level rates of change that are clinically significant and pointing towards a trend of the analyte levels likely breaching the absolute maximum analyte level or the absolute minimum analyte level within a defined period of time. In other words, a predictive trend (e.g., produced by the therapy management engine 114 using one or more trained models) may, in some cases, indicate that a patient is likely to hit, for example, the absolute maximum analyte level within a specified time period (e.g., one or two hours) based on the determined analyte level rate of change. Accordingly, such an analyte level rate of change may be marked as “increasing rapidly”. Similarly, a predictive trend (e.g., produced by the therapy management engine 114 using one or more trained models) may, in some cases, indicate that a patient is likely to hit the absolute minimum analyte level within a specified time period (e.g., one or two hours) based on the analyte level rate of changeDexcom Ref. No.: 0960-PCT01determined. Accordingly, such an analyte level rate of change may he marked as “decreasing rapidly”.

[0122] In certain embodiments, analyte (e.g., glucose) baseline rates of change may be determined from analyte baselines determined for a user over time. For example, a glucose baseline rate of change refers to a rate that indicates how one or more time-stamped glucose baselines for a user change in relation to one or more other time-stamped glucose baselines for the same user, glucose baseline rates of change may be determined over one or more seconds, minutes, hours, days, etc.

[0123] In certain embodiments, an analyte clearance rate may be determined from sensor data (e.g., glucose measurements obtained from a CGM of the continuous analyte monitoring system 104) following the consumption of a known, or estimated, amount of analyte. The analyte clearance rates analyzed over time may be indicative of medication efficacy or onset of a condition. In particular, the slope of a curve of analyte clearance during a first time period (e.g., after administration of an inhibitor) compared to the slope of a curve of an analyte clearance during a second time period (e.g., after consuming the same inhibitor) may be indicative of an effectiveness of a treatment.

[0124] In certain embodiments, the analyte clearance rate may be determined by calculating a slope between a first value (e.g., during a period of increased levels) at to and the user’s analyte baseline reached at ti. In certain embodiments, an analyte clearance rate may be calculated over time until the increased analyte levels of the user reach some value relative to the user’ s analyte baseline (e.g., % of a user’s analyte baseline). Analyte clearance rates calculated over time may be time-stamped and stored in the user’s profile 118.

[0125] In certain embodiments, a standard deviation of analyte levels (not shown) may be determined from sensor data. In some examples, a standard deviation of one or more analyte levels may be determined based on the variability of one or more analyte levels as compared to an average analyte level over one or more time periods. In some embodiments, a time-in-range metric (not shown) may be determined from the analyte data. For example, with an established upper limit and lower limit, the time period during which the analyte data was between the upper and lower limits can be determined. The time-in-range may be determined for individual instances of theDexcom Ref. No.: 0960-PCT01analyte data being in-range or may be determined over a predetermined length of time (one day) for which each individual in-range periods arc summed.

[0126] In certain embodiments, analyte trends may be determined based on analyte levels over certain periods of time. In certain embodiments, glucose trends may be determined based on glucose baselines over certain periods of time. In certain embodiments, analyte trends may be determined based on absolute analyte level minimums over certain periods of time. In certain embodiments, analyte trends may be determined based on absolute maximum analyte levels over certain periods of time. In certain embodiments, analyte trends may be determined based on analyte level rates of change over certain periods of time. In certain embodiments, analyte trends may be determined based on analyte baseline rates of change over certain periods of time. In certain embodiments, analyte trends may be determined based on calculated analyte clearance rates over certain periods of time.

[0127] In certain embodiments, glucose levels may be determined from sensor data (e.g., glucose measurements obtained from a continuous glucose sensor of continuous analyte monitoring system 104).

[0128] In certain embodiments, glucose level rates of change may be determined from sensor data (e.g., glucose measurements obtained from a continuous glucose monitor (CGM) of continuous analyte monitoring system 104 over time). For example, a glucose level rate of change refers to a rate that indicates how one or more time-stamped glucose measurements or values change in relation to one or more other time-stamped glucose measurements or values. Glucose level rates of change may be determined over one or more seconds, minutes, hours, days, etc.

[0129] In certain embodiments, a glucose trend may be determined based on glucose levels over a certain period of time. In certain embodiments, glucose trends may be determined based on glucose level rates of change over certain periods of time.

[0130] In certain embodiments, glycemic variability may be determined from sensor data (e.g., glucose measurements obtained from continuous analyte monitoring system 104 over time). For example, glycemic variability refers to a standard deviation of glucose levels over a period of time. Glycemic variability may be determined over one or more minutes, hours, days, etc.Dexcom Ref. No.: 0960-PCT01

[0131] In certain embodiments, a glucose clearance rate may be determined from sensor data (c.g., glucose levels obtained from a continuous glucose sensor of the continuous analyte monitoring system 104) following the consumption of a known, or estimated, amount of glucose or know nutrient resulting in production of glucose. Glucose clearance rates analyzed over time may be indicative of glucose homeostasis. Glucose trends may be indicative of an effectiveness of a medication type, dosage, and / or frequency.

[0132] In certain embodiments, the glucose clearance rate may be determined by calculating a slope between an initial high glucose value (e.g., highest glucose level during a period of 20-30 minutes after the consumption of glucose) at to and a subsequent low glucose value at ti. The low glucose value (GL) may be determined based on a user’s initial high glucose value (Gu) and baseline glucose value (GB) before the consumption of glucose. In certain embodiments, GL can be a glucose value between Gnand GB, e.g., GL= GB + K*(GH- GB) / 2, where K can be a percentage representing by how much a user’s glucose level returned to the user’s baseline value. When K equals zero, the low glucose value equals the baseline glucose value. When K equals 0.5, the low glucose value equals the mean glucose value between the initial glucose value and the baseline glucose value.

[0133] In certain embodiments, the glucose clearance rate may be determined over one or more periods of time after the consumption of glucose, such as following an oral glucose tolerance test (OGTT). The glucose clearance rate may be calculated for each time period to represent the dynamics of glucose clearance rate after the consumption of glucose. These glucose clearance rates calculated over time may be time-stamped and stored in the user’s profile 118. Certain metrics may be derived from the time-stamped glucose clearance rates, such as mean, median, standard deviation, percentile, etc.

[0134] In certain embodiments, insulin sensitivity may be determined using historical data, real-time data, or a combination thereof, and may, for example, be based upon one or more inputs 128, such as one or more of food consumption information, continuous analyte sensor data, nonanalyte sensor data (e.g., insulin delivery information from an insulin device), etc. Insulin sensitivity refers to how responsive a user’s cells are to insulin. Improving insulin sensitivity for a user may help to reduce insulin resistance in the user.Dexcom Ref. No.: 0960-PCT01

[0135] In certain embodiments, insulin on board may be determined using non-analyte sensor data input (c.g., insulin delivery information) and / or known or learned (c.g. from user 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.

[0136] In certain embodiments, an insulin clearance rate may be determined using historical data, real-time data, or a combination thereof, e.g., by calculating a slope between an initial insulin value (e.g., during a period of increased insulin levels) at to and a final insulin value of the user at ti.

[0137] In certain embodiments, ketone levels may be determined, for example, from the ketone test data of the inputs 128.

[0138] In certain embodiments, health and sickness metrics may be determined, for example, based on one or more of user input (e.g., pregnancy information or known sickness or disease information), from 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, a user’s state may be defined as being one or more of healthy, ill, rested, or exhausted.

[0139] In certain embodiments, 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).

[0140] In certain embodiments, meal habits metrics are based on the content and the timing of a user’s meals. For example, if a meal habit metric is on a scale of 0 to 1, the better / healthier meals the user eats the higher the meal habit metric of the user will be to 1, in an example. Also, the more the user’s food consumption adheres to a certain time schedule or a recommended diet, the closer their meal habit metric will be to 1 , in the example.

[0141] In certain embodiments, medication adherence (not shown) is measured by one or more metrics that are indicative of how committed the user is towards their medication regimen. InDexcom Ref. No.: 0960-PCT01certain embodiments, medication adherence metrics are calculated based on one or more of the timing of when the user takes medication (c.g., whether the user is on time or on schedule), the type of medication (e.g., is the user taking the right type of medication), and the dosage of the medication (e.g., is the user taking the right dosage). In certain embodiments, medication adherence of a user may be determined in a clinical trial where medication consumption and timing of such medication consumption is monitored, through user input, and / or based on analyte data received from the continuous analyte monitoring system 104.

[0142] In certain embodiments, the activity level metric may indicate the user’s level of activity. In certain embodiments, the activity level metric may be determined, for example, based on input from an activity sensor or other physiologic sensors, such as the non-analyte sensors 206. In certain embodiments, the activity level metric may be calculated by the DAM 116 based on one or more of the inputs 128, such as one or more of exercise information, non-analyte sensor data (e.g., accelerometer data), time, user input, etc. In certain embodiments, the activity level may be expressed as a step rate of the user. Activity level metrics may be time-stamped so that they can be correlated with the user’s analyte levels (e.g., glucose levels) at the same time.

[0143] In certain embodiments, exercise regimen metrics (not shown) may indicate one or more of the type of activities the user engages in, the corresponding intensity of such activities, frequency the user engages in such activities, etc. In certain embodiments, exercise regimen metrics may be calculated based on one or more of the analyte sensor data input (e.g., from a lactate monitor, a glucose monitor, etc.), non-analyte sensor data input (e.g., non-analyte sensor data input from an accelerometer, a heart rate monitor, a respiration rate sensor, etc.), calendar input, user input, etc.

[0144] In certain embodiments, body temperature metrics may be calculated by the DAM 116 based on the inputs 128, and more specifically, non-analyte sensor data from a temperature sensor. In certain embodiments, the heart rate metrics (e.g., including heart rate and heart rate variability) may be calculated by the DAM 116 based on the inputs 128, and more specifically, non-analyte sensor data from a heart rate sensor. In certain embodiments, respiratory metrics (not shown) may be calculated by the DAM 116 based on the inputs 128, and more specifically, non-analyte sensor data from a respiratory rate sensor. In certain embodiments, blood pressure metrics (e.g., includingDexcom Ref. No.: 0960-PCT01blood pressure levels and blood pressure trends) may be calculated by the DAM 116 based on the inputs 128, and more specifically, non-analytc sensor data from the blood pressure sensor.

[0145] In certain embodiments, as described in more detail below, physiological parameters (e.g., glucose levels, glucose level rates of change, glucose levels, heart rate, blood pressure, etc.) associated with the user may be stored as metrics 130 when a state or condition of the user is confirmed. In certain embodiments, such physiological parameters may be analyzed over time to provide an indication of changes in the state or condition of the user. In certain embodiments, the user specific values of the physiological parameters experienced by the user may be a valuable input for training one or models designed to assess the current treatment of the user and a likelihood of DKA in a user. In certain embodiments, the user specific values of the physiological parameters experienced by the user may be used to create one or more personalized models specific to the user for greater accuracy.

[0146] FIG. 4 is a flow diagram illustrating an example method 400 for providing therapy management using analyte data, according to certain embodiments disclosed herein. Method 400 may be performed by the health management system 100 to collect / generate data such as inputs 128 and metrics 130, including for example, analyte data, patient information, and non-analyte sensor data mentioned above. For example, the method 400 may be performed by therapy management engine 114 to provide therapy management to a user using a continuous analyte monitoring system 104 including, at least, a continuous analyte sensor 202, as illustrated in FIGS.1 and 2. Method 400 is described below with reference to FIGS. 1 and 2 and their components. The method 400 may provide therapy management in real-time or within a specified period of time. Generally, real-time or continuous measurements of analyte levels, rates of change, trends, clearance rates, and / or other analyte data, as measured in interstitial fluid or blood, can be used to determine a condition of the user (e.g., medication efficacy, DKA onset). Therefore, continuous analyte monitoring of analytes, such as glucose, may provide improved treatment recommendations and / or improved determination of DKA as compared to conventional diagnostics.

[0147] In certain embodiments, the therapy management engine 114 of the health management system 100 may use various algorithms or artificial intelligence (Al) models, such as machinelearning models, trained based on patient- specific data and / or population data to provide treatmentDexcom Ref. No.: 0960-PCT01recommendations and / or DKA predictions. The algorithms and / or machine-learning models may take into account one or more inputs 128 and / or metrics 130 described with respect to FIG. 3 for a patient.

[0148] The one or more machine-learning models described herein for making such predictions may be at least initially trained using population data. A method for training the one or more machine learning models may be described in more detail below with respect to FIG. 5.

[0149] In certain embodiments, as an alternative to using machine learning models, therapy management engine 114 may use rule-based models to provide treatment recommendations and / or predict the risk or likelihood of a patient experiencing DKA. Rule-based models involve using a set of rules for analyzing data. These rules are sometimes referred to as ‘If statements’ as they tend to follow the line of ‘If X happens, then do or conclude Y’. In particular, therapy management engine 114 may apply rule-statements (e.g., if, then statements, do-while statements, catch statements, switch statements, finite state machine framework) to generate the treatment recommendations and / or determine the risk or likelihood of a patient developing DKA.

[0150] Such rules may be defined and maintained by therapy management engine 114 in a reference library. For example, the reference library may maintain ranges of analyte (e.g., potassium) levels and ranges of analyte level rates of change (and / or other analyte data) and / or other analyte metrics. In certain embodiments, such rules may be determined based on empirical research or an analysis of historical patient records, such as the records stored in the historical records database 112. In some cases, the reference library may become very granular. For example, other factors may be used in the reference library to create such “rules”. Other factors may include gender, age, diet, medical history, family medical history, body mass index (BMI), etc. Increased granularity may provide more accurate outputs.

[0151] At block 402, the method 400 may begin by monitoring a patient in real-time (e.g., continuously) to obtain runtime data. In certain aspects, the block 402 can include monitoring one or more analytes of a patient, such as user 102 illustrated in FIG. 1 to obtain analyte data. The one or more analytes monitored may, in certain embodiments, include at least glucose. Block 402 may be performed by the continuous analyte monitoring system 104 illustrated in FIGS. 1 and 2, and more specifically, continuous analyte sensor(s) 202 illustrated in FIG. 2, in certain embodiments.Dexcom Ref. No.: 0960-PCT01For example, continuous analyte monitoring system 104 may in certain embodiments comprise a continuous analyte sensor 202 configured to measure the patient’s analyte levels (c.g., glucose).

[0152] Accordingly, in certain embodiments, the continuous analyte sensor 202 may collect analyte measurements that can be utilized to generate analyte data including analyte baselines, analyte rates of change, analyte baseline rates of change, personalized analyte levels, average analyte levels, maximum and / or minimum analyte levels, absolute maximum and / or minimum analyte levels, standard deviation of analyte levels, analyte clearance rates, analyte trends, etc.

[0153] In certain embodiments, at block 402, continuous analyte monitoring system 104 may continuously monitor glucose levels of a patient during a plurality of time periods. In certain embodiments, the glucose levels may be used for determining a treatment recommendation or predicting the likelihood of DKA. Glucose is a simple sugar (e.g., a monosaccharide). Glucose can be both ingested, as well as, produced in the body from protein, fat, and carbohydrates. Increasing glucose stimulates insulin release. Insulin causes the cells to take in glucose for fuel. Thus, insulin stimulates glucose uptake by cells, thereby reducing glucose levels. In some cases, where glucose levels of a patient are increased and rate(s) of change of glucose levels in the patient’s body are high, excess insulin may be produced. On the other hand, where glucose levels of a patient are decreased and rate(s) of change of glucose levels in the patient’s body are low, there may be less insulin secretion. Low insulin may lead to limited access of glucose by the cells; thus, extracellular glucose levels may increase.

[0154] Insulin is partially removed from circulation by the kidneys. Inhibitors (e.g., SGLT2) may block absorption of glucose at the kidneys. In certain embodiments, the glucose data may be collected by a CGM and may be monitored by the health management system 100 for glycemic variability. Glycemic variability may generally include the standard deviation of glucose levels over a period of time, in addition to time in range (TIR) data. TIR refers to the one or more time periods in which glucose levels of a patient are within a certain desired range (e.g., healthy range).

[0155] In some aspects, the block 402 can include monitoring non-analyte sensor data during the one or more time periods, using one or more non-analyte sensors or devices (e.g., such as the non-analyte sensors 206 and / or the medical device 208 of FIG. 2). As mentioned previously, the non-analyte sensors 206 and devices may include one or more of, but are not limited to, an insulin pump, a haptic sensor, an electrocardiogram (ECG) sensor or heart rate monitor, a blood pressureDexcom Ref. No.: 0960-PCT01sensor, a sweat sensor, a respiratory sensor, a thermometer, a pulse oximeter, an impedance sensor, sensors or devices provided by display device 107 (c.g., accelerometer, camera, global positioning system (GPS), heart rate monitor, etc.) or other user accessories (e.g., a smart watch), or any other sensors or devices that provide relevant information about the user. One or more of these nonanalyte sensors 206 and devices may provide data to the therapy management engine 114 described herein. In some aspects, a user, e.g., a patient, may manually input at least a portion the data for processing by the therapy management engine 114 (e.g., results of ketone tests).

[0156] For example, an accelerometer may be used to determine a physical activity state. Accelerometer data may be analyzed and associated with a change in analyte data (e.g., a sudden downward trend in glucose values) which may be separated from a calculated effect of a medication or other therapy. In another example, a heart rate monitor may be used to provide heart rate data indicative of a physical activity state to further extricate an effect of physical activity from an effect of a medication or other treatment. In another example, a sweat sensor may provide data indicative of a physical activity state to allow for separation of a physical activity factor from an efficacy of a treatment.

[0157] Certain metrics, such as one or more of the metrics 130 illustrated in FIG. 3, may be calculated using measured data from each of these additional sensors. Further, as illustrated in FIG.3, one or more of the metrics 130 calculated from the non-analyte sensor or device data may include body temperature, heart rate (including heart rate variability), respiratory rate, etc. In certain embodiments, described in more detail below, the one or more of the metrics 130 calculated from non-analyte sensor or device data may be used to further inform the treatment recommendation and / or DKA prediction.

[0158] In certain embodiments, one or more non-analyte sensors and / or devices that may be worn by a patient may include a blood pressure sensor. Blood pressure measurements collected from a blood pressure sensor may be used to provide additional insight into health of the patient.

[0159] In certain embodiments, one or more non-analyte sensors and / or devices that may be worn by a patient may include an ECG sensor and / or a heart rate monitor. As is known in the art, an ECG device is a device that measures the electric activity of the heartbeat. In certain embodiments, heart rate measurements, as well as heart rate variability information, collected fromDexcom Ref. No.: 0960-PCT01an ECG sensor and / or a heart rate monitor may be used in combination with glucose data to better inform the treatment recommendation and / or DKA prediction.

[0160] At block 404, the method 400 continues by processing the runtime data from the block 402 to obtain additional runtime data, such as the metrics 130 discussed in relation to 130. Block 404, in certain embodiments, may be performed by the therapy management engine 114.

[0161] At block 406, the method 400 continues by executing a process to detect and mitigate DKA risk based on the runtime data from the blocks 402 and 404. In certain embodiments, the block 406 may be executed by the therapy management engine 114. In general, the block 406 can include, for example, determining an existence of an elevated DKA risk, detecting a risk of DKA, or generating a DKA prediction, which may include: (1) a likelihood or risk that the patient is experiencing (or will experience) DKA and / or (2) a presence and / or severity of DKA experienced by the patient using, for example: at least (a) the analyte metrics of the patient (e.g., determined at block 404), including glucose levels, glucose rate of change, and other relevant glucose metrics (as described in relation to FIG. 3), as well as any ketone levels (e.g., from ketone testing), and other relevant glucose metrics (as described in relation to FIG. 3); (b) other available data about the patient, and (c) a trained Al / ML model or a rule-based model. The other available data about the patient may include, for example, configuration inputs provided by the patient, such as demographic information (e.g., age, gender, ethnicity, etc.), anthropometric information (e.g., height, weight, BMI), clinical chemistry information (e.g., fasting blood glucose level, HbAlc level), compliance with SGLT2 therapy, disease information, diet / meal information, exercise / activity data, renal state information, hydration, etc. In certain embodiments, the block 406 can include determining a root cause of a detected DKA risk and / or determination a DKA mitigation.

[0162] The model described above may be a rule-based model configured to provide real-time therapy management for onset of DKA. As mentioned previously, rule-based models involve using a set of rules for mapping inputs to outputs. In particular, therapy management engine 114 may apply rule- statements (e.g., if, then statements, do-while statements, catch statements, switch statements) to take, as input, the patient’s metrics (e.g., analyte metrics or other metrics described in relation to FIG. 3) and treatment data and determine or detect a risk of a patient experiencingDexcom Ref. No.: 0960-PCT01DKA within a certain defined period of time, perform a DKA risk stratification for a patient, and / or identify risks associated with DKA for the patient.

[0163] Rules implemented by the rule-base model may be defined and maintained by the therapy management engine 114 in a reference library. For example, the reference library may maintain ranges of metrics, such as analyte metrics (e.g., levels and / or rates of change of glucose) as well as various dosages / frequencies of medications (e.g., inhibitors), which together may be mapped to different likelihoods of the onset of DKA. In certain embodiments, such rules may be determined based on empirical research as well as analyzing historical patient records from the historical records database 112. For example, an example of a rule may include: if the patient’s glucose levels exceed a predetermined threshold for more than a predetermined duration (e.g., over 300 mg / dL for more than two hours), the patient is at risk for DKA within a certain defined time period (e.g., 2 minutes, 2 hours, 2 days, 2 weeks, 2 months, etc.). The rules may be more granular and complex such that additional analyte and / or non-analyte metrics and other patient information, such as any of the information stored in the user profile 118, may be used as input for making the determinations described above.

[0164] In certain embodiments, the model may be an Al model, such as a machine-learning model (e.g., supervised), used to provide a likelihood of DKA. In certain embodiments, the therapy management engine 114 may deploy one or more machine learning models for predicting DKA in a patient. Examples of models may include a Bayesian model, regression model, classification model, support vector machine, decision tree, Monte Carlo model, neural network, artificial neural network, convolutional neural network, recurrent neural network, clustering, principal component analysis, discriminant analysis, maximum likelihood estimator, long short-term memory, etc.

[0165] In particular, the therapy management engine 114 may obtain information from a user profile 118 associated with a patient, stored in the user database 110, featurize information for the patient stored in the user profile 118 into one or more features, and use these features as input into such models. Alternatively, information provided by the user profile 118 may be featurized by another entity and the features may then be provided to the therapy management engine 114 to be used as input into the ML models. In certain embodiments, features associated with the patient may be used as input into one or more of the models. Details associated with how one or more machine-learning models can be trained are further discussed in relation to FIG. 5.Dexcom Ref. No.: 0960-PCT01

[0166] For example, an Al model may take, as input, the patient’s metrics (e.g., analyte metrics or other metrics described in relation to FIG. 3) and treatment data (e.g., dosagc / frcqucncy information) and output a likelihood of a patient experiencing DKA within a certain defined period of time, a DKA risk stratification for a patient, or other determinations.

[0167] Examples of functionality that can be performed at the block 406 will be described relative to FIGS. 5-7. After block 406, the method 400 ends.

[0168] FIG. 5 is a flow diagram illustrating an example method 500 for detecting and mitigating DKA risk in real-time, according to certain embodiments disclosed herein. The method 500 may be performed, for example, during the block 406 of FIG. 4. For illustrative purposes, the method 500 will be described as being performed by the therapy management engine 114 of FIGS.1-3.

[0169] At block 502, the therapy management engine 114 receives input data for a patient. The input data can include, for example, the runtime data and / or the configuration inputs discussed above relative to the method 400.

[0170] At block 504, the therapy management engine 114 evaluates criteria associated with DKA using the input data. In certain aspects, the therapy management engine 114 can execute personalized DKA risk detection by evaluating DKA risk criteria, for example, based on data input types selected by the patient, as will be discussed in greater detail relative to FIG. 7. In some aspects, the DKA risk criteria can be adaptive to time or dynamic conditions. For example, different risk criteria can be applicable for times of day, during various activities, etc. In addition, or alternatively, the DKA risk criteria may change over time and / or can be dynamically adjusted over time (e.g., using machine learning algorithms).

[0171] In certain aspects, the DKA risk criteria can relate to CGM data, such as glucose measurements generated by the continuous analyte monitoring system 104 and / or data derived therefrom (e.g., the glucose-related metrics 130). An example of applying DKA risk criteria to CGM data will be described relative to FIG. 6.

[0172] In certain aspects, the DKA risk criteria can relate to a combination of CGM data and other available data about a patient, such as other runtime data and / or one or one or more configuration inputs, as discussed above relative to the method 400. In an example, the DKA riskDexcom Ref. No.: 0960-PCT01criteria can relate to a combination of CGM data and insulin data, for example, from an insulin pump, smart pen, and / or user data entry. In another example, the DKA risk criteria can relate to a combination of CGM data and demographic data and / or anthropomorphic data as discussed above. An example of applying DKA risk criteria to a combination of CGM data and other available data about a patient will be described relative to FIG. 7.

[0173] At decision block 506, the therapy management engine 114 determines whether the DKA risk criteria is satisfied. If therapy management engine 114 determines that the DKA risk criteria is not satisfied, the method 500 ends. However, if the therapy management engine determines that the DKA risk criteria is satisfied, at block 508, the therapy management engine detects a risk of DKA for the patient. In general, the detection can correspond to an identification of an elevated risk based on the satisfaction of the criteria. In addition, or alternatively, the detection can include determining or predicting a likelihood that the patient is experiencing (or will experience) DKA, a presence and / or severity of DKA experienced (or that will be experienced) by the patient, a time period during which DKA is predicted to occur, etc., as discussed above relative to FIG. 4.

[0174] At block 510, in some aspects, the therapy management engine 114 determines a root cause for the detected risk of DKA. In certain aspects, the block 510 can include evaluating insulin delivery root causes using, for example, heuristics or rules. In an example, if insulin on board is less than a first predetermined threshold, and a time-average insulin on board over a predetermined period is less than a second predetermined threshold, insulin delivery may be determined as a root cause of the detected risk. In some aspects, the first and second predetermined thresholds may be the same. In another example, if insulin on board is greater than a first predetermined threshold and at least one glucose measurement (e.g., an average of glucose measurements over the last 10 minutes, 30 minutes, one hour, or other predetermined period) are greater than a second predetermined threshold, a root cause of the detected risk may be determined to be insulin integrity or insulin delivery device integrity (e.g., pump integrity).

[0175] In certain aspects, the block 510 can include evaluating illness or other possible root causes using, for example, heuristics or rules. In an example, if a temperature is greater than a predetermined threshold, illness may be determined to be a root cause. In another example, anDexcom Ref. No.: 0960-PCT01absence of any determined root causes may be determined to be a hydration root cause (i.e., dehydration).

[0176] In some aspects, the block 510 can include evaluating root causes from metabolic state estimates (e.g., posterior likelihoods from Kalman filter residuals).

[0177] In some aspects, the block 510 can include identifying an insulin delivery root cause based on a detected fault in an insulin delivery system or a detected fault in a monitoring system. The fault can be detected as described, for example, in U.S. Patent No. 11, 311,665. U.S. Patent No. 11, 311,665 is hereby incorporated by reference.

[0178] At block 512, in some aspects, the therapy management engine 114 determines a mitigation for the root cause determined at the block 510. In certain aspects, the determined mitigation can be a recommendation based on the determined root cause. In an example, if insulin delivery is determined to be a root cause, the recommendation can be to dose insulin. In another example, if insulin integrity or insulin delivery device integrity (e.g., pump integrity) is determined to be a root cause, the recommendation can be to check an expiration date of insulin, to use a fresh or different insulin, and / or or to check insulin equipment (e.g., integrity of pump or infusion set). In another example, if illness is determined to be a root cause, the recommendation can be to seek medical treatment. In another example, if dehydration is determined to be a root cause, or if there is no other determined root cause, the recommendation can be to drink fluids (e.g., water). In addition, for any root cause, the recommendation can further include a recommendation to test ketones.

[0179] In certain aspects the determined mitigation can be a recommendation for education based on the determined root cause. In an example, if insulin delivery is determined to be a root cause, the recommendation can be for education related to insulin dosing, insulin expiration, and / or an integrity of a pump or infusion set. In another example, if hydration is determined to be a root cause, or if there is no other determined root cause, the recommendation can be for education related to the importance of hydration. In another example, for any root cause, the recommendation can be for education related to testing ketones and / or the dangers of DKA.

[0180] At block 514, in some aspects, the therapy management engine 114 alerts the patient of the detected risk of DKA, the determined root cause, and / or the determined mitigation, forDexcom Ref. No.: 0960-PCT01example, on the display device 107 of FIG. 1. The block 514 can include, for example, presenting the detecting risk from the block 508, the determined root cause from the block 510, and / or any mitigations determined at the block 512. In some cases, alert functionality can be configured by the patient. For example, in some aspects, the therapy management engine 114 can enable to the patient to choose to receive all alerts or to filter which alerts are received and / or how often they presented. In addition, or alternatively, the therapy management engine 114 can allow the patient to acknowledge that they have taken one or more steps to mitigate DKA risk, including any of the mitigations determined and presented by the therapy management engine 114. After block 514, the method 500 ends.

[0181] FIG. 6 is a flow diagram illustrating an example method 600 for detecting and mitigating DKA risk in real-time based on CGM data, according to certain embodiments disclosed herein. The method 600 may be performed, for example, during the block 406 of FIG. 4. For illustrative purposes, the method 600 will be described as being performed by the therapy management engine 114 of FIGS. 1-3.

[0182] At block 602, the therapy management engine 114 receives CGM data for a patient. The CGM data can include, for example, glucose measurements and glucose-related metrics 130, as discussed above relative to FIGS. 3 and 4.

[0183] At block 604, the therapy management engine 114 evaluates criteria associated with DKA using the CGM data. In an example, the DKA risk criteria can be satisfied if the CGM data satisfies a predetermined threshold glucose value for a predetermined threshold period of time (e.g., over 300 mg / dL for more than 2 hours). In addition, or alternatively, the DKA risk criteria can include predetermined thresholds or other criteria related, for example, to any of the glucose-related metrics 130 discussed relative to FIG. 3 (e.g., rate of change). In some aspects, the DKA risk criteria can be adaptive to time or dynamic conditions. For example, the predetermined glucose threshold and / or period of time can be different for various times of day, activities, etc. In addition, or alternatively, the predetermined glucose threshold and / or period of time may change over time and / or can be dynamically adjusted over time (e.g., using machine learning algorithms). In some aspects, the DKA risk criteria can include multiple levels of risk criteria corresponding to multiple severity levels of DKA risk (e.g., thresholds that vary or increase a threshold glucose value and / or a threshold period of time).Dexcom Ref. No.: 0960-PCT01

[0184] At decision block 606, the therapy management engine 114 determines whether the DKA risk criteria is satisfied. If therapy management engine 114 determines that the DKA risk criteria is not satisfied, the method 600 ends. However, if the therapy management engine determines that the DKA risk criteria is satisfied, at block 608, the therapy management engine detects a risk of DKA for the patient. In general, the detection can correspond to an identification of an elevated risk based on the satisfaction of the criteria. In addition, or alternatively, the detection can include determining or predicting a likelihood that the patient is experiencing (or will experience) DKA, a presence and / or severity of DKA experienced (or that will be experienced) by the patient, a time period during which DKA is predicted to occur, etc., as discussed above relative to FIG. 4.

[0185] In general, blocks 610, 612, and 614 can execute as described relative to blocks 510, 512, and 514 of FIG. 5, respectively. After block 614, the method 500 ends.

[0186] FIG. 7 is a flow diagram illustrating an example method 700 for detecting and mitigating DKA risk based on CGM data in combination with other data about a patient, according to certain embodiments disclosed herein. The method 700 may be performed, for example, during the block 406 of FIG. 4. For illustrative purposes, the method 700 will be described as being performed by the therapy management engine 114 of FIGS. 1-3.

[0187] The method 700 includes a configuration process 700A, a DKA risk-detection process 700B, a root-cause determination process 700C, and a mitigation-determination process 700D. In general, the configuration process 700A can be executed upon initiation of DKA risk detection and / or as needed. The DKA risk-detection process 700B can be executed at any suitable interval, such as continuously. In general, the root-cause determination process 700C and the mitigationdetermination process 700D can be executed for each DKA risk detected during an iteration of the DKA risk-detection process 700B.

[0188] With reference to the configuration process 700A, at block 702A, the therapy management engine 114 receives, from the patient, a selection of input types to use for DKA risk prediction. In various aspects, the selection can include CGM data, any other runtime inputs discussed above (e.g., relative to FIG. 4), and / or any configuration inputs discussed above relative to FIG. 4.Dexcom Ref. No.: 0960-PCT01

[0189] In certain aspects, the patient can select “CGM-only,” in which case DKA risk may be predicted or detected based only on CGM data without further consideration of other runtime inputs or configuration inputs (e.g., according to the method 600 of FIG. 6).

[0190] In certain aspects, the patient can select to provide additional data, or configuration inputs, to personalize (or further personalize) DKA risk detection. In various cases, any of the configuration inputs can be provided, for example, as discussed relative to the inputs 128 of FIG.3. For example, the patient can select to include, as part of the configuration inputs, demographic and anthropomorphic data (e.g. body weight, height, BMI, diagnoses, ethnicity, location). In certain aspects, demographic and anthropomorphic data can provide additional resolving power for prediction or detection of DKA risk via individualized regressors and individualized prediction thresholds based on “fixed” biometric data, such as height and weight. In an example, the therapy management engine 114 can leverage regression (e.g., logistic regression) from ketone data collected from diverse populations of persons with diabetes under the condition of sustained hyperglycemia with individualized regressors and individualized prediction thresholds based on body weight and BMI.

[0191] In certain aspects, the patient can select to include, as part of the configuration inputs, medication information. In an example, the medication information can be used to a identify presence of complicating drug interactions, e.g. SGLT2-I or other less impactful drugs that promote euglycemic DKA (e.g., steroids). In addition, or alternatively, the medication information can be used to identify the presence of a relevant co-morbidity (e.g., deducing hypertension from a medication used to treat that condition).

[0192] In certain aspects, the patient can select to include, as part of the configuration inputs, lab work from an EMR. In certain aspects, lab work can provide additional resolving power for DKA risk prediction from prior exposure to DKA, presence of infection, and / or the like. In some cases, the lab work may be used by the therapy management engine 114 to modify DKA risk detection (e.g., thresholds used to detect DKA).

[0193] In certain aspects, the patient can select to include, as part of the configuration inputs, user-reported lifestyle regimen. The user-reported lifestyle regimen can include, for example, diet, exercise, etc. In addition, or alternatively, the user-reported lifestyle regiment can include plannedDexcom Ref. No.: 0960-PCT01activities that are metabolically relevant, such as fasting periods, activities that may limit access to insulin, long hikes in the desert, etc.

[0194] In addition, or alternatively, the patient can select to include additional runtime data (e.g., in addition to CGM data) to personalize (or further personalize) DKA risk detection. In an example, the patient can select to include, as part of the additional selected runtime data, insulin delivery data (e.g., from a connected insulin pump or smart pen or from a runtime user indication). In another example, the patient can select to include, as part of the additional selected runtime data, body temperature, for example, from a connected core or skin temperature measurement device (e.g., including mounted on or within the continuous analyte monitoring system 104) or from a runtime user indication. In various aspects, the therapy management engine 114 can use body temperature for detection of infection and, in some cases, the use of the same to modify thresholds or other criteria for detecting DKA risk. In addition, or alternatively, the patient can select to include, as part of the additional selected runtime data, runtime user indications regarding meals, symptoms, actions (e.g., actions taken to mitigate DKA risk). In addition, or alternatively, the patient can select to include, as part of the additional selected runtime data, runtime medication or pharmacy information (e.g., from EMRs).

[0195] Still with reference to the configuration process 700A, at block 704A, the therapy management engine 114 receives from the patient (e.g., via the display device 107 of FIG. 1), and stores, any configuration input selections at the block 702A. For example, the block 704A can include the therapy management engine 114 allowing for entry of demographic and anthropomorphic data, prescription data, user-reported lifestyle regimen, and / or lab work from health records.

[0196] At block 706A, the therapy management engine 114 receives from the patient (e.g., via the display device 107 of FIG. 1), and stores, any output settings for alerts. The output settings can correspond, for example, to any of the filters or options discussed relative to the block 514 of FIG.5. The block 706A can include, for example, allowing for entry of the output settings.

[0197] At block 708A, the therapy management engine 114 initializes DKA detection settings and criteria, such as a discriminant function and prediction thresholds. For example, in the case of CGM data, the therapy management engine 114 can establish a glucose threshold and a threshold period of time. In addition, or alternatively, the therapy management engine 114 can use formulasDexcom Ref. No.: 0960-PCT01and / or lookup tables to initialize discriminant function parameters and prediction thresholds to optimize a trade-off between sensitivity and specificity tradeoff as a function of the provided data. In various aspects, parameters that may impact this trade-off can include, for example, insulin injection type (e.g., pen, pump), total daily insulin amount, demographic information (e.g., sex, age, etc.), anthropomorphic information, historical CGM characteristic data, temperature data, heart rate data, combinations of the foregoing and / or the like.

[0198] In certain aspects, the DKA risk-detection process 700B can be executed by the therapy management engine 114 according to information and data established during the configuration process 700A. As noted previously, the DKA risk-detection process 700B can be executed at any desired frequency, such as continuously. In certain aspects, the DKA risk-detection process 700B can be executed as part of the block 406 of FIG. 4.

[0199] At block 702B, the therapy management engine 114 receives runtime data for the patient, for example, corresponding to the patient-selected runtime inputs during the configuration process 700A. In various cases, the block 702B can include, for example, receiving CGM data, insulin delivery data, body temperature, etc. In some aspects, the block 702B can include receiving runtime user indications via, for example, the display device 107 of FIG. 1. Such runtime user indications can include, for example, insulin delivery, ketone measurements, body temperature, meals, DKA symptoms, etc. In addition, or alternatively, the block 702B can include, for example, receiving data from third party application programming interfaces (APIs) regarding updated demographic and anthropomorphic data, prescription data, user-reported lifestyle regimen, and / or lab work from health records.

[0200] At block 704B, the therapy management engine 114 evaluates DKA risk criteria, such as a discriminant functions used for DKA risk detection, using the received runtime data. For example, the therapy management engine 114 can test whether the discriminant function exceeds a predetermined DKA risk threshold. The block 704B can include, for example, evaluating regression and logistic regression formulas. In some cases, the block 704B can include estimating metabolic states from underlying physiological models. In certain aspects, the therapy management engine 114 can comb the regression (e.g., logistic regression) formulas and any estimated states to evaluate the discriminant function.Dexcom Ref. No.: 0960-PCT01

[0201] At decision block 706B, the therapy management engine 114 detects a risk of DKA if, for example, the discriminant function exceeds the predetermined DKA risk threshold. In various aspects, in response to a detected risk of DKA, the therapy management engine 114 can trigger execution of the root-cause determination process 700C and the mitigation-determination process 700D. In certain aspects, the root-cause determination process 700C and the mitigationdetermination process 700D can be executed as part of the block 406 of FIG. 4. In general, the root-cause determination process 700C and the mitigation-determination process 700D can execute as described relative to the blocks 510 and 512 of FIG. 5, respectively.

[0202] FIG. 8 illustrates a receiver operating characteristic (ROC) curve for an example in which logistic regression is based only on CGM data, according to certain embodiments disclosed herein.

[0203] FIG. 9 illustrates an ROC curve for an example in which logistic regression is based on CGM data in combination with weight and age data, according to certain embodiments disclosed herein. In the example of FIG. 9, a higher score (.734) is achieved as compared to the CGM-data-only example of FIG. 8.

[0204] FIG. 10 illustrates an ROC curve for an example in which DKA risk detection utilizes CGM data in combination with total daily insulin (TDI), according to certain embodiments disclosed herein. In the example of FIG. 10, a higher score (.79) is achieved as compared to the examples of FIG. 8 and 9.

[0205] Although certain combinations of runtime inputs and configuration inputs are described above for illustrative purposes, it should be appreciated that many different combinations are possible including, for example: (1) only CGM data; (2) CGM data plus age and weight biometrics; (3) CGM data plus insulin delivery data; (4) CGM data plus body temperature; (5) CGM data plus inferred or user-reported data regarding meals; (6) CGM data plus user- reported symptoms; (7) CGM data plus user-reported actions (e.g. mitigation actions); and (8) CGM data plus medication or pharmacy information. Other combinations may also be utilized without deviating from the principles described herein.

[0206] FIGS. 11A-C illustrate examples of evaluating DKA risk, in accordance with certain embodiments of the present disclosure. With reference to FIG. 11 A, a risk of DKA occurring mayDexcom Ref. No.: 0960-PCT01be observed as lagging behind both insulin on board and glucose levels. In particular, in the example of FIG. 11 A, glucose levels arc well above 250 mg / dL within 60 minutes after insulin is withdrawn, with ketone levels lagging behind the glucose levels. In addition, the insulin concentration shown in FIG. 1 IB demonstrates that insulin on board is also slow to decline. In fact, by the time ketones are elevated significantly, the insulin concentration is still above 7 uM / mL.

[0207] In certain aspects, an insulin on board calculation and glucose levels may be used together to impute a relative risk at an individual level, with rates of decline of insulin on board plus rates of glucose increase determining a risk profile of the patient to enter into DKA. In an example, for patients with sufficient insulin on board and low glucose, the DKA risk would be low. In another example, for patients with high glucose but sufficient insulin on board, the DKA risk would be moderate. In another example, for patients with high glucose plus low and still declining insulin on board, the DKA risk would be very high.

[0208] In addition, in certain aspects, the therapy management engine 114 may detect that, upon treatment of DKA with insulin, a risk of the patient to re-enter DKA is much lower than ketone levels demonstrate, as illustrated in FIG. 11C. According to the example of FIG. 11C, it may take over 48 hours to return to baseline ketone levels; however, the patient’s DKA risk by this time is very low since they have had sufficient insulin on board for over two days. Therefore, in certain aspects, the therapy management engine 114 can use a combination of glucose concentrations and historic insulin on board to calculate a safe range that includes an anticipation of the relative risk dropping within hours of the addition of sufficient insulin to return the patient’s glucose levels to normal range and insulin concentration, regardless of ketone levels in the blood.

[0209] FIG. 12 is a block diagram depicting a computing device 1200 configured for DKA detection and mitigation, according to certain embodiments disclosed herein. Although depicted as a single physical device, in embodiments, the computing device 1200 may be implemented using virtual device(s), and / or across a number of devices, such as in a cloud environment. As illustrated, the computing device 1200 includes a processor 1205, a memory 1210, a storage 1215, a network interface 1225, and one or more VO interfaces 1220. In the illustrated embodiment, the processor 1205 retrieves and executes programming instructions stored in the memory 1210, as well as stores and retrieves application data residing in the storage 1215. The processor 1205 isDexcom Ref. No.: 0960-PCT01generally 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.

[0210] The memory 1210 is generally included to be representative of a random access memory (RAM). The storage 1215 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, memory modules, removable memory cards, embedded memory, on-die memory, caches, optical storage, network attached storage (NAS), or storage area networks (SAN).

[0211] In some embodiments, the I / O devices 1235 (such as keyboards, monitors, etc.) can be connected via the I / O interface(s) 1220. Further, via the network interface 1225, the computing device 1200 can be communicatively coupled with one or more other devices and components, such as the user database 110 and / or the historical records database 112. In certain embodiments, the computing device 1200 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 1205, memory 1210, storage 1215, network interface(s) 1225, and the I / O interface(s) 1220 are communicatively coupled by one or more interconnects 1230. In certain embodiments, the computing device 1200 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 computing device 1200 is a server executing in a cloud environment.

[0212] In the illustrated embodiment, the storage 1215 includes the user profile 118. The memory 1210 includes the therapy management engine 114, which itself includes the DAM 116. The therapy management engine 114 is executed by the computing device 1200 to perform operations in the method 400 of FIG. 4, the method 500 of FIG. 5, the method 600 of FIG. 6, and / or the method 700 of FIG. 7.Example Clauses

[0213] Clause 1 : A system for mitigating diabetic ketoacidosis (DKA) risk for a patient in realtime, comprising: a continuous glucose monitoring (CGM) system configured to generate one or more glucose measurements associated with a current glucose level of a patient over a period; oneDexcom Ref. No.: 0960-PCT01or 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 glucose measurements for the patient from the CGM system; receive insulin data for the patient; evaluate criteria associated with DKA using first information related to the glucose measurements and second information related to the insulin data; detect a risk of DKA for the patient responsive to a combination of the first information and the second information satisfying the criteria associated with DKA; and alert the patient based on the detected risk.

[0214] Clause 2: The system of Clause 1, wherein the criteria associated with DKA is based on at least one configuration input previously received from the patient.

[0215] Clause 3: The system of Clause 1, further comprising determining a root cause for the detected risk of DKA based, at least in part, on information related to the insulin data, wherein the alerting comprises presenting information related to the determined root cause.

[0216] Clause 4: The system of Clause 3, wherein the determination comprises, responsive to determinations that insulin board is less than a first predetermined threshold and that a timeaverage insulin on board over a predetermined period is less than a second predetermined threshold, determining the root cause to be insulin delivery.

[0217] Clause 5: The system of Clause 3, wherein the determination comprises, responsive to determinations that insulin on board is greater than a first predetermined threshold and that at least one glucose measurement is greater than a second predetermined threshold, determining the root cause to be at least one of insulin integrity or insulin delivery device integrity.

[0218] Clause 6: The system of Clause 4, wherein the one or more processors are further configured to execute the executable instructions to receive a body temperature from a temperature sensor associated with the patient, wherein the determination of the root cause comprises evaluating illness of the patient based on the body temperature.

[0219] Clause 7: The system of Clause 4 wherein the one or more processors are further configured to execute the executable instructions to determine a mitigation for the determined root cause, wherein the alerting comprises presenting information related to the determined mitigation.

[0220] Clause 8: The system of Clause 7, wherein, responsive to a determination that insulin delivery is the root cause, the determined mitigation comprises a recommendation to dose insulin.Dexcom Ref. No.: 0960-PCT01

[0221] Clause 9: The system of Clause 7, wherein, responsive to a determination that at least one of insulin integrity or insulin delivery device integrity is the root cause, the determined mitigation comprises at least one of the following: a recommendation for the patient to check an insulin expiration date; a recommendation for the patient to use a different insulin; or a recommendation for the patient to check insulin equipment.

[0222] Clause 10: The system of Clause 7, wherein the determined mitigation comprises a recommendation for the patient to test ketones.

[0223] Clause 11: The system of Clause 1, wherein the detection comprises testing whether a discriminant function exceeds a predetermined DKA risk threshold.

[0224] Clause 12: The system of Clause 11, wherein: the discriminant function is initialized based, at least in part, on at least one of demographic information or anthropomorphic information associated with the patient; and the testing comprises evaluating a regression formula based on ketone data collected from a population of persons.

[0225] Clause 13: The system of Clause 1, wherein the criteria associated with DKA comprise a requirement that the glucose measurements exceed a predetermined threshold for more than a predetermined period of time.

[0226] Clause 14: The system of Clause 1, wherein the insulin data is received from an insulin delivery device.

[0227] Clause 15: A method of mitigating diabetic ketoacidosis (DKA) risk for a patient in real-time, the method comprising, by one or more processors: receiving glucose measurements for the patient from a continuous glucose monitoring (CGM) system; receiving insulin data for the patient from an insulin delivery device; evaluating criteria associated with DKA using first information related to the glucose measurements and second information related to the insulin data; detecting a risk of DKA for the patient responsive to a combination of the first information and the second information satisfying the criteria associated with DKA; and alerting the patient based on the detected risk.Additional Considerations

[0228] The methods disclosed herein comprise one or more steps or actions for achieving the methods. The method steps and / or actions may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps or actions is specified,Dexcom Ref. No.: 0960-PCT01the order and / or use of specific steps and / or actions may be modified without departing from the scope of the claims.

[0229] As used herein, a phrase referring to “at least one of’ a list of items refers to any combination of those items, including single members. As an example, “at least one of: a, b, or c” is intended to cover a, b, c, a-b, a-c, b-c, and a-b-c, as well as any combination with multiples of the same element (e.g., a-a, a-a-a, a-a-b, a-a-c, a-b-b, a-b-c, b-b, b-b-b, b-b-c, c-c, and c-c-c or any other ordering of a, b, and c).

[0230] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language of the claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” Unless specifically stated otherwise, the term “some” refers to one or more. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. No claim element is to be construed under the provisions of 35 U.S.C. § 112(f) unless the element is expressly recited using the phrase “means for” or, in the case of a method claim, the element is recited using the phrase “step for.”

[0231] While various examples of the invention have been described above, it should be understood that they have been presented by way of example only, and not by way of limitation. Likewise, the various diagrams may depict an example architectural or other configuration for the disclosure, which is done to aid in understanding the features and functionality that can be included in the disclosure. The disclosure is not restricted to the illustrated example architectures or configurations, but can be implemented using a variety of alternative architectures and configurations. Additionally, although the disclosure is described above in terms of various example examples and aspects, it should be understood that the various features and functionality described in one or more of the individual examples are not limited in their applicability to theDexcom Ref. No.: 0960-PCT01particular example with which they are described. They instead can be applied, alone or in some combination, to one or more of the other examples of the disclosure, whether or not such examples are described, and whether or not such features are presented as being a part of a described example. Thus the breadth and scope of the present disclosure should not be limited by any of the above-described example examples.

[0232] All references cited herein are incorporated herein by reference in their entirety. To the extent publications and patents or patent applications incorporated by reference contradict the disclosure contained in the specification, the specification is intended to supersede and / or take precedence over any such contradictory material.

[0233] Unless otherwise defined, all terms (including technical and scientific terms) are to be given their ordinary and customary meaning to a person of ordinary skill in the art, and are not to be limited to a special or customized meaning unless expressly so defined herein.

[0234] Terms and phrases used in this application, and variations thereof, especially in the appended claims, unless otherwise expressly stated, should be construed as open ended as opposed to limiting. As examples of the foregoing, the term ‘including’ should be read to mean ‘including, without limitation,’ ‘including but not limited to,’ or the like; the term ‘comprising’ as used herein is synonymous with ‘including,’ ‘containing,’ or ‘characterized by,’ and is inclusive or open-ended and does not exclude additional, unrecited elements or method steps; the term ‘having’ should be interpreted as ‘having at least;’ the term ‘includes’ should be interpreted as ‘includes but is not limited to;’ the term ‘example’ is used to provide example instances of the item in discussion, not an exhaustive or limiting list thereof; adjectives such as ‘known’, ‘normal’, ‘standard’, and terms of similar meaning should not be construed as limiting the item described to a given time period or to an item available as of a given time, but instead should be read to encompass known, normal, or standard technologies that may be available or known now or at any time in the future; and use of terms like ‘preferably,’ ‘preferred,’ ‘desired,’ or ‘desirable,’ and words of similar meaning should not be understood as implying that certain features are critical, essential, or even important to the structure or function of the invention, but instead as merely intended to highlight alternative or additional features that may or may not be utilized in a particular example of the invention. Likewise, a group of items linked with the conjunction ‘and’ should not be read as requiring that each and every one of those items be present in the grouping, but rather should be read as ‘and / or’Dexcom Ref. No.: 0960-PCT01unless expressly stated otherwise. Similarly, a group of items linked with the conjunction ‘or’ should not be read as requiring mutual exclusivity among that group, but rather should be read as ‘and / or’ unless expressly stated otherwise.

[0235] The term “comprising as used herein is synonymous with “including,” “containing,” or “characterized by” and is inclusive or open-ended and does not exclude additional, unrecited elements or method steps.

[0236] All numbers expressing quantities of ingredients, reaction conditions, and so forth used in the specification are to be understood as being modified in all instances by the term ‘about.’ Accordingly, unless indicated to the contrary, the numerical parameters set forth herein are approximations that may vary depending upon the desired properties sought to be obtained. At the very least, and not as an attempt to limit the application of the doctrine of equivalents to the scope of any claims in any application claiming priority to the present application, each numerical parameter should be construed in light of the number of significant digits and ordinary rounding approaches.

[0237] Furthermore, although the foregoing has been described in some detail by way of illustrations and examples for purposes of clarity and understanding, it is apparent to those skilled in the art that certain changes and modifications may be practiced. Therefore, the description and examples should not be construed as limiting the scope of the invention to the specific examples and examples described herein, but rather to also cover all modification and alternatives coming with the true scope and spirit of the invention.

Claims

Dexcom Ref. No.: 0960-PCT01CLAIMS1. A system for mitigating diabetic ketoacidosis (DKA) risk for a patient in real-time, comprising:a continuous glucose monitoring (CGM) system configured to generate one or more glucose measurements associated with a current glucose level of a patient over a period;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 glucose measurements for the patient from the CGM system;receive insulin data for the patient;evaluate criteria associated with DKA using first information related to the glucose measurements and second information related to the insulin data;detect a risk of DKA for the patient responsive to a combination of the first information and the second information satisfying the criteria associated with DKA; andalert the patient based on the detected risk.

2. The system of claim 1 , wherein the criteria associated with DKA is based on at least one configuration input previously received from the patient.

3. The system of claim 1, further comprising determining a root cause for the detected risk of DKA based, at least in part, on information related to the insulin data, wherein the alerting comprises presenting information related to the determined root cause.

4. The system of claim 3, wherein the determination of the root cause comprises evaluating one or more insulin delivery root causes.

5. The system of claim 3, wherein the determination comprises, responsive to determinations that insulin board is less than a first predetermined threshold and that a time-average insulin on board over a predetermined period is less than a second predetermined threshold, determining the root cause to be insulin delivery.

6. The system of claim 3, wherein the determination comprises, responsive to determinations that insulin on board is greater than a first predetermined threshold and that at least oneDexcom Ref. No.: 0960-PCT01glucose measurement is greater than a second predetermined threshold, determining the root cause to be at least one of insulin integrity or insulin delivery device integrity.

7. The system of claim 4, wherein the determination of the root cause comprises evaluating one or more root causes from one or more metabolic state estimates for the patient.

8. The system of claim 4, wherein the one or more processors are further configured to execute the executable instructions to receive a body temperature from a temperature sensor associated with the patient, wherein the determination of the root cause comprises evaluating illness of the patient based on the body temperature.

9. The system of claim 4, wherein the determination comprises determining the root cause to be dehydration responsive to determining an absence of a plurality of other root causes.

10. The system of claim 4 wherein the one or more processors are further configured to execute the executable instructions to determine a mitigation for the determined root cause, wherein the alerting comprises presenting information related to the determined mitigation.

11. The system of claim 10, wherein, responsive to a determination that insulin delivery is the root cause, the determined mitigation comprises a recommendation to dose insulin.

12. The system of claim 10, wherein, responsive to a determination that at least one of insulin integrity or insulin delivery device integrity is the root cause, the determined mitigation comprises at least one of the following:a recommendation for the patient to check an insulin expiration date;a recommendation for the patient to use a different insulin; ora recommendation for the patient to check insulin equipment.

13. The system of claim 10, wherein, responsive to a determination that illness is the root cause, the determined mitigation comprises a recommendation for the patient to seek medical treatment.

14. The system of claim 10, wherein, responsive to a determination that dehydration is the root cause, the determined mitigation comprises a recommendation for the patient to drink fluids.Dexcom Ref. No.: 0960-PCT0115. The system of claim 10, wherein the determined mitigation comprises a recommendation for the patient to test ketones.

16. The system of claim 10, wherein the determined mitigation comprises a recommendation for education based on the determined root cause.

17. The system of claim 1, wherein the detection comprises testing whether a discriminant function exceeds a predetermined DKA risk threshold.

18. The system of claim 17, wherein the discriminant function is initialized based, at least in part, on at least one of demographic information or anthropomorphic information associated with the patient.

19. The system of claim 18, wherein the testing comprises evaluating a regression formula based on ketone data collected from a population of persons.

20. The system of claim 1 , wherein the criteria associated with DKA comprise a requirement that the glucose measurements exceed a predetermined threshold for more than a predetermined period of time.

21. The system of claim 1, wherein the insulin data is received from an insulin delivery device.

22. A method of mitigating diabetic ketoacidosis (DKA) risk for a patient in real-time, the method comprising, by one or more processors:receiving glucose measurements for the patient from a continuous glucose monitoring (CGM) system;receiving insulin data for the patient from an insulin delivery device;evaluating criteria associated with DKA using first information related to the glucose measurements and second information related to the insuslin data;detecting a risk of DKA for the patient responsive to a combination of the first information and the second information satisfying the criteria associated with DKA; andalerting the patient based on the detected risk.Dexcom Ref. No.: 0960-PCT0123. The method of claim 22, wherein the criteria associated with DKA is based on at least one configuration input previously received from the patient.

24. The method of claim 22, fur ther comprising determining a root cause for the detected risk of DKA based, at least in part, on information related to the insulin data, wherein the alerting comprises presenting information related to the determined root cause.

25. The method of claim 24, wherein the determining the root cause comprises evaluating one or more insulin delivery root causes.

26. The method of claim 24, wherein the determining comprises, responsive to determinations that insulin board is less than a first predetermined threshold and that a time-average insulin on board over a predetermined period is less than a second predetermined threshold, determining the root cause to be insulin delivery.

27. The method of claim 24, wherein the determining comprises, responsive to determinations that insulin on board is greater than a first predetermined threshold and that at least one glucose measurement is greater than a second predetermined threshold, determining the root cause to be at least one of insulin integrity or insulin delivery device integrity.

28. The method of claim 25, wherein the determining the root cause comprises evaluating one or more root causes from one or more metabolic state estimates for the patient.

29. The method of claim 25, further comprising receiving a body temperature from a temperature sensor associated with the patient, wherein the determining the root cause comprises evaluating illness of the patient based on the body temperature.

30. The method of claim 25, wherein the determining the root cause comprises determining the root cause to be dehydration responsive to determining an absence of a plurality of other root causes.

31. The method of claim 25, further comprising determining a mitigation for the determined root cause, wherein the alerting comprises presenting information related to the determined mitigation.Dexcom Ref. No.: 0960-PCT0132. The method of claim 31, wherein, responsive to a determination that insulin delivery is the root cause, the determined mitigation comprises a recommendation to dose insulin.

33. The method of claim 31, wherein, responsive to a determination that at least one of insulin integrity or insulin delivery device integrity is the root cause, the determined mitigation comprises at least one of the following:a recommendation for the patient to check an insulin expiration date;a recommendation for the patient to use a different insulin; ora recommendation for the patient to check insulin equipment.

34. The method of claim 31, wherein, responsive to a determination that illness is the root cause, the determined mitigation comprises a recommendation for the patient to seek medical treatment.

35. The method of claim 31, wherein, responsive to a determination that dehydration is the root cause, the determined mitigation comprises a recommendation for the patient to drink fluids.

36. The method of claim 31, wherein the determined mitigation comprises a recommendation for the patient to test ketones.

37. The method of claim 31, wherein the determined mitigation comprises a recommendation for education based on the determined root cause.

38. The method of claim 22, wherein the detecting comprises testing whether a discriminant function exceeds a predetermined DKA risk threshold.

39. The method of claim 38, wherein the discriminant function is initialized based, at least in part, on at least one of demographic information or anthropomorphic information associated with the patient.

40. The method of claim 39, wherein the testing comprises evaluating a regression formula based on ketone data collected from a population of persons.Dexcom Ref. No.: 0960-PCT0141. The method of claim 22, wherein the criteria associated with DKA comprise a requirement that the glucose measurements exceed a predetermined threshold for more than a predetermined period of time.

42. The method of claim 22, wherein the insulin data is received from an insulin delivery device.

43. A system for mitigating diabetic ketoacidosis (DKA) risk for a patient in real-time, comprising:a continuous glucose monitoring (CGM) system configured to generate one or more glucose measurements associated with a current glucose level of a patient over a period;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 glucose measurements for the patient from the CGM system;evaluate criteria associated with DKA using information related to the glucose measurements;detect a risk of DKA for the patient responsive to the information related to the glucose measurements satisfying the criteria associated with DKA; andalert the patient based on the detected risk.

44. The system of claim 43, wherein the criteria associated with DKA comprise a requirement that the glucose measurements exceed a predetermined threshold for more than a predetermined period of time.

45. The system of claim 43, wherein the criteria is evaluated based only on the information related to the glucose measurements.

46. The system of claim 43, wherein the criteria is evaluated based only on the information related to the glucose measurements responsive to a CGM-only selection from the patient.

47. The system of claim 43, wherein the criteria is evaluated based on the information related to the glucose measurements in combination with demographic information for the patient.Dexcom Ref. No.: 0960-PCT0148. A method of mitigating diabetic ketoacidosis (DKA) risk for a patient, the method comprising, by one or more processors:receiving glucose measurements for the patient from a continuous glucose monitoring (CGM) system;evaluating criteria associated with DKA using information related to the glucose measurements; detecting a risk of DKA for the patient responsive to the information related to the glucose measurements satisfying the criteria associated with DKA; andalerting the patient based on the detected risk.

49. The method of claim 48, wherein the criteria associated with DKA comprise a requirement that the glucose measurements exceed a predetermined threshold for more than a predetermined period of time.

50. The method of claim 48, wherein the criteria is evaluated based only on the information related to the glucose measurements.

51. The method of claim 48, wherein the criteria is evaluated based only on the information related to the glucose measurements responsive to a CGM-only selection from the patient.

52. The method of claim 48, wherein the criteria is evaluated based on the information related to the glucose measurements in combination with demographic information for the patient.

Images