Onboarding and total daily insulin adaptivity

Abstract

To disclose a device, a computer-readable medium, and techniques that provide an onboarding process and an adaptivity process for a drug delivery device.SOLUTION: A processor executing an onboarding process determines whether a history of delivered insulin to a user meets specific sufficiency requirements. The onboarding process enables a processor to cause the drug delivery device to administer doses of insulin to a user, according to an initial total daily insulin dose calculation that is determined on the basis of the sufficiency of the insulin delivery history. The initial total daily insulin may be adapted according to the adaptivity process as new insulin delivery is collected. The insulin delivery history, when sufficient, may be used to set total daily insulin dosages that enable automated insulin delivery upon replacement of a drug delivery device. The adaptivity process may be implemented to modify initial insulin delivery doses to provide adapted insulin delivery doses.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The examples described enable the onboarding of user data for use in a closed-loop algorithm and provide features for a drug delivery system that implements an adaptive technique to continuously evaluate a user's insulin requirements using the updated user data.

[0002] Related Applications This application claims priority to U.S. Patent Application No. 16 / 586,499, filed September 27, 2019, entitled "Onboarding and Adaptive One-Day Total Insulin." The entire contents of the foregoing application are hereby incorporated by reference herein.

Background Art

[0003] To provide more accurate insulin dosages to users, diabetes management devices that operate with continuous glucose monitoring devices (CGMs) and wearable insulin injection devices are available. Wearable insulin injection devices, when functioning properly, are typically replaced after a few days. When replacing a wearable insulin injection device, the diabetes management algorithm executed by the diabetes management device may require the user to provide insulin administration inputs (referred to as "open-loop" operation) to the algorithm for a period of time, such as several days or weeks, while the algorithm collects data until the diabetes management device can initiate an automated insulin dosing regimen (referred to as "closed-loop" operation). As a result, the user may have to manually provide insulin administration inputs for several days or weeks during open-loop operation before the diabetes management device can initiate closed-loop automated insulin delivery operation.

[0004] The delay in the start of an automated insulin administration regimen, which is part of the closed-loop operation, is inconvenient for the user and limits diabetes management devices from providing an accurate estimate of the user's true insulin needs in a short time before replacing the wearable insulin injection device again, or from repeating the cycles of open-loop and closed-loop operation.

SUMMARY OF THE INVENTION

[0005] Examples of non-transitory computer-readable media embodied in programming code executable by a processor are disclosed. When executing the programming code, the processor operates to perform functions, including the function of obtaining a portion of the insulin delivery history relevant to the user. When executing the programming code, the processor can operate to determine whether the portion of the insulin delivery history meets the sufficient requirements. In response to the determination that the insulin delivery history meets the sufficient requirements, a safety upper limit may be selected as the limit of the amount of insulin delivered over a certain period. The selected safety upper limit may be an amount of insulin that exceeds the amount of insulin related to the safety lower limit. The amount of insulin delivered during a certain period that is below the selected safety upper limit may be set. In response to the set amount of insulin, the delivery of the amount of insulin may be initiated.

[0006] A device comprising a processor, a memory, and a transceiver is disclosed. The memory may be operative to store programming code, an artificial pancreas application, onboarding application code, adaptive application code, and data related to the artificial pancreas application, the onboarding application code, and the adaptive application code. The transceiver may be communicatively coupled to the processor and operative to transmit and receive signals including information usable by or generated by the artificial pancreas application, the onboarding application code, or the adaptive application code. The programming code, the artificial pancreas application, the onboarding application code, and the adaptive application code may be executable by the processor. When executing the artificial pancreas application, the onboarding application code, or the adaptive application code, the processor controls insulin delivery and operates to perform functions. The functions include obtaining a portion of the insulin delivery history related to the user. The insulin delivery history may include the amount of insulin delivered for each of some insulin delivery dosages administered to the user. The processor may be able to determine whether the portion of the insulin delivery history meets the insulin history requirements. In response to a determination that the insulin delivery history meets the insulin history requirements, an initial daily total insulin value may be set. The initial daily total insulin value is transmitted for receipt by a wearable drug delivery device.

Brief Description of the Drawings

[0007]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

[0008] The various examples provide methods, systems, devices, and computer-readable media for facilitating a condensed onboarding of an adaptation scheme operative to determine an accurate estimate of a user's insulin requirements in a user-insulin therapy program and / or any general insulin delivery system. For example, the estimate of the user's insulin requirements, as perceived by the user, may be based on the total daily insulin (TDI) parameter of a particular user. Also, by way of an exemplary process, where the history of insulin delivery is insufficient, a reasonable "onboarding" scheme can provide an initial estimate of the TDI and reasonable limits of maximum confidence.

[0009] Some insulin delivery systems can track the course of past insulin delivery history. For example, the stored past insulin delivery history can track the course of when the insulin dosage is administered, the amount of insulin in the dosage, the type of insulin administered (e.g., rapid-acting, standard, intermediate-acting, long-acting or the like), blood glucose measurement, etc. Using the insulin delivery history, the example described provides a method for the overall insulin delivery assessment within an automatic insulin delivery system that uses the insulin delivery history over an increasingly long history period to reduce the risks of hyperglycemia and hypoglycemia. Since almost all insulin deliveries are usually known to the insulin delivery system with high precision over time, the examples described herein use the known insulin delivery history when starting a new drug delivery device and while the drug delivery device is operating to provide an assessment of the overall insulin delivery and to more accurately determine the total daily insulin (TDI) requirement for each user.

[0010] According to the accuracy of the described algorithm, the example described allows for moving backward the time range of the insulin delivery history and the length of the minimum effective insulin delivery history, as well as the maximum difference between the time stamps of the first and last entries of the insulin delivery history over a sufficient period. That sufficient period is used to generate a TDI parameter, which is a robust and generalizable TDI estimate for a particular user. The exemplary process functions 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 account for any short-term acute fluctuations in insulin sensitivity that may occur due to temporary life events such as illness, rapid weight loss, intense exercise therapy or the like.

[0011] The process example may be used with blood glucose levels, insulin delivery, and any additional algorithms or computer applications that function to manage general and overall insulin therapy. Such algorithms may be referred to as "artificial pancreas" algorithm-based systems, or more generally artificial pancreas (AP) applications. The AP algorithm functions to provide automatic delivery of insulin based on blood glucose sensor inputs such as those received from a CGM, etc. In one example, when executed by a processor, the artificial pancreas (AP) application causes the system to monitor the user's glucose value and determine the appropriate insulin level for the user based on the monitored glucose value (e.g., blood glucose concentration or blood glucose measurement) and other information such as the user-provided information on carbohydrate intake, exercise time, meal time, or the like, and take measures to maintain the user's blood glucose value within an appropriate range. The appropriate range of blood glucose values may be considered the target blood glucose value for a particular user. For example, the target blood glucose value may be acceptable if it is within the range of 80 mg / dl to 120 mg / dl, which satisfies the clinical criteria for dealing with diabetes treatment. However, the AP application enhanced by the methods and processes described herein may be able to more accurately determine the insulin dosage and establish the timing for administering the established insulin dosage. As described in more detail with reference to the examples of FIGS. 1-7, the AP application utilizes insulin delivery history and other information to generate commands and, for example, transmit commands to a wearable drug delivery device including a pump, and control the delivery of the determined insulin dosage to the user in the same way as controlling other functions, and can change future insulin dosages or timing.

[0012] The examples described are advantageous and beneficial for any application of a "closed-loop" processing algorithm or automatic insulin delivery mechanism, enabling a substantially immediate and safe start of automatic delivery upon first pod use, and on the other hand, the delivery mechanism can be made to coincide with any changes in the user's insulin requirements over time.

