Method and system for meal event detection and medication bolus calculation

Abstract

A method for drug bolus calculation has been developed. The method includes: receiving physiological measurements from an analyte sensor coupled to a user; receiving data corresponding to at least one meal event, the data including a timestamp corresponding to when a meal is ingested; identifying a missed meal event time, the missed meal event time corresponding to a meal ingested by the user and not corresponding to a timestamp of any meal event; calculating a suggested bolus based at least in part on a length of time elapsed from the missed meal event time to a current time; and generating an output message indicative of the suggested bolus of the medicament.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to systems and methods for identifying meal events and generating warnings and medication bolus recommendations for meals that are not properly logged in a diabetes management system, generally to the identification of hypoglycemic episodes and recovery meals, and more specifically to systems and methods for identifying meal events and calculating insulin bolus doses for individuals with diabetes. BACKGROUND

[0002] Some individuals with diabetes (PwDs) require daily injections of insulin to maintain healthy blood glucose levels, which are typically measured as glucose levels. In PwDs whose glucose levels are considered to be "in range," certain events, such as the ingestion of a meal, cause an elevation in glucose, which requires the administration of an insulin bolus to prevent hyperglycemia. Conversely, PwDs can experience hypoglycemic episodes, in which glucose levels drop below a recommended range, and the PwD ingests a meal or administers a hormone, such as glucagon, to restore glucose levels to within the range. PwDs who require injections of medication often use diabetes management software applications to provide bolus calculations to determine the appropriate dose of insulin or other medication that should be administered with a meal, or to track hypoglycemic episodes. Diabetes management software provides benefits not only for the short-term management of diabetes, but also for the long-term health of PwDs, as diabetes management applications can store records of glucose levels and instances and patterns of hyperglycemia and hypoglycemia over a longer period of time, which healthcare professionals can analyze to provide improved treatment for PwDs.

[0003] While existing diabetes management software can provide many benefits for PwDs, in some instances, PwDs do not consistently use the diabetes management software. For example, in some instances, PwDs ingest a meal and forget to use the diabetes management software to log the meal and administer the appropriate bolus of insulin or other medication with the meal. In other instances, PwDs experience hypoglycemia and need to ingest a meal or administer a medication, such as glucagon, to restore glucose to within range levels. Because hypoglycemic episodes often cause disorientation and can occur at night, PwDs can forget to use the diabetes management application to log the recovery from the hypoglycemic episode. Accordingly, it would be beneficial to have systems and methods that improve the identification of meal events, hypoglycemic events, and the calculation of medication boluses for PwDs. SUMMARY

[0004] In one embodiment, a method for medication bolus calculation has been developed. The method includes receiving, with a processor, a plurality of physiological measurements from an analyte sensor, the plurality of physiological measurements received as a time series of physiological measurements from an analyte sensor coupled with a user; identifying, with the processor, a missed meal event corresponding to a meal ingested by the user; calculating, with the processor, a suggested bolus to be administered in response to the missed meal event, the suggested bolus calculated based at least in part on a length of time elapsed from a timestamp of the missed meal event to a current time; and generating, with an output device coupled with the processor, an output message indicating the suggested bolus of medication. The identification of the missed meal event further includes generating the timestamp for the missed meal event based on a change in the plurality of physiological measurements corresponding to a time of the meal; identifying an elevated level of physiological measurements occurring after the timestamp that exceeds a predetermined threshold; and identifying that the timestamp for the missed meal event does not correspond to a timestamp of any of one or more additional meal events stored in a memory operatively coupled with the processor.

[0005] In another embodiment, a method for unrecorded meal identification in a diabetes management system has been developed. The method includes receiving, with a processor, a plurality of physiological measurements from an analyte sensor, the plurality of physiological measurements received as a time series of physiological measurements from an analyte sensor coupled with a user; identifying, with the processor, an unrecorded meal event corresponding to a meal ingested by the user; generating, with an output device coupled with the processor, an output to alert the user of the unrecorded meal event; and storing, with the processor, a record of the unrecorded meal event in a memory in response to receiving a confirmation via an input device coupled with the processor. The identification of the unrecorded meal event further includes generating a timestamp for the unrecorded meal event based on a change in the plurality of physiological measurements corresponding to a time of the meal; identifying a decrease in the plurality of physiological measurements corresponding to a physiological response to administration of a medication bolus occurring after the timestamp; and identifying that the timestamp for the unrecorded meal event does not correspond to a timestamp of any of one or more additional meal events stored in a memory operatively coupled with the processor.

[0006] In another embodiment, a method for recovery meal event detection in a diabetes management system has been developed. The method includes receiving, with a processor, a plurality of physiological measurements from an analyte sensor, the plurality of physiological measurements received as a time series of physiological measurements from an analyte sensor coupled with a user; identifying, with the processor, a recovery meal event corresponding to a meal ingested by the user; generating, with an output device coupled with the processor, an output to alert the user of the recovery meal event; and storing, with the processor, a record of the recovery meal event in a memory in response to receiving a confirmation via an input device coupled with the processor. The identification of the recovery meal event further includes generating a timestamp for the recovery meal event based on a change in the plurality of physiological measurements corresponding to a time of the meal; identifying at least a portion of the plurality of physiological measurements that occurred prior to the timestamp that are below a predetermined threshold; and identifying that the timestamp for the recovery meal event does not correspond to a timestamp of any of one or more additional meal events stored in a memory operatively coupled with the processor. BRIEF DESCRIPTION OF DRAWINGS

[0007] For ease of identification of the discussion of any particular element or action, one or more most significant digits of the reference characters refer to the figure number in which that element is first introduced.

[0008] FIG. 1 is a schematic diagram of an illustrative embodiment of a diabetes management system including a glucose sensor, an electronic device, and an optional medication delivery device.

[0009] FIG. 2 is a block diagram of a process for missed meal event detection and bolus recommendation using the system of FIG. 1.

[0010] FIG. 3 is a block diagram of a process for recovery meal event detection using the system of FIG. 1.

[0011] FIG. 4 is a block diagram of a process for detecting and recording a recovery meal event.

[0012] FIG. 5 is a graph depicting a series of glucose measurements generated during an unrecorded meal event using the system of FIG. 1.

[0013] FIG. 6 is a graph depicting a series of glucose measurements generated during a missed meal event using the system of FIG. 1.

[0014] FIG. 7 is a graph depicting a series of glucose measurements generated during a recovery meal event using the system of FIG. 1. DETAILED DESCRIPTION

[0015] These and other advantages, effects, features and objects of the application will become better understood from the following description, appended claims, and accompanying drawings. In the description, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration embodiments of the inventive concept. Throughout the drawings, corresponding reference numerals indicate corresponding parts.

