Safety constraints for control algorithm-based drug delivery systems

Abstract

Providing safety constraints for control algorithm-based drug delivery systems. [Solution] Disclosed are systems, methods, and computer-readable media products that provide safety constraints for insulin delivery management programs. Various embodiments provide safety constraints for a control-algorithm-based drug delivery system that provides automatic delivery of drugs based on sensor input. Glucose measurements may be received from a sensor at regular time intervals. A processor may predict future glucose values ​​based on previous glucose measurements. The safety constraints aid in safe operation of the drug delivery system during various operating scenarios. In some embodiments, the predicted future glucose values ​​may be used to implement safety constraints that mitigate under- or over-delivery of drugs without unduly burdening the user of the drug delivery system and without sacrificing drug delivery system performance. Other safety constraints are also disclosed.

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. Provisional Patent Application No. 62 / 667,118, filed May 4, 2018, the entire contents of which are incorporated herein by reference.

[0002] (Technical field) The described embodiments provide automatic delivery of medication based on sensor input and provide safety constraints for the medication delivery system to ensure that the user does not over-deliver or under-deliver the medication that is automatically provided based on a control algorithm. [Background technology]

[0003] (background) Medication delivery systems typically deliver medication to a user based on the user's health condition. For example, a control algorithm-based drug delivery system can monitor the user's glucose level, determine an appropriate level of medication, such as insulin, for the user based on the monitored medical condition, such as the glucose level, and subsequently dispense the medication to the user. The control algorithms used in control algorithm-based drug delivery systems and other drug delivery systems generally rely on data provided by the user, such as insulin delivery amount and user data provided, and / or expected glucose and medication levels determined by different means. However, the data provided or expected levels may be incorrect or erroneous, which can lead to incorrect medication dosages and incorrect medication delivery schedules. Data and measurement errors can occur due to many different reasons, such as user confusion (e.g., having an incorrect time, entering an incorrect number, or the like), glucose sensor drift or bias (which can be due to many different factors related to the glucose sensor), errors in the medication delivery system, or the like. As a result, conventional medication delivery systems do not provide safety constraints that allow automated medication delivery systems to respond to incorrect data and measurement errors. Therefore, a need exists for a drug delivery system, such as an insulin management system, that includes such features as safety constraints, alerts, and corrective actions. Summary of the Invention [Means for solving the problem]

[0004] (summary) What is disclosed is a non-transitory computer readable medium embodied with programming code executable by a processor. The processor, upon execution of the programming code, is operable to perform functions including a function for receiving glucose measurements at regular time intervals via a wireless connection with a glucose monitor. The glucose measurements are performed by the glucose monitor. Future glucose values ​​may be predicted based on previous glucose measurements. An insulin basal delivery rate (insulin basal delivery rate) may be calculated based on the glucose measurements. The basal insulin delivery rate may be adjusted to be provided by the medical device based on the predicted future glucose values. Insulin may be delivered via the medical device according to the adjusted basal insulin delivery rate.

[0005] Disclosed is a method implemented by a processor coupled to a glucose monitor via a wireless connection. The method includes receiving, by the processor, a number of glucose measurements from the glucose monitor. Each glucose measurement of the number of glucose measurements is received at a regular time interval over a period of time, the regular time interval being less than the period of time. A number of future glucose measurements may be predicted using at least one of the number of received glucose measurements. It may be determined that a subsequent glucose measurement has not been received within a next regular time interval. In response to determining that a subsequent glucose measurement has not arrived, a daily total insulin-based basal delivery rate may be adjusted to be provided by the medical device based on at least one of the number of predicted future glucose measurements. Insulin may be delivered via the medical device according to the adjusted daily total insulin-based basal delivery rate.

[0006] Disclosed is another method in which a processor coupled to a medical device determines that the medical device is delivering more than a preset volume of insulin over a set amount of time. The preset volume of insulin is based on one or more of a user input basal rate, a rate calculated by an artificial pancreas algorithm using an average daily delivery rate, a rate based on a user weight and / or a user age, a total daily amount of insulin delivered, or a total daily basal amount delivered. In response to the determination, an amount of insulin to be delivered by the medical device as an adjusted basal dosage is adjusted based on a calculation using the volume of insulin delivered over the set amount of time and the total daily amount of insulin to be delivered as calculated by the artificial pancreas algorithm.

[0007] Disclosed is a system including a medical device, a sensor, and a management device. The medical device includes a pump, a reservoir configured to contain insulin, a processor, and a transceiver, and the medical device is operable to deliver insulin in response to an output from the processor. The sensor may include a transmitter, a processor, and a cannula. The sensor is operable to measure blood glucose and output a blood glucose value. The management device may include a processor, a memory configured to store an artificial pancreas algorithm, and a transceiver. The artificial pancreas algorithm is operable to determine the number and dosage of insulin to be delivered to a user, the time and dosage may be calculated based on the user's gender, the user's age, the user's weight, the user's height, and / or the glucose level provided by the sensor. The processor of the management device is operable to determine the occurrence of a hypoglycemic event in response to execution of the artificial pancreas algorithm. In response to determining the occurrence of a hypoglycemic event, a glucose rate of change filter may be implemented for a predetermined period of time. The rate of change filter limits the rate of change in the measured blood glucose levels used by the artificial pancreas algorithm in determining the time for delivery of insulin and the dosage of insulin being delivered. The processor commands the medical device to deliver the determined dosage of insulin at the determined time for delivery.

[0008] Further disclosed is another method including determining, by a processor of the medical management device, in response to receiving a glucose measurement from the sensor, that the medical device has delivered insulin below a fixed personalized basal rate for a period of insulin delivery history. A consequence of delivering insulin below the fixed personalized basal rate is a negative insulin on board value. The processor may determine that the negative insulin remaining value is greater than three times the user's total daily insulin-based hourly basal value. In response to the negative insulin remaining value being greater than several times the user's total daily insulin-based hourly basal value, the delivery of insulin by the medical device may be modified to deliver a total daily basal amount or a personalized volume of insulin. A notification message may be output to request the user to acknowledge the modified delivered amount of insulin or a requirement for a new calibration value for use by the processor in calculating a calibrated amount of insulin for delivery.

[0009] Disclosed is another example of a non-transitory computer readable medium embodied with programming code executable by a processor. The processor, upon execution of the programming code, is operable to perform functions including a function for obtaining a series of glucose concentration values ​​as measured at regular time intervals by a glucose monitor. The processor may detect a rapid rate of increase in the glucose concentration. In response to detecting a rapid rate of increase in the glucose concentration, the processor may implement a response to the rapid rate of increase in the glucose concentration.

[0010] Also disclosed is an example of another method in which a processor coupled to a glucose sensor determines that insulin delivery is not declining at a suitable rate to recover from a hypoglycemic event. In response to the determination, the likelihood of insulin suspension may be increased by either reducing a penalty of a projected outcome within the artificial pancreas algorithm such that the required insulin delivery rate is below a user-inputted basal delivery rate, or by scaling deviations in insulin delivery rate below the user-inputted basal delivery rate to be proportional to the user-inputted basal delivery rate.