[0013] The described process may be particularly advantageous when a user first uses or exchanges a wearable drug delivery device such as an OmniPod® (Insulet Corporation, Billerica, Massachusetts) or a similarly configured device with similar performance. These wearable drug delivery devices can administer insulin doses 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 the user first uses a new wearable drug delivery device or exchanges a used wearable drug delivery device, the installation of the new wearable drug delivery device or the installation of the wearable drug delivery device for exchange, the installation of the wearable drug delivery device (either to make new or to exchange) may be referred to as an initial installation or a first installation.

[0014] As will be described in more detail later with reference to FIG. 7, the wearable drug delivery device may be controlled by a processor operable to execute the above-described AP algorithm and to execute the exemplary processes described herein. The processor may be configured as 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 smartwatch, a smart fitness device or the like) or other types of mobile devices. 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 a sufficient insulin delivery history at the initial or first installation of a 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 can include blood glucose measurements, the dosage of insulin administered (i.e., the dosing amount), the time at which the insulin is administered, the carbohydrate-to-insulin ratio, an insulin sensitivity assessment, an insulin adjustment factor, a basal profile or the like. As a note, the basal profile may be a 24-hour profile of the basal requirement defined by the start and end times of each interval and the basal delivery rate. For example, one basal profile is as follows. [Table 1]

[0016] The "basal profile" refers to the entire above table. Depending on their individual requirements, different users can have different basal profiles.

[0017] If a sufficient insulin delivery history is available and accessible, the onboarding process may be omitted. Examples of onboarding procedures can include a process of resetting the total daily insulin (TDI) estimate when there is a sufficiently long gap in the user's insulin delivery history and the insulin delivery history is insufficient.

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