[0016] While the inventive concept is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and are herein described in detail. It should be understood, however, that the description herein of specific embodiments is not intended to limit the inventive concept to the particular forms disclosed, but on the contrary, it is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the inventive concept as defined by the embodiments described herein and the appended claims. Accordingly, the scope of the inventive concept is intended to be defined only by the appended claims. Thus, it will be appreciated that the embodiments described herein can have advantages, effects and features that are useful in solving other problems.

[0017] Apparatuses, systems, and methods will now be described, by way of example only, with reference to the accompanying drawings in which are shown some, but not all, embodiments of the inventive concept. Indeed, these apparatuses, systems and methods can be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Like reference numerals refer to elements throughout.

[0018] Similarly, many modifications and other embodiments of the apparatuses, systems and methods described herein will come to mind to one skilled in the art to which the disclosure pertains having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the apparatuses, systems and methods are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the embodiments. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

[0019] Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of the present method, preferred methods and materials are described herein.

[0020] Furthermore, the use of the indefinite article "a / an" to refer to an element does not preclude the possibility of the existence of more than one element, unless the context explicitly requires that there be exactly one element. Therefore, the indefinite article "a / an" generally means "at least one / a." Similarly, the terms "have," "contain," or "include," or any arbitrary grammatical variations thereof, are used in a non-exclusive manner. Thus, these terms can refer to either a situation where no further features exist in the entity described herein besides those introduced by these terms, or a situation where one or more further features exist. For example, expressions such as "A has B," "A contains B," and "A includes B" can refer to a situation where no other elements exist in A besides B (i.e., A consists solely and exclusively of B), or a situation where one or more other elements exist in A besides B, such as element C, elements C and D, or even other elements.

[0021] As used herein, the term Individual with Diabetes (PwD) refers to a person diagnosed with one or more forms of diabetes or at risk of being diagnosed with one or more forms of diabetes, including prediabetes, type 1 diabetes, type 2 diabetes, gestational diabetes, and one or more comorbidities associated with diabetes. Some of the embodiments described herein refer more specifically to insulin-dependent PwD. Insulin-dependent PwDs administer insulin or similar medications to control glucose levels, and some insulin-dependent PwDs administer multiple daily doses of insulin to manage elevated glucose levels resulting from meal intake. A single dose of insulin is referred to as a bolus, and diabetes management applications allow the collection and viewing of diabetes log information and may include a bolus calculator to help the PwD determine the amount of each bolus to maintain glucose levels within a healthy range. While the exact glucose values ​​considered to be within the range may vary for a particular PwD, general guidelines known in the art recommend maintaining glucose levels within a range that does not exceed 140 or 180 mg / dL in the postprandial state or 100 mg / dL on an empty stomach to avoid hyperglycemia and does not drop below 70 mg / dL to avoid hypoglycemia.

[0022] As used herein, the term "physiological parameter" refers to any quantifiable aspect of PwD physiology measured as part of the provision of diabetes management services to PwD. A non-limiting list of physiological parameters of interest for the treatment of diabetes and diabetes comorbidities includes glucose, glycated hemoglobin (HbA1c), ketones, estimated glomerular filtration rate (eGFR), and blood pressure (BP).

[0023] As used herein, the term "meal event" refers to an event in which a PwD consumes a meal and administers a bolus of insulin or a similar medication targeted to maintain the PwD within a range. The diabetes management application records a meal event as a recorded event in which the consumption of the meal itself is recorded and in which a bolus of medication administered with the meal by the PwD is recorded. The diabetes management application can receive data for an identified meal event contemporaneously with or after the consumption of the meal and the bolus of medication at mealtime. As used herein, the term "unrecorded meal event" refers to an event in which a PwD consumes a meal and administers a bolus of medication but at least one of the meal or the bolus of medication is not entered into the diabetes management application. As used herein, the term "missed meal event" refers to an event in which a PwD consumes a meal but does not administer a bolus of medication or administers an insufficient amount of medication, which results in a post-meal hyperglycemic condition for the PwD. In some cases, the diabetes management application does not receive a record of the missed meal, while in other cases, the diabetes management application receives a record of the consumption of the missed meal, but the PwD fails to administer an appropriate bolus of medication to control the post-meal glycemic response to the meal. As used herein, the term "restorative meal event" refers to a meal or medication administered by a PwD to recover from a hypoglycemic episode. A restorative meal can include the consumption of food, particularly food with a high glucose content, the administration of a medication, such as glucagon, which raises glucose levels, or both. A restorative meal event restores the glucose level of the PwD to an acceptable post-meal level within a range.

[0024] FIG. 1 depicts a diabetes management system 100, which includes an electronic device 104, an analyte sensor 140, and an optional medication delivery device 160. In FIG. 1, the user 102 is an insulin-dependent PwD who uses the diabetes management system 100 to manage his or her diabetes, including using the diabetes management system 100 to receive bolus recommendations for insulin or another diabetes medication.

[0025] In the system 100, the electronic device 104 includes an electronic device processor 108, which is operatively connected to a communication interface 112, an input / output (I / O) device 116, and a memory 120. While specific attributes and operations of certain components in the electronic device 104 related to detecting and recording meal events and generating medication bolus recommendations are described in further detail herein, in at least some embodiments, the electronic device 104 is embodied as a commercially available smartphone, tablet computer, personal computer, wearable device such as a smartwatch or fitness tracker, or another suitable electronic device operated by the user 102.

[0026] In the electronic device 104, the processor 108 is a digital logic device formed of one or more integrated circuits that typically includes one or more central processing unit (CPU) cores and a graphics processing unit (GPU) to execute stored program instructions implementing operating systems and application software and provide a graphical user interface via one or more display devices, which are incorporated in the I / O device 116 in FIG. 1. Among other software programs, a diabetes management application configured to receive data from the analyte sensor 140, provide diabetes management recommendations and bolus recommendations to the user 102 via the I / O device 116, and optionally send bolus commands to the medicament delivery device 160 is one example of a software program that the processor 108 executes during operation. The diabetes management application is provided to the electronic device 104 via an online application store, an installation medium such as an optical disc or flash drive, or by any other installation process known in the art. The processor 108 further incorporates peripheral devices and memory controllers that provide operable connections with the communication interface 112, the I / O device 116, and the memory 120. Additional elements of the processor 108 optionally include a digital signal processor (DSP), an image processing unit, a neural network accelerator, an analog-to-digital converter, a digital-to-analog converter, and any other suitable digital and analog electronic components. For illustrative purposes, FIG. 1 depicts the processor 108, the communication interface 112, the I / O device 116, and the memory 120 as separate components, but in some embodiments, the processor 108 is implemented as a system-on-a-chip (SoC) configuration that incorporates components of some or all of the communication interface 112, the I / O device 116, and the memory 120.

