Onboarding and Total Daily Insulin Compliance

Abstract

Disclosed are a device, a computer-readable medium, and techniques for providing an onboarding process and an adaptation process to a drug delivery device. A processor executing the onboarding process determines whether a history of insulin delivered to a user meets certain sufficiency requirements. The onboarding process enables the processor to cause the drug delivery device to administer insulin doses to the user according to a calculation of an initial total daily insulin dose determined based on the sufficiency of the insulin delivery history. The initial total daily insulin may be adapted according to an adaptation process when new insulin deliveries are collected. The insulin delivery history, if sufficient, may be used to set a total daily insulin dosage that enables automatic insulin delivery upon replacement of the drug delivery device. The adaptation process may be performed to modify the initial insulin delivery dose and provide an adapted insulin delivery dose.

Description

[Technical Field]

[0001] The described example provides features for a drug delivery system that enables onboarding of user data for use in closed-loop algorithms and implements adaptive techniques that continuously assess the user's insulin requirements using updated user data.

[0002] Related Applications This application claims priority to U.S. Patent Application No. 16 / 586,499, entitled "Onboarding and Total Daily Insulin Adaptability," filed September 27, 2019, the contents of which are incorporated herein by reference in their entirety. [Background technology]

[0003] To provide users with more accurate insulin dosing, diabetes management devices are available that work with continuous glucose monitors (CGMs) and wearable insulin injection devices. Wearable insulin injection devices are typically replaced after a few days if they are functioning properly. When the wearable insulin injection device is replaced, the diabetes management algorithm running on the diabetes management device may require the user to provide insulin dosing inputs (referred to as "open-loop" operation) while the algorithm collects data over a period of days or weeks before the diabetes management device can begin an automated insulin dosing regimen (referred to as "closed-loop" operation). As a result, while the diabetes management device is operating in open loop mode, the user may have to manually provide insulin dosing inputs for several days or weeks before the closed-loop, automated insulin delivery operation can begin.

[0004] Delays in initiating an automated insulin dosing regimen that is part of closed-loop operation are inconvenient for the user and limit the diabetes management device's ability to provide an accurate estimate of the user's true insulin needs for a short period of time before the wearable insulin injection device needs to be replaced again or to cycle through open-loop and closed-loop operation. Summary of the Invention

[0005] An example of a non-transitory computer-readable medium embodied with programming code executable by a processor is disclosed. When executing the programming code, the processor is operative to perform functions, including obtaining a portion of an insulin delivery history associated with a user. When executing the programming code, the processor can be operative to determine whether the portion of the insulin delivery history meets a sufficiency requirement. In response to determining that the insulin delivery history meets a sufficiency requirement, an upper safety limit may be selected as a limit for the amount of insulin delivered over a period of time. The selected upper safety limit may be an amount of insulin that exceeds an amount of insulin associated with a lower safety limit. An amount of insulin delivered over a period of time that is below the selected upper safety limit may be set. Delivery of an amount of insulin may be initiated in response to the set amount of insulin.

[0006] A device is disclosed that includes a processor, a memory, and a transceiver. The memory may be operative to store programming code, an artificial pancreas application, an onboarding application code, an adaptation application code, and data associated with the artificial pancreas application, the onboarding application code, and the adaptation application code. The transceiver may be communicatively coupled to the processor and operative to send and receive signals including information usable by or generated by the artificial pancreas application, the onboarding application code, or the adaptation application code. The programming code, the artificial pancreas application, the onboarding application code, and the adaptation application code may be executable by the processor. When executing the artificial pancreas application, the onboarding application code, or the adaptation application code, the processor is operative to control insulin delivery and perform functions. The functions include obtaining a portion of an insulin delivery history associated with a user. The insulin delivery history may include the amount of insulin delivered for each of several insulin delivery dosages administered to the user. The processor may determine whether the portion of the insulin delivery history meets insulin history sufficiency requirements. In response to determining that the insulin delivery history meets the insulin history sufficiency requirement, an initial total daily insulin value may be set. The initial total daily insulin value may be transmitted for receipt by the wearable drug delivery device. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 10 illustrates a flow chart of an exemplary process for determining settings of an insulin delivery system. [Figure 2] FIG. 1 illustrates an example process associated with an example situation related to the use of a wearable drug delivery device. [Figure 3]FIG. 10 shows a diagram illustrating a further example process associated with another example situation related to the use of a wearable drug delivery device. [Figure 4] FIG. 10 illustrates another example process associated with a further example situation related to the use of a wearable drug delivery device. [Figure 5] FIG. 10 illustrates yet another exemplary process associated with an exemplary situation related to the use of a wearable drug delivery device. [Figure 6] 10A-10C illustrate example processes associated with additional example situations related to the use of a wearable drug delivery device. [Figure 7] FIG. 1 illustrates functional blocks of a drug delivery system suitable for carrying out the example processes and techniques described herein. DETAILED DESCRIPTION OF THE INVENTION

[0008] Various examples provide methods, systems, devices, and computer-readable media for facilitating condensed onboarding of a user's insulin therapy program and / or adaptive schemes that operate to determine an accurate estimate of the user's insulin needs for any common insulin delivery system. For example, the user's estimate of what constitutes the user's insulin needs may be based on a specific user's total daily insulin (TDI) parameter. Additionally, exemplary processes allow a rational "onboarding" scheme to provide a starting estimate of TDI and a reasonable limit of maximum confidence when insulin delivery history is insufficient.

[0009] Some insulin delivery systems can keep track of past insulin delivery history. For example, the stored past insulin delivery history can keep track of when insulin doses are administered, the amount of insulin in the dose, the type of insulin administered (e.g., fast-acting, standard, intermediate-acting, long-acting, or the like), blood glucose measurements, etc. Using insulin delivery history, the described examples provide a method for total insulin delivery assessment within an automated insulin delivery system that uses insulin delivery history over increasingly longer historical periods to reduce the risk of hyperglycemia and hypoglycemia. Because nearly all insulin delivery is typically known to the insulin delivery system over time with high accuracy, the examples described herein use the known insulin delivery history to provide an assessment of total insulin delivery when starting a new drug delivery device and while the drug delivery device is in operation, and more accurately determine each user's total daily insulin (TDI) requirements.

[0010] Due to the accuracy of the described algorithm, the described example allows for the regression of the time range of insulin delivery history, the minimum valid insulin delivery history length, and the maximum difference between the timestamps of the first and last entries in the insulin delivery history for a sufficient period of time. That sufficient period is used to generate a TDI parameter, which is a robust and generalizable estimate of TDI for a particular user. The exemplary process operates to calculate this TDI parameter and can dynamically update the TDI estimate over time based on long-term changes to the user's physiology. The exemplary method may be robust enough to accommodate any short-term acute fluctuations in insulin sensitivity that may occur due to temporary life events such as illness, rapid weight loss, intense exercise regimens, or the like.

[0011] The example process may be used with any additional algorithms or computer applications that function to manage blood glucose levels, insulin delivery, and general overall insulin therapy. Such algorithms may be referred to as "artificial pancreas" algorithm-based systems, or more generally, artificial pancreas (AP) applications. AP algorithms function to provide automatic insulin delivery based on blood glucose sensor input, such as that received from a CGM. In one example, the artificial pancreas (AP) application, when executed by a processor, enables the system to monitor a user's glucose levels, determine the user's appropriate insulin level based on the monitored glucose levels (e.g., blood glucose concentration or blood glucose readings) and other user-provided information, such as carbohydrate intake, exercise duration, meal times, or the like, and take action to maintain the user's blood glucose level within an appropriate range. An appropriate blood glucose level range may be considered a target blood glucose level for a particular user. For example, a target blood glucose level may be acceptable if it is within the range of 80 mg / dL to 120 mg / dL, a range that meets clinical criteria for addressing diabetes treatment. However, an AP application enhanced by the methods and processes described herein may be able to more accurately determine insulin dosages and establish timing for administering established insulin dosages. As described in more detail with reference to the examples of Figures 1-7, the AP application can utilize insulin delivery history and other information to generate and send commands to a wearable drug delivery device, including, for example, a pump, to control delivery of determined insulin dosages to the user and modify future insulin dosages or timing, as well as control other functions.

[0012] The described example is advantageous and beneficial for any application of a "closed loop" processing algorithm or automatic insulin delivery mechanism, allowing for substantially immediate and safe initiation of automatic delivery upon first pod use, while allowing the delivery mechanism to adapt to any changes in the user's insulin needs over time.

[0013] The described process may be particularly advantageous when a user is first using or replacing a wearable drug delivery device such as an OmniPod® (Insulet Corporation, Billerica, Massachusetts) or a similarly configured device with similar capabilities. These wearable drug delivery devices can administer a dose of insulin for several days, but for ease of discussion, the number of days a wearable drug delivery device can be used may be limited to three days. Additionally, whether a user is first using a new wearable drug delivery device or replacing a used wearable drug delivery device, the installation of a new wearable drug delivery device or the installation of a replacement wearable drug delivery device (whether new or replacement) may be referred to as an initial installation or first installation.

[0014] As described in more detail below with reference to Figure 7, the wearable drug delivery device may be controlled by a processor operable to execute the AP algorithm described above and to perform the example processes described herein. The processor may be configured to be a component of a mobile device, such as a smartphone, a dedicated insulin therapy program processor, a tablet, a smart wearable device (e.g., a smart watch, a smart fitness device, or the like), or other type of mobile device. Alternatively, or in addition, the processor may also be part of the wearable drug delivery device or another device operable to communicate with the wearable drug delivery device.

[0015] In an example, a process called onboarding may be performed based on the availability of sufficient insulin delivery history upon initial or first placement of the wearable drug delivery device for a user's treatment. The onboarding process may be a process by which a processor can receive user parameters for controlling the wearable drug delivery device to provide automatic insulin delivery. In one example, the user parameters may include blood glucose measurements, administered doses of insulin (i.e., dosages), times at which insulin is administered, carbohydrate-to-insulin ratios, insulin sensitivity assessments, insulin adjustment factors, basal profiles, or the like. Of note, the basal profile may be a 24-hour profile of basal needs defined by start and end times for each interval and a basal delivery rate. For example, one basal profile may look like this: [Table 1]

[0016] "Base Profile" refers to the entire table above. Different users can have different base profiles depending on their individual needs.

[0017] If sufficient insulin delivery history is available and accessible, the onboarding process may be omitted. An example of an onboarding procedure could be the process of resetting total daily insulin (TDI) estimates when there are sufficiently long gaps in the user's insulin delivery history that the insulin delivery history is insufficient.

[0018] In another example process, user parameters used during onboarding to establish insulin delivery system settings that initiate automatic insulin delivery may be adapted over time by a process executed when the processor enters an adaptive mode. The processor may initiate the adaptive mode when it determines that the insulin delivery history is sufficient for the system to adjust performance over time based on new information, including insulin deliveries, new blood glucose measurements, or the like. The insulin delivery system settings may be updated by calculating updated parameters based on the new information and the received user parameters.