[0019] By a combination of the onboarding process and the adaptation process during the application of any "closed loop" or automatic insulin delivery mechanism, automatic delivery can be safely initiated immediately upon first pod use (i.e., while also matching the delivery mechanism to any changes in the user's true insulin requirements over time).

[0020] FIG. 1 shows a flow chart of an exemplary process for determining settings of an insulin delivery system. Process 100 may be executed by a processor operative to control a wearable drug delivery device over a period of time. For example, at 105, a portion of an insulin delivery history associated with a user may be obtained from a data storage device such as the processor's memory, from a remote server of a cloud-based data storage system or the like. At 110, the processor can determine whether the portion of the insulin delivery history meets the adequacy requirements. The evaluation of adequate history at 110 of the onboarding process may be performed at a standard time when the user typically exchanges information with a wearable drug delivery device and / or a personal diabetes management device (described in more detail with reference to FIG. 7). In an example such as a typical tube pump drug delivery device, this evaluation at 110 may occur each time the user replaces an insulin container within an insulin management and delivery system (not shown in this example). In the example, at 110, the processor can analyze the obtained portion of the insulin delivery history against a predetermined criterion that, if present, satisfies the adequacy requirements of the insulin delivery history. For example, the analysis of the portion of the insulin delivery history by the processor can perform adaptation or onboarding when an adequate insulin delivery history is not available (i.e., the insulin delivery history is inadequate) 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 confirm that any estimated TDI covers a sufficient period and sufficient samples of insulin requirements over all hours of the day. 1) The system can have at least a variable MIN of known insulin delivery history 長さ time, and 2) The known insulin history of MIN 長さ or more, in total, is MAX ブロックmay cover a period within the time limit, and 3) the known insulin delivery history that meets the first two conditions is MAX 履歴 may not be older than 履歴 days.

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

[0023] The design of the minimum length of time MIN 長さ is used to ensure that there is sufficient data to calculate a reasonable estimate of the TDI. This data MAX ブロック The design of the maximum span of is used to ensure that the available data is not overly weighted towards a specific period of one day. For example, in the evaluation of the user's insulin requirement only during the post-breakfast period from 8 am to 12 pm for 12 days, 48 hours of data is provided, but it may not represent the user's true insulin requirement. And the insulin delivery history MAX 履歴 The design of the maximum age of is executed to ensure that the system re-evaluates the insulin delivery history when any long-term changes in insulin requirements are not captured due to large gaps in the known insulin history.

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

[0025] In addition, in certain examples, this insulin history assessment can also consider short-term gaps in the insulin history of less than 30 days. In these specific examples, the processor may consider the possibility of an unknown insulin delivery history during these gaps and perform its calculations assuming that a fixed or variable value of insulin may have occurred as insulin-on-board or IOB. In one example, this additional insulin delivery IOB エクストラ can be set to 1 / 6 of the TDI to represent one standard meal (1 / 2 of the TDI generally results from a meal bolus, and the user generally takes three 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 sufficient requirements, the processor can generate a confirmation signal based on the results of the analysis to confirm that the insulin delivery history meets the sufficient requirements for satisfying the total number of hours of data within a continuous period within the previous number of days, and process 100 proceeds to 120. In certain examples, combining the onboarding and adaptation processes with an automatic insulin delivery algorithm can reduce the constraints on the maximum insulin delivery possible by the algorithm. At 112, this limit may be set using a multiplier A that can be "2 times" the basal insulin limit, or in certain examples, this is a reduction from a multiplier B times that can be "4 times" the basal insulin limit if there is sufficient history, 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 an example of a sufficient insulin delivery history, the basal input limit may be set as 4 times the basal insulin dosage, while for an insufficient insulin delivery history, the basal input limit may be set as 2 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 the total daily insulin or the like. For example, the selected safety upper limit may be a multiple B times the basic limit between the maximum amount of insulin for delivery and the minimum amount of insulin delivered by the drug delivery device. The value B can be a multiplier applied to the amount of insulin delivered over a certain period. For example, the value B may be in the range of about 3.5 to 5.0, or a specific value such as 4 or the like. In one example, the period to which the value B can be applied may be time, 1 day, 2 days, or 3 days, or some number of days of the like, time related to the life cycle of the drug delivery device, and the like.

[0029] Conversely, if the processor is at 110 and the insulin delivery history does not meet the sufficient requirements (for example, the total number of hours does not meet the required total time (such as 48 hours), has too long a gap (exceeds 2 - 8 hours), and is determined to be older than the required elapsed time of the data (such as exceeding 30 days), the processor can trigger the onboarding mode to minimize any risks to the user. In the onboarding mode, process 100 can proceed from 110 to 112. At 112, the processor may operate to select a safety lower limit for the amount of insulin to be delivered in response to the determination that the insulin delivery history does not meet the sufficient requirements. The period during which insulin can be delivered at the safety lower limit may be 1 day (i.e., 24 hours), 12 hours, 8 hours, or the like. The selected safety lower limit is lower than the selected safety upper limit and exceeds the minimum amount of insulin delivered by the drug delivery device. The value of the safety lower limit may be a multiplier having a value A that can be multiplied on the basis of the user's TDI to limit the maximum insulin delivery to be lower than the standard use. This value A may be selected to improve the user's safety while further enabling sufficient insulin delivery to maintain normal daily blood glucose fluctuations. For example, the selected safety lower limit may be less than the selected safety upper limit and may exceed the minimum amount of insulin delivered by the drug delivery device. In this example, since there is no sufficient insulin delivery history, the initial amount of insulin delivered at the time of installation of the drug delivery device can be set.

[0030] The amount of insulin set to be delivered on that day may be set lower than the selected safety lower limit (114). During the onboarding process, the system calculates the TDI using the basic parameters of user input. For example, the AP algorithm can provide the 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 average of the user's basal insulin over 24 hours. The required amount of insulin does not change significantly over time. For example, the insulin dosage of a young person in their teens may only change by 20% within a year. In a specific example, the TDI is calculated by multiplying 2 by the sum of each user input basic segment as shown in Equation 1 below (weighted over the period of each basic segment, which is typically defined as the difference between the start time and the end time of the basic segment). Equation 1 TDI オンボーディング =2Σb(t)*(t b、終了 -t b、開始 )

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

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

[0033] After the total daily insulin is set based on the safety lower limit in 114, the processor may indicate that the insulin delivery history is insufficient (116). For example, the processor can set the adaptation flag to false, that is, not true, which indicates that there is an insufficient insulin delivery history for the adaptation mode and / or related functions in processes other than process 100.

[0034] After the execution of either step 116 or step 120, process 100 can lead to decision step 130. In 130, the processor can determine based on new information related to the amount of insulin delivered by the drug delivery device obtained from the updated insulin delivery history regarding whether the adaptation mode of the processor is active or inactive. For example, the processor may determine that the adaptation flag is set to true. In that case, based on the result of the determination, the processor can 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 after the insulin delivery history was obtained in step 105. In one example, the processor may set or reset the total daily 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 adaptation flag is set to true, the total daily insulin may be set (140) based on the weighted sum of the previously set total daily insulin and the amount of insulin delivered over a certain period, and the daily average of the amount of insulin delivered during the waiting period (e.g., based on the updated insulin delivery history) from the new information. The weighting may be, for example, in a ratio of 80:20, 60:40, 50:50 or the like, depending on conditions related to the insulin delivery history, blood glucose measurements newer than the insulin delivery history or the like. Of course, other weightings may be used, or a cost function or the like may be executed to make a new total daily insulin setting.

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

[0037] After either step 140 or step 135 is executed, process 100 proceeds to 150. At 150, a determination is made as to whether the last insulin delivery occurred within the past Y hours. In this example, Y can be a time value having a value in minutes or hours, such as 6 hours, 120 minutes, or the like. For example, a wearable drug delivery device can be operative to provide an acknowledgement signal to the processor in response to receipt of an activation signal or in response to the administration of an insulin dose. Alternatively, the wearable drug delivery device can transmit a signal whenever insulin is delivered by a pump controller that couples the insulin to a pump mechanism of the wearable drug delivery device. In this example, the pump controller may not provide confirmation that drug delivery has occurred or may provide some indication of a malfunction in insulin delivery by the drug delivery device (e.g., no insulin available, reservoir empty, pump mechanism 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 there is a gap rendering the insulin delivery history (currently 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 calculations performed by the processor executing the AP algorithm and based on adaptability and on-board programming code. This IOB may not be included in the insulin delivery history so as not to affect the remaining on-boarding and the TDI calculations in the adaptation process. After step 155, process 100 proceeds to 160.

[0039] Conversely, in response to the 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 the delivery of an insulin amount according to the selected safety upper limit. For example, the processor can transmit a signal via the connection established with the wearable drug delivery device, and the wearable drug delivery device activates its mechanism to deliver an appropriate amount of insulin to the user. The appropriate amount of insulin is the dosage related to the set total daily insulin or a dosage less than the selected safety upper limit.

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

[0043] In certain examples, process 100 can provide different settings within an AP application or algorithm based on the adequacy of the insulin delivery history. In a first example, when an initial pod is launched and the insulin delivery history is inadequate (step 110), the AP application can set the safety limit to A times the basal insulin dose (step 112), the TDI can be set to an active user input basal profile (step 114), and the adaptability is set to false at startup (step 116). In another example, a first pod that is launched and has access to a sufficient insulin delivery history (step 110) can have different settings based on process 100 than this first pod. For example, in the settings of the next pod, the safety limit can be set to B times the basal insulin dose (step 120), the adapt flag may be set to false at startup (since this may be the default value, the setting is carried over from the previous pod (the first pod) or of the same type (step 130)), and the TDI can be set based on the usage of the previous pod. For a second pod, subsequent pods with a sufficient insulin delivery history following the first pod can have the safety limit set to B times the basal insulin dose (e.g., 4 times in some examples). The TDI can be set to a weighted sum (1 番目 weight of X previous pod usage + 2 番目 weight of X previous pod startup TDI setting) and the adapt flag may be set to true. For any pod, once the pod is launched, the TDI parameter at which the AP application functions may not change during the life cycle of the pod. However, the actual TDI of the pod measured by the insulin delivered and reflected in the insulin delivery history may be different from the TDI set during the startup of each pod. Thus, when the adapt flag is set to true, the weighted sum of the measured TDI and the startup TDI is used to launch subsequent pods.

[0044] Referring to FIGS. 2-6, it may be beneficial to describe the details of the onboarding process and the adaptation process. In the example of FIG. 2, process 100 can be executed by a processor of a personal diabetes management device, a smart accessory device, a drug delivery device, or the like (or by a distributed processing configuration among various devices) whenever a wearable drug delivery device is replaced.

[0045] For example, the onboarding process and the adaptation process can be automatically executed without or with limited user interaction by the processor or the pod at each "pod startup" (the term "pod" as used herein is equivalent to a wearable drug delivery device and the terms are used interchangeably). For example, at the startup of pod 210, since there is no past or previous history (in this example, neither short-term nor long-term history), as a result, the insulin delivery history is determined to be insufficient at 110 in FIG. 1. In response to the determination that the insulin delivery history is insufficient for the initial settings of pod 210, the onboarding logic (executed by the processor) can start process 100 at steps 112-116 in FIG. 1. For example, at the startup of pod 210 (row A), the processor's determination that there is an insufficient insulin delivery history results in a closed-loop algorithm executed by the processor that restricts the total insulin delivered in any one cycle. This may be, for example, 1, 5, 10, 15 minutes or the like, and may be less than C times the average of the user's input basic profile (or "2×" and formula 1 as shown in the example of FIG. 2). Further, in this example, the processor also adds 1 / 6 of the user's total daily insulin, which is estimated to be 2 times the total of the user's basic profile as in formula 1, in order to further restrict insulin delivery since there is a recent gap in the insulin delivery history exceeding 6 hours. Of course, other fractions or percentages of the total daily insulin or basal insulin delivery can be selected or set. This setting can be used for the life cycle of pod 210 (e.g., about 3 days or the like). After the life cycle of pod 210 is completed, another pod such as pod 220 can be started. As part of the startup of pod 220, the processor can obtain the insulin delivery history of pod 210. As shown in row B, the insulin delivery history of pod 210 can cover approximately 72 hours (of the insulin delivery history (IDH)) without any gaps. As a result, the processor can evaluate that the insulin delivery history is sufficient.As a result of the determination that the insulin delivery history is sufficient, the processor can set the safety limit of the total daily insulin that can be delivered to B times (or 4 times (4×) as shown in this example) the basal insulin delivery limit for that day.

[0046] During the activation of pod 230, when pod 220 may reach the end of its life cycle, the processor can obtain the new insulin delivery history of pod 220. Using the new insulin delivery history of pod 220, the processor can set the safety limit to B times the total daily insulin (TDI). In the example of FIG. 2, each of pods 230, 240, and 250 may accumulate a sufficient insulin delivery history and be activated using a safety limit set to B times the total daily insulin (TDI).

[0047] In the example of FIG. 3, the evaluation of the insulin delivery history can reveal that the insulin delivery history is insufficient during the activation 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. Since the insulin delivery history of pod 310 in the example of FIG. 3 does not reach the threshold number of hours, the activation of pod 310 can set the insulin carried to a percentage or fraction of the total daily insulin. In the example of FIG. 3, due to a gap in the insulin delivery history of more than 6 hours, the processor may operate to establish the setting of pod 310 for the insulin carried at 1 / 6 of the total daily insulin. Additionally, the safety limit may be set to A times the basal insulin limit, or 2 times the basal insulin limit in this example.

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

[0049] In an example, at 311, the pod 310 may only be used for 42 hours (two days), during which it may become defective, run out of insulin, or experience another failure that results in non-delivery of insulin. In response to a failure, the pod 310 may operate to generate an alarm or other indication, for example, that insulin is not being delivered, or it can transfer an alarm signal to the processor. The processor can operate to indicate an alarm situation if a confirmation response signal is not received within a predetermined period or for the same type. In one example, even though insulin is being delivered, the transceiver in the pod 310 may have lost its connection to the processor or have some other communication impairment. The pod 310 and / or the processor can operate to track how long the period was during which the alarm was set in order to determine whether the insulin delivery history is sufficient.

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

[0051] The activation of the pod 330 is an example of the improvement and refinement of the onboarding example. In this example, upon activation of the pod 330, the processor can be operative to determine that the insulin delivery history is 68 hours out of about 2.75 days or 72 hours without a gap exceeding 6 hours (recall that the gap of the pod 310 is 6 hours), 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 can be operative 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, since the last insulin delivery exceeds Y hours, in this example 6 hours, etc., the gap flag is set to true and the insulin on board is set to a fraction or remainder of the total daily insulin, e.g., 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 without affecting the estimate of the total daily insulin requirement and can limit the operation of the algorithm. For example, with sufficient insulin history, pods 340 and 350 can all start operating in the adaptive mode (e.g., the insulin history for adaptability, such as for pod 330 as shown in FIG. 3, is evaluated for the activation of pod 340).

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

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

[0054] As shown in line 4A, pod 410 operates and provides data throughout its life cycle. The end of the life cycle of pod 410 is when pod 410 is replaced with pod 420. At the activation of pod 420, the processor may be operative to determine that the insulin delivery history provided during the life cycle of pod 410 is sufficient, and as a result, the safety limit of pod 420 can be set to B times the basal insulin limit. The adaptation flag is set to false, and the total daily insulin can be set as the average daily insulin delivered according to the new insulin delivery history of pod 410 (insulin history for starting the TDI estimate value as shown in line 4A, pod 420).

[0055] The life cycle of pod 420 is shortened, and the processor or pod 420 can generate an alarm. As a result of the shortened life cycle of pod 420, as shown in row 4B, the insulin delivery history is missing data from the most recent 24 hours (as shown in 421). The period of missing data (i.e., 24 hours) may exceed the 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 history is sufficient because there is a gap exceeding 6 hours, but the insulin delivery history data without interruption for 48 hours is continuous with data less than 30 days. As a result, the processor sets the total daily insulin based on the insulin delivery history and sets the safety limit to B times the basal insulin limit, but may operate to limit the loaded starting insulin to the ratio 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] Pod 430 generates insulin delivery data throughout its 72-hour (or 3-day) life cycle and provides a sufficient insulin delivery history (as shown in row 4C), so the activation of pod 440 is simple, including setting the adaptation flag to true for point 440. Similarly, the life cycle of pod 440 is completed with a sufficient insulin delivery history without a gap (as shown in row 4D), and as a result, the activation of pod 450 is simple, including setting the adaptation flag to true for point 450. All of pods 430, 440, and 450 can start operating in the adaptation mode with a sufficient insulin history (e.g., as shown in FIG. 4, insulin history for adaptability, pod 430, etc.).

[0057] Another example in which process 100 of FIG. 1 reacts to an insufficient insulin delivery history is shown in FIG. 5. The example of FIG. 5 shows an example of process 100 corresponding to a long gap in the insulin delivery history data. In the example of FIG. 5, during the activation of pod 510, the processor can be operative to note that there is an insufficient insulin delivery history. As a result, in the example of FIG. 5, the processor can be operative to establish the settings of pod 510 relative to the insulin loaded therein at 1 / 6 of the total daily insulin. Additionally, the safety limit may be set to A times the basal insulin limit, or in this example, 2 times the basal insulin limit.

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

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

[0060] In this example, the missing data exceeds 28 days (e.g., 28 days and a half or any fraction exceeding 28 days). When the pod 530 is activated, the processor can be operative to determine that the insulin delivery history is insufficient. Because even if the last data of the insulin delivery history was from a 48 - hour period of continuity, the data gap exceeds 28 days, which is considered as the starting data of a consecutive 48 - hour period older than the threshold of 30 days. As a result of the starting data of the consecutive 48 - hour period being older than 30 days, the insulin delivery history is insufficient. Thus, when the processor can be operative to set the total daily insulin using the average user - input basal insulin value, the safety limit becomes twice the basal insulin limit and the gap flag becomes true.

[0061] As shown in line 5B, the insulin delivery history from the pod 530 is sufficient for the activation of the pod 540. When the pod 540 is activated, the processor can be operative to determine that the insulin delivery history is sufficient because the insulin delivery history has been collected continuously without gaps over 72 hours and the data of 72 hours is not older than 30 days. Since the insulin delivery history is sufficient, the processor can be operative to set the safety limit to B times (e.g., 4 or 6 times) the basal insulin limit, and for example, set the total daily insulin as the one - day average of the insulin delivered according to the new insulin delivery history. Since the pod 540 is the first pod with B times the basal insulin limit, the total daily insulin is set to the one - day average of the insulin delivered according to the new insulin delivery history. This may be regarded as the new starting TDI estimate of the pod 540.

[0062] Due to the sufficient insulin delivery history generated during the life cycle of the pod 540 (as shown in line 5C), when the pod 550 is activated, the processor can use that sufficient insulin delivery history to generate a new total daily insulin value and maintain the setting of the safety limit at B times (e.g., 4 times) the basal insulin limit. The pod 55 can start operating in the adaptive mode.

[0063] As discussed in the foregoing example, daily, the adaptability and onboarding process continuously updates the insulin history. For example, the insulin delivery data collected daily can replace the previous history from the insulin delivery history, and as a result, the AP algorithm more accurately estimates the onboard insulin and adapts the total daily insulin to optimally match the user's insulin dosage requirements. As long as the user consistently uses the AP algorithm while the adaptation mode automatically enables the automatic delivery of insulin for about seven days, about 80% of the difference between the current insulin value and the substantially optimal value is overcome.

[0064] In another example, before replacing the pod, the user can manually administer the insulin dosage. As a result, the onboard insulin may exceed that indicated by the insulin delivery history. The onboarding process can take this possibility into account and apply an insulin onboard correction factor to deliver insulin conservatively so as not to exceed the safety upper limit or the safety lower limit.

[0065] As described above, the disclosed processes and applications can include an adaptation mode in which the processor changes settings when receiving data from other component devices such as a blood glucose sensor or a wearable drug delivery device (i.e., a pod) that is described in more detail with reference to FIG. 7.

[0066] The following is a discussion with reference to FIG. 6 of an example of an adaptation process triggered when there is a sufficient insulin delivery history to calculate an accurate estimate of the TDI. In the proposed example, if there is a sufficient history based on the above evaluation, the system triggers a smart adaptation process to utilize the known insulin delivery history and can relax the existing safety limits when the reliability of the user's insulin requirement is higher.

[0067] The goal of the adaptation process is to adjust the onboarding TDI, which may be different from the actual TDI, and compensate for a significant portion of the difference between the onboarding TDI and the true TDI (i.e., the actual user's TDI) with short-term use since onboarding, and adjust the TDI based on changes in the user's requirements that cannot be processed by the artificial pancreas algorithm (e.g., users in their teens who age over the years).

[0068] Over consecutive years of use, the adaptation mode is expected to improve compensation for long-term changes over time (such as an increase of 26% or more per year and a change of 5 to 10 times that of childhood).

[0069] An example of the adaptation mode is shown in the example of Figure 6. As the initial activation of the pod 610, the past insulin history is not available. 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 the total daily insulin level based on the average of the user-entered basal insulin dosage and a safety limit of A times the basic limit (in the example of Figure 6, A is equal to 2). At the start of the pod 610, the processor can generate, for example, a time stamp indicating the start of the life cycle of the pod 610. In one example, the processor can generate a time stamp each time a signal indicating the operation of the delivered insulin by the wearable drug delivery device, or an acknowledgement signal, is received from a pod such as the pod 610.

[0070] Line 6A indicates each day labeled A-I when the pod (i.e., the wearable drug delivery device) is used. When in the adaptation mode, the processor can operate 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 Figure 7) for each A-I of each day if possible. Of course, the processor can also operate to collect other data such as dietary carbohydrates, exercise, bolus dosage, insulin type, or user input data related to the same.

[0071] In this example, during the life cycle of pod 610, the processor can be operative to collect insulin delivery history data every A, B, and C days. At the end of the life cycle of pod 610, the processor can be operative to activate pod 620. In one example, the processor can access the insulin delivery history data for 3 days (i.e., days A, B, and C) during the activation of pod 620. Alternatively, the processor can obtain updated insulin delivery history data collected during the operation of the wearable drug delivery device 610, which is the wearable drug delivery device being exchanged. When pod 620 is activated, using the insulin delivery history data collected during days A, B, and C, the processor can determine that the insulin delivery history is sufficient and can set the total daily 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 determines that the adaptive mode is active and, in response, can set the total daily insulin dosage based on the weighted sum of the previously set total daily insulin dosage and the daily average of the insulin dosage based on the updated insulin delivery history.

[0072] For example, when in the adaptive mode, the processor can set the total daily insulin of pod 620 to be equal to the average insulin delivered over the past 3 days (e.g., A, B, and C) according to Equation 2.

[0073] Equation 2 TDI ポッド620 =(I A +I B +I C ) / 3 where TDI is the total daily insulin of 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 can transmit the set total daily insulin dosage for reception by the wearable drug delivery device (i.e., pod 620). The life cycle of pod 620 can be extended over days D, E, and F. During the life cycle of pod 620, the insulin delivery history can include the 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 the adaptive mode. When pod 630 is activated, the processor can set the total daily insulin for pod 630 based on the weighted sum of the previous total daily insulin setting (i.e., TDI ポッド620 ) and the average of the average insulin delivered over the most recent 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] Equation 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, respectively, the level of confidence in how reliable the insulin-on-board calculation is for the user over the life cycle of the previous pod. For example, the weighted confidence may be generated based on the ratio of the automatically delivered insulin dosage to the number of user input insulin dosages delivered. In this example, the processor can maintain a count of the number of insulin dosages automatically delivered by the wearable drug delivery device and a count of the number of user input insulin dosages delivered by the wearable drug delivery device over a period of time. The period may be, for example, the life cycle of the previous pod or one day of the current life cycle of the currently executing pod. The reliability of insulin delivery during the day with a high ratio of automatic delivery compared to the insulin delivery requested by the user may be weighted more highly. As a result of a higher confidence value, the most recently determined daily total insulin value may be weighted more heavily. Alternatively, if the confidence score is low, the adaptive algorithm may weight and reduce the weight of the most recently determined daily total insulin value.

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

[0078] Equation 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 of the insulin delivered on day G.

[0079] The weights of 0.8 and 0.2 may be selected based on the processor's determination that each new insulin delivery history is limited to less than one day. Alternatively, or in addition, the weights 0.8 and 0.2 may be selected based on weighted confidence as described above. Since the new insulin delivery history is limited, the new insulin delivery history is for pod 630 (i.e., TDI ポッド630The insulin delivery history used to determine the total daily insulin of ポッド630 may not be considered as reliable as that of

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

[0081] Equation 5 TDI ポッド650 =0.6*TDI ポッド640 +0.4*(I H +I I ) / 2 where TDI is the total daily insulin of 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 daily total insulin setting for each pod may be determined at the start of each pod based on data collected during the life cycle of the previous pod. In some examples, the insulin delivery history of the immediately preceding pod may be considered most relevant to the daily total insulin setting.

[0083] In one example, the onboarding and adaptation algorithms executed by the processor can 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-entered insulin doses delivered by the wearable drug delivery device over a period such as one day or 24 hours. As a result, instead of performing a general total of all insulin deliveries throughout the day, the processor can generate a "weighted confidence" of the daily total insulin delivery. For example, when the onboarding and adaptation algorithms are combined with a closed-loop automatic insulin delivery algorithm (such as an artificial pancreas (AP) algorithm), the reliability of insulin delivery matching the user's actual needs may be higher when the proportion of automatic insulin delivery (i.e., delivery initiated by the AP algorithm) is higher compared to manual delivery (i.e., delivery initiated by the user). In this example, the adaptation algorithm can assign a higher weight to insulin deliveries during the day with a higher proportion of automatic delivery compared to the insulin delivery requested by the user.

[0084] The advantage of the adaptation process described above is the resilience of the process to short-term but large changes in insulin delivery while achieving the above reference objectives of the adaptation process. The adaptation process executed while the processor is in the adaptation mode enables robust execution corresponding to missing data points. For example, illness, missing boluses, or life events should not have a large impact on the TDI estimate or long-term changes in insulin delivery. Additionally, even if the insulin history is missing, it should not have a large impact on the TDI estimate.

[0085] Given these objectives, the proposed adaptive approach attempts to evaluate all past insulin delivery histories in each pod replacement cycle and perform an exponentially weighted moving average of the daily insulin requirement 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 represented by Equation 6 below.

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

[0088] Here, TDI N represents an estimated value of the user's TDI for the Nth adaptive step (or the cycle of steps 105-170 in FIG. 1), and F 適応 represents a convergence coefficient that indicates how quickly the TDI estimate adapts to insulin delivery data from the new insulin delivery history. New insulin · data represents any insulin delivery history that has become available since the last TDI calculation and was not used in the (N - 1)th estimate of the user's TDI, and n 日、新しいインスリン·データ represents the number of days of new insulin · data that is available in the new insulin delivery history and the total of several days of new insulin · data. For example, the Nth adaptation of the user's TDI can be equal to 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). Here, F 適応 is (0.2), 3 is equal to n 日数、新しいインスリン·データ , TDI N-1 is the previous TDI, and A, B, and C represent the amount of total daily insulin used by the user.

[0089] Various methods exist for F 適用It may be used to determine the optimal value. For example, some use cases may be examined to determine whether an exemplary value of this coefficient of 0.2 is appropriate. This coefficient may be adjusted based on the user's actual convergence rate to the TDI. F 適用 The value of represents the convergence rate at which the Nth estimated value of the TDI value converges to the user's actual TDI requirement, and F 適用 the higher the value of 、 the more quickly it can converge to the user's actual requirement, but the higher the vulnerability to fluctuations in the user's sensitivity. F 適用 The optimal value of can be estimated by evaluating the average variation in the user's insulin requirement and evaluating the allowable risk of over- or underestimating the user's TDI requirement in the presence of noise. Then, F 適用 the optimal value of may be a value that minimizes the risk while maximizing the convergence rate 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 figures show various use cases comparing different starting TDIs with the true TDI of 48U, as well as the impact of changes in the daily insulin requirement and the sensitivity of the system to these changes. The foregoing descriptions of the onboarding algorithm and the adaptation algorithm may be extended to incorporate other elements.

[0091] Since the above processing involves storing data that may not be present in the pod or wearable drug delivery device, the processes of the example of FIG. 1 and the examples of FIGS. 2-6 may be executed by a computer application running on a personal diabetes management device (PDM), a smartphone, a wearable smart device (e.g., a smartwatch, 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 performance to execute the described processes. These and other examples may be discussed in more detail with reference to the functional block diagram of the example of the diabetes treatment system shown in FIG. 7.

[0092] Examples of the hardware configurations of 2-3 have been provided above, but with alternative hardware configurations, processing performance can be utilized in the pod or wearable drug delivery device via wireless communication performance, and any new data collected or previously collected data may be stored within the wireless communication range or on another device that is easily accessible via other devices within the wireless communication range. For example, the pod can include a processor that runs a computer application that enables the aforementioned example and operates to communicate with a smartphone. The smartphone can store the newly collected data or previously collected data or access a remote server such as a cloud-based server.

[0093] It may be helpful to discuss an example of a drug delivery system that can execute the process examples of FIGS. 1-6. FIG. 7 shows an example of a drug delivery system 700.

[0094] The drug delivery system 700 may operate to execute an AP application that includes functionality to provide an onboarding process and 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 can include a wearable drug delivery device (pump) 702, a blood glucose sensor 704, and a management device (PDM) 706. In one example, the system 700 can also include a smart accessory device 707, which can communicate with other component devices of the system 700 via either a wired or wireless communication link 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 a diabetic patient, and deliver to the user any therapeutic agent that includes insulin or any drug or medicine of the same kind. 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., directly attached to a body part and / or skin of the user via an adhesive or the like). In one example, the 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 component devices to facilitate the automatic delivery of drugs (also referred to as therapeutic agents) to the user. The wearable drug delivery device 702 can store drugs and be operative to provide the drugs to the user. The wearable drug delivery device 702 is often referred to as a pump or an insulin pump in relation to the operation of discharging drugs from a reservoir 725 for delivery to the user. The example refers to a reservoir 725 that stores insulin, but the reservoir 725 can be operative to store other drugs or therapeutic agents suitable for the 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 can 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 for transferring the drug from the reservoir 725 to the user via the needle or cannula (not shown), or other drive mechanisms. The pump mechanism 724 may be fluidly coupled to the reservoir 725 and communicatively coupled to the processor 721. The wearable drug delivery device 702 can also include a power source 728, such as a battery, a 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, the memory 723, and the communication device 726). Although not shown, the power source for power supply may similarly be included in each of the sensor 704, the smart accessory device 707, and the personal diabetes management device (PDM) 706 as well.

[0098] The blood glucose sensor 704 may be a device communicatively coupled to the processor 761 or 721 and can be operative to measure blood glucose levels at predetermined time intervals, such as every five minutes or the like. The blood glucose sensor 704 may provide several blood glucose measurement values to a processor that executes an AP application that functions on each of the devices such as 721, 761, and 771.

[0099] The wearable drug delivery device 702 can provide insulin stored in reservoir 725 to the user based on information (e.g., blood glucose measurement values) provided by sensor 704 and / or personal diabetes management device (PDM) 706. For example, the wearable drug delivery device 702 may include analog and / or digital circuitry that can be implemented as a processor 721 (or processors) for controlling the delivery of drugs or therapeutic agents. The circuitry used to execute processor 721 can include individual special logic and / or configuration devices, application-specific integrated circuits, 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 a microcontroller device or processor that executes any combination thereof. For example, processor 721 can execute control algorithms such as artificial pancreas application 729 and other programming code that enables processor 721 to deliver to the user a dosage of a drug or therapeutic agent at predetermined intervals to the pump or as required based on the TDI settings discussed in the examples of FIGS. 1-6. The size and / or timing of the dosage may be determined, for example, by artificial pancreas application 729 or the like. In one example, the pump or wearable drug delivery device 702 is communicatively coupled to the processor 761 of the personal diabetes management device via wireless link 720 or via a wireless link such as 791 from smart accessory device 707 or 708 from sensor 704. The pump mechanism 724 of the wearable drug delivery device can receive an actuation signal from processor 761 and, in response to receiving the actuation signal, can operate to discharge insulin from reservoir 725 according to a set insulin bolus dosage.

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

[0101] The smart accessory device 707 may be, for example, an Apple Watch (registered trademark), other wearable smart devices including glasses provided by other manufacturers, global positioning system-enabled wearables, wearable fitness devices, smart clothing, or the like. Similar to the personal diabetes management device 706, the smart accessory device 707 can also be operative 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 a memory 773. The memory 773 can store an instance of an AP application 779 that includes programming code to provide process examples described with reference to the examples of FIGS. 1-6. The memory 773 can also be operative to store programming code and store data associated with the AP application 779. The sensor 704 of the system 700 can be a continuous glucose monitor (CGM) as described above, which can include a processor 741, a memory 743, a sensing or measuring device 744, and a communication device 746. The memory 743 can store an instance of an AP application 749 as well as other programming code, and can be operative to store data associated with the AP application 749. The AP application 749 can also include programming code to provide process examples described with reference to the examples of FIGS. 1-6. The user interface 778 may be presented on a touch screen display device, some buttons and a presentation on the display, a combination of buttons and a touch screen 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 dosage of a drug or therapeutic agent) can be initiated locally or remotely by a wearable drug delivery device 702 and may be 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 a memory 723 coupled to the wearable drug delivery device 702 may be used to be determined by the wearable drug delivery device 702. Additionally, the wearable drug delivery device 702 can be operative to communicate with a cloud-based service 711 via a communication device 726 and a communication link 788.

[0103] Alternatively, remote instructions can 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 that executes an instance of an artificial pancreas application 769. Or, a smart accessory device 707 has a processor 771 that executes an instance of an artificial pancreas application 769 and other programming code for controlling various devices such as the wearable drug delivery device 702, the smart accessory device 707, and / or sensors 704. The wearable drug delivery device 702 can execute any received instructions (either internally or originating from the personal diabetes management device 706) to deliver a drug or therapeutic agent to the user. In this way, the delivery of a drug or therapeutic agent to the user can be automated.

[0104] In various examples, the wearable drug delivery device 702 can communicate with a personal diabetes management device 706 via a wireless link 720. The personal diabetes management device 706 can be, for example, an electronic device such as a smartphone, a tablet, a dedicated diabetes treatment management device, or the like. The personal diabetes management device 706 can 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 can 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] Sensor 704 may be a glucose sensor that operates to measure blood glucose and output data representing a blood glucose value or blood glucose values. For example, sensor 704 may be a glucose monitor or a continuous glucose monitor (CGM). Sensor 704 can include a processor 741, a memory 743, a sensing / measurement device 744, and a communication device 746. The communication device 746 of sensor 704 can include one or more sensing elements, electronic transmitters, receivers, and / or transceivers for communicating with the personal diabetes management device 706 via the wireless link 722 or with the wearable drug delivery device 702 via the link 708. The sensing / measurement device 744 can include one or more sensing elements such as glucose measurement, heart rate monitor, or the like. The processor 741 can include a microcontroller device or a processor that executes individual special logic and / or configuration devices, application specific integrated circuits, software instructions, firmware, programming instructions stored in a memory (such as memory 743), or any combination thereof. For example, the memory 743 can store an instance of the AP application 749 executable by the processor 741.

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