[0027] In the electronic device 104, the communication interface 112 is a peripheral interface, e.g., wireless or wired, that provides a direct communication channel between the electronic device 104, the analyte sensor 140, and the medicament delivery device 160. Non-limiting examples of wireless communication interface devices include a Bluetooth transceiver implementing one or more of the Bluetooth series of protocols, including Bluetooth Low Energy (BLE) and near-field communication (NFC) adapters. Non-limiting examples of wired communication interface devices include universal serial bus (USB) adapters. Additionally, alternative communication interface embodiments including wired or wireless network interface adapters can also be used that provide compatible communication interfaces between the electronic device 104, the analyte sensor 140, and the medicament delivery device 160.

[0028] In the electronic device 104, the input / output [I / O] devices 116 include any hardware interface that enables the user 102 to receive information from and provide input to the diabetes management application and other software programs executed by the processor 108 during operation. Examples of input devices include input buttons, scroll wheels, keyboards, mice, touch screens, audio microphone inputs, camera devices, and the like. Examples of output devices include display screens, audio speakers, indicator lights, haptic feedback devices, and the like. During operation, the I / O devices 116 receive input from the user 102 to control the diabetes management application and provide manual feedback thereto, and the I / O devices provide output to the user 102 to provide bolus calculations and other diabetes management information.

[0029] In the electronic device 104, the memory 120 includes one or more volatile data storage devices, such as random access memory (RAM), and non-volatile data storage devices, such as solid state memory, magnetic media, or optical media that stores programmed instructions and data used to control operation of the electronic device 104. In particular, FIG. 1 depicts program instructions 122 stored by the memory 120 that implement the diabetes management application to perform the processes described herein. The stored program instructions 122 also include an operating system and other related commercially available software that controls operation of the electronic device 104. The memory 120 also stores time series data of physiological measurements 124, filtering criteria 126, and a history of meal events and hypoglycemic episode data 128 that the diabetes management application uses to provide bolus calculations and other diabetes management advice to the user 102.

[0030] While the electronic device 104 is depicted as a self-contained electronic device capable of all of the functions and operations described herein, those skilled in the art will recognize that more complex networked computing systems can be employed to perform portions of the functions and operations of the electronic device 104. For example, a network server computing system coupled with the electronic device 104 by a data network such as the Internet or another suitable network can receive the time series physiological measurement data 124, meal event and hypoglycemic event history data 128, and other data from the electronic device 104 and remotely execute stored program instructions for a diabetes management program to identify unrecorded meal events, missed meal events, recovery meal events, hypoglycemic episodes, and generate medication bolus recommendations and other diabetes management program recommendations. The mobile electronic device 104 receives the results of these computations and displays the results to the user 102 or performs other functions based on the results. In addition, in some configurations, a remote data storage server stores backup copies or greater historical archives of the time series physiological measurement data 124, meal event and hypoglycemic event history data 128, and other data from the electronic device 104. Thus, any reference to the operation of the processor 108, memory 120, or other elements of the electronic device 104 should be understood to apply equally to multiple computing systems that are communicatively coupled and configured to perform the functions and operations described herein.

[0031] In the system 100, the analyte sensor 140 is a device that generates physiological measurements of at least one chemical analyte in the body of the user 102. In most cases, the measured chemical analyte is a level of glucose, and more specifically blood sugar, which is measured directly or indirectly by the analyte sensor 140. In other configurations, the analyte sensor 140 detects other analytes, such as ketones. In one embodiment, the analyte sensor 140 is a commercially available continuous glucose monitor (CGM) device that is attached to the body of the user 102. The CGM analyte sensor 140 measures glucose values indirectly via interstitial fluid in the body of the user 102. The CGM analyte sensor 140 generates glucose measurements at regular intervals, such as every one minute, every five minutes, or at another periodic rate that enables generation of time series physiological measurements, such as time series glucose level measurements in the user 102.

[0032] In system 100, analyte sensor 140 includes a sensor controller 144, a sensor element 146, a communication interface 148, and a memory 152. Sensor controller 144 is a digital, analog, or combined digital / analog control device that is operatively connected with sensor element 146, communication interface 148, and memory 152. In most embodiments, sensor controller 144 executes firmware instructions stored in memory 152 (not shown) during operation. Sensor element 146 includes any electrochemical or other sensing hardware that performs detection of an analyte in the body of user 102 to generate physiological measurements. Sensor controller 144 operates sensor element 146 to generate measurements of a physiological parameter, such as glucose, and stores one or more physiological parameter measurements in memory 152 as a set of time series physiological measurements 154. Communication interface 148 in analyte sensor 140 is another communication interface device that is compatible with corresponding communication interface 112 in electronic device 104. During operation, sensor controller 144 operates communication interface 148 to transmit stored time series physiological measurements 154 to electronic device 104. Electronic device processor 108 stores the data as time series physiological measurement data 124 in memory 120. In one mode of operation, sensor controller 144 transmits each physiological measurement data to electronic device 104 with minimal delay after generation of each measurement, while in other embodiments, memory 152 stores a plurality of measurements in time series and transmits batches of the plurality of physiological measurements to electronic device 104 periodically or in response to on-demand requests from electronic device 104. Each physiological measurement data in physiological measurements 154 includes data corresponding to a measurement of an analyte, such as a quantitative value of a measured glucose level in user 102, a timestamp indicating when the measurement was generated, and any other metadata necessary to track the measured analyte physiological parameter over time in user 102.

[0033] In system 100, drug delivery device 160 is a pump, smart pen, or other drug delivery device configured to receive commands from electronic device 104 to deliver a suggested bolus of a drug, such as insulin, to user 102. Drug delivery device 160 includes a drug delivery system 164 that further includes a reservoir for the drug, electromechanical devices that control the rate and amount of drug delivered to user 102, and an electronic control device that operates the components of the drug delivery device and is operably connected to a communication interface 168. Communication interface 168 in drug delivery device 160 is another communication interface device that is compatible with corresponding communication interface 112 in electronic device 104. Drug delivery device 160 is an optional component of system 100, as in some configurations, electronic device 104 provides drug bolus suggestions to user 102, and user 102 subsequently manually administers the drug to the suggested bolus.

[0034] FIG. 1 describes system 100 for illustrative purposes, but one skilled in the art will recognize that many alternative hardware and software configurations are suitable for implementing the functionality described herein. For example, some or all of the functionality from electronic device 104 in FIG. 1 can be alternatively implemented in analyte sensor 140 or drug delivery device 160. Additionally, the functionality attributed to processor 108 in electronic device 104 need not be implemented entirely in a self-contained device, but can be performed at least in part by one or more processors in a network-connected server, and any description of a single processor is understood to encompass multiple processor devices that are orchestrated to implement the functionality described herein. Thus, while the description herein specifically refers to various components and processors in system 100, one skilled in the art will recognize that these descriptions are not limiting in scope and are equally applicable to various hardware and software configurations.