[0019] The combination of onboarding and adaptation processes during application of any "closed loop" or automatic insulin delivery mechanism allows automatic delivery to begin immediately and safely upon first pod use (i.e., while also adapting the delivery mechanism to any changes in the user's true insulin needs over time).

[0020] FIG. 1 shows a flow chart of an exemplary process for determining settings for an insulin delivery system. Process 100 may be executed by a processor operating to control a wearable drug delivery device over a period of time. For example, at 105, a portion of insulin delivery history associated with a user may be retrieved from a data storage device, such as the processor's memory, from a remote server, a cloud-based data storage system, or the like. At 110, the processor can determine whether the portion of insulin delivery history meets a sufficiency requirement. The evaluation of sufficiency history at 110 of the onboarding process may be performed at standard times when a user normally interacts with the wearable drug delivery device and / or personal diabetes management device (described in more detail with reference to FIG. 7). In one example, such as a typical tube pump drug delivery device, this evaluation at 110 may occur each time the user changes insulin containers in the insulin management and delivery system (not shown in this example). In an example, at 110, the processor can analyze the retrieved portion of insulin delivery history against predetermined criteria, if any, that meet the sufficiency requirement for insulin delivery history. For example, analysis of the insulin delivery history portion by the processor can perform adaption or onboarding when sufficient insulin delivery history is not available (i.e., insufficient insulin delivery history) and determine whether there is sufficient history to perform a safe onboarding process for the user.

[0021] The process at 110 in FIG. 1 can be summarized as follows: The following conditions can be evaluated to ensure that any TDI estimate covers a sufficient period and sufficient sample of insulin requirements across all times of the day: 1) The system must ensure that the TDI estimate covers at least a variable MIN of known insulin delivery history. 長さ 2)MIN 長さ The total known insulin history is MAX ブロックand 3) known insulin delivery history that meets the first two conditions may be greater than or equal to MAX 履歴 It may not be older than the date.

[0022] In one preferred example, MIN 長さ The time may be set to 48, or at least 2 days of insulin delivery history. ブロック The time may be set to 54 hours or a maximum span of 2.5 days. 履歴 may be set to 30 days, i.e., the insulin delivery history considered cannot be older than 30 days.

[0023] Time MIN 長さ The minimum length design is used to ensure there is enough data to calculate a reasonable estimate of TDI. ブロック The maximum span design is used to ensure that the available data is not overly weighted to a particular period of the day. For example, assessing a user's insulin needs over only the post-breakfast period from 8:00 AM to 12:00 PM for 12 days provides 48 hours of data that may not be representative of the user's true insulin needs. And, the insulin delivery history MAX 履歴 The maximum age design is performed to ensure that the system re-evaluates insulin delivery history if any long-term changes in insulin requirements are not captured due to large gaps in known insulin history.

[0024] An example of insufficient insulin delivery history may be when there are long gaps in a user's insulin delivery history. A long gap in insulin delivery history may be considered, for example, a gap longer than 2-8 hours in a 48-hour period or a 48-hour period that is older than 30 days. Of course, other gaps may also be considered long, such as, for example, 9 hours in a 36-hour period, 2 hours in a 24-hour period, 15 minutes in a 1-hour period, or the like.

[0025] Additionally, in certain examples, this insulin history evaluation may also consider short gaps in insulin history of less than 30 days. In these specific examples, the processor may consider the possibility of unknown insulin delivery history during these gaps and perform its calculations assuming that fixed or variable values of insulin may have occurred as insulin-on-board or IOB. In one example, this additional insulin delivery IOB エクストラ may be set to 1 / 6 of the TDI to represent one standard meal (1 / 2 of the TDI is typically due to meal boluses, and users typically take 3 meal boluses per day).

[0026] Returning to the example of FIG. 1 , in response to the determination at 110 that the insulin delivery history meets the sufficiency requirement, the processor can generate a confirmation signal confirming, based on the results of the analysis, that the insulin delivery history meets the sufficiency requirement of satisfying the total number of hours of data in consecutive periods within the previous number of days, and process 100 proceeds to 120. In certain examples, the onboarding and adaptive process can be combined with an automatic insulin delivery algorithm to reduce the constraint on the maximum insulin delivery allowed by the algorithm. At 112, this limit may be set using a multiplier A, which may be “two times” the basal insulin limit, and in certain examples, this is a reduction from a multiplier B, which, with sufficient history, may be “four times” the basal insulin limit, as set at 120.

[0027] For example, based on the determination at 110, the processor can limit the total daily insulin amount administered by the wearable drug delivery history to a multiple of the basal insulin dosage set by the user. For example, if the processor determines that the insulin delivery history is sufficient, a first multiplier of the basal insulin dosage, such as B (which may be equal to 4, 6, or 8), may be selected, while a second multiplier, such as A (which may be set to 1.5, 2, or 3), may be selected if the processor determines that the insulin delivery history is insufficient. In the example of sufficient insulin delivery history, the basal input limit may be set as four times the basal insulin dosage, while for insufficient insulin delivery history, the basal input limit may be set as two times the basal insulin dosage.

[0028] At 120, the processor can select a safety upper limit for the amount of insulin delivered per day, such as total daily insulin or the like. For example, the selected safety upper limit may be a basal limit between the maximum amount of insulin for delivery and the minimum amount of insulin delivered by the drug delivery device, multiplied by a multiplier B. The value B may be a multiplier applied to the amount of insulin delivered over a period of time. For example, the value B may be in the range of about 3.5 to 5.0, or a specific value of 4 or the like. In one example, the period of time to which the value B may apply may be an hour, a number of days such as 1 day, 2 days, or 3 days, or the like, a time period related to the life cycle of the drug delivery device, etc.