[0107] Sensor 704 may also be coupled to the user, for example, by an adhesive or the like and can provide information or data regarding one or more medical conditions and / or the user's physical attributes. The information or data provided by sensor 704 may be used to adjust the drug delivery operation of 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 can include a processor 761, a management device memory 763, and a communication device 764. The personal diabetes management device 706 can include analog and / or digital circuitry that may be implemented as a processor 761 (or processors) to perform processes for managing a user's blood glucose level and controlling the delivery of drugs or therapeutic agents to the user. The processor 761 can 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 can 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 be operative to perform various functions such as those described with respect to the examples of FIGS. 1 and 3. The communication device 764 may be a receiver, a transmitter, or a 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 be operative to transmit signals including information that can be used by, or generated by, an AP application or the like.Each of the communication devices 726, 746, and 776 of the wearable drug delivery device 702, the sensor 704, and the smart accessory device 707 can be operative to transmit signals including information that can be used by or generated by an AP application or the like.

[0109] The wearable drug delivery device 702 can communicate with the sensor 704 via the wireless link 708 and can communicate with the personal diabetes management device 706 via the wireless link 720. The sensor 704 and the personal diabetes management device 706 can communicate via the wireless link 722. The smart accessory device 707, if present, can communicate with the wearable drug delivery device 702, the sensor 704, and the personal diabetes management device 706 via the wireless links 791, 792, and 793, respectively. The wireless links 708, 720, 722, 791, 792, and 793 can be any type of wireless link operative using a known wireless standard or a proprietary standard. As an example, the wireless links 708, 720, 722, 791, 792, and 793 can provide communication links based on Bluetooth®, Wi-Fi, near-field communication standards, cellular standards, or any other wireless protocol via the respective communication devices 726, 746, and 764. In some examples, the wearable drug delivery device 702 and / or the personal diabetes management device 706 can each include a keypad, a touch screen display, a lever, a button, a microphone, a speaker, a display or the like operative to enable a user to input information and for the personal diabetes management device to output information for presentation to the user, and user interfaces 727 and 768.

