CLOSED-LOOP DIABETES TREATMENT SYSTEM DETECTING MEAL OR MISSED BOLUS

CROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to U.S. Provisional Application No. 62/705,091, filed on June 10, 2020, entitled “CLOSED-LOOP DIABETES TREATMENT SYSTEM DETECTING MEAL OR MISSED BOLUS,” the disclosure of which is incorporate by reference herein in its entirety.

TECHNICAL FIELD

[0002] This document relates to a closed-loop diabetes treatment system detecting a meal and/or a missed bolus.

BACKGROUND

[0003] Diabetes mellitus is a chronic metabolic disorder caused by the inability of a person's pancreas to produce sufficient amounts of the hormone insulin such that the person's metabolism is unable to provide for the proper absorption of sugar and starch. This failure leads to hyperglycemia, i.e., the presence of an excessive amount of glucose within the blood plasma. Persistent hyperglycemia has been associated with a variety of serious symptoms and life threatening long-term complications such as dehydration, ketoacidosis, diabetic coma, cardiovascular diseases, chronic renal failure, retinal damage and nerve damages with the risk of amputation of extremities. Because healing is not yet possible, a permanent therapy is necessary which provides constant glycemic control in order to constantly maintain the level of blood analyte within normal limits. Such glycemic control is achieved by regularly supplying external drugs to the body of the patient to thereby reduce the elevated levels of blood analyte. An external biologically effective drug (e.g., insulin or its analog) is commonly administered by means of daily injections. In some cases, multiple, daily injections of a mixture of rapid- and long-acting insulin are administered via a reusable transdermal liquid dosing device.

SUMMARY

[0004] In a first aspect, a computer-implemented method of performing closed-loop insulin therapy comprises: receiving blood glucose values and bolus information regarding a person with diabetes, the blood glucose values and the bolus information relating to a period of time; determining, based on the blood glucose values, the bolus information, and a meal size propensity record regarding the person, an amount of insulin for the person; and causing, in response to the determination, the amount of insulin to be administered to the person.

[0005] Implementations can include any or all of the following features. Determining the amount of insulin comprises determining, based on the blood glucose values, the bolus information, and the meal size propensity record, a size of a meal ingested by the person, and selecting the amount of insulin based on the determined size of the meal. The meal size propensity record is a personalized meal size propensity record for the person. The meal size propensity record corresponds to a population. Determining the amount of insulin comprises determining, based on the blood glucose values, the bolus information, and the meal size propensity record, a timing of a meal ingested by the person, and selecting the amount of insulin based on the determined timing of the meal. The computer-implemented method further comprises performing dose capture regarding the person, wherein the bolus information is obtained based on the dose capture. The meal size propensity record is based on a first time period, the method further comprising receiving another meal size propensity record that is based on a second time period of different length than the first time period, and determining another amount of insulin for the person based on the other meal size propensity record. The computer-implemented method further comprises taking into account a gesture of the person with diabetes.

[0006] In a second aspect, a computer program product is stored in a non-transitory storage medium, the computer program product including instructions that when executed by at least one processor cause the at least one processor to perform operations comprising: receiving blood glucose values and bolus information regarding a person with diabetes, the blood glucose values and the bolus information relating to a period of time; determining, based on the blood glucose values, the bolus information, and a meal size propensity record regarding the person, an amount of insulin for the person; and causing, in response to the determination, the amount of insulin to be administered to the person.

[0007] In a third aspect, a closed-loop insulin treatment device comprises: a glucose sensor; an insulin injection device; and a closed-loop control device having a meal size propensity record regarding a person with diabetes, the closed-loop control device configured to receive blood glucose values from the glucose sensor and bolus information regarding the person, the blood glucose values and the bolus information relating to a period of time, the closed-loop control device further configured to determine, based on the blood glucose values, the bolus information, and the meal size propensity record, an amount of insulin for the person, and to cause the insulin injection device to inject the amount of insulin to the person.

[0008] Implementations can include any or all of the following features. The closed- loop control device comprises a closed-loop controller configured to apply the blood glucose values and the bolus information to a dynamic model. The dynamic model comprises a meal prediction component configured to predict, based on the blood glucose values, the bolus information, and the meal size propensity record, a meal size for the person. The dynamic model comprises a meal determination component configured to determine, based on the blood glucose values, the bolus information, and the meal size propensity record, a size of a meal ingested by the person. The dynamic model comprises a bolus prediction component configured to predict, based on the blood glucose values, the bolus information, and the meal size propensity record, a bolus size for the person. The dynamic model comprises a bolus determination component configured to determine, based on the blood glucose values, the bolus information, and the meal size propensity record, a size of a bolus administered to the person. The closed-loop insulin treatment device further comprises a gesture recognition component, wherein the closed-loop control device is further configured to take into account a gesture of the person with diabetes in determining the amount of insulin for the person.

[0009] In a fourth aspect, a computer-implemented method comprises: receiving blood glucose values and bolus information regarding a person with diabetes, the blood glucose values and the bolus information relating to a period of time; receiving a meal size propensity record regarding the person; classifying, based on the blood glucose values, the bolus information, and the meal size propensity record, each of multiple time periods within the period of time regarding whether the time period is associated with ingestion of a meal by the person; performing regression analysis on the classified multiple time periods to identify a first time period of the classified multiple time periods as corresponding to a beginning of the meal, wherein the bolus information indicates no bolus associated with the identified first time period; and associating, based on the regression analysis, a missed bolus event with the meal.

[0010] The computer-implemented method further comprises performing at least one action based on the event being associated with the period of time. The action includes issuing an alert regarding the person. The blood glucose values and the bolus information are received substantially in real time, and wherein the alert is issued substantially in real time with the bolus being missed. Issuing the alert in real time comprises waiting a predetermined time after the beginning of the meal before determining that the bolus was missed.

Classifying the multiple time periods comprises providing the blood glucose values and the bolus information to a first machine-learning set including at least one classifier, and wherein performing the regression analysis comprises providing at least an output of the first machine-learning set to a second machine-learning set including at least one regressor. The first machine-learning set includes multiple classifiers receiving also the blood glucose values and the bolus information, and wherein classifying each of the multiple time periods comprises generating one classification event for each of the multiple classifiers for each of the multiple time periods. The computer-implemented method further comprises providing each of the multiple classifiers with an aggregation of at least one of the blood glucose values or the bolus information. Receiving the bolus information comprises receiving data generated by a pen cap based on the pen cap detecting at least one of a removal of the pen cap from an insulin pen, or a replacement of the pen cap on the insulin pen. Receiving the bolus information comprises receiving amount information corresponding to an amount of insulin administered to the person. The computer-implemented method further comprises generating the meal size propensity record based on the blood glucose values and the bolus information. The computer-implemented method further comprises generating multiple meal size propensity records corresponding to different days of a week for the person. Generating the meal size propensity record comprises using a bolus probability density as a proxy for meal occurrence likelihood. The computer-implemented method further comprises generating the bolus probability density by aggregating bolus events for the person that are included in the bolus information. The bolus events are distributed within the period of time, and wherein aggregating the bolus events comprises: wrapping the bolus events over a time interval shorter than the period of time so that the bolus events are distributed within the time interval; generating, based on the bolus events wrapped over the time interval, a continuous distribution of likelihood over the time interval; and replicating the continuous distribution of likelihood at least once within the period of time. Generating the continuous distribution of likelihood comprises smoothing the bolus events wrapped over the time interval. Smoothing the bolus events comprises performing a kernel smoothed density estimate. Generating the continuous distribution of likelihood comprises filtering the bolus events wrapped over the time interval. The meal size propensity record comprises a heat map having a first axis corresponding to carbohydrates and a second axis corresponding to time of day, wherein contents of the heat map indicate respective probabilities. The computer-implemented method further comprises issuing an alert regarding the person based on the missed bolus event being associated with the meal. The blood glucose values and the bolus information are received substantially in real time, and wherein the alert is issued substantially in real time with the bolus being missed. The computer-implemented method further comprises taking into account the meal size propensity record before issuing the alert, wherein a relatively lower threshold for the alert is used when a current meal probability is relatively higher, wherein a relatively higher threshold for the alert is used when a current meal probability is relatively lower. Taking into account the meal size propensity record comprises changing a threshold for a feature in a machine-learning classifier based on a kernel smoothed density estimate in the meal size propensity record. Taking into account the meal size propensity record comprises reducing a threshold for associating the missed bolus event with the meal. The bolus information includes bolus events that are delta functions, the method further comprising broadening, before classifying the multiple time periods, each of the bolus events to have a finite time duration. Broadening each of the bolus events comprises convolving the delta function with a rectangle function. No bolus being associated with the identified first time period comprises that the bolus information includes no bolus separated from the identified first time period by at most a predefined time, and wherein the finite time duration is a multiple of the predefined time. The computer-implemented method further comprises aggregating, before classifying the multiple time periods, the bolus events in multiple overlapping time intervals. The blood glucose values and the bolus information are received substantially in real time. The blood glucose values and the bolus information are received in batch. No bolus being associated with the identified first time period comprises that the bolus information includes no bolus separated from the identified first time period by at most a predefined time, and wherein the bolus information does include a bolus separated from the identified first time period by more than the predefined time, the method further comprising associating a late bolus event with the bolus. The computer-implemented method further comprises receiving a gesture of the person with diabetes, wherein classifying the multiple time periods is further based on the gesture.

[0011] In a fifth aspect, a computer program product stored in a non -transitory storage medium, the computer program product including instructions that when executed by at least one processor cause the at least one processor to perform operations comprising: receiving blood glucose values and bolus information regarding a person with diabetes, the blood glucose values and the bolus information relating to a period of time; receiving a meal size propensity record regarding the person; classifying, based on the blood glucose values, the bolus information, and the meal size propensity record, each of multiple time periods within the period of time regarding whether the time period is associated with ingestion of a meal by the person; performing regression analysis on the classified multiple time periods to identify a first time period of the classified multiple time periods as corresponding to a beginning of the meal, wherein the bolus information indicates no bolus associated with the identified first time period; and associating, based on the regression analysis, a missed bolus event with the meal.

[0012] Implementations can include any or all of the following features. The meal size propensity record is a personalized meal size propensity record for the person. The meal size propensity record corresponds to a population.

[0013] In a sixth aspect, a computer-implemented method of generating a meal size propensity record comprises: receiving bolus information regarding a person with diabetes, the bolus information comprising bolus events distributed within a period of time; receiving carbohydrate announcements for the person regarding the period of time; and generating a meal size propensity record based on the bolus information and the carbohydrate announcements.

[0014] Implementations can include any or all of the following features. The computer-implemented method further comprises processing the bolus information to determine a timing of meals ingested by the person during the period of time, the timing of the meals forming a first dimension for generating the meal size propensity record. The carbohydrate announcements form a second dimension for generating the meal size propensity record. The computer-implemented method further comprises receiving blood glucose values regarding the person for the period of time, wherein processing the bolus information comprises: classifying, based on the blood glucose values and the bolus information, each of multiple time periods within the period of time regarding whether the time period is associated with ingestion of a meal by the person; and performing regression analysis on the classified multiple time periods to identify a first time period of the classified multiple time periods as corresponding to a beginning of the meal, wherein the bolus information indicates no bolus associated with the identified first time period. Classifying the multiple time periods comprises providing the blood glucose values and the bolus information to a first machine-learning set including at least one classifier, and wherein performing the regression analysis comprises providing at least an output of the first machine-learning set to a second machine-learning set including at least one regressor. The first machine-learning set includes multiple classifiers receiving also the blood glucose values and the bolus information, and wherein classifying each of the multiple time periods comprises generating one classification event for each of the multiple classifiers for each of the multiple time periods. The computer-implemented method further comprises providing each of the multiple classifiers with an aggregation of at least one of the blood glucose values or the bolus information. Generating the meal size propensity record comprises using a bolus probability density as a proxy for meal occurrence likelihood. The computer-implemented method further comprises generating the bolus probability density by aggregating bolus events for the person that are included in the bolus information. The bolus events are distributed within the period of time, and wherein aggregating the bolus events comprises: wrapping the bolus events over a time interval shorter than the period of time so that the bolus events are distributed within the time interval; generating, based on the bolus events wrapped over the time interval, a continuous distribution of likelihood over the time interval; and replicating the continuous distribution of likelihood at least once within the period of time. Generating the continuous distribution of likelihood comprises smoothing the bolus events wrapped over the time interval. Smoothing the bolus events comprises performing a kernel smoothed density estimate. Generating the continuous distribution of likelihood comprises filtering the bolus events wrapped over the time interval. The bolus information includes bolus events that are delta functions, the method further comprising broadening, before classifying the multiple time periods, each of the bolus events to have a finite time duration. Broadening each of the bolus events comprises convolving the delta function with a rectangle function. The computer-implemented method further comprises receiving a gesture of the person with diabetes, wherein generating the meal size propensity record is further based on the gesture.

[0015] In a seventh aspect, a computer program product is stored in a non-transitory storage medium, the computer program product including instructions that when executed by at least one processor cause the at least one processor to perform operations comprising: receiving bolus information regarding a person with diabetes, the bolus information comprising bolus events distributed within a period of time; receiving carbohydrate announcements for the person regarding the period of time; and generating a meal size propensity record based on the bolus information and the carbohydrate announcements.

BRIEF DESCRIPTION OF DRAWINGS

[0016] The patent or application file contains at least one drawing executed in color. Copies of this patent or patent application publication with color drawing(s) will be provided by the Office upon request and payment of the necessary fee.

[0017] FIG. 1A shows an example of a closed-loop diabetes treatment system.

[0018] FIG. IB shows another example of a closed-loop diabetes treatment system. [0019] FIG. 2 shows an example of a system that can detect a meal and/or a missed bolus.

[0020] FIG. 3 shows an example of input and output for meal and/or missed-bolus detection.

[0021] FIG. 4 shows an example of feature generation, and aggregation and scaling of one or more features.

[0022] FIG. 5 shows an example of features relating to estimated glucose value and rates of change.

[0023] FIG. 6 shows an example of spreading out data of a feature.

[0024] FIG. 7A schematically shows an example of aggregating bolus information.

[0025] FIG. 7B shows an example of a meal probability density.

[0026] FIG. 8 schematically shows an example of aggregating feature information into aggregated feature information.

[0027] FIG. 9 schematically shows an example of classification based on a feature.

[0028] FIG. 10 schematically shows an example of regression based on classification.

[0029] FIG. 11 shows an example of a system for diabetes management.

[0030] FIG. 12 is a perspective view of an example of an infusion pump system.

[0031] FIG. 13 shows an example of a meal size probability density estimate for a population based on 70 days of data.

[0032] FIG. 14 shows an example of a meal size probability density estimate for a single subject based on 7 days of data.

[0033] FIG. 15 shows an example of a meal occurrence probability density estimate for a single subject based on 7 days of data.

[0034] FIG. 16 shows an example of a meal size probability density estimate for a single subject based on 7 days of data.

[0035] FIG. 17 shows an example of a meal size probability density estimate for a single subject based on 14 days of data.

[0036] FIG. 18 shows an example of a meal occurrence probability density estimate for a single subject based on 14 days of data.

[0037] FIG. 19 shows an example of a meal size probability density estimate for a single subject based on 14 days of data.

[0038] FIGS. 20A-B show examples of graphical user interfaces.

[0039] FIG. 21 shows a simplified block diagram of an example of a computing platform for insulin-based management of diabetes. [0040] FIG. 22 shows a simplified block diagram of an example of a system for insulin- based management of diabetes.

[0041] FIG. 23 shows a diagram of an example of a system for diabetes management.

[0042] FIG. 24 shows an example of a system for training a regression model.

[0043] FIG. 25 shows a functional block diagram of an example of a system for training a regression model using machine learning.

[0044] FIG. 26 illustrates an example of a data journey in accordance with one embodiment.

[0045] FIG. 27A shows an example of a system for detecting that a person with diabetes ingests a meal.

[0046] FIGS. 27B-C show examples of gesture recognition.

[0047] FIG. 28 illustrates an example architecture of a computing device that can be used to implement aspects of the present disclosure.

[0048] Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

[0049] This document describes examples of systems and techniques for detecting meal ingestion and/or a missed bolus with regard to a person with diabetes, and/or aspects of such meal or missed bolus (e.g., meal size). In some implementations, one or more approaches for machine-learning can be applied to determine, for a period of time, a bolus probability density for the person with diabetes. For example, a meal probability density for the person can be generated based on the bolus probability density. The detection of the meal ingestion and/or the missed bolus can be used for one or more purposes. In some implementations, a diabetes treatment can be implemented or altered based on the detection. For example, an automatic bolus injection, an alert, a recommendation, and/or a bolus recommendation can be made based on the detection.

[0050] Examples described herein mention delivering insulin to a person with diabetes. Insulin delivery devices include, but are not limited to, insulin injection pens, insulin inhalers, insulin pumps, and insulin syringes. The improper dosing of insulin, whether due to human error, malfunction of an insulin pen, skipping doses, double dosing, or incorrect dosing, is always a concern. Methods, devices, and systems provided herein are described for the delivery of insulin, collection of blood glucose data, and/or the treatment of diabetes. Moreover, methods, devices, and systems provided herein may be adapted for the delivery of other medications, the collection of other analyte data, and/or the treatment of other diseases. Methods, devices, and systems provided herein are described by exemplifying features and functionalities of a number of illustrative embodiments. Other implementations are also possible.

[0051] Some examples herein refer to an insulin injection pen. An insulin injection pen includes at least one container holding insulin (e.g., an insulin cartridge), a dial or other mechanism to specify a dose, and a pen needle for transcutaneous delivery of the insulin into the tissue or vasculature of the person with diabetes. In a reusable insulin injection pen, the insulin container (e.g., the cartridge) is replaceable or refillable. A prefilled insulin injection pen is intended for use during a limited time. The dose-specifying mechanism can include a rotatable wheel coupled to mechanics and/or electronics for capping the administered amount of insulin at the volume of the specified dose (e.g., in terms of a number of units of insulin). The dose-specifying mechanism can have a mechanical and/or electronic display that reflects the current setting of the mechanism. The pen needle can be permanently attached to the housing of the insulin injection pen (e.g., as in the case with a disposable pen), or it can be removable (e.g., so that a new needle can be applied when needed). For example, a replaceable pen needle can include a hollow needle affixed to a fitting configured for removeable attachment to an end of the insulin injection pen.

[0052] Some examples herein refer to a mobile communication device. As used herein a mobile communication device includes, but is not limited to, a mobile phone, a smartphone, a wearable electronic device (e.g., a smart watch), a tablet, a laptop computer, a portable computer, and similar devices. A mobile communication device includes one or more processors, a non-transitory storage device (e.g., a memory and/or a hard drive) holding executable instructions for operating the mobile communication device, wireless communication components, and one or more input and/or output devices (e.g., a touchscreen, display, or keyboard). The mobile communication device can operate according to one or more application programs stored locally on the mobile communication device, or remotely (e.g., when using cloud computing), or combinations thereof. The mobile communication device can execute at least one operating system in order to perform functions and services.

[0053] Some examples herein refer to a blood glucose meter (BGM). ABGM is an electronic device configured to receive a sample from the person with diabetes (e.g., a blood sample) and analyze the sample to estimate the blood glucose level of the person with diabetes. The BGM may be configured to have a new test strip partially inserted into the BGM for each sample, and the person then places a drop of blood onto the end of the test strip extending from the BGM. The BGM performs testing on the drop of blood through the test strip.

[0054] Some examples herein refer to a continuous glucose monitor (CGM). A CGM is an electronic device configured to take readings of glucose values on an ongoing basis or at regular intervals in order to estimate the blood glucose level of the person with diabetes. Some CGMs determine blood glucose values periodically (e.g., after a certain number of seconds or minutes) and output the information automatically or upon being prompted. The CGM may include wireless communication components for one or more types of signaling, including, but not limited to, Near-Field Communication (NFC) and/or Bluetooth communication.

