SYSTEM AND METHOD FOR ENSURING ADEQUATE BOLUS DELIVERY FOR MEAL REPLACEMENT - Patent application

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 benefit of U.S. Provisional Patent Application No. 63 / 300,460, filed January 18, 2022, the contents of which are incorporated by reference in their entirety herein. [Background technology]

[0002] Many conventional automated drug delivery systems are known, including, for example, a wearable drug delivery device of the type shown in FIG. 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 can be, for example, an OmniPod® drug delivery device manufactured by Insulet Corporation of Acton, Massachusetts. The drug delivery device 102 can be a drug delivery device such as those described in U.S. Pat. No. 7,303,549, U.S. Pat. No. 7,137,964, and U.S. Pat. No. 6,740,059, the contents of each of which are incorporated herein by reference in their entirety.

[0003] The wearable drug delivery device 102 is typically configured with a processor and memory and may execute a medication delivery algorithm (MDA). Alternatively, the medication delivery application may be executed on or via a remote device, such as a remote personal diabetes manager (PDM) or a smartphone, which may be configured to transmit medication delivery instructions to the wearable drug delivery device 102.

[0004] The MDA can provide a basal dose of a liquid medication. For example, in the case of a diabetic patient, the MDA can deliver a basal dose of insulin or a co-formulation of insulin with another medication to the user while allowing the user to self-administer a bolus dose of the liquid medication to compensate for post-prandial fluctuations in the user's blood glucose level.

[0005] A typical procedure for a user to self-administer a meal bolus is to use a bolus calculator to calculate the appropriate bolus dose to compensate for the meal consumed. To use the bolus calculator, the user inputs a predetermined number of carbohydrates in the meal, and the bolus dose is calculated based on the user's insulin-to-carb ratio. Typically, the bolus dose is the number of grams of carbohydrate in the meal divided by the insulin-to-carb ratio.

number

[0006] However, this method is prone to error as users often misestimate the number of carbohydrates in a meal. Furthermore, the insulin-to-carbohydrate ratio can change throughout the day depending on recent athletic activity, stress levels, hormonal fluctuations, etc. Too much or too little insulin can create a dangerous situation.

[0007] Additionally, experienced users may become comfortable using an automatic insulin delivery (AID) system and become complacent in self-administering bolus doses of liquid medications, inadvertently reducing the number of boluses taken for meals. This may increase the number of times users do not manually supplement meals with boluses. Additionally, meal boluses may be delayed, or a bolus taken in anticipation of a meal may be delayed.

[0008] Given the many uncertainties surrounding self-administration of a bolus dose, it may be desirable to provide a degree of safety to the user by incorporating some safeguards into the MDA that can compensate for, or at least warn the user of, abnormal situations that may arise due to the inherent shortcomings of self-administration of a bolus dose.

[0009] definition As used herein, the term "liquid drug" should be taken to include any drug in liquid form that can be administered by a drug delivery device via a subcutaneous cannula, including, for example, insulin, GLP-1, pramlintide, morphine, blood pressure medications, chemotherapy drugs, fertility medications, etc., or co-formulations of two or more of GLP-1, pramlintide, and insulin. Summary of the Invention [Means for solving the problem]

[0010] This Summary is provided to introduce a simplified abstract of concepts that are described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended as an aid in determining the scope of the claimed subject matter.

[0011] In a first embodiment, the MDA may be configured to provide a safeguard against insufficient delivery of a bolus dose of a liquid drug or to compensate for insufficient delivery of a bolus dose of a liquid drug. In a first aspect, various innovative features may be incorporated into the MDA to provide a safe calculation of a bolus dose to be automatically administered by the drug delivery device. The innovative features are described in further detail below. In a second aspect of the invention, the MDA may evaluate past glucose history to automatically determine whether the user has consumed a meal that was not manually compensated for or was undercompensated. If it is determined that the user has consumed a meal, in a third aspect of the invention, the MDA may provide a metric to the user and may increase the aggressiveness of the MDA for 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 may be automatically delivered by the drug delivery device 102.

[0012] In various embodiments, the drug delivery algorithm may provide all or any combination of the above-mentioned aspects of the present invention.

[0013] In the drawings, like reference characters generally refer to the same parts throughout the different views.In the following description, various embodiments of the present 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] [Diagram 2] FIG. 2 is an illustration of a prior art wearable drug delivery device of the type in which the invention disclosed herein may be used.

[0016] [Diagram 3]FIG. 3 is a diagram of an exemplary user interface screen showing a "Going to Eat" button that is 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] [Diagram 5] FIG. 5 is a diagram of an exemplary user interface screen showing a "Set Nighttime Mode" button and fields for entering start and end times for nighttime mode.

[0019] [Figure 6] FIG. 6 is a flow chart illustrating how the overnight coefficient is adjusted based on 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 blood glucose measurements over a day showing the rise in glucose levels when a meal is ingested and the portion of the plot used to detect a meal.

[0022] [Figure 9] Figure 9 is a schematic diagram of the machine learning pipeline.

[0023] [Figure 10] FIG. 10 illustrates the supervised training process for the 10-minute meal detector, the 15-minute meal detector, and the 20-minute meal detector.

[0024] [Figure 11] FIG. 11 is a flow chart illustrating the pooling of results from the 10-minute meal detector, the 15-minute meal detector, and the 20-minute meal detector to provide robust meal detection results.

[0025] [Figure 12] FIG. 12 is a flow chart illustrating the process of administering an automatic bolus of insulin. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0026] Detailed Description The present disclosure presents various systems, components, and methods for providing safeguards against insufficient bolus doses when a user is self-administering a bolus dose. The embodiments described herein provide one or more advantages over conventional prior art systems, components, and methods, namely, safeguards built into the drug delivery algorithm provide a safety net for the user in the event that the user self-administers an insufficient bolus dose.