[0011] Further examples of methods are also disclosed in which a processor coupled to a glucose sensor determines that insulin delivery is not declining at a suitable rate to maintain glucose concentrations during exercise or other activities that may induce an increased risk of hypoglycemia. In response to the determination, either the control target glucose value may be increased to a glucose value higher than the current target glucose value, or the input basal delivery may be reduced to an input basal value lower than the current input basal value. The present specification also provides, for example, the following items: (Item 1) A non-transitory computer readable medium having embodied therein programming code executable by a processor, the programming code, when executed by the processor, receiving, at regular time intervals, values ​​of glucose measurements made by a glucose monitor; predicting future glucose values ​​based on previous glucose measurements; adjusting a basal insulin delivery rate to be provided by a medical device based on the predicted future glucose values; delivering insulin via said medical device in accordance with said adjusted basal insulin delivery rate; 23. A non-transitory computer readable medium operable to perform functions including functions for performing the steps of: (Item 2) When the programming code is executed by the processor, the processor further: receiving a subsequent glucose measurement via a wireless connection with the glucose monitor; determining a daily total insulin-based basal glucose level using the received subsequent glucose measurements and previous glucose values ​​from a past time period; comparing said daily total insulin based basal glucose level to a user set basal glucose set point; determining an updated basal insulin delivery rate to be delivered by the medical device in response to a result of the comparison indicating that the user-set basal glucose set point is erroneous, the updated basal insulin delivery rate being updated from the adjusted basal insulin delivery rate; 2. The non-transitory computer-readable medium of claim 1, which performs functions to perform the steps of: (Item 3) When the programming code is executed by the processor, the processor further: receiving one or more glucose measurements from the glucose monitor; Receiving a user input reference calibration value; identifying a discrepancy between one or more glucose measurements from the glucose monitor and the user-input reference calibration value; modifying the adjusted basal insulin delivery rate based on the identified difference; and 2. The non-transitory computer-readable medium of claim 1, which performs functions to perform the steps of: (Item 4) When the programming code is executed by the processor, the processor further comprises: prior to modifying the adjusted basal insulin delivery rate based on the identified discrepancy: calibrating the glucose monitor based on the identified discrepancy; and determining that the identified difference is a positive step change in the amount of insulin being delivered; obtaining a current new blood glucose measurement from the calibrated glucose monitor in response to the identified difference being a positive step change; modifying the adjusted basal insulin delivery rate based on the identified discrepancy using the current new blood glucose measurement; 4. The non-transitory computer-readable medium of claim 3, which performs functions to perform the steps of: (Item 5) 5. The non-transitory computer readable medium of item 4, wherein the positive step change is an increase in the amount of insulin delivered. (Item 6) When the programming code is executed by the processor, the processor further comprises: prior to modifying the adjusted basal insulin delivery rate based on the identified discrepancy: calibrating the glucose monitor based on the identified discrepancy; and determining that the identified difference is a negative step change; in response to the identified difference being a negative step change, providing instructions to suspend delivery of insulin for a predetermined amount of time. 4. The non-transitory computer-readable medium of claim 3, which performs functions to perform the steps of: (Item 7) 7. The non-transitory computer readable medium of item 6, wherein the negative step change is a decrease in the amount of insulin delivered. (Item 8) When the programming code is executed by the processor, the processor further: determining that a hypoglycemic event is occurring based on measurements provided by the glucose monitor; modifying said adjusted basal insulin delivery rate in response to determining that a hypoglycemic event is occurring. 2. The non-transitory computer-readable medium of claim 1, which performs functions to perform the steps of: (Item 9) When the programming code is executed by the processor, the processor further comprises: when modifying the adjusted basal insulin delivery rate in response to determining that a hypoglycemic event is occurring: setting a reduced temporary basal delivery rate of the medical device for use in dosing calculations for a predetermined period of time following the determination of the occurrence of the hypoglycemic event. 9. The non-transitory computer-readable medium of claim 8, which performs functions to perform the steps of: (Item 10) When the programming code is executed by the processor, the processor further comprises: when modifying the adjusted basal insulin delivery rate in response to determining that a hypoglycemic event is occurring: Following the determination of the occurrence of the hypoglycemic event, setting a reduced temporary basal delivery rate of the medical device for use in dosing calculations until the rate of change of blood glucose level decreases below a predetermined threshold. 9. The non-transitory computer-readable medium of claim 8, which performs functions to perform the steps of: (Item 11) When the programming code is executed by the processor, the processor further comprises: when modifying the adjusted basal insulin delivery rate in response to determining that a hypoglycemic event is occurring: Following the determination of the occurrence of the hypoglycemic event, setting a reduced temporary basal delivery rate of the medical device for use in dosing calculations until the blood glucose level exceeds a predetermined threshold. 9. The non-transitory computer-readable medium of claim 8, which performs functions to perform the steps of: (Item 12) 1. A method implemented by a processor coupled to a glucose monitor via a wireless connection, the method comprising: receiving, by the processor, a number of glucose measurements from the glucose monitor, each glucose measurement of the number of glucose measurements being received at regular time intervals over a period of time, the regular time intervals being less than the period of time; predicting a number of future glucose measurements using at least one of the number of glucose measurements; and determining that a subsequent glucose measurement has not been received within a next regular time interval; responsive to determining that the subsequent glucose measurement has not arrived, adjusting a total daily insulin-based basal delivery rate to be provided by the medical device based on at least one of the predicted number of future glucose measurements; delivering insulin via said medical device in accordance with said adjusted total daily insulin based basal delivery rate; A method comprising: (Item 13) 13. The method of claim 12, wherein the insulin is delivered via the medical device over a trusted, predicted period of time according to the adjusted total daily insulin based basal delivery rate. (Item 14) determining that insulin delivery should be suspended in response to a last received glucose measurement being within a specified range of a previous glucose measurement and the trusted prediction period spanning a duration corresponding to a predetermined number of regular time intervals; selecting a time period for suspending delivery of the insulin from a plurality of pre-defined time periods based on the value of the last received glucose measurement falling within a particular range of a plurality of ranges of glucose measurements; suspending delivery of insulin for said selected period of time; Item 14. The method of item 13, further comprising: (Item 15) 1. A method comprising: determining, by a processor coupled to a medical device, that the medical device is delivering more than a preset volume of insulin for a set amount of time, the preset volume of insulin being based on one or more of a user input basal rate, a rate calculated by an artificial pancreas algorithm using an average daily delivery rate, a rate based on a user weight and / or a user age, a total daily amount of insulin delivered, or a total daily basal amount delivered; in response to said determining, adjusting an amount of insulin to be delivered by said medical device as an adjusted basal dosage based on a calculation using the volume of insulin delivered over said set amount of time and a total daily amount of insulin to be delivered as calculated by an artificial pancreas algorithm; limiting the amount of insulin to be delivered as the adjusted basal dosage to a maximum volume of the user's basal insulin delivery volume divided by either the time increment over which the adjusted basal dosage is administered or the percentage of the basal rate per hour, the time increment being less than one hour; A method comprising: (Item 16) Item 16. The method of item 15, further comprising receiving glucose measurements from the glucose sensor at regular time intervals. (Item 17) 1. A system comprising: a medical device comprising a pump, a reservoir configured to contain insulin, a processor, and a transceiver, the medical device operable to deliver insulin in response to an output from the processor; a sensor comprising a transmitter, a processor, and a cannula, the sensor operable to measure blood glucose and output a blood glucose level; 1. A management device, the management device comprising: a management device processor; a management device memory configured to store programming instructions including an artificial pancreas algorithm; and a management device transceiver, the management device processor, in response to execution of the programming instructions including the artificial pancreas algorithm, Determining the occurrence of a hypoglycemic event; Implementing a glucose change rate filter over a predetermined time period in response to determining the occurrence of the hypoglycemic event, the glucose change rate filter limiting a rate of change in measured blood glucose values ​​used by the artificial pancreas algorithm in determining a time for delivery of insulin and a dosage of insulin to be delivered; instructing the medical device to deliver the determined dosage of insulin at a determined time for delivery; a management device operable to A system comprising: (Item 18) The processor of the management device further, in response to executing the artificial pancreas algorithm, the first time the measured glucose value falls below a predetermined threshold associated with said hypoglycemic event; when the measured glucose value exceeds another predetermined threshold value after the occurrence of the hypoglycemic event; until the glucose rate of change is decreased below a further predetermined threshold, or Until the glucose exceeds an additional predetermined threshold. 20. The system of claim 17, wherein the system is operable to limit a duration for implementation of the glucose change rate filter by applying one or more limitations from: (Item 19) 20. The system of claim 17, wherein the management device processor applies the glucose change rate filter at one of all times, when both positive and negative glucose change rates are determined, or when only positive glucose change rates are determined, in response to execution of the artificial pancreas algorithm. (Item 20) The processor of the management device further, in response to executing the artificial pancreas algorithm, Determining the frequency and dosage of insulin to be delivered to the user 20. The system of claim 17, wherein the time and the dosage are calculated based on a user's gender, a user's age, a user's weight, a user's height, and / or a glucose level provided by the sensor. (Item 21) The processor of the management device further, in response to executing the artificial pancreas algorithm, changing from a closed loop to an open loop mode of operation; constraining maximum insulin delivery according to a basal delivery rate personalized for the user for a set period of time or until the event ends after detection of an event, said event being different from said hypoglycemic event; delivering a set personalized basal rate for a set period of time after detection of said hypoglycemic event or until said hypoglycemic event ends; limiting the rate of change as used by the processor for a set period of time after detection of the event, or until the event has ended; or The glucose change rate filter is applied at all times or following a hypoglycemic event to limit the response by the artificial pancreas algorithm. 20. The system of claim 17, operable to implement one of the following: (Item 22) The processor of the management device further, in response to executing the artificial pancreas algorithm, responsive to initiation of closed-loop operation of the artificial pancreas algorithm, determining that sufficient glucose history is not available for use by the artificial pancreas algorithm; In response to determining that sufficient glucose history is not available, limiting the maximum delivery of insulin to a predetermined value for a set amount of time; or and requesting a user response to a query as to whether a non-basal insulin dose was delivered within the previous duration. and 20. The system of claim 17, wherein the system is operable to: (Item 23) The processor of the management device further, in response to executing the artificial pancreas algorithm, responsive to initiation of closed-loop operation of the artificial pancreas algorithm, determining that sufficient glucose history is not available for use by the artificial pancreas algorithm; in response to determining that sufficient glucose history is not available, requesting a user input to provide to the managing device an amount of insulin to be delivered by the medical device; in response to receiving an amount of insulin delivered in response to the request, calculating a remaining amount of insulin for the user based on the amount of insulin delivered; determining, when the calculated user's insulin remaining amount falls below a predetermined threshold, to utilize the user's personalized insulin decay curve using the calculated user's insulin remaining amount; 20. The system of claim 17, wherein the system is operable to: (Item 24) 1. A method comprising: determining, by a processor of the medical management device, in response to receiving a glucose measurement from the sensor, that the medical device has delivered insulin below a fixed personalized basal rate for a period of insulin delivery history, where a consequence of delivering insulin below the fixed personalized basal rate is a negative insulin remaining value; determining that the negative insulin residual value is greater than a multiple of the user's hourly basal value of their total daily insulin base; modifying delivery of insulin by the medical device to deliver a total basal amount or a personalized volume of insulin on a daily basis in response to the negative insulin residual value being greater than several times the user's hourly basal total daily insulin basis; outputting a notification message requesting a user to either acknowledge the altered delivery amount of insulin or request a new calibration value for use by the processor in calculating a calibrated amount of insulin for delivery; A method comprising: (Item 25) in response to receiving a user acknowledgement of the modified delivery amount of insulin. 25. The method of claim 24, further comprising continuing the altered delivery of insulin. (Item 26) generating, by the processor, the new calibration value in response to receiving the request for the new calibration value; applying, by the processor, the new calibration value and calculating the calibrated amount of insulin for delivery; 25. The method of claim 24, further comprising: (Item 27) A non-transitory computer readable medium having embodied therein programming code executable by a processor, the programming code, when executed by the processor, obtaining a series of glucose concentration values ​​as measured at regular time intervals by a glucose monitor; detecting a rapid rate of increase in glucose concentration; responsive to detecting a rapid rate of increase in said glucose concentration, implementing a response to said rapid rate of increase in said glucose concentration; 23. A non-transitory computer readable medium operable to perform functions for performing the steps of: (Item 28) the rapid rate of increase in glucose concentration exceeds a certain threshold, the rapid rate of increase of the glucose concentration across a series of glucose concentration values, a first value in the series of glucose concentration values ​​being below a first threshold; the rapid rate of increase of the glucose concentration traverses a range of glucose concentration values, any value in the range being below a second threshold; and / or The rate of increase is determined from a second derivative of the glucose concentration above a threshold. Item 28. The non-transitory computer-readable medium of item 27. (Item 29) When the processor, in response to executing the programming code, implements a response to a rapid rate of increase in the glucose concentration, limiting the recommended delivery amount to a user-personalized maximum delivery amount for a defined duration following a hypoglycemic event; limiting the recommended delivery rate to a maximum delivery rate personalized to said user after a hypoglycemic event until the rate of change decreases below a predetermined threshold; limiting the recommended delivery rate to a maximum delivery rate personalized to the user after a hypoglycemic event until the glucose concentration exceeds a predetermined threshold; or Combinations of these 28. The non-transitory computer-readable medium of claim 27, operable to perform functions for carrying out the steps of: (Item 30) When the processor, in response to executing the programming code, implements a response to a rapid rate of increase in the glucose concentration, reducing a gain, an artificial pancreas algorithm cost function, and / or aggressiveness of an artificial pancreas algorithm executed by said processor to limit the amount of insulin delivered: i.) for a predetermined period of time following a hypoglycemic event; ii.) until said glucose concentration is above a predetermined threshold following a hypoglycemic event; iii.) until said rate of change decreases below a predetermined threshold following a hypoglycemic event; or iv.) any combination of i.), ii.), or iii.). and operable to perform functions for the gain of the artificial pancreas algorithm being an indication of the user's glucose change per unit of insulin as applied in response to execution of the artificial pancreas algorithm; the cost function being a measure related to deviations in the measured and expected glucose and / or deviations in expected and basal insulin amounts; Aggressiveness relates to the responsiveness of the artificial pancreas algorithm to deviations in the cost function; Item 28. The non-transitory computer-readable medium of item 27. (Item 31) When the processor, in response to executing the programming code, implements a response to a rapid rate of increase in the glucose concentration, Implementing a glucose rate of change filter for a predetermined period of time following a hypoglycemic event. 30. The non-transitory computer readable medium of claim 27, wherein the glucose change rate filter is operable to limit the glucose change rate provided to the artificial pancreas algorithm. (Item 32) The glucose change rate filter may include, following a hypoglycemic event: until the rate of change decreases below a predetermined threshold. until the glucose concentration exceeds a predetermined threshold. across both positive and negative rates of change or only positive rates of change, or In any combination thereof 32. The non-transitory computer-readable medium of item 31 implemented therein. (Item 33) Item 32. The non-transitory computer readable medium of item 31, wherein the glucose change rate filter is implemented at all times following a hypoglycemic event. (Item 34) When the processor, in response to executing the programming code, implements a response to a rapid rate of increase in the glucose concentration, setting a reduced target blood glucose level for a predetermined period of time following a hypoglycemic event that can be used for medication calculations; setting a reduced target blood glucose level that can be used for dosing calculations until the glucose rate of change decreases below a predetermined threshold after a hypoglycemic event; setting a reduced target blood glucose level that can be used for dosing calculations until said glucose exceeds a predetermined threshold; or Setting reduced target blood glucose levels for any combination thereof 28. The non-transitory computer-readable medium of claim 27, operable to perform functions for carrying out the steps of: (Item 35) 1. A method comprising: determining, by a processor coupled to the glucose sensor, that insulin delivery is not declining at a suitable rate to recover from the hypoglycemic event; In response to said determination, Reducing the estimated outcome penalty within the artificial pancreas algorithm so that the required insulin delivery rate is below the user-inputted basal delivery rate; or Scaling deviations in insulin delivery rate below the user-input basal delivery rate to be proportional to the user-input basal delivery rate. Increase the likelihood of insulin suspension by either A method comprising: (Item 36) 1. A method comprising: determining, by a processor coupled to the glucose sensor, that insulin delivery is not declining at a suitable rate to maintain glucose concentrations during exercise or other activity that may induce an increased risk of hypoglycemia; In response to said determination, modifying the control target glucose value by increasing said control target glucose value to a glucose value higher than the current target glucose value; or modifying the input basal delivery rate by reducing the input basal delivery rate to an input basal value that is lower than the current input basal value. and In response to said modification, insulin delivery is reduced at a faster rate to maintain glucose levels. A method comprising: [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 illustrates an example of a drug delivery system operable to implement the techniques and processes described herein.

