A system and method for ensuring sufficient bolus administration for dietary compensation.

Abstract

Systems and methods are disclosed for providing safeguards to prevent or compensate for insufficient delivery of a bolus dose of a liquid medication in an automated medication delivery system. Safeguards include, for example, functionality built into the medication delivery algorithm to ensure that the medication delivery algorithm delivers an appropriate bolus dose, either manually by a user or automatically by the medication delivery system. Additionally, various methods are described for providing the medication delivery algorithm with a means to determine when a meal has been ingested, and in some embodiments providing an automatic bolus dose of a liquid medication in response to the determination.

Description

[Technical Field] 【0001】 Related applications This application claims the interests of U.S. Provisional Patent Application No. 63 / 300,460, filed on 18 January 2022, the contents of which are incorporated herein by reference in their entirety. [Background technology] 【0002】 Many conventional automated drug delivery systems are well known, including, for example, the type of wearable drug delivery device shown in Figure 2. The drug delivery device 102 can be designed to deliver any type of liquid drug to a user. In certain embodiments, the drug delivery device 102 may be, for example, the OmniPod® drug delivery device manufactured by Insulet Corporation in Acton, Massachusetts. The drug delivery device 102 may be a drug delivery device as described in U.S. Patents 7,303,549, 7,137,964, and 6,740,059, the contents of which are incorporated herein by reference in their entirety. 【0003】 The wearable drug delivery device 102 is typically configured to include a processor and memory and can execute a medication delivery algorithm (MDA). Alternatively, the drug delivery application may be performed on or via a remote device, such as a remote personal diabetes manager (PDM) or a smartphone, which may be configured to transmit drug delivery instructions to the wearable drug delivery device 102. 【0004】 MDA can provide a basal dose of liquid medication. For example, in the case of diabetic patients, MDA can deliver a basal dose of insulin or a co-formulation of insulin and other drugs to the user, while also allowing the user to self-administer a bolus dose of liquid medication to compensate for postprandial fluctuations in the user's blood glucose level. 【0005】 The standard procedure for users to self-administer a meal bolus is to use a bolus calculator to calculate the appropriate bolus dose to supplement the ingested meal. The user inputs a predetermined number of carbohydrates in the meal to use the bolus calculator, and the bolus dose is calculated based on the user's insulin-to-carbohydrate ratio. Typically, the bolus dose is calculated by dividing the grams of carbohydrates in the meal by the insulin-to-carbohydrate ratio. 【number】 【0006】 However, this method is prone to errors because users often misestimate the amount of carbohydrates in their meals. Furthermore, the insulin-to-carbohydrate ratio can fluctuate throughout the day due to factors such as recent exercise activity, stress levels, and hormonal changes. Excessive or insufficient insulin levels can lead to dangerous situations. 【0007】 Furthermore, experienced users may find the use of automated insulin delivery (AID) systems easier and may become complacent in self-administering bolus doses of liquid medication by inadvertently reducing the number of bolus doses required for meals. This could lead to an increase in cases where meals are not adequately supplemented manually by bolus doses. Additionally, meal bolus doses may be delayed, or bolus doses may be taken in anticipation of a meal, but the meal may be delayed. 【0008】 Given the many uncertainties surrounding self-administration of bolus doses, it is desirable to provide users with some degree of safety by incorporating several safeguards into the MDA that compensate for or at least warn users of abnormal situations that may arise due to the inherent drawbacks of self-administration of bolus doses. 【0009】 definition In this specification, the term “liquid drug” should be interpreted to include any liquid drug that can be administered by a drug delivery device via a subcutaneous cannula, such as insulin, GLP-1, pramulintide, morphine, antihypertensive drugs, chemotherapy drugs, fertility drugs, or two or more co-formulations of GLP-1, pramulintide, and insulin. [Overview of the Initiative] [Means for solving the problem] 【0010】 This summary is provided to provide a simplified overview of concepts extracted from the detailed explanation described later. This summary is not intended to identify any important or essential features of the claimed subject matter, nor is it intended to assist in determining the scope of the claimed subject matter. 【0011】 In the first embodiment, the MDA can be configured to provide a safeguard against an insufficient delivery of a bolus dose of a liquid drug or to compensate for an insufficient delivery of a bolus dose of a liquid drug. In a first aspect, various innovative features can be incorporated into the MDA to provide a safe calculation of a bolus dose automatically administered by a drug delivery device. The innovative features will be described in more detail below. In a second aspect of the invention, the MDA can evaluate a past glucose history to automatically determine whether the user has consumed a meal that was not manually compensated for or was undercompensated. If the user is determined to have consumed a meal, in a third aspect of the invention, the MDA can provide measurement criteria to the user and increase the aggressiveness of the MDA against high glucose concentrations during these periods. In a fourth aspect of the invention, when the MDA determines that a meal has been consumed, a bolus dose of insulin can be automatically delivered by the drug delivery device 102. 【0012】 In various embodiments, the drug delivery algorithm can provide all or any combination of the above-described aspects of the invention. 【0013】 In the drawings, like reference characters generally refer to the same part throughout different figures. In the following description, various embodiments of the invention are described with reference to the accompanying drawings. 【Brief Description of the Drawings】 【0014】 [Figure 1] FIG. 1 is a functional block diagram of an exemplary system suitable for implementing the systems and methods disclosed herein. 【0015】 [Figure 2] FIG. 2 is a diagram of a prior art wearable drug delivery device of the type in which the invention disclosed herein is used. 【0016】 [Figure 3]FIG. 3 is a diagram of an exemplary user interface screen showing a "Going to Eat" button used to inform the system software that the user is about to consume a meal. 【0017】 [Figure 4] FIG. 4 is a histogram showing the insulin delivered for each meal as a percentage of the user's TDI. 【0018】 [Figure 5] FIG. 5 is a diagram of an exemplary user interface screen showing a "Set Nighttime Mode" button and fields for entering the start and end times of the nighttime mode. 【0019】 [Figure 6] FIG. 6 is a flowchart showing how the nighttime coefficient is adjusted based on the previous insulin administration. 【0020】 [Figure 7] FIG. 7 is a plot of blood glucose measurements overlaid with a sliding window used to detect meals. 【0021】 [Figure 8] FIG. 8 is a plot of the daily blood glucose measurements showing the increase in glucose levels when a meal is consumed and the portion of the plot used for meal detection 【0022】 [Figure 9] FIG. 9 is a schematic diagram of a machine learning pipeline. 【0023】 [Figure 10] FIG. 10 is a diagram showing the supervised training process for a 10-minute meal detector, a 15-minute meal detector, and a 20-minute meal detector. 【0024】 [Figure 11] Figure 11 is a flowchart showing the pooling of results from 10-minute, 15-minute, and 20-minute meal detectors to provide robust meal detection results. 【0025】 [Figure 12] Figure 12 is a flowchart showing the process of administering an automated insulin bolus. [Modes for carrying out the invention] 【0026】 Detailed explanation This disclosure presents various systems, components, and methods for providing safeguards against insufficient bolus administration when a user is self-administering a bolus dose. Embodiments described herein offer one or more advantages over prior art systems, components, and methods, namely, providing a safety net to the user in the event of insufficient self-administration of a bolus dose by incorporating safeguards into the drug delivery algorithm. 【0027】 Various embodiments of the present invention include systems and methods for delivering a drug to a user autonomously or in accordance with radio signals received from an electronic device, using a drug delivery device (which may be referred to herein as a “pod”). In various embodiments, the electronic device may be a smartphone, a smartwatch, a smart necklace, a module attached to a drug delivery device, or a user device including any other type or kind of electronic device that can be carried by the user or worn on the user’s body and runs an algorithm for calculating the time and dosage of drug delivery. 【0028】 For example, a user device can run an "artificial pancreas" algorithm to calculate the timing and dosage of insulin delivery. The user device can also communicate with sensors, such as glucose sensors, to collect data about the user's physical attributes or state, including glucose levels. These sensors may be located inside or on the user's body and may be part of a drug delivery device or a separate device. 【0029】 Alternatively, the drug delivery device may communicate with the sensor in lieu of, or in addition to, communication between the sensor and the user device. Communication may be direct (e.g., if the sensor is integrated with the drug delivery device or is otherwise part of the drug delivery device) or remote / wireless (e.g., if the sensor is located in a separate housing from the drug delivery device). In these embodiments, the drug delivery device includes computing hardware (e.g., a processor, memory, firmware, etc.) that executes some or all of the algorithms for calculating the time and dosage of drug delivery. 【0030】 Figure 1 is a functional block diagram of an exemplary drug delivery system 100 suitable for carrying out the systems and methods described herein. The drug delivery system 100 can implement (and / or provide functionality for) drug delivery algorithms such as artificial pancreas (AP) applications and govern or control the automated delivery of drugs or medications, such as insulin, to a user (e.g., maintaining normal blood glucose levels, which are normal levels of blood glucose). The drug delivery system 100 may also be an automated drug delivery system including a drug delivery device 102 (which may be wearable), an analyte sensor 108 (which may also be wearable), and a user device 105. 【0031】 In an optional example, the drug delivery system 100 may also include an accessory device 106, such as a smartwatch or a personal assistant device, which can communicate with other components of the system 100 via either wired or wireless links 191-193. 【0032】 User devices The user device 105 may be a computing device such as a smartphone, tablet, personal diabetes management (PDM) device, or dedicated diabetes treatment management device. In one example, the user device 105 may include a processor 151, device memory 153, user interface 158, and communication interface 154. The user device 105 may also include analog and / or digital circuits that can be implemented as the processor 151 for executing processing based on programming code stored in the device memory 153, such as a user application 160 for managing the user's blood glucose levels and controlling the delivery of drugs, medications, or therapeutic agents to the user, and for providing other functions such as calculating carbohydrate-corrected doses and corrected bolus doses. The user device 105 can be used to program, configure, and / or control the operation of the drug delivery device 102 and / or analyte sensor 108 and optional smart accessory devices 106. 【0033】 The processor 151 may also be configured to execute programming code stored in the device memory 153, such as a user application 160. The user application 160 may be a computer application capable of operating to deliver medication based on information received from the analyte sensor 108, a cloud-based service 111, and / or the user device 105 or an optional accessory device 106. The memory 153 may also store programming code for operating, for example, a user interface 158 (e.g., a touchscreen device, a camera, etc.), a communication interface 154, or similar. When the processor 151 executes the user application 160, it may be configured to provide displays and notifications related to meal intake, blood glucose measurement, etc. The user interface 158 is under the control of the processor 151 and may be configured to present a graphical user interface that allows input of meal notifications, adjustment of setting selections, etc., as described herein. 【0034】 In a specific example, when the user application 160 is an AP application, the processor 151 is also configured to execute a diabetes treatment plan (which may be stored in memory) managed by the user application 160. In addition to the functions described above, when the user application 160 is an AP application, it can further provide the function of determining the carbohydrate compensation dose, the corrected bolus dose, and the basal dose according to the diabetes treatment plan. Furthermore, as an AP application, the user application 160 provides the function of outputting signals to the drug delivery device 102 via the communication interface 154 in order to deliver the determined bolus dose and basal dose. 【0035】 The communication interface 154 may include one or more transceivers operating according to one or more radio frequency protocols. In one embodiment, the transceivers may consist of a cellular transceiver and a Bluetooth® transceiver. The communication interface 154 may be configured to receive and transmit signals containing information usable by the user application 160. 【0036】 The user device 105 may further include one or more output devices 155, such as a speaker or a vibration transducer, to provide the user with various signals. 【0037】 Drug delivery devices In various exemplary embodiments, the drug delivery device 102 may include a reservoir 124 and a drive mechanism 125, controllable by a controller 121 that runs a drug delivery algorithm (MDA) 129 stored in a memory 123 mounted on the drug delivery device (and, in exemplary embodiments, a wearable drug delivery device). Alternatively, the controller 121 may operate to control the reservoir 124 and the drive mechanism 125 based on signals received from a user application 160 that communicates with the drug delivery device 102 via a communication link 194 and runs on a user device 105. The drive mechanism 125 operates to longitudinally translate a plunger through the reservoir to push a liquid drug through an outlet fluid port into a needle / cannula 186. 【0038】 In another embodiment, the drug delivery device 102 may also include an optional second reservoir 124-2 and a second drive mechanism 125-2, enabling independent delivery of two different liquid drugs. For example, reservoir 124 may be filled with insulin and reservoir 124-2 may be filled with plumlintide or GLP-1. In some embodiments, each of reservoirs 124, 124-2 may be configured with separate drive mechanisms 125, 125-2, respectively, which may be independently controllable by controller 121 under the direction of MDA 129. Either reservoir 124, 124-2 may be connected to a common needle / cannula 186. 【0039】 The drug delivery device 102 may optionally be configured to include a user interface 127 that provides means for receiving input from a user and means for outputting information to the user. The user interface 127 may include, for example, a light-emitting diode, a button on the housing of the drug delivery device 102, a sound transducer, a microdisplay, a microphone, an accelerometer for detecting the operation of the device or a user gesture (e.g., tapping the housing of the device), or any other type of interface device configured to allow the user to input information and / or for the drug delivery device 102 to output information to present to the user (e.g., an alarm signal). 【0040】 The drug delivery device 102 includes a patient interface 186 for interface with the user to deliver a liquid drug. The patient interface 186 may be, for example, a needle or cannula for delivering the drug into the user's body (this may be done subcutaneously, intraperitoneally, or intravenously). The drug delivery device 102 may further include a mechanism for inserting the needle / cannula 186 into the user's body, which may be integrated with the drug delivery device 102 or be attachable to the drug delivery device 102. In one embodiment, the insertion mechanism may consist of an actuator that inserts the needle / cannula 186 under the user's skin and then retracts the needle, leaving the cannula in place. 【0041】 In one embodiment, the drug delivery device 102 includes a communication interface 126, which may be a transceiver operating according to one or more radio frequency protocols such as Bluetooth®, Wi-Fi®, a short-range wireless communication standard, or a cellular standard. The controller 121 can communicate with the user device 105 and the analyte sensor 108, for example, via the communication interface 126. 【0042】 In some embodiments, the drug delivery device 102 may include one or more sensors 184. The sensors 184 may include one or more pressure sensors, power sensors, etc., which are communicatively coupled to the controller 121 and provide various signals. For example, a pressure sensor may be configured to provide an indication of the fluid pressure detected in the fluid path between the patient interface 186 and the reservoir 124. The pressure sensor may be coupled to or integrated with the actuator for inserting the patient interface 186 into the user. In one embodiment, the controller 121 may be operable to determine the drug infusion rate based on the fluid pressure indication. The drug infusion rate may be compared to an infusion rate threshold, and the comparison result may be used in determining the amount of residual insulin (insulin onboard, IOB) or the total daily insulin (total daily insulin, TDI). In one embodiment, an analyte sensor 108 may be integrated with the drug delivery device 102. 【0043】 The drug delivery device 102 further includes a power supply 128, such as a battery, piezoelectric device, or energy harvesting device, for supplying power to the controller 121, memory 123, drive mechanism 125, and / or other components of the drug delivery device 102. 【0044】 The drug delivery device 102 may be configured to perform and execute the processes necessary to deliver a drug dose to the user without input from the user device 105 or an optional accessory device 106. As will be described in more detail, the MDA 129 may be operable to determine, for example, the amount of insulin to be delivered, IOB, insulin remaining amount, etc., and to actuate the controller 121 to the drive mechanism 125 to deliver the drug from the reservoir 124. The MDA 129 may take data received from the analyte sensor 108 or the user application 160 as input. 【0045】 Reservoirs 124 and 124-2 can be configured to store drugs, medications, or therapeutic agents suitable for automated delivery, such as insulin, pramulintide, GLP-1, insulin and GLP-1 co-formulations, morphine, blood pressure medications, chemotherapy drugs, and infertility treatments. 【0046】 The drug delivery device 102 may be a wearable device, may be attached to the user's body at the attachment site, and may deliver any therapeutic drug, including any drug or pharmaceutical such as insulin, to the user at or near the attachment site. The surface of the drug delivery device 102 may contain an adhesive to facilitate attachment to the user's skin. 【0047】 When configured to communicate with an external device such as a user device 105 or an analyzer sensor 108, the drug delivery device 102 can receive signals from the user device 105 or analyzer sensor 108 via a wired or wireless link 194. The controller 121 of the drug delivery device 102 can receive and process signals from each external device and deliver drugs to the user according to a diabetes treatment plan or other drug delivery plan. 【0048】 Included devices The optional accessory device 107 may be a wearable smart device such as a smartwatch (e.g., Apple Watch®), smart glasses, smart jewelry, a Global Positioning System-enabled wearable, a wearable fitness device, or smart clothing. Similar to the user device 105, the accessory device 107 may also be configured to perform various functions, including controlling the drug delivery device 102. For example, the accessory device 107 may include a communication interface 174, a processor 171, a user interface 178, and memory 173. The user interface 178 may be a graphical user interface displayed on the touchscreen display of the smart accessory device 107. The memory 173 may store programming code for operating various functions of the smart accessory device 107, as well as instances of the user app 160, or a simplified version of the user app 160 with reduced functionality. In some embodiments, the accessory device 107 may also include various types of sensors. 【0049】 Analytical sample sensor The analyte sensor 108 may include a controller 131, a memory 132, a sensing / measuring device 133, an optional user interface 137, a power / energy harvesting circuit 134, and a communication interface 135. The analyte sensor 108 may be communicatively coupled to the processor 151 of the management device 105 or the controller 121 of the drug delivery device 102. The memory 132 may be configured to store information and programming code 136. 【0050】 The analyte sensor 108 may be configured to detect multiple different analytes such as glucose, lactate, ketones, uric acid, sodium, potassium, and alcohol levels, and to output detection results such as measured values. In exemplary embodiments, the analyte sensor 108 may be a continuous glucose monitor (CGM) configured to measure blood glucose levels at predetermined time intervals, such as every 5 minutes or every minute. The communication interface 135 of the analyte sensor 108 may have a circuit that acts as a transceiver to communicate the measured blood glucose level to the user device 105 via the wireless link 195, or to the drug delivery device 102 via the wireless communication link 108. Although referred to herein as the analyte sensor 108, the sensing / measuring device 133 of the analyte sensor 108 may include one or more additional sensing elements such as a glucose measuring element, a heart rate monitor, or a pressure sensor. The controller 131 may include independent, dedicated logic and / or components, application-specific integrated circuits, a microcontroller or processor that executes software instructions, firmware, programming instructions stored in memory (such as memory 132), or any combination thereof. 【0051】 Similar to the controller 121 of the drug delivery device 102, the controller 131 of the analyte sensor 108 may be operable to perform many functions. For example, the controller 131 may be configured by programming code 136 to manage the collection and analysis of data detected by the sensing and measuring device 133. 【0052】 Although the analyte sensor 108 is depicted separately from the drug delivery device 102 in Figure 1, in various embodiments, the analyte sensor 108 and the drug delivery device 102 may be integrated into the same unit. That is, in various examples, the analyte sensor 108 may be part of the drug delivery device 102, integrated with the drug delivery device 102, and contained within the same housing as the drug delivery device 102, or in a housing that can be attached to the housing of the drug delivery device 102, or otherwise adjacent to it. In such configurations, the controller 121 can independently perform the functions necessary for proper drug delivery without any external input from the user device 105, cloud-based service 111, another sensor (not shown), optional accessory device 106, etc. 【0053】 Cloud-based services The drug delivery system 100 can communicate with or receive services from a cloud-based service 111. Services provided by the cloud-based service 111 may include data storage for personal or anonymized data, such as blood glucose measurements, past IOB or TDI, previous carbohydrate compensation doses, and other forms of data. Furthermore, the cloud-based service 111 may process anonymized data from multiple users to provide generalized information related to TDI, insulin sensitivity, IOB, etc. The communication link 115 connecting the cloud-based service 111 to each device 102, 105, 106, 108 of the system 100 may be a cellular link, a Wi-Fi® link, a Bluetooth® link, or a combination thereof. 【0054】 Communication link Wireless communication links 115 and 191-196 may be any type of wireless link operating using a known or proprietary wireless communication standard. For example, wireless communication links 191-196 may provide communication links based on Bluetooth®, Zigbee®, Wi-Fi®, short-range wireless communication standards, cellular standards, or any other wireless protocol via their respective communication interfaces 126, 135, 154, and 174. 【0055】 Example of operation In the example, user application 160 implements a graphical user interface, which is the primary interface with the user, and is used for starting and stopping the drug delivery device 102, programming the base and bolus computer settings for manual mode, and programming settings specific to automatic mode (hybrid closed-loop or closed-loop). 【0056】 The user app 160 provides a graphical user interface 158 that uses large text, graphics, and on-screen instructions to guide the user through the setup process and use the system 100. It is also used to program a basal insulin delivery profile tailored to the user, check the status of the drug delivery device 102, initiate insulin bolus administration, make changes to the patient's insulin delivery profile, handle system warnings and alarms, and allow the user to switch between automatic and manual modes. 【0057】 The user app 160 can be configured to operate in manual mode, delivering insulin at programmed basal rates and bolus volumes, with the option to set basal or temporary basal profiles for different times of day. The controller 121 also has the ability to function as a sensor-equipped pump in manual mode, using sensor glucose data provided by the analyte sensor 108 for input into a bolus calculator. 【0058】 The user app 160 may be configured to operate in an automated mode that assists in the use of multiple target blood glucose levels. For example, in one embodiment, the target blood glucose level may be in the range of 110–150 mg / dL, and its increments may be 10 mg / dL, 5 mg / dL, or other increments, but preferably 10 mg / dL. The user experience reflects the current setup flow, where the healthcare provider assists the user in programming the basal rate, glucose target value, and bolus calculator settings. These are then communicated to the user app 160 as insulin administration parameters. The insulin administration parameters are adapted over time based on the total daily insulin (TDI) delivered during each use of the drug delivery device 102. A temporary hypoglycemia protection mode may be implemented by the user for various periods of time in automated mode. In hypoglycemia protection mode, the algorithm reduces insulin delivery and is intended for use over temporary periods when insulin sensitivity is expected to be higher, such as during exercise. 【0059】 User app 160 (or MDA 129) can provide periodic insulin microboluses based on past glucose measurements and / or predicted glucose over a predicted interval (e.g., 60 minutes). Optimal postprandial control may require the user to administer meal boluses in the same manner as their current pump therapy, but the normal operation of user app 160 compensates for any missed meal boluses and mitigates persistent hyperglycemia. User app 160 uses a control strategy aimed at achieving and maintaining set target glucose levels, thereby reducing the duration of persistent hyperglycemia and hypoglycemia. 【0060】 In some embodiments, the user device 105 and the analyte sensor 108 do not need to communicate directly with each other. Instead, data from the analyte sensor (e.g., blood glucose measurement) may be communicated to the drug delivery device 102 via link 196 and then transmitted to the user device 105 via link 194. In some embodiments, the serial number of the analyte sensor must be entered into the user application 160 to enable communication between the analyte sensor 108 and the user device 105. 【0061】 User app 160 can provide the ability to calculate a suggested bolus dose through the use of a bolus calculator. The bolus calculator is provided for the user's convenience to assist in determining a suggested bolus dose based on ingested carbohydrates, recent blood glucose readings (or blood glucose readings when using a fingerstick), a programmable correction factor, insulin-to-carbohydrate ratio, target glucose value, and residual insulin (IOB). IOB is estimated by user app 160 considering insulin delivered by any manual bolus and algorithm, and IOB may be divided into basal IOB and bolus IOB, where basal IOB considers insulin delivered by algorithm and bolus IOB considers any bolus delivery. 【0062】 Description of the Embodiment The main embodiments of the present invention are directed toward improvements implemented in an automated drug delivery system 100, an example of which is shown in Figure 1. These improvements are intended to make it easier for the user to maintain safe blood glucose levels. In one embodiment, the improvement eliminates the need for the user to calculate and administer a bolus dose by providing the user with a safe bolus dose upon notification of a meal event, and then providing any further necessary doses of liquid drug according to MDA 129. In another embodiment, the drug delivery system 100 automatically maintains an acceptable glucose level even if the user does not self-administer a bolus dose of insulin before or after a meal. 【0063】 Improvements may be implemented, for example, by modifying software (i.e., user application 160 or MDA 129) that runs as part of the drug delivery system 100. In certain embodiments, certain functions may be implemented in user application 160 running on user device 105, and other functions may be implemented in MDA 129 running on drug delivery device 102. Since various functions may be shared between user application 160 and MDA 129, user application 160 and MDA 129 are collectively referred to as “system software” in this specification. 【0064】 In one embodiment, the user is provided with a user-selectable "Going to Eat" button 302, as shown in Figure 3, which, when selected by the user, indicates a meal event to the system software (i.e., indicates that the user intends to eat). In certain embodiments, upon receiving notification of a meal event, the MDA 129 can replace the bolus calculator, eliminating the need for the user to input the carbohydrate profile of the intended meal. In a preferred embodiment of the present invention, the button 302 may be displayed on the user interface 158 of the user device 105, or in an alternative embodiment, on the user interface 178 of the accessory device 106. In other embodiments, if the drug delivery device 102 includes a user interface 127, the user can notify the system software of a meal event by providing direct input to the drug delivery device 102 via the user interface 127 (however, in this example, the graphic representation of the button 302 is not displayed). When the user selects the “Eat” button 302 (or when the drug delivery device 102 is provided with instructions for a meal event), a safe bolus insulin dose is calculated and delivered to the user. The calculation of the safe bolus takes into account the user's current blood glucose level, residual insulin (IOB), the user's glucose trend over a given past period (30 minutes in a preferred embodiment), and whether night mode is enabled. Each of these considerations is described later in this specification. 【0065】 The analysis of insulin delivered before meals is illustrated in the histogram shown in Figure 4. The histogram shows the density of delivered insulin as a percentage of the total daily insulin intake (TDI) for a typical user. A safe nominal insulin dose, which can be adjusted by various considerations to determine a safe bolus dose, can be expressed as a percentage of the user's total daily insulin intake (TDI) as follows: 【number】 Here, x is the desired percentage, and TDI is the user's total daily insulin dose. In one embodiment, x can be set to, for example, 8%, but other percentages can be selected on a user-by-user basis. For example, x may be set to a percentage between 5% and 15% (including the endpoints). 【0066】 In another embodiment of the present invention, a safe corrected dose of insulin (IOB safe requirement) may be calculated based on the user's current blood glucose level, high glucose threshold, and a correction factor (for example, based on the 1600 rule, which estimates the reduction in blood glucose level per unit of insulin by dividing the factor 1600 by the TDI, as shown in Equation 2 below). In some embodiments, the safe corrected dose may be expressed as follows: 【number】 Here, BG current This is the user's current blood glucose measurement, and T Elevated This is a high threshold. 【0067】 In one embodiment, T Elevated Any value can be used for this, but for example, T ElevatedIt may be set to 150 mg / dl. The high threshold is used to determine a safe bolus dose in combination with a safe nominal insulin dose and IOB. There are two purposes for a safe correction dose. First, it is to make the insulin requirement safe, and second, it is to provide some flexibility for the delay in food intake after the user indicates the intention to consume food by selecting the "Have a meal" button 302. 【0068】 If data from the CGM is missing, the minimum CGM value for the past 30 minutes can be used as BG current When there is no valid CGM data for the past 30 minutes, the IOB safety requirement can be calculated as follows. 【Equation】 Here,[[]]END]] T Low is the low threshold. 【0069】 Any value may be used for the low threshold, but the value of T Low may be set to 100 mg / dl, 70 mg / dl or 40 mg / dl in certain embodiments. Since the low threshold is always lower than the high threshold, using the low threshold will make the IOB safety requirement negative and reduce the total insulin. 【0070】 In some embodiments, the safe bolus dose calculated and delivered after the user presses the "Have a meal" button 302 may be further adjusted by a trend correction factor (CF T ) that depends on the trend of the user's blood glucose measurement values for a predetermined time period before selecting the button 302. In certain embodiments, the predetermined time period can be, for example, 30 minutes. In a preferred embodiment of the present invention, blood glucose measurement values are received regularly from the CGM every 5 minutes, but in other embodiments, other periods may be used. In an embodiment where CGM measurements are received at 5-minute intervals, seven blood glucose measurement values starting from the current blood glucose measurement value BG i can be obtained for the previous 30-minute time period. 【0071】 Trends can be detected by calculating the coarse slope and coarse curvature of blood glucose measurements over time. In one embodiment, the trend may be calculated by first averaging the range of blood glucose measurements over 15-minute blocks as follows: 【number】 【number】 【number】 【number】 【0072】 Subsequently, the coarse slope and coarse curvature are defined as follows: 【number】 【number】 【0073】 In a specific embodiment, the trend correction coefficient CF T This can be determined using a rule set. Any rule set can be used, but in exemplary embodiments, the rule set is CF T This can be determined as follows: 【number】 【number】 【number】 【0074】 If one or more CGM values ​​are missing or unavailable during a given historical period, data quality metrics may be used to determine whether sufficient CGM data is available to perform trend analysis. Such metrics may, for example, be that no more than x% (e.g., 30%) of data points are missing in the last 30 minutes. If the data quality is unacceptable, trend correction is not performed and CF is not applied. T It is set to 1. 【0075】 If the user has experienced a hypoglycemic event immediately prior to a bolus dose triggered by a meal event notification (e.g., hypoglycemia within 1 hour or within the threshold time limit), the rebound factor from hypoglycemia (HF) will be reduced to decrease the safe bolus dose. Rebound ) can be applied. The hypoglycemic rebound coefficient can be specified as follows: 【number】 Here, In some embodiments, z = 0.75, and in other embodiments, it is a different constant. 【0076】 In some embodiments, a nighttime mode setting may be provided. If the nighttime mode setting is enabled, the safe bolus dose is further reduced to further reduce the risk of hypoglycemia. In one embodiment, the user is provided with a nighttime mode user interface screen 500, as shown in Figure 5. This screen includes a user-selectable "Set Nighttime Mode" button 502, which, when selected by the user, indicates to the system software that nighttime mode is enabled. The user can set a start time 504 and an end time 506 to indicate when nighttime mode will be implemented. 【0077】 In an alternative embodiment, night mode can be automatically enabled by using an inertial measurement unit (IMU) sensor on the pump. The IMU comprises one or more of an accelerometer, a gyroscope, and often a magnetometer. Together, these sensors can determine the movement, orientation (or tilt) of the device along one or more of the x, y, and z axes. For sustained activities such as running, swimming, or sleeping, the IMU generates unique profiles of signal activity along each axis. By decoding these signals, unique identifying characteristics that correspond to the activity can be identified. Therefore, if it is determined that the user is sleeping, unique identifying characteristics can be detected along the three axes, and together with time zone information, the user's "night" mode can be determined. 【0078】 In a preferred embodiment of the present invention, the night mode user interface screen 500 may be displayed on the user interface 158 of the user device 105, or in an alternative embodiment, on the user interface 178 of the accessory device 106. In another embodiment, if the drug delivery device 102 is equipped with a user interface 127, the user can directly initiate night mode on the drug delivery device 102 via the user interface 127 (however, in this example, the night mode user interface screen 500 is not displayed). 【0079】 When night mode is enabled and the "Eat" button 302 is pressed, the nighttime factor (NF) may be set to vary, for example, between 0.6 and 0.9. In some embodiments, a value of 0.75 can be set as the default. If the current value has previously caused an increased risk of hypoglycemia, the value can be decreased. Conversely, if blood glucose levels have been high in the past, the current value can be increased. 【0080】 The flowchart shown in Figure 6 can be used to determine adjustments to NF based on measurements of the user's blood glucose level over the past 3 hours, after a safe bolus dose has been delivered. Starting with the current NF, a safe bolus dose is delivered, and blood glucose is monitored for a predetermined time period, e.g., 3 hours. If blood glucose rises, the current NF is increased, e.g., by 10%, for the following calculation. Elevated blood glucose may, in some embodiments, be defined as blood glucose exceeding the setpoint by a value greater than 80 mg / dl at 3 hours. Other values, e.g., exceeding the setpoint by 50 mg / dl, 60 mg / dl, 70 mg / dl, 90 mg / dl, or 100 mg / dl at 3 hours, may be used. In other embodiments, other criteria may be used. If blood glucose is not elevated, it is determined whether blood glucose has fallen below a low setpoint. If not, the current NF is not changed. However, if blood glucose has fallen below the setpoint, the NF may be reduced, e.g., by 10%, for the following calculation. 【0081】 In certain embodiments, any combination of the propensity coefficient, hypoglycemia rebound coefficient, and nighttime coefficient can be applied to the safe bolus dose to modify the amount of liquid drug represented by the safe bolus dose, which is delivered to the user in response to the user selecting button 302. When using all the coefficients described above, the safe bolus insulin dose can be expressed as follows: 【number】 Here, CF T HF Rebound , and NF modify the value of x for safety. In various embodiments, a safe bolus dose may take into account a propensity coefficient, a hypoglycemic rebound coefficient, and a nocturnal coefficient, or any combination thereof (including the absence of all of these coefficients) to calculate the safe bolus dose. 【0082】 IOB is the amount of insulin-on-board (insulin remaining since the previous insulin delivery). If IOB is negative, it is rounded to zero. 【0083】 The safe bolus dose is ideal for closed-loop systems where algorithmic (basal) insulin can be safely increased to compensate for the safe bolus dose, significantly reducing the risk of hypoglycemia in closed-loop systems. After the safe bolus dose is administered upon notification of a meal event, the system software 100 of the drug delivery device compensates for further postprandial fluctuations in the user's blood glucose level according to algorithmic basal insulin delivery embodied by MDA129. 【0084】 As the value of x decreases, insulin may be administered multiple times according to equation (14). For example, if x is set or reduced to 3.5% by applying the various coefficients described earlier, the first bolus insulin delivery may be administered when the user selects the "Eat Meal" button 302, the second bolus 10 minutes later, and the third bolus 20 minutes later. To safely administer insulin, blood glucose trends can be utilized. IOB is safe against excessive insulin administration. 【0085】 Detection of Uncompensated or Undercompensated Meals - This embodiment of the present invention discloses a method for evaluating past glucose history to determine whether the user has had meals that were not manually compensated via self-bolus administration or were undercompensated, and whether the user did not notify the drug delivery system 100 of the meals and events by selecting button 302. In an extension of this embodiment, if uncompensated or undercompensated meals are detected, the system software may provide the user with a metric and increase the aggressiveness of MDA 129 for high glucose concentrations during those periods. 【0086】 A typical unbolus or bolus-deficient meal can result in a significant increase in the user's glucose and a significant increase in automated insulin delivery beyond the basal level. In one embodiment of this aspect of the present invention, the system software can review a 5-hour window with 5-minute moving increments over each 24-hour period, as follows: 【number】 【number】 Here, W post This is the total amount of insulin administered during the most recent 5-hour window; G post This is the average of glucose measurements over the most recent 5-hour window; I alg This is the insulin recommended by the drug delivery algorithm; 228 is the number of 5-hour windows in a day; 60 is the number of 5-minute cycles in 5 hours. 【0087】 As those skilled in the art will understand, the constants in the above equation are adjustable parameters. Different constants will be used depending on the periodic interval used to evaluate the equation or the window size. 【0088】 If W post and G post If certain criteria are met, all data points for that specific period can be considered to satisfy the definition of detecting an unreported meal. In one embodiment, these criteria may be, for example, as follows: True / False 【number】 【0089】 Here, the threshold is at least twice the user's TDI-based basal amount delivered over the most recent 5-hour window, and the user's average glucose over the most recent 5-hour window is greater than 180. It is important to note that all specific numerical values ​​introduced in this embodiment are variable parameters. For example, the increments and total duration of the moving window can vary, such as reviewing a 6-hour window every 30-minute increment, or a 3-hour window every 15-minute increment, or reviewing at other values. Furthermore, the threshold for the selection criterion can also vary. For example, the threshold for total increased automated insulin delivery can be 1.5 times, 3 times, or 4 times the basal delivery. Also, the final glucose concentration can vary as a different value, such as 150 mg / dL, 250 mg / dL, the user's final glucose target value, or other values. 【0090】 The user's average glucose concentration during each transition window can also be included as a condition, either as an addition to or as a replacement for the termination glucose condition, along with the relevant detection threshold. For example, the condition could be that the average glucose during the transition window is greater than 150 mg / dL. 【0091】 The system can instead provide a probabilistic calculation of meal occurrences based on the degree to which each condition is exceeded, rather than a binary detection of meals during this period. For example, the system might provide a 50% probability of an unannounced meal or a bolus-deficient meal occurring if automated insulin delivery exceeds 1.5 times the basal dose over a 5-hour window, and this probability could rise to 100% if delivery exceeds 3 times the basal dose during the same period. Each condition can provide a probability of meal delivery, and the final determination of the meal occurrence probability can be calculated as the average, sum, or other combination of the evaluation of meal probabilities across all conditions. 【0092】 For each period in which an unreported meal is detected, the system can inform the user that the system has detected that the user has eaten an unreported meal. Furthermore, the system software can provide a recommended insulin dose based on the user's final glucose level at the end of the period, which would have improved the user's glucose control outcome if the user had self-administered that amount of bolus. 【number】 【0093】 Furthermore, the system software can respond more aggressively to glucose deviations during the first 90 minutes of this period by reducing the Q:R ratio (relative cost of insulin deviation versus glucose deviation) during this period, based on the additional insulin required, as follows: 【number】 【0094】 In another aspect of the present invention, meal detection can be performed using a machine learning approach. In this embodiment, meals can be detected based on a machine learning model that detects characteristic elevation profiles of blood glucose levels. The meal detection model is preferably trained on a closed-loop control dataset. Blood glucose profiles from closed-loop data with predetermined elevation characteristics are labeled to be used as training data. In one embodiment, the elevation characteristics may be, for example, 20 ml / dl within 15 minutes, 40 ml / dl within 30 minutes, and 60 ml / dl within 60 minutes. 【0095】 In one embodiment, blood glucose data for the two hours preceding the first rise in blood glucose level (10 minutes, 15 minutes, and 20 minutes after the first rise in blood glucose level) is used to train a decision tree for detecting meals. 【0096】 Figure 7 shows a sliding window over the blood glucose level plot used for meal detection. In this example, meals are detected as the window indexes over time, reaching BG points 23, 24, 25, and beyond. Figure 8 shows the relationship between blood glucose elevation and meal detection, illustrating the pattern for a day with three meals. 【0097】 To detect meals, specific features are detected from blood glucose data. In one embodiment, a two-hour history of blood glucose data is maintained. In this embodiment, blood glucose is sampled every five minutes, yielding 25 data points. In embodiments where different history periods or different intervals for sampling blood glucose levels are used, different numbers of data points become available for analysis. In one embodiment of the present invention, the following features may be detected: 15-minute mean (average blood glucose level every 15 minutes over the most recent two-hour history); range feature (difference in blood glucose levels every 15 minutes); delta value (difference in 15-minute mean values, providing a rough slope for the blood glucose plot); slope value (difference between consecutive values ​​of the slope for the blood glucose plot); and second derivative (difference in the slope for the blood glucose plot). Other features may be used in other embodiments of the present invention. 【0098】 In the training phase, blood glucose data with rising characteristics, such as 20 ml / dl within 15 minutes, 40 ml / dl within 30 minutes, and 60 ml / dl within 60 minutes, are identified. The identified data is presented to a machine learning model, and meal detection rules are developed. To recognize the postprandial rise in glucose levels, the entire rising portion of the blood glucose curve is used, but it should be noted that in one embodiment, only the values ​​at 10, 15, and 20 minutes of the rising blood glucose curve (and the values ​​of a total of 25 data points prior to each of these points) are presented to the machine learning system. The goal is to detect meals with minimal waiting time. 【0099】 The machine learning pipeline is shown in Figure 9, illustrating the data generation for the 10-minute meal detection classifier, the 15-minute meal detection classifier, and the 20-minute meal detection classifier. The BG rise point for meals must be within the low threshold and high threshold. The 10-minute classifier refers to 10 minutes ahead and 110 minutes before to extract 2 hours of data; the 15-minute classifier refers to 15 minutes ahead and 105 minutes before to extract 2 hours of data; and the 20-minute classifier refers to 20 minutes ahead and 100 minutes before to extract 2 hours of data. Figure 10 shows the supervised training of the 10-minute meal classifier, the 15-minute meal classifier, and the 20-minute meal classifier. 【0100】 In certain embodiments, decision trees can be used to detect meals. In one embodiment, meals are detected using three different delay periods. These are 10-minute delay detectors, 15-minute delay detectors, and 20-minute delay detectors. The 10-minute, 15-minute, and 20-minute delay detectors recognize the rise in blood glucose levels, assuming that the rise in postprandial blood glucose levels began 10 minutes, 15 minutes, and 20 minutes prior to the current time, respectively. The exact rules used in the meal detection decision tree may vary based on different embodiments of the invention. Furthermore, detectors using different time periods can also be developed. 【0101】 To make meal detection more robust, the models may be cascaded and / or combined. When a new blood glucose value is received from CGM108, the 10-minute, 15-minute, and 20-minute meal detectors are activated at 5-minute intervals to detect meals. These results are combined to form a robust meal detection model, an example of which is shown in Figure 11. At 1100, the most recent cycle of MDA129 begins, and at 1102, the most recent blood glucose measurement is received and added to the most recent 2-hour history. The 10-minute delayed meal detector 1104, the 15-minute delayed meal detector 1106, and the 20-minute delayed meal detector 1108 provide the 2-hour history of blood glucose measurements. At 1110, the results from the delayed meal detectors 1104, 1106, and 1108 are pooled, and at 1112, the meal detection result is output. Based on the combination of results from delayed meal detectors 1104, 1106, and 1108, various rules may be implemented by the pool classifier in 1110 to determine whether the meal detection is "true" or "false". 【0102】 For example, if the 10-minute delayed meal detector returns true in the current cycle, it is expected that the 15-minute delayed meal detector will return true in the next cycle (it is also possible that the 10-minute delayed meal detector will return true in this cycle), and the 20-minute delayed meal detector will return true in the cycle after that. For robustness, periods during which these detectors can return true are allowed, and the final meal detection result is synthesized by extracting the results from the 10-minute, 15-minute, and 20-minute detectors, as shown in Figure 11. 【0103】 Automated Bolus Administration - In certain embodiments, when an unbolused or bolus-deficient meal is detected, an automated bolus dose of insulin is injected, regardless of the method used for detection. Figure 12 shows the logic flow for determining whether an automated bolus should be administered. At 1200, the cycle begins. As previously stated, in a preferred embodiment of the invention, each cycle is 5 minutes long, and a new blood glucose measurement is received from the CGM during each 5-minute cycle. In a particular embodiment of the invention, the reception of a new BG measurement triggers the start of the next cycle. At 1202, the most recent blood glucose measurement is received, and at 1204, the meal detector described earlier is run on the most recent blood glucose measurement, including the most recently received measurement. At 1206, if a meal is detected, an automated bolus is administered at 1208 as described above. If no meal is detected, control returns to 1200 and waits for the start of the next cycle. 【0104】 The automated bolus may have a nominal insulin delivery volume. In one embodiment, the automated bolus may be the safe bolus dose described in detail above. In other exemplary embodiments, the required insulin amount is nominally a percentage of the user's TDI (e.g., 8%). This insulin amount is the safe IOB requirement (IOB). SR It is adjusted for correction by the current IOB. The safe IOB requirement indicates the insulin needed to correct blood glucose (however, to improve safety, a higher value such as 150 mg / dl may be used instead of the insulin set value). 【number】 Here, 【number】 Here, CF is a correction factor defined as 1600 / TDI. 【0105】 If a manual bolus is administered before an automated bolus is triggered, the IOB (Insulin Isolation Block) regulates insulin delivery. If the IOB is sufficiently high, the automated bolus can deliver 0 units of insulin. Conversely, if the user is bolus-deficient, an appropriate amount of insulin will be supplied according to the IOB. 【0106】 Automated bolus delivery ensures a safe amount of insulin is delivered for postprandial blood glucose compensation. The core closed-loop control algorithm continuously provides the appropriate amount of basal insulin to maximize the time the user is within range. 【0107】 The following embodiments relate to various embodiments of the systems and methods disclosed herein for providing a method for determining optimal drug delivery by providing a stepwise exploration of a search space for the possible amounts of drug to be delivered to a user. 【0108】 Example 1 is a method according to the first embodiment of the present invention, and includes the steps of receiving notification of a meal event, calculating a safe bolus dose to be delivered to the user, delivering the safe bolus dose, mitigating the user's blood glucose level, and compensating for further fluctuations in the user's blood glucose level by the drug delivery algorithm of the drug delivery system. 【0109】 Example 2 is an extension of Example 1 or any other example disclosed herein, wherein notification of a meal event includes the user selecting a button on the user interface. 【0110】 Example 3 is an extension of Example 1 or other examples disclosed herein, in which the safe bolus dose is calculated as a function of the safe nominal insulin delivery rate and the current residual insulin. 【0111】 Example 4 is an extension of Example 3 or any other example disclosed herein, in which the safe nominal insulin delivery dose is calculated as a percentage of the user's total daily insulin requirement. 【0112】 Example 5 is an extension of Example 4, or any other example disclosed herein, wherein the safe bolus dose is modified by a blood glucose correction factor that takes into account the user's current blood glucose level. 【0113】 Example 6 is an extension of Example 5 or other examples disclosed herein, wherein the safe bolus dose is modified by a trend correction factor that corrects for the trend of the user's blood glucose levels over a predetermined period in the past. 【0114】 Example 7 is an extension of Example 6 or other examples disclosed herein, wherein the trend correction coefficient is based on the slope and curvature of the user's blood glucose levels over a predetermined period in the past. 【0115】 Example 8 is an extension of Example 5, or any other example disclosed herein, wherein the safe bolus dose is modified by a rebound coefficient from hypoglycemia that reduces the safe bolus dose by a predetermined amount if the user experiences a hypoglycemic event within a predetermined period prior to the delivery of the safe bolus dose. 【0116】 Example 9 is an extension of Example 5 or other examples disclosed herein, wherein the safe bolus dose is modified by a night factor that reduces the safe bolus dose by a calculated amount if the bolus dose is administered during the nighttime period. 【0117】 Example 10 is an extension of Example 9 or other examples disclosed herein, wherein if in a past occurrence the current value of the nighttime coefficient has caused an additional risk of hypoglycemia, the current value is lowered, or if in a past occurrence the current value of the nighttime coefficient has caused the user's blood glucose level to rise, the current value is raised. 【0118】 Example 11 is an extension of Example 3 or other examples disclosed herein, and the safe bolus dose can be modified by any combination of the blood glucose correction factor, the trend correction factor, the rebound factor from hypoglycemia, and the nocturnal factor. 【0119】 Example 12 is an extension of Example 1 or any other example disclosed herein, further comprising dividing a safe bolus dose into multiple step doses delivered at predetermined time intervals after notification of a meal event. 【0120】 Example 13 is an extension of Example 12, or any other example disclosed herein, in which a safe bolus dose is recalculated for each stepwise delivery. 【0121】 Example 14 is an extension of Example 1 or other examples disclosed herein, and the meal event notification includes automatically detecting meal intake based on the user's blood glucose level received from a continuous glucose monitor. 【0122】 Example 15 is an extension of Example 14 or other examples disclosed herein, in which the automatic detection of meal intake is based on the detection of a significant increase in the user's blood glucose level in a significant increase in the automatic delivery of liquid drugs calculated by the drug delivery algorithm of the drug delivery system. 【0123】 Example 16 is an extension of Example 15 or other examples disclosed herein, wherein the increase in the user's blood glucose level and the increase in the automatic delivery of liquid medication are evaluated within a predetermined travel window, which is evaluated each time a new blood glucose measurement is received from a continuous glucose monitor. 【0124】 Example 17 is an extension of Example 14 or other examples disclosed herein, in which the automated detection of food intake is based on the analysis of a plot of the user's blood glucose levels by one or more machine learning models trained as food detection classifiers. 【0125】 Example 18 is an extension of Example 17, or another example disclosed herein, in which one or more machine learning models are trained to detect postprandial elevations in the user's blood glucose levels that begin at various times prior to the current time. 【0126】 Example 19 is an extension of Example 18 or other examples disclosed herein, wherein one or more machine learning models include a 10-minute delay detector, a 15-minute delay detector, and a 20-minute delay detector. 【0127】 Example 20 is an extension of Example 17 or other examples disclosed herein, in which one or more machine learning models are cascaded to provide a final decision on dietary intake. 【0128】 Example 21 is an extension of Example 14 or other examples disclosed herein, in which the automated detection of dietary intake is based on the analysis of a plot of the user's blood glucose levels by one or more decision trees. 【0129】 Example 22 is an extension of Example 21 or other examples disclosed herein, in which the decision tree uses multiple delay detectors to recognize an increase in blood glucose levels, using the assumption that the increase in blood glucose levels began at various times prior to the current time. 【0130】 Example 23 is an extension of Example 22 or other examples disclosed herein, wherein the plurality of delay detectors include a 10-minute delay detector, a 15-minute delay detector and a 20-minute delay detector. 【0131】 Example 24 is an extension of Example 22 or other examples disclosed herein, in which the results of multiple delay detectors are pooled and a final food detection determination is synthesized. 【0132】 Example 25 is an extension of Example 14 or any other example disclosed herein, and in response to notification of a meal event, the method further includes notifying the user of the detection of an internally unnotified meal and providing the user with a recommended bolus dose. 【0133】 Example 26 is an extension of Example 25, or any other example disclosed herein, and further includes adjusting the drug delivery algorithm of the drug delivery system to respond more aggressively to glucose deviations based on a recommended bolus dose in response to notification of a meal event. 【0134】 Example 27 is a method according to a second embodiment of the present invention, comprising the steps of: automatically detecting meal intake based on the user's blood glucose level received from a continuous glucose monitor; notifying the user of the detection of an unannounced meal; providing the user with a recommended bolus dose; and adjusting the drug delivery algorithm of the drug delivery system to respond more aggressively to glucose deviations based on the recommended bolus dose. 【0135】 Example 28 is a system of a third embodiment, comprising a processor and software that runs on the processor and provides functions for receiving notifications of meal events, calculating a safe bolus dose to be delivered to the user, delivering the safe bolus dose, monitoring the user's blood glucose level, and compensating for further fluctuations in the user's blood glucose level according to the drug delivery algorithm of the drug delivery system. 【0136】 Example 29 is an extension of Example 28 or any other example disclosed herein, wherein notification of a meal event includes the user selecting a button on the user interface of the drug delivery system. 【0137】 Example 30 is an extension of Example 28 or any other example disclosed herein, further comprising a continuous glucose monitor, wherein meal event notification includes automatically detecting meal intake based on the user's blood glucose level received from the continuous glucose monitor. 【0138】 Software-related implementations of the technologies described herein may include, but are not limited to, firmware, application-specific software, or any other type of computer-readable instruction that can be executed by one or more processors. Computer-readable instructions may be provided via a non-temporary computer-readable medium. Hardware-related implementations of the technologies described herein include, but are not limited to, integrated circuits (ICs), application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), and / or programmable logic devices (PLDs). In some examples, the technologies described herein, and / or any system or component described herein, may be executed using a processor that executes computer-readable instructions stored on one or more memory components. 【0139】 Those skilled in the art in the relevant fields will be able to implement many modifications and adaptations of the invention. The implementations provided herein, including the values ​​of adjustable parameters, should be considered illustrative and not limit the invention in any sense. As those skilled in the art will understand, many variations of the implementations described herein are possible and fall within the scope of the invention. Furthermore, the features of the various embodiments described herein are not mutually exclusive and can exist in various combinations and permutations, even if not explicitly stated herein, without departing from the spirit and scope of the invention. Accordingly, the methods and apparatus disclosed herein should be considered illustrative, not as limitations of the invention. This disclosure also includes the following aspects: [Aspect 1] A method for compensating for dietary intake in a drug delivery system, To receive notifications about meal events; Calculating a safe bolus dose to be delivered to the user; To deliver the aforementioned safe bolus dose; To monitor the user's blood glucose level; A method comprising compensating for further fluctuations in the user's blood glucose level in accordance with the drug delivery algorithm of the drug delivery system. [Aspect 2] The method according to embodiment 1, wherein the notification of a meal event includes user selection of a button on the user interface of the drug delivery system. [Aspect 3] The method according to embodiment 1, wherein the safe bolus dose is calculated as a function of the safe nominal insulin delivery rate and the current residual insulin. [Aspect 4] The method according to embodiment 3, wherein the safe nominal insulin delivery dose is calculated as a percentage of the user's total daily insulin requirement (TDI). [Aspect 5] The safe bolus dose is, A blood glucose correction coefficient that takes into account the user's current blood glucose level; A trend correction coefficient that corrects for the trend in the user's blood glucose levels over a predetermined period in the past; If the user experiences a hypoglycemic event within a predetermined time period prior to the delivery of the safe bolus dose, a rebound coefficient from hypoglycemia is used to reduce the safe bolus dose by a predetermined amount; If the bolus dose is administered during the nighttime period, a nighttime coefficient is used to reduce the safe bolus dose by a calculated amount. The method according to embodiment 4, modified by one or more of the above. [Aspect 6] The method according to embodiment 5, wherein the trend correction coefficient is based on the slope and curvature of the user's blood glucose level over the predetermined past period. [Aspect 7] The method according to aspect 5, wherein night mode is automatically detected using motion profiles and time zone information provided by the IMU. [Aspect 8] The method according to embodiment 5, wherein the current value of the nighttime coefficient is lowered if, in a past occurrence, the current value caused a further risk of hypoglycemia, or raised if, in a past occurrence, the current value caused the user's blood glucose level to rise. [Aspect 9] Delivering the aforementioned safe bolus dose is The method according to embodiment 1, further comprising dividing the safe bolus dose into a plurality of stepwise doses to be administered at predetermined intervals following notification of a meal event. [Aspect 10] The method according to embodiment 9, wherein the safe bolus dose is recalculated with each stepwise delivery. [Aspect 11] The method according to embodiment 1, wherein the notification of a meal event includes automatic detection of meal intake based on the user's blood glucose level received from a continuous glucose monitor. [Aspect 12] The method according to embodiment 11, wherein the automatic detection of the intake of the meal is performed based on the detection of a significant increase in the user's blood glucose level and a significant increase in the automatic delivery of liquid drugs calculated by the drug delivery algorithm of the drug delivery system. [Aspect 13] The method according to embodiment 12, wherein the increase in the user's blood glucose level and the increase in the automatic delivery of the liquid drug are evaluated with respect to a predetermined moving window of width, which is evaluated each time a new blood glucose measurement is received from the continuous glucose monitor. [Aspect 14] The method according to aspect 11, wherein the automatic detection of the intake of the meal is based on the analysis of the user's blood glucose level plot by one or more machine learning models trained as meal detection classifiers. [Aspect 15] The method according to aspect 14, wherein the one or more machine learning models are trained to detect postprandial increases in the user's blood glucose levels that begin at various times prior to the present time. [Aspect 16] The method according to embodiment 15, wherein the one or more machine learning models include a 10-minute detector, a 15-minute detector, and a 20-minute detector, and the one or more machine learning models are cascaded to provide a final determination of dietary intake. [Aspect 17] The method according to aspect 11, wherein the automatic detection of the intake of the meal is based on the analysis of a plot of the user's blood glucose levels by one or more decision trees using multiple delayed detectors that recognize that the blood glucose level has risen, assuming that the rise in blood glucose level began at various times prior to the present time. [Aspect 18] The method according to embodiment 17, wherein the results of the multiple delay detectors are pooled to synthesize a final meal detection decision. [Aspect 19] In response to the notification of the aforementioned meal event, the method is: To notify the user that an unreported meal has been detected; The method according to embodiment 1, further comprising providing the user with a recommended bolus dose. [Aspect 20] In response to the notification of the aforementioned meal event, the method is: The method according to embodiment 1, further comprising adjusting the drug delivery algorithm of the drug delivery system to respond more aggressively to glucose deviations based on the recommended bolus dose.

