Automated Insulin Delivery (AID) systems deliver small amounts of insulin to users at frequent intervals, such as every 5 minutes. Such AID systems may include control software that determines the size of the insulin doses and then delivers such insulin doses. In some conventional AID systems, the control software seeks to maintain the glucose level of a user at a target glucose level. The control software receives regular glucose level readings from a glucose sensor. The control software predicts the glucose level of the user for a period, such as for the next 12 operation cycles of the delivery device, based on glucose level history and insulin delivery history. Based on these predictions, the control software may choose an insulin delivery dose.
In making the predictions and determining the next insulin delivery dose, the control software may reference the Insulin On Board (JOB) for a user. The IOB refers to the estimated amount of insulin that has not yet acted in the body of the user in that it has not yet affected the glucose level of the user.
Conventional AID systems rely upon IOB curves (sometimes referred to as “insulin decay curves”) for users in predicting future glucose levels of users and determining basal insulin delivery doses. The conventional IOB curves are fixed and based on population averages.
Conventional AID systems may overly constrain insulin deliveries after large insulin boluses are administered based on the resulting inflated IOB value. As a result, the response by the AID system to rapidly increasing glucose levels may be limited. The control software conventionally must limit its insulin delivery until the IOB returns to a level below the correction insulin amount that would be needed. This constraint fails to account for such large boluses typically being accompanied by user meal ingestion, and thus, the large insulin boluses may already be taken into account within the glucose-insulin dynamics. Hence, it may be sub-optimal to constrain further control software action due to the IOB contributed by meal boluses.
In accordance with a first inventive facet, a medicament delivery system for delivering medicament to a user may include a non-transitory readable storage medium storing computer programming instructions and a processor configured for executing the computer programming instructions. The computer programming instructions, when executed, may cause the processor to create a model of analyte-medicament interactions that is customized for the user based on analyte level history and medicament delivery history. The computer programming instructions, when executed, also may cause the processor to determine a standard impulse response for the model, determine, from the standard impulse response, an indication of how much medicament is on board over time for the user after a specified amount of medicament is delivered, and use the indication in determining a dose of medicament for the user to be output by the medicament delivery system.
The medicament delivery system may further include a reservoir for storing the medicament. Exemplary medicaments that may be used include insulin, glucagon-like peptide-1 receptor agonist (GLP-1), glucose-dependent insulinotropic polypeptide (GIP), or other hormones, and/or combinations of medicaments, such as two or more of insulin, GLP-1, and GIP, or other like hormones. This disclosure may refer to “insulin,” “Insulin On Board,” “Duration of Insulin Action,” etc., but it should be understood that the medicaments listed above and others may be used. The analyte level may be a glucose level and/or a ketone level. The indication may be a curve, a function, an equation, a set of equations, a table, or a storage holding values that are indicative of how much medicament is on board for the user over time after the specified amount of medicament is delivered. The computer programming instructions also may cause the processor to initiate delivery of the specified amount of medicament to the user. In some instances, the medicament may be insulin, and the model may be a glucose prediction model that predicts a future glucose level value of the user based on earlier glucose level values and insulin deliveries for the user. The computer programming instructions may further cause updating of the indication to account for recent analyte level values for the user and the updated indication may be used in determining a next dose of medicament for the user to be output by the medicament delivery system. The indication of how much medicament is on board over time for the user after a specified amount of medicament is delivered may be a nonlinear curve.
In accordance with another inventive facet, a medicament delivery system for delivering medicament to a user may include a non-transitory readable storage medium storing computer programming instructions and a processor configured for executing the computer programming instructions. The computer programming instructions may cause the processor to determine an estimate of duration of insulin action for a user, and to compare the estimate of duration of insulin action for the user to a threshold. where the estimate of duration of insulin action (DIA) for the user exceeds a threshold, the computer programming instructions may cause the processor to generate a notification of a recommendation to decrease the duration of insulin action for the user.
The execution of the computer programming instructions by the processor may cause outputting of the notification on a display device. The medicament delivery system may include an on-body medical device, such as medicament delivery device, that is secured to the user, and the recommendation may recommend a change in medicament delivery device infusion location on the user to reduce scarring. The recommendation may recommend a medicament delivery device location on the user that is typically not subject to, or less subject to, pressure by contact.
The recommendation may recommend using faster acting insulin. The recommendation may recommend avoiding ingestion of certain foods, such as certain types of foods or a list of foods.
In accordance with an additional inventive facet, a medicament delivery system for delivering medicament to a user may include a non-transitory readable storage medium storing computer programming instructions and a processor configured for executing the computer programming instructions. Executing the computer programming instructions with the processor may cause the processor to determine an estimate of duration of insulin action for a user, update the estimate of duration of insulin action for the user over time, and where the estimate of duration of insulin action changes more than a threshold amount over time, and generate a notification of a recommendation to reduce the change in the duration of insulin action for the user. As such, the duration of insulin action may be dynamic and automatically adjusted for the user as opposed to a static or fixed or “set” DIA.
Where the estimate of duration of insulin action is increasing, the recommendation may be to change location of where a medicament delivery device that is part of the medicament delivery system is secured to the user. The recommendation may be to modify diet patterns to previous diet patterns that resulted in acceptable glucose level control for the user. The estimate of duration of insulin action may be decreasing, and the recommendation may be to keep a present location of where the medicament delivery device is secured to the user. The medicament delivery device may be an insulin pump adhered to the user.
The exemplary embodiments may dynamically and automatically adjust an IOB profile for a user of a medicament delivery device to customize the IOB profile to the user based on recent glucose level history and insulin deliveries rather than on the conventional static IOB profiles that are derived from population averages. This dynamic customization may improve the glucose level management performance of the medicament delivery device for the user by more accurately capturing the IOB of the user over time. The IOB profile for a user is dynamic in that the IOB profile may be automatically updated at regular intervals or responsive to other trigger events.
For a user, a customized IOB profile may be generated as an insulin decay curve in the exemplary embodiments. The process of customizing the IOB profile begins with creating a custom model of insulin-glucose interactions. This model may predict future glucose level values for the user based on past glucose level values and weight coefficients. An impulse response (e.g., a response to a bolus pulse) for the model may be calculated, and the impulse response may be converted into a customized insulin decay curve.
The exemplary embodiments may calculate a DIA for a user from the customized insulin decay curves. Given that there is an association between time in a desired glucose level range and DIA, the exemplary embodiments may compare the DIA for the user with one or more thresholds to determine whether the user can take any steps to reduce the DIA when needed. The exemplary embodiments may generate and output notifications to the user to help reduce the DIA of the user. In addition, the exemplary embodiments may monitor the rate of change of the DIA of the user. If the DIA is increasing over time, recommendations may be generated and output to the user to take actions that will reverse, slow, or halt the increase and/or return to a more acceptable DIA. Where the DIA is decreasing, a recommendation may be generated and sent that recommends continued use of their current choices that affect DIA so as to decrease the DIA, maintain an ideal DIA, or keep the DIA from increasing.
The exemplary embodiments may aim to not overly constrain insulin delivery due to the contribution of insulin boluses to JOB. In some exemplary embodiments, the JOB used by the control software may be partitioned between IOB due to bolus deliveries and IOB due to AID delivery (such as basal insulin deliveries). Thus, the user may have different (simultaneous) Durations of Insulin Action. The IOB due to the bolus deliveries may be based upon a DIA that is particular to insulin boluses. The JOB due to basal deliveries may be based upon a DIA that is particular to basal insulin or AID deliveries of basal insulin. The DIA that is particular to insulin boluses may be shorter than the DIA due to AID delivery to avoid constraining insulin delivery for too long due to the contribution of insulin boluses to JOB. A combined JOB value may be used that reflects the shorter DIA for bolus deliveries and the longer DIA for basal deliveries. In addition, the DIA that is particular to insulin boluses may be dynamically varied based on actual insulin bolus activity. The DIA that is particular to insulin boluses may shorten with increasing cumulative recent insulin bolus deliveries and may increase with decreasing cumulative recent insulin bolus deliveries.
The medicament delivery device 202 may include a processor 210. The processor 210 may be, for example, a microprocessor, a logic circuit, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC) or a microcontroller. The processor 210 may maintain a date and time as well as other functions (e.g., calculations or the like). The processor 210 may be operable to execute a control application 216 encoded in computer programming instructions stored in the storage 214 that enables the processor 210 to direct operation of the medicament delivery device 202. The control application 216 may be a single program, multiple programs, modules, libraries or the like. The processor 210 also may execute computer programming instructions stored in the storage 214 for a user interface (UI) 217 that may include one or more display screens shown on display 227. The display 227 may display information to the user 208 and, in some instances, may receive input from the user 208, such as when the display 227 is a touchscreen.
The control application 216 may control delivery of the medicament to the user 208 per a control approach like that described herein. The control application may use a glucose prediction model as described below for predicting future glucose levels of the user 208. The storage 214 may hold histories 211 for a user, such as a history of basal deliveries, a history of bolus deliveries, and/or other histories, such as a meal event history, exercise event history, glucose level history, other analyte level history, and/or the like. In addition, the processor 210 may be operable to receive data or information. The storage 214 may include both primary memory and secondary memory. The storage 214 may include random access memory (RAM), read only memory (ROM), optical storage, magnetic storage, removable storage media, solid state storage or the like.
The medicament delivery device 202 may include a tray or cradle and/or one or more housings for housing its various components including a pump 213, a power source (not shown), and a reservoir 212 for storing medicament for delivery to the user 208. A fluid path to the user 208 may be provided, and the medicament delivery device 202 may expel the medicament from the reservoir 212 to deliver the medicament to the user 208 using the pump 213 via the fluid path. The fluid path may, for example, include tubing coupling the medicament delivery device 202 to the user 208 (e.g., tubing coupling a cannula to the reservoir 212), and may include a conduit to a separate infusion site. The medicament delivery device 202 may have operational cycles, such as every 5 minutes, in which basal doses of medicament are calculated and delivered as needed. These steps are repeated for each cycle.
There may be one or more communications links with one or more devices physically separated from the medicament delivery device 202 including, for example, a management device 204 of the user and/or a caregiver of the user, sensor(s) 206, a smartwatch 230, a fitness monitor 232 and/or another variety of device 234. The communication links may include any wired or wireless communication links operating according to any known communications protocol or standard, such as Bluetooth®, Wi-Fi, a near-field communication standard, a cellular standard, or any other wireless protocol.
The medicament delivery device 202 may interface with a network 222 via a wired or wireless communications link. The network 222 may include a local area network (LAN), a wide area network (WAN), a cellular network, a Wi-Fi network, a near field communication network, or a combination thereof. A computing device 226 may be interfaced with the network 222, and the computing device may communicate with the medicament delivery device 202.
The medicament delivery system 200 may include one or more sensor(s) 206 for sensing the levels of one or more analytes. The sensor(s) 206 may be coupled to the user 208 by, for example, adhesive or the like and may provide information or data on one or more medical conditions, physical attributes, or analyte levels of the user 208. The sensor(s) 206 may be physically separate from the medicament delivery device 202 or may be an integrated component thereof. The sensor(s) 206 may include, for example, glucose monitors, such as continuous glucose monitors (CGM's) and/or non-invasive glucose monitors. The sensor(s) 206 may include ketone sensors, other analyte sensors, heart rate monitors, breathing rate monitors, motion sensors, temperature sensors, perspiration sensors, blood pressure sensors, alcohol sensors, or the like. Some sensors 206 may also detect characteristics of components of the medicament delivery device 202. For instance, the sensors 206 in the medicament delivery device may include voltage sensors, current sensors, temperature sensors and the like.
The medicament delivery system 200 may or may not include a management device 204. In some embodiments, no management device is needed as the medicament delivery device 202 may manage itself. The management device 204 may be a special purpose device, such as a dedicated personal diabetes manager (PDM) device. The management device 204 may be a programmed general-purpose device, such as any portable electronic device including, for example, a dedicated controller, such as a processor, a micro-controller, or the like. The management device 204 may be used to program or adjust operation of the medicament delivery device 202 and/or the sensor(s) 206. The management device 204 may be any portable electronic device including, for example, a dedicated device, a smartphone, a smartwatch, or a tablet. In the depicted example, the management device 204 may include a processor 219 and a storage 218. The processor 219 may execute processes to manage a user's glucose levels and to control the delivery of the medicament to the user 208. The medicament delivery device 202 may provide data from the sensors 206 and other data to the management device 204. The data may be stored in the storage 218. The processor 219 may also be operable to execute programming code stored in the storage 218. For example, the storage 218 may be operable to store one or more control applications 220 for execution by the processor 219. Storage 218 may also be operable to store historical information such as medicament delivery information, analyte level information, user input information, output information, or other historical information. The control application 220 may be responsible for controlling the medicament delivery device 202, such as by controlling the automated medicament delivery (ADD) (or, for example, automated insulin delivery (AID)) of medicament to the user 208. The storage 218 may store the control application 220, histories 221 like those described above for the medicament delivery device 202, and other data and/or programs.
A display 240, such as a touchscreen, may be provided for displaying information. The display 240 may display user interface (UI) 223. The display 240 also may be used to receive input, such as when it is a touchscreen. The management device 204 may further include input elements 225, such as a keyboard, button, knobs, or the like, for receiving input form the user 208.
The management device 204 may interface with a network 224, such as a LAN or WAN or combination of such networks, via wired or wireless communication links. The management device 204 may communicate over network 224 with one or more servers or cloud services 228. Data, such as sensor values, may be sent, in some embodiments, for storage and processing from the medicament delivery device 202 directly to the cloud services/server(s) 228 or instead from the management device 204 to the cloud services/server(s) 228.
Other devices, like smartwatch 230, fitness monitor 232 and device 234 may be part of the medicament delivery system 200. These devices 230, 232 and 234 may communicate with the medicament delivery device 202 and/or management device 204 to receive information and/or issue commands to the medicament delivery device 202. These devices 230, 232 and 234 may execute computer programming instructions to perform some of the control functions otherwise performed by processor 210 or processor 219, such as via control applications 216 and 220. These devices 230, 232 and 234 may include displays for displaying information. The displays may show a user interface for providing input by the user, such as to request a change or pause in dosage, or to request, initiate, or confirm delivery of a bolus of medicament, or for displaying output, such as a change in dosage (e.g., of a basal delivery amount) as determined by processor 210 or management device 204. These devices 230, 232 and 234 may also have wireless communication connections with the sensor 206 to directly receive analyte measurement data. Another delivery device 205, such as a medicament delivery pen (such as an insulin pen), may be accounted for (e.g., in determining JOB) or may be provided for also delivering medicament to the user 208.
The functionality described herein for the exemplary embodiments may be under the control of or performed by the control application 216 of the medicament delivery device 202 or the control application 220 of the management device 204. In some embodiments, the functionality wholly or partially may be under the control of or performed by the cloud services/servers 228, the computing device 226 or by the other enumerated devices, including smartwatch 230, fitness monitor 232 or another wearable device 234.
In the closed loop mode, the control application 216, 220 determines the medicament delivery amount for the user 208 on an ongoing basis based on a feedback loop. For a medicament delivery device that uses insulin, for example, the aim of the closed loop mode is to have the user's glucose level at a target glucose level or within a target glucose range.
In some embodiments, the medicament delivery device 202 need not deliver one medicament alone. Instead, the medicament delivery device 202 may one medicament, such as insulin, for lowering glucose levels of the user 208 and also deliver another medicament, such as glucagon, for raising glucose levels of the user 208. The medicament delivery device 202 may deliver a glucagon-like peptide (GLP)-1 receptor agonist medicament for lowering glucose or slowing gastric emptying, thereby delaying spikes in glucose after a meal. In other embodiments, the medicament delivery device 202 may deliver pramlintide, or other medicaments that may substitute for insulin. In other embodiments, the medicament delivery device 202 may deliver concentrated insulin. In some embodiments, the medicament or medicament delivered by the medicament delivery device may be a coformulation of two or more of those medicaments identified above. In a preferred embodiment, the medicament delivery device delivers insulin; accordingly, reference will be made throughout this application to insulin and an insulin delivery device, but one of ordinary skill in the art would understand that medicaments other than insulin can be delivered in lieu of or in addition to insulin.
As was mentioned above, exemplary embodiments may provide dynamic customized IOB profiles per user. The IOB profiles are customized for a user based on insulin delivery history and glucose level history. The IOB profiles are dynamic in that they may be updated regularly in exemplary embodiments to adapt to the needs of the user.
In the exemplary embodiments, the IOB profiles of users may be captured by insulin decay curves that depict the remaining insulin action of a dose of insulin that was delivered to the respective users over time.
G
Δ(k)=b1GΔ(k−1)+b2GΔ(k−2)+b3GΔ(k−3)−KIΔ(k−3) (Equation 1)
where GΔ(k) is a delta between a predicted glucose level at cycle k and a target glucose level value, b1, b2, and b3 are weight coefficients for the past glucose values, IΔ(k−3) is a delta between the insulin dose delivered at cycle k−3, and K is a weight coefficient. The model can be simplified as:
G
Δ(k)=b1GΔ(k−1)+b2GΔ(k−2)+b3GΔ(k−3)+D(k) (Equation 2)
where D(k) is a disturbance at cycle k. The simplification of the model allows the model to be set as a model of only past glucose level values. This can expressed in matrix form g=Gb at 502. The matrices are as follows:
The parameters in matrix b may then be solved at 504 using the following equation:
b=(GTG)−1GTg (Equation 4).
Thus, the weight coefficients in matrix b are determined.
This model of insulin-glucose interactions may be updated.
In determining the model, certain data in the glucose level value history may be omitted from consideration.
With reference again to
Another option for producing an impulse response for the model with the determined parameters (i.e., weight coefficients) is depicted in the flowchart 1000 of
G(k+3)=b1G(k+2)+b2G(k+1)+b3G(k)+Kδ(k) (Equation 4).
With reference again to
If you plot the remaining area under the curve over time, this results in the graph shown in
The exemplary embodiments may analyze the resulting customized insulin decay curves to provide recommendations to the user to improve time in range for the user. Time in range denotes the time duration that a glucose level value of the user remains in a desirable range, such as within a defined range surrounding the target glucose level value of the user (e.g., 100 mg/dL to 150 mg/dL). The time in range for a user can be correlated to their DIA. DIA is the time from the injection of insulin until the entire metabolic effect of the insulin has ended (e.g., the time span of the insulin decay curve from injection until 0 insulin action is reached). Shorter DIA is correlated with better time in range and a user's DIA is reflective of their lifestyle and body physiology.
Recommendations may also be generated and conveyed when there is a significant deviation form initially calculated parameters.
With reference again to
Other recommendations than those detailed above may be used. The example recommendations are intended to be illustrative and not limiting.
The IOB values used by the control application 216 or 220 in exemplary embodiments may be separated into a bolus contribution to the IOB (designated as IOBbol) and the basal contribution to the IOB (designated as IOBAID). Hence, IOB may viewed as the sum of IOBbol and IOBAID. The IOBbol value may be useful in better constraining insulin deliveries following delivery of large insulin boluses than conventional systems that rely on a single IOB that does not take into account unique IOBbol and IOBAID values. As a user boluses more, the DIA decreases, according to methods described herein, so that the boluses do not unduly constrain AID insulin delivery. Moreover, DIAbol may be shorter than DIAAID to shorten the duration of time that the insulin delivery is constrained following large insulin boluses.
At 2006, IOBbol is used in the control system in predicting future glucose level values and constraining insulin bolus doses.
The DIAbol value may be dynamically varied based on the recent insulin bolus delivery history. DIAbol may be calculated as:
where, over the past X hours (e.g., 6 hours), DIA. is the maximum permitted DIA value, DIAmin is the minimum permitted DIA value, Ibol(i−k) is the bolus at cycle i−k, i is the current cycle index (e.g., 12 five-minute cycles per hour), and TDI is total daily insulin for a user. The result is that the DIAbol shortens as more insulin boluses have been delivered.
While exemplary embodiments have been described herein various changes in form and detail may be made without departing from the intended scope of the appended claims.
This application claims the benefit of U.S. Provisional Patent Application No. 63/343,739, filed May 19, 2022, the entire contents of which are incorporated herein by reference in their entirety.
Number | Date | Country | |
---|---|---|---|
63343739 | May 2022 | US |