[0055] Some examples herein refer to estimated glucose value (EGV). EGV includes one or more values representing an estimate of the concentration of glucose in a person’s blood. The estimate can be associated with a greater or smaller uncertainty (e.g., the error in the determination) and can be characterized as an approximation of the amount of glucose present per unit volume of blood. EGV can be determined or approximated by any of multiple different devices and/or techniques. For example, a CGM, a BGM, and/or another glucose sensor can generate an output that corresponds to EGV.

[0056] In some embodiments, systems, devices, and methods provided herein can recommend insulin doses (e.g., dosages of long-acting and/or rapid-acting insulin) using any suitable technique. In some embodiments, recommended insulin dosages may be based upon blood glucose data (e.g., current EGV from a CGM, flash glucose monitor, BGM, or any other sensor, blood glucose trend data, etc.), insulin administration data (bolus dosage amounts of rapid-acting insulin, dosages of long-acting insulin, dosage times, calculation of Insulin-on-Board ("IOB") and/or active insulin, etc.), meal data (mealtimes, user estimated carbohydrates, user estimated meal categorizations, user estimated glycemic impact of meal user meal history, user meal trends, etc.), and/or one or more insulin delivery parameters (e.g., total daily dose of basal insulin or long-acting insulin, carbohydrate-to-insulin ratio (CR), insulin sensitivity factor (ISF), etc.). Methods, devices and systems provided herein can, in some embodiments, adjust insulin delivery parameters over time based on glucose data and/or insulin administration data.

[0057] Some examples herein refer to long-acting insulin and rapid-acting insulin, or in some cases more generally to first and second types of insulin. Insulin used for therapeutic treatment is often synthesized human insulin. Moreover, different insulins can be characterized in how quickly they typically begin to work in the body of the person with diabetes after administration, and/or how long they typically remain active in the body of the person with diabetes. Rapid-acting insulin can be used to dose for meals or to correct high blood sugar. There is more than one type of insulin that can be considered a rapid-acting insulin. Many, but not necessary all, rapid-acting insulins begin working within about one hour after administration. Examples of rapid-acting insulin include, but are not limited to, insulin aspart (e.g., NovoLog®, Fiasp®, and NovoLog® FlexPen®), insulin lispro (e.g., Humalog®, Admelog®, and Humalog® KwikPen®), and insulin gluisine (e.g., Apidra®, and Apidra® SoloSTAR® Pen). Similarly, there is more than one type of insulin that can be considered a long-acting insulin, and many, but not necessarily all, long-acting insulins begin working about one hour or longer after administration. Long-acting insulin is often referred to as basal insulin (e.g., insulin used to support basic metabolic needs). Generally, a long-acting insulin has a greater active time (i.e., the length of time that the insulin continues to be active in the body of the person with diabetes after administration) than a rapid-acting insulin. Examples of long-acting insulin include, but are not limited to, insulin glargine (e.g.,

Lantus®, Toujeo®, and Basaglar®), insulin detemir (e.g., Levemir®), and insulin degludec (e.g., Tresiba®). As such, a long-acting insulin is an example of a type of insulin having an active time that is longer than an active time for a type of insulin such as a rapid-acting insulin.

[0058] Some examples herein refer to a meal size propensity record. A meal size propensity record is a computer-readable document that indicates a meal size propensity for at least one person. The meal size propensity record can pertain to an individual person with diabetes or to multiple persons (e.g., a population). For example, the meal size propensity record can correspond to actual data that was collected for the person or population. As another example, the meal size propensity record can correspond to data that was simulated for the person or population. The meal size propensity record can, at least in part, indicate a likelihood that a person will ingest a meal of a given size (e.g., having a particular number of grams of carbohydrates). For example, the meal size propensity record can indicate a probability density for one or more meal sizes. The meal size propensity record can be tangibly embodied in a computer-readable storage medium.

[0059] Some examples herein refer to a closed-loop system. A closed-loop system can be used for insulin therapy and/or for insulin treatment. A closed-loop insulin treatment device can include one or more glucose components configured to sense or estimate a glucose level in the blood of a person with diabetes. The closed-loop insulin treatment device can include one or more injection components configured to inject insulin into the person. The closed-loop insulin treatment device can include one or more components configured to control and/or be responsive to the glucose component and/or the injection component, in order to take action based at least in part on a meal size propensity record. Such action can include determining an amount of insulin for the person, and causing the amount of insulin to be injected into the person.

[0060] FIG. 1 A shows an example of a closed-loop diabetes treatment system 100. The closed-loop diabetes treatment system 100 can be used with one or more other examples described herein. The closed-loop diabetes treatment system 100 includes a glucose sensor 102 that is configured to sense or estimate the blood glucose level of a person with diabetes one or more times (e.g., on an ongoing basis, and/or at regular intervals). In some implementations, the glucose sensor 102 includes a CGM and/or a BGM. The closed-loop diabetes treatment system 100 includes an insulin injection device 104 that is configured for injecting (e.g., automatically injecting) one or more bolus amounts of insulin into the person. For example, the insulin injection device 104 can include an insulin pump coupled to a subcutaneous member that is in fluid communication with tissue or vasculature of the person so as to be able to deliver insulin into the person’s body. The closed-loop diabetes treatment system 100 includes a closed-loop control device 106 that is coupled to, or otherwise configured to communicate with, the glucose sensor 102 and the insulin injection device 104. The closed-loop control device 106 includes, or has access to, a meal size propensity record regarding the person with diabetes. The closed-loop control device 106 is configured to receive blood glucose values (e.g., from the glucose sensor 102) and bolus information regarding the person (e.g., from the insulin injection device 104). The closed-loop control device 106 is configured to determine, based on the blood glucose values, the bolus information, and the meal size propensity record, an amount of insulin for the person. For example, this determination can involve calculating how much insulin the closed-loop diabetes treatment system 100 should inject into the person at a given time, or over a period of time. The closed-loop control device 106 is configured to cause the determined amount of insulin to be injected into the person. For example, this can be done by controlling the insulin injection device 104 to deliver the determined amount of insulin in form of one or more boluses.

[0061] In some implementations, the closed-loop diabetes treatment system 100 can calculate, based on meal propensity that a person is about 90% likely to have ingested a meal of approximately M grams of carbohydrates (e.g., a carbohydrate range including M grams) in the last 30 minutes. For example, such a calculation can take into account a meal size propensity, a meal timing propensity, and blood glucose data. The closed-loop diabetes treatment system 100 can then calculate a bolus size based on the meal size of the 90% confidence interval (e.g., the lower end of such a range) and deliver a bolus having a size based on the calculated bolus size. For example, the delivered bolus can have a size that is a fixed percentage of the calculated bolus size. Such a sizing approach can be implemented as a way of erring on the side of delivering less rather than too much insulin.

[0062] FIG. IB shows another example of a closed-loop diabetes treatment system 110. The closed-loop diabetes treatment system 110 can be used with one or more other examples described herein. The closed-loop diabetes treatment system 110 includes one or more inputs 112, one or more closed-loop controllers 114, one or more dynamic models 116, and is configured for performing one or more actions 118 regarding a person with diabetes. For example, performing the action(s) 118 can include automatically injecting insulin into the person with diabetes using the insulin injection device 104 (FIG. 1 A).

[0063] The inputs 112 can include one or more types of information relevant to the diabetes treatment or diabetes therapy of one or more persons. In some implementations, the inputs 112 are obtained from one or more devices that can be coupled to the closed-loop diabetes treatment system 110 and/or to the body of the person with diabetes. For example, one or more of the inputs 112 can include blood glucose values for the person. As another example, one or more of the inputs 112 can include bolus information regarding the person. The blood glucose values and/or the bolus information can relate to a period of time. Such period of time can be on the order of one day or shorter, or on the order of multiple days or longer.

[0064] The closed-loop controller 114 can perform a controlling or managing function in the closed-loop diabetes treatment system 110. As such, the closed-loop controller 114 can receive one or more of the inputs 112, apply the input(s) to the dynamic model 116 in order to determine one or more aspects of the insulin therapy, such as a bolus amount to be injected based on feedback about the person with diabetes, and cause the action(s) 118 to be performed. Any of multiple types of closed-loop controller can be used in the closed-loop diabetes treatment system 110. In some implementations, the closed-loop controller 114 can be or include a proportional -integral-derivative (PID) feedback controller. APID feedback controller can include a control loop mechanism that continuously or regularly calculates an error value based on relevant feedback. For example, the PID feedback controller can determine the error value as a difference between a setpoint and a measured value, and apply a correction to its output accordingly. The correction can be based on terms that are characterized as proportional, integral, and derivative, respectively. The PID controller can be configured to operate according to one or more levels of gain. As another example, the PID controller can be configured to assert a more aggressive, and/or a less aggressive, level of control over one or more parameters relating to insulin therapy.

[0065] In some implementations, the closed-loop controller 114 can be or include a model predictive control (MPC) algorithm. The MPC algorithm can make use of one or more of the dynamic models 116 to determine an applicable value or values. In some implementations, one or more of the dynamic model(s) 116 can be a linear or a non-linear model relating to insulin therapy. For example, the dynamic model 116 can be designed to output an estimated blood glucose value that the person with diabetes is likely to experience given a treatment based on one or more characteristics (e.g., a bolus amount). As another example, the dynamic model 116 can be designed to output the amount of insulin that is expected to be required given one or more characteristics of the person (e.g., their current blood glucose level, and/or information about meal ingestion). In some implementations, the dynamic model 116 includes one or more models regarding glucose absorption in the body. In some implementations, the dynamic model 116 includes one or more models regarding insulin absorption in the body.

[0066] The MPC algorithm can be configured for performing one or more optimizations. In some implementations, the closed-loop controller 114 includes a cost function 120 that evaluates the cost, in terms of one or more variables relevant to insulin therapy, of either taking a particular action or abstaining from taking a particular action. For example, an output of the cost function 120 can represent a difference between estimated blood glucose levels for the next period of time T, assuming that an amount of insulin is injected, and a set or planned blood glucose level that represents a normal or desired condition for the person. Deviation from the set or planned glucose level (or other variable) can be characterized as costly (e.g., associated with relatively high cost) and adherence to the set or planned glucose level can be characterized as not costly (e.g., associated with relatively low or no cost).

[0067] In some implementations, the closed-loop controller 114 includes a cost control component 122. The cost control component 122 can cause one or more of the actions 118 to be performed, or to be inhibited from being performed, based on the cost function 120. In some implementations, the cost control component 122 causes the action(s) 118 to be performed so that the cost function 120 will attain one or more specific cost values. For example, the cost control component 122 can seek to optimize (e.g., minimize) the cost implicated by the cost function 120.

[0068] The closed-loop controller 114 can take into account one or more constraints 124 in determining whether, and/or how to, perform the action(s) 118. In some implementations, the constraints 124 can relate to a maximum or minimum of some variable that is affected by the closed-loop controller 114. For example, the constraints 124 can impose a guidance (e.g., a limit) on the automatic bolusing of insulin into the person with diabetes.

[0069] The system 110 can be provided with at least one feedback 125, as here schematically illustrated using an arrow leading from the action(s) 118 to the input(s) 112. In some implementations, the feedback 125 can be used as an input that is taken into account in determining whether and/or how to perform the action(s) 118. For example, the feedback 125 can indicate the blood glucose level of the person with diabetes and can be considered when deciding whether to automatically inject insulin.

[0070] The dynamic model 116 can include, or make use of, one or more components relating to insulin therapy or treatment. In some implementations, a meal prediction component 126 can be used to predict the occurrence of a meal ingested by the person with diabetes, and/or the size of such a meal. Such a determination can involve a detection and/or estimation performed based on the input(s) 112. For example, the meal prediction component 126 can take into account a meal size propensity record relating to the person, and the person’s blood glucose values and bolus information, and make a determination as to whether the person is likely to ingest a meal.

[0071] In some implementations, a meal determination component 128 can be used to determine or estimate a meal ingestion by the person with diabetes, and/or the size of such a meal. Such a determination can involve a detection and/or estimation performed based on the input(s) 112. For example, the meal determination component 128 can take into account a meal size propensity record relating to the person, the person’s blood glucose values, bolus information, and/or a gesture, and make a determination as to what size meal the person is currently ingesting. Such a determination can be used as an input in selecting an amount of insulin to be automatically injected into the person.

[0072] In some implementations, the system 110 can issue a communication (e.g., a warning, alarm, notice using a user interface, and/or another more or less intrusive or noticeable communication) that the system has determined or estimated that the person with diabetes recently ingested a meal. Such a communication can indicate that a bolus of units of insulin will automatically be bolused in a predetermined time from the communication (e.g., 5 or 15 minutes). In some implementations, the person in response to the communication can instruct the system 110 to not automatically inject the bolus. For example, the person can prevent a bolus injection from being made, or can specify a different bolus amount to be automatically injected. In some implementations, the communication and/or input by the person can be made using one or more buttons in a user interface. For example, a first button/input can correspond to an instruction for the system 110 to immediately inject the recommended bolus size, a second button/input can correspond to an instruction for the system 100 to automatically inject another (specified) bolus amount, and a third button/input can correspond to an instruction for the system 100 to currently not automatically inject any bolus amount.

[0073] In some implementations, a bolus prediction component 130 can be used to predict the occurrence of a bolus injection by the person with diabetes, and/or the size of such a bolus. Such a determination can involve a detection and/or estimation performed based on the input(s) 112. For example, the bolus prediction component 130 can take into account a meal size propensity record relating to the person, and the person’s blood glucose values and bolus information, and make a determination as to whether the person is likely to inject a bolus.

[0074] In some implementations, a bolus determination component 132 can be used to determine a size of a bolus injected into a person with diabetes (e.g., automatically injected). Such a determination can involve a detection and/or estimation performed based on the input(s) 112. For example, the bolus determination component 132 can take into account a meal size propensity record relating to the person, the person’s blood glucose values, bolus information, and/or a gesture, and make a determination as to what size bolus should be automatically injected into the person. The bolus determination component 132 can take into account a dose capture performed regarding the insulin treatment for the person with diabetes.

[0075] FIG. 2 shows an example of a system 200 that can detect a meal (e.g., the size thereof) and/or a missed bolus. The system 200 can be used with one or more other examples described herein. The system 200 or any components thereof can be implemented using one or more computer-based modules, for example as described below with reference to FIG. 27.

[0076] The system 200 can use one or more inputs 210. In some implementations, the inputs 210 include one or more blood glucose values for the person with diabetes. For example, the blood glucose values can originate in a CGM or a BGM, and can be received in batch or substantially in real time. In some implementations, the inputs 210 include bolus information regarding the person with diabetes. For example, the bolus information can reflect actual detection of the time of administration of the bolus, actual detection of the amount of the bolus, estimation of the time of administration of the bolus (e.g., by way of a proxy such as detecting pen cap removal/replacement), and/or estimation of the amount of the bolus. One or more other inputs can be used in addition or instead.

[0077] The system 200 can use one or more feature components 220. In some implementations, the feature component 220 is configured for receiving some or all of the inputs 210 and generating one or more features therefrom. For example, any or all features described elsewhere herein can be generated in the system 200. In some implementations, the feature component 220 is configured for scaling one or more features from the inputs 210.

For example, any or all features described elsewhere herein can be scaled in the system 200. In some implementations, scaling can involve calculating the mean and/or standard deviation for one or more of the features. For example, the calculated mean can be subtracted from the feature, and the difference can be used as a feature in addition to, or instead of, the originally calculated feature. For example, the feature can be divided by the calculated standard deviation, and the quotient can be used as a feature in addition to, or instead of, the originally calculated feature. Both of the above approaches can be used on the feature(s). In some implementations, scaling can be done to prevent a classifier or regressor from using the size of a particular feature as a proxy for information. For example, just because the feature has a large value does not mean the feature should be considered more important than another feature. In some implementations, a training data set is used for training classifier or regressor, and the mean and/or standard deviation can be determined for the training set for later use in testing and/or run time use.

[0078] The system 200 can use a first layer 230 of one or more machine-learning components. The first layer 230 can be characterized as including one or more meal prediction classifiers. The first layer 230 is sometimes referred to as a set of one or more classifiers. In some implementations, the first layer 230 includes one or more classifiers. For example, the classifier(s) can analyze the generated feature(s) and make a determination (e.g., as a binary outcome) of whether a meal has occurred at a given time. In some implementations, one or more of a Random Forest Classifier, a logistic regression classifier, a K-nearest neighbors classifier, an extra-trees classifier, and/or a gradient-boosted tree classifier can be used. In some implementations, one or more of a linear classifier, support vector machine, quadratic classifier, kernel estimator, a boosting classifier, a decision-tree classifier, a neural network, and/or a learning-vector quantization classifier can be used. [0079] The data in the inputs 210 can be organized according to one or more measures of time, and the first layer 230 can operate accordingly. In some implementations, the inputs 210 can include discrete values associated with respective time intervals, sometimes referred to as time points. Any length of time interval can be used. For example, each value can be associated with a respective 15-minute or 5-minute time interval or time point (e.g., based on the sampling frequency of a CGM). The first layer 230, moreover, can generate one classification event (e.g., an outcome reflecting a classification of meal or no meal, or a classification of whether a meal has a particular size) for each classifier for each time point. For example, the first layer 230 can predict that no meal occurred at a particular time point even if the bolus information indicates (e.g., by a pen cap removal) that a bolus was injected at that time point.

[0080] The first layer 230 can use data pertaining to multiple time points to make the classification for each time point. In some implementations, for each time point the classifier(s) can take into account the data from a time interval (e.g., one hour of future, or later-detected, data) in making its classification. For example, this can account for the fact that the physiological effect of carbohydrate consumption is not instantaneous but rather can be distributed over time. As a result the classifier(s) of the first layer 230 can likely detect multiple meal events in nearby (e.g., adjacent) time points. Moreover, if multiple classifiers are used in the first layer 230, each one can potentially give a different (e.g., slightly different) result based on substantially the same input data. For example, aggregation of the results of multiple classifiers can then be performed, such as along the lines exemplified later in this description.

[0081] The system 200 can use a second layer 240 of one or more regressors. The second layer 240 can be characterized as including one or more meal prediction localization regressors. The second layer 240 is sometimes referred to as a set of one or more regressors. For example, the meal prediction localization regressors can seek to determine exactly when the meal predicted by the first layer 230 occurred, and/or the size of the meal. In some implementations, the second layer 240 includes one or more regressors. For example, the regressor(s) can analyze the output of the classifier(s) in the first layer 230 and make a determination (e.g., as a binary outcome) of whether a meal has occurred at a given time, or what was the likely size of the meal. In some implementations, the second layer can be based on a standard logistic function, such as a sigmoid function, that takes a real input and outputs a value between zero and one, which can be interpreted as the determined probability that a meal occurred. For example, a Random Forest-based regressor can be used. The second layer 240 can take the output of the classified s) in the first layer 230, and also one or more of the inputs 210, and convert them to a single point (i.e., a single time point) that the second layer 240 considers to be the beginning of the meal detected by the first layer 230. That is, the second layer 240 can provide one result per time interval, wherein the time interval is longer that the time periods considered by the first layer 230. For example, the second layer 240 can generate one result per hour of data when the first layer 230 gives output for each 15-minute time point. In some implementations, the output of the second layer 240 can be in form of one or more values. For example, a zero output can correspond to determination of a meal beginning in the first 15 minutes of the hour, a one output can correspond to determination of a meal beginning in the second 15 minutes of the hour, and so on. In the just described example, a negative value in the output of the second layer 240 can correspond to no meal being detected. The output of the second layer 240 (e.g., integer values) can be converted into a time lap of Boolean values (e.g., by the system 200 or another system). For example, a false or zero value can represent no meal event for the time point, and a true or one value can represent a meal event for the time point.