[0013] [Diagram 2] FIG. 2 illustrates an example of a fixed insulin delivery rate for a user that is approximately limited to the user's TDI-based insulin amount.

[0014] [Diagram 3] FIG. 3 illustrates an example of adjusting a predicted trajectory based on new glucose measurements.

[0015] [Figure 4] FIG. 4 illustrates an example of the effect of a rate of change filter on blood glucose predictions made by an example artificial pancreas algorithm that is intended to be below the estimated trajectory of future blood glucose levels.

[0016] [Diagram 5] FIG. 5 illustrates an example of constraining maximum insulin delivery.

[0017] [Figure 6] FIG. 6 illustrates an example of constraining insulin delivery to no more than a fixed insulin rate when glucose levels fall below a certain threshold.

[0018] [Figure 7A] FIG. 7A shows a flow chart of a process for adjusting basal insulin delivery using predicted future glucose values, according to embodiments described herein.

[0019] [Figure 7B] FIG. 7B illustrates a flow chart of a process for implementing an embodiment of a safety constraint in response to a communication problem in a drug delivery system, such as the exemplary drug delivery system shown in FIG.

[0020] [Figure 8] FIG. 8 shows a flow chart of an example process for implementing an example safety constraint in response to over-delivery of insulin.

[0021] [Figure 9] FIG. 9 shows a flow chart of an example process for implementing an example safety constraint in response to under-delivery of insulin.

[0022] [Figure 10] FIG. 10 shows a flow chart of an example process for implementing an example response to a fast rate of increase in glucose concentration.

[0023] [Figure 11] FIG. 11 shows a flow chart of an example process for implementing an example response that increases the likelihood of insulin suspension.

[0024] [Figure 12] FIG. 12 shows a flow chart of an example process for implementing an example response to attenuate insulin delivery. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0025] (Detailed Description) Various embodiments provide safety constraints for an "artificial pancreas" algorithm-based system, also more generally referred to as an artificial pancreas algorithm, a control algorithm-based drug delivery system that provides automatic delivery of drugs based on sensor input. For example, an artificial pancreas (AP) algorithm, when executed by a processor, enables the system to monitor a user's glucose level, determine an appropriate level of insulin for the user based on the monitored glucose level (e.g., glucose concentration or glucose measurement) and other information, such as user-provided information, and subsequently dispense insulin to the user. In addition, the AP algorithm utilizes the monitored glucose level and other information to generate, send, and control commands to a medical device, such as a pump, to deliver a bolus dose of insulin to the user, vary the amount or timing of future doses, or perform other controllable functions. The safety constraints described herein provide for safe operation of the drug delivery system during various operating scenarios, including, for example, when sensor input is missing or erroneous, during unexpected events such as unplanned meals, etc. The disclosed safety constraints mitigate under- or over-delivery of drug without unduly burdening the user of the drug delivery system and without sacrificing the performance of the drug delivery system.

[0026] FIG. 1 illustrates an example of a drug delivery system 100. The drug delivery system 100 can include a medical device 102, a sensor 104, and a management device (PDM) 106. In various examples, the drug delivery system 100 can be an automated drug delivery system. In various examples, the medical device 102 can be attached to a user or patient's body and can deliver any therapeutic agent, including any drug or medication, such as insulin or the like, to the user. For example, the medical device 102 can be a wearable device. For example, the medical device 102 can be directly coupled to a user (e.g., directly attached to a body part and / or skin of the user). For example, a surface of the medical device 102 can include an adhesive to facilitate attachment to the user.

[0027] The medical device 102 can include several components to facilitate automated delivery of medication (also referred to as therapeutic agents) to a user. The medical device 102 can store and provide any medication or drug to the user. In various examples, the medical device 102 can be an automated wearable insulin delivery device. For example, the medical device 102 can include a reservoir 125 for storing the medication (such as insulin), a needle or cannula for delivering the medication into the user's body, and a pump mechanism 124 or other drive mechanism for transferring the medication from the reservoir 125 through the needle or cannula (not shown) into the user's body. The medical device 102 can also include a power source 128, such as a battery, for providing power to the pump mechanism 124 and / or other components of the medical device 102 (such as the processor 121, memory 123, and communication device 126). The medical device 102 is often referred to as a pump or insulin pump, referring to the act of expelling the medication from the reservoir 125 for delivery to the user. Reservoir 125 may be configured to store insulin, morphine, or another drug suitable for automated delivery.

[0028] The medical device 102 can provide the stored therapeutic agent to the user based on information provided by the sensor 104 and / or the managing device (PDM) 106. For example, the medical device 102 can also contain analog and / or digital circuitry that can be implemented as a processor 121 (or controller) for controlling delivery of the medication. The circuitry may be used to implement the processor 121 and may include discrete special logic and / or components, application specific integrated circuits, microcontrollers or processors that execute software instructions, firmware, programming instructions (such as the artificial pancreas algorithm 129) stored in a memory device (such as the memory 123), or any combination thereof. In various embodiments, the processor 161 can be configured to cause the pump to deliver doses of the medication to the user at predetermined intervals. For example, the processor 161 may execute a control algorithm such as the artificial pancreas algorithm (AP algorithm) 169. The size and / or timing of the dose may be programmed into the artificial pancreas algorithm 169, for example, by the user or by a third party (such as a medical professional, medical device manufacturer, or the like), using a wired or wireless link.

[0029] Instructions for determining delivery of the medication to the user (e.g., size and / or timing of any dose of medication) may occur locally (e.g., based on programming instructions, such as the instance of the artificial pancreas algorithm 129, stored in memory 123 coupled to the medical device 102 used by the medical device 102 to make the decision) or may occur remotely and be provided to the medical device 102. The remote instructions can be provided to the medical device 102 via a wired or wireless link by an electronic device (PDM) 106, which executes the artificial pancreas algorithm 169. The medical device 102 can execute any received instructions (originating internally or from the management device 106 for delivery of the medication to the user). Thus, under either scenario, delivery of the medication to the user can be automated.

[0030] In various examples, the medical device 102 can communicate with the management device 106 via a wireless link 110. The management device 106 can be any electronic device, such as, for example, an Apple Watch. The management device 106 can be a wearable wireless accessory device. The wireless links 108, 110, and 112 can be any type of wireless link provided by any known wireless standard. As an example, the wireless links 108, 110, and 112 can enable communication between the medical device 102, the management device 106, and the sensor 104 based on Bluetooth, Wi-Fi, a short-range communication standard, a cellular standard, or any other wireless optical or radio frequency protocol.

[0031] The sensor 104 may be a glucose sensor operable to measure blood glucose and output data representative of a blood glucose level or blood glucose level. For example, the sensor 104 may be a glucose monitor or a continuous glucose monitor (CGM). The sensor 104 may include a processor 141, a memory 143, a sensing / measuring device 144, and a communication device 146. The communication device 146 of the sensor 104 may include one or more sensing elements, electronic transmitters, receivers, and / or transceivers to communicate with the management device 106 via the wireless link 112 or with the medical device 102 via the link 108. The sensing / measuring device 144 may include one or more sensing elements, such as a glucose measurement, a heart rate monitor, or the like. For example, the sensor 104 can be a continuous glucose monitor (CGM). The processor 141 may include discrete special logic and / or components, application specific integrated circuits, a microcontroller or processor that executes software instructions, firmware, programming instructions stored in a memory device (such as the memory 143), or any combination thereof. For example, the memory 143 may store an instance of the AP algorithm 149 executable by the processor 141. Although the sensor 104 is depicted as separate from the medical device 102, in various embodiments, the sensor 104 and the medical device 102 may be incorporated into the same unit. That is, in various embodiments, the sensor 104 is part of the medical device 102 and can be contained within the same housing of the medical device 102 (e.g., the sensor 104 can be positioned or embedded within the medical device 102). Glucose monitoring data (e.g., measured glucose values) determined by the sensor 104 can be provided to the medical device 102 and / or the management device 106 and can be used to adjust the automated delivery of insulin by the medical device 102. The management device 106 can be a personal diabetes management device.

