Optimizing event identification by performing patient-specific analyte data transforms

Abstract

In an embodiment, a method of optimizing analyte event identification includes receiving, from a continuous analyte monitoring system, first analyte measurements determined for a patient during a first time period. The method also includes transforming the first analyte measurements into first relevance metrics that each indicate a probability of an occurrence of a defined analyte event during the first time period. The method also includes generating a personalized analyte signature for the patient for the first time period based on the first relevance metrics. The method also includes automatically identifying one or more analyte events for the patient based on an evaluation of additional analyte measurements determined for the patient relative to the personalized analyte signature for the patient.

Description

OPTIMIZING EVENT IDENTIFICATION BY PERFORMING PATIENT-SPECIFIC ANALYTE DATA TRANSFORMSCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to and benefit of U.S. Provisional Patent Application No. 63 / 701,049 filed September 30, 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. 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. Regulation of blood glucose levels depends on the production and use of insulin, which regulates the movement of blood glucose into cells.

[0003] 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 normal ranges. The state of having a higher than normal blood sugar level is called “hyperglycemia.” Chronic hyperglycemia can lead to several health problems, such as cardiovascular disease, cataract and other eye problems, nerve damage (neuropathy), and kidney damage. Hyperglycemia can also lead to acute problems, such as diabetic ketoacidosis - a state in which the body becomes excessively acidic due to the presence of blood glucose and ketones, which are produced when the body cannot use glucose. 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.

[0004] Blood sugar concentration levels may be monitored with an analyte sensor, such as a continuous glucose monitor. A continuous glucose monitor may provide the wearer (patient) with information such as an estimated blood glucose level, a trend of estimated blood glucose levels, etc.SUMMARY

[0005] In an embodiment, one general aspect includes a method of optimizing analyte event identification. The method includes receiving, from a continuous analyte monitoring system, first analyte measurements determined for a patient during a first time period. The method also includes transforming the first analyte measurements into first relevance metrics that each indicate a probability of an occurrence of a defined analyte event during the first time period. The method also includes generating a personalized analyte signature for the patient for the first time period based on the first relevance metrics. The method also includes automatically identifying one or more analyte events for the patient based on an evaluation of additional analyte measurements determined for the patient relative to the personalized analyte signature for the patient.

[0006] In an embodiment, another general aspect includes a system for optimizing analyte event identification. The system includes a continuous analyte monitoring system configured to generate measurements associated with an analyte level of a patient. The system also includes one or more memories that may include executable instructions. The system also includes one or more processors in data communication with the continuous analyte monitoring system and the one or more memories, the one or more processors configured to execute the executable instructions to receive, from the continuous analyte monitoring system, first analyte measurements determined for the patient during a first time period, and to transform the first analyte measurements into first relevance metrics that each indicate a probability of an occurrence of a defined analyte event during the first time period. The one or more processors are further configured to execute the executable instructions to generate a personalized analyte signature for the patient for the first time period based on the first relevance metrics, and to automatically identify one or more analyte events for the patient based on an evaluation of additional analyte measurements determined for the patient relative to the personalized analyte signature for the patient.

[0007] In an embodiment, another general aspect includes a computer-program product that may include a non-transitory computer-usable medium having computer-readable program code embodied therein. The computer-program product is adapted to be executed to implement a method. The method includes receiving, from a continuous analyte monitoring system, first analyte measurements determined for a patient during a first time period. The method also includes transforming the first analyte measurements into first relevance metrics that each indicate aprobability of an occurrence of a defined analyte event during the first time period. The method also includes generating a personalized analyte signature for the patient for the first time period based on the first relevance metrics. The method also includes automatically identifying one or more analyte events for the patient based on an evaluation of additional analyte measurements determined for the patient relative to the personalized analyte signature for the patient.BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

[0011] FIG. 3 illustrates an example of a process for generating a personalized glucose signature for a patient for a defined glucose event of interest, in accordance with certain embodiments.

[0012] FIG. 4 illustrates a graph of example glucose measurements of a patient, in accordance with certain embodiments.

[0013] FIG. 5A illustrates a graph of aggregated relevance metrics and a personalized glucose signature for a defined hyperglycemic event, in accordance with certain embodiments.

[0014] FIG. 5B illustrates a graph of the aggregated relevance metrics and the personalized glucose signature of FIG. 5A in relation to an upper and lower relevance thresholds, in accordance with certain embodiments.

[0015] FIG. 6A illustrates a graph of aggregated relevance metrics and a personalized glucose signature for a defined hypoglycemic event, in accordance with certain embodiments.

[0016] FIG. 6B illustrates a graph of the aggregated relevance metrics and the personalized glucose signature of FIG. 6A in relation to an upper relevance threshold and a lower relevance threshold, in accordance with certain embodiments.

[0017] FIG. 7 illustrates an example of a process for using a personalized glucose signature of a patient to retrospectively evaluate glucose measurements for a defined glucose event of interest, in accordance with certain embodiments.

[0018] FIG. 8A illustrates a graph of the glucose measurements shown in FIG. 4 together with new glucose measurements for a segment of a different day, in accordance with certain embodiments.

[0019] FIG. 8B illustrates a graph showing the new glucose measurements of FIG. 8A in relation to the personalized glucose signature of FIGS. 5A-B, in accordance with certain embodiments.

[0020] FIG. 8C illustrates a graph showing the new glucose measurements of FIG. 8A in relation to the personalized glucose signature of FIGS. 6A-B, in accordance with certain embodiments.

[0021] FIG. 9 illustrates an example of a process for using a personalized glucose signature of a patient to evaluate current glucose measurements for a defined glucose event of interest, in accordance with certain embodiments.

[0022] FIG. 10 is a block diagram depicting a computer system configured for optimized event identification, in accordance with certain embodiments.DETAILED DESCRIPTION

[0023] In a continuous analyte monitoring (CAM) system, an analyte sensor measures analyte levels of a patient and communicates the raw sensor measurements to a transmitter, which can then transmit corresponding analyte values to the patient's device (e.g., a display device such as a mobile phone). The patient can use their device to monitor the health and collect health data (e.g., analyte data). An example of a CAM system is a continuous glucose monitoring (CGM) system. For illustrative purposes, examples will be periodically described herein relative to CGM systems.

[0024] For example, patients with diabetes, as well as other patients, may use a CGM system to continuously measure their glucose levels. For a given patient, a display device (e.g., smartphone or smartwatch) may collect the measured glucose data from the CGM system and present reports based thereon. For example, the display device may provide a retrospective report containing graphs of the measured glucose data over an extended period of time such as a day,week, month, etc. The retrospective report may indicate, among other things, instances of high / low values based on standard thresholds defining hyperglycemia / hypoglycemia. In general, the retrospective report is intended to help the patient identify opportunities for improved glucose control in the future.

[0025] Current glucose reports show fluctuating glucose values for a patient over time and generally do not clearly indicate the relevance or significance of such glucose measurements for particular patients. Typical measurement units (e.g., mg / dL) do not provide any sense of relevance or significance beyond the measurement itself. Measurements that are “bad” for the patient may represent low-hanging fruit for further analysis to improve glucose control, but it is not necessarily self-apparent what measurements are “bad” for individual patients. In some instances, glucose measurements over a given period may be nominally low or high (e.g., based on a threshold), but they might not be significant for the patient. For example, a glucose measurement of 69 mg / dL may be considered low according to a hypoglycemic threshold of 70 mg / dL. However, the measurement may represent a typical morning reading for the patient that quickly improves according to their regular behavior, thus making it less notable and of less concern. In other instances, even if glucose measurements over a given period are not nominally low or high (e.g., based on a threshold), they might be significant for the patient. For example, a glucose measurement of 76 mg / dL may not be considered low according to a hypoglycemic threshold of 70 mg / dL. However, the measurement may represent a highly unusual nighttime reading for the patient that portends a possible hypoglycemic episode, thus making it more notable and of particular concern. A multitude of scenarios similar to these two scenarios may manifest over time. However, it is not feasible, using conventional systems methods, to automatically identify and distinguish these scenarios on a continual basis.