[0082] The system 200 can include an evaluation 250. In some implementations, the evaluation 250 can be characterized as a comparison of the outcome(s) of the second layer 240 with one or more other things (e.g., with at least one of the inputs 210). For example, the evaluation 250 can be characterized as an announced-bolus comparison. In some implementations, the evaluation 250 can correspond to a prediction regarding one or more characteristic relating to the person with diabetes. For example, the evaluation 250 can generate a prediction that the person missed a bolus; that is, that the person did not timely receive insulin for an ingested meal. In some implementations, the meal prediction(s) of the second layer 240 can be directly compared with the bolus information of the inputs 210. Any detected meal that does not have a corresponding detected bolus event within a predetermined time period (e.g., on the order of one hour) can be declared as a missed bolus event; that is, as a missed bolus.

[0083] The system 200 can generate one or more outputs 260. The outputs 260 can be the direct result of the evaluation 250. In some implementations, the outputs 260 can be a time map that represents detected events (e.g., meals, sizes of meals, and/or any missed boluses). For example, the outputs 260 can be a time map where a true or one value can represent a missed bolus for the time point corresponding to the estimated time of the meal, and a false or zero value can represent no missed bolus for the time point.

[0084] Operation of the system 200 can illustrate performance of a computer- implemented method of detecting a missed bolus. Such a method can include receiving blood glucose values (e.g., in the inputs 210) and bolus information (e.g., in the inputs 210) regarding a person with diabetes, the blood glucose values and the bolus information relating to a period of time. The method can include receiving a meal size propensity record regarding the person. The method can include classifying (e.g., using the first layer 230), based on the blood glucose values, the bolus information, and the meal size propensity record, each of multiple time periods within the period of time regarding whether the time period is associated with ingestion of a meal by the person. The method can include performing regression analysis (e.g., by the second layer 240) on the classified multiple time periods to identify a first time period of the classified multiple time periods as corresponding to a beginning of the meal. For an identified time period, the bolus information can indicate (e.g., as indicated by the evaluation 250) no bolus associated with the identified first time period. The method can include associating (e.g., in the outputs 260), based on the regression analysis, a missed bolus event with the meal. One or more actions can be performed based on the missed bolus event having been associated with the meal. For example, the action can include issuing an alert regarding the person.

[0085] The system 200 can be included in one or more devices or other apparatuses.

In some implementations, the system 200 is included in an insulin treatment device. For example, the insulin treatment device can be, or include, a smartphone, a pen cap for an insulin pen, an insulin pen, an insulin pump, a CGM, or a BGM. The system 200 can have a user interface and an alert regarding the person can be issued or generated using the user interface, the alert being based on the missed bolus event being associated with the meal.

[0086] The system 200 was tested using simulated data for a fictitious yet statistically representative population. The results represent both the ability to predict meals and to detect missing boluses. For both meal prediction and missed boluses, the results are characterized with regard to both precision and recall, in terms of positive values and negative values. For meal prediction, a positive value means that a meal was predicted at a certain time point, and a negative value means that a meal was not predicted at the certain time point. For missed bolus, a positive value means that a missed bolus was predicted at a certain time point, and a negative value means that a missed bolus was not predicted at the certain time point.

Precision is defined as the ratio between the number of true positive values and the sum of true and false positive values. That is, the precision answers the question: Of all values (e.g., time points) that the system 200 labeled as true (e.g., as being a meal, or as being a missed bolus), how many were actually true? Recall is defined as the ratio between the number of true positive values and the sum of true positive values and false negative values. That is, the recall answers the question: Of all values (e.g., time points) that the system 200 should have labeled as true, how many were correctly labeled? The following table shows examples of results:

[0087] Here, all of the test runs used a standard chance of a missed bolus (e.g., 10%). To simulate very large and very small meals (e.g., a snack), the meal standard deviation (STD) was doubled in the second test run. The noise factor was increased from each test run to the next. The results show that increasing the noise factor can significantly increase the false positive rate for missed boluses, and thereby decrease the precision.

[0088] FIG. 3 shows an example of input and output for meal and/or missed-bolus detection. Here, the input includes input data 300 and the output includes output data 350. The input data 300 and/or the output data 350 can be used with (e.g., generated by and/or used by) one or more systems or devices described elsewhere herein. For example, the input data 300 can be, or be part of, the inputs 210 (FIG. 2) and the output data 350 can be, or be part of, the outputs 260 (FIG. 2).

[0089] The input data 300 is here presented as a graph in a coordinate system having a blood-related value (e.g., EGV, such as in units of milligrams/deciliter (mg/dl)) on the vertical axis, and having time (e.g., in time points of a predefined sampling interval, such as 15 minutes) on the horizontal axis. The input data 300 here includes multiple sampled values 302, which are illustrated as circles. For example, each of the sampled values 302 corresponds to an EGV estimation performed by a CGM. The graph also shows, for purpose of clarity, multiple true values 304, which are illustrated as a continuous line that connects respective ones of the sampled values 302 to each other. The true values 304 may not be part of the input data 300; rather, the true values can represent the actual EGV values of the person with diabetes if determined continuously. That is, the sampled values 302 represent periodic samplings of the true values 304. The input data 300 here includes a line 306 corresponding to one or more announced boluses. For example, an entry 308 on the line 306 indicates that a bolus was announced as being injected at a time 310. Because carbohydrates affect blood glucose values over a finite time following ingestion of a meal, and because administered insulin can act on a shorter time scale (e.g., rapid-acting insulin) or a longer time scale (e.g., long-acting insulin), the system can wait at least a predetermined amount of time after the detected beginning of a meal before making a determination whether a bolus is missed or is injected late relative to the meal.

[0090] The output data 350 is here presented as a diagram in a coordinate system having predictions made or announcements detected on the vertical axis, and having time (e.g., in time points of a predefined sampling interval, such as 15 minutes) on the horizontal axis. The output data 350 here includes a line 352 corresponding to prediction of one or more meals, and a line 354 corresponding to announcements of one or more injected boluses, or a predicted bolus. For example, an entry 356A on the line 352 indicates that a meal has been predicted as beginning at the time 310. Moreover, an entry 356B on the line 354 corresponds to the entry 308 in the input data 300 and indicates that a bolus was announced. Because the entry 356B is sufficiently contemporaneous with the entry 356A(e.g., coincident, or at least within the same hour), the bolus associated with the entry 356B can be considered timely with regard to the meal associated with the entry 356A. That is, by the entry 356B being associated with the entry 356A, the system can decide not to associate the corresponding meal with a missing bolus event or a late bolus event.

[0091] Here, the output data includes an entry 358A on the line 352 that corresponds to another prediction of a meal. On the line 354, however, there is no entry corresponding to the entry 356B discussed above, meaning that the input data 300 does not contain a bolus announcement corresponding to a time 360. Rather, an entry 358B which occurs on the line 354 at the time 360 can represent a predicted bolus and/or a determined missed bolus. For example, based on determining the entry 358A (i.e., a predicted meal) the entry 358B can represent an expectation by the system that a bolus should be announced in connection (e.g., coincident, or at least within a predefined time) with the detected meal. As another example, after the meal is detected and it is determined that no bolus announcement corresponds to the meal, the entry 358B can represent the determination that a bolus was missed for the detected meal. That is, when bolus information in the input data 300 includes no bolus separated from the time period of the entry 358Aby at most a predefined time, this can trigger a determination of no bolus being associated with the identified time period. The determination of a missed bolus can trigger performance of one or more actions, including, but not limited to, issuance of an alert or a recommendation, or an automatic bolus injection, for example as described elsewhere herein. [0092] A determination of a missed bolus can be the basis for issuing a communication to or for the benefit of the person with diabetes regarding their therapy, which communication can sometimes be referred to as an “insight”. The insight can be communicated to the person directly (e.g., by way of a controller or other electronic device) and/or indirectly (e.g., by way of sending the insight to the person’s health care provider to serve as a basis for coaching the person). In some implementations, an insight can indicate that the person misses meal boluses on a regular basis. For example, after analysis of about one week of data or more, a system can generate an insight communicating that the person appears to have missed, say, three boluses during that time. As another example, the insight can convey that the person appears to miss morning boluses on a regular basis.

[0093] The output data 350 can indicate one or more late boluses. In some implementations, an entry 358C on the line 354 can indicate that a bolus announcement was made at a time 362 (the bolus announcement not shown in input data 300 for simplicity). However, the input data 300 may not have predicted any meal as occurring within a predetermined time (e.g., one hour) of the time 362. Rather, the entry 358C can therefore be deemed to be a late bolus injection for a meal that occurred sometime earlier. Here, for example, the entry 358C can be considered a late bolus event for the meal corresponding to the entry 358A. That is, when bolus information in the input data 300 does include a bolus separated from the time period of the entry 358Aby more than a predefined time, then a late bolus event can be associated with the announced bolus. The determination of a late bolus event can trigger performance of one or more actions, including, but not limited to, issuance of an alert or a recommendation, for example as described elsewhere herein.

[0094] FIG. 4 shows an example of feature generation, and aggregation and scaling of one or more features. The features can be managed using the feature component 220, for example as part of the system 200 (FIG. 2). The feature component 220 can include a feature generation component 400. In some implementations, the feature generation component 400 can generate one or more features based on the inputs 210 (FIG. 2). For example, the feature generation component 400 can generate a feature corresponding to a smoothed EGV, a feature corresponding to a rate of change (ROC) of EGV, a feature corresponding to a derivative (ROC’) of the ROC of the EGV, a feature corresponding to whether a bolus is detected within a predetermined time period (e.g., one hour) of a detected beginning of a meal, a bolus probability density (e.g., a bolus probability by time of day), a geometric mean of the next hour of data (sometimes referred to as m*), a geometric standard deviation of the next hour of data (sometimes referred to as s*), a geometric mean of the entire iteration of data (sometimes referred to as p* iobai), and/or a geometric standard deviation of the entire iteration of data (sometimes referred to as a* iobai). The m and s features can be used to give the system a sense of how the local (e.g., the hour of interest) data differs from the global data (i.e., the entire iteration). In some implementations, the system can operate based on the assumption that, on average, after a meal the person with diabetes will have a higher m* and s* since the blood glucose should be increasing rapidly within the one-hour period. This can be compared to the average (global) values across the entire iteration for reference. As another example, a difference between local and global values can be used. Other features can be generated and/or used.

[0095] The feature component 220 can include a feature aggregation component 410. In some implementations, the feature aggregation component 410 aggregates one or more features over a predetermined time period (e.g., by also taking into account future and/or past feature values). For example, the feature aggregation component 410 can aggregate the next one-hour time period’s worth of feature values at each time point. Other aggregations can be used.

[0096] The feature component 220 can include a feature scaling component 420. The feature scaling component 420 can seek to bring a feature away from large numerical values to avoid giving undue significance to that feature. For example, the feature scaling component 420 can subtract the mean of the (aggregated) feature from the feature value(s) and/or can divide the (aggregated) feature value(s) with the standard deviation of the feature values.

[0097] FIG. 5 shows an example of features 500, 502, and 504 relating to EGV and rates of change. The features 500, 502, and 504 can be used with one or more other features described herein. The features 500, 502, and 504 can be used with one or more systems or devices described elsewhere herein. Each of the features 500, 502, and 504 is presented as a series of data points 500A, 502A, and 504A, respectively, which represent values of the feature on a vertical axis associated with time measured against a horizontal axis. The data points 500A, 502A, and 504A can be connected by a continuous line, which may be an interpolation performed on the input data or on data calculated from the input data. In some implementations, a linear interpolation of the respective data points 500A can be performed though any time points in the feature 500 that are not associated with values. For any remaining time points in the feature 500 that are not associated with values, they can instead be associated with the mean of the signal values. In some implementations, a linear interpolation can be performed for any missing data except missing data at the beginning or end of a sequence of data (e.g., one week of data). For example, the interpolation may require data to be present at the beginning and end of the interval of missing data. In contrast, for one or more missing beginning or end data points, a substitute value can be used. For example, the global mean of the values in the sequence of data can be used. In some implementations, the substitute value can include a mean of values that are local to the missing data.

[0098] In some implementations, the feature 500 can be characterized as signal values and may be present (e.g., as raw data) in an input signal. For example, the feature 500 can correspond to EGV for a person with diabetes (e.g., obtained from a CGM). Here, the feature 500 includes an upward slope 505A followed by a downward slope 505B. The feature 500 can be smoothed in one or more processing steps. In some implementations, the smoothing can involve performing a convolution on at least part of the feature 500. For example, a Savitsky-Golay filter can be applied.

[0099] In some implementations, one or more other features (e.g., the feature 502 and/or 504) can be derived from input data, such as from the feature 500. Such feature(s) can be derived to obtain more informative and/or more convenient representations of data. In some implementations, the feature 502 can correspond to a ROC of the signal values (e.g., a derivative of the EGV). Here, the feature 502 includes a region 506A of positive values corresponding to the upward slope 505A, and a region 506B of negative values corresponding to the downward slope 505B. Here, the feature 502 includes an upward slope 508A and a downward slope 508B.

[0100] In some implementations, the feature 504 can correspond to a ROC of the ROC of the signal values (e.g., a second derivative of the EGV). Here, the feature 504 includes a region 510A of positive values corresponding to the upward slope 508A, and a region 510B of negative values corresponding to the downward slope 508B.

[0101] FIG. 6 shows an example of spreading out data 600 of a feature. The data 600 can be used with one or more other features described herein. The data 600 can be used with one or more systems or devices described elsewhere herein. The data 600 includes data points 602 and 604 corresponding to feature values indicated against a vertical axis and associated with time points along a horizontal axis. In some implementations, the data points 602 and 604 correspond to bolus announcements. For example, each of the data points 602 and 604 can represent a detection or determination that a person with diabetes injects a bolus of insulin.

[0102] The data point 602 is here positioned at a time point A, and the data point 604 at a time point B, on the time axis. In some implementations, the data points 602 and 604 can have essentially no extension in time (that is, in the horizontal direction in the present illustration). Rather, each of the data points 602 and 604 can be characterized as a “spike” and can correspond to a delta function as follows: data point 602 = 5(t — A ), and data point 604 = 5(t — B ), where t is the measure of time and d is the Dirac delta function.

[0103] A feature relating to boluses (e.g., bolus announcement) can be used to give some information on when boluses actually occurred. However, instead of directly using the spikes corresponding to the data points 602 and 604 in the raw data as a feature, one can make the bolus information less informative in one or more ways. In some implementations, the bolus information can be broadened to have a finite time duration. Here, data 600’ results from such broadening and includes a shape 602’ corresponding to the data point 602, and a shape 604’ corresponding to the data point 604. In some implementations, the shape 602’ and/or 604’ is a rectangle. For example, the shapes 602’ and/or 604’ can be formed by convolving the respective delta function with a rectangle function. The shape 602’ can be centered at the time A and the shape 604’ can be centered at the time B. In some implementations, each of the shapes 602’ and/or 604’ can extend for a predetermined time. For example, the shape 602’ can extend for one hour before, and one hour after, the time A, for a spreading of the bolus information over two hours in this example. Similarly, the shape 604’ can be spread over a predetermined time, such as two hours. The predetermined time can be a multiple of a time relevant to insulin treatment. In some implementations, the predetermined time over which bolus information is spread can be a multiple of the maximum delay between the beginning of a meal and administration of the corresponding bolus. For example, when the diabetes management system waits one hour after the beginning of a meal until determining whether a bolus is missing, then the duration of the shape 602’ and/or 604’ can be a number of hours (e.g., two hours). Temporal broadening or spreading of bolus information can have advantages in data analysis. Without broadening, a classifier may excessively rely or only rely on the bolus information (e.g., the presence of a bolus announcement) to predict when meals occurred, thereby missing (i.e., failing to predict) every meal that does not have an associated bolus announcement. In an implementation that at least in part seeks to detect missed boluses, such a result would defeat the purpose of the detector. Therefore, to decrease the chance of such overfitting, the bolus information can be made less informative (without omitting the bolus information), so that the classifier(s) will take into account also other features. [0104] FIG. 7A schematically shows an example of aggregating bolus information 700. The information 700 can be used with one or more other features described herein. The information 700 can be used with one or more systems or devices described elsewhere herein. The information 700 includes data points corresponding to feature values indicated against a vertical axis and associated with time points along a horizontal axis. Particularly, the information 700 includes data points 702 within a time interval 704, data points 706 within a time interval 708, and data points 710 within a time interval 712. In some implementations, the data points 702, 706, and 710 correspond to bolus announcements. For example, each of the data points 702, 706, and 710 can represent a detection or determination that a person with diabetes injects a bolus of insulin. The time intervals 704, 708, and 712 can be of equal length (e.g., 24 hours each). That is, the period of time to which the information 700 pertains (e.g., a number of days) can be subdivided into shorter time intervals such as the time intervals 704, 708, and 712.

[0105] A wrapping of the information 700 can be performed. In some implementations, this involves wrapping the bolus events corresponding to the data points 702, 706, and 710 over a shorter time interval, such as one of the time intervals 704, 708, and 712. Here, information 700’ (shown in a separate diagram for clarity), includes the data points 702, 706, and 710 wrapped over a time interval 714, so that the data points 702, 706, and 710 are distributed over the time interval 714. The time interval 714 has the same length as each of the time intervals 704, 708, and 712 (e.g., 24 hours). This can be considered an aggregation of bolus information, for example so that bolus events are aggregated. The information 700’ gives an estimate of when, throughout the course of a predetermined time interval (e.g., a 24-hour period), the bolus events tend to occur, on average.

[0106] The information 700’ can be subjected to one or more kinds of processing. In some implementations, a smoothing and/or estimation can be performed. For example, a kernel smoothed density estimate 716 can be performed on the bolus information (e.g., bolus events) in the information 700’. The kernel smoothed density estimate 716 can estimate, based on the information 700’, the probability density function for the bolus events represented by the data points 702, 706, and 710. The outcome of performing the kernel smoothed density estimate 716 can be information 700” in its leftmost instance in the illustration, which is a continuous distribution of likelihood over a time interval 714’. The time interval 714’ here corresponds to the time interval 714 for the information 700’, and the information 700” corresponds to a continuous probability distribution that is based on the bolus events in the information 700’. The information 700” can be characterized as bolus probability density by time interval (e.g., bolus probability density by day), and can be used for one or more purposes. The information 700” can be a likelihood vector of predetermined length (e.g., 24 hours). The bolus probability density of the information 700” represents the estimated likelihood, at any time point, that the person with diabetes will inject insulin. For example, bolus probability density can be used as a proxy for meal occurrence likelihood. In some implementations, another operation than the kernel smoothed density estimate 716 can be performed on the information 700’ to generate the information 700”. For example, a filtering of the information 700’ can be performed.

[0107] The information 700” can be replicated one or more times to extend the continuous distribution of likelihood over a longer time. Here, the leftmost instance of the information 700” is replicated into a time interval 717 that is adjacent the time interval 714’, and also into a time interval 718 that is adjacent the time interval 717. As such, three instances of the information 700” are shown. For example, this replication shows an estimate of bolus probability density over a three-day period. Any number of replications can be performed.

[0108] A meal probability density can be similar or identical to a bolus probability density for the same person with diabetes. FIG. 7B shows an example of a meal probability density 720. The meal probability density 720 is a continuous probability distribution that can be based on the information 700’, or directly on the bolus events in the information 700’. For example, based on blood glucose values and bolus information in input data, the meal probability density 720 for the person can be generated. The meal propensity of the meal probability density 720 represents the estimated likelihood, at any time point, that the person with diabetes will ingest a meal. The meal probability density 720 can be used for one or more purposes. In some implementations, the meal probability density 720 can be used in an estimation of whether the person with diabetes will ingest, or has recently ingested, a meal. For example, the determination whether the person has missed a bolus can be based at least in part on the determination, using the meal probability density 720, that the person has ingested a meal.