[0110] In various examples, drug delivery system 700 may be an insulin drug delivery system. In various examples, 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 hereby incorporated 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 a user (e.g., to maintain normal blood glucose - a normal level 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 can be used to determine the timing and dosage of insulin delivery. In various examples, the AP application determines the timing 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 can determine appropriate insulin delivery based on monitoring of the user's glucose level via the sensor 704. The AP application may also enable the user to adjust insulin delivery. For example, the AP application may enable the user to issue a command (e.g., via an input) to the wearable drug delivery device 702, such as a command to deliver an insulin dosage or a bolus dosage. In some examples, different functions of the AP application can 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 can be executed by one device, such as the personal diabetes management device 706, wearable drug delivery device (pump) 702, or sensor 704. In various examples, the drug delivery system 700 operates in accordance with, and can include, the features or functions of the drug delivery system described in U.S. Patent Application No. 15 / 359,187, filed November 22, 2016, the content of which is hereby incorporated by reference in its entirety.

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

[0113] In one example, one or more of the 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 servers and data storage devices (not shown). The communication link 788 can be a cellular link, Wi-Fi link, Bluetooth® link, or a combination thereof, which may be established between the respective devices 702, 706, or 707 and the sensor 704 of the system 700. The data storage device provided by the cloud-based service 711 can store anonymized data of a user's weight, blood glucose measurements, age, dietary carbohydrate information, or the like. Additionally, the cloud-based service 711 can process 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 value based on age can be derived from the anonymized data, which may be useful during the onboarding process when the wearable drug delivery device is activated as described. The cloud-based service 711 can also provide processing services to the system 700 to execute additional processes as described below with reference to process 100 of the example of FIG. 2 or FIG. 3.

[0114] In one example, the wearable drug delivery device 702 can include a communication device 764, which, as described above, operates according to one or more radio frequency protocols such as Bluetooth®, Wi-Fi, near-field communication standards, cellular standards, etc., and can be a receiver, transmitter, or transceiver that enables each device to communicate with a cloud-based service 711. For example, the 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 receivers and transceivers of each device 702, 706, or 707 can be operative to receive signals including respective blood glucose measurement values that can be transmitted by the sensor 704. The respective processors of each device 702, 706, or 707 can be operative to store each of the respective blood glucose measurement values in respective memories such as 723, 763, or 773. Additionally, each memory 723, 763, or 773 can be operative to store information related to insulin delivery including an insulin delivery history, and updates including new data to the insulin delivery history. Each blood glucose measurement value may be stored as data related to an artificial pancreas algorithm such as 729, 749, 769, or 779. In a further example, an AP application that functions on any of the personal diabetes management device 706, the smart accessory device 707, or the sensor 704 can be operative to transmit a control signal for reception by the wearable drug delivery device via the transceivers implemented by the respective communication devices 764, 774, 746. In this example, the control signal can indicate the amount of insulin to be dispensed by the wearable drug delivery device 702.

[0116] Various operation scenarios and examples of the processes executed by system 700 are described herein. For example, system 700 can be operative to execute the process examples of FIGS. 1 - 6. By way of memo, although the examples are described for 3 days, if a new generation pod or a wearable drug delivery device such as 702 can be used for more than 3 days, the life cycles described in the examples of FIGS. 2 - 6 may be executed during the period of the life cycle 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 of its constituent devices) may be executed in hardware, software, or any combination thereof. For example, system 700 or any of its constituent devices may be executed in hardware, software, or any combination thereof. The software associated with the execution of the techniques described herein can 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. The hardware associated with the execution of the techniques described herein can include, but is not limited to, integrated circuits (ICs), application-specific ICs (ASICs), field-programmable arrays (FPAs), and / or programmable logic devices (PLDs). In some examples, the techniques described herein, and / or any system or constituent device described herein, may be executed by a processor that executes computer-readable instructions stored in one or more memory devices.