[0026] Furthermore, typical glucose reports may contain an abundance of events. Although occasional bumps and dips may be visible, it is difficult to identify important events of interest for the reasons explained above. The lack of clear indication of event significance makes it difficult to correlate patient behavior (e.g., meals, exercise, medication taken, insulin administered, etc.) with glucose measurements or events. For example, in a chart showing fluctuating glucose values over time, it is not necessarily apparent to the patient when an unusual meal or activity might have occurred. Problematically, the patient may not take any action in response to the provided data toimprove glucose control due to the burdensome nature of reviewing and interpreting so many unclear events.:

[0027] In response to the above problems, a therapy management system may be provided that facilitates improved glucose reporting and analysis, retrospectively and / or in real-time. More particularly, in certain aspects, the therapy management system can display glucose data in a manner that is illustrative of a patient-specific significance to a glucose event, such as hypoglycemia, hyperglycemia, or a custom or patient-defined event.

[0028] In an example, in certain aspects, the therapy management system can transform a patient’s glucose measurements into a relevance metric representing a probability that the corresponding glucose values are indicative of a predetermined glucose event. The predetermined glucose event may be a standardized clinical event, such as hypoglycemia or hyperglycemia, or a custom or patient-specific event (e.g., events defined in terms of custom or patient-specific thresholds). The relevance metric at a given time may signify, for example, a probability that the glucose value recorded for the patient at that time indicates the predetermined glucose event for the patient. The relevance metric may be provided at a predetermined scale (e.g., 0 to 1, 1 to 100, etc.), so that the meaning of individual values is clear.

[0029] In certain aspects, the therapy management system can generate a personalized glucose signature for the patient based on the patient’s transformed glucose measurements over a period (e.g., a week, month, etc.). The personalized glucose signature may be structured according to a modal day, with the transformed glucose measurements being aggregated by time of day. In certain aspects, the therapy management system can use the personalized glucose signature to retrospectively evaluate transformed glucose measurements for a period of interest (e.g., a day). For example, the therapy management system can identify significant glucose events based on deviations from the personalized glucose signature. In certain aspects, personalized, signaturebased evaluation of glucose events, as described herein, can enable a clearer and more definitive identification of behaviors that result in the significant glucose events.

[0030] In certain aspects, the therapy management system can use the personalized glucose signature to provide a filtered or highlighted view, for example, of only the most significant glucose events on a patient’s timeline. In certain aspects, the filtered view makes it easier for the patient to understand the provided information and also for the therapy management system and / orothers (e.g., the patient, the patient’s caregiver and / or healthcare personnel) to formulate guidance. More particularly, in certain aspects, the filtered or highlighted view can improve recommendations made to the patient, which the patient may follow, thereby improving the patient’s overall health.

[0031] In certain aspects, the therapy management system can use the personalized glucose signature to evaluate current glucose values in real-time. For example, the therapy management system can transform the current glucose measurements into relevance metrics, as discussed above, and determine their significance based on a comparison to the personalized glucose signature. In addition, or alternatively, the therapy management system can use characteristics associated with previously identified glucose events to identify similar glucose events in the future and warn of impending significant glucose events.

[0032] Advantageously, in certain implementations, the systems and methods described herein can generate data, such as personalized glucose signatures, relevance metrics and / or data or analysis based on the foregoing, that is better, clearer, and more personalized to the patient than the data of traditional glucose reports. This better and clearer data can enable more accurate identification of glucose events, more patient involvement in glucose control, and improved time in range. In addition, or alternatively, in certain implementations, the systems and methods described herein can result in more meaningful alerts to patients, since alerts can be based on significance relative to a personalized signature instead of standard thresholds that might not be meaningful for that patient.

[0033] As further advantages, in certain implementations, the systems and methods described herein can facilitate clearer and more definitive identification of significant glucose events as well as behaviors that result in significant glucose events, for example, due to providing a filtered or highlighted view of such events. This increase in the clarity of such events may increase a level of trust a patient has in the recommendations provided by the system identifying such events (such as diet, exercise, and medication recommendations), as well as a level of compliance by the patient with the recommendations, which may improve an overall health of the patient. In addition, in certain implementations, the systems and methods described herein can enable easier identification and tracking of the patient’s condition over time, for example, by updating and tracking the patient’s personalized glucose signature over time. Further, the systems and methods describedherein can facilitate improved and personalized treatment of patient, since treatment can be based on relevance metrics that are defined relative to personalized glucose signatures instead of standard treatment protocols that are not tailored to the nuances of the patient’s behaviors and glucose levels. In addition, or alternatively, the systems and methods described herein can provide a more stable baseline for evaluation, using the personalized signature, as compared to traditional evaluation of fluctuating glucose values.

[0034] As still further advantages, in certain implementations, the meaningfulness of real-time health alerts can be improved by alerting based on glucose events that are identified relative to a personalized signature. In addition, or alternatively, the systems and methods described herein can recommend treatment based on the glucose events. The personalized nature of event identification can increase patient engagement, which in turn can increases a likelihood that a patient follows the recommendations provided, thereby improving health of the patient.

[0035] As still further advantages, in certain implementations, the relevance of alerts communicated to patients can be increased by alerting based on personal relevance. For example, false positive / “false alarm” alerts based on measurements that are nominally high or low but not otherwise significant might be avoided, which can reduce resource consumption (e.g., battery power via screen and audio usage, etc.). Patient alarm fatigue may also be avoided by eliminating these false alarms.

[0036] As still further advantages, in certain implementations, the systems and methods described herein can recommend treatment, or initiate treatment, based on real-time relevance metrics relative to a personalized glucose signature, and / or based on glucose events identified relative to the personalized glucose signature, thereby further improving patient health.

[0037] Although certain examples are described below in relation to glucose levels, the embodiments herein are likewise applicable and useful for improved reporting and analysis in connection with other analyte levels (e.g., ketone levels, lactate levels, etc.).

[0038] 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 insights to be derived using the algorithms described herein for preventively treating hypoglycemia. In other words, single point-in-time measurements collected as a result ofa patient visiting their health care professional every few months results in sporadic data points (e g., that are, at best, months apart in timing) that cannot form the basis of any meaningful data or insight to be derived. As such, without the CAM system of the embodiments herein, it is simply impossible to continuously generate personalized glucose signatures, to continuously use the personalized glucose signatures to retrospectively evaluate glucose measurements for a defined glucose event of interest, and to continuously use the personalized glucose signatures of a patient to evaluate current glucose measurements for the defined glucose event of interest.

[0039] Further, the data stream of analyte values collected over time, with the CAM 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. For example, the derived real-time data and insight in turn allows for providing real-time alerts of glucose events. Realtime 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 CAM 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.

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

[0041] The real-time analyte data that is continuously generated by the CAM system described herein, therefore, allows the therapy management system herein to use a personalized glucose signature of a patient to evaluate glucose measurements for a defined glucose event of interest, 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 tocontinuously process a real-time data stream of analyte values overtime to derive meaningful data and insights using the algorithms and systems described herein. In other words, deriving meaningful data and insight from a stream of real-time data that is continuously generated, processed, calibrated, and analyzed, using the algorithms and systems described herein, is not a task that can be mentally performed. For example, executing the algorithms described in relation to FIGS. 3-4, 5A-B, 6A-B, 7, 8A-C, and 9, in real-time and on a continuous basis, which would involve using a stream of real-time data that is continuously generated by a patient’s CAM system and / or significantly large amount of population data (e.g., hundreds or thousands of data points for each one of thousands or millions of patients in the patient population) is not a task that can be mentally performed, especially in real-time at times.

[0042] Further, certain embodiments herein are directed to a technical solution to a technical problem associated with CAM systems. In particular, each CAM system that is manufactured by a CAM system manufacturer might perform slightly differently. As such, there might be inconsistencies between sensors and the measurements they generate once in use. Accordingly, certain embodiments herein are directed to determining the performance of a CAM 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.

[0043] Generally, calibration sensitivity refers to the amount of electrical current produced by an analyte sensor of a CAM 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.

[0044] The calibration sensitivity, calibration baseline, and other information related to the sensitivity profde for the CAM system may be programmed into the sensor electronics module of the CAM 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 vivosensitivity (Mf), which are programmed into the sensor electronics module and used to convert the analyte sensor electrical signals into measured analyte concentration levels.