[0109] As mentioned, an action (e.g., alerting for a missed bolus) can be generated based on at least one threshold being met. Such threshold(s) can be dynamically adjusted based on the meal probability density 720. In some implementations, the threshold can be adjusted based on whether the value of the meal probability density 720 at the current time is relatively high or relatively low. For example, a relatively lower threshold for the alert can be used when the meal probability density 720 indicates that a current meal probability is relatively higher. As another example, a relatively higher threshold for the alert can be used when the meal probability density 720 indicates that a current meal probability is relatively lower.

[0110] Generating the meal probability density 720 can involve using a bolus probability density as a proxy for meal occurrence likelihood. After the information 700” is generated, the meal probability density 720 can be obtained from the information 700”. As another example, after the meal probability density 720 is generated, the information 700” can be obtained from the meal probability density 720.

[0111] The above examples illustrate performance of a method of determining a personalized meal propensity. Such a method can include receiving bolus information (e.g., the data points 702, 706, and 710) regarding a person with diabetes, the bolus information comprising bolus events distributed within a period of time (e.g., three days). The method can include wrapping the bolus information over a time interval (e.g., the time interval 714) shorter than the period of time so that the bolus events are distributed within the time interval (e.g., as information 700’). The method can include generating a meal probability density (e.g., the meal probability density 720) based on the wrapped bolus information, wherein the meal probability density is a continuous function of time over the time interval. Such a method can be performed in or by one or more devices or other apparatuses. In some implementations, the method is performed in an insulin treatment device. For example, the insulin treatment device can be, or include, a smartphone, a pen cap for an insulin pen, an insulin pen, an insulin pump, a CGM, or a BGM.

[0112] Bolus information can include amount information about the boluses. For example, the person with diabetes can input the amount information into the system (e.g., a smartphone). As another example, an insulin treatment device can have a dose capture function that registers or estimates the bolus amount and provides that information to one or more other components. The information 700” can then additionally indicate the likely amount of the bolus, in addition to the likelihood of a bolus being administered. Based on input data (e.g., blood glucose values and bolus information) and the meal probability density 720, an expected bolus amount can be determined. For example, based on knowing that the person with diabetes usually has a meal at a time of T hours in the day, and that the bolus amount is usually B units of insulin for that meal, and that the current time is approximately T hours, an expected bolus amount of B units can be determined. The bolus information regarding the currently (or most recently) administered bolus amount can then be compared to the expected bolus amount. One or more actions can be taken based on the outcome of such a comparison. For example, an alert can be issued regarding the person (e.g., substantially in real time) based on a discrepancy between the amount information and the expected bolus amount.

[0113] Information about administered boluses can be used in one or more types of insulin treatment systems. In an automated system that controls an insulin pump (e.g., a closed-loop insulin therapy system), such bolus information can be used in calculating a bolus amount to be automatically administered to the person by the system. For example, the bolus can be administered based on detecting a rise in blood glucose level at a time when the person normally or usually eats, yet the system is not detecting a request for a meal bolus at that time. In an insulin therapy system that does not have automatic bolusing (e.g., a system where the person is responsible for manually injecting themselves with insulin using an insulin pen or other device), one or more insights can be generated. In some implementations, an insight can be triggered by detection of a meal of a size that is out of the ordinary (e.g., abnormal) for the person. For example, the insight can communicate that the person tends to have poorly managed blood glucose levels whenever they ingest a relatively small or relatively large meal. In some implementations, an insight can be triggered by detection of falling glucose levels. For example, the insight can communicate a message along the lines of “Today at lunch you only bolused 3 units; you normally bolus 10 units and you currently have an elevated blood glucose level.” As another example, the insight can communicate a message along the lines of “Your blood glucose levels are rapidly falling and you bolused 10 units of insulin, more than twice your normal lunch time insulin; consider treatment options.” Other insights and/or conditions for triggering an insight can be used.

[0114] More than one version of the meal probability density 720 can be generated. In some implementations, the meal probability density 720 can be specific to one or more particular days of the week for the person with diabetes, and one or more other meal probability densities can then be generated for the other day(s) of the week. For example, the person may have a meal probability density for weekdays that differs from a meal probability density for weekend days. In some implementations, one or more thresholds for a feature in a machine-learning classifier (e.g., in the first layer 230 of FIG. 2) can be changed based on the meal probability density 720. For example, the classified s) can be configured to more readily classify a time point as being a meal if the meal probability density 720 indicates a higher likelihood that the person with diabetes ingests meals at the time point. As another example, the meal probability density 720 can be taken into account in insulin therapy management by reducing a threshold for determining that a bolus was missed; that is, for associating a missed bolus event with a detected meal.

[0115] FIG. 8 schematically shows an example of aggregating feature information 800 into aggregated feature information 800’. The feature information 800 and/or the aggregated feature information 800’ can be used with one or more other features described herein. The feature information 800 and/or the aggregated feature information 800’ can be used with one or more systems or devices described elsewhere herein.

[0116] The aggregated feature information 800’ can be formed from the feature information 800. The formation can involve aggregation over a period of time, or a fixed number of samples, to name just two examples. In some implementations, the feature information 800 can be labeled as individual data points Xi, where i is an index. The individual feature values in the feature information 800 can include any type of feature, including, but not limited to, blood glucose values and/or bolus information. For every data point Xi in the feature information 800, the aggregated value in the aggregated feature information 800’ can be labeled f(Xi, Xi+i„ Xi+2, Xi+3), indicating that in this example each aggregated data point Xi’ in the aggregated feature information 800’ is a function of (e.g., an aggregation of) four data points from the feature information 800, labeled Xi, Xi+i„ Xi+2, Xi+3, respectively. As such, a data point 802’ in the aggregated feature information 800’ can be formed as an aggregation of a group 802 of data points in the feature information 800. Similarly, a data point 804’ in the aggregated feature information 800’ can be formed as an aggregation of a group 804 of data points in the information 800, a data point 806’ in the aggregated feature information 800’ can be formed as an aggregation of a group 806, and a data point 808’ can be formed as an aggregation of a group 808. In this example, each of the data points 802’ through 808’ is an aggregation of the future hour of feature data from the feature information 800. The aggregated feature information 800’ can be provided, alone or in combination with other information, to one or more classifiers (e.g., in the first layer 230 in FIG. 2). Two or more aggregations can overlap with each other. For example, each of the groups 802 through 808 includes at least one data point that is also included in another one of the groups 802 through 808. Other ranges and/or approaches for aggregation can be used. For example, a longer or shorter aggregation interval can be used. As another example, data points earlier in time (i.e., in the past) and/or later in time (i.e., in the future) can be aggregated. The terms “past” and “future” are here used relative to the point in time of the aggregated feature information (i.e., the time to which the information is being aggregated).

[0117] FIG. 9 schematically shows an example of classification based on a feature. Here, feature information 900 will be used for generating classifier output 902 by feeding into one or more machine-learning classifiers 904 (e.g., in the first layer 230 of FIG. 2). The feature information 900 is indicated as a value (e.g., a scaled one-hour aggregated feature) measured against a vertical axis as a function of time measured against a horizontal axis. The feature information 900 and/or the classifier output 902 can be used with one or more other features described herein. The feature information 900 and/or the classifier output 902 can be used with one or more systems or devices described elsewhere herein.

[0118] In some implementations, the one or more machine-learning classifiers 904 are configured to predict, based on the feature information 900, when the person with diabetes ingests a meal. Each classifier can make a binary output for one or more points in time. In some implementations, the machine-learning classifiers 904 make outputs (e.g., a determination of meal or no meal) for every point in time. Any time interval between determinations can be used. For example, the machine-learning classifiers 904 can make a determination for every 15 minutes of the feature information 900. The outputs of the machine-learning classifiers 904 can be separate from each other in the classifier output 902. For example, each of lines 906, 908, 910, and 912 here corresponds to an output of a different classifier, which classifiers will here be referred to as classifiers A, B, C, and D, respectively. On each of the lines 906 through 912, one or more meal determinations can be indicated.

[0119] The machine-learning classifiers 904 may arrive at different conclusions regarding one or more time points. Here, for example, at a time 914 the classifier C, but none of the classifiers A, B, or D, determines that a meal takes place. At time 916, moreover, all of the classifiers A-D indicate that no meal is being ingested. At a time 918, finally, all of the classifiers A-D indicate that a meal is being ingested. Accordingly, there can be zero or more classifier outputs for each time point. Also, the machine-learning classifiers 904 can tend to classify multiple consecutive time points as being meals. In some situations, this can be because the person with diabetes ingested the meal over an extended time. In other situations, however, this can be caused by the relatively slow impact of carbohydrates on blood glucose levels, and/or by the relatively fast or slow action by the administered insulin. In some implementations, regression analysis (e.g., by the second layer 240 in FIG. 2) can be applied to such classifier output in an attempt to identify the beginning of a meal.

[0120] FIG. 10 schematically shows an example of regression based on classification. The regression takes classifier output 1000 and uses it (e.g., by the second layer 240 in FIG.

2) to generate regressor output 1002. The classifier output 1000 is indicated as individual binary values (e.g., determinations of meal or no meal by individual classifiers) as a function of time measured against a horizontal axis. The feature classifier output 1000 and/or the regressor output 1002 can be used with one or more other features described herein. The classifier output 1000 and/or the regressor output 1002 can be used with one or more systems or devices described elsewhere herein.

[0121] An individual output in the regressor output 1002 can be based on a range (or window) of the classifier output 1000. Here, an output 1004’ in the regressor output 1002 is based on a range 1004 of the classifier output 1000. Similarly, an output 1006’ is based on a range 1006, and an output 1008’ is based on a range 1008. In some implementations, the range can be about three hours. Other (shorter and/or longer) ranges can be used. Two or more of the ranges 1004-1008 can overlap with each other. The range(s) can have any of multiple temporal relations to the regressor value being determined. Here, the output 1004’ represents the center hour (e.g., middle hour among three hours) of the range 1004. Similarly, the output 1006’ represents the center hour of the range 1006, and the output 1008’ represents the center hour of the range 1008.

The regressor output 1002 can have any suitable format that conveys whether the regression determines a meal is occurring, or did occur, at the specified time(s). In some implementations, the regressor output 1002 is integer based. For example, the regressor(s) can assign one type of value (e.g., a negative integer) to indicate a determination of no meal, and another type of value (e.g., zero or a positive integer) to indicate a determination of a meal. In some implementations, the regressor output 1002 can be issued less often than the individual time points on which the classifier output was based (e.g., the classifier(s) may have generated the classifier output once for every 15-minute period). For example, with every hour the regressor(s) can issue one output (e.g., a single integer) that indicates at what time during that hour the meal is determined to have begun. In some implementations, different (positive) integer values can code respective shorter time periods. For example, the integer zero can indicate the first quarter of an hour, the integer one can indicate the second quarter, and so on.

[0122] Training data can be used. In some implementations, training data reflecting distribution of a blood protein within a population can be used. The training data can be generated from simulated data and/or from data obtained from one or more actual persons with diabetes. In some implementations, the distribution can be indicated in terms of a cumulative probability density measured against a vertical axis, and feature values measure against a horizontal axis. Training data can be used with one or more other features described herein. Training data can be used with one or more systems or devices described elsewhere herein. For example, the training data indicates the probability density for different values of the blood protein AIC.

[0123] FIG. 11 shows an example of a system 1100 for diabetes management. The system 1100 can be used in combination with, or can include aspects of, one or more other examples described elsewhere herein. Here, the system 1100 includes an insulin injection pen 1102. In some implementations, the insulin injection pen 1102 is considered an insulin injection pen for a certain type of insulin, such as a rapid-acting insulin pen. For example, the insulin injection pen 1102 is a Humalog™ pen, a Novolog™ pen, or an Apidra™ pen. Here, the system 1100 includes an insulin injection pen 1104. In some implementations, the insulin injection pen 1104 is considered an insulin injection pen for a certain other type of insulin having an active time that is longer than an active time for the certain type of insulin, such as a long-acting insulin pen. For example, the insulin injection pen 1104 is a Lantus™ pen, a Levemir™ pen, a Toujeo™ pen, or a Tresiba™ pen. Here, the system 1100 includes a glucose monitor 1106 (e.g., a CGM) or another glucose sensor, and a remote user interface device 1108. As shown, each insulin injection pen 1102 and 1104 includes a corresponding pen cap 1110 and 1112, respectively, which are in wireless communication with other components of the system 1100. As shown, the insulin injection pens 1102 and 1104 can include dials 1114 and 1116, respectively, for a user to set a dosage to be delivered, and a respective dose indicator window 1118 and 1120. In some implementations, one or more of the insulin injection pens 1102 and/or 1104 may include dose-capture technology and/or be in wireless communication with other components of the system 1100. Additional details about possible insulin pens and/or insulin pen caps are exemplified below.

[0124] Glucose monitor 1106 or another glucose sensor can include any suitable sensor device and/or monitoring system capable of providing data that can be used to estimate one or more blood glucose values. As shown, glucose monitor 1106 or another glucose sensor can be a sensor configured to transmit blood glucose data wirelessly. For example, the glucose monitor 1106 or another glucose sensor can include an optical communication device, an infrared communication device, a wireless communication device (such as an antenna), and/or chipset (such as a Bluetooth device (e.g., Bluetooth Low Energy (BLE), Classic Bluetooth, etc.), an NFC device, an 802.6 device (e.g., Metropolitan Area Network (MAN), a Zigbee device, etc.), a WiFi device, a WiMax device, a Long Term Evolution (LTE) device, cellular communication facilities, etc.), and/or the like. The glucose monitor 1106 or another glucose sensor may exchange data with a network and/or any other devices or systems described in the present disclosure. In some cases, the glucose monitor 1106 or another glucose sensor can be interrogated with an NFC device by the user moving one or more components of the system 1100 near the glucose monitor 1106 or another glucose sensor to power the glucose monitor 1106 or another glucose sensor, and/or to transmit blood glucose data from the glucose monitor 1106 or another glucose sensor, to other components of system 1100. For example, the pen cap 1110 and/or 1112 can exchange data with (e.g., obtain glucose values from) the glucose monitor 1106 or another glucose sensor by being brought in close proximity thereof.

[0125] As shown, remote user interface device 1108 is a smartphone in some examples. In some implementations, any suitable remote user interface device can be used, including, but not limited to, a computer tablet, a smartphone, a wearable computing device, a smartwatch, a fitness tracker, a laptop computer, a desktop computer, a smart insulin pen (e.g., the pen caps 1110 and/or 1112), and/or other appropriate computing devices. As shown in the exemplary user interface of the exemplary mobile app running on the depicted smartphone, the user interface can include a bolus calculator button 1122 and optionally other buttons for the user to enter data or to request recommendations. The exemplary user interface can also or instead include a display of blood glucose data (e.g., past, present, and/or predicted). As shown, the user interface includes a graph 1124 of historical data (e.g., from the previous 30 minutes), a continuation 1126 of that graph having projected data, a point indicator 1128 showing the current (or most recent) estimated blood glucose value, and a display 1130 of the current (or most recent) estimated blood glucose value. The user interface can also or instead include text 1132 explaining the glucose data, text 1134 and/or text 1136 providing suggested actions. For example, text 1134 can provide insulin, carbohydrates, or other therapy suggestions. For example, text 1136 can suggest that the user obtain blood glucose data. In some cases, the user interface can permit the user to click on the glucose data or otherwise navigate in the mobile app to obtain more detailed or more complete blood glucose data. In some implementations, the user interface can also or instead provide one or more insights for the benefit of the person with diabetes. For example, an insight can communicate a message along the lines of “You normally have a meal bolus between noon and 2 PM, but didn’t bolus today and your blood glucose levels are rising. Did you forget to bolus?”

[0126] The user interface can depict insulin data. In some cases, the user interface can indicate an amount 1138 of IOB, which may be only for a particular type of insulin (including, but not limited to, rapid-acting insulin). In some implementations, IOB (sometimes referred to as active insulin) can be defined as the amount of insulin that has been delivered and is still active in the person’s body based on estimated duration of insulin action. In some cases, an IOB calculation may be for both rapid-acting and long-acting insulin. In some cases, the user interface can display information 1140, including, but not limited to, the time and/or amounts of the most recent doses of rapid-acting and/or long-acting insulins. In some cases, the user interface can permit the user to click on the insulin data or otherwise navigate in the mobile app to more detailed and/or more complete insulin delivery data. In some cases, a user interface can overlay blood glucose data and insulin delivery data in any suitable format, such as a graphical display of the timing of blood glucose data vs. the timing of insulin delivery data.

[0127] In use, a user (e.g., the person with diabetes and/or a caregiver) can use the system 1100 to get recommendations regarding an appropriate insulin dosage. In the case of an upcoming need to deliver long-acting insulin, the text 1134 may be changed to provide a recommended long-acting insulin dosage. In some cases, a recommended dosage may appear on pen cap 1110 and/or 1112. In the case of the user wanting to deliver a bolus of rapid-acting insulin, the user may press bolus calculator button 1122 to enter into a bolus calculator. Any suitable bolus calculator could be used in systems, methods, and devices provided herein. For example, the bolus calculator can provide a user interface for a user to enter a meal announcement as either a correction only, a small meal, a normal sized meal, or a large meal. Upon selecting the meal size, the user interface can provide a recommended bolus dosage based on a number of carbohydrates associated with the corresponding button and optionally based upon blood glucose data. Additionally, or alternatively, dose capture pen caps for the insulin injection pen 1102 and/or 1104 can include a user interface that permits the user to obtain a meal bolus recommendation for different types of meals (small, medium, large; breakfast, lunch, dinner; 10 grams carbs, 20 grams carbs, 45 grams carbs; etc.) and/or announce a meal size, including, but not limited to, a small meal, medium meal, or large meal. In some implementations, the text 1132, 1134, and/or 1136 is presented elsewhere than on the user interface device 1108. For example, presentation can be done on the pen cap 1110 and/or 1112.

[0128] The pen cap 1110 and/or 1112 can include at least one display. In some implementations, the pen cap 1110 includes a display 1142. In some implementations, the pen cap 1112 includes a display 1144. The display 1142 and/or 1144 can comprise any suitable type of display technology, including, but not limited to, a dynamic electronic display (e.g., a light-emitting diode display) or a static electronic display (e.g., an E-Ink display). The display 1142 and/or 1144 can present information to a user, including, but not limited to, any information output that is described elsewhere herein. For example, an insulin dosage suggestion and/or an alert or other communication can be presented.

[0129] The pen cap 1110 and/or 1112 can include at least one input control. In some implementations, the pen cap 1110 includes a button 1146. In some implementations, the pen cap 1112 includes a button 1148. The button 1146 and/or 1148 can comprise any suitable type of input technology, including, but not limited to, an electronic switch. The button 1146 and/or 1148 can trigger the corresponding pen cap 1110 and/or 1112 to perform one or more operations, including, but not limited to, any operation that is described elsewhere herein.