[0029] Conversely, if the processor determines at 110 that the insulin delivery history does not meet the sufficient requirements (e.g., the total number of hours does not meet the required total time (e.g., 48 hours), has too long gaps (e.g., more than 2-8 hours), and is older than the required age of the data (e.g., more than 30 days), the processor may trigger an onboarding mode to minimize any risk to the user. In the onboarding mode, the process 100 may proceed from 110 to 112. At 112, the processor may operate, in response to determining that the insulin delivery history does not meet the sufficient requirements, to select a lower safety limit for the amount of insulin to be delivered. The period during which insulin may be delivered at the lower safety limit may be 1 day (i.e., 24 hours), 12 hours, 8 hours, or 12 hours. or the like. The selected lower safety limit may be lower than the selected upper safety limit and exceed the minimum amount of insulin delivered by the drug delivery device. The value of the lower safety limit may be a multiplier having a value A that can be multiplied by the user's TDI-based basis to limit the maximum insulin delivery to be lower than standard use. This value A may be selected to improve user safety while still allowing delivery of enough insulin to maintain normal daily blood glucose variability. For example, the selected lower safety limit may be lower than the selected upper safety limit and exceed the minimum amount of insulin delivered by the drug delivery device. Because there is not enough insulin delivery history in this example, an initial amount of insulin delivered may be set at the time of installation of the drug delivery device.

[0030] The amount of insulin set to be delivered that day may be set below the selected lower safety limit (114). During the onboarding process, the system utilizes user-inputted basal parameters to calculate the TDI. For example, the AP algorithm can provide an average of the user's basal insulin input for use in the onboarding process. For example, the user's basal insulin input may be 0.6 units / hour of insulin in the morning, 1.2 units / hour of insulin in the afternoon, and 0.8 units / hour of insulin in the evening and at night. The algorithm functions to use the user's basal insulin average over a 24-hour period. Insulin needs do not change significantly over time. For example, a teenager's insulin dosage may only change by 20% within a year. In a specific example, the TDI is calculated by the sum of each user-inputted basal segment (weighted by the duration of each basal segment, which is typically defined as the difference between the start time of the basal segment and the end time of the basal segment) multiplied by 2, as shown in Equation 1 below: Formula 1 TDI オンボーディング =2Σb(t)*(t b、終了 -t b、開始 )

[0031] where b(t) is the basic segment of the user input, and t b、開始 is the time (in hours or fractions thereof) at which the basic segment begins, and t b、終了 is the time (in hours or fractions thereof) that the basic segment ends, and 24 represents the time in a day. This onboarding TDI is then used to guide the user through any manual or automatic insulin delivery, with the possibility of an additional safety flag that may be set to indicate to the system that the TDI estimate is based on insufficient history and that the system is not confident in its accuracy.

[0032] For example, at 114, the processor can set a lower safety limit for total daily insulin using the currently active user-inputted base profile for insulin delivery multiplied by a multiplier associated with the lower safety limit. The multiplier can have a value C that can be in the range of about 1.2 to 3.5 or the like. In one example, the period of time can be hours, a day, several days, such as 2 or 3, a time associated with the life cycle of the drug delivery device, or the like.

[0033] After the total daily insulin is set based on the lower safety limit at 114, the processor may indicate that there is insufficient insulin delivery history (116). For example, the processor may set the adaptive flag to false, i.e., not true, indicating that a process other than process 100 has insufficient insulin delivery history for adaptive mode and / or related functions.

[0034] After execution of either step 116 or step 120, process 100 may lead to decision step 130. At 130, the processor may determine whether the adaptive mode of the processor is active or inactive based on new information related to the amount of insulin delivered by the drug delivery device obtained from the updated insulin delivery history. For example, the processor may determine that the adaptive flag is set to true. If so, based on the result of the determination, the processor may obtain new information related to the amount of insulin delivered by the wearable drug delivery device from the updated insulin delivery history. For example, the new information may be information collected since the insulin delivery history was obtained in step 105. In one example, the processor may set or reset the daily total insulin (140) based on the new information (if the insulin delivery history is insufficient).

[0035] For example, assuming that the insulin delivery history is determined to be sufficient, a safety upper limit is selected, and the adaptive flag is set to true, the total daily insulin may be set (140) to the amount of insulin delivered over a period of time based on a weighted sum of the previously set total daily insulin, and, from the new information, the daily average of the amount of insulin delivered during the waiting period (e.g., based on the updated insulin delivery history). The weighting may be, for example, a ratio of 80:20, 60:40, 50:50, or the like, depending on conditions related to the insulin delivery history, blood glucose measurements more recent than the insulin delivery history, or the like. Of course, other weightings may be used, or a cost function, or the like, may be implemented to determine the new total daily insulin setting.

[0036] Alternatively, at 130, the processor may determine that the adaptation flag is not set to true (i.e., the adaptation flag is set to false), in which case process 100 proceeds to 133. At 133, the total daily insulin may be set to the amount of insulin delivered for a period of time based on a daily average of the amount of insulin delivered during the waiting period (e.g., new insulin delivery history). After 133, process 100 proceeds to 135 where the processor sets the adaptation flag to true, and the processor begins the adaptation mode.

[0037] After either step 140 or step 135 is performed, process 100 proceeds to 150. At 150, a determination is made whether the last insulin delivery occurred within the past Y hours. In this example, Y is a time value that can have a value of minutes or hours, such as 6 hours, 120 minutes, or the like. For example, the wearable drug delivery device can be activated to provide an acknowledgment signal to the processor in response to receiving an activation signal or in response to a dose of insulin being delivered. Alternatively, the wearable drug delivery device can send a signal whenever insulin is delivered by a pump controller coupled to a pump mechanism of the wearable drug delivery device. In this example, the pump controller may not provide confirmation that drug delivery occurred or may provide some indication of a failure in insulin delivery by the drug delivery device (e.g., no insulin is available, the reservoir is empty, the pump mechanism has failed, or the like).

[0038] In one example, in response to a determination that the last insulin delivery did not occur within the past Y hours, process 100 can proceed to 155. At 155, a gap flag can be set to true, which may mean that a gap exists that renders the insulin delivery history (now including any updated or new data) insufficient. Additionally, in response to a determination that no insulin delivery occurred within a predetermined last insulin delivery period, the processor can establish an initial insulin on-board (IOB) setting equal to a percentage of the set total daily insulin dosage. This is also a safety constraint to prevent too much insulin from being delivered to the user based on the calculations performed by the processor executing the AP algorithm and the adaptive and on-board programming code. This IOB may not be included in the insulin delivery history so that the TDI calculations during the remainder of the onboarding and adaptive processes are not affected. After step 155, process 100 proceeds to 160.

[0039] Conversely, in response to a determination at 150 that the last insulin delivery occurred within the past Y hours, process 100 proceeds to 160 .

[0040] At 160, the processor can transmit the set total daily insulin dosage, the selected safety limit setting, and the gap flag setting to the wearable drug delivery device (WDDD) via a wired or wireless connection established with the wearable drug delivery device. From 160, process 100 can proceed to 170.

[0041] At 170, the processor can initiate delivery of an amount of insulin according to the selected safety upper limit. For example, the processor can send a signal via a connection established with the wearable drug delivery device, causing the wearable drug delivery device to activate its mechanism to deliver the appropriate amount of insulin to the user. The appropriate amount of insulin is a dose associated with the set total daily insulin or a dose less than the selected safety upper limit.

[0042] After 170, the process 100 can return to 105 until another pod is ready to be launched.

[0043] In certain examples, process 100 can provide different settings within an AP application or algorithm based on the sufficiency of insulin delivery history. In a first example, when an initial pod is activated and insulin delivery history is insufficient (step 110), the AP application can set the safety limit to A times the basal input dose (step 112), the TDI may be set to the active user-input base profile (step 114), and adaptive may be set to false at activation (step 116). In another example, a first pod that is activated and has access to sufficient insulin delivery history (step 110) can have different settings from the first pod based on process 100. For example, the settings for a subsequent pod can set the safety limit to B times the basal insulin dose (step 120), the adaptive flag may be set to false at activation (this may be a default value so the setting is carried over from the previous pod (first pod) or the like (step 130)), and the TDI may be set based on the previous pod's usage. For the second pod, a subsequent pod that follows the first pod and has sufficient insulin delivery history, the safety limit can be set at B times (e.g., 4 times in some instances) the basal input dose. The TDI is the weighted sum (1 番目 Weight of X previous pod usage +2 番目 The weight X may be set to the previous pod activation TDI setting, and the adaptive flag may be set to true. For any pod, once the pod is activated, the TDI parameters that the AP application operates on may not change during the pod's lifecycle. However, the pod's actual TDI, as measured by insulin delivered and reflected in the insulin delivery history, may differ from the TDI set during each pod activation. Therefore, when the adaptive flag is set to true, a weighted sum of the measured TDI and the activated TDI is used to activate subsequent pods.

[0044] It may be helpful to explain the details of the onboarding and adaptation processes with reference to Figures 2 through 6. In the example of Figure 2, process 100 may be performed by a processor in a personal diabetes management device, a smart accessory device, a drug delivery device, or the like (or in a distributed processing configuration among various devices) whenever a wearable drug delivery device is replaced.

[0045] For example, the onboarding and adaptation processes may be performed automatically with no or limited user interaction by the processor or pod at each “pod activation” (as used herein, the term “pod” is equivalent to a wearable drug delivery device, and the terms are used interchangeably). For example, at activation of pod 210, there is no past or previous history (in this example, no short-term or long-term history), and as a result, the insulin delivery history is determined to be insufficient at 110 in FIG. 1 . In response to a determination that the insulin delivery history is insufficient for the initial configuration of pod 210, onboarding logic (executing on the processor) may initiate process 100 at steps 112-116 in FIG. 1 . For example, at activation of pod 210 (row A), the determination by the processor that there is insufficient insulin delivery history results in a closed-loop algorithm executed by the processor that limits the total insulin delivered in any one cycle. This may be 1, 5, 10, 15 minutes, or the like, and may be less than or equal to C times the average of the user's input basal profile (or "2x" and Equation 1, as shown in the example of FIG. 2). Further, in this example, the processor adds 1 / 6 of the user's total daily insulin, estimated as 2 times the sum of the user's basal profile as in Equation 1, as there is a recent gap in insulin delivery history of more than 6 hours, to initiate on-board insulin to further limit insulin delivery. Of course, other fractions or percentages of total daily insulin or basal insulin delivery may be selected or set. This setting may be used for the life cycle of pod 210 (e.g., approximately 3 days, or the like). After the life cycle of pod 210 has expired, another pod, such as pod 220, may be activated. As part of activating pod 220, the processor may obtain the insulin delivery history of pod 210. As shown in row B, the insulin delivery history of pod 210 may span approximately 72 hours (of insulin delivery history (IDH)) without any gaps. As a result, the processor can assess that the insulin delivery history is sufficient.As a result of determining that the insulin delivery history is sufficient, the processor can set a safety limit for the total daily insulin that can be delivered at B times (or as shown in this example, 4 times (4x))) the basal insulin delivery limit for that day.

[0046] Pod 220 may reach the end of its life cycle; during activation of pod 230, the processor can obtain a new insulin delivery history for pod 220. Using the new insulin delivery history for pod 220, the processor can set a safety limit to B times the total daily insulin (TDI). In the example of Figure 2, each of pods 230, 240, and 250 may have accumulated sufficient insulin delivery history and be activated with a safety limit set to B times the total daily insulin (TDI).

[0047] In the example of FIG. 3 , evaluation of the insulin delivery history may reveal insufficient insulin delivery history between activations of each new wearable drug delivery device; for example, the insulin delivery history may be less than a threshold number of hours, such as 48 hours. Because the insulin delivery history of the pod 310 in the example of FIG. 3 does not reach the threshold number of hours, activation of the pod 310 may set the loaded insulin to a percentage or fraction of the total daily insulin. In the example of FIG. 3 , a gap in insulin delivery history of more than six hours may cause the processor to operate to establish a setting for the pod 310 for loaded insulin at 1 / 6 of the total daily insulin. Additionally, a safety limit may be set at A times the basal insulin limit, or in this example, twice the basal insulin limit.

[0048] When operating properly, the processor (not shown in this example) can, for example, send a control signal to the pod 310 instructing the pod 310 to deliver a dose of insulin. In response to delivering the dose of insulin, the pod 310 can generate an acknowledgment signal that is sent to the processor.

[0049] In an example, at 311, the pod 310 may only be used for 42 hours (2 days) before it becomes defective, runs out of insulin, or experiences another malfunction resulting in non-delivery of insulin. In response to the malfunction, the pod 310 may be operable to generate an alarm or other indication, for example, that insulin is not being delivered, or may forward an alarm signal to the processor. The processor may be operable to indicate an alarm condition if no acknowledgment signal is received within a predetermined period of time, or the like. In one example, the transceiver within the pod 310 may have lost connection with the processor or have some other communication failure, even though insulin is being delivered. The pod 310 and / or processor may be operable to track how long the alarm has been set to determine whether the insulin delivery history is sufficient.

[0050] Upon startup of the pod 320, the processor can operate to determine that a gap of six hours results in insufficient insulin delivery history. As a result, upon startup of the pod 320, a gap in insulin delivery history of more than six hours can cause the processor to establish an onboard insulin setting of 1 / 6 of the total daily insulin, with a safety limit set at twice the basal insulin limit. The pod 320 can provide data for approximately 24 hours during which the pod 320 can operate properly and deliver insulin according to the pod setting indicated by the processor. Of course, the pod 320 may become defective or be removed from the user. As a result, in this example, collection of insulin delivery history data may again fail, resulting in insufficient insulin delivery history at the end of the pod 320's lifecycle.

[0051] Activation of the pod 330 is an example of an improvement and refinement of the onboarding example. In this example, upon activation of the pod 330, the processor may operate to determine that the insulin delivery history is approximately 2.75 days, or 68 hours out of 72 hours, without gaps of more than 6 hours (recall that the gaps for the pod 310 are 6 hours), and that the insulin delivery history is less than 30 days (i.e., 48 hours (or 2 days) since the last data was collected, and 72 hours (or 3 days) since the insulin delivery history data has been continuously collected). Based on this information, the processor may operate to determine that the insulin delivery history is sufficient and set the safety limit to B times the basal insulin limit, or, in this example, 4 times the basal insulin limit. However, because the last insulin delivery was more than Y hours, such as 6 hours in this example, the gap flag is set to true, and the on-board insulin is set to a percentage or fraction of the total daily insulin, such as 1 / 6 or the like. The flexibility of the proposed adaptive approach means that this additional insulin on board at the start of each pod session can be utilized to constrain the operation of the algorithm without affecting the estimate of total daily insulin requirements. For example, with sufficient insulin history, pods 340 and 350 can all begin operating in adaptive mode (e.g., pod 330 as shown in FIG. 3, where insulin history for adaptation is evaluated upon activation of pod 340).

[0052] In the example of FIG. 3, pod 330 operates continuously without expiring insulin delivery history data, as do pods 340 and 350, which are activated in a manner similar to pod 330 according to the example process shown in FIG. 1.

[0053] The example of Figure 4 illustrates another exemplary process. In the example of Figure 4, during activation of the pod 410, the processor may be operative to note that the insulin delivery history is insufficient. As a result, in the example of Figure 4, the processor may be operative to establish a setting for the pod 410 for insulin loaded at 1 / 6 of the total daily insulin. Additionally, a safety limit may be set at A times the basal insulin limit, or in this example, 2 times the basal insulin limit.

[0054] As shown in row 4A, pod 410 operates and provides data throughout its lifecycle. The end of the pod 410 lifecycle is when pod 410 is replaced with pod 420. Upon start-up of pod 420, the processor may operate to determine that the insulin delivery history provided during the lifecycle of pod 410 is sufficient, so that the safety limit of pod 420 can be set to B times the basal insulin limit. The adaptive flag can be set to false, and the total daily insulin can be set as the daily average of insulin delivered according to pod 410's new insulin delivery history (insulin history for starting TDI estimate, pod 420, as shown in row 4A).

[0055] The life cycle of the pod 420 is shortened, and the processor or pod 420 can generate an alert. As a result of the shortened life cycle of the pod 420, as shown in row 4B, the insulin delivery history is missing data from the last 24 hours (as shown at 421). The period of missing data (i.e., 24 hours) may exceed a threshold Y hours of missing data (e.g., 6 hours) (as evaluated at 150 in FIG. 1). The processor may operate to determine that the insulin device's history is sufficient because there is a gap of more than 6 hours, but less than 30 days of data, resulting in 48 consecutive hours of uninterrupted insulin delivery history data. As a result, the processor may operate to set the total daily insulin based on the insulin delivery history, setting a safety limit of B times the basal insulin limit, but limiting the loaded starting insulin to a percentage or fraction of the loaded insulin. For example, the processor may operate to set the loaded insulin to 1 / 6 of the total daily insulin, or the like.

[0056] Because pod 430 has generated insulin delivery data over its entire 72-hour (or 3-day) lifecycle, providing sufficient insulin delivery history (as shown in row 4C), starting up pod 440 is simple, including setting the adaptive flag to true for point 440. Similarly, the lifecycle of pod 440 is completed with sufficient insulin delivery history without gaps (as shown in row 4D), so starting up pod 450 is simple, including setting the adaptive flag to true for point 450. Pods 430, 440, and 450 can all begin operating in adaptive mode with sufficient insulin history (e.g., insulin history for adaptive, pod 430, etc., as shown in FIG. 4).

[0057] Another example of how process 100 of FIG. 1 responds to insufficient insulin delivery history is shown in FIG. 5. The example of FIG. 5 illustrates an example of process 100 responding to long gaps in insulin delivery history data. In the example of FIG. 5, during startup of pod 510, the processor can be operative to note that there is insufficient insulin delivery history. As a result, in the example of FIG. 5, the processor can be operative to establish a setting in pod 510 for insulin loaded at 1 / 6 of the total daily insulin. Additionally, a safety limit may be set at A times the basal insulin limit, or in this example, 2 times the basal insulin limit.

[0058] As shown in row 5A, pod 510 operates and provides data throughout its lifecycle. At the end of the lifecycle of pod 510, it is time to replace pod 510 with pod 520. Upon start-up of pod 520, the processor may operate to determine that the insulin delivery history is sufficient, set a safety limit to B times the basal insulin limit, and set the daily average of insulin delivered according to the daily total and new insulin delivery history, for example, as a weighted sum of the previous daily total insulin settings.

[0059] In this example, after a period of 48 consecutive hours, the pod 520 may result in the generation of an alert indicating that the insulin delivery history has not been updated for some reason. Additionally, insulin delivery history is not collected for more than 28 days. For example, a user may stop using the pod (e.g., wearable drug delivery device) for some reason.

[0060] In this example, the missing data exceeds 28 days (e.g., 28 and a half days, or any fractional number greater than 28 days). When pod 530 is activated, the processor can operate to determine that the insulin delivery history is insufficient because, even if the last data in the insulin delivery history is from a consecutive 48-hour period, the gap in data exceeds 28 days, which makes the data at the beginning of the consecutive 48-hour period older than a threshold of 30 days. As a result of the data at the beginning of the consecutive 48-hour period being older than 30 days, the insulin delivery history is insufficient. Therefore, when the processor can operate to set the total daily insulin using the average user-entered basal insulin value, the safety limit is twice the basal insulin limit, and the gap flag is set to true.

[0061] As shown in row 5B, the insulin delivery history from pod 530 is sufficient for activation of pod 540. Upon activation of pod 540, the processor may operate to determine that the insulin delivery history is sufficient because the insulin delivery history was collected over 72 consecutive hours with no gaps, and the 72 hours of data is not older than 30 days. Because the insulin delivery history is sufficient, the processor may operate to set a safety limit to B times the basal insulin limit (e.g., 4 or 6 times), and may set the total daily insulin, for example, as the daily average of insulin delivered according to the new insulin delivery history. Because pod 540 is the first pod at B times the basal insulin limit, the total daily insulin is set to the daily average of insulin delivered according to the new insulin delivery history. This may be considered a new starting TDI estimate for pod 540.

[0062] With sufficient insulin delivery history generated during the lifecycle of pod 540 (as shown in row 5C), the processor can use that sufficient insulin delivery history when powering up pod 550 to generate a new total daily insulin value and maintain a safety limit setting of B times (e.g., 4 times) the basal insulin limit. Pod 55 can begin operating in adaptive mode.

[0063] As discussed in the previous example, each day, the adaptability and onboarding process continuously updates the insulin history. For example, insulin delivery data collected each day can replace previous history from the insulin delivery history, resulting in the AP algorithm more accurately estimating onboard insulin and adapting the total daily insulin to best match the user's insulin dosing requirements. As long as the user consistently uses the AP algorithm while the adaptability mode automatically enables automatic insulin delivery for approximately seven days, approximately 80% of the difference between the current insulin value and the substantially optimal value will be overcome.

[0064] In another example, a user may manually administer a dose of insulin before changing the pod. As a result, the insulin delivered may exceed that indicated by the insulin delivery history. The onboarding process can account for this possibility and apply an insulin delivery correction factor to conservatively deliver insulin so as not to exceed either the upper or lower safety limits.

[0065] As noted above, the disclosed processes and applications may include an adaptive mode in which the processor changes settings when it receives data from other components, such as a blood glucose sensor or a wearable drug delivery device (i.e., a pod), which are described in more detail with reference to FIG. 7.

[0066] Below is a discussion with reference to Figure 6 of an example of an adaptation process that is triggered when there is sufficient insulin delivery history to calculate an accurate estimate of TDI. In the proposed example, if there is sufficient history based on the above evaluation, the system can trigger a smart adaptation process to leverage known insulin delivery history and relax existing safety limits when there is more confidence in the user's insulin needs.

[0067] The goals of the adaptation process are to adjust the onboarding TDI, which may differ from the actual TDI; compensate for a significant portion of the difference between the onboarding TDI and the true TDI (i.e., the actual user's TDI) over the short period of use since onboarding; and adjust the TDI based on changes in the user's needs that cannot be handled by the artificial pancreas algorithm (e.g., an aging teenage user).

[0068] Over successive years of use, adaptive mode is expected to improve compensation for long-term changes over time (e.g., increases of 26% or more / year and 5-10 times the changes during childhood).

[0069] An example of the adaptive mode is shown in the example of FIG. 6. Upon initial activation of pod 610, no past insulin history is available, and as a result, the processor determines that the insulin delivery history is insufficient. Based on the determination of insufficient insulin delivery history, the processor can set a total daily insulin level based on the average of the user-entered basal insulin dosage and a safety limit of A times the basal limit (in the example of FIG. 6, A equals 2). Upon activation of pod 610, the processor can generate a time stamp indicating, for example, the beginning of the life cycle of pod 610. In one example, the processor can generate a time stamp each time a signal, or an acknowledgment signal, indicating activation of insulin delivery by the wearable drug delivery device is received from a pod, such as pod 610.

[0070] Row 6A shows each day labeled with the AI that the pod (i.e., wearable drug delivery device) is used. When in adaptive mode, the processor may be operative to collect insulin delivery data and blood glucose measurement data from a blood glucose sensor (described in more detail with reference to the example of FIG. 7) for each AI on each day, if available. Of course, the processor may be operative to collect other data, such as user-input data related to meal carbohydrates, exercise, bolus dosage, insulin type, or the like.

[0071] In this example, during the life cycle of the pod 610, the processor can be operative to collect insulin delivery history data for days A, B, and C. At the end of the life cycle of the pod 610, the processor can be operative to activate the pod 620. In one example, the processor can access three days (i.e., days A, B, and C) of insulin delivery history data during activation of the pod 620. Alternatively, the processor can obtain updated insulin delivery history data collected during operation of the wearable drug delivery device 610, which is the replacement wearable drug delivery device. Upon activation of the pod 620, the processor can determine that the insulin delivery history is sufficient and set the daily total insulin based on the insulin delivery history from days A, B, and C. Alternatively, the processor can obtain new information related to the amount of insulin delivered by the drug delivery device from the updated insulin delivery history. The processor can determine that the adaptive mode is active and accordingly set the total daily insulin dosage at a weighted sum of the previously set total daily insulin dosage and the daily average of insulin doses based on the updated insulin delivery history.

[0072] For example, when in adaptive mode, the processor may set the total daily insulin for the pod 620 equal to the average insulin delivered over the past three days (eg, A, B, and C) according to Equation 2.

[0073] Formula 2 TDI ポッド620 =(I A +I B +I C ) / 3 where TDI is the total daily insulin for each pod, I A is the insulin delivered on day A, I B is the insulin delivered on day B, and I C is the insulin delivered on day C.

[0074] The processor can set the TDI as shown in Equation 2 and transmit the set total daily insulin dosage for receipt by the wearable drug delivery device (i.e., pod 620). The life cycle of pod 620 can extend over days D, E, and F. During the life cycle of pod 620, the insulin delivery history can include data collected during days D, E, and F, as shown in row 6B. As long as the insulin delivery history is sufficient, the processor can remain in adaptive mode. Upon startup of pod 630, the processor can read the previous total daily insulin setting (i.e., TDI ポッド620 ) and the average of the average insulin delivered over the last three days (e.g., D, E, and F). This is shown, for example, in step 140 of FIG. 1. Equation 3 shows an example.

[0075] Formula 3 TDI ポッド630 =0.4*TDI ポッド620 +0.6*(I D +I E +I F ) / 3 where TDI is the total daily insulin for each pod, I D is the insulin delivered on day D, I E is the insulin delivered on day E, I F is the insulin delivered on day F, and the divisor 3 is the number of days.

[0076] The weights 0.4 and 0.6 may be selected based on the confidence level of the insulin-on-board calculations for the user over the lifecycle of the previous pod. For example, a weighted confidence may be generated based on the ratio of automatically delivered insulin doses to the number of user-inputted insulin doses delivered. In this example, the processor may maintain a count of the number of insulin doses automatically delivered by the wearable drug delivery device and a count of the number of user-inputted insulin doses delivered by the wearable drug delivery device over a period of time. The period may be, for example, a day over the lifecycle of the previous pod or the current lifecycle of the currently running pod. The reliability of insulin delivery during days with a higher proportion of automatic delivery compared to user-requested insulin delivery may be weighted more highly. As a result of a higher confidence value, recently determined total daily insulin values may be weighted more heavily. Alternatively, a low confidence score may cause the adaptive algorithm to weight recently determined total daily insulin values less heavily.

[0077] In some examples, a pod or wearable drug delivery device may malfunction but be replaced with a new pod or wearable drug delivery device almost immediately. Such a scenario is illustrated with respect to pod 630. As shown in row 6C, new insulin delivery history data is collected for only one day, day G. The malfunction of pod 630 may generate an alert. In response to the generated alert, pod 630 may be replaced almost immediately with pod 640. As a result of the immediate replacement, future data is not indicated as not being collected, and there is no detectable gap in the new or updated insulin delivery history. Upon startup of pod 640, data collected for new or updated insulin delivery history during the life cycle of pod 630 (i.e., day G) is used in determining a new total daily insulin estimate for pod 640. However, in this example, because a limited amount of data, only one day's data, is added to the new or updated insulin delivery, the processor may adjust the weighting of each parameter as shown in Equation 4.

[0078] Formula 4 TDI ポッド640 =0.8*TDI ポッド630 +0.2I G where TDI is the total daily insulin for each pod and I G is equal to the average insulin delivered on day G.

[0079] The weights of 0.8 and 0.2, respectively, may be selected based on a determination by the processor that each new insulin delivery history is limited to one day or less. Alternatively, or in addition, the weights 0.8 and 0.2 may be selected based on a weighted confidence as described above. Because the new insulin delivery history is limited, the new insulin delivery history may be limited to one day or less. ポッド630) may not be considered as reliable as the insulin delivery history used to determine the total daily insulin for the previous pod. As a result, the processor may apply a lesser weight (e.g., 0.2) to the average insulin delivered on day G and weight the total daily insulin setting (e.g., TDI) for the previous pod. ポッド630 ) may operate to apply a greater weight (e.g., 0.8).