[0045] In certain embodiments, during in vivo use, the sensor electronics module of a CAM 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)Equation 1A calibration baseline (baseline) may also be used to determine a measured analyte concentration level (ACL) from an analyte sensor count value (count) at a time ti, and Equation 2 presents one technique:ACL = (count - baseline) / M(ti)Equation 2

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

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

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

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

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

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

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

[0053] In certain embodiments, therapy management engine 112 refers to a set of software instructions with one or more software modules, including a data analysis module (DAM) 111. In some embodiments, therapy management engine 112 executes entirely on one or more computing devices in a private or a public cloud. In some other embodiments, therapy management engine 112 executes partially on one or more local devices, such as display device 107 (e.g., via application 106) and / or CAM system 104, and partially on one or more computing devices in a private or a public cloud. In some other embodiments, therapy management engine 1 12 executes entirely on one or more local devices, such as display device 107 (e.g., via application 106) and / or CAM system 104. In certain embodiments, therapy management engine 112, via the application 106, may provide interfaces for suggesting and confirming recommended CHO dosages.

[0054] In certain embodiments, DAM 111 of therapy management engine 112 may be configured to receive and / or process a set of inputs 127 (described in more detail below) (also referred to herein as “input data”) to determine one or more outputs 130 (also referred to herein as “metrics data”). Inputs 127 may be stored in the user profile 118 in the user database 110. DAM 111 can fetch inputs 127 from the user database 110 and compute a plurality of outputs 130 which can then be stored as application data 126 in the user profile 1 18. Such outputs 130 may include health-related metrics.

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

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

[0057] In certain embodiments, application 106 collects inputs 127 through user 102 input and / or a plurality of other sources, including CAM system 104, other applications running on display device 107, and / or one or more other sensors and devices. In certain embodiments, such sensors and devices include one or more of, but are not limited to, an insulin pump, other types of analyte sensors, sensors or devices provided by display device 107 (e.g., accelerometer, camera, global positioning system (GPS), heart rate monitor, etc.) or other user accessories (e.g., a smartwatch), or any other sensors or devices that provide relevant information about the user 102. In certain embodiments, user profde 1 18 also stores application configuration information indicating the current configuration of application 106, including its features and settings.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0092] In certain embodiments, outputs 130 generated, determined, or computed by DAM 1 11 include an insulin resistance metric (also referred to herein as an “insulin resistance”). The insulin resistance metric may be determined using historical data, real-time data, or a combination thereof, and may, for example, be based upon one or more inputs 127, such as one or more of food consumption information, blood glucose information, insulin delivery information, the resulting glucose levels, etc. In certain embodiments, the insulin on board metric may be determined using insulin delivery information, and / or known or learned (e.g., from patient data) insulin time action profdes, 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.

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

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

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

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

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

[0098] In certain embodiments, outputs 130 generated, determined, or computed by DAM 111 can include relevance metrics that result from individual transformations of glucose measurements. In certain embodiments, the relevance metrics can represent a probability that the corresponding glucose measurements are indicative of a predetermined glucose event. In certain aspects, the glucose event can be defined by, or associated with, a value, value range and / or threshold that defines the glucose event. In some cases, the glucose event can be a clinically defined event, such hypoglycemia or hyperglycemia. In addition, or alternatively, the glucose event can be custom event, such as a patient-defined event. In various embodiments, some or all glucose measurements can be transformed into relevance metrics for each of a plurality of glucose events (e.g., hypoglycemia, hyperglycemia, one or more custom glucose events, etc.). In various embodiments, the transformations can utilize logistic regression and / or other methods.

[0099] Equation 3 below illustrates an example transformation of a glucose measurement (G) into a relevance metric (Hypof) for a hypoglycemic event. In the example of Equation 3, the hypoglycemic event is associated with (e.g., includes or is at least partially defined by) a tunable hypoglycemic parameter or threshold (i.e., 75). In various embodiments, the hypoglycemic parameter can be tuned to be more or less sensitive to the hypoglycemic event (e.g., increased for greater sensitivity, or decreased for less sensitivity).1HypoA= 1 ->1 + e sEquation 3

[0100] Equation 4 below illustrates an example transformation of a glucose measurement (G) into a relevance metric (Hypof) for a hypoglycemic event. In Equation 4, as in Equation 3, the hypoglycemic event is defined by a tunable hypoglycemic parameter or threshold (i.e., 75). In addition, Equation 4 includes a tunable offset value (Offset) that can impact how rapidly HypoBincreases.1HypoB= 1 - (75 -G)1 +e5+OffsetEquation 4

[0101] Equation 5 below illustrates an example transformation of a glucose measurement (G) into a relevance metric (Hypoc) for a hypoglycemic event. Equation 5 follows the approach discussed above relative to Equation 4, except that in Equation 5, the hypoglycemic event is defined by a patient’s mean glucose measurement MGover a period of time. The period of time can be, for example, a preceding month, two months, one-hundred days, and / or the like. In addition, or alternatively, the period of time can be defined as a function of CGM sensors (e.g., the patient’s last ten sensor sessions).