[0118] Some examples of the disclosed devices may be implemented using a manufacture that can store instructions or a set of instructions that, when executed by, for example, a memory medium, a computer-readable medium, or a machine (i.e., a processor or a controller), cause the machine to execute a method and / or operations in accordance with the examples of the present disclosure. Such a machine can include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, or the like, and can be implemented using any suitable combination of hardware and / or software. A computer-readable medium or component can be, 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 a 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 disc read-only memory (CD-ROM), compact disc recordable (CD-R), compact disc rewritable (CD-RW), optical disc, magnetic media, magneto-optical media, removable memory card or disk, various types of digital versatile discs (DVDs), tape, cassette, or the like. The instructions can include any suitable type of code, such as source code, compiled code, interpreter code, executable code, static code, dynamic code, encrypted code, programming code, etc., that is executed using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language. A non-transitory computer-readable medium embodied with programming code can cause a processor to perform functions such as those described herein when the programming code is executed.

[0119] Certain examples of the present disclosure have been described above. However, it should be clearly noted that the present disclosure is not limited to these examples, but rather intends to include additions and modifications to those explicitly described herein within the scope of the disclosed examples. Further, the various features of the examples described herein are not mutually exclusive and can 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 stated herein. In fact, 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. Accordingly, the disclosed examples should not be defined by the foregoing exemplary description alone.

