Dual hormone delivery system for reducing impending hypoglycemia and/or hyperglycemia risk

Abstract

The exemplary embodiments attempt to identify impending hypoglycemia and/or hyperglycemia and take measures to prevent the hypoglycemia or hyperglycemia. Exemplary embodiments may provide a drug delivery system for delivering insulin and glucagon as needed by a user of the drug delivery system. The drug delivery system may deploy a control system that controls the automated delivery of insulin and glucagon to a patient by the drug delivery system. The control system seeks among other goals to avoid the user experiencing hypoglycemia or hyperglycemia. The control system may employ a clinical decision support algorithm as is described below to control delivery of insulin and glucagon to reduce the risk of hypoglycemia or hyperglycemia and to provide alerts to the user when needed. The control system assesses whether the drug delivery system can respond enough to avoid hypoglycemia or hyperglycemia and generates alerts when manual action is needed to avoid hypoglycemia or hyperglycemia.

Description

BACKGROUND

Drug delivery systems that deliver insulin attempt to deliver insulin that diabetic patients cannot produce naturally. Some of the drug delivery systems attempt to deliver small doses of insulin at periodic intervals. Closed loop control systems may be used to adjust insulin delivery dosages and/or rates. These drug delivery systems generally assume that the insulin sensitivity of all patients is roughly the same. One drawback of many such drug delivery systems is that they inadvertently may drive the patient's blood glucose (BG) level to hypoglycemia levels or to hyperglycemia levels.

SUMMARY

In accordance with an exemplary embodiment, a device includes a communication interface with a glucose monitor for enabling glucose level readings of a user from the monitor to be communicated to the device. The device also includes a storage for storing insulin delivery history and/or glucagon delivery history to the user and a carbohydrate ingestion history of the user. The device additionally includes a delivery device interface with a delivery device for delivery of the insulin and/or glucagon to the user. Further, the device includes processing logic for determining whether the user will experience hypoglycemia and/or whether the user will experience hyperglycemia without further preventive measures based at least on one of the glucose level readings of the user, the insulin delivery history and/or the glucagon delivery history to the user, and a limit on an ability of the delivery device to modify the glucose level of the user over a time period. The processing logic may trigger a preventive measure to modify the glucose level of the user where it is determined that the user will experience hypoglycemia and/or it is determined that the user will experience hyperglycemia without further preventive measures.

The processing logic may trigger the preventive measure of generating an alert that the user will experience hypoglycemia or hyperglycemia. The device may further comprise a video display, and the alert may comprise output displayed on the video display. The device may further comprise an audio output device, and the alert may comprise audio output that is output via the audio output device. The device, in addition to the alert, may cause delivery of a bolus of insulin or glucagon to the user from the delivery device. The processing logic may determine that the user will experience hypoglycemia without preventive measures, and the alert may instruct the user to ingest rescue carbohydrates. The alert may specify a quantity of the carbohydrates for the user to ingest. The triggered preventive measure may be delivery of a bolus of insulin or glucagon from the delivery device.

The processing logic may comprise one of a microprocessor, a field gate programmable array (FPGA), an application specific integrated circuit (ASIC) or a controller integrated circuit. The limit on the device to modify the glucose level of the user may be one of an amount of insulin that can be delivered to the user over a period of time, an amount of glucagon that can be delivered over the period of time or how long can insulin delivery be suspended. The determining whether the user will experience hypoglycemia and/or whether the user will experience hyperglycemia without preventive measures may be additionally based on a carbohydrate ingestion history of the patient.

In accordance with an exemplary embodiment, a method is performed by processing logic of a device. The method includes receiving a glucose monitor reading of a glucose level of a user. The method also includes determining anticipated glucose levels of the user over a future time window based at least on the glucose monitor reading of the glucose level of the user, an amount of insulin already delivered to the user that will affect the glucose level of the user during the future time window, and a limit on an ability of a delivery device to modify the glucose level of the user over a time period. The method additionally includes comparing the determined anticipated glucose levels of the user over the future time window with a hypoglycemic action threshold and/or a hyperglycemic action threshold. Where the comparing indicates that at least one of the determined anticipated glucose levels exceeds a hyperglycemic action threshold, the method triggers an action to reduce the glucose action of the user; and where the comparing indicates that one of the determined anticipated glucose level falls below a hypoglycemic action threshold, the method triggers an action to increase the glucose level of the user.

Where the comparing indicates that at least one of the determined anticipated glucose levels exceeds a hyperglycemic threshold, with the device, a bolus of insulin may be delivered to the user in addition to the generating of an alert that a hyperglycemic event may occur. A dosage of the bolus of insulin to be delivered to bring a glucose level of the user to an acceptable level over the future time window may be determined, and the determined dosage may be delivered to the user by a delivery device. Where the comparing indicates that one of the determined anticipated glucose level falls below a hypoglycemic action threshold, with the device, a bolus of glucagon to the user by a delivery device may occur in addition to the generating an alert that hypoglycemia may occur. The processing logic may implement a closed loop control system for regulating delivery of insulin and/or glucagon to the user. Instructions that cause a processor to perform the method may be stored on a non-transitory computer-readable storage media. The hypoglycemic action threshold may account for a hypoglycemia threshold and an amount suspension of delivery of insulin by the delivery device can reduce the glucose level of the user. The hyperglycemia action threshold may account for the hyperglycemia threshold and a multiple of basal insulin delivery by the delivery device.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a simplified diagram of a drug delivery system for practicing an exemplary embodiment.

FIG. 2 depicts a more detailed diagram of a drug delivery system for practicing an exemplary embodiment.

FIG. 3 depicts a flowchart of illustrative steps for reducing risk of hypoglycemia and/or hyperglycemia with a drug delivery system.

FIG. 4 depicts a depicts a flowchart of illustrative steps for reducing risk of hypoglycemia with a drug delivery system.

FIG. 5 depicts a flowchart of illustrative steps for determining whether a system response of a drug delivery system is sufficient to avoid a hypoglycemic risk.

FIG. 6 depicts a diagram of possible system responses to a hypoglycemic risk.

FIG. 7 depicts a diagram showing illustrative types of hypoglycemic risk alerts.

FIG. 8 depicts a flowchart of illustrative steps for accounting for carbohydrate ingestion in adjusting insulin on board (IOB) for a user.

FIG. 9 depicts a depicts a flowchart of illustrative steps for reducing risk of hyperglycemia with a drug delivery system.

FIG. 10 depicts a flowchart of illustrative steps that may be performed to determine a required amount of IOB for a user to avoid hyperglycemia.

FIG. 11 depicts a flowchart of illustrative steps that may be performed to determine limits of a system response to a hyperglycemic risk.

FIG. 12 depicts a flowchart of illustrative steps that may be performed to determine a maximum automated insulin action over a time period for a drug delivery system.

FIG. 13 depicts a diagram depicting illustrative types of system compensation responses for a hyperglycemic risk.

FIG. 14 depicts a diagram of illustrative types of hyperglycemic risk alerts.

FIG. 15 depicts an illustrative blood glucose level scale showing thresholds that may be used by exemplary embodiments.

DETAILED DESCRIPTION