[0102] Equation 6 below illustrates an example transformation of a glucose measurement (G) into a relevance metric (HyperAfor a hyperglycemic event. In the example of Equation 6, the hyperglycemic event is associated with (e.g., includes or is at least partially defined by) a tunable hyperglycemic parameter or threshold (i.e., 220). In various embodiments, the hyperglycemic parameter can be tuned to more or less sensitive to the hyperglycemic event (e.g., decreased for greater sensitivity, or increased for less sensitivity).Equation 6

[0103] Equation 7 illustrates an example transformation of a glucose measurement (G) into a relevance metric (HyperB) for a hyperglycemic event. In Equation 7, as in Equation 6, the hyperglycemic event is associated with (e.g., includes or is at least partially defined by) a tunable hyperglycemic parameter or threshold (i.e., 220). In addition, Equation 7 includes a tunable offset value (Offset) that can impact how rapidly HyperBincreases.Equation 7

[0104] As mentioned above, in some embodiments, the relevance metrics of the outputs 130 can relate to custom glucose events, for example, defined by a patient. In an example, the patient can establish a custom low-glucose event that is defined by a custom low-glucose threshold according to the example of Equation 3 and / or Equation 4. In another example, the patient can establish a custom high-glucose event that is defined by a custom high-glucose threshold according to the example of Equation 6 and / or Equation 7. By way of more particular example, a patient desiring tight glucose control may define custom glucose events for both patient-defined low and high thresholds (e.g., 80 for low and 180 for high). Other examples of custom glucose events will be apparent to one skilled in the art after a detailed review of the present disclosure.

[0105] In certain embodiments, outputs 130 generated, determined, or computed by DAM 111 can include personalized glucose signatures of a patient. The personalized glucose signatures canbased on the relevance metrics of the patient over a period (e g., a week, month, etc ). In certain embodiments, the personalized glucose signature can be structured according to a 24-hour modal day, with the relevance metrics over the period being aggregated by time windows thereof (e.g., 1 -minute windows, 5-minute windows, hourly windows, etc.). In various embodiments, personalized glucose signatures can be generated on-demand and / or with any suitable regularity. Advantageously, in certain examples, the personalized glucose signatures can be compared and used to track the patient’s glucose control over time (e.g., improved control, worse control, etc.). Examples of generating the personalized glucose signatures will be discussed in greater detail relative to FIGS. 4, 5A-B, and 6A-B.

[0106] Although relevance metrics and personalized signatures are discussed above relative to glucose measurements, as mentioned previously, the embodiments herein are likewise applicable and useful for improved reporting and analysis in connection with other analytes (e.g., ketones, lactates, etc.). For example, the transformation algorithms discussed above relative to Equations 3-7 can be adapted for another analyte by establishing a threshold value, for example, that represents a clinical or custom event for that analyte. In an example, the transformation algorithms discussed above relative to Equation 3, Equation 4, and / or Equation 5 can be adapted for another analyte by establishing a suitable low threshold for that analyte. In similar fashion, the transformation algorithms discussed above relative to Equation 6 and / or Equation 7 can be adapted for another analyte by establishing a suitable high threshold for that analyte. Likewise, in certain embodiments, personalized signatures can be generated for another analyte based on corresponding relevance metrics for that analyte over a period. For illustrative purposes, the present disclosure will continue to describe various examples that utilize glucose measurements.

[0107] FIG. 3 illustrates an example of a process 300 for generating a personalized glucose signature for a patient for a defined glucose event of interest, in accordance with certain embodiments. The defined glucose event of interest can be, for example, a hypoglycemic event, a hyperglycemic event, a custom glucose event, or another type of event, as discussed previously relative to FIG. 2.

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

[0109] At block 302, the therapy management engine 112 receives glucose measurements of the patient for a time period. In general, the time period can span any suitable interval, such as a number of days, a week, a month, and / or the like. The glucose measurements can be generated and received, for example, as discussed relative to FIGS. 1A-B and 2.

[0110] At block 304, the therapy management engine 112 transforms each of the glucose measurements into a relevance metric indicative of a relevance of the measurement to the defined glucose event of interest. In various embodiments, the block 304 can include performing any of the transformations discussed relative to FIG. 2, in correspondence to the defined glucose event of interest. In some embodiments, the block 304 can include normalizing any of the transformations discussed relative to FIG. 3 to a suitable scale (e.g., 0 to 1, 1, to 100 etc.), such that the scaled values serve as the relevance metrics. In some embodiments, glucose measurements can be transformed into relevance metrics in real-time as the measurements are generated. In such embodiments, instead of performing blocks 302 and 304 as indicated, the therapy management engine 112 can retrieve or access the relevance metrics for the period (i.e., the previously transformed glucose measurements).[OHl] At block 306, the therapy management engine 112 groups the relevance metrics into a plurality of time windows based on time of day. For example, the therapy management engine 112 can divide a modal day into the plurality of time windows (e.g., logical bins or buckets) and associate each relevance metric with the corresponding time window. The time windows can be of any suitable granularity (e.g., 1,440 one-minute windows, 288 five-minute windows, 24 hourly windows, etc.). In some cases, the time windows can be of varying length (e.g., hourly windows between midnight and 8:00 am and 5-minute windows during the rest of the day).

[0112] At block 308, the therapy management engine 112 aggregates the relevance metrics within each time window to yield a plurality of aggregate values. In general, the plurality of aggregate values can include an aggregate value for each time window. For example, for each time window of the modal day, the therapy management engine 112 can compute an average, weightedaverage, median, or modal value of the relevance metrics grouped therein. It should be appreciated that the relevance metrics can also be aggregated in other suitable ways. In some embodiments, the plurality of aggregate values can serve as a personalized glucose signature for the patient for the glucose event of interest. In such embodiments, the process 300 can end without proceeding to block 310. In other embodiments, the process 300 can proceed to block 310, as indicated, for data smoothing and / or other processing.

[0113] At block 310, the therapy management engine 112 applies a filter to the plurality of aggregate values, for example, to smooth out noise therein. The filter can be, for example, a moving average, moving median, polynomial filter, and / or the like. In certain embodiments, the filtered plurality of aggregate values can serve as a personalized glucose signature for the patient for the glucose event of interest. After block 310, the process 300 ends.

[0114] In some cases, during the process 300, the therapy management engine 112 can enforce a minimum initial period for the signature (e.g., one week, one month, etc.), such that no signature is generated and / or used until the glucose measurements are available for at least the minimum initial period. In such scenarios, the process 300 can be aborted or not started. In addition, or alternatively, in some cases, the minimum initial period can be dynamically determined and / or optimized based on an automated analysis of standard deviation between glucose measurements in each time window.

[0115] FIGS. 4, 5A-B, and 6A-B illustrate examples of personalized glucose signatures that can be generated as described relative to the process 300 of FIG. 3. FIG. 4 illustrates a graph 400 of example glucose measurements 401 of a patient over a 7-day period. The glucose measurements 401 can be received, for example, as discussed relative to the block 302 of FIG. 3. The glucose measurements 401 will be used as the basis for examples described in FIGS. 5A-B and 6A-B.

[0116] FIG. 5A illustrates a graph 500A of aggregated relevance metrics 502 and a personalized glucose signature 504 for a defined hyperglycemic event, both of which are based on the glucose measurements 401 of FIG. 4, in accordance with certain embodiments. The aggregated relevance metrics 502 can result, for example, from aggregating relevance metrics within each time window of a modal day, as discussed relative to block 308 of FIG. 3. The personalized glucose signature 504 can result, for example, from applying a filter (e.g., a Savitzky-Golay filterthat smooths data using a local polynomial fit a sub-set of the data) to the aggregated relevance metrics 502, as discussed relative to block 310 of FIG. 3.

[0117] FIG. 5B illustrates a graph 500B of the aggregated relevance metrics 502 and the personalized glucose signature 504 of FIG. 5 A in relation to an upper relevance threshold 506 and a lower relevance threshold 508, in accordance with certain embodiments. The upper relevance threshold 506 and the lower relevance threshold 508 can each be defined, for example, as an offset relative to the personalized glucose signature 504, such as a multiple thereof. The upper relevance threshold 506 and / or the lower relevance threshold 508 can merge with an upper or lower relevance boundary (e.g., 1 or 0), respectively, when the distance between the personalized glucose signature 504 and the boundary is less than the offset. In certain aspects, exceeding the upper relevance threshold 506 can indicate deviation from the personalized glucose signature 504 in a way that is generally more suggestive of the hyperglycemic event for the patient, while falling below the lower relevance threshold 508 can indicate deviation from the personalized glucose signature 504 in a way that is generally less suggestive of the hyperglycemic event for the patient.

[0118] The upper relevance threshold 506 and the lower relevance threshold 508 may also be adjusted in accordance with one or more patient inputs (such as planned caloric intake). For example, a patient participating in an exercise / diet program may input a first caloric meal intake for a recurring time period that is correlated to their upper relevance threshold 506. At a later time, the patient may input a second caloric meal intake for the recurring time period that has a smaller value than the first caloric meal intake. In response to the receipt of the second caloric meal intake, the upper relevance threshold 506 may be lowered to account for the smaller calorie intake of the user during the recurring time period.

[0119] In various embodiments, the upper relevance threshold 506 and / or the lower relevance threshold 508 can establish a configurable buffer relative to the personalized glucose signature 504 for purposes of monitoring and alerting for the defined hyperglycemic event, as will be further discussed relative to FIGS. 7 and 9. In these embodiments, a hyperglycemic event can be identified based on, and limited to, deviations from the personalized glucose signature 504 that satisfy, for example, the upper relevance threshold 506. In some embodiments, the identification of a hyperglycemic event can be further limited to deviations that persist for a minimum amount of time (e.g., a minimum number of consecutive measurements, a minimum number of minutes, aminimum number or proportion of measurements from a configurable window, such as half or more of a two-hour window, etc.).

[0120] In addition, or alternatively, a different glucose event can be identified based on deviations from the personalized glucose signature 504 that satisfy, for example, the lower relevance threshold 508. For example, such deviations can indicate that the aggregated relevance metrics 502 are highly likely to not be representative of a hyperglycemic event for the patient, and thus be noteworthy for their favorability relative to the hyperglycemic event. In some embodiments, the identification of such favorable events can be further limited to deviations that persist for a minimum amount of time (e.g., a minimum number of consecutive measurements, a minimum number of minutes, a minimum number or proportion of measurements from a configurable window, such as half or more of a two-hour window, etc.).

[0121] FIG. 6A illustrates a graph 600A of aggregated relevance metrics 602 and a personalized glucose signature 604 for a defined hypoglycemic event, both of which are based on the glucose measurements 401 of FIG. 4, in accordance with certain embodiments. The aggregated relevance metrics 602 can result, for example, from aggregating relevance metrics within each time window of a modal day, as discussed relative to block 308 of FIG. 3. The personalized glucose signature 604 can result, for example, from applying a filter (e.g., a Savitzky-Golay filter that smooths data using a local polynomial fit a sub-set of the data) to the aggregated relevance metrics 602, as discussed relative to block 310 of FIG. 3.

[0122] FIG. 6B illustrates a graph 600B of the aggregated relevance metrics 602 and the personalized glucose signature 604 of FIG. 6A in relation to an upper relevance threshold 606 and a lower relevance threshold 608. The upper relevance threshold 606 and the lower relevance threshold 608 can each be defined, for example, as an offset relative the personalized glucose signature 604, such as a multiple thereof. The upper relevance threshold 606 and / or the lower relevance threshold 608 can merge with an upper or lower relevance boundary (e.g., 1 or 0), respectively, when the distance between the personalized glucose signature 604 and the boundary is less than the offset. In certain aspects, exceeding the upper relevance threshold 606 can indicate deviation from the personalized glucose signature 604 in a way that is generally more suggestive of the hypoglycemic event for the patient, while falling below the lower relevance threshold 608can indicate deviation from the personalized glucose signature 604 in a way that is generally less suggestive of the hypoglycemic event for the patient.

[0123] In various embodiments, the upper relevance threshold 606 and / or the lower relevance threshold 608 can establish a configurable buffer relative to the personalized glucose signature 604 for purposes of monitoring and alerting for the defined hypoglycemic event, as will be further discussed relative to FIGS. 7 and 9. In these embodiments, a hypoglycemic event can be identified based on, and limited to, deviations from the personalized glucose signature 604 that satisfy, for example, the upper relevance threshold 606. In some embodiments, the identification of a hypoglycemic event can be further limited to deviations that persist for a minimum amount of time (e g., a minimum number of consecutive measurements, a minimum number of minutes, a minimum number or proportion of measurements from a configurable window, such as half or more of a two-hour window, etc.).

[0124] In addition, or alternatively, a different glucose event can be identified, for example, based on deviations from the personalized glucose signature 604 that satisfy, for example, the lower relevance threshold 608. For example, such deviations can indicate that the aggregated relevance metrics 602 are highly likely to not be representative of a hypoglycemic event for the patient, and thus be noteworthy for their favorability relative to the hypoglycemic event. In some embodiments, the identification of such favorable events can be further limited to deviations that persist for a minimum amount of time (e g., a minimum number of consecutive measurements, a minimum number of minutes, a minimum number or proportion of measurements from a configurable window, such as half or more of a two-hour window, etc.).

[0125] FIG. 7 illustrates an example of a process 700 for using a personalized glucose signature of a patient to retrospectively evaluate glucose measurements for a defined glucose event of interest, in accordance with certain embodiments. The glucose event of interest can be, for example, a hypoglycemic event, a hyperglycemic event, a custom glucose event, or another type of event, as discussed previously relative to FIG. 2.

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

[0127] At block 702, the therapy management engine 112 receives glucose measurements of the patient for a period of interest, for example, for evaluation relative to the personalized glucose signature. In general, the period of interest can span any suitable interval, such as a number of hours (e.g., a preceding eight hours), a number of days, a current day, a previous day, a current week, a previous week, a current month, a previous month, and / or the like. The glucose measurements can be generated and received, for example, as discussed relative to FIGS. 1-2.

[0128] At block 704, the therapy management engine 112 transforms each of the glucose measurements into a relevance metric indicative of a relevance of the measurement to the defined glucose event of interest. In general, the transformation can include any of the functionality discussed relative to the block 304 of FIG. 3. In some embodiments, glucose measurements can be transformed into relevance metrics in real-time as the measurements are generated. In such embodiments, instead of performing blocks 702 and 704 as indicated, the therapy management engine 112 can retrieve or access the relevance metrics for the period (i.e., the previously transformed glucose measurements).

[0129] At block 706, the therapy management engine 112 evaluates the relevance metrics for the period of interest relative to the personalized glucose signature for the glucose event of interest. At block 708, the therapy management engine 112 identifies glucose events corresponding to the glucose event of interest based on deviations, in the relevance metrics, relative to the personalized glucose signature, as discussed above relative to FIGS. 4, 5A-B and 6A-B. For example, glucose events corresponding to the glucose event of interest can be identified each time the relevance metrics satisfy an upper relevance threshold relative to the personalized glucose signature. In some embodiments, as discussed previously, the identification of glucose events can be limited to deviations that persist for a minimum amount of time (e.g., a minimum number of consecutive measurements, a minimum number of minutes, a minimum number or proportion of measurements from a configurable window, such as half or more of a two-hour window, etc.).

[0130] At block 710, the therapy management engine 112 presents information that visually indicates the period of interest’s (e.g., day’s) relevance metrics and / or glucose events in relationto the personalized glucose signature. An example of the present information will be described in greater detail relative to FIGS. 8A-C.

[0131] In some cases, the glucose measurements for the period of interest may be presented in a primary display area (e.g., a primary user interface, a primary portion of a user interface, etc.), while the period of interest’s relevance metrics and / or glucose events are presented in a secondary display area (e.g., a secondary user interface, a secondary portion of a user interface, etc.). In addition, or alternatively, in some embodiments, the patient or other user can select a display option to show the relevance metrics and / or glucose events together with, or instead of, the glucose measurements (e.g., via selection of an icon, link, button, or other control). In addition, or alternatively, in some embodiments, the period of interest’s relevance metrics and / or glucose events may be overlaid on a graph of the glucose measurements for the period of interest. Other examples and variations will be apparent to one skilled in the art after a detailed review of the present disclosure.

[0132] At block 712, the therapy management engine 112 enables input of patient behavioral events in correlation to the information presented at the block 710. In general, the information presented at the block 710 can help the patient or other user identify and accurately indicate certain patient behaviors (e.g., a meal, exercise, medication taken, insulin administered, etc.) in relation to a time, or an approximate time, at which they occurred. For example, the block 712 can include allowing the patient or other user to enter a meal in relation to a time of a noted hyperglycemia event, an insulin treatment in relation to a time of a noted hypoglycemic or hyperglycemic event, and / or the like. After block 712, the process 700 ends.

[0133] By displaying the relevance metrics and / or glucose events of a patient for a period of interest in relation to the patient’s personalized glucose signature, and correlating this data with patient behavior, the therapy management engine 112 may provide additional health insights for the patient that may improve an overall health of the patient. For example, after determining relevance metrics and / or glucose events for a patient for a first time period, the therapy management engine 112 may receive an indication that the patient has started taking a predetermined medication (such as Glucagon-like peptide-1 (GLP-1) medication to control their weight). After receiving this indication, the therapy management engine 112 may determine relevance metrics and / or glucose events for the patient for a second time period subsequent to thefirst time period. The relevance metrics and / or glucose events for the first time period may be compared to the relevance metrics and / or glucose events for the second time period to determine an effect / effectiveness of the predetermined medication taken by the patient. For example, the relevance metrics and / or glucose events for the second time period may be overlaid onto the relevance metrics and / or glucose events of the first time period for display to the patient or other user. A duration of glucose events for the first time period may be compared to a duration of glucose events for the second time period, and the difference may be presented to the patient or other user in correlation with an identification of the predetermined medication in order to present an effectiveness of such medication for the patient. The effects of other patient activity data, such as type / duration / timing of exercise, size / calorie content / timing of meals, etc. may be considered in a similar manner as above.

[0134] In another example, first relevance metrics and / or glucose events may be determined for a patient for a first nighttime / early morning time period in which the patient has indicated to the therapy management engine 112 that they administered an insulin dose at a first predetermined time (e.g., a first predetermined time before sleeping). Second relevance metrics and / or glucose events may then be determined for a patient for a second nighttime / early morning time period in which the patient has indicated to the therapy management engine 112 that they administered an insulin dose at a second predetermined time (e.g., a second predetermined time before sleeping that is different from the first predetermined time before sleeping). The therapy management engine 112 may then compare the first and second relevance metrics / glucose events to determine an effect the timing of the insulin dose has on the patient during their sleeping / early morning fasting glucose levels. The difference between these first and second first and second relevance metrics / glucose events may be presented to the patient (e.g. by displaying within a GUI an overlay of the first and second first and second relevance metrics / glucose events during a similar time of day). The therapy management engine 112 may also analyze the first and second relevance metrics / glucose events in association with the timing specifics of the associated insulin doses, and may recommend an optimal timing of an insulin dose for the patient prior to sleeping in order to optimize their sleeping / early morning fasting glucose levels.

[0135] FIGS. 8A-C illustrate examples of using the personalized glucose signatures discussed relative to FIGS. 4, 5A-B and 6A-B to evaluate other glucose measurements, as described relative to the process 700 of FIG. 7. In particular, FIG. 8A illustrates a graph 800A of the glucosemeasurements 401 shown in FIG. 4 together with new glucose measurements 810 for a segment of a different day, such as a subsequent day, in accordance with certain embodiments. The new glucose measurements 810 can be received, for example, as discussed relative to the block 702 of FIG. 7. The new glucose measurements 810 will be used as the basis for examples described in FIGS. 8B-C.

[0136] FIG. 8B illustrates a graph 800B showing the new glucose measurements 810 of FIG. 8A in relation to the personalized glucose signature 504, the upper relevance threshold 506, and the lower relevance threshold 508 of FIGS. 5A-B, in accordance with certain embodiments. In the example of FIG. 8B, the new glucose measurements 810 satisfy the upper relevance threshold 506 for a minimum amount of time during a segment 812 (e.g., half or more of a two hour window). Therefore, in the example of FIG. 8B, the segment 812 can be identified as a hyperglycemic event. In various embodiments, the graph 800B and the segment 812 corresponding to the hyperglycemic event can be presented, for example, as part of the block 710 of FIG. 7.

[0137] FIG. 8C illustrates a graph 800C showing the new glucose measurements 810 of FIG. 8A in relation to the personalized glucose signature 604, the upper relevance threshold 606, and the lower relevance threshold 608 of FIGS. 6A-B, in accordance with certain embodiments. In the example of FIG. 8C, the new glucose measurements 810 satisfy the upper relevance threshold 606 for a minimum amount of time during each of a segment 814 and a segment 818 (e.g., for half or more of a two hour window). Therefore, according to the example of FIG. 8C, the segment 814 and the segment 818 can each be identified as a hypoglycemic event.

[0138] In the example of FIG. 8C, the new glucose measurements 810 also satisfy the upper relevance threshold 606 during a segment 816; however, during the segment 816, the upper relevance threshold 606 is satisfied for less than the minimum amount of time (e.g., at least one hour of a two-hour segment). Therefore, in the example of FIG. 8C, the segment 816 is not identified as a hypoglycemic event. In various embodiments, the graph 800C and the two segments corresponding to hypoglycemic events (i.e., the segment 814 and the segment 818) can be presented, for example, as part of the block 710 of FIG. 7.

[0139] FIG. 9 illustrates an example of a process 900 for using a personalized glucose signature of a patient to evaluate current glucose measurements for a defined glucose event of interest, in accordance with certain embodiments. The glucose event of interest can be, forexample, a hypoglycemic event, a hyperglycemic event, a custom glucose event, or another type of event, as discussed previously relative to FIG. 2.

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

[0141] At block 902, the therapy management engine 112 receives one or more current glucose measurements of the patient, for example, for evaluation relative to the personalized glucose signature. The current glucose measurement s) can be received, for example, in real-time as the measurement is generated, as discussed relative to FIGS. 1-2.