[0027] Various embodiments of the present invention include systems and methods for delivering medication to a user using a drug delivery device (sometimes referred to herein as a "pod"), either autonomously or according to a wireless signal received from an electronic device. In various embodiments, the electronic device may be a user device, including a smartphone, a smart watch, a smart necklace, a module attached to the drug delivery device, or any other type or kind of electronic device that may be carried by a user or worn on the user's body and that executes an algorithm to calculate the time and dosage of delivery of the medication.

[0028] For example, the user device may run an "artificial pancreas" algorithm that calculates the time and dosage of insulin delivery. The user device may also communicate with sensors, such as glucose sensors, that collect data regarding the user's physical attributes or conditions, such as glucose levels. The sensor is placed in or on the user's body and may be part of the drug delivery device or may be a separate device.

[0029] Alternatively, the drug delivery device can communicate with the sensor instead of or in addition to the communication between the sensor and the user device. The communication can be direct (e.g., if the sensor is integrated with or otherwise part of the drug delivery device) or remote / wireless (e.g., if the sensor is located in a different housing than the drug delivery device). In these embodiments, the drug delivery device includes computing hardware (e.g., processor, memory, firmware, etc.) that executes some or all of the algorithms that calculate the time and dosage of delivery of the medication.

[0030] 1 is a functional block diagram of an exemplary drug delivery system 100 suitable for implementing the systems and methods described herein. The drug delivery system 100 may implement (and / or provide functionality for) a drug delivery algorithm, such as an artificial pancreas (AP) application, to govern or control the automated delivery of a drug or medication, such as insulin, to a user (e.g., to maintain euglycemia, which is a normal level of blood glucose). The drug delivery system 100 may be an automated drug delivery system that includes a drug delivery device 102 (which may be wearable), an analyte sensor 108 (which may also be wearable), and a user device 105.

[0031] The drug delivery system 100 may also include, in optional examples, an accessory device 106, such as a smart watch, a personal assistant device, etc., which may communicate with other components of the system 100 via either wired or wireless communication links 191-193.

[0032] User Device The user device 105 may be a computing device such as a smartphone, tablet, personal diabetes management (PDM) device, dedicated diabetes care management device, etc. In one example, the user device 105 may include a processor 151, a device memory 153, a user interface 158, and a communication interface 154. The user device 105 may also include analog and / or digital circuitry that may be implemented as the processor 151 for performing processing based on programming code stored in the device memory 153, such as a user application 160 for managing the user's blood glucose level and controlling delivery of drugs, medications, or therapeutics to the user, as described below, and for providing other functions such as calculating carbohydrate correction doses, correction bolus doses, etc. The user device 105 may be used to program, adjust settings, and / or control operation of the drug delivery device 102 and / or analyte sensor 108 and optional smart accessory device 106.

[0033] The processor 151 may also be configured to execute programming code stored in the device memory 153, such as user apps 160. The user apps 160 may be computer applications operable to deliver medication based on information received from the analyte sensor 108, the cloud-based service 111, and / or the user device 105 or optional accessory device 106. The memory 153 may also store programming code for operating, for example, a user interface 158 (e.g., a touch screen device, a camera, etc.), a communication interface 154, or the like. When executing the user apps 160, the processor 151 may be configured to implement displays and notifications related to food intake, blood glucose measurements, and the like. The user interface 158 is under the control of the processor 151 and may be configured to present a graphical user interface that allows for input of food announcements, adjustment of setting selections, and the like, as described herein.

[0034] In a specific example, when the user app 160 is an AP application, the processor 151 is also configured to execute a diabetes treatment plan (which may be stored in the memory) managed by the user app 160. In addition to the above-mentioned functions, when the user app 160 is an AP application, it can further provide functions to determine a carbohydrate compensation dose, a correction bolus dose, and determine a basal dose according to the diabetes treatment plan. Furthermore, as an AP application, the user app 160 provides functions to output a signal to the drug delivery device 102 via the communication interface 154 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 app 160.

[0036] The user device 105 may further include one or more output devices 155, for example speakers and vibration transducers, for providing various signals to the user.