[0035] FIG. 2 is a block diagram of a process 200 for identifying unrecorded meal events and automatically generating a log to record the unrecorded meal events in a diabetes management system. In the following description, a reference to a function or operation of process 200 refers to the operation of one or more processors executing stored program instructions to perform the function or operation in conjunction with other components in a diabetes management system. For illustrative purposes, process 200 is described in conjunction with system 100 of FIG. 1. In particular, while stored program instructions 122 implement a diabetes management application that enables user 102 to record meals and drug boluses in a conventional manner, system 100 implements additional functionality of process 200 to enable automatic detection and recording of unrecorded meal events.

[0036] The process 200 begins when the electronic device 104 receives time series data of measured physiological parameters from the analyte sensor 140 (block 204). In the system 100, the analyte sensor 140 generates physiological measurements as time series glucose measurements or measurements of another analyte in the body of the user 102. The sensor controller 144 operates the communication interface 148 to transmit recorded physiological measurements and corresponding timestamps to the corresponding communication interface 112 of the electronic device 104. As described above, in some configurations the analyte sensor 140 transmits physiological measurement data with minimal delay, while in other configurations the analyte sensor memory 152 stores data of multiple time series physiological measurements 154 spanning a longer period of time, such as minutes or hours. In the electronic device 104, the processor 108 stores the glucose measurement data as time series physiological measurement data 124 in the memory 120. In some embodiments, the electronic device 104 stores a large set of physiological data of recorded physiological measurement data spanning days, weeks, or months, while the analyte sensor 140 stores a relatively small amount of physiological measurement data that is deleted after the data is transmitted to the electronic device 104.

[0037] The process 200 continues with the electronic device 104 identifying data corresponding to at least one unrecorded meal event based on the glucose data or other physiological measurement data and based on previously recorded meal events (block 208). In one configuration, the processor 108 in the mobile electronic device 104 automatically identifies a meal event based on an observed upward trend in the physiological measurement data of the user 102 and in particular based on an observed increase in glucose levels. FIG. 5 depicts a graph 500 plotting time series glucose values corresponding to a meal event that is considered an unrecorded meal event for purposes of the process 200 when the user 102 does not provide input to the system 100 recording meals and administered drug boluses. In one embodiment, the processor 108 identifies the unrecorded meal event based on a linear slope approximation or other derivative of the upward trend in glucose levels occurring within a predetermined time period after the meal, as depicted in region 508, and generates a timestamp of the mealtime (e.g., 8:30 AM) corresponding to the upward glucose trend in region 508. Alternative meal detection techniques can also be adapted for use with the diabetes management software in the system 100. An exemplary algorithm is described by Turksoy et al. in “Meal-Detection in Patients with Type 1 Diabetes: A New Module for The Multivariable Adaptive Artificial Pancreas Control System”, IEEE J Biomed Health Inform (January 2016). Still other techniques for meal detection include using an artificial neural network or other machine learning classifier trained to identify patterns in physiological parameters in time series data corresponding to meals from predetermined training data. In one embodiment, the timestamp of the estimated mealtime is a single time value, while in another embodiment, the timestamp includes a time range providing an estimate of the elapsed period of the meal. The processor 108 also identifies a downward trend in the measured post-meal glucose values 512, which depicts the user 102 returning to in-range glucose levels, indicating that the user 102 administered a drug bolus with the meal. The downward trend in physiological parameter data, such as the glucose levels in FIG. 5, indicates a physiological response by the user 102 to the administration of a drug bolus during the unrecorded meal event. The processor 108 compares the estimated timestamp of the detected meal event to the timestamps of previously recorded meal events in the meal event data 128 in the memory 120 to determine that the detected meal event is an unrecorded meal event when the previously recorded meal events do not have the same or similar timestamps.

[0038] Process 200 continues with processor 108 generating an estimated mealtime and medication bolus log entry record for the identified unrecorded meal (block 212). In one configuration, processor 108 uses the estimated time stamp of the unrecorded meal event to generate a record of the meal, and system 100 receives further data from user 102 at a later time regarding the amount and content of the meal and the amount of medication bolus. In another configuration, processor 108 optionally estimates the nutritional content of the meal in terms of total calories, carbohydrates / fat / protein, or any other appropriate nutritional metric. In one embodiment, processor 108 generates an estimate based on the magnitude of the rise in glucose levels present in the physiological measurement data. In another embodiment, processor 108 uses a previously trained machine learning (ML) prediction model that generates an estimate based on the physiological measurement data in the time frame of the unrecorded meal. In one configuration, medication delivery device 160, such as an insulin pump or insulin smart pen, records the amount of medication bolus administered and transmits the bolus amount to electronic device 104. Processor 108 stores the bolus data with meal event data 128, and optionally can use the time of bolus delivery to assist in determining the time of the unrecorded meal event. In other configurations where precise medication bolus data is not available, processor optionally uses a pre-existing bolus calculation algorithm to generate an estimate of the administered bolus for the unrecorded meal event. The bolus calculation algorithm uses the physiological measurement data of the rise in glucose relative to target range glucose levels in the time frame of the unrecorded meal, a predetermined insulin sensitivity factor for user 102, and the estimated nutritional information of the unrecorded meal to determine an estimate of the administered medication bolus.

[0039] Process 200 continues with processor 108 applying one or more filtering criteria to the unrecorded meal event to identify whether the unrecorded meal event satisfies the one or more filtering criteria to enable generation of an alert to prompt user 102 to input verification or correction of the estimated record of the unrecorded meal event (block 216). In electronic device 104, memory 120 stores filtering criteria data 126 that includes predefined or dynamically configured rules to control when the diabetes management application generates a prompt for user 102 to provide information about an unrecorded meal. In the embodiment of FIG. 1, filtering criteria data 126 includes a time of day filtering criteria corresponding to a sleep schedule of user 102. The sleep schedule filtering criteria can be set by default for the diabetes management application, or user 102 can input sleep schedule criteria to dynamically update the criteria values. Examples of other filtering criteria include a minimum elapsed time from a most recent prior alert to require before generating a new alert to reduce user fatigue during operation of system 100, and a filtering criteria to suppress an alert about an unrecorded meal when another meal event or medication bolus is predicted to occur within a threshold time period when user 102 is expected to have been available to interact with system 100.

[0040] If processor 108 in electronic device 104 identifies that user 102 is likely to be asleep or does not satisfy one or more other filtering criteria based on the current time (block 216), processor 108 waits for the next launch of the diabetes management application in system 100 to receive verification or additional information about the generated unrecorded meal event (block 220). In some configurations, when user 102 next launches the diabetes management application, the diabetes management application presents confirmation output to user 102 to verify that the meal event occurred at the identified time, and optionally enables user 102 to provide additional information about the meal event, which processor 108 stores with meal event data 128 or corrects the automatically generated estimated information about the meal event. As described above, the additional information about the meal includes elements such as an estimate of the meal amount, a total number of calories, a ratio of carbohydrates / protein / fat in the meal, or any other suitable information about the meal. If user 102 did not consume a meal at the time of the detected unrecorded meal, processor 108 deletes the unrecorded meal event record, or prompts user 102 to input a corrected time if the unrecorded meal event occurred at a different time than the automatically identified time of the unrecorded meal event.