[0130] The pen cap 1110 and/or 1112 can record and/or convey one or more types of pen capping information. Pen capping information (e.g., information about when the pen cap is secured to and/or released from the injection pen) can include information about a current capping period (e.g., the time since the last capping), information about a duration of one or more uncappings (which may also be referred to herein as “decapping(s)”), and/or the timing (e.g., time-of-day or time elapsed since) of each uncapping and each capping. For example, capping information can include data reflecting when the pen cap was placed onto the insulin injection pen, data reflecting when the pen cap was removed from the insulin injection pen, or both. In some embodiments, pen capping information may be presented to a user on a display of the pen cap. In some embodiments, pen capping information may be presented by a speaker in the pen cap. For example, in some embodiments, a pen cap may provide a timer clock that counts up from the last time the pen cap was secured to the injection pen. In some embodiments, a pen cap accessory can wirelessly communicate pen capping information to a remote computing device (e.g., the user interface device 1108 and/or a smartphone, tablet, etc.). In some embodiments, one or more accessories or smart delivery devices can detect other events associated with medication delivery actions and use that information in ways that pen capping information is described herein. For example, in some cases an injection pen accessory may be secured to an injection pen such that it can detect the mechanical movement of the dosing mechanism to determine a time of a dose of medication (and optionally but not necessarily an amount of medication delivered at that time).

[0131] Pen capping information may be stored, displayed, and/or analyzed in combination with glucose data to determine user behaviors, such as, for example, whether the person is appropriately dosing insulin for meals and/or to correct elevated blood glucose levels. In some embodiments, pen capping information may be presented on a graphical representation of blood glucose data for the user and presented to a user and/or to a healthcare professional. In some embodiments, blood glucose data from a period of time after each capping event may be evaluated to determine whether the user appropriately dosed insulin for that capping event, e.g., appropriate dose, under dose, or over dose.

[0132] In some embodiments, a pen capping event may be disregarded where other information indicates that a dose was not provided. For example, where no change in the dosage selection of the insulin pen (e.g., a dial) was detected, the event may be disregarded.

In some embodiments, a pen uncapping and recapping event may be disregarded if the total uncapping time is less than a first threshold (e.g., 4-6 seconds). For example, the threshold may be determined by setting it at an amount of time too short to permit for an injection, but long enough to allow a user to check the end of the pen to see if there is insulin remaining or if there is a needle attached to the pen. In some cases, the total decapping time (the time between an uncapping event and the subsequent recapping) for a decapping event may be analyzed in combination with blood glucose data to determine if there was an injection during that decapping event. In some cases, if the total decapping time exceeds a second threshold period of time (e.g., at least 15 minutes, at least 30 minutes, etc.), blood glucose data and the methods described herein for detecting a meal timing may be used to determine an approximate time of an injection.

[0133] Some or all components of the system 1100 can perform one or more operations or functions described elsewhere herein. In some implementations, the system 1100 can determine at least one missed bolus event and associated the event with a meal ingested by the person with diabetes. The system 1100 can issue an alert based on detecting a missed bolus. The alert can be issued substantially in real time (e.g., by allowing for about one hour after the detection of a beginning of a meal before determining that a bolus is missed). The system 1100 can determine insulin use by detecting removal and/or replacement of the pen cap 1110 and/or 1112. The system 1100 can detect an amount of insulin that is injected. In some implementations, the system 1100, or a part thereof, can be an insulin treatment device configured for classifying each of multiple time periods within the period of time regarding whether the time period is associated with ingestion of a meal by the person, and for performing regression analysis on the classified multiple time periods to identify a time period of the classified multiple time periods as corresponding to a beginning of the meal.

The system 1100 can associate a missed bolus event with the meal as applicable.

[0134] FIG. 12 is a perspective view of an example of an infusion pump system 1200. The infusion pump system 1200 can be portable and have a plunger engagement device 1201 to serve as a reusable pump apparatus (rather than a disposable pump device). In such circumstances, the infusion pump system 1200 may comprise a reusable device that houses the control circuitry and the pump drive system within a single housing construct. In some implementations, the infusion pump system 1200 can include a reusable pump device that houses both controller circuitry and a pump drive system. The infusion pump system 1200 can include a housing that defines a cavity in which a fluid cartridge can be received (not shown for simplicity). For example, the infusion pump system 1200 can be adapted to receive a fluid cartridge in the form of a carpule that is preloaded with insulin or another medicine. The pump drive system can act upon the fluid cartridge to controllably dispense medicine through an infusion set 1202 and into the user’s tissue or vasculature. In this embodiment, the user can wear the infusion pump system 1200 on the user’s skin under clothing or in the user’s pocket while receiving the medicine dispensed through the infusion set 1202. Any of multiple possible mechanisms for delivering medicament (e.g., insulin) can be used. In some implementations, the plunger engagement device 1201 of the infusion pump system 1200 may include a retention spring (not shown) that once activated biases the plunger of the fluid cartridge towards a piston rod of the drive system to increase dosage accuracy.

[0135] A user interface 1204 of the infusion pump system 1200 includes a display device 1206 and one or more user-selectable buttons 1208A-1208E. The display device 1206 can include an active area in which numerals, text, symbols, images, or a combination thereof can be displayed. The display device 1206 can be used to communicate a number of settings or menu options for the infusion pump system 1200. For example, the display device 1206 can be used to communicate medicinal delivery information, such as the basal delivery rate, a bolus dosage, a historical record of medicine delivered, the amount of medicine remaining in the fluid cartridge, a communication, an alert, or the like. In another example, the display device 1206 can be used to communicate time and date information, which can be used by the user to determine dosage schedules, bolus delivery times, meal times, or the like.

[0136] Accordingly, the user may press one or more of the buttons 1208A-E to shuffle through a number of menus or program screens that show particular settings and data (e.g., review data that shows the medicine dispensing rate, the total amount of medicine dispensed in a given time period, the amount of medicine scheduled to be dispensed at a particular time or date, the approximate amount of medicine remaining in the fluid cartridge, or the like). Also, the user can adjust the settings or otherwise program the infusion pump system 1200 by pressing one or more buttons 1208A-E of the user interface 1204. Thus, the user can contemporaneously monitor the operation of the infusion pump system 1200 from the same user interface 1204. [0137] The infusion set 1202 can include a flexible tube 1210 that extends from the pump device to a subcutaneous cannula 1212 that may be retained by a skin adhesive patch 1214 that secures the subcutaneous cannula 1212 to the infusion site. The skin adhesive patch 1214 can retain the infusion cannula 1212 in fluid communication with the tissue or vasculature of the user so that the medicine dispensed through the tube 1210 passes through the cannula 1212 and into the user's body. In some implementations, the infusion set 1200 can include a glucose sensor 1216 that can indicate one or more EGVs. The glucose sensor 1216 is here illustrated as a component separate from the infusion set 1202 and the infusion pump for clarity (e.g., the glucose sensor 1216 can be removably attached to the skin of the person with diabetes). In some implementations, the glucose sensor 1216 can be an integrated component. The glucose sensor 1216 can include a CGM and/or a BGM, to name just two examples.

[0138] Some or all components of the infusion pump system 1200 can perform one or more operations or functions described elsewhere herein. In some implementations, the infusion pump system 1200 can determine at least one missed bolus event and associated the event with a meal ingested by the person with diabetes. The infusion pump system 1200 can issue an alert based on detecting a missed bolus. For example, the alert can be issued to a person with diabetes who uses an insulin pump and can communicate a message along the lines of “You typically bolus X units for lunch and today you bolused Y units (or you did not bolus), do you want to increase the bolused amount to X units?” The alert can be issued substantially in real time (e.g., by allowing for about one hour after the detection of a beginning of a meal before determining that a bolus is missed). The infusion pump system 1200 can determine insulin use by detecting that insulin is being injected into the person with diabetes. The infusion pump system 1200 can detect an amount of insulin that is injected via the infusion pump system 1200. In some implementations, the infusion pump system 1200, or a part thereof, can be an insulin treatment device configured for classifying each of multiple time periods within the period of time regarding whether the time period is associated with ingestion of a meal by the person, and for performing regression analysis on the classified multiple time periods to identify a time period of the classified multiple time periods as corresponding to a beginning of the meal. The infusion pump system 1200 can associate a missed bolus event with the meal as applicable.

[0139] FIG. 13 shows an example of a meal size probability density estimate 1300 for a population based on 70 days of data. The meal size probability density estimate 1300 is an example of a meal size propensity record. The meal size probability density estimate 1300 is here presented as a heat map having a vertical axis corresponding to carbohydrates (e.g., in units of grams (g)) and a horizontal axis corresponding to time of day (e.g., in units of hours (hr)). Contents of the heat map indicate respective probabilities. A scale 1302 indicates probability by way of color or other shading. For example, a relatively blue shade can correspond to a relatively high probability. As another example, a relatively white or red shade can correspond to a relatively low probability. The meal size probability density estimate 1300 can be based on a simulated population. For example, the population can have 300 subjects and correspond to a time period of 70 days. Other numbers of subjects (e.g., a single subject) and/or periods of time (e.g., a single day) can be used.

[0140] Areas of a particular shading according to the scale 1302 can be interpreted as a probability of having a meal, and/or a probability of having a meal of a particular size. For example, an area 1304 is centered around approximately 7 AM and can correspond to breakfast meals for the population during the time period, and the carbohydrate distributions thereof. For example, an area 1306 is centered around approximately noon and can correspond to lunch meals for the population during the time period, and the carbohydrate distributions thereof. For example, an area 1308 is centered around approximately 7 PM and can correspond to dinner meals for the population during the time period, and the carbohydrate distributions thereof. The meal size probability density estimate 1300 shows, for example, that the most likely meal size at approximately the middle of the day (e.g., noon) is about 40 grams of carbohydrates, and that the probability for having a meal of about 100 grams of carbohydrates at about midnight is relatively low.

[0141] FIG. 14 shows an example of a meal size probability density estimate 1400 for a single subject based on 7 days of data. The meal size probability density estimate 1400 is an example of a meal size propensity record. The meal size probability density estimate 1400 is here presented as a heat map having a vertical axis corresponding to carbohydrates (e.g., in units of grams (g)) and a horizontal axis corresponding to time of day (e.g., in units of hours (hr)). Contents of the heat map indicate respective probabilities. A scale 1402 indicates probability probability density by way of color or other shading. For example, a relatively blue shade can correspond to a relatively high probability. As another example, a relatively white or red shade can correspond to a relatively low probability. The meal size probability density estimate 1400 can be based on a simulated population. For example, the meal size probability density estimate 1400 can be obtained by applying a bandwidth of 0.35 to a kernel density estimate. Other numbers of subjects (e.g., multiple subjects) and/or periods of time (e.g., more or fewer days) can be used. [0142] Areas of a particular shading according to the scale 1402 can be interpreted as a probability of having a meal, and/or a probability of having a meal of a particular size. For example, an area 1404 is centered around approximately 7 AM and can correspond to breakfast meals for the subject during the time period, and the carbohydrate distributions thereof. For example, an area 1406 is centered around approximately noon and can correspond to lunch meals for the subject during the time period, and the carbohydrate distributions thereof. For example, an area 1408 is centered around approximately 7 PM and can correspond to dinner meals for the subject during the time period, and the carbohydrate distributions thereof. The meal size probability density estimate 1400 indicates when three meals for the subject occur, particularly when looking at a probability over about 0.2% on the scale 1402. The meal size probability density estimate 1400 shows, for example, that the most likely meal size at approximately the middle of the day (e.g., noon) is about 40 grams of carbohydrates, and that the probability for having a meal of about 100 grams of carbohydrates at about midnight is relatively low.

[0143] FIG. 15 shows an example of a meal occurrence probability density estimate 1500 for a single subject based on 7 days of data. The meal occurrence probability density estimate 1500 is an example, at least in combination with other information, of a meal size propensity record. The meal occurrence probability density estimate 1500 is here presented as a graph having a vertical axis corresponding to meal probability density and a horizontal axis corresponding to time of day (e.g., in units of hours). Contents of the graph indicate respective probabilities. The meal occurrence probability density estimate 1500 can be based on a simulated population. Other numbers of subjects (e.g., multiple subjects) and/or periods of time (e.g., more or fewer days) can be used.

[0144] A height of the meal occurrence probability density estimate 1500 can be interpreted as a probability of having a meal. For example, an area 1502 is centered around approximately 7 AM and can correspond to breakfast meals for the subject during the time period. For example, an area 1504 is centered around approximately noon and can correspond to lunch meals for the subject during the time period. For example, an area 1506 is centered around approximately 7 PM and can correspond to dinner meals for the subject during the time period. The meal occurrence probability density estimate 1500 shows a signal for the time(s) when a meal can be expected. The meal occurrence probability density estimate 1500 shows, for example, that the likelihood of ingesting a meal at approximately the middle of the day (e.g., noon) is higher than at, say, midnight.

[0145] FIG. 16 shows an example of a meal size probability density estimate 1600 for a single subject based on 7 days of data. The meal size probability density estimate 1600 is an example of a meal size propensity record. The meal size probability density estimate 1600 is here presented as a graph having a vertical axis corresponding to meal size probability density and a horizontal axis corresponding to size of meal (e.g., in grams of carbohydrates). Contents of the graph indicate respective probabilities. The meal size probability density estimate 1600 can be based on a simulated population. Other numbers of subjects (e.g., multiple subjects) and/or periods of time (e.g., more or fewer days) can be used.

[0146] A height of the meal size probability density estimate 1600 can be interpreted as a probability of having a meal of a given size. For example, an area 1602 is centered around approximately 40 grams of carbohydrates and can correspond to the likelihood of any meal for the subject (e.g., breakfast, lunch, or dinner) during the time period having that size. The meal size probability density estimate 1600 shows, for example, that the likelihood of ingesting a 40-gram meal is higher than, say, an 80-gram meal.

[0147] In some implementations, the time period covered by a meal size propensity record can vary from one record to another. Different lengths of time periods can be used. FIG. 17 shows an example of a meal size probability density estimate for a single subject based on 14 days of data. The meal size probability density estimate 1700 is an example of a meal size propensity record. The meal size probability density estimate 1700 is here presented as a heat map having a vertical axis corresponding to carbohydrates (e.g., in units of grams (g)) and a horizontal axis corresponding to time of day (e.g., in units of hours (hr)). Contents of the heat map indicate respective probabilities. A scale 1702 indicates probability by way of color or other shading. For example, a relatively blue shade can correspond to a relatively high probability. As another example, a relatively white or red shade can correspond to a relatively low probability. The meal size probability density estimate 1700 can be based on a simulated population. For example, the population can have 300 subjects and correspond to a time period of 70 days. In some implementations, the meal size probability density estimate 1700 can be obtained by applying a bandwidth of 0.3 to a kernel density estimate. For example, having more data can allow for less smoothing to be performed and can provide greater accuracy of the probability estimate. Other numbers of subjects (e.g., multiple subjects) and/or periods of time (e.g., more or fewer days) can be used.

[0148] Areas of a particular shading according to the scale 1702 can be interpreted as a probability of having a meal, and/or a probability of having a meal of a particular size. For example, an area 1704 is centered around approximately 7 AM and can correspond to breakfast meals for the subject during the time period, and the carbohydrate distributions thereof. For example, an area 1706 is centered around approximately noon and can correspond to lunch meals for the subject during the time period, and the carbohydrate distributions thereof. For example, an area 1708 is centered around approximately 7 PM and can correspond to dinner meals for the subject during the time period, and the carbohydrate distributions thereof. The meal size probability density estimate 1700 indicates when three meals for the subject occur. The meal size probability density estimate 1700 shows, for example, that the most likely meal size at approximately the middle of the day (e.g., noon) is about 40 grams of carbohydrates, and that the probability for having a meal of about 100 grams of carbohydrates at about midnight is relatively low. The meal size probability density estimate 1700 can show a clearer occurrence of each meal, and/or the associated meal size, than, say, the meal size probability density estimate 1400 (FIG. 14).

[0149] FIG. 18 shows an example of a meal occurrence probability density estimate 1800 for a single subject based on 14 days of data. The meal occurrence probability density estimate 1800 is an example, at least in combination with other information, of a meal size propensity record. The meal occurrence probability density estimate 1800 is here presented as a graph having a vertical axis corresponding to meal probability density and a horizontal axis corresponding to time of day (e.g., in units of hours). Contents of the graph indicate respective probabilities. The meal occurrence probability density estimate 1800 can be based on a simulated population. Other numbers of subjects (e.g., multiple subjects) and/or periods of time (e.g., more or fewer days) can be used.

[0150] A height of the meal occurrence probability density estimate 1800 can be interpreted as a probability of having a meal. For example, an area 1802 is centered around approximately 7 AM and can correspond to breakfast meals for the subject during the time period. For example, an area 1804 is centered around approximately noon and can correspond to lunch meals for the subject during the time period. For example, an area 1806 is centered around approximately 7 PM and can correspond to dinner meals for the subject during the time period. The meal occurrence probability density estimate 1800 shows a signal for the time(s) when a meal can be expected. The meal occurrence probability density estimate 1800 shows, for example, that the likelihood of ingesting a meal at approximately the middle of the day (e.g., noon) is higher than at, say, midnight.

[0151] FIG. 19 shows an example of a meal size probability density estimate 1900 for a single subject based on 14 days of data. The meal size probability density estimate 1900 is an example of a meal size propensity record. The meal size probability density estimate 1900 is here presented as a graph having a vertical axis corresponding to meal size probability density and a horizontal axis corresponding to size of meal (e.g., in grams of carbohydrates). Contents of the graph indicate respective probabilities. The meal size probability density estimate 1900 can be based on a simulated population. Other numbers of subjects (e.g., multiple subjects) and/or periods of time (e.g., more or fewer days) can be used.

[0152] A height of the meal size probability density estimate 1900 can be interpreted as a probability of having a meal of a given size. For example, an area 1902 is centered around approximately 40 grams of carbohydrates and can correspond to the likelihood of any meal for the subject (e.g., breakfast, lunch, or dinner) during the time period having that size. The meal size probability density estimate 1900 shows, for example, that the likelihood of ingesting a 40-gram meal is higher than, say, an 80-gram meal.

[0153] The above examples illustrate performance of a computer-implemented method of generating a meal size propensity record. Such a method can include receiving bolus information regarding a person with diabetes. Such bolus information can include bolus events distributed within a period of time. The method can include receiving carbohydrate announcements for the person regarding the period of time. The method includes generating the meal size propensity record based on the bolus information and the carbohydrate announcements. One or more dimensions of information can be taken into account. In some implementations, a timing of the meals can form a first dimension for generating the meal size propensity record. For example, the bolus information can be processed to determine the timing of the meals. In some implementations, the carbohydrate announcements can form a second dimension for generating the meal size propensity record.

[0154] FIGS. 20A-B show examples of graphical user interfaces 2000 and 2050, respectively. The graphical user interfaces 2000 and/or 2050 can be used in combination with one or more other examples described elsewhere herein. Each of the graphical user interfaces 2000 and 2050 can be presented on a suitable display. In some implementations, the graphical user interfaces 2000 and/or 2050 can be presented on a display of a closed-loop insulin treatment device. In some implementations, the graphical user interface 2000 relates to an insulin injection pen for a certain type of insulin, such as a long-acting insulin pen. For example, the graphical user interface 2000 can be presented on the display 1142 and/or 1144 (FIG. 11), and/or on the display device 1206 (FIG. 12). In some implementations, the graphical user interface 2050 relates to an insulin injection pen for a certain other type of insulin, such as a rapid-acting insulin pen. For example, the graphical user interface 2000 and/or 2050 can be presented on the display 1142 and/or 1144 (FIG. 11), and/or on the display device 1206 (FIG. 12).

[0155] One or more of the graphical user interfaces 2000 and 2050 can support one or more types of processes relating to insulin therapy management. In some implementations, a pairing process can be supported that seeks to establish a connection between a pen cap and one or more other devices. For example, connection between the pen cap and a smartphone (e.g., the remote user interface device 1108 in FIG. 11) can be established. In some implementations, a daily use process can be supported that corresponds to the person’s with diabetes ordinary use of the pen cap, after one or more successful pairings with the other device(s), to manage diabetes therapy.