[0142] At block 904, the therapy management engine 112 transforms each current glucose measurement, in real-time as the measurement is received, into a relevance metric indicative of a relevance of the measurement to the defined glucose event of interest. In general, the transformation can include any of the functionality discussed relative to the block 304 of FIG. 3.

[0143] At block 906, the therapy management engine 112 evaluates the relevance metric(s) relative to the personalized glucose signature. At block 908, the therapy management engine 112 identifies glucose events corresponding to the glucose event of interest, if any, based on deviations relative to the personalized glucose signature, as discussed above relative to FIGS. 4, 5A-B and 6A-B. For example, glucose events corresponding to the glucose event of interest can be identified each time the relevance metric(s) satisfy an upper relevance threshold relative to the personalized glucose signature. In some embodiments, as discussed previously, the identification of glucose events can be limited to deviations that persist for a minimum amount of time (e.g., a minimum number of consecutive measurements, a minimum number of minutes, a minimum number or proportion of measurements from a configurable window, such as half or more of a two-hour window, etc.).

[0144] At block 910, the therapy management engine 112 can predict future glucose event(s). For example, in certain embodiments, the therapy management engine 112 can use characteristicsassociated with previously identified glucose events (e.g., during previous iterations of the process 900 of FIG. 9 and / or the process 700 of FIG. 7) to predict similar glucose events in the future and warn of impending significant glucose events. In an example, the therapy management engine 112 can predict fasting glucose levels based on trends observed in previous days (e.g., based on delta and / or slope from end-of-day to early morning).