[0080] As shown in row 6D, pod 640 may operate for two days, day H and day I, before experiencing a malfunction. Pod 640 may generate an alert in response to the malfunction. In response to the malfunction, pod 640 may be replaced almost immediately with pod 650. As a result of the immediate replacement, future data is not indicated as not being collected, and there is no detectable gap in the new or updated insulin delivery history. Upon startup of pod 640, the processor may be operative to determine that data collected for new or updated insulin delivery history during the lifecycle of pod 640 (i.e., day H and day I) may be used to determine a new total daily insulin estimate for pod 650. Additionally, the processor may be operative to determine that the new or updated insulin delivery history collected during the lifecycle of pod 640 includes two days of insulin delivery history compared to the one-day insulin delivery history collected during the lifecycle of pod 630. As a result of the determination, the processor may determine that the new or updated insulin delivery history collected during the lifecycle of pod 640 includes two days of insulin delivery history compared to the one-day insulin delivery history collected during the lifecycle of pod 630. ポッド650 ) may be operated to adjust the weight of the total daily insulin estimate. For example, the processor may set the total daily insulin as shown in Equation 5 below:

[0081] Formula 5 TDI ポッド650 =0.6*TDI ポッド640 +0.4*(I H +I I ) / 2 where TDI is the total daily insulin for each pod, I H is the insulin delivered on day H, and I I is the insulin delivered on day I.