[0156] In some implementations, a daily use workflow for the graphical user interface 2000 can include a default screen (e.g., presenting a name of the insulin currently contained in an insulin injection pen or other insulin injection device), a timer screen 2002, and/or a dose suggestion screen 2004. For example, the person with diabetes can cycle through two or more screens using an input control (e.g., the button 1146 and/or 1148 in FIG. 11, and/or one or more of the buttons 1208A-E in FIG. 12). For example, the graphical user interface 2000 can automatically return to presenting the default screen if no action is undertaken using the pen cap (e.g., by way of a button other otherwise) within a predefined time period.

[0157] In some implementations, the timer screen 2002 presents a time that has elapsed since the last dose (e.g., since a most recent capping/uncapping event that qualifies as an indicator of insulin dosage). For example, the timer screen currently states that it has been 3 hours and 10 minutes since the last dose. In some implementations, the elapsed time can be based on actual dosage timing (e.g., as reported by an injection device), or on a proxy for insulin injection timing other than capping/uncapping.

[0158] In some implementations, the dose suggestion screen 2004 presents an insulin dosage suggestion 2006. The insulin dosage suggestion 2006 can contain one or more recommendations to the person with diabetes. For example, the insulin dosage suggestion 2006 currently suggests that the person with diabetes should ingest a daily dose of insulin (e.g., long-acting insulin) corresponding to an amount of 23u (units).

[0159] In some implementations, a daily use workflow for the graphical user interface 2050 can include a default screen (e.g., presenting a name of the insulin currently contained in the insulin injection pen), a timer screen 2052, a blood glucose value screen 2054, a blood glucose value screen 2056, a dose suggestion screen 2058, and/or a dose suggestion screen 2060. For example, the person with diabetes can cycle through two or more screens using an input control (e.g., the button 1146 and/or 1148 in FIG. 11, and/or one or more of the buttons 1208A-E in FIG. 12). For example, the graphical user interface 2050 can automatically return to presenting the default screen if no action is undertaken using the pen cap (e.g., by way of a button other otherwise) within a predefined time period.

[0160] In some implementations, the timer screen 2052 presents a time that has elapsed since the last dose (e.g., since a most recent capping/uncapping event that qualifies as an indicator of insulin dosage). For example, the timer screen currently states that it has been 3 hours and 10 minutes since the last dose. In some implementations, the elapsed time can be based on actual dosage timing (e.g., as reported by an injection device), or on a proxy for insulin injection timing other than capping/uncapping.

[0161] In some implementations, the blood glucose value screens 2054 and/or 2056 presents data obtained by way of a glucose monitor or another glucose sensor (e.g., a CGM). For example, the blood glucose value screen 2054 can present a value of a blood glucose estimate (e.g., 320 mg/dL), present a trend indication (e.g., an arrow pointing up, or towards the right and up, or to the right, or towards the right and down, or down), and/or a suggestion that the person with diabetes should check his or her blood glucose (BG). For example, the blood glucose value screen 2056 can present a value of a blood glucose estimate (e.g., 320 mg/dL), present a trend indication (e.g., an arrow pointing up, or towards the right and up, or to the right, or towards the right and down, or down), and an insulin dosage suggestion as to whether the person with diabetes should ingest a correction dose (e.g., here zero units is recommended).

[0162] In some implementations, the graphical user interface 2050 can include a meal size area 2061. For example, the meal size area 2061 can be included in the blood glucose value screen 2056. The meal size area 2061 can relate to a determination, estimation, and/or user input, of one or more carbohydrate announcements. In some implementations, the person with diabetes can make an input into the system to indicate the size of a meal that is being, or is to be, ingested. For example, the carbohydrate announcement can be made by entering the amount of carbohydrates (e.g., in grams) into the system. In some implementations, a carbohydrate announcement can include an estimate of carbohydrates that is back-calculated based on a size of bolus, after subtracting out a portion of a user-initiated bolus that is assumed to be for a correction dose. For example, the bolus size can be entered as a number of units of insulin.

[0163] In some implementations, the dose suggestion screen 2058 presents an insulin dosage suggestion 2062 relating to a meal. The insulin dosage suggestion 2062 can contain one or more recommendations to the person with diabetes based on information about the meal. For example, the insulin dosage suggestion 2062 currently suggests that the person with diabetes should ingest 4 units of insulin if the meal is a small meal, 7 units if the meal is a medium meal, and 10 units if the meal is a large meal. In some implementations, a pen cap or an insulin injection device for which the graphical user interface 2050 is implemented may work in combination with one or more glucose monitors or another glucose sensor. For example, the graphical user interface 2050 can work with a CGM. As another example, the graphical user interface 2050 can work with a BGM.

[0164] The graphical user interface 2000 and/or 2050 can present one or more other types of information not illustrated in the present examples. Such information can include, but is not limited to, alerts (e.g., regarding a missed bolus), a communication (e.g., regarding a late bolus), messages regarding a need to charge the pen cap, messages that the pen cap is currently synchronizing data, and/or error messages (e.g., urging the person with diabetes to consult the remote user interface device 1108 (FIG. 11).

[0165] FIG. 21 shows a computing platform 2100 for insulin-based management of diabetes. The computing platform 2100 can be used with one or more other examples described elsewhere herein. In disclosed embodiments, computing platform 2100 is, or is operative to be executed as, a data processing system, and more specifically, as a data processing system for detecting a meal (e.g., the size thereof) and/or a missed bolus for a person with diabetes. The computing platform 2100, or one or more components thereof, can be implemented using one or more components exemplified below in the description of FIG. 27.

[0166] Computing platform 2100 may include data store 2110 and processor(s) 2102. Data store 2110 may include therapy data 2112. Therapy data 2112 is data related to insulin therapy of one or more persons. Therapy data 2112 can include insulin dosing data 2114, meal data 2116, and blood glucose data 2118. For example, therapy data 2112 can include blood glucose values and/or bolus information relating to a period of time. Alternatively, or additionally, therapy data 2112 may include exercise data, sleep data, and/or physiological parameters of a patient (e.g., ISF or CR).

[0167] Blood glucose data 2118 may include data about blood glucose in a human body at one or more times. Blood glucose data 2118 may include measurements of blood glucose levels, for example, raw blood glucose measurements, blood glucose estimates based on blood glucose measurements, and/or aggregations of the same (e.g., averages, trends and metrics). Blood glucose data 2118 may include date and time (e.g., a timestamp), and a value for each blood glucose measurement. In disclosed embodiments, any suitable glucose sensor may provide blood glucose data 2118, for example, a CGM, a flash glucose monitor, a BGM. In the case of CGMs and flash glucose monitors, they may be configured to provide blood glucose data 2118 based on interstitial fluid glucose levels of a person, which may be correlated to blood glucose levels. A BGM may be configured to provide blood glucose data based on a blood sample. Accordingly, the term “blood glucose” is not limited herein to using just blood glucose data, values, levels etc., but is also intended to include interstitial fluid glucose levels, intermediate measurements, and equivalents thereof.

[0168] Insulin dosing data 2114 may include dosing event data. Dosing event data may include data about insulin dosing actions at one or more times and may include, for example, a dosing time or time range, type of insulin (e.g., long-acting (LA) insulin and rapid-acting (RA) insulin) dosed, brand of insulin, and/or amount of dosed insulin. In some embodiments, dosing event data may include an indication of a dosing mechanism, for example, injection pen, inhaler, or infusion pump. In some embodiments, dosing event data may include an indication of whether dosing event data, in part or in whole, is based on an actual dosing action (e.g., detecting insulin delivery, for example, based on a manual action of a pump or a control signal configured to cause insulin delivery), user tracking of dosing actions (e.g., a person with diabetes or caregiver enters a dose using a therapy application executing on a mobile device), or inferred dosing actions (e.g., from capping/uncapping of an injection pen).

[0169] Processor(s) 2102 may be configured to execute a number of engines for performing disclosed embodiments. Processor(s) 2102 can include a meal/missed-bolus detector 2104, math engine 2106, and reporting engine 2108.

[0170] Meal/missed-bolus detector 2104 may be configured, generally, to process therapy data 2112 or part(s) of therapy data 2112, and detect a meal and/or a missed bolus. A part of therapy data 2112 processed by the meal/missed-bolus detector 2104 may correspond to a particular time period. In one embodiment, meal/missed-bolus detector 2104 may return predictions of a discrete variable, such as to detect whether the person with diabetes ingests a meal and/or misses a bolus. The meal/missed-bolus detector 2104 may output one or more discrete variables, or can cause one or more other actions to be taken. The meal/missed-bolus detector 2104 may include one or more classifiers and one or more regressors, and can be trained using one or more supervised and/or unsupervised learning techniques, including those described in more detail in this disclosure.

[0171] Math engine 2106 may be configured to perform various statistical calculations using therapy data 2112 and results provided by meal/missed-bolus detector 2104. In various embodiments, statistical calculations may include, for example, frequency calculations, confidence calculations, probability calculations, and more.

[0172] Reporting engine 2108 may be configured, generally, to generate one or more reports 2120 responsive to meal/missed-bolus detector 2104 and/or math engine 2106.

Reports 2120 may include descriptions of retrospective studies performed at computing platform 2100, and/or determinations resulting therefrom, and may include, for example, patient identifiers, descriptions of retrospective time periods, assigned class labels, the class labels and more.

[0173] FIG. 22 shows a simplified block diagram of an example of a system for insulin- based management of diabetes. Any suitable technique used by one of ordinary skill in the art in the field of data science to calculate and/or express probabilities may be used with disclosed embodiments. Some embodiments relate, generally, to insulin therapy systems and elements thereof that incorporate systems, methods and devices for detecting a meal and/or a missed bolus. FIG. 22 shows a system 2200 for insulin therapy, in accordance with disclosed embodiments. The system 2200 can be used with one or more other examples described elsewhere herein. The system 2200, or one or more components thereof, can be implemented using one or more components exemplified below in the description of FIG. 27.

[0174] In the embodiment shown in FIG. 22, data processing system 2202, clinical decision support system 2210, and therapy management system 2208 are computing platforms configured, generally, to provide various services related to insulin therapy, in whole or in part, to each other and to health care provider (HCP) systems 2206 and patient systems 2204. The data processing system 2202, clinical decision support system 2210, therapy management system 2208, HCP systems 2206, and patient systems 2204 can be connected by at least one network 2212 (e.g., the Internet). HCP systems 2206 may include, for example, portals, dashboards, electronic medical record systems, computing platforms executing the same, and more.

[0175] In some embodiments, therapy management system 2208 may be or includes one or more computing platforms configured to receive and store therapy data (such as therapy data 2112 in FIG. 21) and physiological parameters about patients, issue alarms and alerts, and manage therapy settings for insulin delivery systems. In short, the therapy management system 2208 performs insulin-based management of diabetes.

[0176] In some embodiments, clinical decision support system 2210 may be one or more computing platform configured as a health data technology system for assisting HCPs with clinical decision making tasks, and more specifically in this example, assist HCPs with clinical decision making tasks related to a person’s insulin therapy. In disclosed embodiments, clinical decision support system 2210 is configured to assist with insulin-based management of diabetes, and automatically analyzes therapy data, identifies clinically relevant patterns in a person’s therapy from the therapy data, and provides data and recommendations to HCP systems 2206 based on those patterns. A goal of embodiments of clinical decision support system 2210 is to improve outcomes for persons with diabetes by facilitating communication of clinically relevant “insights” about a person’s insulin-based therapy to patient systems 2204 and HCP systems 2206 as well as by facilitating communication of therapy related advice from HCP systems 2206 to patient systems 2204. For example, the clinical decision support system 2210 can issue alerts and/or communications regarding missed or late boluses.

[0177] In disclosed embodiments, data processing system 2202 may be or include one or more computing platforms configured to process therapy data stored at, or received from, therapy management systems 2208 and/or clinical decision support system 2210. In one embodiment, data processing system 2202 may, among other things, include one or more elements of computing platform 2100 (FIG. 21), including meal/missed-bolus detector 2104.

In this manner, data processing system 2202 may be configured to perform meal and/or missed-bolus detection for therapy management system 2208 and/or clinical decision support system 2210.

[0178] By way of example, data processing system 2202 may perform meal detection, and/or missed-bolus detection, on therapy data stored at clinical decision support system 2210 and provide one or more reports (e.g., report 2120 in FIG. 21) detailing one or more labeled retrospective time periods, as well as one or more determinations regarding a detected meal and/or a missed bolus. Clinical decision support system 2210 may use the data in the reports to trigger insights and/or recommendations that it sends to HCP systems 2206. Upon HCP system 2206 accessing messages from clinical decision support system 2210, data from the reports may be included in such message or accessible by HCP systems 2206 - e.g., accessible if HCP systems 2206 requests data to support an insight or recommendation described in a message.

[0179] FIG. 23 shows a diagram of an example of a system 2300 for diabetes management. The system 2300 can be used in combination with, or can include aspects of, one or more other examples described elsewhere herein. The system 2300, or one or more components thereof, can be implemented using one or more components exemplified below in the description of FIG. 27.

[0180] The system 2300 can include an inputs layer 2302, an individual time series features layer 2304, a metrics layer 2306 for making determinations regarding features, and an action decision layer 2308. The inputs layer 2302 can facilitate that the system 2300 obtains data regarding blood glucose levels and/or dosage times. In some implementations, the inputs layer 2302 facilitates connection with a CGM 2310 (e.g., the glucose monitor 1106 of FIG. 11, or the glucose sensor 1216 of FIG. 12, or another glucose sensor). In some implementations, the inputs layer 2302 facilitates receipt of therapy settings 2311. For example, the therapy settings 2311 specifies one or more doses of insulin, and/or characteristics of the dose(s) of insulin, for a person with diabetes. In some implementations, the inputs layer 2302 facilitates receipt of dose times data 2312 (e.g., by way of detecting capping data from a pen cap of an insulin injection pen, or using another proxy for dosage times). In some implementations, the inputs layer 2302 facilitates receipt of pen cap usage data 2313. For example, the pen cap usage data 2313 can be based on one or more capping or uncapping event of a pen cap for an insulin injection pen. One or more of the CGM 2310, therapy settings 2311, dose times data 2312, or the pen cap usage data 2313 can be used in some implementations. For example, the dose times data 2312 can be determined or inferred from the pen cap usage data 2313. In some implementations, the inputs layer 2302 can receive about two weeks of blood glucose data and dosage timing information in a batch, or information can be received substantially in real time. In some implementations, the time period between therapy parameter adjustments can be configurable by an algorithm. For example, the time period between consecutive therapy parameter adjustments can be referred to as an iteration of the algorithm. The inputs layer 2302 can provide some or all of the information to the individual features/metrics layer 2304.

[0181] The individual time series features layer 2304 can serve to select the relevant data features that will help with the evaluation of whether a meal is ingested and/or a bolus is missed. In some implementations, the individual time series features layer 2304 includes an individual dose analysis engine 2314. For example, the individual dose analysis engine 2314 can identify one or more individual dose times in dose times data 2312, identify one or more blood glucose values from the CGM 2310 corresponding to the identified one or more individual dose times, calculate one or more other metrics such as m* or s* from a set of time series features of interest, and/or process the feature(s) to make a determination of whether the person with diabetes ingests a meal and/or misses a bolus.

[0182] The individual dose analysis engine 2314 can select one or more metrics to be applied in analyzing blood glucose values and/or bolus information. In some implementations, the individual dose analysis engine 2314 applies one or more of a metric 2316 relating to overnight insulin dosage, a metric 2318 relating to insulin dosage taken after a meal, and/or a metric 2320 relating to an after-meal dose with a correction dose. For example, the metric 2316 can be applied to a portion of the blood glucose data that can correspond to sleeping time for the person with diabetes (e.g., sleeping time can be an example of fasting time for the person with diabetes). For example, the metric 2318 can be applied to a portion of the blood glucose data that corresponds to time in connection with an ingested meal. For example, the metric 2320 can be applied to a portion of the blood glucose data that corresponds to time in connection with an eaten meal, wherein the dose times data 2312 indicates that the person with diabetes took a correction dose (e.g., an insulin dosage suggestion made to the person with diabetes may have included a correction bolus recommendation, and capping data from the pen cap indicates that the correction bolus recommendation was accepted by the person with diabetes.)

[0183] In the metrics layer 2306, one or more of the metrics selected by the individual dose analysis engine 2314 can be applied to detect a meal and/or missed bolus. In some implementations, the metrics layer 2306 includes a classification component 2322 that classifies one or more instances of blood glucose data, and/or one or more instances of bolus information, using the selected metric(s). For example, the classification component 2322 can apply the metric(s) to blood glucose values and bolus information to determine whether a person with diabetes ingests a meal or misses a bolus after a meal.

[0184] The action decision layer 2308 can make one or more decisions based on the determination by the metrics layer 2306. In some implementations, the action decision layer 2308 includes an engine 2324. For example, the engine 2324 can evaluate classifier outputs generated by the metrics layer 2306 and decide when one or more meals began and/or when the person missed a bolus dose. The action decision layer 2308 can cause one or more alert 2326 to be generated. The action decision layer 2308 can cause one or more communication 2328 to be issued for the person with diabetes. The action decision layer 2308 can cause one or more probability density record 2330 regarding the person with diabetes to be generated.

[0185] FIG. 24 shows an example of a system 2400 for training a regression model.

The system 2400 can be used with one or more other examples described elsewhere herein. The system 2400 can involve the following stages: gathering data 2402; preprocessing the data 2402 at 2404 (into a training dataset 2406) and at 2408 (into a testing dataset 2410); researching the regression model, in terms of an algorithm 2416 and an evaluation 2418 that are based on the training dataset 2406 at 2412, by way of one or more iterations 2420; testing the regression model using the testing dataset 2410 at 2414; training, at 2421, a regression model 2422; and evaluating the regression model 2422 using production data 2424 to make one or more predictions 2426. In some implementations, the training dataset 2406 can include both a set of training data and a set of validation data.

[0186] The data 2402 can include actual patient data or simulated data, or combinations thereof. For example, data can be provided on a real-time basis or from storage. The data 2402 can be preprocessed to clean the data 2402. For example, the data 2402 can be converted from a raw format (e.g., a format as collected) into a format suitable for regression analysis. As another example, noise can be removed from the data 2402, and/or inconsistencies in the data 2402 can be removed. As another example, missing values in the data 2402 can be ignored (e.g., by removing a remainder of a column or row of the missing value). The training can involve supervised or unsupervised learning. In some implementations, supervised learning involves regression to learn how to predict a numerical value of a continuous variable.

[0187] The regression model 2422 can take as inputs at least blood glucose values for a person with diabetes and bolus information (e.g., time-of-admini strati on data) for the insulin therapy treatment. In some implementations, the blood glucose values are read, estimated, or inferred using one or more devices (e.g., a CGM or a BGM). For example, blood glucose values can be collected from the person with diabetes at regular intervals. In some implementations, the time-of-administration information (e.g., when the person ingested insulin, sometimes referred to as time-of-bolus information) can be read, estimated, or inferred using one or more devices (e.g., an insulin injection pen, or a pen cap of the insulin injection pen). For example, time-of-administration information can be collected from the person with diabetes at regular intervals.

[0188] In some implementations, the diabetes therapy management system (e.g., a smartphone, insulin injection pen, or a pen cap) facilitates receipt of dose times data (e.g., by way of detecting capping data from a pen cap of an insulin injection pen, or using another proxy for dosage times). In some implementations, pen cap usage data can be detected. For example, the pen cap usage data can be based on one or more capping or uncapping events of a pen cap for an insulin injection pen. One or more of dose times data or pen cap usage data can be used in some implementations. For example, the dose times data can be determined or inferred from the pen cap usage data. In some implementations, about two weeks of blood glucose data and dosage timing information can be received. In some implementations, the time period between therapy parameter adjustments can be configurable by an algorithm. For example, the time period between consecutive therapy parameter adjustments can be referred to as an iteration of the algorithm. [0189] FIG. 25 shows a functional block diagram of system 2500 for training a regression model (such as meal/missed-bolus detector 2104 in FIG. 21) using machine learning techniques, in accordance with disclosed embodiments. The system 2500 can be used with one or more other examples described elsewhere herein.

[0190] In a contemplated operation, supervised learning engine 2508 trains regression model 2510 using training data 2502 and sets of engineered features (i.e., feature sets 2506) selected for model training purposes. In some embodiments, regression model 2510 is a function or algorithm that detects meal ingestion and/or a missed bolus. An initial “best guess” may be used for regression model 2510 which is then continually improved by supervised learning engine 2508. In disclosed embodiments, regression model 2510 and supervised learning engine 2508 may implement any suitable supervised learning algorithms and ensemble methods thereof for performing embodiments of the disclosure, including, for example, a Random Forest regressor, a linear support vector regressor (SVR), an SVR with radial basis function (RBF) kernel, Lasso, or Ridge regression model. Disclosed embodiments may also implement supervised learning algorithm(s) that do not use feature selection, including, for example, one class support vector machine (SVM) without feature selection, and logistic regression without feature selection.

[0191] In one embodiment, training data 2502 is labeled therapy data associated with one or more persons with diabetes. A person with diabetes may be chosen so they are representative of a desired domain of physiologies, eating behaviors, exercise behaviors, sleeping behaviors, diurnal profile variation, and more.

[0192] In disclosed embodiments, feature sets 2506 are sub-sets of features engineered (i.e., formed) in the training data 2502 and used by supervised learning engine 2508 to train any regression model. In one embodiment, feature sets 2506 are created using a feature selection process for selecting a subset of features included in a feature domain created using feature engineering techniques. Features in a feature domain may include, for example, EGV, a ROC of EGV, a ROC of the ROC of EGV, a bolus distance (e.g., a bolus announcement spread out over a finite time), a bolus probability density (e.g., a bolus probability density used as a proxy for meal propensity), m* (e.g., a geometric mean of a feature, over a time period or the entire available data span), s* (e.g., a geometric standard deviation of a feature, over a time period or the entire available data span).

[0193] That is, one or more feature sets can be constructed, such as by a selection process at a feature engineering stage. The feature selection process can be performed using the feature sets and the data to obtain a training feature set. Feature sets 2506 may be selected from the feature domain using any suitable feature selection technique or combination of techniques for trying features in the feature domain and identifying important features, including, for example, sequential forward feature selection, sequential backward elimination, and tree-based feature selection algorithms.

[0194] Labeled test data 2514 is test data 2512 classified and labeled by regression model 2510 during successive iterations of system 2500. The system 2500 includes target classified test data 2520. Labeled test data 2514 is the “true” or “target” labels for test data 2512. Stated another way, it is the labeling result that is the target for regression model 2510. Predictive ability analyzer 2516 assess the predictive ability of regression model 2510 by comparing the labels of the labeled test data 2514 that were predicted by the regression model 2510 to the true values in the target test data. Any suitable technique for calculating and/or assessing validity of a model may be used by predictive ability analyzer 2516, including for example, precision, recall, number of detected events versus number of true events, confusion matrix, area-under-the-free-curve (AUC), receiver operating characteristics (ROC) curve. Techniques such as Grid search combined with cross validation, and N-fold cross-validation can be used for hyper parameter tuning of a regressor.

[0195] Feature selection 2518 receives assessment results from predictive ability analyzer 2516 and, in response, changes feature sets 2506 to attempt to improve accuracy and/or attempt to simplify feature sets 2506. As non-limiting examples, changes to feature sets 2506 may include, changing weighting for features of feature sets 2506, adding features to feature sets 2506 to attempt to improve accuracy of predictions, removing unnecessary features from feature sets 2506, and combinations thereof.

[0196] Feature engineering 2504 receives assessment results from predictive ability analyzer 2516 and, in some cases, performs feature engineering techniques to extract new features from test data 2512 and add those features to engineered features 2522. These new features may be used in the feature selection process by feature selection 2518.

[0197] In one embodiment, system 2500 may include simulation engine 2524 configured to generate simulation data 2526 from which training data 2502 and test data 2512 may be obtained. Simulation engine 2524 may be configured to simulate insulin therapy scenarios for a variety of persons with diabetes. The profiles can be created so as to represent a cross-section of persons with diabetes in terms of characteristics such as physiology (e.g., age, weight, height, complicating health conditions, diurnal profile variation, etc.), lifestyle (e.g., eating behaviors, exercise behaviors, sleeping behaviors, etc.), socio-economic factors (e.g., income, race, geographic location, marriage status, child status, etc.), differences in how persons measure and track meal intake, and differences in the operation and quality of insulin delivery systems and components the persons use. In one embodiment, simulation engine 2524 is configured to model for missing therapy data due to, for example, lost components, failure to input therapy related data, failure to wear a glucose monitor, and lost Bluetooth connection.

[0198] Some disclosed embodiments relate, generally, to obtaining training data and test data, such as training data 2502 and test data 2512, from simulation data such as simulation data 2526. FIG. 26 shows a functional block diagram of an example of a data journey 2600, for creating training data from simulation data, in accordance with disclosed embodiments. Each stage of data journey 2600 is shown as an operational block that describes at least some notable intermediate data elements of data journey 2600.

[0199] In operational block 2602, training simulation data 2604 is obtained by selecting part of simulation data (such as simulation data 2526 in FIG. 25)) to be training simulation data 2604. In one embodiment, 90 days’ worth of simulated data is obtained and the first 60 days of simulation data is selected to be training simulation data 2604 and the last 30 days of simulation data is selected to be test simulation data.