[0145] At block 912, the therapy management engine 112 can notify, or alert, the patient and / or other users of the identified and / or predicted glucose events, so that corrective action can be taken, as applicable. At block 914, the therapy management engine 112 can optionally recommend and / or initiate treatment. For example, the therapy management engine 112 can present a treatment recommendation, such as food, exercise, medication taken, insulin administered, and / or the like. In some cases, a treatment (e.g., insulin dosage) can be automatically determined and commanded to a medical device such as the medical device 108 of FIG. IB (e.g., command to an insulin pump). From block 914, the process 900 returns to the block 902 and executes as described previously.

[0146] FIG. 10 is a block diagram depicting a computer system 1000 configured for optimized event identification, for example, according to certain embodiments disclosed herein. Although depicted as a single physical device, in embodiments, the computer system 1000 may be implemented using virtual device(s), and / or across a number of devices, such as in a cloud environment and / or via separate modules of portable or cloud devices. As illustrated, the computer system 1000 includes a processor 1005, a memory 1010, a storage 1015, a network interface 1025, and one or more I / O interfaces 1020. In the illustrated embodiment, the processor 1005 retrieves and executes programming instructions stored in the memory 1010, as well as stores and retrieves application data residing in the storage 1015. The processor 1005 is generally representative of a single CPU and / or GPU, multiple CPUs and / or GPUs, a single CPU and / or GPU having multiple processing cores, and the like.

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

[0148] In some embodiments, the I / O devices 1035 (such as keyboards, monitors, etc.) can be connected via the I / O interface(s) 1020. Further, via the network interface 1025, the computer system 1000 can be communicatively coupled with one or more other devices and components, such as the user database 110. In certain embodiments, the computer system 1000 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 1005, memory 1010, storage 1015, network interface(s) 1025, and the I / O interface(s) 1020 are communicatively coupled by one or more interconnects 1030. In certain embodiments, the computer system 1000 is representative of the display device 107 associated with the user. In certain embodiments, as discussed above, the display device 107 can include the user’s laptop, computer, smartphone, and the like. In another embodiment, the computer system 1000 is a server executing in a cloud environment.

[0149] In the illustrated embodiment, the storage 1015 includes the user profile 118. The memory 1010 includes the therapy management engine 112. The therapy management engine 112 can be executed by the computer system 1000 to perform operations, for example, of the process 300 of FIG. 3, the process 700 of FIG. 7, and / or the process 900 of FIG. 9.Example Clauses

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

[0151] Clause 1: A method of optimizing analyte event identification, comprising, by a computer system: receiving, from a continuous analyte monitoring system, first analyte measurements determined for a patient during a first time period; transforming the first analyte measurements into first relevance metrics that each indicate a probability of an occurrence of a defined analyte event during the first time period; generating a personalized analyte signature for the patient for the first time period based on the first relevance metrics; and automatically identifying one or more analyte events for the patient based on an evaluation of additional analyte measurements determined for the patient relative to the personalized analyte signature for the patient.

[0152] Clause 2: The method of Clause 1, wherein the generating the personalized analyte signature comprises: grouping the first relevance metrics into a plurality of time windows of amodal day; and aggregating the first relevance metrics within each of the plurality of time windows to yield a plurality of aggregate values.

[0153] Clause 3: The method of Clause 2, wherein the aggregating comprises computing an average of the first relevance metrics within each of the plurality of time windows.