[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 executing a drug delivery algorithm (MDA) 129 stored in a memory 123 onboard 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 app 160 executing on the user device 105, communicated to the drug delivery device 102 via a communication link 194. The drive mechanism 125 operates to translate a plunger longitudinally through the reservoir to force the liquid drug through an outlet fluid port and into the 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 to allow for independent delivery of two different liquid drugs. As an example, the reservoir 124 may be filled with insulin and the reservoir 124-2 may be filled with pramlintide or GLP-1. In some embodiments, each of the reservoirs 124, 124-2 may be configured with a separate drive mechanism 125, 125-2, respectively, which may be separately controllable by the controller 121 under the direction of the MDA 129. Both of the reservoirs 124, 124-2 may be connected to a common needle / cannula 186.

[0039] The drug delivery device 102 may optionally be configured with a user interface 127 that provides means for receiving input from a user and for outputting information to a 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 device movement or a user gesture (e.g., tapping on the housing of the device), or any other type of interface device configured to allow a user to input information and / or for the drug delivery device 102 to output information for presentation to a user (e.g., an alarm signal, etc.).

[0040] The drug delivery device 102 includes a patient interface 186 for interfacing with a 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 integral to the drug delivery device 102 or may be attachable to the drug delivery device 102. The insertion mechanism may consist in one embodiment 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, a cellular standard, etc. The controller 121 may 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 of a pressure sensor, a power sensor, etc. that are communicatively coupled to the controller 121 and provide various signals. For example, the pressure sensor may be configured to provide an indication of a fluid pressure detected in a fluid path between the patient interface 186 and the reservoir 124. The pressure sensor may be coupled to or integral with an actuator for inserting the patient interface 186 into a user. In one example, the controller 121 may be operable to determine a drug infusion rate based on the indication of the fluid pressure. The drug infusion rate may be compared to an infusion rate threshold, and the comparison may be usable in determining an amount of insulin onboard (IOB) or a total daily insulin (TDI) amount. In one embodiment, the analyte sensor 108 may be integral with the drug delivery device 102.

[0043] The drug delivery device 102 further includes a power source 128, such as a battery, a piezoelectric device, an energy harvesting device, etc., for powering the controller 121, the memory 123, the drive mechanism 125 and / or other components of the drug delivery device 102.

[0044] The drug delivery device 102 may be configured to implement and execute the processes necessary to deliver a dose of medication to a user without input from the user device 105 or 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, the IOB, the amount of insulin remaining, etc., and cause the controller 121 to actuate the drive mechanism 125 to deliver the medication from the reservoir 124. The MDA 129 may take as input data received from the analyte sensor 108 or the user app 160.

[0045] The reservoirs 124, 124-2 can be configured to store a drug, agent, or therapeutic agent suitable for automated delivery, such as insulin, pramlintide, GLP-1, a co-formulation of insulin and GLP-1, morphine, blood pressure medication, chemotherapy medication, or fertility medication.

[0046] The drug delivery device 102 may be a wearable device and may be attached to the body of a user at an attachment location and may deliver any therapeutic agent, including any drug or pharmaceutical, such as insulin, to the user at or near the attachment location. The surface of the drug delivery device 102 may include an adhesive to facilitate attachment to the skin of a user.

[0047] When configured to communicate with an external device, such as a user device 105 or an analyte sensor 108, the drug delivery device 102 can receive signals from the user device 105 or the analyte sensor 108 via a wired or wireless link 194. A controller 121 of the drug delivery device 102 can receive and process the signals from the respective external device and effectuate the delivery of drugs to the user according to a diabetes treatment plan or other drug delivery regimen.

[0048] Attached Devices The optional accessory device 107 may be a wearable smart device, such as a smart watch (e.g., Apple Watch®), smart glasses, smart jewelry, a global positioning system-enabled wearable, a wearable fitness device, smart clothing, and the like. Similar to the user device 105, the accessory device 107 may also be configured to perform various functions, including control of 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 a memory 173. The user interface 178 may be a graphical user interface displayed on a touch screen 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 user apps 160, or simplified versions of the user apps 160 with reduced functionality. In some examples, the accessory device 107 may also include various types of sensors.

[0049] Analyte 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 a processor 151 of the management device 105 or a 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 a number of different analytes, such as glucose, lactate, ketones, uric acid, sodium, potassium, alcohol levels, etc., and output a detection result, such as a measurement. 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, every minute, etc., in an exemplary embodiment. The communication interface 135 of the analyte sensor 108 may have circuitry that operates as a transceiver to communicate the measured blood glucose levels 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, a pressure sensor, etc. The controller 131 may include separate dedicated logic and / or components, an application specific integrated circuit, a microcontroller or processor executing software instructions, firmware, programming instructions stored in a memory (such as the 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] 1, the analyte sensor 108 and the drug delivery device 102 may be incorporated into the same unit. That is, in various examples, the analyte sensor 108 is part of the drug delivery device 102, may be integral with the drug delivery device 102, may be included in the same housing as the drug delivery device 102, or in a housing that is attachable to or otherwise adjacent to the housing of the drug delivery device 102. In such example configurations, the controller 121 can perform the functions necessary for proper delivery of the medication alone, without any external input from the user device 105, the cloud-based service 111, another sensor (not shown), the optional accessory device 106, or the like.

[0053] Cloud-based services The drug delivery system 100 can communicate with or receive services from a cloud-based service 111. The services provided by the cloud-based service 111 can include data storage to store personal or anonymized data, such as blood glucose measurements, past IOB or TDI, previous carbohydrate compensation doses, and other forms of data. Additionally, the cloud-based service 111 can process anonymized data from multiple users to provide generalized information related to TDI, insulin sensitivity, IOB, etc. The communication links 115 coupling the cloud-based service 111 to each device 102, 105, 106, 108 of the system 100 can be cellular links, Wi-Fi links, Bluetooth links, or combinations thereof.

[0054] Communication Links The wireless communication links 115 and 191-196 may be any type of wireless link operating using a known or proprietary wireless communication standard. By way of example, the wireless communication links 191-196 may provide a communication link based on Bluetooth, Zigbee, Wi-Fi, a short-range wireless communication standard, a cellular standard, or any other wireless protocol via the respective communication interfaces 126, 135, 154, 174.

[0055] Example of operation In an operational example, the user application 160 implements a graphical user interface that is the primary interface with the user and is used to start and stop the drug delivery device 102, program basal and bolus calculator settings for manual mode, and program settings specific to automatic mode (hybrid closed loop or closed loop).

[0056] The user app 160 provides a graphical user interface 158 that can use large text, graphics, and on-screen instructions to guide the user through the set-up process and use of the system 100. It is also used to program a user-customized basal insulin delivery profile, check the status of the drug delivery device 102, initiate a bolus of insulin, 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 a manual mode in which the user app 160 delivers insulin at programmed basal rates and bolus amounts, with the option to set basal profiles for different times of the day or temporary basal profiles. The controller 121 also has the capability to function as a sensor-equipped pump in manual mode, using sensor glucose data provided by the analyte sensor 108 to input into a bolus calculator.

[0058] The user app 160 may be configured to operate in an automatic mode that supports the user app 160 to use 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, with increments of 10 mg / dL, 5 mg / dL, or other increments, but preferably in increments of 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, and bolus calculator settings, which then inform the user app 160 of the insulin delivery parameters. The insulin delivery parameters are adapted over time based on the total daily insulin (TDI) delivered during each use of the drug delivery device 102. A temporary hypoglycemic protection mode may be implemented by the user in the automatic mode for various times. In the hypoglycemic protection mode, the algorithm reduces insulin delivery and is intended for use over temporary periods when insulin sensitivity is expected to be high, such as during exercise.

[0059] The user app 160 (or MDA 129) can provide periodic insulin microboluses based on past glucose measurements and / or predicted glucose over a prediction interval (e.g., 60 minutes). Optimal post-prandial control may require the user to deliver meal boluses in the same manner as current pump therapy, but normal operation of the user app 160 compensates for missed meal boluses and reduces persistent hyperglycemia. The user app 160 employs a goal-directed control strategy that seeks to achieve and maintain set target glucose values, thereby reducing the duration of persistent hyperglycemia and hypoglycemia.

[0060] In some embodiments, the user device 105 and the analyte sensor 108 may not communicate directly with each other. Instead, data from the analyte sensor (e.g., a blood glucose measurement) may be communicated to the drug delivery device 102 via link 196 and then conveyed to the user device 105 via link 194. In some embodiments, the analyte sensor serial number must be entered into the user app 160 to enable communication between the analyte sensor 108 and the user device 105.

[0061] The user app 160 may 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 aid in determining a suggested bolus dose based on ingested carbohydrates, most recent blood glucose reading (or blood glucose reading if using a fingerstick), a programmable correction factor, insulin to carbohydrate ratio, target glucose value, and residual insulin (IOB). The IOB is estimated by the user app 160 taking into account any manual bolus and algorithmically delivered insulin, and the IOB may be divided between basal IOB and bolus IOB, where the basal IOB takes into account algorithmically delivered insulin and the bolus IOB takes into account any bolus delivery.

[0062] Description of the embodiments A primary embodiment of the present invention is directed to an improvement implemented in an automatic drug delivery system 100, an example of which is shown in FIG. 1, to facilitate a user in maintaining a safe blood glucose level. 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 further necessary administration of liquid drug according to MDA 129. In another embodiment, the drug delivery system 100 automatically maintains acceptable glucose levels even if the user does not self-administer a bolus dose of insulin before or after a meal.

[0063] The improvements may be implemented, for example, by modification of software (i.e., user apps 160 or MDA 129) executing as part of the drug delivery system 100. In certain embodiments, certain functions may be implemented in user apps 160 executing on the user device 105 and other functions may be implemented in the MDA 129 executing on the drug delivery device 102. Because various functions may be shared between the user apps 160 and the MDA 129, the user applications 160 and the MDA 129 are collectively referred to herein as "system software."

[0064] In one embodiment, the user is provided with a "Going to Eat" user selectable button 302, shown in FIG. 3, which, when selected by the user, indicates a meal event to the system software (i.e., indicates the user intends to eat). In certain embodiments, the MDA 129, upon receiving notification of a meal event, can take the place of a bolus calculator and can eliminate the need for the user to input a carbohydrate profile for the intended meal. In a preferred embodiment of the 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 an input directly to the drug delivery device 102 via the user interface 127 (although in this example, a graphical representation of the button 302 is not displayed). When the user selects the "Eat" button 302 (or the drug delivery device 102 is provided with an indication of a meal event), a safe bolus insulin dose is calculated and delivered to the user, with the safe bolus calculation taking into account the user's current blood glucose level, remaining insulin (IOB), the user's glucose trends over a predefined period of time in the past (in a preferred embodiment, 30 minutes), and whether night mode is enabled. Each of these considerations is described later in this specification.

[0065] An analysis of insulin delivered before a meal is depicted in the histogram shown in Figure 4. The histogram shows the delivered insulin versus density as a percentage of a typical user's total daily insulin (TDI). A safe nominal insulin dose, which may be adjusted by various considerations to determine a safe bolus dose, may be expressed as a percentage of a user's total daily insulin (TDI) as follows:

number

[0066] In another aspect of the invention, a safe correction dose of insulin (IOB safe requirement) can be calculated based on the user's current blood glucose level, high glucose threshold, and a correction factor (e.g., based on the 1600 rule, which estimates the drop in blood glucose level per unit of insulin by dividing the factor 1600 by the TDI, as shown in Equation 2 below). The safe correction dose, in some embodiments, can be expressed as:

number

[0067] In one embodiment, T Elevated Any value may be used for , for example, T Elevatedmay be set at 150 mg / dl. The high threshold is used in combination with the safe nominal insulin dose and the IOB to determine a safe bolus dose. The safe correction dose serves two purposes: first, to ensure a safe insulin requirement, and second, to allow some flexibility in delaying the intake of a meal after the user has indicated an intent to consume a meal by selecting the "Eat" button 302.

[0068] If data from the CGM is missing, the minimum CGM value from the past 30 minutes is used as the BG current If there is no valid CGM data for the past 30 minutes, the IOB safety requirement can be calculated as follows:

number

[0069] Any value may be used for the low threshold, but T Low The value of may be set to 100 ml / dl, 70 ml / dl or 40 ml / dl in certain embodiments. Since the low threshold is always lower than the high threshold, using the low threshold makes the IOB safety requirement negative, decreasing the total insulin.

[0070] In some embodiments, the safe bolus dose that is calculated and delivered after the user presses the "Eat" button 302 is calculated using a trend correction factor (CF) that depends on the trend of the user's blood glucose readings for a predetermined period of time prior to selecting the button 302. T ) can be further adjusted. In certain embodiments, the predetermined time period may be, for example, 30 minutes. In a preferred embodiment of the invention, blood glucose measurements are received periodically from the CGM every 5 minutes, although other periods may be used in other embodiments. In an embodiment in which CGM measurements are received at 5 minute intervals, a time period of the previous 30 minutes may be used to determine the current blood glucose measurement BG i Seven blood glucose measurements are obtained starting from

[0071] Trends can be detected by calculating the coarse slope and coarse curvature of the blood glucose measurements over time. In one embodiment, trends can be calculated by first calculating the average of the range of blood glucose measurements over 15 minute blocks as follows:

number

number

number

number

[0072] Then the coarse slope and coarse curvature are defined as follows:

number

number

[0073] In certain embodiments, the trend correction factor CF T can be determined using a rule set. Although any rule set can be used, in an exemplary embodiment, the rule set is CF T can be determined as follows:

number

number

number

[0074] If one or more CGM values ​​for a given historical period are missing or unavailable, a data quality metric may be used to determine whether sufficient CGM data is available to make a trend determination. Such a metric may be, for example, that more than x% (e.g., 30%) of data points are not missing in the last 30 minutes. If the data quality is unacceptable, no trend correction is performed and CF T is set to 1.

[0075] A hypoglycemia rebound factor (HF) is set to reduce the safe bolus dose if the user experiences a hypoglycemic event (e.g., hypoglycemia within one hour or within a threshold time limit) immediately prior to a bolus dose triggered by a meal event notification. Rebound ) can be applied. The hypoglycemic rebound factor can be specified as follows:

number

[0076] In some embodiments, a night mode setting may be provided. When the night 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 night mode user interface screen 500, shown in FIG. 5. This screen includes a "Set Nighttime Mode" user selectable button 502, which, when selected by the user, indicates to the system software that night mode is enabled. The user may set a start time 504 and an end time 506 to indicate when night mode will be implemented.

[0077] In an alternative embodiment, the night mode can be automatically enabled using an inertial measurement unit (IMU) sensor on the pump. The IMU includes one or more of an accelerometer, a gyro, and often a magnetometer. Together, these sensors can determine the motion, orientation (or tilt) of the device in one or more of the x, y, and z axes. For sustained activities such as running, swimming, or sleeping, the IMU generates a unique profile of signal activity for each axis. By deciphering these signals, a unique signature associated with the activity can be identified. Thus, if the user is determined to be sleeping, unique signatures along the three axes can be detected and, together with time zone information, a determination of the user's "night" mode can be made.

[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 auxiliary device 106. In other embodiments, if the drug delivery device 102 comprises a user interface 127, the user may initiate night mode directly on the drug delivery device 102 via the user interface 127 (but in this example without displaying the night mode user interface screen 500).

[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 may be set as a default. If in the past the current value has created an increased risk of hypoglycemia, the value may be decreased. Conversely, if in the past blood glucose has been elevated, the current value may be increased.

[0080] The flow chart shown in FIG. 6 can be used to determine an adjustment to the NF based on measurements of the user's blood glucose level over the past three hours during which a safe bolus dose was delivered. Starting with the current NF, a safe bolus dose is delivered and blood glucose is monitored for a predetermined period of time, for example, three hours. If blood glucose is elevated, the current NF is increased, for example, by 10%, for the next calculation. Elevated blood glucose may be defined in some embodiments as blood glucose exceeding the set value by more than 80 mg / dl at the three-hour time point. Other values ​​may be used, for example, 50 mg / dl, 60 mg / dl, 70 mg / dl, 90 mg / dl, or 100 mg / dl above the set value at the three-hour time point. In other embodiments, other criteria may be used. If the blood glucose is not elevated, it is determined whether the blood glucose has fallen below the low set value. If not, the current NF is not changed. However, if blood glucose falls below the set value, the NF may be decreased, for example, by 10%, for the next calculation.

[0081] In certain embodiments, any combination of trend factors, hypoglycemic rebound factors, and overnight factors may be applied to the safe bolus dose to modify the amount of liquid medication represented by the safe bolus dose that is delivered to the user in response to the user selecting button 302. Using all of the factors described above, the safe bolus insulin dose may be expressed as:

number

[0082] IOB is the remaining insulin (insulin-on-board) from the previous insulin delivery. If IOB is negative, it is rounded to 0.

[0083] The safe bolus dose is ideal for a closed loop system where algorithmic (basal) insulin can be safely increased to compensate for the safe bolus dose, greatly reducing the risk of hypoglycemia in a closed loop system. After the safe bolus dose is administered upon notification of a meal event, the drug delivery device's system software 100 follows the algorithmic basal insulin delivery embodied by the MDA 129 to compensate for further post-prandial fluctuations in the user's blood glucose level.

[0084] As the value of x decreases, multiple insulin doses may be administered according to equation (14). For example, x may be set or reduced to 3.5% by application of the various coefficients described above, and a first bolus insulin delivery may be administered when the user selects the "Eat" button 302, a second bolus 10 minutes later, and a third bolus 20 minutes later. Blood glucose trends may be utilized to safely administer insulin. IOB is safe against overdosing insulin.

[0085] Un-Bolused or Under-Bolused Meal Detection - In this aspect of the invention, a method is disclosed that evaluates past glucose history to determine if the user has had a meal that was not manually compensated for via self-bolus administration or was under-bolused, and for situations where the user did not notify the drug delivery system 100 of the meal and event by selecting button 302. In an extension of this embodiment, if an un-compensated or under-compensated meal is detected, the system software can provide metrics to the user and also increase the aggressiveness of the MDA 129 for high glucose concentrations during those periods.

[0086] A typical no-bolus or under-bolus meal can result in a significant increase in the user's glucose and a significant increase in automatic insulin delivery above basal. In one embodiment of this aspect of the invention, the system software can review a 5 hour window in 5 minute moving increments over each 24 hour period as follows:

number

number

[0087] As will be appreciated by those skilled in the art, the constants in the above equations are adjustable parameters: different periodic intervals over which the equations are evaluated, or different window sizes, will use appropriately different constants.

[0088] If W post and G post If , meet certain criteria, then all data points for that particular period can be considered to meet the definition of an unannounced meal detection. In one embodiment, these criteria can be, for example:

number

[0089] Here, the threshold is at least twice the user's TDI-based basal delivered over the last 5-hour window, and the user's average glucose over the last 5-hour window is greater than 180. It is important to note that the specific numerical values ​​introduced in this embodiment are all variable parameters. The increments of the moving window as well as the total duration can be changed, for example, reviewing a 6-hour window every 30-minute increment, or reviewing a 3-hour window every 15-minute increment, or other values. Furthermore, the thresholds of the selection criteria can also be changed. For example, the threshold for total increased automatic insulin delivery can be 1.5 times, 3 times, or 4 times compared to 2 times the basal delivery. Also, the final glucose concentration can be changed as different values, 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 moving window, along with an associated threshold of detection, can also be included as a condition in addition to or as an alternative to the termination glucose condition, for example, that the average glucose during the moving window is greater than 150 mg / dL.

[0091] Rather than a binary detection of meals during this period, the system can instead provide a probabilistic calculation of meal occurrence depending on the degree to which each condition is exceeded. For example, the system can provide a 50% likelihood that an unannounced meal or under-bolus meal has occurred if automated insulin delivery exceeds 1.5 times the basal rate over a 5-hour window, and the likelihood can increase to 100% if delivery exceeds 3 times the basal rate during this same period. Each condition can provide a probability of meal delivery, and a final determination of the meal occurrence probability can be calculated as the average, sum, or other combination of the assessments of meal probabilities across all conditions.

[0092] For each period in which an unannounced meal is detected, the system can inform the user that the system detected that the user had an unannounced meal, and the system software can provide a recommended amount of insulin based on the user's final glucose at the end of the period that would have improved the user's glucose control outcome if the user had self-administered a bolus of that amount.

number

[0093] Additionally, the system software can respond more aggressively to glucose deviations during the first 90 minutes of this period by decreasing the Q:R ratio (relative cost of insulin deviation vs. 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 a characteristic rise profile of blood glucose levels. The meal detection model is preferably trained on a closed-loop control data set. Blood glucose profiles from the closed-loop data with predefined rise characteristics are labeled to be used as training data. In one embodiment, the rise characteristics can 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, a decision tree for meal detection is trained on two hours of back-log blood glucose data starting from 10 minutes after the first blood glucose rise, 15 minutes after the first blood glucose rise, and 20 minutes after the first blood glucose rise.

[0096] Figure 7 shows a sliding window over a plot of blood glucose levels used to detect meals. In this example, meals are detected as the window indexes through time when the sliding window reaches BG points 23, 24, 25, and beyond. Figure 8 shows the relationship between blood glucose rise and meal detection. A pattern is shown for a day with three meals.

[0097] To detect meals, certain features are detected from the 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, resulting in 25 data points. In embodiments where a different history period or different intervals for sampling of blood glucose levels are used, a different number of data points will be available for analysis. In one embodiment of the present invention, the following features may be detected: 15-minute average (average blood glucose value for every 15 minutes during the last two hours of history); range feature (difference in blood glucose levels for every 15 minutes); delta value (difference in 15-minute average values, which provides a rough slope of the blood glucose plot); slope value (difference between successive values ​​of the slope of the blood glucose level plot); and second derivative (difference in the slope of the blood glucose level 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 20ml / dl within 15 minutes, 40ml / dl within 30 minutes, and 60ml / dl within 60 minutes are identified. The identified data is presented to a machine learning model to develop meal detection rules. It should be noted that while the complete rising portion of the blood glucose curve is used to recognize the post-prandial rise in glucose levels, in one embodiment, only 10, 15, and 20 minutes (and the values ​​of a total of 25 data points prior to each time point) of the rising blood glucose curve are presented to the machine learning system. The objective is to detect meals with minimal latency.

[0099] The machine learning pipeline is depicted in Figure 9, showing 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 of the meal must be inside the low and high thresholds. The 10-minute classifier looks at 10 minutes ahead and 110 minutes back to extract 2 hours of data, the 15-minute classifier looks at 15 minutes ahead and 105 minutes back to extract 2 hours of data, and the 20-minute classifier looks at 20 minutes ahead and 100 minutes back to extract 2 hours of data. Figure 10 shows 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 a 10-minute delay detector, a 15-minute delay detector, and a 20-minute delay detector. The 10-minute delay detector, the 15-minute delay detector, and the 20-minute delay detector recognize a rise in blood glucose level assuming that the post-prandial blood glucose rise started 10 minutes, 15 minutes, and 20 minutes before the current time, respectively. The exact rules used in the meal detection decision tree may vary based on different embodiments of the invention. Additionally, detectors using different time periods can also be developed.

[0101] To make meal detection more robust, models may be cascaded and / or combined. When a new blood glucose value is received from the CGM 108, at each 5 minute interval, a 10 minute meal detector, a 15 minute meal detector, and a 20 minute meal detector are triggered to detect meals. These results are combined into a robust meal detection model, an example of which is shown in FIG. 11. At 1100, the most recent cycle of the MDA 129 begins, 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 are added to the 2 hour history of blood glucose measurements. At 1110, the results from each of 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 a pooled classifier at 1110 to determine whether the meal detection is "TRUE" or "FALSE".

[0102] As an example, if the 10 minute delay meal detector returns true in the current cycle, it is expected that the 15 minute delay meal detector will return true in the next cycle (which may also return true in this cycle), the 20 minute delay meal detector will return true in the next cycle, etc. For robustness, a period during which these detectors may return true is allowed, and the final meal detection result is combined by subtracting the results of the 10 minute, 15 minute, and 20 minute detectors, as shown in FIG.

[0103] Automatic Bolus Delivery - In certain embodiments, when a missed or under-bolused meal is detected, an automatic bolus dose of insulin is injected, regardless of the method used for detection. FIG. 12 shows the logic flow for determining whether an automatic bolus should be delivered. At 1200, a cycle begins. As previously described, in a preferred embodiment of the invention, each cycle is 5 minutes long and during each 5 minute cycle, a new blood glucose reading is received from the CGM. In certain embodiments of the invention, the receipt of a new BG reading triggers the start of the next cycle. At 1202, a most recent blood glucose reading is received and at 1204, the meal detector described above is performed on the most recent blood glucose readings, including the most recently received reading. At 1206, if a meal is detected, at 1208, an automatic bolus is delivered as previously described. If no meal is detected, control returns to 1200 to await the start of the next cycle.

[0104] The auto-bolus may have a nominal insulin delivery amount. In one embodiment, the auto-bolus may be a safe bolus dose as described in detail above. In another exemplary embodiment, the insulin requirement is nominally a percentage of the user's TDI (e.g., 8%). This insulin amount is determined by the safe IOB requirement (IOB requirement). SR ) for correction and adjusted by the current IOB. The Safe IOB Requirement indicates the insulin required to correct blood glucose (however, instead of using the insulin set point, a higher value, e.g. 150 mg / dl, may be used for improved safety).

number

number

[0105] If a manual bolus is administered before the auto-bolus is triggered, the IOB will regulate the insulin delivery: if the IOB is high enough, the auto-bolus can administer 0 units of insulin, whereas if the user is under-bolused, the IOB will provide the appropriate amount of insulin.

[0106] Auto-bolus delivers a safe amount of insulin for post-meal glycemic compensation, and the core closed-loop control algorithm continues to provide the appropriate amount of basal insulin to maximize time in range for the user.

[0107] The following examples relate to various embodiments of the systems and methods disclosed herein for providing a method for determining optimal delivery of a drug by providing a step-by-step exploration of a search space of possible amounts of a drug to be delivered to a user.

[0108] Example 1 is a method of a first embodiment of the present invention, which includes receiving a notification of a meal event, calculating a safe bolus dose to be delivered to a user, delivering the safe bolus dose, moderating the user's blood glucose level, and compensating for further fluctuations in the user's blood glucose level via a drug delivery algorithm of a drug delivery system.

[0109] Example 2 is an extension of example 1 or any other example disclosed herein, where the notification of the meal event includes a user selecting a button in a user interface.

[0110] Example 3 is an extension of Example 1, or any other example disclosed herein, where the safe bolus dose is calculated as a function of the safe nominal insulin delivery rate and the current remaining insulin.

[0111] Example 4 is an extension of Example 3, or any other example disclosed herein, where the nominal safe insulin delivery amount is calculated as a percentage of the user's total daily insulin need.

[0112] Example 5 is an extension of Example 4, or any other example disclosed herein, where the safe bolus dose is modified by a glycemic correction factor that takes into account the user's current blood glucose level.

[0113] Example 6 is an extension of Example 5, or any other embodiment disclosed herein, where the safe bolus dose is modified by a trend correction factor that corrects for the user's blood glucose trend over a given period of time in the past.

[0114] Example 7 is an extension of Example 6, or any other example disclosed herein, where the trend correction factor is based on the slope and curvature of the user's blood glucose levels over a past period of time.

[0115] Example 8 is an extension of Example 5, or any other example disclosed herein, where the safe bolus dose is modified by a rebound factor 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 delivery of the safe bolus dose.

[0116] Example 9 is an extension of Example 5, or any other example disclosed herein, where the safe bolus dose is modified by an overnight factor that reduces the safe bolus dose by a calculated amount if the bolus dose is administered during an overnight period.

[0117] Example 10 is an extension of Example 9, or any other embodiment disclosed herein, where if in a past occurrence the current value of the overnight factor created an additional risk of hypoglycemia, the current value is lowered, or if in a past occurrence the current value of the overnight factor elevated the user's blood glucose level, the current value is increased.

[0118] Example 11 is an extension of Example 3, or any other example disclosed herein, where the safe bolus dose can be modified by any combination of a blood glucose correction factor, a trend correction factor, a hypoglycemia rebound factor, and an overnight factor.

[0119] Example 12 is an extension of Example 1 or any other example disclosed herein, wherein delivering the safe bolus dose further includes dividing the safe bolus dose into multiple incremental doses delivered at predetermined times after notification of the meal event.

[0120] Example 13 is an extension of Example 12, or any other example disclosed herein, where the safe bolus dose is recalculated at each incremental delivery.

[0121] Example 14 is an extension of example 1 or any other example disclosed herein, where the notification of the meal event includes automatically detecting the intake of a meal based on the user's blood glucose level received from a continuous glucose monitor.

[0122] Example 15 is an extension of Example 14, or any other example disclosed herein, wherein automatically detecting the intake of a meal is based on detecting a significant increase in the user's blood glucose level in a significant increase in the automatic delivery of a liquid medication as calculated by a drug delivery algorithm of the medication delivery system.

[0123] Example 16 is an extension of Example 15, or any other embodiment disclosed herein, where an increase in the user's blood glucose level and an increase in the automatic delivery of liquid medication are evaluated in a predetermined moving window that is evaluated upon receipt of each new blood glucose measurement from the continuous blood glucose monitor.

[0124] Example 17 is an extension of Example 14 or any other example disclosed herein, where the automatic detection of meal intake is based on analysis of a plot of the user's blood glucose levels by one or more machine learning models trained as meal detection classifiers.

[0125] Example 18 is an extension of Example 17 or any other example disclosed herein, where the one or more machine learning models are trained to detect post-prandial rises in the user's blood glucose level beginning at various times prior to the current time.

[0126] Example 19 is an extension of Example 18 or other examples disclosed herein, wherein the 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 any other example disclosed herein, where 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 any other example disclosed herein, where the automatic detection of meal intake is based on analysis of a plot of the user's blood glucose level by one or more decision trees.

[0129] Example 22 is an extension of Example 21 or any other example disclosed herein, where the decision tree uses multiple delayed detectors to recognize an increase in blood glucose level using the assumption that the increase in blood glucose level began at various times prior to the current time.

[0130] Example 23 is an extension of example 22 or any other example disclosed herein, where the multiple 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 any other example disclosed herein, where the results of multiple delayed detectors are pooled and a final meal detection call is combined.

[0132] Example 25 is an extension of Example 14, or any other example disclosed herein, wherein in response to notification of a meal event, the method further includes notifying the user of detection of an internal unannounced event of the meal and providing a recommended bolus dose to the user.

[0133] Example 26 is an extension of Example 25, or any other example disclosed herein, wherein in response to notification of a meal event, the method further includes adjusting a drug delivery algorithm of the drug delivery system to respond more aggressively to glucose deviations based on a recommended bolus dose.

[0134] Example 27 is a method of a second embodiment of the present invention, comprising the steps of automatically detecting the intake of a meal based on a 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 a drug delivery algorithm of a drug delivery system to be more responsive to glucose deviations based on the recommended bolus dose.

[0135] Example 28 is a third embodiment system comprising a processor and software executing on the processor that provides the functionality of receiving notification of a meal event, calculating a safe bolus dose to be delivered to a 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 in accordance with a drug delivery algorithm of the drug delivery system.

[0136] Example 29 is an extension of Example 28 or any other example disclosed herein, where the notification of the meal event includes a user selecting a button on a 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, and wherein the notification of the meal event includes automatically detecting the intake of a meal based on the user's blood glucose level received from the continuous glucose monitor.

[0138] Software-related implementations of the techniques described herein may include, but are not limited to, firmware, application specific software, or any other type of computer-readable instructions that may be executed by one or more processors. The computer-readable instructions may be provided via a non-transitory computer-readable medium. Hardware-related implementations of the techniques described herein may include, but are not limited to, integrated circuits (ICs), application specific ICs (ASICs), field programmable arrays (FPGAs), and / or programmable logic devices (PLDs). In some examples, the techniques described herein and / or any system or configuration components described herein may be implemented using a processor executing computer-readable instructions stored on one or more memory components.

[0139] Those skilled in the art to which the present invention pertains may realize many modifications and adaptations of the present invention. The implementations provided herein, including the values ​​of adjustable parameters, should be considered as illustrative and not limiting the present invention in any way. As will be appreciated by those skilled in the art, many variations of the implementations described herein are possible and fall within the scope of the present invention. Furthermore, it should be understood that the features of the various embodiments described herein are not mutually exclusive and may exist in various combinations and permutations without departing from the spirit and scope of the present invention, even if such combinations or permutations are not expressly stated herein. Thus, the methods and apparatus disclosed herein should be taken as illustrative of the present invention, and not as limiting thereof.

Claims

1. 1. A method of compensating for food intake in a drug delivery system, comprising: receiving a notification of a meal event; Calculating a safe bolus dose to be delivered to a user; delivering said safe bolus dose; monitoring a blood glucose level of the user; and compensating for further fluctuations in the user's blood glucose level in accordance with a drug delivery algorithm of the drug delivery system.

2. The method of claim 1 , wherein the notification of a meal event comprises a user selection of a button on a user interface of the medication delivery system.

3. The method of claim 1 , wherein the safe bolus dose is calculated as a function of a safe nominal insulin delivery rate and current residual insulin.

4. The method of claim 3 , wherein the safe nominal insulin delivery amount is calculated as a percentage of the user's total daily insulin requirement (TDI).

5. The safe bolus dose is: a blood glucose correction factor, taking into account the user's current blood glucose level; a trend correction factor that corrects for trends in the user's blood glucose levels over a past predetermined period of time; a hypoglycemia rebound factor that reduces the safe bolus dose by a predetermined amount if the user experiences a hypoglycemic event within a predetermined period of time prior to delivery of the safe bolus dose; an overnight factor that reduces the safe bolus dose by a calculated amount if the bolus dose is administered during an overnight period; The method of claim 4 , modified by one or more of:

6. The method of claim 5 , wherein the trend correction factor is based on a slope and curvature of the user's blood glucose levels over the past predetermined period of time.

7. The method of claim 5 , wherein the night mode is automatically detected using a motion profile and time zone information provided by the IMU.

8. 6. The method of claim 5, wherein the current value of the night-time coefficient is lowered if, in past occurrences, the current value created an increased risk of hypoglycemia, or is increased if, in past occurrences, the current value increased the user's blood glucose level.

9. Delivering the safe bolus dose comprises:

10. The method of claim 1, further comprising dividing the safe bolus dose into multiple incremental doses administered at predetermined times after notification of a meal event.

10. 10. The method of claim 9, wherein the safe bolus dose is recalculated with each incremental delivery.

11. The method of claim 1 , wherein the notification of a meal event comprises automatic detection of meal intake based on the user's blood glucose level received from a continuous glucose monitor.

12. 12. The method of claim 11, wherein the automatic detection of ingestion of the meal is based on detection of a significant increase in the user's blood glucose level and a significant increase in automatic delivery of liquid medication calculated by a drug delivery algorithm of the medication delivery system.

13. 13. The method of claim 12, wherein increases in the user's blood glucose level and increases in the automatic delivery of the liquid medication are evaluated with respect to a moving window of predetermined width that is evaluated each time a new blood glucose measurement is received from the continuous glucose monitor.

14. 12. The method of claim 11, wherein the automated detection of the meal intake is based on analysis of a plot of the user's blood glucose levels by one or more machine learning models trained as meal detection classifiers.

15. 15. The method of claim 14, wherein the one or more machine learning models are trained to detect post-prandial rises in blood glucose levels of the user beginning at various times prior to a current time.

16. 16. The method of claim 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 meal intake.

17. 12. The method of claim 11, wherein the automatic detection of the intake of the meal is based on analysis of the plot of the user's blood glucose level by one or more decision trees that use multiple delay detectors to recognize when blood glucose levels have risen assuming that the rise in blood glucose level began at various times prior to the current time.

18. 20. The method of claim 17, wherein the results of the multiple delayed detectors are pooled to combine a final meal detection decision.

19. In response to the notification of the meal event, the method includes: notifying the user that an unreported meal has been detected; The method of claim 1 , further comprising providing a recommended bolus dose to the user.

20. In response to the notification of the meal event, the method includes:

10. The method of claim 1, further comprising adjusting a drug delivery algorithm of the drug delivery system to react more aggressively to glucose deviations based on the recommended bolus dose.

Images