[0082] As shown, the total daily insulin setting for each pod may be determined at the time of each pod's startup based on data collected during the lifecycle of the previous pod. In some instances, the insulin delivery history of the immediately preceding pod may be deemed most relevant for setting the total daily insulin.

[0083] In one example, the onboarding and adaptation algorithm executed by the processor can maintain a calculation of the number of insulin doses automatically delivered by the wearable drug delivery device and the number of user-inputted insulin doses delivered by the wearable drug delivery device over a period of time, such as a day or 24 hours. As a result, instead of performing a general summation of all insulin deliveries throughout the day, the processor can generate a “weighted confidence” of total daily insulin delivery. For example, when the onboarding and adaptation algorithm is combined with a closed-loop automatic insulin delivery algorithm (such as an artificial pancreas (AP) algorithm), a higher proportion of automatic insulin delivery (i.e., delivery initiated by the AP algorithm) compared to manual delivery (i.e., delivery initiated by the user) may result in a higher reliability of insulin delivery that matches the user's actual needs. In this example, the adaptation algorithm can assign a higher weight to insulin delivery during days when a higher proportion of automatic delivery occurs compared to user-requested insulin delivery.

[0084] An advantage of the above adaptive process is its resilience to short-term but significant changes in insulin delivery while achieving the above-referenced objectives of the adaptive process. The adaptive process, performed while the processor is in adaptive mode, allows for robust execution that accommodates missing data points. For example, illness, missed boluses, or life events should not significantly impact the TDI estimate or long-term changes in insulin delivery. Additionally, missing insulin history should not significantly impact the TDI estimate.

[0085] Given these objectives, the proposed adaptive approach evaluates all past insulin delivery history at each pod replacement cycle and attempts to perform an exponential moving average of daily insulin requirements between the previous total insulin delivery value and the current insulin delivery value.

[0086] In this example, the overall adaptability of the insulin delivery history, such as that described with reference to the examples of FIGS. 2-6, can be expressed by the following Equation 6:

[0087] Formula 6 TDI N =(1-F 適応 n 日、新しいインスリン·データ )TDI N-1 +F 適応 New insulin data

[0088] Here, TDI N represents the user's TDI estimate for the Nth adaptation step (or cycle of steps 105-170 in Figure 1), and F 適応 represents the convergence factor, which describes how quickly the TDI estimate adapts to insulin delivery data from new insulin delivery history. New insulin data represents any insulin delivery history that has become available since the last TDI calculation and that was not used in the (N-1)th estimate of the user's TDI, where n 日、新しいインスリン·データ represents the number of days of new insulin data that are available in the new insulin delivery history and the total number of days of new insulin data. For example, the Nth adaptation of a user's TDI is TDI N =(1-0.2*3)TDI N-1 +0.2*3*(A+B+C) / 3=(1-0.2*3)TDI+0.2*(A+B+C), where F 適応 is (0.2), 3 is n 日数、新しいインスリン·データ Equal to TDI N-1 is the previous TDI, and A, B, and C represent the total amount of insulin used by the user per day.

[0089] Various methods are available for 適用This factor may be used to determine the optimal value of F. For example, several use cases may be examined to determine whether the example value of this factor, 0.2, is appropriate. This factor may be adjusted based on the user's actual rate of convergence to TDI. 適用 The value of represents the convergence rate at which the Nth estimate of TDI value converges to the user's actual TDI requirement, and F 適用 The higher the value of 、 It can converge more quickly to the user's actual needs, but is more vulnerable to fluctuations in user sensitivity. F 適用 The optimal value of F can be estimated by assessing the average variability of a user's insulin requirements and assessing the acceptable risk of over- or underestimating a user's TDI requirements in the case of noise. 適用 The optimal value of may be the value that minimizes risk while maximizing the rate of convergence to the user's actual average TDI requirement (i.e., the average TDI that needs to be delivered to this particular user).

[0090] The following figure shows various use cases comparing different starting TDIs with a true TDI of 48U, as well as the impact of changes in daily insulin requirements and the sensitivity of the system to these changes. The preceding description of the onboarding and adaptive algorithms may be expanded to incorporate other factors.

[0091] Because the above processing involves storing data that may not reside in the pod or wearable drug delivery device, the example process of FIG. 1 and the examples of FIGS. 2-6 may be performed by a computer application running on a personal diabetes management device (PDM), a smartphone, a wearable smart device (e.g., a smart watch, a GPS device, or the like), a long-term (e.g., one or two years of use) wearable insulin delivery device, or the like. However, larger pumps may have sufficient computing power and data storage capabilities to perform the described processes. These and other examples may be discussed in more detail with reference to the functional block diagram of an example diabetes treatment system shown in FIG. 7.

[0092] While a few example hardware configurations are provided above, alternative hardware configurations may make processing capabilities available in the pod or wearable drug delivery device via wireless communication capabilities, and any new or previously collected data may be stored in a separate device within wireless communication range or accessible via another device within wireless communication range. For example, the pod may include a processor running a computer application that enables the foregoing examples and operates to communicate with a smartphone. The smartphone may store new or previously collected data or access a remote server, such as a cloud-based server.

[0093] It may be helpful to discuss an example drug delivery system that can implement the example processes of Figures 1 to 6. Figure 7 shows an example drug delivery system 700.

[0094] The drug delivery system 700 may operate to execute an AP application including functionality to provide an onboarding process and to execute an adaptation process to change settings established during the onboarding process. The drug delivery system 700 may be an automated drug delivery system that may include a wearable drug delivery device (pump) 702, a blood glucose sensor 704, and a drug delivery management device (PDM) 706. The system 700, in one example, may also include a smart accessory device 707, which may communicate with other components of the system 700 via either wired or wireless communication links, such as 791-793.

[0095] In one example, the wearable drug delivery device 702 can be attached to the body of a user, such as a patient or diabetic, and deliver any therapeutic agent to the user, including any drug or medication, such as insulin or the like. The wearable drug delivery device 702 can be, for example, a wearable device worn by the user. For example, the wearable drug delivery device 702 can be directly coupled to the user (e.g., attached directly to a body part and / or skin of the user via an adhesive or the like). In one example, a surface of the wearable drug delivery device 702 can include an adhesive to facilitate attachment to the user.

[0096] The wearable drug delivery device 702 can include several components to facilitate the automatic delivery of a drug (also called a therapeutic agent) to a user. The wearable drug delivery device 702 can store a drug and be operable to provide the drug to a user. The wearable drug delivery device 702 is often referred to as a pump or insulin pump, in reference to the operation of expelling the drug from a reservoir 725 for delivery to the user. While the example refers to a reservoir 725 that stores insulin, the reservoir 725 can be operable to store other drugs or therapeutic agents suitable for automatic delivery of morphine or the like.

[0097] In various examples, the wearable drug delivery device 702 may be an automated wearable drug delivery device. For example, the wearable drug delivery device 702 may include a reservoir 725 for storing a drug (such as insulin), a needle or cannula (not shown) for delivering the drug into the user's body (which may be subcutaneous), and a pump mechanism (machine) 724 or other drive mechanism for transferring the drug from the reservoir 725 through the needle or cannula (not shown) to the user. The pump mechanism 724 may be fluidly coupled to the reservoir 725 and communicatively coupled to a processor 721. The wearable drug delivery device 702 may also include a power source 728, such as a battery, piezoelectric device, or the like, for powering the pump mechanism 724 and / or other components of the wearable drug delivery device 702 (such as the processor 721, memory 723, and communication device 726). Although not shown, a power source for providing power may also be included in each of the sensor 704, smart accessory device 707, and personal diabetes management device (PDM) 706.

[0098] The blood glucose sensor 704 may be a device communicatively coupled to the processor 761 or 721 and may be operable to measure blood glucose levels at predetermined time intervals, such as every 5 minutes or the like. The blood glucose sensor 704 may provide several blood glucose measurements to a processor executing an AP application running on the respective device, such as 721, 761, and 771.

[0099] The wearable drug delivery device 702 can provide the user with insulin stored in the reservoir 725 based on information (e.g., blood glucose measurements) provided by the sensor 704 and / or the personal diabetes management device (PDM) 706. For example, the wearable drug delivery device 702 can include analog and / or digital circuitry that can be implemented as a processor 721 (or processors) for controlling the delivery of a drug or therapeutic agent. The circuitry used to implement the processor 721 can include discrete specialized logic and / or components, an application-specific integrated circuit, a microcontroller device or processor that executes software instructions, firmware, programming instructions, or programming code stored in memory 723 (e.g., enabling an artificial pancreas application (AP App) 729, similar to the process examples of FIGS. 1 and 3), or any combination thereof. For example, the processor 721 can execute control algorithms, such as the artificial pancreas application 729, and other programming code that can enable the processor 721 to deliver drug or therapeutic agent doses to the user at predetermined intervals or as needed based on the TDI settings discussed in the examples of FIGS. 1-6. The size and / or timing of the dose may be determined, for example, by an artificial pancreas application 729 or the like. In one example, the pump or wearable drug delivery device 702 is communicatively coupled to a processor 761 of the personal diabetes management device via a wireless link 720, or via a wireless link such as 791 from a smart accessory device 707 or sensors 704-708. The pump mechanism 724 of the wearable drug delivery device can receive an activation signal from the processor 761 and, in response to receiving the activation signal, be activated to eject insulin from a reservoir 725 according to a set insulin bolus dosage.

[0100] Other devices in system 700, such as management device 706, smart accessory device 707, and sensor 704, can also operate to perform various functions, including control of wearable drug delivery device 702. For example, personal diabetes management device 706 may include a communication device 764, a processor 761, and management device memory 763. Personal diabetes management device memory 763 can store an instance of AP application 769 that includes programming code and that, when executed by processor 761, provides the example processes described with reference to the examples of Figures 1-6. Personal diabetes management device memory 763 can also store programming code for providing the example processes described with reference to the examples of Figures 1-6.