The exemplary embodiments address the above-described drawback of conventional drug delivery systems. The exemplary embodiments attempt to identify impending hypoglycemia and/or hyperglycemia and take measures to prevent the hypoglycemia or hyperglycemia. Exemplary embodiments may provide a drug delivery system for delivering insulin and glucagon as needed by a user of the drug delivery system. The drug delivery system may deploy a control system that controls the automated delivery of insulin and glucagon to a patient by the drug delivery system. The control system seeks among other goals to avoid the user experiencing hypoglycemia or hyperglycemia. The control system may employ a clinical decision support algorithm as is described below to control delivery of insulin and glucagon to reduce the risk of hypoglycemia or hyperglycemia and to provide alerts to the user when needed. The control system assesses whether the drug delivery system can respond enough to avoid hypoglycemia or hyperglycemia and generates alerts when manual action is needed to avoid hypoglycemia or hyperglycemia. For instance, if a user is at risk of hypoglycemia and the maximum drug delivery system response (such as suspension of insulin delivery or delivery of glucagon) is deemed to be insufficient, an alert may be sent to the user to ingest a certain quantity of carbohydrates.

The control system may use data from a BG sensor, such as a continuous glucose monitor (CGM), and a quantity of insulin already delivered to a user in making decisions regarding drug delivery and alerts. In addition, the control system may consider the operating limits of the drug delivery system and pre-existing carbohydrate ingestion by a user.

Although the drug delivery system may be an artificial pancreas (AP) system that seeks to emulate in part the endocrine behavior of an actual human pancreas, it should be appreciated that the approach described herein is more general and can apply to other drug delivery systems for delivering insulin and/or glucagon. The drug delivery system may employ different types of tubed or tubeless pumps for drug delivery. A closed loop control system may be used in some exemplary embodiments.

FIG. 1 illustrates a simplified block diagram of an example of a drug delivery system 100 suitable for practicing an exemplary embodiment. The drug delivery system 100 may not only deliver insulin to the user but also may deliver glucagon to the user. The example drug delivery system 100 may include a controller 102, a pump mechanism or other fluid extraction mechanism 104 (hereinafter “pump 104”), and a sensor 108. The controller 102, pump 104, and sensor 108 may be communicatively coupled to one another via a wired or wireless communication paths. For example, each of the controller 102, the pump 104 and the sensor 108 may be equipped with a wireless radio frequency transceiver operable to communicate via one or more communication protocols, such as Bluetooth®, or the like. The sensor 108 may be a glucose monitor such as, for example, a CGM 108. The CGM 108 may, for example, be operable to measure BG values of a user to generate the measured actual BG level signal 112.

As shown in the example, the controller 102 may receive a desired BG level signal 110, which may be a first signal, indicating a desired BG level or range for a user. The desired BG level signal 110 may be received from a user interface to the controller or other device, or by an approach that automatically determines a BG level for a user. The sensor 108 may be coupled to the user and be operable to measure an approximate value of an actual BG level of the user. The measured BG value, the actual BG level, the approximate measured value of the actual BG level are only approximate values of a user's BG level and it should be understood that there may be errors in the measured BG levels. The errors may, for example, be attributable to a number of factors such as age of the sensor 108, location of the sensor 108 on a body of a user, environmental factors (e.g., altitude, humidity, barometric pressure), or the like. The terms measured BG value, actual BG level, approximate measured value of the actual BG level may be used interchangeably throughout the specification and drawings. In response to the measured BG level or value, the sensor 108 generate a signal indicating the measured BG value. As shown in the example, the controller 102 may also receive from the sensor 108 via a communication path, a measured BG level signal 112, which may be a second signal, indicating an approximate measured value of the actual BG level of the user.

Based on the desired BG level signal 110 and the measured actual BG level signal 112 and additional information as will be described below, the controller 102 may generate one or more control signals 114 for directing operation of the pump 104. For example, one of the control signals 114 may cause the pump 104 to deliver a dose of insulin or glucagon 116 to a user via output 106. The dose of insulin or glucagon 116 may, for example, be determined based on a difference between the desired BG level signal 110 and the actual BG signal level 112 and additional information. The dose of insulin or glucagon 116 may be determined as an appropriate amount to drive the actual BG level of the user to the desired BG level. Based on operation of the pump 104 as determined by the control signals 114, the user may receive the insulin 116 from the pump 104. It should be appreciated that in some embodiments, separate pumps may be provided for the insulin and the glucagon. Moreover, in addition to the control signal to the pump 104, the drug delivery system may generate alerts as will be described below.

In various examples, one or more components of the drug delivery system 100 may be incorporated into a wearable or on body drug delivery system that is attached to the user.

The simplified block diagram of the example drug delivery system 100 provides a general illustration of the drug delivery of the drug delivery system and the feedback loop provided therein. An example of a more detailed implementation of devices usable in such a drug delivery system is illustrated in FIG. 2.

Various examples of a drug delivery system include a wearable drug delivery device that may operate in the system to manage treatment of a diabetic user according to a diabetes treatment plan. The diabetes treatment plan may include a number of parameters related to the delivery of insulin and/or glucagon that may be determined and modified by a computer application referred to as a drug delivery application. This application may also generate alerts as described below.

A wearable drug delivery device as described herein may include a controller operable to direct operation of the wearable drug delivery device via the drug delivery application. For example, a controller of the wearable drug delivery device may provide a selectable activity mode of operation for the user. Operation of the drug delivery device in the activity mode of operation may reduce a probability of hypoglycemia during times of increased insulin sensitivity for the user and may reduce a probability of hyperglycemia during times of increased insulin requirements for the user. The activity mode of operation may be activated by the user or may be activated automatically by the controller. The controller may automatically activate the activity mode of operation based on a detected activity level of the user and/or a detected location of the user.

FIG. 2 illustrates an example of a drug delivery system 200. The drug delivery system 200 may include a drug delivery device 202, a management device 206, and a BG sensor 204.

In the example of FIG. 2, the drug delivery device 202 may be a wearable or on-body drug delivery device that is worn by a user on the body of the user (designated as patient 205). The drug delivery device 202 may include a pump mechanism 224 that may, in some examples be referred to as a drug extraction mechanism or component, and a needle deployment mechanism 228. In various examples, the pump mechanism 224 may include a pump or a plunger (not shown).

The needle deployment component 228 may, for example include a needle (not shown), a cannula (not shown), and any other fluid path components for coupling the stored liquid drug in the respective reservoirs 225A and 225B to the user 205. Separate reservoirs may be provided for insulin 225A and for glucagon 225B. The cannula may form a portion of the fluid path component coupling the user 205 to one of the reservoirs 225A and 225B. After the needle deployment component 228 has been activated, a fluid path (not shown) to the user is provided, and the pump mechanism 224 may expel a liquid drug from a respective one of the reservoirs 225A or 225B to deliver the liquid drug to the user via the fluid path. The fluid path may, for example, include tubing (not shown) coupling the wearable drug delivery device 202 to the user (e.g., tubing coupling the cannula to the reservoirs 225A and 225B). Separate fluid paths may be provided for the insulin reservoir to the user and the glucagon reservoir to the patient.

The wearable drug delivery device 202 may further include a controller 221 and a communications interface device 226. The controller 221 may be implemented in hardware, software, or any combination thereof. The controller 221 may, for example, be a microprocessor, a logic circuit, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC) or a microcontroller coupled to a memory. The controller 221 may maintain a date and time as well as other functions (e.g., calculations or the like) performed by processors. The controller 221 may be operable to execute a drug delivery algorithm stored in the memory that enables the controller 221 to direct operation of the drug delivery device 202. In addition, the controller 221 may be operable to receive data or information indicative of the activity of the user from the IMU 207, as well as from any other sensors (such as those (e.g., accelerometer, location services application or the like) on the management device 206 or CGM 204) of the drug delivery device 202 or any sensor coupled thereto, such as a global positioning system (GPS)-enabled device or the like.