[0041] If the processor 108 in the electronic device 104 identifies that the filtering criteria are met (block 216), the processor 108 generates an alert to receive verification and additional information about the generated unrecorded meal event (block 224). In this configuration, the processor 108 generates a visual, audio, audiovisual, or haptic alert to the user 102 via the I / O device 116 in the electronic device 104. The electronic device 104 receives verification and additional data of the unrecorded meal event from the user 102 in a manner similar to that described above with reference to the processing of block 220.

[0042] The electronic device 104 generates an output notifying the user 102 of the identified meal event, and the user 102 confirms ingestion of the meal at the timestamp of the identified meal, optional details about the meal, and the dose of the administered drug bolus. If the user 102 did not ingest the meal within the general time range of the detected meal or did not administer the estimated drug bolus, the diabetes management application receives a denial of the meal event from the user and deletes the meal event or receives input from the user 102 to modify the information related to the meal event. In another configuration, the electronic device 104 receives meal event data as input from the user 102 via the I / O device 116, the input indicating the time of ingestion of the meal and optionally including information about the meal, such as an estimate of the meal amount, a total number of calories, a ratio of carbohydrates / protein / fat in the meal, or any other suitable information about the meal.

[0043] FIG. 3 is a block diagram of a process 300 for identifying a missed meal event and generating a drug bolus recommendation in a diabetes management system. In the following description, a reference to a function or operation of the process 300 refers to the operation of one or more processors executing stored program instructions to perform the function or operation in conjunction with other components in the diabetes management system. For illustrative purposes, the process 300 is described in conjunction with the system 100 of FIG. 1. In the system 100, the processor 108 in the electronic device 104 can implement the process 300 concurrently with the process 200 described above, or configured to perform either process separately.

[0044] Process 300 begins when electronic device 104 receives time series data of measured physiological parameters from analyte sensor 140 (block 304). During process 300, electronic device 104 receives physiological parameter data, such as glucose data, from analyte sensor 140 in substantially the same manner as described above with reference to the processing of block 204 in process 200. In some embodiments, processor 108 concurrently performs processes 200 and 300 using a common set of physiological parameter data received from analyte sensor 140.

[0045] Process 300 continues with processor 108 identifying a missed meal event based on the physiological parameter data and a record of previously logged meals (block 308). While user 102 can log most meal events, in some cases, user 102 consumes a meal without administering an appropriate bolus of insulin or other medication with the meal to control post-meal glucose levels, which results in a hyperglycemic condition. In electronic device 104, processor 108 identifies a missed meal event based on both the received physiological measurement data, such as time series glucose data, and a record of previously identified meal events to avoid inaccurate association of a missed meal event with a previously identified meal event. In some cases, user 102 only intermittently activates a diabetes management application in electronic device 104, and electronic device 104 receives a backlog of physiological parameter data from analyte sensor 140 to enable processor 108 to identify missed meal events in time series physiological parameter measurements, such as time series glucose measurements.

[0046] Figure 6 depicts a graph 600 showing time-series glucose values ​​corresponding to missed meal events. Processor 108 identifies meal events in a manner similar to the unrecorded meal detection process described in block 208 of reference process 200 above, based on a linear slope approximation or other derivative of the upward trend in glucose levels occurring within a predetermined time period after the meal, as depicted in region 608, or using another meal detection algorithm known in the art. Processor 108 generates a timestamp for the meal time (e.g., 6:30 PM) corresponding to the upward glucose trend region 608 in a manner similar to that described in graph 500 of reference Figure 5 above. Processor 108 identifies a meal event as a missed meal event, not a recorded meal event, unrecorded meal event, or resuming meal event based on two factors: a timestamp of the estimated time of the meal (which does not correspond to the timestamp of the identified meal event or the recorded bolus); and postprandial glucose data that remains elevated above a target range threshold after the missed meal event timestamp without showing any indication of returning to levels within the range that would occur when user 102 administers the appropriate bolus of medication. Figure 6 In the context, range 612 indicates an extended period of elevated glucose levels in physiological measurement data that exceed a predetermined maximum threshold (e.g., 120 mg / dL), without indicating a downward progression to glucose levels within the range, and processor 108 identifies missed meal events in part based on this postprandial response.

[0047] Referring again to Figure 3, after identifying a missed meal event, processor 108 generates an alert to inform user 102 of the missed meal, and optionally receives verification of the missed meal, as well as additional data (block 320) corresponding to the time and nutritional content of the missed meal event. In mobile electronic device 104, processor 108 records the time of the meal event associated with meal event data 128. The diabetes management application also presents an acknowledgment output to user 102 to confirm that the meal event occurred at the identified time, and optionally enables user 102 to provide additional information about the meal event that processor 108 stores along with meal event data 128. In some configurations, if the automatically generated timestamp is inaccurate but the user did indeed consume the meal within the general timeframe indicated by the glucose data, user 102 optionally updates the timestamp of the missed meal event. However, if user 102 does not consume the meal corresponding to the missed meal event, user 102 enters a denial in response to the confirmation output, and the diabetes management application cancels any meal bolus calculation and does not record the missed meal event.