[0120] The program aspect of a technology can generally be considered a "product" or "manufactured article" in the form of executable code and / or associated data that is executed or embodied in a type of machine-readable medium. Memory-type media includes 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, etc., which can provide non-transitory storage for software programming at any time. It is emphasized that an abstract of the disclosure is provided so that the reader can quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it is not to 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 one example for the purpose of streamlining the disclosure. This method of disclosure should not be construed as reflecting an intention that the claimed examples require more features than are expressly recited in each claim. Rather, as the following claims reflect, the subject matter of the invention lies in less than all of the features of a single disclosed example. Accordingly, the following claims are hereby incorporated by reference into the detailed description, and each claim stands on its own as a separate example. In the appended claims, the terms "comprising" and "wherein" are used as the plain English equivalents of the respective terms "including" and "where" respectively. Further, 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 the exemplary examples has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the exact forms disclosed. Many modifications and variations are possible in light of this disclosure. It is intended that the scope of the disclosure be defined not by this detailed description, but rather by the claims appended hereto. Future applications claiming the priority of this application may claim the disclosed subject matter in a different manner and can generally include any set of one or more limitations as variously disclosed herein or otherwise shown.

Claims

1. A non - transitory computer - readable medium embodied in programming code executable by a processor, wherein when the programming code is executed, the processor operates to perform functions to: obtain a portion of an insulin delivery history related to a user, determine whether the portion of the insulin delivery history meets adequacy requirements, in response to a determination that the insulin delivery history meets the adequacy requirements, select a safety upper limit as a limit on the amount of insulin delivered over a certain period, the selected safety upper limit being an amount of insulin that exceeds the amount of insulin related to a safety lower limit, set the amount of insulin to be delivered by a drug delivery device below the safety upper limit, and initiate delivery of an amount of insulin according to the set amount of insulin. The non - transitory computer - readable medium includes these functions.