The controller 221 may provide the alert, for example, through the communications interface device 226. The communications interface device 226 may provide a communications link to one or more management devices physically separated from the drug delivery device 202 including, for example, a management device 206 of the user and/or a caregiver of the user (e.g., a parent). The communication link provided by the communications interface device 226 may include any wired or wireless communication link operating according to any known communications protocol or standard, such as Bluetooth or a cellular standard.

The example of FIG. 2 further shows the drug delivery device 202 in relation to a BG sensor 204, which may be, for example, a CGM. The CGM 204 may be physically separate from the drug delivery device 202 or may be an integrated component thereof. The CGM 204 may provide the controller 221 with data indicative of measured or detected BG levels of the user.

The management device 206 may be maintained and operated by the user or a caregiver of the user. The management device 206 may control operation of the drug delivery device 202 and/or may be used to review data or other information indicative of an operational status of the drug delivery device 202 or a status of the user. The management device 206 may be used to direct operations of the drug delivery device 202 and generate alerts to the user. The management device 206 may include a processor 261 and memory devices 263. The memory devices 262 may store a drug delivery (DD) application 269 including programming code that may implement the functionality described herein. The management device 206 may receive alerts, notifications, or other communications from the drug delivery device 202 via one or more known wired or wireless communications standard or protocol.

The drug delivery system 200 may be operable to implement a DD application. The drug delivery system 200 may be an automated drug delivery system that may include a wearable drug delivery device (pump) 202, a sensor 204, and a personal diabetes management device (PDM) 206.

In an example, the wearable drug delivery device 202 may be attached to the body of a user 205 and may deliver any therapeutic agent, including any drug or medicine, such as insulin or the like, to a user. The wearable drug delivery device 202 may, for example, be a wearable device worn by the user. For example, the wearable drug delivery device 202 may be directly coupled to a user (e.g., directly attached to a body part and/or skin of the user via an adhesive or the like). In an example, a surface of the wearable drug delivery device 202 may include an adhesive to facilitate attachment to a user.

The wearable drug delivery device 202 may be referred to as a pump, or an insulin pump, in reference to the operation of expelling a drug from the reservoirs 225A and 225B for delivery of the drug to the user.

In an example, the wearable drug delivery device 202 may include reservoirs 225A and 225B for storing the drugs (such as insulin and glucagon), a needle or cannula (not shown) for delivering the respective drugs into the body of the user (which may be done subcutaneously, intraperitoneally, or intravenously), and a pump mechanism (mech.) 224, or other drive mechanism, for transferring the drugs from the reservoirs 225A and 225B, through a needle or cannula (not shown), and into the user. The reservoirs 225A and 225B may be configured to store or hold a liquid or fluid, such as insulin, morphine, or another therapeutic drug. The pump mechanism 224 may be fluidly coupled to reservoirs 225A and 225B, and communicatively coupled to the processor 221. The wearable drug delivery device 202 may also include a power source (not shown), such as a battery, a piezoelectric device, or the like, for supplying electrical power to the pump mechanism 224 and/or other components (such as the processor 221, memory 223, and the communication device 226) of the wearable drug delivery device 202. Although also not shown, an electrical power supply for supplying electrical power may similarly be included in each of the sensor 204, the smart accessory device 207 and the management device (PDM) 206.

In an example, the BG sensor 204 may be a device communicatively coupled to the processor 261 or 221 and may be operable to measure a BG value at a predetermined time interval, such as every 5 minutes, or the like. The BG sensor 204 may provide a number of BG measurement values to the drug delivery applications operating on the respective devices. For example, the BG sensor 204 may be a continuous BG sensor that provides BG measurement values to the drug delivery applications operating on the respective devices periodically, such as approximately every 5, 10, 12 minutes, or the like.