[0154] Clause 4: The method of Clause 2, wherein the generating the personalized analyte signature comprises applying a filter to the plurality of aggregate values, the personalized analyte signature comprising the filtered plurality of aggregate values.

[0155] Clause 5: The method of Clause 1, further comprising tuning a parameter associated with the defined analyte event to at least one of increase or decrease sensitivity to the defined analyte event, wherein the transforming is based on the tuned parameter.

[0156] Clause 6: The method of Clause 5, wherein the tuned parameter is indicative of at least one of a low or high analyte value.

[0157] Clause 7: The method of Clause 1, further comprising enforcing a minimum initial period for the personalized analyte signature, such that the personalized analyte signature is not generated until analyte measurements of the patient are available for at least the minimum initial period.

[0158] Clause 8: The method of Clause 1, wherein: the continuous analyte monitoring system comprises a continuous glucose monitoring system; the first analyte measurements comprise glucose measurements; the personalized analyte signature comprises a personalized glucose signature; the defined analyte event comprises a defined glucose event; and the one or more analyte events comprise one or more glucose events.

[0159] Clause 9: The method of Clause 8, wherein the defined glucose event comprises at least one of a defined hypoglycemic event or a defined hyperglycemic event.

[0160] Clause 10: The method of Clause 1, further comprising: receiving, from the continuous analyte monitoring system, second analyte measurements determined for the patient during a second time period; transforming the second analyte measurements into second relevance metrics that each indicate a probability of occurrence of the defined analyte event during the second time period; and evaluating the second relevance metrics relative to the personalized analyte signature, wherein the automatically identifying the one or more analyte events for the patient is based onthe evaluation of the second analyte measurements relative to the personalized analyte signature for the patient.

[0161] Clause 11 : The method of Clause 10, wherein the one or more analyte events are automatically identified based on one or more deviations in the second relevance metrics relative to the personalized analyte signature.

[0162] Clause 12: The method of Clause 10, wherein the one or more analyte events are automatically identified based on a segment of the second relevance metrics satisfying a relevance threshold relative to the personalized analyte signature.

[0163] Clause 13: The method of Clause 10, wherein the one or more analyte events are automatically identified based on a segment of the second relevance metrics satisfying a relevance threshold relative to the personalized analyte signature for a minimum amount of time.

[0164] Clause 14: The method of Clause 10, further comprising presenting information that visually indicates at least one of the second relevance metrics or the one or more analyte events in relation to the personalized analyte signature.

[0165] Clause 15: The method of Clause 14, wherein the presenting comprises: presenting the second analyte measurements in a primary display area; and presenting the at least one of the second relevance metrics or the one or more analyte events in a secondary display area.

[0166] Clause 16: The method of Clause 14, wherein the presenting comprises overlaying the at least one of the second relevance metrics or the one or more analyte events on a graph of the second analyte measurements for the second time period.

[0167] Clause 17: The method of Clause 14, further comprising enabling a user to input one or more patient behavioral events in correlation to the presented information, the one or more patient behavioral events comprising at least one of a meal, exercise, medication taken or insulin administered.

[0168] Clause 18: The method of Clause 1, further comprising: receiving, from the continuous analyte monitoring system, one or more current analyte measurements of the patient; transforming the one or more current analyte measurements into one or more relevance metrics that each indicate a probability of occurrence of the defined analyte event; evaluating the one or more relevance metrics relative to the personalized analyte signature, wherein the automatically identifying theone or more analyte events for the patient is based on the evaluation of the one or more relevance metrics relative to the personalized analyte signature for the patient; and alerting a user of the one or more analyte events.

[0169] Clause 19: A method of optimizing glucose event identification, comprising: receiving, from a continuous glucose monitoring system, first glucose measurements determined for a patient during a first time period; transforming the first glucose measurements into first relevance metrics that each indicate a probability of an occurrence of a defined glucose event during the first time period; generating a personalized glucose signature for the patient for the first time period based on the first relevance metrics; and automatically identifying one or more glucose events for the patient based on an evaluation of additional glucose measurements for the patient relative to the personalized glucose signature for the patient.

[0170] Clause 20: The method of Clause 19, wherein the defined glucose event comprises at least one of a defined hypoglycemic event or a defined hyperglycemic event.

[0171] Clause 21 : A method of optimizing analyte event identification, comprising: receiving, from a continuous analyte monitoring system, analyte measurements determined for a patient during a time period; transforming the analyte measurements into relevance metrics that each indicate a probability of an occurrence of a defined analyte event during the time period; evaluating the relevance metrics relative to a personalized analyte signature for the patient; and automatically identifying one or more analyte events for the patient based on the evaluating.

[0172] Clause 22: The method of Clause 21, wherein the one or more analyte events are automatically identified based on one or more deviations in the relevance metrics relative to the personalized analyte signature.

[0173] Clause 23: The method of Clause 21, wherein the one or more analyte events are automatically identified based on a segment of the relevance metrics satisfying a relevance threshold relative to the personalized analyte signature.

[0174] Clause 24: The method of Clause 21, wherein the one or more analyte events are automatically identified based on a segment of the relevance metrics satisfying a relevance threshold relative to the personalized analyte signature for a minimum amount of time.

[0175] Clause 25: The method of Clause 21, further comprising presenting information that visually indicates at least one of the relevance metrics or the one or more analyte events in relation to the personalized analyte signature.

[0176] Clause 26: The method of Clause 25, wherein the presenting comprises: presenting the analyte measurements in a primary display area; and presenting the at least one of the relevance metrics or the one or more analyte events in a secondary display area.

[0177] Clause 27: The method of Clause 25, wherein the presenting comprises overlaying the at least one of the relevance metrics or the one or more analyte events on a graph of the analyte measurements for the time period.

[0178] Clause 28: The method of Clause 25, further comprising enabling a user to input one or more patient behavioral events in correlation to the presented information, the one or more patient behavioral events comprising at least one of a meal, exercise, medication taken or insulin administered.

[0179] Clause 29: The method of Clause 21, wherein: the continuous analyte monitoring system comprises a continuous glucose monitoring system; the analyte measurements comprise glucose measurements; the personalized analyte signature comprises a personalized glucose signature; the defined analyte event comprises a defined glucose event; and the one or more analyte events comprise one or more glucose events.

[0180] Clause 30: The method of Clause 29, wherein the defined glucose event comprises at least one of a defined hypoglycemic event or a defined hyperglycemic event.

[0181] Clause 31 : A method of optimizing analyte event identification, comprising: receiving, from a continuous analyte monitoring system, one or more current analyte measurements of a patient; transforming the one or more current analyte measurements into one or more relevance metrics that each indicate a probability of occurrence of a defined analyte event; evaluating the one or more relevance metrics relative to a personalized analyte signature for the patient; automatically identifying one or more analyte events for the patient based on the evaluating; and alerting a user of the one or more analyte events.

[0182] Clause 32: The method of Clause 31, wherein the one or more analyte events are automatically identified based on one or more deviations in the relevance metrics relative to the personalized analyte signature.

[0183] Clause 33: The method of Clause 31, wherein the one or more analyte events are automatically identified based on a segment of the relevance metrics satisfying a relevance threshold relative to the personalized analyte signature.

[0184] Clause 34: The method of Clause 31, wherein the one or more analyte events are automatically identified based on a segment of the relevance metrics satisfying a relevance threshold relative to the personalized analyte signature for a minimum amount of time.

[0185] Clause 35: The method of Clause 31, further comprising predicting one or more future analyte events based on characteristics associated with one or more previously identified analyte events.

[0186] Clause 36: The method of Clause 31, further comprising automatically determining a treatment based on the one or more analyte events and presenting the automatically determined treatment to a user.

[0187] Clause 37: The method of Clause 31, further comprising automatically determining a treatment based on the one or more analyte events and commanding a medical device based on the automatically determined treatment.

[0188] Clause 38: The method of Clause 31, wherein: the continuous analyte monitoring system comprises a continuous glucose monitoring system; the one or more current analyte measurements comprise one or more current glucose measurements; the personalized analyte signature comprises a personalized glucose signature; the defined analyte event comprises a defined glucose event; and the one or more analyte events comprise one or more glucose events.