[0048] During the process 300, if the user 102 confirms a missed meal event, the processor 108 executes the diabetes management application to generate a bolus recommendation for the missed meal event, the bolus recommendation applying a time discount factor based on a length of time elapsed since the missed meal event to a current time (block 324). Using the system 100 of FIG. 1 as an example, the processor 108 utilizes existing art bolus calculation algorithms to generate a recommended bolus amount for the user 102, just as the user 102 would have entered meal time information to calculate a medication bolus at the time of the meal, such as calculating a meal bolus during an identified meal event. Thus, the diabetes management application can utilize existing bolus calculation algorithms to generate a meal bolus recommendation. Since the missed meal event occurs after the ingestion of a meal, during the process 300 the processor 108 identifies a length of time elapsed from the time of the missed meal event to a current time and applies a time varying discount factor to the recommended bolus amount, the time varying discount factor generally adjusting downward the amount of the recommended meal bolus to account for the elapsed time since the missed meal event occurred. The discount factor described herein is relative to the difference between a meal bolus, which is generally a larger medication bolus that accounts for the intake of carbohydrates, and a correction bolus, which is a medication bolus calculated to lower a hyperglycemic glucose level to a glucose level within a predetermined range of the PwD without accounting for a specific intake of carbohydrates, and is generally a smaller medication bolus than a meal bolus. In one example, the processor 108 uses the following table of time discount factors in the diabetes management application: Table 1: Example time varying discount factors Table 1 depicts linear discount factors that are applied to the amount of a suggested mealtime bolus from the bolus calculation algorithm based on elapsed time from the timestamp of the missed meal event, where a brief delay (0 to 15 minutes) results in a suggested full mealtime bolus (100%) and progressively longer delays result in a percentage scaling of the suggested mealtime bolus amount to 0% after 60 minutes (only the calculation of the standard correction bolus). For example, if the undiscounted calculated mealtime bolus is 8 units of insulin and the calculated correction bolus is 4 units of insulin, then at the time of calculating the bolus 30 minutes after the meal was ingested, a 50% discount factor results in a suggested 6 units of insulin bolus. Of course, the discount factors of Table 1 are merely illustrative examples, and alternative configurations of discount factors using discrete or continuous timeline linear decay functions, piecewise decay functions, exponential decay functions, logarithmic decay functions, or any other suitable decay function. Moreover, alternative configurations can use a discount time range that is longer or shorter than the 60 minute time range depicted by Table 1. In the event that the elapsed time from the timestamp of the missed meal event exceeds a maximum time threshold for mealtime bolus calculation, the diabetes management application optionally generates a correction bolus calculation if the user 102 remains in a hyperglycemic state. The correction bolus calculation typically does not use specific data about the ingested meal in the bolus calculation, but rather calculates a bolus based on the current measured glucose level, the user's 102 predetermined insulin sensitivity, the desired target glucose level to return the user 102 to an in-range glucose level, and the prior history of meals and boluses to provide a safe and effective correction bolus.

[0049] Process 300 continues with processor 108 generating an output message to user 102 and optionally to drug delivery device 160 indicating a recommended bolus to deliver a recommended bolus of insulin or another drug to user 102 (block 328). In electronic device 104, processor 108 operates one or more of I / O devices 116 to produce an output message to user 102 indicating a recommended bolus of a drug. In one configuration, a display device in electronic device 104 generates a visual display of the recommended bolus, while in another configuration, processor 108 uses speech synthesis hardware and software to generate an audible output of the recommended bolus using an audio speaker, and electronic device 104 optionally uses multiple output devices to generate the output. In configurations of system 100 that include drug delivery device 160, electronic device 104 optionally transmits a command message to drug delivery device 160 to operate drug delivery device 160 to administer a recommended bolus of insulin or other drug to user 102. For example, processor 108 transmits a command message to a corresponding communication interface 168 in drug delivery device 160 using communication interface 112. User 102 uses a smart pen-type drug device to inject a drug at a set bolus dose based on the command message, or if drug delivery device 160 is a drug pump, pump 160 delivers a bolus in response to the command message from electronic device 104.

[0050] Processes 200 and 300 are generally, although not exclusively, performed in response to a meal ingested by user 102 as part of his or her daily routine. In other cases, a PwD ingests a recovery meal in response to a hypoglycemic episode to restore his or her glucose level to a healthy range. In most cases, a PwD does not need to administer a dose of insulin or other drug as a result of a recovery meal, but a diabetes management application stores a record of the hypoglycemic episode and recovery meal to assist the PwD and healthcare providers in long-term glucose management to avoid future hypoglycemic episodes. Thus, ensuring that a diabetes management application receives accurate information about a recovery meal provides a medical benefit to user 102.

[0051] FIG. 4 is a block diagram of a process 400 for detecting and recording a recovery meal taken by a PwD to recover from a hypoglycemic episode in a diabetes management system. In the following description, reference to the function or operation of process 300 refers to the operation of one or more processors executing stored program instructions to perform the function or operation in conjunction with other components in a diabetes management system. Process 400 is described in conjunction with system 100 of FIG. 1 for illustrative purposes. In system 100, processor 108 in electronic device 104 can implement process 400 concurrently with one or both of processes 200 and 300 described above, or configured to perform any of these processes separately.

[0052] Process 400 begins when electronic device 104 receives time series data of measured physiological parameters from analyte sensor 140 (block 404). During process 400, electronic device 104 receives physiological parameter data, such as glucose data, from analyte sensor 140 in substantially the same manner as described above with reference to the processing of block 204 in process 200. In some embodiments, processor 108 uses a common set of physiological parameter data received from analyte sensor 140 to concurrently perform one or more of processes 200, 300, and 400.

[0053] Process 400 continues with processor 108 in electronic device 104 identifying a hypoglycemic recovery meal event based on the physiological measurement data and at least one meal event (block 408). While hypoglycemic episodes can occur at any time of day, many hypoglycemic episodes occur during the night when the PwD is sleeping, and hypoglycemic episodes often result in disorientation. Thus, in many cases, user 102 can take a recovery meal, but will not use the diabetes management application to record the recovery meal at the time of the hypoglycemic episode. In electronic device 104, processor 108 identifies a recovery meal event based on both the received physiological measurement data, such as time series glucose data, and a record of previously identified meal events to avoid inaccurate association of the recovery meal event with a previously identified meal event. In some cases, user 102 only intermittently activates the diabetes management application in electronic device 104, and electronic device 104 receives a backlog of physiological parameter data from analyte sensor 140 to enable processor 108 to identify a recovery meal event in the time series physiological parameter measurements, such as time series glucose measurements.

[0054] FIG. 7 depicts a graph 700 plotting time-series glucose values corresponding to a restorative meal event. Processor 108 identifies a restorative meal event based on a minimum glucose level threshold 702 indicating that user 102 has experienced a hypoglycemic event, as the time-series glucose data falls below the threshold. In the example of FIG. 7, the minimum glucose level threshold 702 is indicated as 70 mg / dL, but in electronic device 104 the diabetes management application can be configured with different threshold levels. Processor 108 identifies a hypoglycemic onset based on the time-series of glucose levels falling below the minimum glucose threshold 702, which is indicated in region 708 of graph 700 in FIG. 7. Processor 108 detects a meal using one of the meal detection techniques described above in processes 200 and 300 in response to elevated glucose levels in the physiological parameter data as depicted by region 712 of graph 700 to generate an estimated timestamp for the restorative meal. Processor 108 identifies the meal event as a restorative meal event both based on the estimated time of the meal, which does not correspond to a time at which a prior recorded meal event, and based on the measurement and time-series glucose data in region 708 of the hypoglycemic onset and recovery from the hypoglycemic onset in region 712 of the glucose levels. Specifically, for a restorative meal event, processor 108 generates an estimated timestamp for the restorative meal as being within the hypoglycemic event time range 708 and corresponding to an upward trend in glucose levels as depicted by region 712, and recovery to in-range glucose levels. These features distinguish a restorative meal event from an unrecorded meal event or a missed meal event.