[0032] The sensor 104 can also be coupled to the user, for example, by adhesive or the like, and can provide information or data regarding one or more medical conditions and / or physical attributes of the user. The information or data provided by the sensor 104 can be used to adjust the drug delivery operation of the medical device 102. The management device 106 can be used to program or adjust the operation of the medical device 102 and / or the sensor 104. The management device 106 can be any portable electronic device including, for example, a processor 161, a dedicated controller such as a smartphone, or a tablet. In an embodiment, the management device (PDM) 106 may include the processor 161, a management device memory 163, and a communication device 164. The management device 106 may contain analog and / or digital circuitry that can be implemented as the processor 161 (or controller) to execute processes for managing the glucose of the user and to control the delivery of medication. The processor 161 may also be operable to execute programming code stored in the management device memory 163. For example, the management device memory 163 may be configured to store an artificial pancreas algorithm 169, which may be executed by the processor 161. The processor 161, when executing the artificial pancreas algorithm 169, may be operable to perform various functions, such as those described with respect to the illustrative embodiment. The communication device 164 may be a receiver, transmitter, or transceiver that operates according to one or more radio frequency protocols.

[0033] The medical device 102 and the sensor 104 may communicate via a wireless link 108. The medical device 102 and the management device 106 may communicate via a wireless link 110. The sensor 104 and the management device 106 may communicate via a wireless link 112. The wireless links 108, 110, and 112 may be any type of wireless link provided by any known wireless standard. As examples, the wireless links 108, 110, and 112 may provide a communication link based on Bluetooth, Wi-Fi, a short-range communication standard, a cellular standard, or any other wireless protocol via the respective communication devices 126, 146, and 164. In some examples, the medical device 102 and / or the management device 106 may include a user interface, such as a keypad, a touch screen display, buttons, a microphone, a speaker, a display, or the like, operable to allow a user to enter information and for the management device to output information for presentation to the user.

[0034] In various embodiments, the drug delivery system 100 can be an insulin drug delivery system. In various embodiments, the medical device 102 can be an OmniPod® (Insulet Corporation, Billerica, Mass.) insulin delivery device, as described in U.S. Patent No. 7,303,549, U.S. Patent No. 7,137,964, or U.S. Patent No. 6,740,059, each of which is incorporated herein by reference in its entirety.

[0035] In various examples, the drug delivery system 100 can implement an artificial pancreas (AP) algorithm (and / or provide AP functionality) to regulate or control automated insulin delivery to a user (e.g., to maintain euglycemia, i.e., normal levels of glucose in the blood). The AP algorithm can be implemented by the medical device 102 and / or the sensor 104. The AP algorithm can be used to determine the number and dosage of insulin deliveries. In various examples, the AP algorithm can determine the number and dosage for delivery based on information known about the user, such as the user's gender, age, weight, or height, and / or information gathered (e.g., from the sensor 104) about the user's physical attributes or condition. For example, the AP algorithm may determine an appropriate delivery amount of insulin based on monitoring the user's glucose level through the sensor 104. The AP algorithm can also enable the user to adjust insulin delivery. For example, the AP algorithm can enable the user to issue commands (e.g., via an input) to the medical device 102, such as a command to deliver an insulin bolus. In some examples, different functions of the AP algorithm may be distributed among two or more of the management device 106, the pump 102, or the sensor 104. In other examples, different functions of the AP algorithm may be implemented by one device, such as the management device 106, the pump 102, or the sensor 104. In various examples, the drug delivery system 100 may operate according to or include any of the features or functionality of the drug delivery system described in U.S. Patent Application No. 15 / 359,187, filed November 22, 2016, which is incorporated herein by reference in its entirety.

[0036] As described herein, the drug delivery system 100 or any component thereof may be considered to provide AP functionality or to implement an AP algorithm. Thus, reference to an AP algorithm (e.g., its functionality, operation, or capability) is made for convenience and may refer to and / or include the operation and / or functionality of the drug delivery system 100 or any constituent components thereof (e.g., the medical device 102 and / or the management device 106). For example, the drug delivery system 100 as an insulin delivery system implementing an AP algorithm may be considered to be a drug delivery system or an AP algorithm-based delivery system that uses sensor input (e.g., data collected by the sensor 104).

[0037] Because the drug delivery system 100 relies on sensor input for proper operation of drug delivery, the drug delivery system 100 may impose delivery limits for safety reasons. Although delivery constraints may be imposed to ensure safe automatic delivery of a drug (e.g., insulin) to a user, in some examples it may be desirable to not have constraints that unduly reduce AP algorithm control performance or that unduly burden the user. The techniques described herein enable the drug delivery system 100 to optimize glucose control performance and minimize any additional burden or inconvenience imposed on the user while maximizing user safety.

[0038] For example, the sensor 104 as a CGM may operate with or otherwise exhibit sensor bias, drift, or other discrepancies in determined data values ​​that may lead to over- or under-delivery of drug to the user. The techniques described herein provide safety constraints for the operation of the drug delivery system 100, including safety mitigations in case of failure of the sensor 104, erroneous values ​​provided by the sensor 104, and / or missing data from the sensor 104 and other risks associated with relying on the sensor 104. The techniques described herein also provide safety constraints specific to higher risk conditions, such as lower glucose values, and the response of the implemented AP algorithm to external perturbations, such as residual carbohydrates or the like.

[0039] The drug delivery system 100 may be, in some examples, a wearable automated drug delivery system including a medical device 102, a sensor 104, and a management device 106. In one example of a wearable automated drug delivery system, the medical device 102 may be a wearable insulin delivery device, the management device 106 may be a handheld electronic computing device, and the sensor 104 may be a continuous glucose monitor. The management device 106 may be a mobile device or a mobile phone, or may be a dedicated custom electronic device. As part of the wearable automated drug delivery system, the medical device 102 and the sensor 104 may each be directly coupled to a user.

[0040] The sensor 104 can provide sensor data to the medical device 102 and / or the management device 106. The management device 106 can include a controller or processor and a memory. The memory can store instructions that can be executed by the controller or processor. The instructions, when executed, can implement an "artificial pancreas" algorithm. In general, the management device 106 can include a controller for determining the amount of insulin to be delivered (e.g., in terms of dosage and frequency) to the user based on data from the sensor 104 and providing corresponding instructions to the medical device 102 regarding the determined delivery of insulin.

[0041] In various embodiments, as described above, the sensor 104 can be provided as part of or embedded within the wearable insulin delivery device 102. Additionally, in various embodiments, as described above, the system 100 can include intermediate wireless devices (e.g., the management device 106) that can wirelessly relay information between the devices depicted in FIG.

[0042] In general, the system 100 can automatically monitor a user's glucose level, automatically determine delivery of insulin to the user based on the monitored glucose level, and automatically provide the determined amount of insulin to the user. Each of these steps can be performed without any user input or interaction. In various embodiments, user confirmation can be required before insulin is provided to the user, as discussed above. For example, when the management device 106 is implemented as a mobile phone, for added security, the user may be required to confirm or acknowledge the delivery of the determined insulin to the user. Failure to receive such confirmation may result in insulin delivery being blocked or prevented. This security feature can mitigate hacking or other cybersecurity risks.

[0043] In various examples, the drug delivery system 100 can be operated such that glucose values ​​are periodically provided by the sensor 104 to an AP algorithm running on a processor (e.g., the medical device 102 and / or the management device 106). For example, the glucose values ​​can be provided periodically, such as, for example, about every 5 minutes (e.g., corresponding to a control cycle of the system 100). The medical device 102 can adjust the amount of insulin for delivery based on the received glucose values.

[0044] It may be useful to briefly describe an example of operations performed by the system 100 with reference to FIG. 7A. The AP algorithm 169 or 129 of FIG. 1 executing on the management device processor 161 or 121 of FIG. 1 may implement the process 700 as shown in FIG. 7A. At 710, the AP algorithm may receive glucose measurements via a wireless connection (e.g., 108 or 112) with a glucose monitor (such as the sensor 104) at regular time intervals. The regular time intervals may be intervals of about 5 minutes, 10 minutes, 1 hour, every specific hour of the day, etc. Based on the previous glucose values, the AP algorithm may predict (720) future glucose values. Based on the predicted future glucose values ​​from 720, the AP algorithm may adjust the insulin delivery amount at 730, for example, by adjusting the insulin basal delivery rate based on the predicted future glucose values. At 740, insulin may be delivered via the medical device according to the adjusted insulin basal delivery rate. For example, the medical device 102 can deliver an amount of insulin to the user at regular periods, such as approximately every 5 minutes, with the amount adjusted based on the received glucose value.

[0045] The process 700 of the example of FIG. 7A continues and the processor may receive subsequent glucose measurements via a wireless connection with the glucose monitor. A total insulin-based basal glucose level for the day may be determined using the received subsequent glucose measurements and previous glucose values ​​from the past time period. The processor may compare the total insulin-based basal glucose level for the day to a user-set basal glucose set point (e.g., 110-120 mg / dL or equivalent). In response to the results of the comparison indicating that the user-set basal glucose set point is incorrect, the processor may determine an updated basal insulin delivery rate to be delivered by the medical device. In an example, the updated basal insulin delivery rate is updated from the adjusted basal insulin delivery rate from step 730.

[0046] The techniques described herein provide safety constraints for the delivery of insulin based on known or unknown failures or inaccuracies of the sensor 104. Examples of various operating scenarios and responses thereto by the system 100 are described herein.