[0189] Clause 39: The method of Clause 38, wherein the defined glucose event comprises at least one of a defined hypoglycemic event or a defined hyperglycemic event.

[0190] Clause 40: A system for optimizing analyte event identification, comprising: a continuous analyte monitoring system configured to generate measurements associated with an analyte level of a patient; one or more memories comprising executable instructions; and one or more processors in data communication with the continuous analyte monitoring system and theone or more memories, the one or more processors configured to execute the executable instructions to: receive, from the continuous analyte monitoring system, first analyte measurements determined for the patient during a first time period; transform the first analyte measurements into first relevance metrics that each indicate a probability of an occurrence of a defined analyte event during the first time period; generate a personalized analyte signature for the patient for the first time period based on the first relevance metrics; and automatically identify one or more analyte events for the patient based on an evaluation of additional analyte measurements determined for the patient relative to the personalized analyte signature for the patient.

[0191] Clause 41 : A system for optimizing analyte event identification, comprising: a continuous glucose monitoring system configured to generate measurements associated with an analyte level of a patient; one or more memories comprising executable instructions; and one or more processors in data communication with the continuous glucose monitoring system and the one or more memories, the one or more processors configured to execute the executable instructions to: receive, from the continuous glucose monitoring system, first glucose measurements determined for a patient during a first time period; transform the first glucose measurements into first relevance metrics that each indicate a probability of an occurrence of a defined glucose event during the first time period; generate a personalized glucose signature for the patient for the first time period based on the first relevance metrics; and automatically identify one or more glucose events for the patient based on an evaluation of additional glucose measurements for the patient relative to the personalized glucose signature for the patient.

[0192] Clause 42: A system for optimizing analyte event identification, comprising: a continuous analyte monitoring system configured to generate measurements associated with an analyte level of a patient; one or more memories comprising executable instructions; and one or more processors in data communication with the continuous analyte monitoring system and the one or more memories, the one or more processors configured to execute the executable instructions to: receive, from the continuous analyte monitoring system, analyte measurements determined for a patient during a time period; transforming the analyte measurements into relevance metrics that each indicate a probability of an occurrence of a defined analyte event during the time period; evaluating the relevance metrics relative to a personalized analyte signature for the patient; and automatically identifying one or more analyte events for the patient based on the evaluating.

[0193] Clause 43: A system for optimizing analyte event identification, comprising: a continuous analyte monitoring system configured to generate measurements associated with an analyte level of a patient; one or more memories comprising executable instructions; and one or more processors in data communication with the continuous analyte monitoring system and the one or more memories, the one or more processors configured to execute the executable instructions to: receive, from a continuous analyte monitoring system, one or more current analyte measurements of a patient; transform the one or more current analyte measurements into one or more relevance metrics that each indicate a probability of occurrence of a defined analyte event; evaluate the one or more relevance metrics relative to a personalized analyte signature for the patient; automatically identify one or more analyte events for the patient based on the evaluation of the one or more relevance metrics; and alert a user of the one or more analyte events.

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

[0195] Clause 45: An apparatus, comprising means for performing a method in accordance with any combination of Clauses 1-39.

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

[0197] Clause 47: A computer program product embodied on a computer-readable storage medium comprising code for performing a method in accordance with any combination of Clauses 1-39.Additional Considerations

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

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

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

[0201] In this document, the terms “a” or “an” are used, as is common in patent documents, to include one or more than one, independent of any other instances or usages of “at least one” or “one or more.” In this document, the term “or” is used to refer to a nonexclusive or, such that “A or B” includes “A but not B,” “B but not A,” and “A and B,” unless otherwise indicated. In this document, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein.” Also, in the following claims, the terms “including” and “comprising” are open-ended, that is, a system, device, article, composition, formulation, or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall within the scope of that claim. Moreover, in the following claims, the terms “first,” “second,” and “third,” etc. are used merely as labels, and are not intended to impose numerical requirements on their objects.

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

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

Claims

CLAIMS1. A method of optimizing analyte event identification, comprising: receiving, from a continuous analyte monitoring system, first analyte measurements determined for a patient during a first time period; transforming the first analyte measurements into first relevance metrics that each indicate a probability of an occurrence of a defined analyte event during the first time period; generating a personalized analyte signature for the patient for the first time period based on the first relevance metrics; and automatically identifying one or more analyte events for the patient based on an evaluation of additional analyte measurements determined for the patient relative to the personalized analyte signature for the patient.

2. The method of claim 1, wherein the generating the personalized analyte signature comprises: grouping the first relevance metrics into a plurality of time windows of a modal day; and aggregating the first relevance metrics within each of the plurality of time windows to yield a plurality of aggregate values.

3. The method of claim 2, wherein the aggregating comprises computing an average of the first relevance metrics within each of the plurality of time windows.

4. The method of claim 2, wherein the generating the personalized analyte signature comprises applying a filter to the plurality of aggregate values, the personalized analyte signature comprising the filtered plurality of aggregate values.

5. The method of claim 1, further comprising tuning a parameter associated with the defined analyte event to at least one of increase or decrease sensitivity to the defined analyte event, wherein the transforming is based on the tuned parameter.

6. The method of claim 5, wherein the tuned parameter is indicative of at least one of a low or high analyte value.

7. The method of claim 1, further comprising enforcing a minimum initial period for the personalized analyte signature, such that the personalized analyte signature is not generated until analyte measurements of the patient are available for at least the minimum initial period.

8. The method of claim 1, wherein: the continuous analyte monitoring system comprises a continuous glucose monitoring system; the first analyte measurements comprise glucose measurements; the personalized analyte signature comprises a personalized glucose signature; the defined analyte event comprises a defined glucose event; and the one or more analyte events comprise one or more glucose events.

9. The method of claim 8, wherein the defined glucose event comprises at least one of a defined hypoglycemic event or a defined hyperglycemic event.

10. A system for optimizing analyte event identification, comprising: a continuous analyte monitoring system configured to generate measurements associated with an analyte level of a patient; one or more memories comprising executable instructions; and one or more processors in data communication with the one or more memories and configured to execute the executable instructions to: receive, from the continuous analyte monitoring system, first analyte measurements determined for the patient during a first time period; transform the first analyte measurements into first relevance metrics that each indicate a probability of an occurrence of a defined analyte event during the first time period; generate a personalized analyte signature for the patient for the first time period based on the first relevance metrics; and automatically identify one or more analyte events for the patient based on an evaluation of additional analyte measurements determined for the patient relative to the personalized analyte signature for the patient.

11. The system of claim 10, wherein the generation of the personalized analyte signature comprises: grouping the first relevance metrics into a plurality of time windows of a modal day; and aggregating the first relevance metrics within each of the plurality of time windows to yield a plurality of aggregate values.

12. The system of claim 10, wherein the one or more processors are further configured to execute the executable instructions to tune a parameter associated with the defined analyte event to at least one of increase or decrease sensitivity to the defined analyte event, wherein the transformation of the first analyte measurements is based on the tuned parameter.

13. The system of claim 10, wherein the one or more processors are further configured to execute the executable instructions to enforce a minimum initial period for the personalized analyte signature, such that the personalized analyte signature is not generated until analyte measurements of the patient are available for at least the minimum initial period.

14. The system of claim 10, wherein: the continuous analyte monitoring system comprises a continuous glucose monitoring system; the first analyte measurements comprise glucose measurements; the personalized analyte signature comprises a personalized glucose signature; the defined analyte event comprises a defined glucose event; and the one or more analyte events comprise one or more glucose events.

15. A computer-program product comprising a non-transitory computer-usable medium having computer-readable program code embodied therein, the computer-readable program code adapted to be executed to implement a method comprising: receiving, from a continuous analyte monitoring system, first analyte measurements determined for a patient during a first time period; transforming the first analyte measurements into first relevance metrics that each indicate a probability of an occurrence of a defined analyte event during the first time period; generating a personalized analyte signature for the patient for the first time period based on the first relevance metrics; and automatically identifying one or more analyte events for the patient based on an evaluation of additional analyte measurements determined for the patient relative to the personalized analyte signature for the patient.

Images