[0055] Referring again to FIG. 4, during process 400, processor 108 applies one or more filtering criteria to the restorative meal event to identify whether the restorative meal event satisfies one or more filtering criteria to enable generation of an immediate alert to prompt user 102 to input a verification or correction of the record of the identified restorative meal event (block 412). In system 100, processor 108 uses filtering criteria 126 to determine whether the time or other aspects of the restorative meal event satisfy the requirements for generation of an immediate alert, or if the criteria are not satisfied, to wait for a subsequent activation of the diabetes management application to alert user 102 for the restorative meal event. While processor 108 applies filtering criteria 126 in a similar manner in processes 200 and 400, in some embodiments, the particular set of filtering criteria rules applied to unrecorded meal events can be different from the particular set of filtering criteria rules applied to restorative meal events.

[0056] If the identified recovery meal event does not satisfy the application's filtering criteria (block 412), the process 400 continues with the electronic device 104 not generating an immediate output alert to the user 102, but waiting for a subsequent activation of the diabetes management application to receive a further confirmation of the low blood glucose recovery meal event (block 414). However, if the identified recovery meal event satisfies the application's filtering criteria (block 412), the process 400 continues with the electronic device 104 generating an output to alert the user 102 for the identification of the recovery meal event (block 416). In some configurations, the processor 108 uses the I / O device 116 to generate the output when the user 102 next activates the diabetes management application after the low blood glucose episode and recovery meal have occurred. In other configurations, the processor 108 uses the I / O device 116 to generate the output at a preconfigured time, such as when the user 102 normally wakes up in the morning or at the user's 102 next meal event.

[0057] The output alert includes a confirmation prompt that enables the user 102 to confirm that the recovery meal event occurred or indicate that no recovery meal event occurred. If the electronic device 104 receives user input that does not confirm the recovery meal event (block 416), the electronic device 104 ignores the recovery meal and the processor 108 does not record the recovery meal event in the meal event and low blood glucose episode history data 128 (block 420). However, in at least some configurations, even if the user 102 indicates that no recovery meal event occurred, the processor 108 generates a record of the low blood glucose event based on the physiological parameter data from the analyte sensor 140, but this record does not include additional data regarding the recovery meal. However, if the electronic device 104 receives user input that confirms the recovery meal event (block 416), the processor 108 stores a record of the low blood glucose episode and recovery meal event in the meal event and low blood glucose episode history data 128 (block 424). As part of the record, the diabetes management application optionally prompts the user 102 to input additional information regarding the recovery meal event, such as inputting the type and amount of food ingested, if the PwD administered a medication, such as glucagon, in addition to or in place of the food eaten, and inputting any symptoms associated with the low blood glucose episode. The electronic device 104 receives the input of the additional recovery meal event information via the I / O device 116.

[0058] The system 100, and processes 200, 300, and 400 described above implement improvements in tracking ingestion of unrecorded meals; calculating insulin or other medication boluses when a PwD fails to administer an appropriate medication bolus with a missed meal; and detecting a restorative meal associated with a hypoglycemic episode. These processes benefit the PwD’s diabetes management using the system 100 in making meal logging more effective and in providing dynamic updates to bolus recommendations in the event of a missed meal. These processes also improve the operation of the diabetes management software by greater accuracy in tracking meal events and hyperglycemic or hypoglycemic episodes, which improves the system 100’s ability to provide accurate recommendations for diabetes management.

[0059] The disclosure has been described in connection with the embodiments presented herein that are believed to be most useful and preferred. However, the scope of the disclosure is not intended to be limited to the disclosed embodiments. Therefore, persons skilled in the art understand that all modifications and alternatives falling within the spirit and scope of the disclosure are encompassed by the disclosure as set forth in the claims that follow.

[0060] Numbered examples: 1. A method for medication bolus calculation, comprising: providing stored program instructions of a diabetes management application configured to be stored in a memory of an electronic device and, when executed by a processor in the electronic device, the diabetes management application is configured to: receive a plurality of physiological measurements from an analyte sensor, the plurality of physiological measurements received as a time series of physiological measurements from an analyte sensor coupled with a user; identify a missed meal event corresponding to a meal ingested by the user, the diabetes management application further configured to: generate a timestamp for the missed meal event based on a change in the plurality of physiological measurements corresponding to a time of the meal; identify an elevated level of physiological measurements occurring after the timestamp that exceeds a predetermined threshold; and identify that the timestamp for the missed meal event does not correspond to a timestamp of any of one or more additional meal events stored in a memory operably coupled with the processor; calculate a recommended bolus to be administered in response to the missed meal event, the recommended bolus calculated based at least in part on a length of time elapsed from the timestamp of the missed meal event to a current time; and generate, with an output device coupled with the processor, an output message indicating the recommended bolus of medication.

[0061] 2. A computer program product comprising program instructions configured to operate a processor to: receive a plurality of physiological measurements from an analyte sensor, the plurality of physiological measurements received as a time series of physiological measurements from an analyte sensor coupled with a user; identify a missed meal event corresponding to a meal ingested by the user, the processor further configured to: generate a timestamp for the missed meal event based on a change in the plurality of physiological measurements corresponding to a time of the meal; identify an elevated level of physiological measurements occurring after the timestamp that exceed a predetermined threshold; and identify that the timestamp for the missed meal event does not correspond to a timestamp of any of one or more additional meal events stored in a memory operably coupled with the processor; calculate a suggested bolus to be administered in response to the missed meal event, the suggested bolus calculated based at least in part on a length of time elapsed from the timestamp of the missed meal event to a current time; and generate, with an output device coupled with the processor, an output message indicating the suggested bolus of medication.

[0062] 3. A method for missed meal identification in a diabetes management system, comprising: providing stored program instructions of a diabetes management application, the diabetes management application configured to be stored in a memory of an electronic device and, when executed by a processor in the electronic device, the diabetes management application configured to: receive a plurality of physiological measurements from an analyte sensor, the plurality of physiological measurements received as a time series of physiological measurements from an analyte sensor coupled with a user; identify a recovery meal event corresponding to a meal ingested by the user, the processor further configured to: generate a timestamp for the recovery meal event based on a change in the plurality of physiological measurements corresponding to a time of the meal; identify at least a portion of the plurality of physiological measurements occurring before the timestamp that are below a predetermined threshold; and identify that the timestamp for the recovery meal event does not correspond to a timestamp of any of one or more additional meal events stored in a memory operably coupled with the processor; generate, with an output device, an output to alert the user of the recovery meal event; and store a record of the recovery meal event in the memory in response to receiving a confirmation via an input device coupled with the processor.