[0101] The smart accessory device 707 may be, for example, an Apple Watch®, other wearable smart devices including eyeglasses offered by other manufacturers, a global positioning system-enabled wearable, a wearable fitness device, smart clothing, or the like. Like the personal diabetes management device 706, the smart accessory device 707 may also be operable to perform various functions, including control of the wearable drug delivery device 702. For example, the smart accessory device 707 may include a communication device 774, a processor 771, a user interface 778, and memory 773. The memory 773 may store an instance of an AP application 779, including programming code for providing the example processes described with reference to the examples of FIGS. 1-6. The memory 773 may also store programming code and be operable to store data related to the AP application 779. The sensor 704 of the system 700 may be a continuous glucose monitor (CGM) as described above, which may include a processor 741, a memory 743, a sensing or measuring device 744, and a communication device 746. Memory 743 may store an instance of AP application 749 as well as other programming code and may operate to store data related to AP application 749. AP application 749 may also include programming code for providing the example processes described with reference to the examples of Figures 1-6. User interface 778 may be presented as a touchscreen display device, a number of buttons and a display presentation, a combination of buttons and a touchscreen display presentation, or the like.

[0102] Instructions for determining the delivery of a drug or therapeutic agent (e.g., as a bolus dosage) to a user (e.g., the size and / or timing of any doses of the drug or therapeutic agent) may be initiated locally by the wearable drug delivery device 702 or remotely initiated and provided to the wearable drug delivery device 702. In an example of local determination of drug or therapeutic agent delivery, programming instructions, such as an instance of an artificial pancreas application 729 stored in memory 723 coupled to the wearable drug delivery device 702, may be used to make the determination by the wearable drug delivery device 702. Additionally, the wearable drug delivery device 702 may be operable to communicate with a cloud-based service 711 via the communication device 726 and communication link 788.

[0103] Alternatively, remote instructions may be provided to the wearable drug delivery device 702 via a wired or wireless link by a personal diabetes management device (PDM) 706. The personal diabetes management device (PDM) 706 has a processor 761 executing an instance of an artificial pancreas application 769. Alternatively, the smart accessory device 707 has a processor 771 executing an instance of the artificial pancreas application 769 as well as other programming code for controlling various devices, such as the wearable drug delivery device 702, the smart accessory device 707, and / or the sensor 704. The wearable drug delivery device 702 can execute any received instructions (internal or originating from the personal diabetes management device 706) to deliver a drug or therapeutic agent to the user. In this manner, delivery of the drug or therapeutic agent to the user may be automated.

[0104] In various examples, the wearable drug delivery device 702 can communicate with the personal diabetes management device 706 via a wireless link 720. The personal diabetes management device 706 may be an electronic device, such as a smartphone, a tablet, a dedicated diabetes care management device, or the like. The personal diabetes management device 706 may also be a wearable wireless accessory device. The wireless links 708, 720, 722, 791, 792, and 793 may be any type of wireless link provided by any known wireless standard. As an example, the wireless links 708, 720, 722, 791, 792, and 793 may enable communication between the wearable drug delivery device 702, the personal diabetes management device 706, and the sensor 704 based on, for example, Bluetooth®, Wi-Fi®, a near field communication standard, a cellular standard, or any other wireless optical or radio frequency protocol.

[0105] The sensor 704 may be a glucose sensor operable to measure blood glucose and output data representative of a blood glucose level or glucose concentration. For example, the sensor 704 may be a glucose monitor or continuous glucose monitor (CGM). The sensor 704 may include a processor 741, a memory 743, a sensing / measuring device 744, and a communication device 746. The communication device 746 of the sensor 704 may include one or more sensing elements, an electronic transmitter, a receiver, and / or a transceiver for communicating with the personal diabetes management device 706 via wireless link 722 or the wearable drug delivery device 702 via link 708. The sensing / measuring device 744 may include one or more sensing elements, such as a glucose monitor, a heart rate monitor, or the like. The processor 741 may include a microcontroller device or processor that executes separate specialized logic and / or components, an application specific integrated circuit, software instructions, firmware, programming instructions stored in a memory (such as memory 743), or any combination thereof. For example, memory 743 may store an instance of an AP application 749 that is executable by processor 741 .

[0106] Although the sensor 704 is shown as separate from the wearable drug delivery device 702, in various examples, the sensor 704 and the wearable drug delivery device 702 may be incorporated into the same device. That is, in various examples, the sensor 704 may be part of the wearable drug delivery device 702 or may be included within the same housing of the wearable drug delivery device 702 (e.g., the sensor 704 may be disposed within or embedded within the wearable drug delivery device 702). Glucose monitoring data (e.g., measured blood glucose levels) obtained by the sensor 704 may be provided to the wearable drug delivery device 702, the smart accessory device 707, and / or the personal diabetes management device 706 and may be used to determine daily insulin total settings, safety limit settings, storage of data related to insulin delivery history, or the like, enabling improved automated delivery of insulin by the wearable drug delivery device 702.

[0107] The sensor 704 may also be coupled to the user, for example, by adhesive or the like, and may 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 704 may be used to adjust the drug delivery operations of the wearable drug delivery device 702.

[0108] In one example, the personal diabetes management device 706 may be a personal diabetes manager. The personal diabetes management device 706 may be used to program or adjust the operation of the wearable drug delivery device 702 and / or the sensor 704. The personal diabetes management device 706 may be any portable electronic device, including, for example, a dedicated processor such as processor 761, a smartphone, or a tablet. In one example, the personal diabetes management device (PDM) 706 may include the processor 761, a management device memory 763, and a communication device 764. The personal diabetes management device 706 may include analog and / or digital circuitry that may be implemented as the processor 761 (or processors) to perform processes for managing a user's blood glucose level and control the delivery of medications or therapeutic agents to the user. The processor 761 may also be operative to execute programming code stored in the personal diabetes management device memory 763. For example, the personal diabetes management device memory 763 may be operative to store an artificial pancreas application 769 that may be executed by the processor 761. When executing the artificial pancreas application 769, the processor 761 can operate to perform various functions, such as those described with respect to the examples of Figures 1 and 3. The communication device 764 can be a receiver, transmitter, or transceiver that operates according to one or more radio frequency protocols. For example, the communication device 764 can include a cellular transceiver and a Bluetooth transceiver that enables the personal diabetes management device 706 to communicate with a data network via the cellular transceiver, and further with the sensor 704 and the wearable drug delivery device 702. Each transceiver of the communication device 764 can operate to transmit a signal containing information usable by or generated by an AP application or the like.The communication devices 726, 746, and 776 of the wearable drug delivery device 702, the sensor 704, and the smart accessory device 707, respectively, can be operable to transmit signals containing information usable by or generated by an AP application or the like.

[0109] Wearable drug delivery device 702 can communicate with sensor 704 via wireless link 708 and with personal diabetes management device 706 via wireless link 720. Sensor 704 and personal diabetes management device 706 can communicate via wireless link 722. Smart accessory device 707, if present, can communicate with wearable drug delivery device 702, sensor 704, and personal diabetes management device 706 via wireless links 791, 792, and 793, respectively. Wireless links 708, 720, 722, 791, 792, and 793 may be any type of wireless link operating using known wireless standards or proprietary standards. By way of example, wireless links 708, 720, 722, 791, 792, and 793 may provide a communication link based on Bluetooth, Wi-Fi, a near field communication standard, a cellular standard, or any other wireless protocol via respective communication devices 726, 746, and 764. In some examples, wearable drug delivery device 702 and / or personal diabetes management device 706 may include user interfaces 727 and 768, respectively, such as a keypad, touchscreen display, lever, button, microphone, speaker, display, or the like, operable to allow a user to input information and for the personal diabetes management device to output information for presentation to the user.

[0110] In various examples, the drug delivery system 700 may be an insulin drug delivery system. In various examples, the wearable drug delivery device 702 may be an OmniPod® (Insulet Corporation, Billerica, Massachusetts) drug 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.

[0111] In various examples, the drug delivery system 700 executes an artificial pancreas (AP) algorithm (and / or provides AP functionality) to manage or control the automatic delivery of insulin to the user (e.g., to maintain euglycemia—normal levels of glucose in the blood). The AP application may be executed by the wearable drug delivery device 702 and / or the sensor 704. The AP application may be used to determine the time and dosage of insulin delivery. In various examples, the AP application may determine the time and dosage of delivery based on information known about the user, such as the user's gender, age, weight, or height, and / or information collected about the user's physical attributes or condition (e.g., from the sensor 704). For example, the AP application may determine the appropriate delivery of insulin based on the user's glucose level monitoring via the sensor 704. The AP application may also allow the user to adjust insulin delivery. For example, the AP application may allow the user to issue commands (e.g., via input) to the wearable drug delivery device 702, such as commands to deliver insulin doses or bolus doses. In some examples, different functions of the AP application may be distributed among two or more personal diabetes management devices 706, wearable drug delivery devices (pumps) 702, or sensors 704. In other examples, different functions of the AP application may be performed by a single device, such as a personal diabetes management device 706, a wearable drug delivery device (pump) 702, or a sensor 704. In various examples, the drug delivery system 700 may operate in accordance with or include features or functionality of the drug delivery system described in U.S. Patent Application No. 15 / 359,187, filed November 22, 2016, the contents of which are incorporated herein by reference in their entirety.

[0112] As described herein, drug delivery system 700 or any of its components, such as a wearable drug delivery device, may be considered to provide AP functionality or execute an AP application. Accordingly, reference to an AP application (e.g., functionality, operation, or performance thereof) is made for convenience and may refer to and / or include the operation and / or functionality of drug delivery system 700 or any of its components (e.g., wearable drug delivery device 702 and / or personal diabetes management device 706). Drug delivery system 700 may also be considered to be a drug delivery system, e.g., an insulin delivery system that executes an AP application, or an AP application-based delivery system that uses sensor input (e.g., data collected by sensor 704).

[0113] In one example, one or more devices 702, 704, 706, or 707 can be operative to communicate with a cloud-based service 711 via a wireless communication link 788. The cloud-based service 711 may utilize a server and data storage device (not shown). The communication link 788 may be a cellular link, a Wi-Fi link, a Bluetooth® link, or a combination thereof, established between each device 702, 706, or 707 and the sensors 704 of the system 700. The data storage device provided by the cloud-based service 711 can store anonymized data such as a user's weight, blood glucose readings, age, dietary carbohydrate information, or the like. Additionally, the cloud-based service 711 can process the anonymized data from multiple users to provide generalized information related to various parameters used by the AP application. For example, a general target blood glucose level based on age can be derived from the anonymized data, which may be useful during the onboarding process when a wearable drug delivery device is activated, as described. Cloud-based service 711 may also provide processing services to system 700 to perform example process 100 of FIG. 2 or additional processes such as those described below with reference to FIG.

[0114] In one example, the wearable drug delivery device 702 can include a communication device 764, which may be a receiver, transmitter, or transceiver that, as described above, operates according to one or more radio frequency protocols, such as Bluetooth, Wi-Fi, a near field communication standard, a cellular standard, etc., and may enable the respective device to communicate with the cloud-based service 711. For example, output from the sensor 704 or the wearable drug delivery device (pump) 702 may be transmitted to the cloud-based service 711 for storage or processing via the transceiver of the communication device 764. Similarly, the wearable drug delivery device 702, the management device 706, and the sensor 704 can be operative to communicate with the cloud-based service 711 via a communication link 788.