[0047] In an operational embodiment, the system 100 may respond with an automatic pause of insulin delivery when the blood glucose measurement id falls below a glucose threshold, according to the following discussion. In an operational embodiment, regardless of the prediction made by the AP algorithm, the AP algorithm may enter an automatic pause mode when the glucose level determined by the sensor 104 falls below a threshold (e.g., below 60 mg / dL). The AP algorithm may automatically resume insulin delivery based on a model predictive control (MPC) algorithm when the glucose value rises above the threshold. In various embodiments, the drug delivery system 100 may stop delivering insulin to the user when hypoglycemia is detected (e.g., based on the glucose level falling below a predetermined threshold). Automatic resumption of delivery to the user may be provided when the glucose level rises above a threshold. An MPC algorithm, operating as part of the AP algorithm, may be used for automatic initiation.

[0048] In other operational examples, the system 100 may respond by constraining the AP algorithm to a basal rate below a threshold, in accordance with the discussion below. In various examples, the AP algorithm can be constrained to deliver at or below a fixed insulin rate when glucose values ​​fall below a predetermined threshold. FIG. 6 illustrates an example of constraining delivery to or below a fixed insulin rate under such a scenario. The AP algorithm may reduce or suspend insulin delivery when glucose values ​​fall below a threshold. The fixed insulin delivery rate can be personalized to the user and determined by a basal rate entered by the user, a rate calculated by the AP algorithm based on an average AP algorithm-based daily delivery amount, a rate based on the user's weight, age, total daily insulin amount (TDI), and / or other measurements.

[0049] As an example, a "TDI-based basal rate" can be calculated by multiplying the user's total daily insulin requirement, i.e., the sum of the user's insulin delivery over a past period, such as 24 hours, by 0.5 (assuming that the basal rate would naturally be covered by half of the user's total insulin requirement per day, while the other half of the user's total insulin requirement per day is covered by insulin provided at mealtimes or as a bolus), and then dividing that value by 24 (i.e., the time of day). For example, if the user's TDI is 48, the user's TDI-based basal rate is 48 x 0.5 / 24, i.e., 1 U / hour. This gives an estimate of the total basal rate that the user may actually need in a day, and is less susceptible to any erroneously user-entered basal value.

[0050] The predetermined threshold may be a fixed (e.g., hardwired) threshold, a user-set threshold, or a user-set threshold adjusted by a fixed (positive or negative) deviation value (e.g., a user-set target glucose amount minus a fixed 10 mg / dL adjustment amount). As an example, the fixed insulin delivery rate may be about half of the set basal delivery amount when the glucose level falls below the predetermined threshold. Figure 2 illustrates an example of a fixed insulin delivery rate for a user that is generally limited to the user's TDI-based insulin amount.

[0051] The techniques described herein can account for sensor values ​​provided to the AP algorithm / drug delivery system 100 that may be incorrect or erroneous for any number of reasons by providing sensor independent safety constraints. In such cases, the system 100 may implement glucose independent safety constraints on the maximum delivery of insulin over a period of time, as described below.

[0052] For example, FIG. 8 illustrates a process flow chart for implementing an example of a safety constraint in response to over-delivery of insulin. In various examples, such as process 800, the AP algorithm can be constrained to a maximum fixed insulin delivery rate for a set amount of time if the AP algorithm is delivering a volume of insulin greater than a preset one personalized to the user. For example, the process can be operable to deliver a maximum amount of the user's input basal or TDI-based basal amount in response to execution of the AP algorithm if the AP algorithm has delivered three times the sum of the user's basal delivery amounts within the past three hours (often referred to as the 3×3 rule). A processor (such as processor 161) coupled to the medical device (such as 102, which may be a pump) can determine that the medical device is delivering a volume of insulin greater than a preset one for a set amount of time (810). The amount of insulin to be delivered by the medical device as an adjusted basal dosage can be adjusted (820) based on a calculation using the volume of insulin delivered over the set amount of time and the total daily amount of insulin to be delivered as calculated by the artificial pancreas algorithm. At 830, the processor may limit the amount of insulin to be delivered as the adjusted basal dosage to the maximum volume of the user's basal insulin delivery volume divided by either the time increment or the percentage of the basal rate per hour that the adjusted basal dosage is administered. In the example of FIG. 8, the time increment may be a regular time interval. Examples of regular time intervals may be less than an hour, more than an hour, or the like, such as, for example, 5 minutes, 9 minutes, 23 minutes, or the like. Alternatively, the time increment may simply be an increment based on a counter value or the like.

[0053] The AP algorithm may then reduce or suspend insulin delivery, but is constrained to a maximum insulin delivery amount. Figure 5 illustrates an example of constraining the maximum insulin delivery amount. The fixed insulin delivery rate and pre-set insulin delivery volume can be personalized to the user and determined by the user's entered basal rate, a rate calculated by the AP algorithm based on the average AP algorithm-based daily delivery amount, weight, age, total daily insulin delivered, a rate based on total daily basal delivered, or other measurements. In addition, the constrained delivery may be accompanied by an alert or alarm to the user indicating the same.

[0054] In other cases, the system 100 may implement a glucose-independent safety constraint on the maximum amount of insulin delivered at any one time, as described below. In various embodiments, the AP algorithm can be constrained to deliver no more than a fixed volume of insulin personalized to the user over any one control cycle. For example, the AP algorithm can deliver no more than 6 times the user's basal rate divided by 5-minute increments (e.g., often referred to as the 6× rule), or 50% of the basal rate per hour (e.g., 1.2u / hr / 2=.6 units of basal rate) in one algorithm delivery volume. The fixed volume of insulin delivery can be personalized to the user and can be determined by the basal rate entered by the user, a rate calculated by the AP algorithm based on the average AP algorithm-based daily delivery volume, weight, age, total daily insulin delivered, a rate based on the total daily basal amount delivered, or other measurements.

[0055] In further cases, the system 100 may implement a glucose independent safety constraint to limit under-delivery of insulin, as described below. In various embodiments, the AP algorithm / drug delivery system 100 may implement a negative insulin remaining amount (IOB) constraint. The AP algorithm may enter a fixed insulin delivery rate mode personalized to the user if the AP algorithm under-delivers insulin by more than a volume of insulin personalized to the user over a period of time incorporating IOB. For example, 2.5 times the user's basal amount within the past 4 hours after applying the IOB decay curve. The AP algorithm calculates the remaining IOB at each control cycle. A negative IOB determination may indicate that the algorithm has been delivering less than a fixed personalized rate (i.e., basal amount) over a period of insulin delivery history. The negative IOB value may be a cumulative "under-basal" delivered amount that takes into account IOB decay.

[0056] FIG. 9 illustrates a process flow chart for implementing an example of a safety constraint in response to under-delivery of insulin. In process 905, a processor (such as 121 or 161 in FIG. 1 ) may receive a signal from a medical device indicating the amount of insulin being delivered by the medical device (such as 102 in FIG. 1 ), and the processor may maintain the total amount (e.g., volume) of insulin delivered in memory (such as 123 or 163 in FIG. 1 ), for example, as an insulin delivery history. The insulin delivery history may span, for example, minutes, hours, days, weeks, months, periods between appointments with a physician, years, or the like. In example process 905, a processor of a medical management device (such as 106 in FIG. 1 ) may determine (915) that the medical device has delivered insulin below a fixed personalized basal rate for a period of insulin delivery history in response to receiving a glucose measurement from a sensor (such as 104 in FIG. 1 ). The result of delivering insulin below the fixed personalized basal rate is a negative insulin remaining value. At 925, the processor may determine that the negative insulin remaining value is greater than three times the user's daily total insulin base hourly basal value. In response to the negative insulin remaining value being greater than several times (such as 3, 6, 2.5, or the like) the user's daily total insulin base hourly basal value, the delivery of insulin by the medical device may be modified (935) to deliver a daily base total basal amount or personalized insulin volume. At 945, a notification message may be output requesting the user to acknowledge the modified delivery amount of insulin or a requirement for a new calibration value for use by the processor in calculating a calibrated amount of insulin for delivery.

[0057] The process 905 continues at 955, where the process 905 may determine whether a user acknowledgment of the request for a new calibration value has been received. In response to receiving the user acknowledgment of the modified delivered amount of insulin, the medical device continues with the modified delivered amount of insulin (962). In response to receiving the new calibration value, the processor generates a new calibration value (965), and the new calibration value is applied by the processor to calculate a calibrated amount of insulin for delivery (975).

[0058] In various embodiments, if the negative IOB determination is greater than three times the user's TDI-based hourly basal value, the AP algorithm may revert to delivering a TDI-based basal amount or a personalized insulin volume and notify the user accordingly. User input may be required for the user to acknowledge the system status via a notification message or for a requirement for a new calibration value. The system 100 may deliver a basal amount until the notification message is acknowledged or a calibration is typed in. Additionally, the system 100 may resume operation in a manner prior to the negative IOB determination in response to a user acknowledgement and / or the performance of a calibration of the sensor 104, which in this embodiment may be a continuous glucose monitor (CGM).

[0059] Disclosed are examples of determining and resolving communication problems, such as between a sensor (e.g., 104) and either a pump 102 and / or a management device (e.g., 106) in a drug delivery system, such as that described with reference to FIG. 1.

[0060] FIG. 7B illustrates a process flow chart for implementing an example of a safety constraint in response to a communication problem in a drug delivery system, such as the example drug delivery system illustrated in FIG. 1. In various examples, under a scenario where measurements from the sensor 104 are not received by the AP algorithm (e.g., missing values ​​from the sensor 104), the system 100 may respond according to an example process 705 illustrated in FIG. 7B. In the example of FIG. 7B, the process 705 may respond based on the last known value (or values) from the sensor 104. For example, at 715, a processor such as 121, 141, or 161 may receive several glucose measurements from the sensor 104. In an example, each glucose measurement of the several glucose measurements may be received at regular time intervals over a period of time, the regular time intervals being less than the period of time. Of course, the regular time intervals may be equivalent to those described in the discussion of FIG. 7A. The processor may predict future glucose values ​​at 725 using at least one of the several received glucose measurements. For example, each time an AP algorithm executing on the processor receives a value, future glucose values ​​to be received in future time intervals may be predicted. The processor may determine (735) that a subsequent glucose measurement has not been received within the next regular time interval. For example, when a glucose measurement from the sensor 104 is expected but not received, the system 100 may use the predicted glucose value that was generated when the last received value from the sensor 104 was received. For example, in response to determining that a subsequent glucose measurement has not arrived, a daily total insulin-based basal delivery rate may be adjusted (745) to be provided by the medical device based on at least one of several predicted future glucose measurements. The processor may issue instructions to a medical device, such as 102 of FIG. 2, so that insulin may be delivered via the medical device 102 in accordance with the adjusted daily total insulin-based basal delivery rate at 755.