2. Further embodied in programming code executable by the processor, when the programming code is executed, the processor operates to determine whether the portion of the insulin delivery history meets the adequacy requirements by: analyzing the obtained portion of the insulin delivery history against a predetermined criterion, confirming, based on the result of the analysis, that the insulin delivery history meets the adequacy requirements that satisfy the total number of hours of data within a continuous period within the previous number of days, and performing a further function of generating a confirmation signal indicating that the insulin delivery history meets the adequacy requirements. The non - transitory computer - readable medium according to claim 1 includes this function.

3. Further embodied in programming code executable by the processor, when the programming code is executed, the processor: obtains new information related to the amount of insulin delivered by the drug delivery device from an updated insulin delivery history, determines that an adaptation mode is active, in response to the determination that the adaptation mode is active, sets the total daily insulin dosage based on a weighted sum of the previously set total daily insulin dosage and the average daily insulin dosage based on the updated insulin delivery history, and A non - transitory computer - readable medium according to claim 1, operative to perform a further function of transmitting the set total daily insulin dosage for reception by a wearable drug delivery device.

4. Further embodied in programming code executable by the processor, and when executing the programming code, the processor determines whether insulin delivery has occurred within a predetermined final insulin delivery period, and operates to perform a further function of transmitting the selected safety limit setting to the drug delivery device in response to a determination that the insulin delivery has occurred within the predetermined final insulin delivery period. A non - transitory computer - readable medium according to claim 3.

5. Further embodied in programming code executable by the processor, and when executing the programming code, the processor determines whether the drug delivery device has performed insulin delivery within a predetermined final insulin delivery period, and operates to perform a 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 performed insulin delivery within the predetermined final insulin delivery period. A non - transitory computer - readable medium according to claim 3.

6. Further embodied in further programming code executable by the processor, and when executing the further programming code, the processor operates to perform further functions to obtain new information related to the amount of insulin delivered by the drug delivery device from an updated insulin delivery history, determine that the adaptive mode is inactive, set the total daily insulin dosage to a daily average based on the obtained new information in response to a determination that the adaptive mode is inactive, set the adaptive mode to active, and include a function of providing the set total insulin dosage to the drug delivery device. A non - transitory computer - readable medium according to claim 1.

7. Further embodied in programming code executable by the processor, and when executing the programming code, the processor determine whether the drug delivery device has delivered insulin within a predetermined final insulin delivery period, and operate to perform a 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 final insulin delivery period, the non-transitory computer-readable medium of claim 6. **Claim 8** further embodied in programming code executable by the processor, and when executing the programming code, the processor determine whether the drug delivery device has delivered insulin within a predetermined final insulin delivery period, and operate to perform a further function of establishing an initial 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 final insulin delivery period, the non-transitory computer-readable medium of claim 6. **Claim 9** further embodied in programming code executable by the processor, and when executing the programming code for determining whether the portion of the insulin delivery history meets the sufficient requirements, the processor determine that the portion of the insulin delivery history does not meet the sufficient requirements, select a safety lower limit for the amount of insulin delivered over a period of time in response to a determination that the insulin delivery history does not meet the sufficient requirements, the selected safety lower limit being lower than the selected safety upper limit and exceeding the minimum amount of insulin delivered by the drug delivery device, and operate to limit the amount of insulin delivered by the wearable drug delivery device to below the selected safety lower limit, the non-transitory computer-readable medium of claim 1. **Claim 10** further embodied in programming code executable by the processor, and when executing the programming code, the processor further operate to set the safety lower limit to an insulin level equal to a multiplier applied to a basal insulin limit setting, the period being one day, the non-transitory computer-readable medium of claim 9. **Claim 11** Further embodied in programming code executable by the processor, when executing the programming code, the processor The non - transitory computer - readable medium of claim 9, further operative to provide an indication that the adaptive mode is inactive. **Claim 12** Further embodied in programming code executable by the processor, when executing the programming code, the processor operates to perform a function, and when determining whether the insulin delivery history is sufficient, the data of the insulin delivery history totals approximately 48 hours over a continuous period of about 54 hours without gaps exceeding about 6 hours, and the non - transitory computer - readable medium of claim 5, comprising a function of determining that it is not older than about 30 days. **Claim 13** A processor, a memory communicatively coupled to the processor and operative to store programming code, an artificial pancreas application, on - boarding application code, adaptive application code, and data related to the artificial pancreas application, the on - boarding application code, or the adaptive application code; the programming code, the artificial pancreas application, the on - boarding application code, and the adaptive application code are executable by the processor; a transceiver communicatively coupled to the processor and operative to transmit and receive signals including information usable by or generated by the artificial pancreas application, the on - boarding application code, and the adaptive application code, and to exchange signals with a wearable drug delivery device; when executing the artificial pancreas application, the on - boarding application code, or the adaptive application code, the processor controls the delivery of insulin and operates to perform a function; obtain a portion of the insulin delivery history related to the user, the insulin delivery history including the amount of insulin delivered for each of some insulin delivery dosages administered to the user; determine whether the portion of the insulin delivery history meets the sufficient requirements of the insulin history. In response to a determination that the insulin delivery history meets the sufficient requirements of the insulin history, set an initial total daily insulin value, and A device including a function of transmitting the initial total daily insulin value for reception by the wearable drug delivery device.

14. The processor is communicatively coupled to a blood glucose sensor, and the processor Receives a plurality of blood glucose measurement values from the blood glucose sensor, and each blood glucose measurement value is received at a predetermined time interval over a certain period of time, Change the initial total daily insulin value based on the plurality of received blood glucose measurement values, generate an adapted total daily insulin value, and The device according to claim 13, further operating to execute the operation of the wearable drug delivery device using the adapted total daily insulin value.

15. The processor Receives an indication that the wearable drug delivery device has been replaced with a replacement wearable drug delivery device, Obtain updated insulin delivery history data collected during the operation of the replaced wearable drug delivery device, and Further operate to set the total daily insulin delivered by the replacement wearable drug delivery device based on the sum of the parameters, the parameters corresponding to the total daily insulin set for the wearable drug delivery device and the amount of insulin delivered during the life cycle of the replaced wearable drug delivery device, and the weights being applied to each parameter. The device according to claim 13.

16. The processor Further operates to determine that the value of the weight applied to the parameter is based on the length of the updated insulin delivery history, and the value of the weight applied to each parameter is less than 1. The device according to claim 15.

17. The processor Further operates to receive an alarm signal from the wearable drug delivery device, the alarm signal indicating a malfunction of the wearable drug delivery device. The device according to claim 13.

18. A touch screen display device communicatively coupled to the processor, further comprising a user interface generated by the processor and presented on the touch screen display device The device according to claim 13, wherein the processor is operative to receive an input indicating a basal insulin dosage via the touch screen display device and the user interface **Claim 19** The processor maintains a count of the number of insulin doses automatically delivered over a period of time by the wearable drug delivery device maintains a count of the number of user-input insulin doses delivered over a period of time by the wearable drug delivery device generates a weighted confidence based on a ratio of the automatically delivered insulin doses to the number of user-input insulin doses delivered and is further operative to assign a higher weight to the insulin delivery during a higher percentage of the day compared to the insulin delivery requested by the user **Claim 20** The processor is 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 being selected when the processor determines that the insulin delivery history is sufficient and a second multiplier being selected when the processor determines that the insulin delivery history is insufficient

Images