[0115] In one example, the respective receiver and transceiver of each device 702, 706, or 707 can be operative to receive a signal including a respective blood glucose measurement, which may be transmitted by the sensor 704. The respective processor of each device 702, 706, or 707 can be operative to store each respective blood glucose measurement in a respective memory, such as 723, 763, or 773. Additionally, the respective memory 723, 763, or 773 can be operative to store information related to insulin delivery, including insulin delivery history, and updates, including new data, to the insulin delivery history. Each blood glucose measurement may be saved as data related to the artificial pancreas algorithm, such as 729, 749, 769, or 779. In a further example, an AP application functioning on either the personal diabetes management device 706, the smart accessory device 707, or the sensor 704 can be operative to transmit a control signal for receipt by the wearable drug delivery device via a transceiver executed by the respective communication device 764, 774, 746. In this example, the control signal may indicate the amount of insulin to be ejected by the wearable drug delivery device 702.

[0116] Various operating scenarios and examples of processes performed by system 700 are described herein. For example, system 700 can operate to perform the example processes of Figures 1-6. As a note, although the examples are described for three days, if a new generation pod or wearable drug delivery device such as 702 may be usable for more than three days, the lifecycle described in the examples of Figures 2-6 may be performed during the lifecycle of the new generation pod.

[0117] The techniques described herein for providing an onboarding and adaptation process as described herein for a drug delivery system (e.g., system 700 or any component thereof) may be implemented in hardware, software, or any combination thereof. For example, system 700 or any component thereof may be implemented in hardware, software, or any combination thereof. Software associated with the execution of the techniques described herein may include, but is not limited to, firmware, application-specific software, or any other type of computer-readable instructions that may be executed by one or more processors. Hardware associated with the execution of the techniques described herein may include, but is not limited to, integrated circuits (ICs), application-specific ICs (ASICs), field programmable arrays (FPGAs), and / or programmable logic devices (PLDs). In some examples, the techniques described herein and / or any system or component described herein may be implemented by a processor executing computer-readable instructions stored in one or more memory components.

[0118] Some examples of the disclosed devices may be implemented using, for example, a storage medium, computer-readable medium, or article of manufacture capable of storing instructions or sets of instructions that, when executed by a machine (i.e., a processor or controller), can cause the machine to perform methods and / or operations in accordance with examples 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 component may include, for example, any suitable type of memory device, memory, memory component, memory medium, storage device, storage component, storage medium, and / or storage device, 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), compact disk recordable (CD-R), compact disk rewritable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory cards or disks, various types of digital versatile disks (DVDs), tape, cassette, or the like. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, programming code, etc., implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language. The non-transitory computer readable medium embodied with programming code, when executing the programming code, can cause a processor to perform functions such as those described herein.

[0119] Specific examples of the present disclosure have been described above. However, it should be expressly noted that the present disclosure is not limited to these examples, and rather, additions and modifications to those explicitly described herein are also intended to be included within the scope of the disclosed examples. Furthermore, it should be understood that the features of the various examples described herein are not mutually exclusive and may exist in various combinations and permutations without departing from the spirit and scope of the disclosed examples, even if such combinations or permutations are not explicitly set forth herein. Indeed, variations, modifications, and other implementations of what is described herein will occur to those skilled in the art without departing from the spirit and scope of the disclosed examples. Therefore, the disclosed examples should not be defined solely by the foregoing illustrative description.

[0120] The program aspects of technology can be thought of as "products" or "articles of manufacture," typically in the form of executable code and / or associated data executed or embodied on some type of machine-readable medium. Storage-type media may include any or all of the tangible memory of a computer, processor, or the like, or associated modules, such as various semiconductor memories, tape drives, disk drives, and the like, which may provide non-transitory storage for software programming at any time. It is emphasized that this Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, various features are grouped together in a single example to streamline the disclosure. This method of disclosure should not be interpreted as reflecting an intention that the claimed examples require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed example. Accordingly, the following claims are hereby incorporated by reference into the Detailed Description, with each claim standing on its own as a separate example. In the appended claims, the terms "comprises" and "wherein" are used as the plain-English equivalents of the respective terms "comprising" and "wherein." Furthermore, the terms "first," "second," "third," etc. are used merely as labels and are not intended to impose numerical requirements on their objects.

[0121] The foregoing description of illustrative examples has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed. Many modifications and variations are possible in light of this disclosure. It is intended that the scope of the disclosure be limited not by this detailed description, but rather by the claims appended hereto. Future applications claiming priority to this application may claim the disclosed subject matter differently and may generally include any set of one or more limitations as variously disclosed or otherwise set forth herein. Some aspects of the invention are described below. [Aspect 1] A non-transitory computer-readable medium embodied with programming code executable by a processor, the programming code causing the processor to perform a function when executed, the Obtaining a portion of the insulin delivery history associated with the user; determining whether the portion of the insulin delivery history meets sufficiency requirements; responsive to determining that the insulin delivery history meets the sufficiency requirement, selecting an upper safety limit as a limit on the amount of insulin delivered over a period of time, the selected upper safety limit being an amount of insulin that exceeds an amount of insulin associated with a lower safety limit; setting the amount of insulin delivered by the drug delivery device below the upper safety limit; and A non-transitory computer readable medium comprising functionality to initiate delivery of an amount of insulin according to the set amount of insulin. [Aspect 2] Further embodied in programming code executable by the processor, wherein when executing the programming code, the processor is operative to determine whether the portion of the insulin delivery history satisfies a sufficiency requirement, analyzing the acquired portion of the insulin delivery history for predetermined criteria; Based on the results of the analysis, verifying that the insulin delivery history satisfies the sufficiency requirement of satisfying the total number of hours of data within a contiguous period within a number of prior days; and 2. The non-transitory computer-readable medium of embodiment 1, wherein the non-transitory computer-readable medium performs the further function of generating a confirmation signal indicative of confirmation that the insulin delivery history meets the sufficiency requirement. [Aspect 3] The method may further be embodied in programming code executable by the processor, wherein when executing the programming code, the processor: obtaining new information related to the amount of insulin delivered by the drug delivery device from an updated insulin delivery history; Determines that adaptive mode is active, In response to determining that the adaptive mode is active, setting a total daily insulin dosage at a weighted sum of a previously set total daily insulin dosage and a daily average of insulin doses based on the updated insulin delivery history; and 10. The non-transitory computer-readable medium of embodiment 1, operative to perform the further function of transmitting the set total daily insulin dosage for receipt by a wearable drug delivery device. [Aspect 4] The method may further be embodied in programming code executable by the processor, wherein when executing the programming code, the processor: determining whether insulin delivery occurred within a predetermined last insulin delivery period; and A non-transitory computer-readable medium as described in aspect 3, which is operable to perform the further function of transmitting the selected safety limit setting to the drug delivery device in response to a determination that the insulin delivery occurred within the predetermined last insulin delivery period. [Aspect 5] The method may further be embodied in programming code executable by the processor, wherein when executing the programming code, the processor: determining whether the drug delivery device has delivered insulin within a predetermined last insulin delivery period; and A non-transitory computer-readable medium as described in aspect 3, which is operative to perform the further function of establishing a starting insulin loading setting equal to a percentage of the set total daily insulin dosage in response to a determination that the drug delivery device has not delivered insulin within the last predetermined insulin delivery period. [Aspect 6] and further embodied in additional programming code executable by the processor, the processor being operable to perform additional functions when executing the additional programming code, obtaining new information related to the amount of insulin delivered by the drug delivery device from an updated insulin delivery history; determining that the adaptive mode is inactive, responsive to determining that the adaptive mode is inactive, setting the total daily insulin dosage to a daily average based on the obtained new information; setting the adaptive mode to active; and 2. The non-transitory computer-readable medium of claim 1, comprising functionality for providing the set total insulin dosage to the drug delivery device. [Aspect 7] The method may further be embodied in programming code executable by the processor, wherein when executing the programming code, the processor: determining whether the drug delivery device delivered insulin within a predetermined last insulin delivery period; and A non-transitory computer-readable medium as described in aspect 6, which is operable to perform the further function of transmitting the selected safety limit setting to the drug delivery device in response to a determination that the drug delivery device has delivered insulin within the predetermined last insulin delivery period. [Aspect 8] The method may further be embodied in programming code executable by the processor, wherein when executing the programming code, the processor: determining whether the drug delivery device delivered insulin within a predetermined last insulin delivery period; and A non-transitory computer-readable medium as described in aspect 6, which is operable to perform the further function of establishing a starting insulin loading setting equal to a percentage of the set total daily insulin dosage in response to a determination that the drug delivery device has not delivered insulin within the predetermined last insulin delivery period. [Aspect 9] Further embodied in programming code executable by the processor, wherein when executing the programming code for determining whether the portion of the insulin delivery history meets a sufficiency requirement, the processor: determining that the portion of the insulin delivery history does not meet the sufficiency requirement; responsive to determining that the insulin delivery history does not meet the sufficiency requirement, selecting a lower safety limit for the amount of insulin delivered over a period of time, the selected lower safety limit being lower than the selected upper safety limit and exceeding a minimum amount of insulin delivered by the drug delivery device; and 10. The non-transitory computer-readable medium of aspect 1, operable to limit the amount of insulin delivered by the wearable drug delivery device to below the selected lower safety limit. [Aspect 10] The method may further be embodied in programming code executable by the processor, wherein when executing the programming code, the processor: 10. The non-transitory computer-readable medium of claim 9, further operable to set the lower safety limit to an insulin level equal to a multiplier applied to a basal insulin limit setting, wherein the period is one day. [Aspect 11] The method may further be embodied in programming code executable by the processor, wherein when executing the programming code, the processor: 10. The non-transitory computer-readable medium of embodiment 9, further operative to provide an indication that the adaptive mode is inactive. [Aspect 12] Further embodied in programming code executable by the processor, wherein when executing the programming code, the processor operates to perform a function: when determining whether the insulin delivery history is sufficient, the insulin delivery history data is for a total of about 48 hours over a continuous period of about 54 hours with no gaps of more than about 6 hours; and 6. The non-transitory computer-readable medium of embodiment 5, comprising functionality for determining that the content is not older than about 30 days. [Aspect 13] a processor; a memory communicatively coupled to the processor and operable to store programming code, an artificial pancreas application, an onboarding application code, an adaptation application code, and data related to the artificial pancreas application, the onboarding application code, or the adaptation application code; the programming code, the artificial pancreas application, the onboarding application code, and the adaptation application code are executable by the processor; a transceiver communicatively coupled to the processor and operable to send and receive signals containing information usable by or generated by the artificial pancreas application, the onboarding application code, and the adaptation application code, and to exchange signals with a wearable drug delivery device; when executing the artificial pancreas application, the onboarding application code, or the adaptation application code, the processor operates to control insulin delivery and perform functions; obtaining a portion of an insulin delivery history associated with the user, the insulin delivery history including an amount of insulin delivered for each number of insulin delivery dosages administered to the user; determining whether the portion of the insulin delivery history meets insulin history sufficiency requirements; responsive to determining that the insulin delivery history meets the insulin history sufficiency requirement, setting an initial total daily insulin value; and a device including the capability to transmit said initial daily total insulin value for receipt by said wearable drug delivery device. [Aspect 14] The processor is communicatively coupled to a blood glucose sensor, the processor comprising: receiving a plurality of blood glucose measurements from the blood glucose sensor, each blood glucose measurement being received at a predetermined time interval over a period of time; modifying the initial total daily insulin value based on the received plurality of blood glucose measurements to generate an adapted total daily insulin value; and Aspect 14. The device of aspect 13, further operative to use the adapted total daily insulin value to perform operations of the wearable drug delivery device. [Aspect 15] The processor: receiving an indication that the wearable drug delivery device has been replaced with a replacement wearable drug delivery device; Obtaining updated insulin delivery history data collected during operation of the replaced wearable drug delivery device; and The device of aspect 13, further operable to set a total daily insulin to be delivered by the replacement wearable drug delivery device based on the acquired insulin delivery history based on a sum of parameters, the parameters corresponding to a total daily insulin to be set in the wearable drug delivery device and an amount of insulin delivered during the life cycle of the wearable drug delivery device being replaced, and a weight is applied to each parameter. [Aspect 16] The processor: 16. The device of aspect 15, further operative to determine that the values of the weights applied to parameters are based on a length of the updated insulin delivery history, and wherein the values of the weights applied to each parameter are less than 1. [Aspect 17] The processor: Aspect 14. The device of aspect 13, further operative to receive an alarm signal from the wearable drug delivery device, the alarm signal indicating a malfunction of the wearable drug delivery device. [Aspect 18] a touchscreen display device communicatively coupled to the processor; and a user interface generated by the processor and presented on the touchscreen display device; 14. The device of claim 13, wherein the processor is operative to receive input indicating a basal insulin dosage via the touchscreen display device and the user interface. [Aspect 19] The processor: maintaining an accounting of the number of insulin doses automatically delivered by the wearable drug delivery device over a period of time; maintaining an accounting of the number of user-entered insulin doses delivered by the wearable drug delivery device over a period of time; generating a weighted confidence based on a ratio of automatically delivered insulin doses to the number of user-entered insulin doses delivered; and A device as described in aspect 13, further operative to assign a higher weight to the insulin delivery during days with a higher proportion of automatic delivery compared to user-requested insulin delivery. [Aspect 20] The processor: further operative to limit the amount of total daily insulin administered by the wearable drug delivery device to a multiple of the user's basal insulin dosage; a first multiplier is selected if the processor determines that the insulin delivery history is sufficient; and A device as described in aspect 13, wherein a second multiplier is selected if the processor determines that the insulin delivery history is insufficient.