The wearable drug delivery device 202 may contain analog and/or digital circuitry that may be implemented as a controller 221 (or processor) for controlling the delivery of the drug or therapeutic agent. The circuitry used to implement the processor 221 may include discrete, specialized logic and/or components, an application-specific integrated circuit, a microcontroller or processor that executes software instructions, firmware, programming instructions or programming code (enabling, for example, the DD application 229 stored in memory 223, or any combination thereof. The memory 223 may store measured glucose levels, insulin delivery history, glucagon delivery history, carbohydrate ingestion history and/or the like. The processor 221 may execute a control algorithm, such as the DD application 229, and other programming code that may make the processor 221 operable to cause the pump to deliver doses of the drugs or therapeutic agents to a user at predetermined intervals or as needed to bring BG measurement values to a target BG value, such as will be described in more detail below. The size and/or timing of the doses may be programmed, for example, into the DD application 229 by the user or by a third party (such as a health care provider, wearable drug delivery device manufacturer, or the like) using a wired or wireless link, such as 220, between the wearable drug delivery device 202 and a management device 206 or other device, such as a computing device at a healthcare provider facility. In an example, the pump or wearable drug delivery device 202 is communicatively coupled to the processor 261 of the management device via the wireless link 220 or via a wireless link, such as 291 from smart accessory device 207 or 208 from the sensor 204. The pump mechanism 224 of the wearable drug delivery device may be operable to receive an actuation signal from the processor 261, and in response to receiving the actuation signal and expel insulin from the reservoirs 225A and 225B and the like.

The devices in the system 200, such as management device 206, smart accessory device 207 and sensor 204, may also be operable to perform various functions including controlling the wearable drug delivery device 202. For example, the management device 206 may include a communication device 264, a processor 261, and a management device memory 263 for storing data, such as insulin delivery history, glucose delivery history, BG level history, alert history, carbohydrate ingestion history and activity history. The management device memory 263 may store an instance of the DD application 269 that includes programming code, that when executed by the processor 261 provides the process examples described herein. The management device memory 263 may also store programming code for providing the process examples described with reference to the examples herein.

Although not shown, the system 200 may include a smart accessory device may be, for example, an Apple Watch®, other wearable smart device, including eyeglasses, provided by other manufacturers, a global positioning system-enabled wearable, a wearable fitness device, smart clothing, or the like. Similar to the management device 206, the smart accessory device (not shown) may also be operable to perform various functions including controlling the wearable drug delivery device 202. For example, the smart accessory device may include a communication device, a processor, and a memory. The memory may store an instance of the AP application that includes programming code for providing the process examples described with reference to the examples described herein. The memory may also as store programming code and be operable to store data related to the AP application.

The sensor 204 of system 200 may be a CGM as described above, that may include a processor 241, a memory 243, a sensing or measuring device 244, and a communication device 246. The memory 243 may store an instance of a DD application 249 as well as other programming code and be operable to store data related to the drug delivery application 249. The DD application 249 may also include programming code for providing the process examples described with reference to the examples described herein.

Instructions for determining the delivery of the drugs or therapeutic agents (e.g., as a bolus dosage) to the user (e.g., the size and/or timing of any doses of the drug or therapeutic agent) may originate locally by the wearable drug delivery device 202 or may originate remotely and be provided to the wearable drug delivery device 202. In an example of a local determination of drug or therapeutic agent delivery, programming instructions, such as an instance of the DD application 229, stored in the memory 223 that is coupled to the wearable drug delivery device 202 may be used to make determinations by the wearable drug delivery device 202. In addition, the wearable drug delivery device 202 may be operable to communicate via the communication device 226 and communication link 288 with the wearable drug delivery device 202 and with the BG sensor 204 via the communication device 226 and communication link 289.

Alternatively, the remote instructions may be provided to the wearable drug delivery device 202 over a wired or wireless link by the management device (PDM) 206. The PDM 206 may be equipped with a processor 261 that may execute an instance of the DD application 269, if present in the memory 263. The memory may store computer-readable instructions for execution by the processor 261. The memory may include a non-transitory computer-readable storage media for storing instructions executable by the processor. The wearable drug delivery device 202 may execute any received instructions (originating internally or from the management device 206) for the delivery of insulin and glucagon to the user. In this way, the delivery of the insulin to a user may be automated.

In various examples, the wearable drug delivery device 202 may communicate via a wireless communication link 288 with the management device 206. The management device 206 may be an electronic device such as, for example, a smart phone, a tablet, a dedicated diabetes therapy management device, or the like. Alternatively, the management device 206 may be a wearable wireless accessory device, such as a smart watch, or the like. The wireless links 287-289 may be any type of wireless link provided by any known wireless standard. As an example, the wireless links 287-289 may enable communications between the wearable drug delivery device 202, the management device 206 and sensor 204 based on, for example, Bluetooth®, Wi-Fi®, a near-field communication standard, a cellular standard, or any other wireless optical or radio-frequency protocol.

The sensor 204 may also be coupled to the user by, for example, adhesive or the like and may provide information or data on one or more medical conditions and/or physical attributes of the user. The information or data provided by the sensor 204 may be used to adjust drug delivery operations of the wearable drug delivery device 202. For example, the sensor 204 may be a glucose sensor operable to measure BG and output a BG value or data that is representative of a BG value. For example, the sensor 204 may be a glucose monitor that provides periodic BG measurements a CGM, or another type of device or sensor that provides BG measurements.

The sensor 204 may include a processor 241, a memory 243, a sensing/measuring device 244, and communication device 246. The communication device 246 of sensor 204 may include an electronic transmitter, receiver, and/or transceiver for communicating with the management device 206 over a wireless link 222 or with wearable drug delivery device 202 over the link 208. The sensing/measuring device 244 may include one or more sensing elements, such as a BG measurement element, a heart rate monitor, a blood oxygen sensor element, or the like. The processor 241 may include discrete, specialized logic and/or components, an application-specific integrated circuit, a microcontroller or processor that executes software instructions, firmware, programming instructions stored in memory (such as memory 243), or any combination thereof. For example, the memory 243 may store an instance of a DD application 249 that is executable by the processor 241.

Although the sensor 204 is depicted as separate from the wearable drug delivery device 202, in various examples, the sensor 204 and wearable drug delivery device 202 may be incorporated into the same unit. That is, in one or more examples, the sensor 204 may be a part of the wearable drug delivery device 202 and contained within the same housing of the wearable drug delivery device 202 (e.g., the sensor 204 may be positioned within or embedded within the wearable drug delivery device 202). Glucose monitoring data (e.g., measured BG values) determined by the sensor 204 may be provided to the wearable drug delivery device 202, smart accessory device 207 and/or the management device 206, which may use the measured BG values to determine movement of the wearable drug delivery device indicative of physical activity of the user, an activity mode, a hyperglycemia mode and a hyperglycemia mode.

In an example, the management device 206 may be a personal diabetes manager. The management device 206 may be used to program or adjust operation of the wearable drug delivery device 202 and/or the sensor 204. The management device 206 may be any portable electronic device including, for example, a dedicated controller, such as processor 261, a smartphone, or a tablet. In an example, the personal management device (PMD) 206 may include a processor 261, a management device management device memory 263, and a communication device 264. The management device 206 may contain analog and/or digital circuitry that may be implemented as a processor 261 (or controller) for executing processes to manage a user's BG levels and for controlling the delivery of the drugs or therapeutic agents to the user. The processor 261 may also be operable to execute programming code stored in the management device management device memory 263. For example, the management device management device memory 263 may be operable to store a DD application 269 that may be executed by the processor 261. The processor 261 may when executing the DD application 269 may be operable to perform various functions, such as those described with respect to the examples. The communication device 264 may be a receiver, a transmitter, or a transceiver that operates according to one or more radio-frequency protocols. For example, the communication device 264 may include a cellular transceiver and a Bluetooth transceiver that enables the management device 206 to communicate with a data network via the cellular transceiver and with the sensor 204 and the wearable drug delivery device 202. The respective transceivers of communication device 264 may be operable to transmit signals containing information useable by or generated by the drug delivery application or the like. The communication devices 226 and 246 of respective wearable drug delivery device 202 and sensor 204, respectively, may also be operable to transmit signals containing information useable by or generated by the drug delivery application or the like.

The wearable drug delivery device 202 may communicate with the sensor 204 over a wireless link 208 and may communicate with the management device 206 over a wireless link 220. The sensor 204 and the management device 206 may communicate over a wireless link 222. The smart accessory device 207, when present, may communicate with the wearable drug delivery device 202, the sensor 204 and the management device 206 over wireless links 287, 288 and 289, respectively. The wireless links 287, 288 and 289 may be any type of wireless link operating using known wireless standards or proprietary standards. As an example, the wireless links 287, 288 and 289 may provide communication links based on Bluetooth®, Wi-Fi, a near-field communication standard, a cellular standard, or any other wireless protocol via the respective communication devices 226, 246 and 264. In some examples, the wearable drug delivery device 202 and/or the management device 206 may include a user interface 227 and 268, respectively, such as a keypad, a touchscreen display, levers, buttons, a microphone, a speaker, a display, or the like, that is operable to allow a user to enter information and allow the management device to output information for presentation to the user.

In various examples, the drug delivery system 200 may be an insulin drug delivery system. For example, the wearable drug delivery device 202 may be the OmniPod® (Insulet Corporation, Billerica, Mass.) insulin delivery device as described in U.S. Pat. Nos. 7,303,549, 7,137,964, or U.S. Pat. No. 6,740,059, each of which is incorporated herein by reference in its entirety or another type of insulin delivery device.

In the examples, the drug delivery system 200 may implement the embellished AP algorithm (and/or provide drug delivery functionality) to govern or control automated delivery of insulin and glucagon to a user (e.g., to maintain euglycemia—a normal level of glucose in the blood). The drug delivery application may be implemented by the wearable drug delivery device 202 and/or the sensor 204. The drug delivery application may be used to determine the times and dosages of insulin and glucagon delivery. In various examples, the drug delivery application may determine the times and dosages for delivery based on information known about the user, such as the user's sex, age, weight, or height, and/or on information gathered about a physical attribute or condition of the user (e.g., from the sensor 204). For example, the drug delivery application may determine an appropriate delivery of insulin or glucagon based on glucose level monitoring of the user through the sensor 204. The drug delivery application may also allow the user to adjust insulin or glucagon delivery. For example, the drug delivery application may allow a user to select (e.g., via an input) commands for output to the wearable drug delivery device 202, such as a command to set a mode of the wearable drug delivery device, such as an activity mode, a hyperglycemia protect mode, a hypoglycemia protect mode, deliver an insulin bolus, deliver a glucagon bolus or the like. In one or more examples, different functions of the drug delivery application may be distributed among two or more of the management device 206, the wearable drug delivery device (pump) 202 or the sensor 204. In other examples, the different functions of the drug delivery application may be performed by one device, such the management device 206, the wearable drug delivery device (pump) 202 or the sensor 204. In various examples, the drug delivery system 200 may include features of or may operate according to functionalities of a drug delivery system as described in U.S. patent application Ser. No. 15/359,187, filed Nov. 22, 2016 and Ser. No. 16/570,125, filed Sep. 13, 2019, which are both incorporated herein by reference in their entirety.

As described herein, the drug delivery system 200 or any component thereof, such as the wearable drug delivery device may be considered to provide embellished AP functionality or to implement a drug delivery application. Accordingly, references to the drug delivery application (e.g., functionality, operations, or capabilities thereof) are made for convenience and may refer to and/or include operations and/or functionalities of the drug delivery system 200 or any constituent component thereof (e.g., the wearable drug delivery device 202 and/or the management device 206). The drug delivery system 200—for example, as an insulin delivery system implementing an drug delivery application—may be considered to be a drug delivery system or a drug delivery system that uses sensor inputs (e.g., data collected by the sensor 204).

In an example, the drug delivery device 202 includes a communication device 264, which as described above may be a receiver, a transmitter, or a transceiver that operates according to one or more radio-frequency protocols, such as Bluetooth, Wi-Fi, a near-field communication standard, a cellular standard, that may enable the respective device to communicate with the cloud-based services 211. For example, outputs from the sensor 204 or the wearable drug delivery device (pump) 202 may be transmitted to the cloud-based services 211 for storage or processing via the transceivers of communication device 264. Similarly, wearable drug delivery device 202, management device 206 and sensor 204 may be operable to communicate with the cloud-based services 211 via the communication link 288.

In an example, the respective receiver or transceiver of each respective device 202, 206 or 207 may be operable to receive signals containing respective BG measurement values of the number of BG measurement values that may be transmitted by the sensor 204. The respective processor of each respective device 202, 206 or 207 may be operable to store each of the respective BG measurement values in a respective memory, such as 223, 263 or 273. The respective BG measurement values may be stored as data related to the drug delivery, such as 229, 249, or 269. In a further example, the drug delivery application operating on any of the management device 206, the smart accessory device 207, or sensor 204 may be operable to transmit, via a transceiver implemented by a respective communication device, 264, 274, 246, a control signal for receipt by a wearable drug delivery device. In the example, the control signal may indicate an amount of insulin to be expelled by the wearable drug delivery device 202.

In an example, one or more of the devices 202, 204, or 206 may be operable to communicate via a wired communication links 277, 278 and 279, respectively. The cloud-based services (not shown) may utilize servers and data storage (not shown). A communication link that couples the drug delivery system 200 to the cloud-based services may be a cellular link, a Wi-Fi link, a Bluetooth link, or a combination thereof, that is established between the respective devices 202, 204, or 206 of system 200. For example, the data storage (not shown) provided by the cloud-based services may store anonymized data, such as user weight, BG measurements, age, meal carbohydrate information, or the like. In addition, the cloud-based services 211 may process the anonymized data from multiple users to provide generalized information related to the various parameters used by the drug delivery application. For example, an age-based general target BG value related to activity levels or particular exercises or sports may be derived from the anonymized data, which may be helpful when a user selects an activity mode (or a hyperglycemia protect mode, or a hypoglycemia protect modes) or the system 200 automatically implements the activity mode (or the hyperglycemia protect, or the hypoglycemia protect modes). The cloud-based services may also provide processing services for the system 200, such as performing a process described with reference to later examples.

The wearable drug delivery device 202 may also include a user interface 227. The user interface 227 may include any mechanism for the user to input data to the drug delivery device 202, such as, for example, a button, a knob, a switch, a touch-screen display, or any other user interaction component. The user interface 227 may include any mechanism for the drug delivery device 202 to relay data to the user and may include, for example, a display, a touch-screen display, an audio output device or any means for providing a visual, audible, or tactile (e.g., vibrational) output (e.g., as an alert). The user interface 227 may also include additional components not specifically shown in FIG. 2 for sake brevity and explanation. For example, the user interface 227 may include a one or more user input or output components for receiving inputs from or providing outputs to a user or a caregiver (e.g., a parent or nurse), a display that outputs a visible alert, a speaker that outputs an audible, or a vibration device that outputs tactile indicators to alert a user or a caregiver of a potential activity mode, a power supply (e.g., a battery), and the like. Inputs to the user interface 227 may, for example, be a via a fingerprint sensor, a tactile input sensor, a button, a touch screen display, a switch, or the like. In yet another alternative, the activity mode of operation may be requested through a management device 206 that is communicatively coupled to a controller 221 of the wearable drug delivery device 202. In general, a user may generate instructions that may be stored as user preferences in a memory, such as 223 or 263 that specify when the system 200 is to enter the activity mode of operation.

Various operational scenarios and examples of processes performed by the system 200 are described herein. For example, the system 200 may be operable to implement process examples related to an activity mode including a hyperglycemia protect mode and a hypoglycemia protect mode as described in more detail below.

In an example, the drug delivery device 202 may operate as an embellished AP system (e.g., as a portion of the drug delivery system 100) and/or may implement techniques or an algorithm via a drug delivery application that controls and provides functionality related to substantially all aspects of a drug delivery system or at least portions thereof. The drug delivery device 202 may operate in an open-loop or closed-loop manner for providing a user with insulin and glucagon.

Additional features may be implemented as part of the drug delivery application, such as the activity mode, the hyperglycemia mode, the hypoglycemia mode, or the like. For example, the drug delivery device 202 when programming code is executed that enables the activity mode, hyperglycemia mode, hypoglycemia mode or the like of the drug delivery application. As the AP embellished application including the programming code for the activity mode, the hyperglycemia mode, and the hypoglycemia mode is executed, the drug delivery application may adjust operations, such as detecting motion or movement of the wearable drug delivery device that is indicative of physical activity of the user. For example, motion and movement of the wearable drug delivery device 202 that induces motions characteristic of physical activity of the user (e.g., movements, such as jumping, dancing, running, weightlifting, cycling or the like) may be detected by the IMU 207. In addition, the IMU 207, as described with reference to FIG. 3, may include a global positioning system that may detect a location of the wearable drug delivery device 202. Alternatively, or in addition, the wearable drug delivery device 202 may also utilize Wi-Fi location services to determine the location of the wearable drug delivery device 202. For example, the drug delivery algorithm may learn from repeated interaction with the user who may input an indication at particular times that they are about to perform physical activity. Alternatively, or in addition, the wearable drug delivery device 202 may upon detection of a particular location (e.g., gym, sports field, stadium, track, or the like) determine that the user is about to increase their physical activity.

As was mentioned above, the drug delivery system 200 may take steps to assess a risk of hypoglycemia and/or hyperglycemia and take preventive measures to attempt to avoid hypoglycemia or hyperglycemia. The assessment may look at the BG level of the user, the insulin on board for the user, the limit of the automated drug delivery system response and other values such as previously ingested carbohydrates. Based on the assessment, the drug delivery system 200 may deliver insulin or glucagon to a user or may suspend delivery of insulin to the user. Where the assessment indicates that the system limits prevent complete remediation of imminent hypoglycemia or hyperglycemia, the system may generate alerts that instruct the user to take manual action. In some instances, only alerts are generated without system action. In other instances where the system limits are not exceeded, no alerts may be produced; rather the system simply may perform the drug delivery or suspend drug delivery.

FIG. 3 depicts a flowchart 300 of illustrative steps that may be performed in an exemplary embodiment. The drug delivery system initially assesses whether any action is needed (302). The assessment largely is a determination of whether hypoglycemia or hyperglycemia is imminent for the user without additional preventive measures being taken separate from standard basal insulin delivery to the user. The drug delivery system then determines the limits of the system compensation (304). This may include determining how much insulin or glucagon can be delivered in bolus form, how much basal insulin is going to be delivered and how long can insulin delivery be suspended relative to current BG levels and target BG levels. The system determines whether the system compensation suffices to reach the target glucose level (306). If the system compensation suffices, then the system compensation may be performed (308). If the system compensation does not suffice, the system response may still be performed (310) to adjust the BG level of the user closer to the target BG level. This step may be optional. In addition, an alert may be generated to prompt manual action by the user to take remedial measures, such as carbohydrate ingestion, manual insulin or glucagon injection, or simply to inform the user of the risk so that the user can contact medical personnel or the like (312).

FIG. 4 depicts a flowchart 400 of illustrative steps that may be performed for the case of a hypoglycemia risk. These steps may be performed on an ongoing basis when new BG readings take place or only when certain ranges of BG levels are obtained. First, the drug delivery system determines the insulin action required to bring the BG level of the patient to the hypoglycemic threshold from the current BG level reading (402). This determination may entail calculating the following equation:

${\mathrm{IOB}}_{hypo}=\frac{\mathrm{CGM}\left(t\right)-{\mathrm{threshold}}_{hypo}}{1800/\mathrm{TDI}}$ where IOB_hypo is the amount of insulin onboard required to result in the insulin action to bring the BG level of the user to the hypoglycemic threshold; CGM(t) is the BG level at time t; threshold_hypo is the hypoglycemic blood threshold; and TDI is the total daily insulin needs of the user. The above equation determines the difference in BG level between the current BG level and the hypoglycemic threshold BG level. Then, the equation divides this difference by a factor indicative of a heuristic value of the user's correction factor that specifies the amount of drop in glucose concentration (mg/dL) for 1 U of insulin. It should be appreciated that the coefficient 1800 has been use but other coefficient values may be used instead. For instance, a value that is personalized to the user may be used.

The system determines the insulin on board (IOB) for the user to capture the currently remaining insulin action within the user (404). The IOB captures the basal insulin delivered as well as bolus deliveries. The IOB may also be adjusted for carbohydrate ingestion as will be described below. A determination is made whether the IOB is excessive such that the hypoglycemic threshold will be reached (406). This determination may entail calculating:IOB_excess=IOB(t)−IOB_hypo where the excess IOB_excess is the excess value. A positive value indicates that the hypoglycemic threshold will be reached. A negative number indicates that the hypoglycemic threshold will not be reached and no further steps are needed.

If IOB_excess is positive, the drug delivery system checks whether the system compensation will be sufficient (408). In this instance, the system compensation may be suspension of basal insulin delivery for a fixed period of time, such as an hour. FIG. 5 depicts a flowchart 500 of steps that may be performed to determine if the possible system compensation is sufficient. First, the system determines the minimum automated insulin action possible (502). This may be, for example, the insulin action resulting from suspending the delivery of automated insulin deliveries in a closed loop control system for an hour. This value may be calculated as:

${\mathrm{IOB}}_{\min }=\mathrm{IOB}\left(t\right)-\frac{\mathrm{TDI}}{48}$ where IOB_min is the minimum automated insulin action possible; IOB(t) is the insulin on board at time t; and TDI/48 is the total daily insulin of the user divided by 48 to obtain the amount of insulin that is delivered automatically in an hour assuming that the automated deliveries account for half of the TDI.

The IOB_min value is the compared with IOB_hypo to determine if the suspension of the automated delivery is enough to avoid hypoglycemia for the user (504). If IOB_min is greater than IOB_hypo (506), the suspension suffices (508); otherwise, the suspension does not suffice (510).

FIG. 6 shows possible forms of system compensation for hypoglycemia (600). As was discussed above, one form of response is to suspend automated insulin delivery (602). It should be appreciated that in some exemplary embodiments, the system compensation also may include automated glucagon deliveries (604) as will be described below and not just suspension of insulin delivery. The extent that such automated glucagon deliveries may alter the BG level of the patient may be part of the calculus to determine if the system response is sufficient.

Hence, if the system compensation suffices (408), the system compensation is performed (410). In this case, the automated insulin delivery is suspended for a preset time, such as an hour, to prevent the user BG level reaching the hypoglycemia threshold. However, if the system response is not sufficient, the system compensation may still be performed to assist in increasing the BGlevel of the patient (412). This step may be optional in some instances. However, an alert may be generated to have action performed (414). The action may be an automated action, such as the suspension of automated insulin delivery or an automated delivery of glucagon. In that instance, the alert serves to inform the user of the automated action. However, the alert may relate to manual action that is requested of the user. These alerts may be referred to as manual risk alerts.

The manual hypoglycemic risk alerts (702) may take different forms as depicted in the diagram 700 of FIG. 7. A basic alert (704) simply may advise the user of the hypoglycemic risk. This type of alert (704) may prompt the user to take preventive measures or contact medical personnel. Another variety of alert may prompt the user to take a specific action, such as ingestion of a given quantity of carbohydrates (706). The amount of carbohydrates ingested may be calculated as:CHO_rec=IOB_excess·ICR where ICR refers to the user's insulin to carbohydrate ratio. Yet another alert may prompt the user to manually deliver a glucagon bolus of a specified dose (708). The amount of glucagon delivery may be calculated as:

$Glu\left(t\right)=\frac{{\mathrm{IOB}}_{excess}\left(t\right)}{b\left(t\right)·1h}·0.04\frac{W}{B}$ where Glu(t) is the recommended glucagon delivery, in mg, for the current time t; IOB_excess(t) is the user's current excess insulin on board; b(t) is the user's current basal profile entry; W is the user's bodyweight, in kilograms; and B is a standard baseline bodyweight for which the ratio between 1 basal hour rate delivery and 0.04 mg of glucagon delivery are equivalent. There may be other varieties of alerts and alert types may be combined.

The above-described approach may be expanded to incorporate any pre-existing carbohydrate ingestion to better inform the estimate of pre-existing insulin delivery in the IOB estimate. As shown in the flowchart 800 of FIG. 8, the first step is to determine the sum of rescue carbohydrate ingestion (802). The following equation determines the sum of rescue carbohydrate ingestion over a time scale, assuming a linear decay:

${\mathrm{CHO}}_m\left(i\right)=\sum _{k=i}^{i-t_m}\left(1-\frac{t_k-t_m}{5}\right)\mathrm{CHO}\left(k\right)$ Where CHO_m(i) is the sum of carbohydrate ingestion, k is an index of rescue carbohydrate ingestion events, CHO (k) is the amount of carbohydrates ingested at the kth ingestion, t_k is the time of the kth ingestion event and t_m is the time of the first rescue carbohydrate ingestion.

The user's insulin to carbohydrate ratio may be determined (804). This value may be calculated as:

$\mathrm{ICR}=\frac{450}{\mathrm{TDI}}$ where ICR is the user's insulin to carbohydrate ratio, TDI is the user's total daily insulin, and 450 is a heuristic coefficient. Given the ICR, IOB for the user may be adjusted to account for the rescue carbohydrate ingestion (806). One possible equation for the adjustment is:

$\mathrm{IOB}\left(t\right)={\mathrm{IOB}}_{\mathrm{before}\mathrm{CHO}}-\frac{{\mathrm{CHO}}_m}{\mathrm{ICR}}$ where IOB_{before CHO} is the IOB before accounting for the rescue carbohydrate ingestion. The equation determines the reduction in insulin due to the amount of carbohydrate ingestion with linear decay given the insulin to carbohydrate ratio of the user.

As was mentioned above, the clinical decision support algorithm of the drug delivery system not only seeks to reduce the risk of hypoglycemia but also seeks to reduce the risk of hyperglycemia. FIG. 9 provides a flowchart 900 depicting illustrative steps that may be performed to avoid hyperglycemia. These steps may be performed at any time. For instance, they may be performed each time a new BG level reading for a user is received or only when the BG level is in a defined range, such as above a target threshold. Initially, the drug delivery system determines the insulin action required to bring the user to the target threshold (902).

FIG. 10 provides a flowchart 100 of illustrative steps that may be performed to determine the insulin action required to reach target (see step 902). First, the current glucose level of the user is determined at time t (1002). This is referred to as CGM(t). A check is made whether CGM(t) is above the target(t) (1004). This check may be made by calculating CGM(t)−target(t) and determining if it is positive value (1006). The value of this difference represents the magnitude of how much glucose the insulin action must account process. The difference may then be used to determine how much insulin is required to reduce the BG level of the user to the target. One way to determine the amount of insulin is to divide the difference by 1800/TDI (1008). Thus, the insulin action required may be calculated as:

${\mathrm{IOB}}_{\mathrm{req}}=\frac{\mathrm{CGM}\left(t\right)-\mathrm{target}\left(t\right)}{1800/\mathrm{TDI}}$ where IOB_req is the insulin on board required to bring the current BG level CGM(t) to the target threshold target(t) at time t. The 1800/TDI value applies the 1800 rule to determine the amount of insulin necessary to move the BG level to the target.

The drug delivery system determines the IOB(t) for the user (904) and then determines if the IOB(t) suffices to reach the target target(t) (906). This can be expressed as an equation as:IOB_deficiency=IOB_req−IOB(t)where IOB_deficiency refers to the deficiency in insulin to reach the target. A positive value indicates that there is a deficiency, whereas a negative value indicates that there is no deficiency. If there is no deficiency, the IOB(t) suffices, and there is no need for further preventive measures. However, if there is a positive value, the IOB(t) does not suffice and action should be taken.

If there is a deficiency (906), a determination is made whether the limits of the system compensation suffice (908). FIG. 11 depicts a flowchart (1100) of illustrative steps for determining the limits of the system compensation. The system may examine multiple types of system compensation. First, the system may look at whether the maximum automated insulin action by the drug delivery device (1102). The determination of the maximum automated insulin action is described in more detail below relative to FIG. 12. The maximum automated insulin action may suffice to address the hyperglycemia risk by bringing the BG level of the user to the target level. The system may also look at the delivery of an insulin bolus and determine how much insulin may be delivered by a bolus (1104). The delivery of an insulin bolus may be constrained by parameters such as when was a last insulin bolus delivered, the size of the bolus and the available insulin supply. The combination of the two amounts determined in steps (1102) and (1104) may specify the limits of the system compensation. It should be appreciated that in some embodiments these steps (1102) and (1104) need not be performed; rather a single step may be performed. For example, the drug delivery system may only look at the automated insulin action and not consider the bolus insulin delivery options or vice versa.

FIG. 12 depicts a flowchart (1200) of illustrative steps for determining the maximum automated insulin action (see 1102). The system determines the maximum delivery limit of insulin per day (1202). This is for the case where the drug delivery system is a closed loop system. In other words, a determination is made of how much insulin will the closed loop system allow to be delivered over a time window, such as one hour. The system multiplies the maximum delivery limit by the share of TDI in an hour to establish how much insulin can be delivered in an hour (1204). The resulting product may be summed with the insulin on board IOB(t) to get at the maximum automated insulin action (1206). The total equation may be expressed as:

${\mathrm{IOB}}_{\max }=\mathrm{IOB}\left(t\right)+m\mathrm{ult}\left(t\right)\frac{\mathrm{TDI}}{48}$ where IOB_max is the maximum automated insulin for the next hour; IOB(t) is the insulin on board at time t and mult(t) is the maximum delivery limit of insulin.

Where the system compensation suffices (see 908), the system compensation is performed (910). The system compensation (1302) may take the forms of diagram (1300) in FIG. 13. The system compensation response may entail automated delivery of insulin (1304). The dose amount may be increased responsive to the BG level of the user being above target. Alternatively, the basal dosage amount may be delivered if it will suffice to reduce the BG level of the user to target. The system compensation response may include delivering a bolus dose of insulin (1306). The bolus may be delivered in conjunction with the automated delivery of insulin.

Where the system compensation response is not enough, the system compensation may still be performed as described above in some instances (912). In other instances, the system compensation may be skipped. The drug delivery system may also issue alerts to the user (914). FIG. 14 shows a diagram (1400) depicting illustrative hyperglycemic risk alerts (1401) that may be issued. The alert may be informative of the impending hyperglycemic risk (1402). The alert may suggest that the user manually deliver an insulin bolus of a specified dosage (1404). It will be appreciated that other types of alerts may be generated and that the types of alerts may be combined.

In one exemplary embodiment, the clinical decision support algorithm can also incorporate the value and trend of the current glucose values and enable the recommendations if a specific threshold or additional conditions are met while the users are in closed loop. For example, the threshold can also be set to only activate the alert if additional safety constraints are exceeded. For example (as shown in FIG. 15), with an assumed maximum insulin delivery action of 4 times basal and a glucose target 1506 of 120 mg/dL, the hyperglycemia user action recommendation may only occur above a glucose concentration of 330 mg/dL (see hyperglycemic action threshold 1502) versus a hypoglycemic threshold 1504 of 180 mg/dL. As a further example, if the hypoglycemic threshold 1510 is set to 70 mg/dL, the hypoglycemia user action recommendation may only occur below a glucose concentration of 107.5 mg/dL (see 1508). These thresholds can be utilized by assessing the maximum action that can be taken by an automated insulin delivery algorithm in response to changes in the user's glucose concentrations. For instance, given the safety constraints, the algorithm can suspend insulin delivery as the user's glucose concentration is reduced. In this example, this suspension by the algorithm can occur over one hour.

Typical heuristic rules of thumb can be utilized to determine the impact of basal insulin delivery on the user's glucose concentrations. In standard cases, 50% of the user's total daily insulin (TDI) needs can be assumed to cover the user's basal needs (b), with the other 50% covering the user's bolusing needs. The resulting value shows the basal needs throughout the day, which can be converted to the basal needs per hour by dividing this quantity by the number of hours per day. This value can be related to the heuristic rules of thumb for assessing the user's correction factor (CF), or mg/dL change per U of insulin, which is also based on the TDI. Thus, the value of the TDI is canceled, and regardless of the value of the TDI, the implication is that one hour of insulin delivery equivalent to the user's basal results in a change in user's glucose concentration of 37.5 mg/dL. This can be found in the equation below.

$b*CF=\frac{\mathrm{TDI}}{48}*\frac{1800}{\mathrm{TDI}}=\frac{1800}{48}=37.5$

Consequently, insulin suspension by the algorithm for one hour can compensate for 37.5 mg/dL of glucose drop; therefore, recommendation for user action may only need to occur if a drop that cannot be compensated by insulin suspension will result in user's glucose reaching hypoglycemic risk, meaning a value that is 37.5 mg/dL higher than the standard hypoglycemic threshold of 70 mg/dL, or 107.5 mg/dL.

Similarly, an automated insulin delivery algorithm may request at most a certain amount of the user's basal profile for one hour, one embodiment this being 4 times the user's basal profile for one hour. This means that a recommendation for user action may only need to occur if there is a glucose increase that cannot be compensated by insulin increase by the algorithm. As a result, a value that is greater than the hyperglycemic threshold of 180 mg/dL by 4 times the standard quantity of impact of increased basal, or 4 times 37.5 mg/dL (150 mg/dL) higher than 180 mg/dL, may be the threshold in this embodiment. In this example, the value of the threshold would thus be 330 mg/dL.

The values that are recommended in this example can vary across a wide range. For instance, the 50% assumption of TDI basal-bolus split can be modified into 25%, or 75%, based on the expected patterns of user activity. Moreover, the duration of assumed insulin action by the algorithm can be modified from 1 hour to 30 minutes (initial delay before insulin generally begins to take action), or 90 minutes (general insulin peak action time).

In another alternative exemplary embodiment, the clinical decision support algorithm defines the thresholds of action differently. The quantity of remaining insulin action may be specified differently than the IOB, such as by utilizing actual insulin delivery histories. The expected limits of insulin delivery by the automated system can also be assessed differently, such as by running a significant amount of simulations and assessing a reasonable maximum and minimum limits of the algorithm delivery over 1 hour.

In another alternative embodiment, the clinical decision support algorithm can incorporate more predictions of future glucose trends based on utilization of a model of insulin-glucose dynamics, and alert the users if glucose concentration values are actually predicted to remain above target or below the hypoglycemic thresholds.

While the present invention has been described with reference to exemplary embodiments herein, it should be appreciated that various changes in form and detail may be made without departing from the intended scope of the present invention as defined in the appended claims.

Claims

1. A device, comprising: a communication interface with a glucose monitor for enabling glucose level readings of a user from the glucose monitor to be communicated to the device;a storage for storing insulin delivery history and/or glucagon delivery history to the user and a carbohydrate ingestion history of the user;a delivery device interface with a delivery device for delivery of the insulin and/or glucagon to the user; andprocessing logic for: determining a required insulin on board (IOB) of the user to reach a target glucose level of the user given a current glucose level of the user;determining a current IOB of the user;calculating a difference between the required IOB of the user to reach the target glucose level and the current IOB of the user;where the difference is positive, determining a limit of device compensation as a maximum automated insulin action that may result from automated insulin deliveries by the device in a period in view of constraints;determining whether the limit of device compensation is enough to reach the target glucose level of the user given the current glucose level and the current IOB of the user;where it is determined that the limit of device compensation is not enough to reach the target glucose level of the user, determining a hyperglycemic action threshold as a sum of the hyperglycemic threshold and a maximum amount of a glucose level of the user that can be compensated by the device in a time period in view of the limit of device compensation for the time period,comparing the current glucose level of the user to the hyperglycemic action threshold; andwhere the current glucose level of the user is greater than the hyperglycemic action threshold, triggering a preventive measure to reduce the glucose level of the user.

2. The device of claim 1, wherein the device further comprises a video display and the preventive measure comprises output displayed on the video display.

3. The device of claim 1, wherein the device further comprises an audio output device and the preventive measure comprises audio output that is output via the audio output device.

4. The device of claim 1, wherein the device, in addition to generating an alert as part of the preventive measure alert, causes delivery of a bolus of insulin to the user from the delivery device as part of the preventive measure.

5. The device of claim 1, wherein the triggered preventive measure is delivery of a bolus of insulin from the delivery device.

6. The device of claim 1, wherein the processing logic comprises one of a microprocessor, a field gate programmable array (FPGA), an application specific integrated circuit (ASIC) or a controller integrated circuit.

7. A method performed by processing logic of a device, the method comprising: receiving a glucose monitor reading of a current glucose level of a user;determining a required insulin on board (IOB) of the user to reach a hypoglycemic glucose level of the user given a current glucose level of the user;determining a current IOB of the user;calculating a difference between the current IOB of the user and the required IOB of the user to reach the hypoglycemic glucose level;where the difference is positive, determining a limit of device compensation as a minimum automated insulin action that may result from suspension of automated insulin deliveries by the device in a period and/or automated glucagon deliveries by the device;determining whether the limit of device compensation is enough to prevent the glucose level of the user from reaching the hypoglycemic glucose level given the current glucose level of the user and the current IOB of the user;where it is determined that the limit of device compensation is not enough to prevent the glucose level of the user from reaching the hypoglycemic glucose level, determining a hypoglycemic action threshold as a sum of the hypoglycemic glucose level and a maximum amount of glucose level decrease that can be compensated for by insulin delivery suspension and/or automated glucagon delivery by the device over the time period;comparing the current glucose level of the user to the hypoglycemic action threshold; andwhere the current glucose level of the user falls below the hypoglycemic action threshold, triggering an action to increase the glucose level of the user.

8. The method of claim 7, wherein the action comprises, with the device, causing the delivery of a bolus of glucagon to the user by the device and/or generating an alert that hypoglycemia may occur.

9. The method of claim 7, wherein the processing logic implements a closed loop control system for regulating delivery of glucagon to the user.

10. A non-transitory computer-readable storage media storing instructions that cause a processor to: receive a glucose monitor reading of a glucose level of a user;determine a required insulin on board (IOB) of the user to reach a hypoglycemic glucose level of the user given a current glucose level of the user;determine a current IOB of the user;calculate a difference between the current IOB of the user and the required IOB of the user to reach the hypoglycemic glucose level;where the difference is positive, determine a limit of device compensation as a minimum automated insulin action that may result from suspension of automated insulin deliveries by the device in a period and/or automated glucagon deliveries by the device;determine whether the limit of device compensation is enough to prevent the glucose level of the user from reaching the hypoglycemic glucose level given the current glucose level and the current IOB of the user;where it is determined that the limit of device compensation is not enough to prevent the glucose level of the user from reaching the hypoglycemic glucose level, determine a hypoglycemic action threshold as a sum of the hypoglycemic glucose level and a maximum amount of glucose level decrease that can be compensated for by insulin delivery suspension and/or automated glucagon delivery by the device over the time period;compare the current glucose level of the user to the hypoglycemic action threshold; andwhere the current glucose level of the user falls below the hypoglycemic action threshold, trigger an action to increase the glucose level of the user.

11. The non-transitory computer-readable storage media of claim 10, wherein the action comprises, with the device, causing the delivery of a bolus of glucagon to the user by a delivery device and/or generating an alert that hypoglycemia may occur.

12. The non-transitory computer-readable storage media claim 10, wherein the processor implements a closed loop control system for regulating delivery of glucagon to the user.