Claims

[Claim 1] A drug delivery system, A method for compensating for dietary intake in the drug delivery system, To receive notifications about dining events, Calculating a safe bolus dose to be delivered to the user, To deliver the aforementioned safe bolus dose, To monitor the user's blood glucose level, In accordance with the drug delivery algorithm of the drug delivery system, further fluctuations in the user's blood glucose level are compensated for, Includes a processor configured to perform a method including, The aforementioned safe bolus dose is calculated as a function of the safe nominal insulin delivery rate and the current remaining insulin. The aforementioned safe nominal insulin delivery dose is calculated as a percentage of the user's total daily insulin requirement (TDI). The safe bolus dose is, A blood glucose correction coefficient that takes into account the user's current blood glucose level, A trend correction coefficient that corrects for the trend in the user's blood glucose levels over a predetermined period in the past, If the user experiences a hypoglycemic event within a predetermined time period prior to the delivery of the safe bolus dose, a rebound coefficient from hypoglycemia is used to reduce the safe bolus dose by a predetermined amount. If the bolus dose is administered during the nighttime period, a nighttime coefficient is applied to reduce the safe bolus dose by a calculated amount, A drug delivery system modified by one or more of the following. [Claim 2] The drug delivery system according to claim 1, wherein the notification of a meal event includes user selection of a button on the user interface of the drug delivery system. [Claim 3] The drug delivery system according to claim 1, wherein the trend correction coefficient is based on the slope and curvature of the user's blood glucose level over a predetermined period in the past. [Claim 4] The drug delivery system according to claim 1, wherein night mode is automatically detected using motion profiles and time zone information provided by the IMU. [Claim 5] The drug delivery system according to claim 1, wherein the current value of the night coefficient is lowered if, in a past occurrence, the current value caused a further risk of hypoglycemia, or raised if, in a past occurrence, the current value caused the user's blood glucose level to rise. [Claim 6] Delivering the aforementioned safe bolus dose is The drug delivery system according to claim 1, further comprising dividing the safe bolus dose into a plurality of stepwise doses to be administered at predetermined intervals following notification of a meal event. [Claim 7] The drug delivery system according to claim 6, wherein the safe bolus dose is recalculated at each step of delivery. [Claim 8] A drug delivery system, A method for compensating for dietary intake in the drug delivery system, To receive notifications about dining events, Calculating a safe bolus dose to be delivered to the user, To deliver the aforementioned safe bolus dose, To monitor the user's blood glucose level, In accordance with the drug delivery algorithm of the drug delivery system, further fluctuations in the user's blood glucose level are compensated for, Includes a processor configured to perform a method including, The notification of a meal event includes an automated detection of meal intake based on the user's blood glucose level received from a continuous glucose monitor, as part of a drug delivery system. [Claim 9] The drug delivery system according to claim 8, wherein the automatic detection of the intake of the meal is performed based on the detection of a significant increase in the user's blood glucose level and a significant increase in the automatic delivery of liquid drugs calculated by the drug delivery algorithm of the drug delivery system. [Claim 10] The drug delivery system according to claim 9, wherein the increase in the user's blood glucose level and the increase in the automatic delivery of the liquid drug are evaluated with respect to a predetermined moving window of width, which is evaluated each time a new blood glucose measurement is received from the continuous glucose monitor. [Claim 11] The drug delivery system according to claim 8, wherein the automatic detection of the intake of the meal is based on the analysis of a plot of the user's blood glucose levels by one or more machine learning models trained as meal detection classifiers. [Claim 12] The drug delivery system according to claim 11, wherein the one or more machine learning models are trained to detect postprandial increases in the user's blood glucose levels that begin at various times prior to the present time. [Claim 13] The drug delivery system according to claim 12, wherein the one or more machine learning models include a 10-minute detector, a 15-minute detector, and a 20-minute detector, and the one or more machine learning models are cascaded to provide a final determination of dietary intake. [Claim 14] The drug delivery system according to claim 8, wherein the automatic detection of the intake of the meal is based on the analysis of a plot of the user's blood glucose levels by one or more decision trees using multiple delay detectors that recognize that the blood glucose level has risen, assuming that the rise in blood glucose level began at various times prior to the present time. [Claim 15] The drug delivery system according to claim 14, wherein the results of the plurality of delay detectors are pooled to synthesize a final meal detection decision. [Claim 16] A drug delivery system, A method for compensating for dietary intake in the drug delivery system, To receive notifications about dining events, Calculating a safe bolus dose to be delivered to the user, To deliver the aforementioned safe bolus dose, To monitor the user's blood glucose level, In accordance with the drug delivery algorithm of the drug delivery system, further fluctuations in the user's blood glucose level are compensated for, Includes a processor configured to perform a method including, In response to the notification of the aforementioned meal event, the method is: To notify the user that an unreported meal has been detected, To provide the user with a recommended bolus dose, A drug delivery system further comprising adjusting the drug delivery algorithm of the drug delivery system to respond more aggressively to glucose deviations based on the recommended bolus dose.

Images