Claims

1. A non-transitory computer-readable medium embodied with programming code executable by a processor, the processor, when executing the programming code, being operative to perform functions, Obtaining a portion of the insulin delivery history associated with the user; determining whether the acquired portion of the insulin delivery history satisfies requirements for insulin delivery; analyzing the acquired portion of the insulin delivery history; determining, based on the results of the analysis, by verifying that the retrieved portion of the insulin delivery history satisfies a requirement that the total number of hours of data be within a contiguous period of time that is within a number of days prior to replacing the drug delivery device with a new drug delivery device; set a limit on insulin delivery in response to determining that the retrieved portion of the insulin delivery history satisfies the requirement for insulin delivery; Setting the amount of insulin delivered by the new drug delivery device to meet the limit; and A non-transitory computer-readable medium comprising functionality for initiating insulin delivery according to the set amount of insulin.

2. and further embodied in programming code executable by the processor, wherein when executing the programming code, the processor: obtaining new information related to the amount of insulin delivered by the new drug delivery device from an updated insulin delivery history; determining that an adaptive mode is active, indicating that insulin delivery to the user is possible; In response to determining that the adaptive mode is active, before replacing the drug delivery device with the new drug delivery device, set a total daily insulin dosage at a weighted sum of a previously set total daily insulin dosage and a daily average of insulin doses based on the updated insulin delivery history; and 10. The non-transitory computer-readable medium of claim 1, operative to perform the further function of transmitting the set total daily insulin dosage for receipt by the new drug delivery device.

3. and further embodied in programming code executable by the processor, wherein when executing the programming code, the processor: determining whether insulin delivery occurred within a predetermined last insulin delivery period; and 3. The non-transitory computer-readable medium of claim 2, operable to perform the further function of transmitting the set total daily insulin dosage to the new drug delivery device in response to a determination that the insulin delivery occurred within the predetermined last insulin delivery period.

4. and further embodied in programming code executable by the processor, wherein when executing the programming code, the processor: determining whether the drug delivery device delivered insulin within a predetermined last insulin delivery period; and 3. The non-transitory computer-readable medium of claim 2, wherein the non-transitory computer-readable medium is operable to perform the further function of setting a starting insulin dosage equal to a percentage of the set total daily insulin dosage in response to a determination that the drug delivery device has not delivered insulin within the last predetermined insulin delivery period.

5. The method may further be embodied in additional programming code executable by the processor, the processor being operable to perform additional functions when executing the additional programming code, obtaining new information related to the amount of insulin delivered by the drug delivery device from an updated insulin delivery history; determining that an adaptive mode is inactive, indicating that insulin delivery to the user is enabled; responsive to determining that the adaptive mode is inactive, setting the total daily insulin dosage to a daily average based on the obtained new information; Setting the adaptive mode to active; and 10. The non-transitory computer-readable medium of claim 1, further comprising the capability to provide the set total daily insulin dosage to the new drug delivery device.

6. and further embodied in programming code executable by the processor, wherein when executing the programming code, the processor: determining whether the drug delivery device delivered insulin within a predetermined last insulin delivery period; and 6. The non-transitory computer-readable medium of claim 5, operable to perform the further function of transmitting the set total daily insulin dosage to the new drug delivery device in response to a determination that the drug delivery device has delivered insulin within the last predetermined insulin delivery period.

7. and further embodied in programming code executable by the processor, wherein when executing the programming code, the processor: determining whether the drug delivery device has delivered insulin within a predetermined last insulin delivery period; and 6. The non-transitory computer-readable medium of claim 5, operable to perform the further function of setting a starting insulin dosage equal to a percentage of the set total daily insulin dosage in response to a determination that the drug delivery device has not delivered insulin within the last predetermined insulin delivery period.

8. Further embodied in programming code executable by the processor, wherein when executing the programming code for determining whether the portion of the insulin delivery history meets the requirement, the processor: determining that the portion of the insulin delivery history does not meet the requirement; responsive to determining that the portion of the insulin delivery history does not meet the requirement, selecting a lower safety limit for the amount of insulin delivered for a period of time, the selected lower safety limit being lower than a selected upper safety limit and exceeding a minimum amount of insulin delivered by the new drug delivery device; and 10. The non-transitory computer-readable medium of claim 1, operable to limit the amount of insulin delivered by the new drug delivery device to below the selected lower safety limit.

9. and further embodied in programming code executable by the processor, wherein when executing the programming code, the processor:

9. The non-transitory computer-readable medium of claim 8, further operative to set the lower safety limit to an insulin level equal to a multiplier applied to a basal insulin limit setting, and wherein the period of time is one day.

10. and further embodied in programming code executable by the processor, wherein when executing the programming code, the processor: The non-transitory computer-readable medium of claim 8 , further operative to provide an indication that the adaptive mode is inactive.

11. Further embodied in programming code executable by the processor, wherein when executing the programming code, the processor operates to perform a function, wherein when determining whether the portion of the insulin delivery history meets the requirement, the data for said portion of said insulin delivery history spans a total of about 48 hours over a continuous period of about 54 hours, with no gaps of more than about 6 hours; and The non-transitory computer-readable medium of claim 4 , including the capability to determine that the content is not older than about 30 days.

12. a processor; a memory communicatively coupled to the processor and operable to store programming code executable by the processor; a transceiver communicatively coupled to the processor and operable to send and receive signals containing information usable by or generated by the artificial pancreas application, the onboarding application code, and the adaptation application code, and to exchange signals with the wearable drug delivery device; When executing the programming code, the processor operates to control insulin delivery and perform functions; obtaining a portion of an insulin delivery history associated with the user, the portion of the insulin delivery history including an amount of insulin delivered for each of a plurality of insulin delivery dosages administered to the user; determining whether the acquired portion of the insulin delivery history satisfies requirements for insulin delivery; analyzing the acquired portion of the insulin delivery history; determining, based on the results of the analysis, by verifying that the retrieved portion of the insulin delivery history satisfies a requirement that the total number of hours of data be within a contiguous period of time that is within a number of days prior to replacing the wearable drug delivery device with a new wearable drug delivery device; responsive to determining that the retrieved portion of the insulin delivery history satisfies the requirement for insulin delivery, setting a limit on an amount of insulin delivery; Setting the amount of insulin delivered by the new wearable drug delivery device to meet the constraints; and A device including functionality to transmit the set amount of insulin for receipt by the new wearable drug delivery device.

13. The processor is communicatively coupled to a blood glucose sensor, the processor comprising: receiving a plurality of blood glucose measurements from the blood glucose sensor, each blood glucose measurement being received at a predetermined time interval over a period of time; modifying the set amount of insulin based on the received blood glucose measurements to generate an adapted amount of insulin; and The device of claim 12 , further operative to use the adapted amount of insulin to perform operations of the new wearable drug delivery device.

14. The processor: receiving an indication that the wearable drug delivery device has been replaced with a new wearable drug delivery device; Obtaining updated insulin delivery history data collected during operation of the replaced wearable drug delivery device; and The device of claim 13, further operable to set a total daily insulin to be delivered by the new wearable drug delivery device based on the acquired insulin delivery history based on a sum of parameters, the parameters corresponding to a total daily insulin to be set for the new wearable drug delivery device and an amount of insulin to be delivered during the life cycle of the wearable drug delivery device being replaced, and a weight is applied to each parameter.

15. The processor:

15. The device of claim 14, further operative to determine that the values of the weights applied to the parameters are based on the length of the updated insulin delivery history, and wherein the values of the weights applied to each parameter are less than 1.

16. The processor: The device of claim 12 , further operative to receive an alarm signal from the new wearable drug delivery device, the alarm signal indicating a malfunction of the new wearable drug delivery device.

17. a touchscreen display device communicatively coupled to the processor; a user interface generated by the processor and presented on the touchscreen display device; 13. The device of claim 12, wherein the processor is operative to receive input indicating a basal insulin dosage via the touchscreen display device and the user interface.

18. The processor: maintaining an accounting of the number of user-entered insulin doses delivered over a period of time by the new wearable drug delivery device; generating a weighted confidence based on a ratio of automatically delivered insulin doses to the number of user-entered insulin doses delivered; and 13. The device of claim 12, further operative to assign a higher weight to the insulin delivery during days with a higher proportion of automatic delivery compared to user-requested insulin delivery.

19. The processor: further operative to limit the total daily amount of insulin administered by the new wearable drug delivery device to a multiple of the user's basal insulin dosage; a first multiplier is selected if the processor determines that the portion of the insulin delivery history meets the requirement; and The device of claim 12 , wherein a second multiplier is selected if the processor determines that the portion of the insulin delivery history does not meet the requirement.

Images