[0061] In a further example, insulin may be delivered via the medical device according to the adjusted total daily insulin-based basal delivery rate for the trusted predicted period. In a further example, the processor may further determine to suspend insulin delivery in response to the last received glucose measurement being within a particular range of the previous glucose measurement and the trusted predicted period spanning a duration corresponding to a predetermined number of regular time intervals. The period during which insulin delivery is to be suspended may be determined based on the value of the last received glucose measurement falling within a particular range of a plurality of ranges of glucose measurements. In response, the period for suspending insulin delivery may be selected from a number of pre-set periods, and the processor may suspend insulin delivery for the selected period.

[0062] Alternatively, the medical device may deliver insulin using previous predicted glucose values ​​(and corresponding insulin dosage values) for an allowed "trusted prediction" period. In yet another example, insulin delivery may continue if the last received value from the sensor 104 is above a threshold and is predicted to deliver above the baseline rate of insulin, and predictions may be used for 15 minutes or longer.

[0063] If values ​​from the sensor 104 do not resume before the trusted prediction period expires, the AP algorithm response may depend on the last received value (or values) from the sensor 104 and a prediction based thereon by the AP algorithm. In various examples, the AP algorithm may respond with an insulin delivery amount and possibly a notification to the user via the management device 106, for example, according to the following table: [Table 1-1] [Table 1-2] [Table 1-3] [Table 1-4]

[0064] In various embodiments, each cycle (eg, control cycle) referenced above can be of any duration, including, but not limited to, about 5 minutes, 8 minutes, or the like.

[0065] In various embodiments, the AP algorithm may permanently or temporarily attenuate the extended portion of the extended bolus in response to glucose levels only, glucose levels and AP algorithm predictions, or AP algorithm predictions only. In various embodiments, the AP algorithm may automatically discontinue the extended portion of the extended bolus in response to glucose levels only, glucose levels and AP algorithm predictions, or AP algorithm predictions only. The extended portion of the extended bolus may be applied to correction or meal IOBs for future automated or manual insulin dosing decisions. When applied to correction IOBs, the AP algorithm may be more conservative in hypoglycemia. When applied to correction IOBs, the AP algorithm may be more conservative in hyperglycemia.

[0066] In other cases, system 100 may limit the system's response to a hypoglycemic event response, such as ingesting rescue carbohydrates, as described below. For example, in the event that the user suffers a hypoglycemic event (e.g., glucose concentration falls below the 70 mg / dL hypoglycemic threshold), the user may respond by ingesting fast acting carbohydrates to rapidly increase the user's blood glucose. This is an unannounced meal to system 100, which has the potential to be viewed by system 100 as a very fast increase in glucose. In response, system 100 may respond by delivering additional insulin to compensate for these carbohydrates. However, this may not be a preferred response because the carbohydrates were specifically ingested to increase the user's glucose level, and the user may not want to receive insulin to counteract these carbohydrates.

[0067] In an example, the processor may execute programming code stored in the memory to perform functions for determining that a hypoglycemic event is occurring based on measurements provided by a glucose monitor (such as sensor 104 in FIG. 1). In response to determining that a hypoglycemic event is occurring, the system 100 may modify the adjusted insulin basal rate via a processor such as 121, 141, or 161. For example, the processor may modify the adjusted insulin basal rate by setting a reduced temporary basal rate of the medical device used for dosing calculations for a predetermined period of time following the determination of the occurrence of a hypoglycemic event. Alternatively, the system 100 may set, via the processor, a reduced temporary basal rate that may be used in dosing calculations until the glucose change rate decreases below a predetermined threshold following the determination of the occurrence of a hypoglycemic event. In another alternative, the system 100 may set a reduced temporary basal rate that may be used in dosing calculations until the blood glucose (measured by a sensor such as 104 in FIG. 1) exceeds a predetermined threshold following the determination of the occurrence of a hypoglycemic event.

[0068] For example, techniques for detecting such scenarios (e.g., system 100 detecting the ingestion of fast acting carbohydrates to address a hypoglycemic event) are described herein and include the following detection techniques: 1) detection of a fast rate of increase in glucose concentration above a threshold (e.g., 2 mg / dL / min); 2) detection of a fast rate of increase in glucose concentration across a series of glucose concentration values ​​when the first value in the series falls below the first threshold (e.g., when the first value in the series falls below a hypoglycemic threshold of 70 mg / dL, such as in (1)). 3) detecting a rapid rate of increase in glucose concentration when any value in the series falls below a second threshold (e.g., detecting a rapid rate of change as in (1) when any value in the series falls below a system target glucose of 120 mg / dL); and / or 4) detecting a rapid change in the second derivative (e.g., acceleration) of glucose concentration above a predetermined threshold (e.g., finding a significant change in the rate of change of glucose concentration across any number of points, e.g., finding a 2 mg / dL / min decrease to a 2 mg / dL / min increase in glucose concentration).

[0069] 10 is a flow chart of an exemplary process for implementing an example of a response to a rapid rate of increase in a glucose concentration or measurement. In the example of FIG. 10, a processor executing programming code, such as an AP algorithm, may perform process 1000. The processor may be operable to obtain a series of glucose concentration values ​​as measured by a glucose monitor at regular time intervals (1010). The processor may detect a rapid rate of increase in the glucose concentration and, in response to detecting the rapid rate of increase in the glucose concentration or measurement, may implement a response to the rapid rate of increase in the glucose concentration (1020).

[0070] For example, in response to detecting a fast rate of increase in glucose concentration (e.g., using the detection techniques described above) that indicates the ingestion of fast acting carbohydrates to address a hypoglycemic event, a response (e.g., by system 100) to the detection of the ingestion of fast acting carbohydrates to address a hypoglycemic event may be implemented (1030). In an example, a processor within system 100 may be operable to perform functions when implementing a response to a fast rate of increase in glucose concentration, such as those described below, in response to executing programming code. Examples of techniques implemented by the system via a processor executing programming code that may implement a response to the detection of the ingestion of fast acting carbohydrates (based on a fast rate of increase in glucose concentration) in response to a fast rate of increase in glucose concentration are described below and may include one or more of the following:

[0071] i. Limit the AP algorithm recommended delivery rate to a user-personalized maximum delivery rate (eg, below basal rate) for a defined duration (eg, 25 minutes) after the event.

[0072] ii. After a hypoglycemic event, limit the AP algorithm recommended delivery rate to a user-personalized maximum delivery rate (eg, below basal rate) until the rate of change decreases below a predefined threshold.

[0073] iii. After a hypoglycemic event, limit the AP algorithm recommended delivery rate to a user-personalized maximum delivery rate (eg, below basal) until glucose rises above a predefined threshold.

[0074] iv. Limit the AP algorithm delivery of insulin using any combination of techniques i, ii, or iii.

[0075] v. Reducing the AP algorithm gain, cost function, and / or aggressiveness for a predetermined period of time after a hypoglycemic event. The AP algorithm gain may be, for example, a model gain that is an indication of the amount the user's glucose would change per unit of insulin. The cost function may be, for example, a measurement of deviation of the glucose error value from a set point. The set point may be, for example, a target glucose value (e.g., 113 mg / dL), which in an example may be set within a range of about 110-120 mg / dL or equivalent. In general, the further the glucose measurement is from the target glucose value (either higher or lower), the higher the cost value generated by the cost function will be, while glucose measurements closer to the target glucose value will have lower cost values. In an example, the cost function may be related to deviations in measured and expected glucose and / or deviations in expected and basal insulin amounts. The aggressiveness may be related to the responsiveness of the AP algorithm to deviations in the cost function. Aggressiveness can be thought of as the rate at which the AP algorithm reduces the cost function and drives the glucose measurement toward the set point. A high aggressiveness setting may attempt to drive the glucose measurement toward the set point quickly, while a low aggressiveness setting may correct the glucose value more smoothly.

[0076] vi. After a hypoglycemic event, reduce the AP algorithm gain, cost function, and / or aggressiveness until glucose is above a predefined threshold.

[0077] vii. After a hypoglycemic event, reduce the AP algorithm gains, cost function, and / or aggressiveness until the rate of change decreases below a predefined threshold.

[0078] viii. Limiting the AP algorithm delivery of insulin using any combination of techniques v, vi, or vii.

[0079] ix. Implementing a glucose rate of change filter for a predetermined period of time following a hypoglycemic event. FIG. 4 illustrates an example of how a rate of change filter can affect predictions made by the AP algorithm, resulting in a lower estimated trajectory of future blood glucose values. A rate of change filter can be used by a processor (such as processor 121, 141, or 161) executing the AP algorithm to limit the rate of glucose change seen (acted upon) or provided to the AP algorithm. For example, a glucose measurement may be provided by a glucose sensor. Using multiple glucose measurements, a rate of change of the glucose measurement can be determined. A rate of change filter can be used to either attenuate or amplify the rate of change of the glucose measurement utilized by the AP algorithm. Application of the rate of change filter can be limited for a duration, for example, from when the processor determines that the glucose measurement first falls below a predetermined threshold or from when glucose rises above a predetermined threshold after being induced. For example, if the rate of change becomes high (e.g., 4 mg / dL) following a rescue carbohydrate intake, a rate of change filter can limit the rate of change allowed by the algorithm to 2 mg / dL for 30 minutes after returning above 70 mg / dL to reduce the AP algorithm response to carbohydrates.

[0080] x. Following a hypoglycemic event, implement a glucose rate of change filter until the rate of change decreases below a predefined threshold.

[0081] xi. Following a hypoglycemic event, implement a glucose rate of change filter until glucose is above a predefined threshold.

[0082] xii. Implement a glucose change rate filter at all times.

[0083] xiii. The rate of change filter may be for both positive and negative rates of change or only positive rates of change.

[0084] xiv. Implement a glucose change rate filter using any combination of techniques ix, x, xi, xii, or xiii.

[0085] xv. The system 100 can set a reduced target blood glucose level that can be used for medication calculations for a predetermined period of time following a hypoglycemic event.

[0086] xvi. The system 100 can set a reduced target blood glucose level that can be used for dosing calculations after a hypoglycemic event until the glucose rate of change decreases below a predetermined threshold.

[0087] xvii. The system 100 can set a reduced target blood glucose level that can be used for dosing calculations until glucose is above a predetermined threshold.

[0088] xviii. The system 100 may set reduced target blood glucose levels for any combination of techniques xv, xvi, or xvii above.