[0063] 4. A computer program product comprising program instructions configured to operate a processor to: receive a plurality of physiological measurements from an analyte sensor, the plurality of physiological measurements received as a time series of physiological measurements from an analyte sensor coupled with a user; identify a recovery meal event corresponding to a meal ingested by the user, the processor further configured to: generate a timestamp for the recovery meal event based on a change in the plurality of physiological measurements corresponding to a time of the meal; identify at least a portion of the plurality of physiological measurements occurring prior to the timestamp that are below a predetermined threshold; and identify that the timestamp for the recovery meal event does not correspond to a timestamp of any of one or more additional meal events stored in a memory operatively coupled with the processor; generate output with an output device to alert the user about the recovery meal event; and store a record of the recovery meal event in the memory in response to receiving a confirmation via an input device coupled with the processor.

[0064] 5. A method for recovery meal event identification in a diabetes management system, comprising: providing stored program instructions of a diabetes management application configured to be stored in a memory of an electronic device, and when executed by a processor in the electronic device, the diabetes management application is configured to: receive a plurality of physiological measurements from an analyte sensor, the plurality of physiological measurements received as a time series of physiological measurements from an analyte sensor coupled with a user; identify a recovery meal event corresponding to a meal ingested by the user, the processor further configured to: generate a timestamp for the recovery meal event based on a change in the plurality of physiological measurements corresponding to a time of the meal; identify at least a portion of the plurality of physiological measurements occurring prior to the timestamp that are below a predetermined threshold; and identify that the timestamp for the recovery meal event does not correspond to a timestamp of any of one or more additional meal events stored in a memory operatively coupled with the processor; generate output with an output device to alert the user about the recovery meal event; and store a record of the recovery meal event in the memory in response to receiving a confirmation via an input device coupled with the processor.

[0065] 6. A computer program product comprising program instructions configured to operate a processor to: receive a plurality of physiological measurements from an analyte sensor, the plurality of physiological measurements received as a time series of physiological measurements from an analyte sensor coupled with a user; identify a recovery meal event corresponding to a meal ingested by the user, the processor further configured to: generate a timestamp for the recovery meal event based on a change in the plurality of physiological measurements corresponding to a time of the meal; identify at least a portion of the plurality of physiological measurements that occurred prior to the timestamp that are below a predetermined threshold; and identify that the timestamp for the recovery meal event does not correspond to a timestamp of any of one or more additional meal events stored in a memory operatively coupled with the processor; generate an output with an output device to alert the user about the recovery meal event; and store a record of the recovery meal event in the memory in response to receiving a confirmation via an input device coupled with the processor.

Claims

1. A method for calculating drug injection, comprising: The processor receives multiple physiological measurements from the analyte sensor, the multiple physiological measurements being received as time-series physiological measurements from the analyte sensor connected to the user; The processor identifies missed meal events corresponding to meals consumed by the user, the identifier further including: A timestamp for the missed meal event is generated based on changes in the multiple physiological measurements corresponding to the time of the meal. The elevation level of the physiological measurement exceeding a predetermined threshold after the timestamp is identified; and The timestamp indicating the missed meal event does not correspond to the timestamp of any of one or more other meal events stored in memory operatively connected to the processor; The processor calculates a suggested push to be applied in response to the missed meal event, the suggested push being calculated at least in part based on the length of time elapsed from the timestamp of the missed meal event to the current time; and The output device connected to the processor generates the recommended injection message indicating the drug.

2. The method according to claim 1, further comprising: The output device generates a timestamp notification to the user indicating when the meal event was missed. as well as The processor receives input in response to the prompt, the input further including one of the following: The timestamp of the missed meal event time included in the prompt or confirmation that the meal was ingested at the timestamp received from the user; or Denial, which indicates that no meals were consumed except for at least one meal event.

3. The method of claim 2, wherein the processor cancels the calculation of the suggested push in response to receiving the denial in the input.

4. The method according to any one of claims 1 to 3, wherein the calculation of the proposed annotation further comprises: A time-varying discount factor is applied to the recommended order amount, which reduces the recommended order amount proportionally to the length of time elapsed from the time of the missed meal event to the current time.

5. The method according to any one of claims 1 to 4, wherein the output message further comprises a command transmitted to a drug delivery device to deliver the recommended bolus to the patient.

6. The method according to any one of claims 1 to 5, wherein the drug is insulin.

7. The method according to any one of claims 1 to 6, wherein the analyte sensor is a continuous glucose monitor.

8. A method for identifying unrecorded meals in a diabetes management system, comprising: The processor receives multiple physiological measurements from the analyte sensor, the multiple physiological measurements being received as time-series physiological measurements from the analyte sensor connected to the user; The processor identifies unrecorded meal events corresponding to meals consumed by the user, the identification further including: A timestamp for the unrecorded meal event is generated based on changes in the multiple physiological measurements corresponding to the time of the meal. A decrease in any of the plurality of physiological measurements corresponding to the physiological response to the administration of the drug bolus, occurring after the timestamp, is identified; and The timestamp for the unrecorded meal event is not identified as corresponding to the timestamp of any of one or more other meal events stored in a memory operatively connected to the processor; The output device connected to the processor generates output to send an alert to the user regarding the unrecorded meal event; and The processor stores the record of the unrecorded meal event in memory in response to receiving an acknowledgment via an input device connected to the processor.

9. The method of claim 8, further comprising: The processor applies filtering criteria to identified unrecorded meal events; as well as An output alarm is generated only when the applied filtering criteria are met, at the time the unrecorded meal event is identified.

10. The method of claim 9, wherein in response to the identification that the unrecorded meal event occurred during a predetermined sleep period of the user, the processor identifies that the filtering criteria are not met and cancels the generation of the output alarm.

11. The method according to any one of claims 8 to 10, wherein the plurality of physiological measurements from the analyte sensor are plurality of glucose measurements from a continuous glucose monitor.

12. The method according to any one of claims 8 to 11, wherein the drug is insulin.

13. A method for detecting restorative meal events in a diabetes management system, comprising: The processor receives multiple physiological measurements from the analyte sensor, the multiple physiological measurements being received as time-series physiological measurements from the analyte sensor connected to the user; The processor identifies restorative meal events corresponding to meals consumed by the user, the identifier further including: A timestamp for the restorative meal event is generated based on changes in the multiple physiological measurements corresponding to the time of the meal. Identify at least a portion of the multiple physiological measurements that occurred before the timestamp and were below a predetermined threshold; and The timestamp identifying the restorative meal event does not correspond to the timestamp of any of one or more other meal events stored in memory operatively connected to the processor; The output device connected to the processor generates output to alert the user regarding the restorative meal event; and The processor stores a record of the restorative meal event in memory in response to receiving an acknowledgment via an input device connected to the processor.

14. The method of claim 13, further comprising: The processor receives input data corresponding to at least one of the type of food ingested, the amount of food ingested, or the type of medication administered during the restorative meal event in response to an output alarm. as well as The processor stores the input data in the memory in association with the record of the restorative meal.

15. The method according to any one of claims 13 to 14, wherein the plurality of physiological measurements from the analyte sensor are plurality of glucose measurements from a continuous glucose monitor.

Images