[0200] In operational block 2606, each missed bolus event is flagged in the training simulation data 2604 to obtain flagged data 2608. Notably, each true missed bolus in the simulation data 2604 is known for each person with diabetes that was part of a simulation.

[0201] In operational block 2606, feature engineering techniques are used on flagged data 2608 to obtain feature set 2610. More specifically, feature engineering techniques are used to form features in flagged data 2608 to obtain the feature set 2610.

[0202] In operational block 2612, feature set 2610 is chunked to obtain positive chunked data 2616 and negative chunked data 2618. In various embodiments, a chunk of data is data that is relevant to a class (here a positive class or negative class), and a chunk of data may itself be formed by aggregating sub-units of data. Positive chunked data 2616 are chunks of data associated with a positive class (i.e., there is a missed bolus event detected). In one embodiment, positive chunked data 2616 may be obtained by aggregating feature set 2610 (here, training data) corresponding to the next 60 minutes’ worth of observations after each missed bolus event. Further, a 60 minute chunk of therapy data may be formed of therapy data corresponding to 12 instances of consecutive 5 minute observations.

[0203] Negative chunked data 2618 are chunks of data associated with a negative class (i.e., no missed bolus event detected). In one embodiment, negative chunked data 2618 may be obtained by aggregating training data corresponding to a 60 minutes’ worth of observations where (1) the observations in the 60 minutes are consecutive in timestamps; (2) chunks of chunked data 2618 do not intersect (i.e., the intersection of chunks of chunked data 2618 is empty); and (3) no chunks of chunked data 2616 and chunks of chunked data 2618 intersect (i.e., the intersection of chunks of chunked data 2616 and chunked data 2618 is empty). In one embodiment, available chunks of data are randomly selected to form chunked data 2616 and/or chunked data 2618. In one embodiment, a number of chunks selected for chunked data 2616 is substantially the same as the number of chunks selected for chunked data 2618.

[0204] Feature values 2614 for positive chunked data 2616 and feature values 2620 for negative chunked data 2618 are obtained for chunks of chunked data 2616 and chunks of chunked data 2618, respectively, in operational block 2612. In various embodiments, feature values may be calculated for a chunk of data or one or more smaller observational units of a chunk of data. For example, feature values may be calculated using therapy data for each of the 5 minute observational units that form a 60 minute chunk of therapy data.

[0205] In operational block 2622, positive class data 2624 and negative class data 2628 are obtained, and more specifically, are constructed from chunks of chunked data 2616 and chunks of chunked data 2618, respectively. In one embodiment, each positive class data 2624 is formed by labeling the constituent chunks of data of chunked data 2616 with a positive class identifier (e.g., “true” or “1”) and copying the labeled chunks of data into positive class data 2624. Similarly, in one embodiment, each negative class data 2628 is formed by labeling the constituent chunks of data of chunked data 2618 with a negative class identifier (e.g., “false” or “0”) and copying the labeled chunks of data to negative class data 2628.

[0206] In operational block 2622, aggregated feature set values 2626 for positive class data 2624 and aggregated feature set values 2630 for negative class data 2628 are obtained. In one embodiment, aggregated feature set values 2626 for positive class data 2624 and aggregated feature set values 2630 for negative class data 2628 are formed by aggregating feature values 2614 for positive chunked data 2616 and feature values 2620 for negative chunked data 2618, respectively, on a feature by feature basis into a single value for the chunk. In various embodiments, any suitable statistical method for aggregating may be used, including, for example, one or more of mean, median, a commercially available aggregate function (e.g., first value). In various embodiments, training data, such as training data 2502 (FIG. 25), may be obtained by combining positive class data 2624 and negative class data 2628. [0207] In one embodiment, training data obtained as a result of data journey 2600 may be characterized as balanced training data, i.e., having a substantially equal number of observations from both classes (e.g., “detected missed bolus” and “no detected missed bolus”). Since the probability of a missed bolus event is lower than the probability of no missed-bolus event, the observations in simulation data 2526 (FIG. 25) should (in theory) be imbalanced, more specifically, the negative observations should outweigh the positive observations. So, when obtaining balanced training data, a majority of negative observations may not be considered, and so there is potential for data loss. In one embodiment, any impact of data loss is alleviated by using ensemble or bagging techniques.

[0208] In disclosed embodiments, test data, such as test data 2512 (FIG. 25), may be obtained in a manner similar to data journey 2600 described above, except that the entire set of test simulation data may be chunked. Test data may be imbalanced (i.e., does not have to be balanced). So, in one embodiment, chunks may be formed by applying a rolling window to test simulation data. For example, 60 minute chunks may be formed by travelling across an entire test simulation data in 5 minute by 5 minute observational units, person by person. Features may be formed for each rolling window by aggregating values using suitable statistical methods similar to training data as described above.

[0209] In some cases, there may not be enough consecutive observational sub-units available to form a full chunk of data. Using the example of a 60 minute chunk of data formed of 5-minute observational units, after a missed bolus event there may be 6 of the 5- minute observational units and 5 discontinuities (e.g., gaps between observations). So, in one embodiment, a chunk of data is discarded if fewer than a predetermined number of consecutive observational units is available. Each chunk may be assigned a label with an appropriate class identifier to indicate that it is associated with a missed bolus or no missed bolus. In one embodiment, a chunk of data may be assigned a positive class label if any missed bolus event is within plus-minus 5 minutes of a chunk start time, and assigned a negative class label if otherwise.

[0210] FIG. 27A shows an example of a system 2700 for detecting that a person with diabetes ingests a meal. The system 2700 can be used with one or more other examples described herein. The system 2700 is configured to receive one or more inputs and determine or estimate whether a person with diabetes is currently ingesting a meal. In some implementations, the system can receive input(s) 2702. For example, the input(s) 2702 can include, among other inputs, one or more of the inputs 112 in FIG. IB and/or the inputs 210 in FIG. 2. The system 2700 can include a fitness tracker 2704. In some implementations, the fitness tracker 2704 is provided with one or more inertial measurement units (IMU) (e.g., a gyroscope and/or an accelerometer) allowing the fitness tracker 2704 to determine its position, orientation, and/or change of position and/or change of orientation, in multiple degrees of freedom. In some implementations, the fitness tracker 2704 has a wireless communication device (e.g., a Bluetooth unit, or any other personal area network device) that allows for transmission of information to one or more components of the system 2700. For example, the signal(s) from the fitness tracker 2704 can be received as the input(s) 2702.

[0211] The system 2700 can include a wearable device 2706. The wearable device 2706 is here illustrated as a pair of smart glasses or other smart optical device, solely for purposes of illustration. In some implementations, the wearable device 2706 is configured for being worn on the upper body of the person. For example, the person can wear the wearable device 2706 on the person’s head. In some implementations, the wearable device 2706 is provided with one or more image sensing units (e.g., a camera or other optical sensor) allowing the wearable device 2706 to capture images of the environment or other surrounding nearby the person wearing the wearable device 2706. For example, the wearable device 2706 can include virtual-reality googles and/or augmented-reality goggles. In some implementations, the wearable device 2706 has a wireless communication device (e.g., a Bluetooth unit, or any other personal area network device) that allows for transmission of information to one or more components of the system 2700. For example, the signal(s) from the wearable device 2706 can be received as the input(s) 2702.

[0212] The system 2700 can include a gesture recognition component 2708 that can be implemented using one or more examples described with reference to FIG. 28. The gesture recognition component 2708 is configured to analyze the input(s) 2702 and determine or estimate whether the input(s) indicate, or are consistent with, meal ingestion by the person with diabetes. The gesture recognition component 2708 can apply one or more classifiers and/or regressors (e.g., as described elsewhere herein) to make a determination regarding the input(s). The gesture recognition component 2708 can make one or more outputs 2710. In some implementations, the output(s) 2710 can indicate whether the person is currently determined or estimated to be ingesting a meal (e.g., a binary output), or can indicate a probability that the person is ingesting a meal (e.g., a continuous variable). For example, the output can be taken into account by the closed-loop control device 106 (FIG. 1 A) and/or by the closed-loop controller 114 (FIG. IB).

[0213] FIGS. 27B-C show examples of gesture recognition. In FIG. 27B, the fitness tracker 2704 is initially detected to be in a first position, here shown drawn in solid lines. The fitness tracker 2704 can then undergo motion, as schematically illustrated by an arc 2712, to assume a second position, here shown drawn in broken lines. The movement corresponding to the arc 2712 can be detected by the IMU of the fitness tracker 2704. For example, the IMU can detect the acceleration and/or velocity of the fitness tracker 2704 while undergoing the motion. As another example, the IMU can detect that the absolute location (e.g., relative to a reference coordinate system) of the fitness tracker 2704 in the first position changes to a different absolute location in the second position. In some implementations, the movement corresponding to the arc 2712 can be detected as a gesture. For example, the processing circuitry of the fitness tracker 2704 can process the sensor data detected as a result of the movement and generate the input(s) 2702. As another example, the processing circuitry of the fitness tracker 2704 can provide raw (e.g., essentially unprocessed) data from its sensor(s) as the input(s) 2702, and the processing (e.g., gesture recognition) can be performed by the gesture recognition component 2708. In some implementations, a gesture corresponding to an eating motion can be recognized by the system 2700. For example, the movement corresponding to the arc 2712 can be generated when the person moves an arm on which the fitness tracker 2704 is positioned toward the person’s mouth.

[0214] In FIG. 27C, the wearable device 2706 (FIG. 27A) has a field of view 2714, here schematically shown as an area drawn in broken lines. The field of view 2714 corresponds to what the camera or other image sensor of the wearable device 2706 can currently see. For example, the field of view 2714 can at least in part overlap with the direction that the person using the wearable device 2706 is facing. An object 2716 is initially outside the field of view 2714, and is not detected by the wearable device 2706 at that time. The object 2716 can move into the field of view 2714, as here schematically illustrated by an arc 2718. The movement corresponding to the arc 2718 can be detected by the wearable device 2706. For example, the wearable device 2706 can detect that the object 2716 enters and remains in the lower portion of the field of view 2714. For example, the lower portion of the field of view 2714 can be close to the jaw or mouth of the person using the wearable device 2706, and as such the presence of the object 2716 in that region can be an indication of meal ingestion. In some implementations, the movement corresponding to the arc 2718 can be detected as a gesture. For example, the processing circuitry of the wearable device 2706 can process the sensor data detected as a result of the movement and generate the input(s) 2702 (FIG. 27A). As another example, the processing circuitry of the wearable device 2706 can provide raw (e.g., essentially unprocessed) data from its sensor(s) as the input(s) 2702, and the processing (e.g., gesture recognition) can be performed by the gesture recognition component 2708 (FIG. 27A).

[0215] The output 2710 (FIG. 27A) by the gesture recognition component 2708 can be used in one or more ways. In some implementations, the determination or estimation of whether a person with diabetes is ingesting a meal, and if so the size of the meal, can be aided by a determination or an indication that the person is currently eating. For example, the output 2710 can trigger the system 100 (FIG. 1A) and/or the system 110 (FIG. IB) to recognize that a meal is being ingested, and to consult the meal size probability density estimate 1600 to obtain a likely size of the meal. As another example, the output 2710 can be taken into account in combination with one or more other propensity records (e.g., the meal occurrence probability density estimate 1500 in FIG. 15) as the basis for whether the person is currently ingesting a meal. As yet another example, the amount of time and/or the number of times that the fitness tracker 2704 (FIG. 27B) is brought into the second position can be taken into account as an indication of the duration of the meal and therefore its size. As yet another example, the amount of time and/or the number of times that the object 2716 (FIG. 27C) is brought into the lower portion of the field of view 2714 can be taken into account as an indication of the duration of the meal and therefore its size. Other approaches can be used.

[0216] FIG. 28 illustrates an example architecture of a computing device 2800 that can be used to implement aspects of the present disclosure, including any of the systems, apparatuses, and/or techniques described herein, or any other systems, apparatuses, and/or techniques that may be utilized in the various possible embodiments.

[0217] The computing device illustrated in FIG. 28 can be used to execute the operating system, application programs, and/or software modules (including the software engines) described herein.

[0218] The computing device 2800 includes, in some embodiments, at least one processing device 2802 (e.g., a processor), such as a central processing unit (CPU). A variety of processing devices are available from a variety of manufacturers, for example, Intel or Advanced Micro Devices. In this example, the computing device 2800 also includes a system memory 2804, and a system bus 2806 that couples various system components including the system memory 2804 to the processing device 2802. The system bus 2806 is one of any number of types of bus structures that can be used, including, but not limited to, a memory bus, or memory controller; a peripheral bus; and a local bus using any of a variety of bus architectures.

[0219] Examples of computing devices that can be implemented using the computing device 2800 include a desktop computer, a laptop computer, a tablet computer, a mobile computing device (such as a smart phone, a touchpad mobile digital device, or other mobile devices), or other devices configured to process digital instructions.

[0220] The system memory 2804 includes read only memory 2808 and random access memory 2810. Abasic input/output system 2812 containing the basic routines that act to transfer information within computing device 2800, such as during start up, can be stored in the read only memory 2808.

[0221] The computing device 2800 also includes a secondary storage device 2814 in some embodiments, such as a hard disk drive, for storing digital data. The secondary storage device 2814 is connected to the system bus 2806 by a secondary storage interface 2816. The secondary storage device 2814 and its associated computer readable media provide nonvolatile and non-transitory storage of computer readable instructions (including application programs and program modules), data structures, and other data for the computing device 2800.

[0222] Although the example environment described herein employs a hard disk drive as a secondary storage device, other types of computer readable storage media are used in other embodiments. Examples of these other types of computer readable storage media include magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, compact disc read only memories, digital versatile disk read only memories, random access memories, or read only memories. Some embodiments include non-transitory media. For example, a computer program product can be tangibly embodied in a non-transitory storage medium. Additionally, such computer readable storage media can include local storage or cloud-based storage.

[0223] A number of program modules can be stored in secondary storage device 2814 and/or system memory 2804, including an operating system 2818, one or more application programs 2820, other program modules 2822 (such as the software engines described herein), and program data 2824. The computing device 2800 can utilize any suitable operating system, such as Microsoft Windows™, Google Chrome™ OS, Apple OS, Unix, or Linux and variants and any other operating system suitable for a computing device. Other examples can include Microsoft, Google, or Apple operating systems, or any other suitable operating system used in tablet computing devices.