[0089] All of the above predetermined thresholds may be user-defined, fixed, adapted over time using AP algorithm parameters, or personalized to the user based on the TDI or TDI derivative. In addition, other responses such as reducing the temporary basal rate used for dosing calculations are also described in more detail with reference to other examples.

[0090] Returning to the system embodiment of Figure 1, the management device processor 161 of the management device 106 in the system 100 may be operable to perform various functions in response to execution of programming instructions, including an artificial pancreas algorithm. For example, the management device processor may determine the frequency and dosage of insulin to be delivered to the user. The frequency and dosage may be calculated based on the user's gender, the user's age, the user's weight, the user's height, and / or the glucose level provided by a sensor.

[0091] In an example, the managing device processor 161 may determine the occurrence of a hypoglycemic event. In response to the determination of the occurrence of a hypoglycemic event, the managing device processor may implement a glucose change rate filter for a predetermined period of time. The glucose change rate filter may limit the rate of change in measured blood glucose values ​​used by the artificial pancreas algorithm in determining the time for delivery of insulin and the dosage of insulin being delivered. The managing device processor may instruct the medical device, via the wireless link 110, to deliver the determined dosage of insulin at the determined time for delivery. The managing device processor 161 may limit the duration for the implementation of the glucose change rate filter by applying one or more limitations, including from when the measured glucose value first falls below a predetermined threshold associated with a hypoglycemic event, from when the measured glucose value rises above another predetermined threshold after the occurrence of a hypoglycemic event, until the glucose change rate decreases below a further predetermined threshold, or until glucose rises above an additional predetermined threshold.

[0092] The management device processor 161 may further be operable to apply a glucose change rate filter at one of all times, when both positive and negative glucose change rates are determined, or when only positive glucose change rates are determined.

[0093] In another embodiment, the management device processor 161 is further operable to perform one of the following in response to execution of the artificial pancreas algorithm: changing from a closed-loop operating mode to an open-loop operating mode; constraining maximum insulin delivery according to a basal delivery rate personalized for the user after detection of an event, for a set period of time, or until the event has ended, where the event is an event different from a hypoglycemic event; delivering the set personalized basal rate after detection of a hypoglycemic event, for a set period of time, or until the hypoglycemic event has ended; limiting the rate of change as used by the processor after detection of an event, for a set period of time, or until the event has ended; or causing a rate of change filter to be applied to limit the response by the artificial pancreas algorithm at all times or following a hypoglycemic event.

[0094] In some scenarios, the insulin delivery rate may not be tapered as quickly as desired (e.g., at a suitable rate to recover), for example, in the event of the occurrence or impending occurrence of a hypoglycemic event. For example, the system 100 may tapered the insulin delivery rate to an amount of insulin or below that which the user could accept without the system 100 when the user's glucose value falls below a threshold or is trending toward being tapered below a threshold. However, there may be a risk that the system 100 may not tapered the insulin delivery rate as quickly as desired, leading the processor, for example, to the medical device, to deliver insulin even when the user has an imminent hypoglycemic risk. FIG. 11 shows a flowchart of an example process for implementing an example response that increases the likelihood of insulin suspension. In the process 1100, for example, a processor coupled to a glucose sensor in the system 100 may determine (1110) that the insulin delivery is not tapered at a suitable rate to recover from a hypoglycemic event or impending hypoglycemic event. In response, the processor may apply safety constraints and further reduce the insulin.

[0095] For example, the processor may address this slower decay utilizing the techniques described above that modify the processor reaction via the AP algorithm executed by the processor and the safety constraints described. At 1120, the processor may address such a scenario in the following manner.

[0096] a. In various embodiments, calculations performed by the artificial pancreas algorithm may increase the likelihood of insulin suspension by reducing the penalty of the estimated outcome when insulin delivery demand falls below a user-inputted basal delivery rate; or

[0097] b. In various embodiments, calculations performed by the artificial pancreas algorithm may increase the likelihood of insulin suspension by scaling deviations in insulin delivery rates below a user-inputted basal rate so that they are proportional to the user-inputted basal delivery rate.

[0098] In other examples, the system 100 may use some techniques to manage other scenarios in which insulin delivery is not tapered during exercise or other activities that may induce an increased risk of hypoglycemia. For example, the system 100 may tapered insulin delivery when an external disturbance to the system 100, such as exercise or activity, causes a reduction in glucose concentration and an increased risk of hypoglycemia. The system 100 may automatically detect this external disturbance. Alternatively, the external disturbance may be made known or indicated to the system 100 by a user (e.g., through a user interface (not shown) on the medical device 102 and / or the management device 106). FIG. 12 is a flow chart of an example process for implementing an example response of tapering insulin delivery. In an example process 1200, a processor coupled to a glucose sensor in the system 100 may determine (1210) that insulin delivery is not tapered at a rate suitable to maintain glucose concentration or mitigate a hypoglycemic event or an impending hypoglycemic event. In response, the processor may apply safety constraints to further reduce insulin. For example, the processor may modify the control target glucose value by increasing the control target (i.e., glucose set point) to a glucose value higher than the current target (e.g., from a lower current target to 150 mg / dL or equivalent). Alternatively, the system 100 may reduce the input basal value to a value lower than the current input basal value (e.g., about 25% of the user's input basal rate) (1220). In various examples, the system 100 may be subject to an additional upper bound on insulin delivery (e.g., the system 100 may not require an insulin delivery rate greater than about 75% of the user's input basal rate). Application of the safety constraint results in the insulin delivery rate being tapered off at a faster rate to maintain the glucose concentration (1230).

[0099] In some examples, the system 100 may not have sufficient insulin history associated with the user. In response, the insulin delivery history data and glucose value history data can be used by the system 100 to operate in a substantially closed-loop operating mode. When in a closed-loop mode, if there is no known insulin history, there may be a risk that the user has an IOB and the AP algorithm may deliver more insulin than necessary. Techniques herein can address such scenarios where the system 100 may not have sufficient historical operating data.

[0100] In various embodiments, if the system 100 does not have sufficient glucose history when it begins closed-loop operation, the system 100 may respond in one of the following ways.

[0101] I. Prompt the user to query whether a non-basal amount of insulin was delivered in the previous duration. If the answer is "yes," limit the AP algorithm maximum delivery rate of insulin to a pre-determined value for a set amount of time (e.g., limit delivery rate to 1.5 times the user's basal rate for 2 hours).

[0102] II. Request a user response to a query as to whether a non-basal insulin dose was delivered within the previous duration. If the answer is "yes" (i.e., a positive response), have the user type in the amount of insulin delivered and optionally also the time taken. Using this information, the user's IOB can be calculated and provided to the AP algorithm for safety in delivering insulin. The IOB may be used by a predictive algorithm or may directly limit the amount of insulin to be delivered while the IOB remains; or

[0103] III. When initiating closed loop mode, if sufficient insulin history is not present, the AP algorithm limits the maximum delivery to a predetermined value (eg, 100-120 mg / dL, etc.) for a set amount of time.

[0104] Returning to the system embodiment of FIG. 1, the management device processor 161 of the management device 106 may be operable to perform additional functions in response to execution of the artificial pancreas algorithm.

[0105] For example, the managing device processor 161 may determine, in response to initiating closed-loop operation of the artificial pancreas algorithm, that sufficient glucose history is not available for use by the artificial pancreas algorithm (i.e., the glucose history is insufficient). In response to determining that sufficient glucose history is not available, the managing device processor may request the user to enter an amount of insulin to be delivered into the managing device. The request may also include a request for the time at which insulin was delivered or the estimated time elapsed since insulin delivery. In response to receiving the amount of insulin to be delivered, the user's insulin remaining amount may be calculated based on the amount of insulin delivered. Optionally, if the time at which insulin was delivered or the estimated time elapsed since insulin delivery is provided, these individual times or elapsed times may be included in the calculation. For example, the managing device processor may be operable to determine the elapsed time if only the time at which insulin is delivered is provided. The managing device processor may use the calculated user's insulin remaining amount to determine utilization of the user's personalized insulin decay curve when the user's calculated insulin remaining amount would fall below a predetermined threshold. Alternatively, in response to determining that sufficient glucose history is not available, the management device processor may either limit the maximum delivery of insulin to a predetermined value for a set amount of time or request a user response to a query as to whether a non-basal insulin dose has been delivered within the previous duration.

[0106] In some embodiments, the AP algorithm / system set points change in response to various inputs or events (e.g., exercise or food intake). The system 100 can operate to maintain the user at a specific target or set point (e.g., a desired glucose level). In various embodiments, the system 100 can allow the user to set or change the set points of the system 100 under certain scenarios or for certain instances. In various embodiments, the system 100 can allow the user to set or change the set points of the system 100 temporarily for a user-defined amount of time, after the expiration of which the system 100 can revert to the previous target.

[0107] In various embodiments, the set point may be defined as a profile, with different set points set over different time segments of the day. The target blood glucose level may automatically change in each time segment. In various embodiments, if the set point changes, the system 100 may respond abruptly to the step change and deliver too much or too little insulin. To prevent the system 100 from responding to the step change, the prediction by the AP algorithm may be shifted by the amount of the target change. This may prevent the prediction from being affected by the step change in the target.

[0108] In some examples, safety constraints implemented via the AP algorithm may enable the AP algorithm to respond to sensor aberrations, i.e., noise and step changes in value, such as those depicted in FIG. 3. For example, the technique allows the system 100 to effectively manage the response to sudden step changes in aberrations or non-physiological changes in the sensor 104. For example, non-physiological aberrations of the sensor 104 may be caused by a noisy sensor 104, or by physical interactions with the sensor 104, such as pressure on the sensor 104, or by bumping or hitting the sensor 104. The system 100 may respond to this sudden change in value from the sensor 104 and erroneously deliver a drug. The techniques described herein can address this undesirable response and allow such events to be detected by the system 100 in the following ways: A) by determining only the sensor value trend; B) by following a sensor value trend in one direction and determining the opposite trend and detecting a sudden change in trend; C) by determining the rate of change of the sensor value; and / or D) by determining that first derivative or other filtering may be used. Additionally or as an alternative E), in some embodiments, data obtained from an accelerometer in a sensor such as 104 may be used in combination with the trend. For example, pressure-induced sensor problems may occur at a higher rate when, for example, a person is sleeping, and thus sleep detection via accelerometer data may also be used to improve detection of incidents. Accelerometer data may also be used to sense and improve detection of effects on the sensor or delivery unit. For example, a processor may process accelerometer data to detect a person's sleep or orientation when the sensor is experiencing a pressure-induced sensor problem.

[0109] In various examples, upon detection of any of the above-listed events AE, the system 100 may respond in any of the following ways: AA) the AP algorithm may change modes, such as changing from closed-loop operation to open-loop operation, BB) constrain the system 100 to a user-personalized maximum delivery rate (e.g., basal rate) after detection of an event (i.e., one of the above-listed events AE) for a set period of time or until the event ends, CC) deliver a set personalized rate (e.g., basal rate) after detection of an event for a set period of time or until the event ends, DD) the AP algorithm may limit the rate of change as used by the system 100 after detection of an event for a set period of time or until the event ends, or EE) a rate of change filter may be implemented to limit the response by the AP algorithm at all times or following a hypoglycemic event.

[0110] Safety constraints as applied to the AP algorithm and executed by the processor in the system 100 may control the system response to sensor calibration, especially when the sensor is a continuous glucose monitor. For example, under certain circumstances where sensor calibration may be required, there may be a resulting step change in the sensor value. In response, the system 100 may deliver a drug in response to such a step change. For example, the current state of the system 100, on which predictions may be based, may depend on the input sensor values ​​at each control step. These sensor values ​​may depend on user-input reference calibration values ​​(e.g., finger sticks) and may change significantly if there is a significant discrepancy between the sensor readings and the finger stick values ​​used for calibration.

[0111] These rapid changes in sensor values ​​may introduce artificial step changes in glucose trajectory (e.g., calibration jumps as shown in FIG. 3) that are not a true reflection of the actual trend in glucose concentration. Furthermore, the presence of significant differences between fingerstick blood glucose (BG) values ​​and CGM values ​​at the time of calibration means that CGM values ​​entered into the system 100 prior to the calibration reference input and state estimates resulting from those CGM values ​​are unlikely to be reliable and may not reflect the current state. Thus, when these events are detected, the predicted "trajectory" of the AP algorithm is reset to a flat value that matches the current new CGM value. FIG. 3 illustrates an example of adjusting the predicted trajectory based on new CGM values.

[0112] In various examples, this reinitialization may be implemented for positive and negative step changes, and may be limited to only positive step changes in blood glucose levels due to calibration, since negative step changes in blood glucose levels may induce a reduction or pause in insulin delivery for only a few cycles, which may be acceptable.

[0113] For example, in system 100 of FIG. 1 , a processor such as 121, 141, or 161 may be operable to execute a process whereby the processor receives one or more glucose measurements from a glucose monitor, such as sensor 104. The processor may also receive a user-input reference calibration value. Using the one or more glucose values ​​and the user-input reference calibration value, the processor may identify a difference between the one or more glucose values ​​from the glucose monitor and the user-input reference calibration value. Based on the identified difference, the processor may modify the adjusted insulin basal delivery rate.

[0114] In some examples, prior to modifying the adjusted insulin basal delivery rate based on the identified discrepancy, the processor may calibrate the glucose monitor based on the identified discrepancy. The processor may further determine that the identified discrepancy is a positive step change in the amount of insulin being delivered. A positive step change may be, for example, an increase in the amount of insulin delivered. In response to the identified discrepancy being a positive step change, the processor may obtain a current new blood glucose measurement from the calibrated glucose monitor. After obtaining the current new blood glucose measurement, the processor may use the current new blood glucose value to modify the adjusted insulin basal delivery rate based on the identified discrepancy. Alternatively, the identified discrepancy may be determined to be a negative step change, which is a decrease in the amount of insulin delivered. In response to the identified discrepancy being a negative step change, the processor may provide instructions to suspend delivery of insulin for a predetermined amount of time prior to modifying the adjusted insulin basal delivery rate based on the identified discrepancy.

[0115] The techniques described herein for providing safety constraints for a drug delivery system (e.g., system 100 or any component thereof) can be implemented in hardware, software, or any combination thereof. For example, system 100 or any component thereof can be implemented in hardware, software, or any combination thereof. Software-related implementations of the techniques described herein can include, but are not limited to, firmware, application specific software, or any other type of computer-readable instructions that can be executed by one or more processors. Hardware-related implementations of the techniques described herein can 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 embodiments, the techniques described herein and / or components of any system or configuration described herein can be implemented with a processor that executes computer-readable instructions stored on one or more memory components.

[0116] Some embodiments of the disclosed devices may be implemented using, for example, a storage medium, computer-readable medium, or article of manufacture that may store instructions or sets of instructions that, when executed by a machine (i.e., a processor or microcontroller), may cause the machine to perform methods and / or operations according to embodiments of the present disclosure. Such a machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, or the like, and may be implemented using any suitable combination of hardware and / or software. A computer-readable medium or article may include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium, and / or storage unit, such as memory (including non-transitory memory), removable or non-removable media, erasable or non-erasable media, writable or rewritable media, digital or analog media, hard disk, floppy disk, compact disk read only memory (CD-ROM), recordable compact disk (CD-R), rewritable compact disk (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory cards or disks, various types of digital versatile disks (DVDs), tapes, cassettes, or the like. The instructions include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, programming code, and the like, and may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled, and / or interpreted programming language. The non-transitory computer readable medium embodied programming code may cause a processor, upon execution of the programming code, to perform functions such as those described herein.

[0117] Certain examples or embodiments of the present disclosure have been described above. However, it should be expressly noted that the present disclosure is not limited to those embodiments, but rather additions and modifications to the contents explicitly described herein are also intended to be included within the scope of the disclosed embodiments. Furthermore, it should be understood that the features of the various embodiments described herein are not mutually exclusive and can exist in various combinations and permutations without departing from the spirit and scope of the disclosed embodiments (even if such combinations or permutations are not expressly made herein). Indeed, variations, modifications, and other implementations of the contents described herein will occur to those skilled in the art without departing from the spirit and scope of the disclosed embodiments. Thus, the disclosed embodiments are not to be defined solely by the preceding illustrative description.

Claims

1. 1. A method of operating a medical management device, the method being executed by a processor of the medical management device, the method comprising: and determining, in response to receiving a glucose measurement from the sensor, that the medical device has been delivering insulin at a first rate for a period of insulin delivery history that is less than a second rate of insulin delivery, wherein a comparison of insulin delivery at the first rate and the second rate results in a negative insulin remaining value, the second rate being one of: a user initiated insulin delivery rate, an insulin delivery rate calculated by an AP algorithm based on an average AP algorithm based daily delivery, and an insulin delivery rate based on a user's weight, age, and / or total daily insulin amount; determining that the negative insulin remaining value is greater than a threshold; in response to the negative insulin remaining value being greater than the threshold, altering delivery of insulin by the medical device to deliver a total basal amount on a daily basis or to deliver a personalized volume of insulin; and outputting a notification message, the notification message requesting the user to acknowledge the changed delivery of insulin or to request a new calibration value to be used by the processor in calculating a calibrated amount of insulin for delivery.

2. The method of claim 1 , further comprising continuing the altered delivery of insulin in response to receiving a user acknowledgment of the altered delivery of insulin.

3. The method comprises: in response to receiving the request for the new calibration value, the processor generating the new calibration value; The method of claim 1 , further comprising: the processor calculating the calibrated amount of insulin for delivery by applying the new calibration value.

4. A computer-readable medium embodied with programming code executable by a processor, the processor, when executing the programming code, determining, in response to receiving a glucose measurement from the sensor, that for a period of insulin delivery history, the user has been delivering insulin at a first rate that is less than a second rate of insulin delivery, wherein a comparison of insulin delivery at the first rate and the second rate results in a negative insulin remaining value, the second rate being one of: a user initiated insulin delivery rate; an insulin delivery rate calculated by an AP algorithm based on an average AP algorithm based daily delivery; and an insulin delivery rate based on the user's weight, age, and / or total daily insulin amount; determining that the negative insulin remaining value is greater than a threshold; in response to the negative insulin remaining value being greater than the threshold, altering delivery of insulin by the medical device to deliver a total basal amount on a daily basis or to deliver a personalized volume of insulin; and outputting a notification message, the notification message requesting the user to acknowledge the changed delivery of insulin or request a new calibration value to be used by the processor in calculating a calibrated amount of insulin for delivery.

5. 5. The computer-readable medium of claim 4, wherein when the programming code is executed by the processor, the processor is further configured to continue the altered delivery of insulin in response to receiving a user acknowledgment of the altered delivery of insulin.

6. When the programming code is executed by the processor, the processor: In response to receiving the request for the new calibration value, the processor Generate new calibration values, 5. The computer readable medium of claim 4, wherein the processor is further configured to apply the new calibration value and calculate the calibrated amount of insulin for delivery.

7. 1. A system comprising: A medical device comprising a pump, a reservoir configured to contain insulin, a processor, and a transceiver, the medical device operable to deliver insulin in response to an output from the processor; a sensor comprising a transmitter, a processor, and a cannula, the sensor operable to measure blood glucose and output a blood glucose level; 1. A management device comprising: a management device processor; a management device memory configured to store programming instructions including an artificial pancreas algorithm; and a management device transceiver, wherein the management device processor, in response to execution of the programming instructions, determining, in response to receiving a glucose measurement from the sensor, that the medical device has been delivering insulin at a first rate for a period of insulin delivery history that is less than a second rate of insulin delivery, wherein a comparison of insulin delivery at the first rate and the second rate results in a negative insulin remaining value, the second rate being one of: a user initiated insulin delivery rate, an insulin delivery rate calculated by an AP algorithm based on an average AP algorithm based daily delivery, and an insulin delivery rate based on a user's weight, age, and / or total daily insulin amount; determining that the negative insulin remaining value is greater than a threshold; in response to the negative insulin remaining value being greater than the threshold, altering delivery of insulin by the medical device to deliver a total basal amount on a daily basis or to deliver a personalized volume of insulin; and a management device operable to output a notification message requesting a user to acknowledge the changed delivery of insulin or to request a new calibration value to be used by the processor in calculating a calibrated amount of insulin for delivery.

8. The system of claim 7 , wherein the management device processor further comprises continuing the altered delivery of insulin in response to receiving a user acknowledgment of the altered delivery of insulin.

9. The management device processor: In response to receiving the request for the new calibration value, the processor Generate new calibration values, The system of claim 7 , further comprising the processor applying the new calibration value and calculating the calibrated amount of insulin for delivery.

Images