[0224] In some embodiments, a user provides inputs to the computing device 2800 through one or more input devices 2826. Examples of input devices 2826 include a keyboard 2828, mouse 2830, microphone 2832 (e.g., for voice and/or other audio input), touch sensor 2834 (such as a touchpad or touch sensitive display), and gesture sensor 2835 (e.g., for gestural input). In some implementations, the input device(s) 2826 provide detection based on presence, proximity, and/or motion. In some implementations, a user may walk into their home, and this may trigger an input into a processing device. For example, the input device(s) 2826 may then facilitate an automated experience for the user. Other embodiments include other input devices 2826. The input devices can be connected to the processing device 2802 through an input/output interface 2836 that is coupled to the system bus 2806. These input devices 2826 can be connected by any number of input/output interfaces, such as a parallel port, serial port, game port, or a universal serial bus. Wireless communication between input devices 2826 and the input/output interface 2836 is possible as well, and includes infrared, BLUETOOTH® wireless technology, 802.11a/b/g/n, cellular, ultra-wideband (UWB),

ZigBee, or other radio frequency communication systems in some possible embodiments, to name just a few examples.

[0225] In this example embodiment, a display device 2838, such as a monitor, liquid crystal display device, light-emitting diode display device, projector, or touch sensitive display device, is also connected to the system bus 2806 via an interface, such as a video adapter 2840. In addition to the display device 2838, the computing device 2800 can include various other peripheral devices (not shown), such as speakers or a printer.

[0226] The computing device 2800 can be connected to one or more networks through a network interface 2842. The network interface 2842 can provide for wired and/or wireless communication. In some implementations, the network interface 2842 can include one or more antennas for transmitting and/or receiving wireless signals. When used in a local area networking environment or a wide area networking environment (such as the Internet), the network interface 2842 can include an Ethernet interface. Other possible embodiments use other communication devices. For example, some embodiments of the computing device 2800 include a modem for communicating across the network.

[0227] The computing device 2800 can include at least some form of computer readable media. Computer readable media includes any available media that can be accessed by the computing device 2800. By way of example, computer readable media include computer readable storage media and computer readable communication media.

[0228] Computer readable storage media includes volatile and nonvolatile, removable and non-removable media implemented in any device configured to store information such as computer readable instructions, data structures, program modules or other data. Computer readable storage media includes, but is not limited to, random access memory, read only memory, electrically erasable programmable read only memory, flash memory or other memory technology, compact disc read only memory, digital versatile disks or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by the computing device 2800.

[0229] Computer readable communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” refers to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, computer readable communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency, infrared, and other wireless media. Combinations of any of the above are also included within the scope of computer readable media.

[0230] The computing device illustrated in FIG. 28 is also an example of programmable electronics, which may include one or more such computing devices, and when multiple computing devices are included, such computing devices can be coupled together with a suitable data communication network so as to collectively perform the various functions, methods, or operations disclosed herein.

[0231] The terms “substantially” and “about” used throughout this Specification are used to describe and account for small fluctuations, such as due to variations in processing. For example, they can refer to less than or equal to ±5%, such as less than or equal to ±2%, such as less than or equal to ±1%, such as less than or equal to ±0.5%, such as less than or equal to ±0.2%, such as less than or equal to ±0.1%, such as less than or equal to ±0.05%. Also, when used herein, an indefinite article such as "a" or "an" means "at least one."

[0232] It should be appreciated that all combinations of the foregoing concepts and additional concepts discussed in greater detail below (provided such concepts are not mutually inconsistent) are contemplated as being part of the inventive subject matter disclosed herein. In particular, all combinations of claimed subject matter appearing at the end of this disclosure are contemplated as being part of the inventive subject matter disclosed herein.

[0233] Some ideas and possible combinations of ideas are illustrated by the following examples.

[0234] Example 1 : A computer-implemented method of performing closed-loop insulin therapy, the method comprising: receiving blood glucose values and bolus information regarding a person with diabetes, the blood glucose values and the bolus information relating to a period of time; determining, based on the blood glucose values, the bolus information, and a meal size propensity record regarding the person, an amount of insulin for the person; and causing, in response to the determination, the amount of insulin to be administered to the person.

[0235] Example 2: The computer-implemented method of Example 1, wherein determining the amount of insulin comprises determining, based on the blood glucose values, the bolus information, and the meal size propensity record, a size of a meal ingested by the person, and selecting the amount of insulin based on the determined size of the meal.

[0236] Example 3: The computer-implemented method of Example 2, wherein the meal size propensity record is a personalized meal size propensity record for the person.

[0237] Example 4: The computer-implemented method of Example 2, wherein the meal size propensity record corresponds to a population.

[0238] Example 5: The computer-implemented method of any of Examples 1-4, wherein determining the amount of insulin comprises determining, based on the blood glucose values, the bolus information, and the meal size propensity record, a timing of a meal ingested by the person, and selecting the amount of insulin based on the determined timing of the meal.

[0239] Example 6: The computer-implemented method of any of Examples 1-5, further comprising performing dose capture regarding the person, wherein the bolus information is obtained based on the dose capture.

[0240] Example 7: The computer-implemented method of any of Examples 1-6, wherein the meal size propensity record is based on a first time period, the method further comprising receiving another meal size propensity record that is based on a second time period of different length than the first time period, and determining another amount of insulin for the person based on the other meal size propensity record.

[0241] Example 8: The computer-implemented method of any of Examples 1-7, further comprising taking into account a gesture of the person with diabetes.

[0242] Example 9: A computer program product stored in a non-transitory storage medium, the computer program product including instructions that when executed by at least one processor cause the at least one processor to perform operations comprising: receiving blood glucose values and bolus information regarding a person with diabetes, the blood glucose values and the bolus information relating to a period of time; determining, based on the blood glucose values, the bolus information, and a meal size propensity record regarding the person, an amount of insulin for the person; and causing, in response to the determination, the amount of insulin to be administered to the person.

[0243] Example 10: A closed-loop insulin treatment device comprising: a glucose sensor; an insulin injection device; and a closed-loop control device having a meal size propensity record regarding a person with diabetes, the closed-loop control device configured to receive blood glucose values from the glucose sensor and bolus information regarding the person, the blood glucose values and the bolus information relating to a period of time, the closed-loop control device further configured to determine, based on the blood glucose values, the bolus information, and the meal size propensity record, an amount of insulin for the person, and to cause the insulin injection device to inject the amount of insulin to the person.

[0244] Example 11 : The closed-loop insulin treatment device of Example 10, wherein the closed-loop control device comprises a closed-loop controller configured to apply the blood glucose values and the bolus information to a dynamic model.

[0245] Example 12: The closed-loop insulin treatment device of Example 11, wherein the dynamic model comprises a meal prediction component configured to predict, based on the blood glucose values, the bolus information, and the meal size propensity record, a meal size for the person.

[0246] Example 13: The closed-loop insulin treatment device of any of Examples 11- 12, wherein the dynamic model comprises a meal determination component configured to determine, based on the blood glucose values, the bolus information, and the meal size propensity record, a size of a meal ingested by the person.

[0247] Example 14: The closed-loop insulin treatment device of any of Examples Il ls, wherein the dynamic model comprises a bolus prediction component configured to predict, based on the blood glucose values, the bolus information, and the meal size propensity record, a bolus size for the person.

[0248] Example 15: The closed-loop insulin treatment device of any of Examples 11-

14, wherein the dynamic model comprises a bolus determination component configured to determine, based on the blood glucose values, the bolus information, and the meal size propensity record, a size of a bolus administered to the person.

[0249] Example 16: The closed-loop insulin treatment device of any of Examples 10-

15, further comprising a gesture recognition component, wherein the closed-loop control device is further configured to take into account a gesture of the person with diabetes in determining the amount of insulin for the person. [0250] Example 17: A computer-implemented method comprising: receiving blood glucose values and bolus information regarding a person with diabetes, the blood glucose values and the bolus information relating to a period of time; receiving a meal size propensity record regarding the person; classifying, based on the blood glucose values, the bolus information, and the meal size propensity record, each of multiple time periods within the period of time regarding whether the time period is associated with ingestion of a meal by the person; performing regression analysis on the classified multiple time periods to identify a first time period of the classified multiple time periods as corresponding to a beginning of the meal, wherein the bolus information indicates no bolus associated with the identified first time period; and associating, based on the regression analysis, a missed bolus event with the meal.

[0251] Example 18: The computer-implemented method of Example 17, further comprising performing at least one action based on the event being associated with the period of time.

[0252] Example 19: The computer-implemented method of Example 18, wherein the action includes issuing an alert regarding the person.

[0253] Example 20: The computer-implemented method of Example 19, wherein the blood glucose values and the bolus information are received substantially in real time, and wherein the alert is issued substantially in real time with the bolus being missed.

[0254] Example 21 : The computer-implemented method of Example 20, wherein issuing the alert in real time comprises waiting a predetermined time after the beginning of the meal before determining that the bolus was missed.

[0255] Example 22: The computer-implemented method of any of Examples 17-21, wherein classifying the multiple time periods comprises providing the blood glucose values and the bolus information to a first machine-learning set including at least one classifier, and wherein performing the regression analysis comprises providing at least an output of the first machine-learning set to a second machine-learning set including at least one regressor.

[0256] Example 23: The computer-implemented method of Example 22, wherein the first machine-learning set includes multiple classifiers receiving also the blood glucose values and the bolus information, and wherein classifying each of the multiple time periods comprises generating one classification event for each of the multiple classifiers for each of the multiple time periods.

[0257] Example 24: The computer-implemented method of Example 23, further comprising providing each of the multiple classifiers with an aggregation of at least one of the blood glucose values or the bolus information.

[0258] Example 25: The computer-implemented method of any of Examples 17-24, wherein receiving the bolus information comprises receiving data generated by a pen cap based on the pen cap detecting at least one of a removal of the pen cap from an insulin pen, or a replacement of the pen cap on the insulin pen.

[0259] Example 26: The computer-implemented method of any of Examples 17-25, wherein receiving the bolus information comprises receiving amount information corresponding to an amount of insulin administered to the person.

[0260] Example 27: The computer-implemented method of any of Examples 17-26, further comprising generating the meal size propensity record based on the blood glucose values and the bolus information.

[0261] Example 28: The computer-implemented method of Example 27, further comprising generating multiple meal size propensity records corresponding to different days of a week for the person.

[0262] Example 29: The computer-implemented method of any of Examples 27-28, wherein generating the meal size propensity record comprises using a bolus probability density as a proxy for meal occurrence likelihood.

[0263] Example 30: The computer-implemented method of Example 29, further comprising generating the bolus probability density by aggregating bolus events for the person that are included in the bolus information.

[0264] Example 31 : The computer-implemented method of Example 30, wherein the bolus events are distributed within the period of time, and wherein aggregating the bolus events comprises: wrapping the bolus events over a time interval shorter than the period of time so that the bolus events are distributed within the time interval; generating, based on the bolus events wrapped over the time interval, a continuous distribution of likelihood over the time interval; and replicating the continuous distribution of likelihood at least once within the period of time.

[0265] Example 32: The computer-implemented method of Example 31, wherein generating the continuous distribution of likelihood comprises smoothing the bolus events wrapped over the time interval.

[0266] Example 33: The computer-implemented method of Example 32, wherein smoothing the bolus events comprises performing a kernel smoothed density estimate.

[0267] Example 34: The computer-implemented method of any of Examples 31-33, wherein generating the continuous distribution of likelihood comprises filtering the bolus events wrapped over the time interval.

[0268] Example 35: The computer-implemented method of any of Examples 17-34, wherein the meal size propensity record comprises a heat map having a first axis corresponding to carbohydrates and a second axis corresponding to time of day, wherein contents of the heat map indicate respective probabilities.

[0269] Example 36: The computer-implemented method of any of Examples 17-35, the method further comprising issuing an alert regarding the person based on the missed bolus event being associated with the meal.

[0270] Example 37: The computer-implemented method of Example 36, wherein the blood glucose values and the bolus information are received substantially in real time, and wherein the alert is issued substantially in real time with the bolus being missed.

[0271] Example 38: The computer-implemented method of any of Examples 36-37, further comprising taking into account the meal size propensity record before issuing the alert, wherein a relatively lower threshold for the alert is used when a current meal probability is relatively higher, wherein a relatively higher threshold for the alert is used when a current meal probability is relatively lower.

[0272] Example 39: The computer-implemented method of Example 38, wherein taking into account the meal size propensity record comprises changing a threshold for a feature in a machine-learning classifier based on a kernel smoothed density estimate in the meal size propensity record.

[0273] Example 40: The computer-implemented method of any of Examples 38-39, wherein taking into account the meal size propensity record comprises reducing a threshold for associating the missed bolus event with the meal.

[0274] Example 41: The computer-implemented method of any of Examples 17-40, wherein the bolus information includes bolus events that are delta functions, the method further comprising broadening, before classifying the multiple time periods, each of the bolus events to have a finite time duration.

[0275] Example 42: The computer-implemented method of Example 41, wherein broadening each of the bolus events comprises convolving the delta function with a rectangle function.

[0276] Example 43: The computer-implemented method of any of Examples 41-42, wherein no bolus being associated with the identified first time period comprises that the bolus information includes no bolus separated from the identified first time period by at most a predefined time, and wherein the finite time duration is a multiple of the predefined time. [0277] Example 44: The computer-implemented method of any of Examples 41-43, further comprising aggregating, before classifying the multiple time periods, the bolus events in multiple overlapping time intervals.

[0278] Example 45: The computer-implemented method of any of Examples 17-44, wherein the blood glucose values and the bolus information are received substantially in real time.

[0279] Example 46: The computer-implemented method of any of Examples 17-45, wherein the blood glucose values and the bolus information are received in batch.

[0280] Example 47: The computer-implemented method of any of Examples 17-46, wherein no bolus being associated with the identified first time period comprises that the bolus information includes no bolus separated from the identified first time period by at most a predefined time, and wherein the bolus information does include a bolus separated from the identified first time period by more than the predefined time, the method further comprising associating a late bolus event with the bolus.

[0281] Example 48: The computer-implemented method of any of Examples 17-47, further comprising receiving a gesture of the person with diabetes, wherein classifying the multiple time periods is further based on the gesture.

[0282] Example 49: A computer program product stored in a non-transitory storage medium, the computer program product including instructions that when executed by at least one processor cause the at least one processor to perform operations comprising: receiving blood glucose values and bolus information regarding a person with diabetes, the blood glucose values and the bolus information relating to a period of time; receiving a meal size propensity record regarding the person; classifying, based on the blood glucose values, the bolus information, and the meal size propensity record, each of multiple time periods within the period of time regarding whether the time period is associated with ingestion of a meal by the person; performing regression analysis on the classified multiple time periods to identify a first time period of the classified multiple time periods as corresponding to a beginning of the meal, wherein the bolus information indicates no bolus associated with the identified first time period; and associating, based on the regression analysis, a missed bolus event with the meal.

[0283] Example 50: The computer program product of Example 49, wherein the meal size propensity record is a personalized meal size propensity record for the person.

[0284] Example 51 : The computer program product of Example 49, wherein the meal size propensity record corresponds to a population. [0285] Example 52: A computer-implemented method of generating a meal size propensity record, the method comprising: receiving bolus information regarding a person with diabetes, the bolus information comprising bolus events distributed within a period of time; receiving carbohydrate announcements for the person regarding the period of time; and generating a meal size propensity record based on the bolus information and the carbohydrate announcements.

[0286] Example 53: The computer-implemented method of Example 52, further comprising processing the bolus information to determine a timing of meals ingested by the person during the period of time, the timing of the meals forming a first dimension for generating the meal size propensity record.

[0287] Example 54: The computer-implemented method of Example 53, wherein the carbohydrate announcements form a second dimension for generating the meal size propensity record.

[0288] Example 55: The computer-implemented method of any of Examples 53-54, further comprising receiving blood glucose values regarding the person for the period of time, wherein processing the bolus information comprises: classifying, based on the blood glucose values and the bolus information, each of multiple time periods within the period of time regarding whether the time period is associated with ingestion of a meal by the person; and performing regression analysis on the classified multiple time periods to identify a first time period of the classified multiple time periods as corresponding to a beginning of the meal, wherein the bolus information indicates no bolus associated with the identified first time period.

[0289] Example 56: The computer-implemented method of Example 55, wherein classifying the multiple time periods comprises providing the blood glucose values and the bolus information to a first machine-learning set including at least one classifier, and wherein performing the regression analysis comprises providing at least an output of the first machine-learning set to a second machine-learning set including at least one regressor.

[0290] Example 57: The computer-implemented method of Example 56, wherein the first machine-learning set includes multiple classifiers receiving also the blood glucose values and the bolus information, and wherein classifying each of the multiple time periods comprises generating one classification event for each of the multiple classifiers for each of the multiple time periods.

[0291] Example 58: The computer-implemented method of Example 57, further comprising providing each of the multiple classifiers with an aggregation of at least one of the blood glucose values or the bolus information.

[0292] Example 59: The computer-implemented method of any of Examples 52-58, wherein generating the meal size propensity record comprises using a bolus probability density as a proxy for meal occurrence likelihood.

[0293] Example 60: The computer-implemented method of Example 59, further comprising generating the bolus probability density by aggregating bolus events for the person that are included in the bolus information.

[0294] Example 61 : The computer-implemented method of Example 60, wherein the bolus events are distributed within the period of time, and wherein aggregating the bolus events comprises: wrapping the bolus events over a time interval shorter than the period of time so that the bolus events are distributed within the time interval; generating, based on the bolus events wrapped over the time interval, a continuous distribution of likelihood over the time interval; and replicating the continuous distribution of likelihood at least once within the period of time.

[0295] Example 62: The computer-implemented method of Example 61, wherein generating the continuous distribution of likelihood comprises smoothing the bolus events wrapped over the time interval.

[0296] Example 63: The computer-implemented method of Example 62, wherein smoothing the bolus events comprises performing a kernel smoothed density estimate.

[0297] Example 64: The computer-implemented method of any of Examples 61-63, wherein generating the continuous distribution of likelihood comprises filtering the bolus events wrapped over the time interval.

[0298] Example 65: The computer-implemented method of any of Examples 55-64, wherein the bolus information includes bolus events that are delta functions, the method further comprising broadening, before classifying the multiple time periods, each of the bolus events to have a finite time duration.

[0299] Example 66: The computer-implemented method of Example 65, wherein broadening each of the bolus events comprises convolving the delta function with a rectangle function.

[0300] Example 67: The computer-implemented method of any of Examples 52-66, further comprising receiving a gesture of the person with diabetes, wherein generating the meal size propensity record is further based on the gesture.

[0301] Example 68: A computer program product stored in a non-transitory storage medium, the computer program product including instructions that when executed by at least one processor cause the at least one processor to perform operations comprising: receiving bolus information regarding a person with diabetes, the bolus information comprising bolus events distributed within a period of time; receiving carbohydrate announcements for the person regarding the period of time; and generating a meal size propensity record based on the bolus information and the carbohydrate announcements.

[0302] A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the specification.

[0303] In addition, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. In addition, other processes may be provided, or processes may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems. Accordingly, other implementations are within the scope of the following claims.

[0304] While certain features of the described implementations have been illustrated as described herein, many modifications, substitutions, changes and equivalents will now occur to those skilled in the art. It is, therefore, to be understood that appended claims are intended to cover all such modifications and changes as fall within the scope of the implementations. It should be understood that they have been presented by way of example only, not limitation, and various changes in form and details may be made. Any portion of the apparatus and/or methods described herein may be combined in any combination, except mutually exclusive combinations. The implementations described herein can include various combinations and/or sub-combinations of the functions, components and/or features of the different implementations described.