Patent Application
20240252750
Automated drug delivery systems may use measured patient analyte values to determine drug dosages. For example, an automated insulin delivery system may rely on correct blood glucose readings from blood glucose monitors associated with the patient. The measured analyte readings may be used to calculate a dosage of the drug based on the analyte values and/or predicted trend lines based on the analyte values. In this manner, an automated drug delivery system may operate to provide an accurate and efficient level of the drug that is personalized for the patient and their specific physiological condition at the time of the drug delivery cycle.
If the automated drug delivery system is not able to receive patient analyte values (or a sufficient number of analyte values to make a determination), the system may rely on fallback mechanisms for calculating drug dosage during a delivery cycle, such as using conservative or default drug dosages or even stopping drug delivery. The fallback mechanisms are typically configured to provide a safe level of the drug; however, they reduce the overall efficacy of the automated drug delivery system because they are not able to provide a dose that relates directly to a current physiological condition (for instance, analyte levels associated with the drug) of the patient.
Accordingly, automated drug delivery devices may benefit from processes that are able to accurately and safely administer drug dosages specialized for the patient in the absence of analyte measurements.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended as an aid in determining the scope of the claimed subject matter.
In accordance with various embodiments of the present disclosure is a drug delivery device, having a processor a memory storing instructions. The instructions, when executed by the processor, may operate the drug delivery device to receive a present analyte measurement value from an analyte sensor during an initialization of the drug delivery device, receive at least one backfill value measured by the analyte sensor prior to the initialization, calculate a dosage of a drug using the present analyte measurement value and the at least one backfill value, and deliver the dosage of the drug.
In some embodiments of the drug delivery device, the at least one backfill value may include a plurality of analyte values determined by the analyte sensor prior to the initialization of the drug delivery device. In various embodiments of the drug delivery device, the at least one backfill value may include a plurality of analyte values stored by an external controller prior to the initialization of the drug delivery device.
In some embodiments of the drug delivery device, the instructions, when executed by the processor, may operate the drug delivery device to determine an analyte concentration trend based on the present analyte measurement and the at least one backfill value. In exemplary embodiments of the drug delivery device, the instructions, when executed by the processor, may operate the drug delivery device to calculate the dosage based on the analyte concentration trend. In various embodiments of the drug delivery device, the instructions, when executed by the processor, may operate the drug delivery device to receive the at least one backfill value from a controller located external to the drug delivery device.
In some embodiments of the drug delivery device, the initialization is associated with an exchange of the drug delivery device for a deactivated drug delivery device.
In various embodiments of the drug delivery device, the instructions, when executed by the processor, may operate the drug delivery device to determine whether the at least one backfill value meets a safety constraint. In some embodiments of the drug delivery device, the safety constraint may include a minimum number of values in the at least one backfill value. In exemplary embodiments of the drug delivery device, the safety constraint may include the at least one backfill value being within a correlation threshold of the present analyte measurement value.
In some embodiments of the drug delivery device, the analyte measurement value is a blood glucose measurement value, and the drug is insulin, glucagon, a glucagon-like peptide or a combination of at least two of insulin, glucagon or the glucagon-like peptide.
In accordance with various embodiments of the present disclosure is a controller for a drug delivery device, having a processor and a memory storing instructions. The instructions, when executed by the processor, may operate the controller to receive a deactivation indication from a first drug delivery device that the first drug delivery device is being deactivated, establish a connection to a sensor device responsive to the deactivation indication, and collect sensor measurement values from the sensor device as backfill values.
In some embodiments of the controller, the instructions, when executed by the processor, may operate the controller to receive an initialization indication from a second drug delivery device that the second drug delivery device is being initialized, and provide the at least one backfill value to the second drug delivery device.
In some embodiments of the controller, the initialization is associated with an exchange of the second drug delivery device for the first drug delivery device. In various embodiments of the controller, the analyte measurement value is a blood glucose measurement value, and the drug is insulin, glucagon, a glucagon-like peptide or a combination of at least two of insulin, glucagon or the glucagon-like peptide.
In accordance with various embodiments of the present disclosure is a computer-implemented method of operating a drug delivery device. The method may include, via a processor of the drug delivery device, receiving a present analyte measurement value from an analyte sensor during an initialization of the drug delivery device, receiving at least one backfill value measured by the analyte sensor prior to the initialization, calculating a dosage of a drug using the present analyte measurement value and the at least one backfill value, and delivering the dosage of the drug.
In some embodiments of the method, the at least one backfill value may include a plurality of analyte values determined by the analyte sensor prior to the initialization of the drug delivery device. In some embodiments of the method, the at least one backfill value may include a plurality of analyte values stored by an external controller prior to the initialization of the drug delivery device.
In some embodiments of the method, the method may include determining an analyte concentration trend based on the present analyte measurement and the at least one backfill value. In some embodiments of the method, the method may include calculating the dosage based on the analyte concentration trend.
In some embodiments of the method, the method may include receiving the at least one backfill value from a controller located external to the drug delivery device.
In some embodiments of the method, the initialization is associated with an exchange of the drug delivery device for a deactivated drug delivery device.
In some embodiments of the method, the method may include determining whether the at least one backfill value meets a safety constraint. In some embodiments of the method, the safety constraint may include a minimum number of values in the at least one backfill value. In some embodiments of the method, the safety constraint may include the at least one backfill value being within a correlation threshold of the present analyte measurement value.
In some embodiments of the method, the analyte measurement value is a blood glucose measurement value, and the drug is insulin, glucagon, a glucagon-like peptide or a combination of at least two of insulin, glucagon or the glucagon-like peptide.
In accordance with various embodiments of the present disclosure is a computer-implemented method of operating a controller for a drug delivery device, comprising, via a processor of the controller, receiving a deactivation indication from a first drug delivery device that the first drug delivery device is being deactivated, establishing a connection to a sensor device responsive to the deactivation indication; and collecting sensor measurement values from the sensor device as backfill values.
In some embodiments of the method, the method may include receiving an initialization indication from a second drug delivery device that the second drug delivery device is being initialized, and providing the at least one backfill value to the second drug delivery device. In various embodiments of the method, the initialization is associated with an exchange of the second drug delivery device for the first drug delivery device.
In some embodiments of the method, the analyte measurement value is a blood glucose measurement value, and the drug is insulin, glucagon, a glucagon-like peptide or a combination of at least two of insulin, glucagon or the glucagon-like peptide.
The drawings are not necessarily to scale. The drawings are merely representations, not intended to portray specific parameters of the disclosure. The drawings are intended to depict example embodiments of the disclosure, and therefore should not be considered as limiting in scope. In the drawings, like numbering represents like elements.
As described below, a drug delivery system may include a number of components, such as a drug delivery device, a controller, and an analyte sensor. The drug delivery device may be controlled and operate based on signals containing information received from the analyte sensor. Control may be based on an application executing on the drug delivery device, the controller, or the analyte sensor, or the application may be distributed between two or more of the drug delivery device, the controller, or the analyte sensor. For example, the drug delivery device may be configured to deliver a drug at a dosage or frequency based on a measured analyte concentration associated with a patient.
An example of an automatic analyte control application or logic circuit may be specific to a particular type of analyte. Non-limiting examples of analytes may include blood glucose, a hormone, a protein, a medication, ketone, alcohol level, a concentration of the drug itself (e.g., insulin), and the like. A control application specific to controlling a patient's blood glucose may be an Automatic Glucose Control (AGC) application that may rely on a blood glucose measurement value and other information that may be provided by a continuous glucose monitor (CGM). “Automatic glucose control” may refer to an algorithm or computer application that is operable to use blood glucose measurements to determine amounts of a drug to be delivered to a user to in order to maintain the user's measured blood glucose within a set range of blood glucose measurement values. “Blood glucose measurement value” may refer to a numerical value representative of an amount of glucose in a user's blood that has the units of milligrams per deciliter (mg/dL). The other information provided by the CGM may be included as part of, or separately from, the blood glucose measurement value. The AGC may be operable to estimate and store the estimated values of CGM based upon various parameters within the drug delivery system. Such future trend information may be useful in case of missing CGM values to estimate suggested insulin for a short duration.
Although insulin delivery devices, insulin, blood glucose, AGC applications, and CGM devices are used in examples in the present disclosure, embodiments are not so limited as these are provided for illustrative purposes. Embodiments may operate with various types of fluid or drug delivery devices, drugs or other fluids, analytes, automated drug delivery applications, and/or analyte sensors in accordance with the teachings of the present disclosure.
A drug delivery system may include a component that requires replacement based on a time interval, delivery of a volume of the drug, and/or the like. For example, a wearable insulin delivery device may include an insulin pump unit that may include, among other things, a pump, an insulin reservoir, and control elements to control the pump to deliver a dosage of insulin from the insulin reservoir. The insulin pump unit, or a portion thereof, such as the drug or a reservoir containing the drug, may require replacement every 48 to 72 hours or after delivery of a certain volume of insulin (for instance, 200 units). The insulin pump unit may be controlled by an AGC operating on the insulin pump unit and/or an external logic device, such as a computing device (for instance, a smart phone) or a dedicated personal diabetes manager (PDM) device (see, for example,
Deactivation and removal of the previous or old insulin pump unit and installation and activation of the new insulin pump unit may require a substantive amount of time, such as about 5 minutes to about 25 minutes. Depending on the efficiency of the patient and associated drug delivery device components, this may take much longer. In a conventional insulin delivery device, CGM values may not be available or may not be available to the insulin delivery system in a form capable of being used to determine insulin dosage by the AGC until the new insulin pump unit has gone through an initialization or “warm up” period. If the insulin pump unit requires changing every 72 hours, this may lead to a significant amount of time on a weekly basis where CGM-based insulin dosage control is not available to the patient. In the absence of CGM-based insulin dosage control, insulin delivery may be based on conservative default values, such as a patient's basal dosage or less, which may not adequately control a patient's dynamic blood glucose level. In addition, patient conditions (such as a diabetes patient being in a hypo- or hyper-glycemic state) may not be transferred to the new insulin pump unit.
For example, during initialization, AGC systems typically assume that the initial input CGM value has been maintained at a constant value, and establishes a predicted glucose trend as a flat trajectory with the first input CGM value received during initialization (see, for example,
Accordingly, systems and methods according to some embodiments, may provide processes and a drug delivery device capable of measurement-based drug delivery during the initialization (or “warm up”) period. For example, during activation or initialization of the device (for instance, an insulin pump unit), the controller may send CGM values, trends, and/or a few previous CGM values before and/or during device activation. This is during the time window when the previous device was deactivated but the new device was not yet activated. In this opportunistic window, the controller can continue to receive the CGM value by connecting over its own communication path with the CGM and may send this information immediately after activation. In addition, patient conditions under the old insulin pump unit may be immediately or substantially immediately transferred to the new insulin pump unit. Accordingly, a new insulin pump unit may operate to provide insulin based on control processes associated with the patient conditions, such as a hypo- or hyper-glycemic state.
Accordingly, some embodiments may provide methods that manage (or essentially eliminate) the initial blanking period of conventional device where the drug delivery algorithm call is delayed and/or is active but provides conservative dosage values (without the use of CGM data) for a time period and/or during warmup cycles. The AGC process can immediately determine trajectory and time lapse between previous activation and the current activation, thereby approximating the insulin needed immediately and allowing for completion of the warmup process sooner or immediately, depending upon the recent information and the completeness of the CGM information, trend, and past values during the activation. For example, in some embodiments, a new insulin pump unit may be activated immediately or substantially immediately (for instance, within a time period substantially smaller than for conventional devices, such as within the first 1 to 5 minutes of installation on the patient) because the AGC algorithm may use the previous CGM values, trend, and most recent information to accelerate the warm-up to exit out of conservative mode and start CGM-based insulin delivery.
Therefore, drug delivery systems and methods for operating drug delivery devices according to some embodiments may provide multiple technological advantages over conventional systems and methods. In one non-limiting technological advantage, systems may be configured to provide analyte-based drug delivery control during initialization (or “warm up”) of a new device. Conventional devices were only capable of proceeding with a conservative drug delivery approach during and for a certain period after activation of a new drug delivery device. The non-limiting technological advantages may include improvements in computing technology and/or technical field. For instance, systems and methods according to some embodiments may improve conventional logic devices, controllers, computing devices, and/or other computing technology for controlling drug delivery systems by providing computing technology capable of analyte-based drug delivery control during an initialization process of a drug delivery device. In addition, systems and methods according to some embodiments may improve the field of automated drug delivery, including, for example, wearable insulin drug delivery devices and associated processes for controlling these devices, drug therapy, diabetes therapy, and/or the like. Furthermore, the methods according to some embodiments may be applied to the practical applications of controlling a drug delivery device, providing a dosage of a drug to a patient, drug therapy, and/or diabetes therapy. Embodiments are not limited in this context. Additional technological advantages, practical applications, and improvements to computing technology and/or technical fields would be known to a person of skill in the art in view of the teachings of the present disclosure.
Drug delivery system 105 may include a logic device or controller 110, drug delivery device 160 and an analyte sensor 170. Controller 110 may communicate with the drug delivery device 160 via communication link 111 and the drug delivery device 160 may communicate with the analyte sensor 170 via a communication link 112. “Communication link” may refer to a signal pathway between a first device and a second device. As described below, information may be exchanged between the first device and the second device where both devices may transmit and receive information or other signals.
In some embodiments, controller 110 may be a smart phone, PDM, or other mobile computing form factor in wired or wireless communication with drug delivery device 160. For example, controller device 110 and drug delivery device 160 may communicate via various wireless protocols, including, without limitation, Wi-Fi (i.e., IEEE 802.11), radio frequency (RF), Bluetooth®, Zigbee™, near field communication (NFC), Medical Implantable Communications Service (MICS), and/or the like. In another example, controller 110 and adjustment compliance device may communicate via various wired protocols, including, without limitation, universal serial bus (USB), Lightning, serial, and/or the like.
Although controller 110 (and components thereof), drug delivery device 160, and analyte sensor 170 are depicted as separate devices, embodiments are not so limited. For example, in some embodiments, controller 110, drug delivery device 160, and/or analyte sensor 170 may be a single device. In another example, some or all of the components of controller 110 may be included in drug delivery device 160. For example, drug delivery device 160 may include processor circuitry 120, memory unit 130, and/or the like. In some embodiments, each of controller 110 and drug delivery device 160 may include a separate processor circuitry 120, memory unit 130, and/or the like capable of facilitating automatic analyte control and/or device initialization processes according to some embodiments, either individually or in operative combination. Embodiments are not limited in this context (see, for example,
Drug delivery device 160 may include a number of components to facilitate automated delivery of a drug to patient 150. For example, drug delivery device 160 may include a reservoir for storing the drug, a needle or cannula for delivering the drug into the body of the patient, and a pump for transferring the drug from the reservoir, through the needle or cannula, and into the body of the patient. In some embodiments, the drug may be or may include insulin. Drug delivery device 160 may also include a power source, such as a battery, for supplying power to the pump and/or other components of drug delivery device 160. Embodiments are not limited in this context, for example, as drug delivery device 160 may include more or fewer components.
“Analyte sensor” may refer to a sensing and measuring device that may be configured to measure one or more of lactate, ketones, uric acid, sodium, a protein, potassium, alcohol levels, hormone levels, blood glucose, a medication, a drug, a chemotherapy drug, glucagon or a glucagon-like peptide, and/or the like. In some examples, analyte sensor 170 may be configured as a continuous glucose monitor (CGM), which may refer to a wearable device that may at least include a sensor configured to measure blood glucose of a wearer, a transmitter to transmit blood glucose measurement values measured by the sensor (for example, to controller 110 and/or drug delivery device 160), and logic circuitry that controls the sensor and the transmitter. Analyte sensor 170 may be configured with a processor, a communication device, a memory, a sensing/measuring device, and/or other components (see, for example,
In drug delivery system 105 of
Analyte sensor 170 may provide an analyte measurement value at a specific time during an operational time period to drug delivery device 160. “Analyte measurement value” may refer to a numerical value representative of an amount of an analyte being monitored by an analyte sensor and that has the units in common usage of the analyte being monitored, such as milligrams per deciliter (mg/dL), a percentage, or the like. In an example, analyte sensor 170 may be configured to output an analyte measurement value at a predetermined cadence (e.g., every 1, 2, 3, 5, or 10 minutes) or once within a set period of time (e.g., at time=0 in a 5-minute period of time). The set period of time in the example of a diabetes treatment plan may be referred to as a “cycle” or “cycle time,” which may last 5 minutes, or about 5 minutes, about 3 minutes, or about 10 minutes, or the like. A specific time during the operation may be at the beginning of the operational time period.
The outputted analyte measurement value is intended, in this embodiment, for receipt by the drug delivery management application 140 executing on controller 110 and/or automatic analyte control (AAC) application executing on drug delivery device 160, but may be shared with other applications, such as an automatic medication delivery application, an artificial pancreas application, and/or the like. The analyte measurement values may include information that includes an analyte measurement value, such as a blood glucose measurement value, but also information such as analyte rate of change, status information related to a sensing/measuring device in analyte sensor 170, and/or the like.
Controller 110 may be configured with a processor or processor circuitry 120, a memory unit 130, a user interface 182, a communication device or transceiver 180, and/or the like. Memory unit 130 may store information, such as patient information 134, analyte sensor information 134, drug delivery information 136, each of which may include previous analyte measurement values, delivered drug dosages, and/or the like.
In some embodiments, patient information 132 may include information associated with patient 150, including, without limitation, demographic information, physical information (for instance, height, weight, and/or the like), diabetes condition information (for instance, type of diagnosed diabetes (T1D or T2D)), insulin needs (for instance, MDI information, TDI information, insulin types, basal dosage information, bolus dosage information, and/or the like), activity information (for instance, meals and/or meal times, carbohydrate intake, exercise information, and/or the like), insulin sensitivity information, IOB information, BG events (for example, hypoglycemic episodes or hyperglycemic episodes), and/or the like. In some embodiments, at least a portion of patient information 132 may be manually entered by patient 150 or a caregiver, for example, via a user interface of diabetes management application 140. In other embodiments, at least a portion of patient information 132 may be downloaded automatically from network 190 or cloud-based services 611, or transferred automatically from a prior drug delivery device 160 to a new drug delivery device 160. In some embodiments, patient information 132 may include historical information, such as historical values associated with mealtimes, carbohydrate intake, exercise times, and/or the like.
In some embodiments, analyte sensor information 134 may include information associated with analyte sensor 170, including analyte values measured by analyte sensor 170. For example, for a CGM sensor, analyte sensor information 134 may include blood glucose measurements of patient 150. In various embodiments, analyte sensor information 134 may include historical or “backfill” values. In some embodiments, values measured by analyte sensor 170 may be stored as backfill values. In various embodiments, backfill values may include a set number of previous values (for instance, from 2 to 50 previous values) or may include values measured during a previous time period (for instance, the previous 2 minutes to about 60 minutes or the previous 1 cycle to 10 cycles). In some embodiments, the historical or backfill values may be saved by analyte sensor 170, controller 110, and/or drug delivery device 160 and stored in various locations, including on analyte sensor 170, controller 110, drug delivery device 160, and/or a data source 192a-n (including a remote computing device) accessible via network 190.
In some embodiments, drug delivery information 136 may include information used to determine the dosage of the drug to deliver to patient 150, for instance, based on analyte sensor information 134. For example, AAC 166 may determine a dosage of the drug to be delivered based on an analyte value and/or trend determined based on analyte sensor information 134. For example, for an insulin delivery device, AAC 166 may determine a dosage of insulin to deliver for an upcoming delivery cycle based on a trend of patient blood glucose concentrations predicted based on blood glucose values measured by a CGM analyte sensor 170 in order to maintain a blood glucose concentration target or range.
Additionally, memory unit 130 may store computer applications, such as a drug delivery management application 140, which may be or may include a medication delivery application (MDA), an automatic analyte control application, an AGC application, an analyte-based drug delivery application, an automatic analyte control application, an artificial pancreas application, an automated insulin delivery (AID) application, and/or the like, that are executable by processor circuitry 120 and configure processor circuitry 120 to perform different functions according to some embodiments of the present disclosure. Drug delivery management application may include an “automatic analyte control application” that may refer to a computer application that is operable to execute an algorithm operable to use analyte measurement values, including blood glucose measurement values, to locally determine amounts of a drug to be delivered to a user.
Controller 110 when executing drug delivery management application 140 may be configured to set operational parameters for drug delivery device 160, such as user preferences for drug deliveries (e.g., times, durations, and amounts of basal and/or bolus deliveries) and notifications/alarms, drug delivery limits, user statistics (e.g., height, weight, gender, age, type of diabetes, or the like) as well as other settings.
Drug delivery device 160 may also be configured with a processor, a memory, a user interface, a communication device, and/or other components (see, for example,
In drug delivery system 105, analyte sensor 170 may be configured to provide a present analyte measurement value to the drug delivery device 160. The present analyte measurement value may include information related to the present analyte measurement value as well as information related to past analyte measurement values. For example, when analyte sensor 170 is a continuous glucose monitor (CGM), analyte sensor 170 may be configured to provide a blood glucose measurement value or data indicative of a blood glucose measurement value (for instance, in one non-limiting example, raw data that may be converted into blood glucose values). In addition, analyte sensor 170, when configured as a CGM, may provide a blood glucose trend indication, as well as blood glucose measurement values from one or more past cycles, such as the past two to four cycles. For example, if the CGM is configured to provide a blood glucose measurement value once every 5 minutes (i.e., once every cycle) to drug delivery device 160, the CGM may provide a present analyte measurement value (i.e., a present blood glucose measurement value) at the beginning of a 5-minute cycle as well as past analyte measurement values (i.e., past blood glucose measurement values) from 5 minutes ago and 10 minutes ago. In the example, the present blood glucose measurement value may be provided at time=t(0) and the past blood glucose measurement values may be from time=t(−5) and time=t(−10). The past blood glucose measurement values are obtained at a time prior to the present blood glucose measurement value.
Automatic analyte control application 166 may be configured to receive the respective analyte measurement value from analyte sensor 170 during each respective cycle time, including prior cycle times and the present cycle time. In an operational example, the processors (or processing circuitry) in each of the controller 110, drug delivery device 160 and analyte sensor 170 may be synchronized, for example, based on a common clock or heartbeat. Drug delivery device 160 may be provided with information related to analyte sensor 170 by an application executing on controller 110. For example, a user may input an identifier of analyte sensor 170 into a user interface presented on controller 110. Drug delivery device 160 may receive analyte sensor 170 identifier via communication link 111 from controller 110. Drug delivery device 160 may use analyte sensor 170 identifier to establish communication link 112 with analyte sensor 170. For example, using known handshaking protocols, drug delivery device 160 may provide its identifier to the processor of analyte sensor 170. In some embodiments, analyte measurement values from analyte sensor 170 may be delivered to drug delivery device 160. In other embodiments, analyte measurement values from analyte sensor 170 may be delivered to controller 110.
Using known handshaking protocols or similar procedures, communication link 112 may be established by drug delivery device 160 or analyte sensor 170 at the beginning of each cycle (e.g., preset time period) for a duration long enough to deliver a present analyte measurement value as well as information related to the present analyte measurement value. Once the present analyte measurement value and the information related to the present analyte measurement value are delivered, communication link 112 may be dropped (i.e., disconnected) until the beginning of the next cycle. One purpose of reestablishing communication link 112 at the beginning of every cycle may be to conserve energy for both drug delivery device 160 and analyte sensor 170.
In some embodiments, drug delivery device 160 (or a portion thereof) may need to be exchanged with a new drug delivery device 160. For example, drug delivery device 160 may need to be replaced after a certain time period (for instance, from 24 to 72 hours), after a certain volume of the drug has been dispensed (for instance, about 200 units of insulin), after an indication of a change event, and/or at the discretion of the patient. A non-limiting example of a change event may include an error, empty reservoir (or reservoir volume below a threshold), detection of damage, malfunction, and/or the like.
During the exchange process, drug delivery device 160 may be deactivated and removed from patient 150. A new drug delivery device 160 may be implanted on patient and an activation process may be initiated to prime the new drug delivery device 160 and connect the new drug delivery device 160 components such as analyte sensor 170 and/or controller 110. During this deactivation and initialization phase, drug delivery device 160 may not be able to receive analyte sensor information 134 to perform AAC 166 to provide analyte-based drug delivery. Accordingly, drug delivery device 160 may operate under a standard control 164 process. In some embodiments, standard control 164 may include providing patient 150 with a conservative or “safe” dosage of the drug. For an insulin delivery device, the conservative dosage may be a preset basal dosage, no dosage (for instance, 0 units of insulin), and/or a value between basal and no dosage. In some embodiments, the basal dosage may be a basal dosage determined for the patient during an onboarding process or a basal dosage updated based on patient history with drug delivery system 105.
In some embodiments, patient 150 may initiate a deactivation process for drug delivery device 160 via drug delivery device 160 and/or controller 110 (for instance, via drug delivery management application and user interface 182). A deactivation event or signal may be provided to controller 110 when the deactivation process is initiated. In other embodiments, a deactivation event may be determined based on a lack of communication or other functionality of drug delivery device detected by controller (for instance, patient removes drug delivery device 160 or drug delivery device 160 malfunctions without starting with a deactivation process). Responsive to detecting a deactivation event, controller 110 may establish communication link 113 with analyte sensor 170 (if, for instance, communication link 113 has not already been established). In addition, controller 110 may collect and/or store analyte values measured by analyte sensor as backfill values. In some embodiments, the backfill values may be stored as analyte sensor information 134. In some embodiments, controller may collect and store backfill values from analyte sensor 170 until an activation event is detected. In some embodiments, an activation event may be or may include detection of a new drug delivery device 160 and/or detection that drug delivery device 160 may receive analyte measurements from analyte sensor 170.
During the time window when the previous drug delivery device 160 was deactivated but the new drug delivery device 160 was not activated, controller 110 can continue to receive the analyte values measured by analyte sensor by connecting over its own communication link 113 and sending or using this information immediately after activation of the new drug delivery device 160 for automated control of drug delivery via drug delivery device 160 (for instance, via AAC 166).
As indicated in
Referring now to
For example, certain commercial analyte sensors may have the capability to provide “backfill” analyte values (for instance, when stored locally in a memory) when communication is established. In another example, controller 110 may store analyte values that may be used as backfill values. Drug delivery system 105 can deliver a drug based on a trend calculated from these backfill values, avoiding the need for a more conservative starting period over several minutes. In this manner, analyte-based drug delivery processes according to some embodiments may provide better treatment to patient 150.
Future analyte values may be predicted based on prior analyte values. For example, for an insulin delivery device, future glucose values may be predicted based on prior glucose measurement values (for instance, trend 320). An insulin basal delivery rate may be determined or adjusted to be provided by an insulin delivery device based on the predicted future glucose values. Insulin may be delivered via the insulin delivery device according to the adjusted insulin basal delivery rate. Predictions of future glucose values or trends based on backfill values and/or the determination of insulin delivery dosages based on predictions of future glucose values based on backfill values may be determined according to various processes. Non-limiting examples of prediction and/or dosing processes for insulin may include all or some of U.S. patent application Ser. No. 16/586,499, entitled “Onboarding and Total Daily Insulin Adaptivity;” Ser. No. 16/402,753, entitled “Safety Constraints for a Control Algorithm Based Drug Delivery System;” and/or Ser. No. 17/112,314, entitled “Techniques and Devices Providing Adaptivity and Personalization in Diabetes Treatment;” each of which is incorporated by reference as if fully set forth in this present disclosure.
If initial analyte values are not available at the time of activation, processes according to some embodiments may use stratification based upon missing points from any prior analyte point or backfill information. In various embodiments, analyte-based drug delivery control may assess if the suggested delivery based on stratification compared to the conservative approach of basal and delivers and determine delivery dosages accordingly. For example, for an insulin delivery device, if blood glucose was dropping before the deactivation event (or the sensor and drug delivery device otherwise lose communication), then the analyte-based drug delivery process (i.e., AAC) may determine that glucose will, for instance, continue to drop, at least for a period of time, taking into account past trends. Accordingly, as the analyte-based drug delivery process continues to miss points, the process may determine what occurred in the past via the backfill values and determine a trend. For instance, analyte-based drug delivery process may perform a stratified missing point compensation process for points or other information missing due to the deactivation/initialization process. A non-limiting example of a stratified missing point compensation process may include processes the same or similar to the subject matter disclosed in U.S. Provisional Patent Application Ser. No. 63/158,643, entitled “Opportunistic Retrieval of Analyte Value to Improve Automatic Drug Control Accuracy,” which is incorporated by reference as if fully set forth in this present disclosure.
Included herein are one or more logic flows representative of exemplary methodologies for performing novel aspects of the disclosed architecture. While, for purposes of simplicity of explanation, the one or more methodologies shown herein are shown and described as a series of acts, those skilled in the art will understand and appreciate that the methodologies are not limited by the order of acts. Some acts may in accordance therewith, occur in a different order and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all acts illustrated in a methodology may be required for a novel implementation.
A logic flow may be implemented in software, firmware, hardware, or any combination thereof. In software and firmware embodiments, a logic flow may be implemented by computer executable instructions stored on a non-transitory computer readable medium or machine readable medium. The embodiments are not limited in this context.
At block 402, logic flow 400 may determine whether a deactivation request has been received. For example, controller 110 may receive or determine that patient 150 (or another user) has initiated deactivation of drug delivery device 160. In some embodiments, a direct deactivation may not be required at block 402. For example, block 402 may cause logic flow to move to block 404 responsive to a loss of communication or other functionality of a drug delivery device. Logic flow 400 may cause a controller (or other logic device) to establish a connection with an analyte sensor. For example, controller 110 may establish a communication link 113 with analyte sensor 170. At block 406, logic flow 400 may collect analyte sensor information as backfill values. For example, controller 110 may receive analyte values measured via analyte sensor 170 over communication link 113. The analyte values may be stored as backfill values in analyte sensor information 134.
At block 408, logic flow 400 may determine whether a new drug delivery device has been activated and connected to the analyte sensor. For example, controller 110 may receive a signal indicating or otherwise determine that a new drug delivery device 160 has been activated and is receiving analyte values from analyte sensor 170.
In some embodiments, logic flow 400 may cause the controller to stop collecting analyte values from analyte sensor as backfill values at block 410. In various embodiments, at block 412, logic flow 400 may disconnect controller from analyte sensor, for instance, by disconnecting communication link 113 between controller 110 and analyte sensor 170.
At block 502, logic flow 500 may receive a request to activate a new drug delivery device. For example, a new drug delivery device 160 may be installed on patient and may start an initiation process. Logic flow 500 may receive an analyte measurement value from an analyte sensor at block 504. For instance, (new) drug delivery device 160 may receive an analyte value measured by analyte sensor 170. At block 508, logic flow 500 may determine whether a threshold number of sensor values has been received. For example, an AAC process for controlling drug delivery via drug delivery device 160 may operate based on analyte values, trends, and/or the like. The AAC process may require a certain number, amount, or other threshold of analyte values to use as a basis for drug delivery. For example, the threshold may be a certain number of (continuous or semi-continuous) measured analyte values, such as 2 values, 3 values, 4 values, 5 values, 10 values, 20 values, 30 values, 100 values, and any value or range between any two of these values (including endpoints). In another example, the threshold may be based on a time period of value measurement, such as 1 minute, 5 minutes, 10 minutes, 15 minutes, 20 minutes, 30 minutes, 60 minutes, and any value or range between any two of these values (including endpoints). In a further example, the threshold may be based on a number of cycles, such as 1 cycle, 3 cycles, 5 cycles, 10 cycles, and any value or range between any two of these values (including endpoints).
If the threshold number of sensor values has been received by the drug delivery device 160, logic flow 500 may calculate the dosage of the drug using the measured analyte values at block 530. If the threshold number of sensor values has not been received by the drug delivery device 160, logic flow 500 may determine an activation time lapse period at block 510. In some embodiments, the time lapse period may be a time period between when the previous drug delivery device 160 was deactivated and the new drug delivery device 160 was activated (and/or received a first analyte value from analyte sensor 170). In general, in various embodiments, the time lapse value may be a time period or duration thereof in which a drug delivery device was inactive.
At block 512, logic flow 500 may receive backfill values determined during the time lapse period. For example, controller 110 may store or may access backfill values measured by analyte sensor 170 while drug delivery device 160 was inactive and/or not receiving analyte values from analyte sensor 170. The number and/or duration of backfill values may be determined based on the amount of available backfill values. In various embodiments, the number of backfill values may be a threshold number of backfill values, such as 2 values, 3 values, 4 values, 5 values, 10 values, 20 values, 30 values, 100 values, and any value or range between any two of these values (including endpoints). In another example, the threshold duration of backfill values may be based on a time period, such as 1 minute, 5 minutes, 10 minutes, 15 minutes, 20 minutes, 30 minutes, 60 minutes, and any value or range between any two of these values (including endpoints). In a further example, the threshold may be based on a number of cycles, such as 1 cycle, 3 cycles, 5 cycles, 10 cycles, and any value or range between any two of these values (including endpoints).
In general, the threshold of backfill values may be required to ensure there is a sufficient amount of backfill values to determine trends and/or the like for use by an AAC process to deliver a drug based, at least in part, on the backfill values. In some embodiments, backfill values may be used over a duration that precedes the time lapse period (for instance, the time lapse period may be 5 minutes and backfill values measured 10 minutes prior may also be used alone or along with those measured during the time lapse period).
At block 514, logic flow 500 may determine whether the backfill values are within safety constraints. For example, a correlation safety constraint may be based on whether measured analyte values received when the new drug delivery device 160 is activated and starts receiving values is within a correlation threshold of the backfill values. For instance, a correlation threshold for an analyte may be a concentration of 20 mg/dL (or other units as appropriate, such as units/liter). If a first analyte value is (or threshold number of first values are) determined to be 20 mg/dL different from the backfill values (or a specific range of backfill values, such as the last five values), then a safety event may be triggered at block 540 and the backfill values are not used to determine a drug delivery dosage (for example, the first value is 10 units/liter and the last five backfill values average 40 units/liter). In various embodiments, a safety constraint may include requiring a sufficient number and/or continuous number of backfill values. For example, if there is an insufficient number of backfill values (for instance, between less than 10 and less than 2) or if there is too long of a duration of missing backfill values (for instance, between 1 minute and 10 minutes between consecutive backfill values), a safety event may be triggered.
In some embodiments, a safety event may cause a default amount of the drug dosage to be used (for instance, a preset basal amount, less than a preset or historical basal amount, no volume of the drug, and/or the like). In various embodiments, a safety event may cause an alert or other message to be presented to patient 150 or another user, for example, for manual analyte measurement and drug delivery.
Logic flow 500 may calculate a dosage of the drug using the backfill values at block 516. For example, referring to
In some embodiments, the calculated dosage may be based on a conservative, preset basal dosage. For example, logic flow 500 may determine a confidence level associated with the backfill values. In some embodiments, the calculated dosage may be a multiple or add-on to a preset or a historical basal dosage (e.g., a historical average basal dosage) (in either case, hereafter “basal”) depending on a confidence level in the backfill values. For instance, for a confidence level of X, the calculated dosage may be (basal)*(1.10). In another instance, for a confidence level of Y, the calculated dosage may be (basal)*(0.5). In some embodiments, if the confidence level is above a confidence threshold value, the calculated dosage may be based on a prediction processes described in the present disclosure. In other embodiments, if the confidence level is below the confidence threshold value, the calculated dosage may be based on the basal value.
At block 518, logic flow 500 may cause the calculated dosage of the drug to be delivered to the patient.
The operating environment 600 may be or may include an automatic drug delivery system that may include components such as an automatic drug delivery system that is configured to determine a drug dosage and deliver the dosage of the drug without any user interaction, or in some examples, limited user interaction, such as in response to a user depressing a button to indicate measurement of blood glucose or another analyte, or the like. “Drug delivery system environment” may refer to a computing and sensing environment that includes cloud based services, a drug delivery system (that may include a controller, a drug delivery device, and an analyte sensor) and optionally additional devices. The components of the drug delivery system environment may cooperate to provide present analyte measurement values or at least accurate estimates of present analyte measurement values to facilitate calculation of optimal drug dosages for a user.
The automatic drug delivery system 600 may implement (and/or provide functionality for) a medication delivery algorithm, such as an artificial pancreas (AP) application, to govern or control automated delivery of a drug or medication, such as insulin, to a user (e.g., to maintain euglycemia-a normal level of glucose in the blood). The drug delivery system 600 may be an automated drug delivery system that may include a wearable automatic drug delivery device 602, an analyte sensor 603, and a management device (for instance, a PDM, smart phone, table computing device, and/or the like) 605.
The system 600, in an optional example, may also include a smart accessory device 607, such as a smartwatch, a personal assistant device or the like, which may communicate with the other components of system 600 via either a wired or wireless communication links 691-693.
The management device 605 may be a computing device such as a smart phone, a tablet, a personal diabetes management device, a dedicated diabetes therapy management device, or the like. In an example, the management device (PDM) 605 may include a processor 651, a management device memory 653, a user interface 658, and a communication device 654. The management device 605 may contain analog and/or digital circuitry that may be implemented as a processor 651 for executing processes based on programming code stored in the management device memory 653, such as the medication delivery algorithm or application (MDA) 659, to manage a user's blood glucose levels and for controlling the delivery of the drug, medication, or therapeutic agent to the user as well as other functions, such as calculating carbohydrate-compensation dosage, a correction bolus dosage and the like as discussed above. The management device 605 may be used to program, adjust settings, and/or control operation of the wearable automatic drug delivery device 602 and/or the analyte sensor 603 as well as the optional smart accessory device 607.
The processor 651 may also be configured to execute programming code stored in the management device memory 653, such as the MDA 659. The MDA 659 may be a computer application that is operable to deliver a drug based on information received from the analyte sensor 603, the cloud-based services 611 and/or the management device 605 or optional smart accessory device 607. The memory 653 may also store programming code to, for example, operate the user interface 658 (e.g., a touchscreen device, a camera or the like), the communication device 654 and the like. The processor 651 when executing the MDA 659 may be configured to implement indications and notifications related to meal ingestion, blood glucose measurements, and the like. The user interface 658 may be under the control of the processor 651 and be configured to present a graphical user interface that enables the input of a meal announcement, adjust setting selections and the like as described above.
In a specific example, when the MDA 659 is an artificial pancreas (AP) application, the processor 651 is also configured to execute a diabetes treatment plan (which may be stored in a memory) that is managed by the MDA 659 stored in memory 653. In addition to the functions mentioned above, when the MDA 659 is an AP application, it may further provide functionality to enable the processor 651 to determine a carbohydrate-compensation dosage, a correction bolus dosage and determine a basal dosage according to a diabetes treatment plan. In addition, as an AP application, the MDA 659 provides functionality to enable the processor 651 to output signals to the wearable automatic drug delivery device 602 to deliver the determined bolus and basal dosages described with reference to the examples of
The communication device 654 may include one or more transceivers such as Transceiver A 652 and Transceiver B 656 and receivers or transmitters that operate according to one or more radio-frequency protocols. In the example, the transceivers 652 and 656 may be a cellular transceiver and a Bluetooth® transceiver, respectively. For example, the communication device 654 may include a transceiver 652 or 656 configured to receive and transmit signals containing information usable by the MDA 659.
The wearable automatic drug delivery device 602, in the example system 600, may include a user interface 627, a controller 621, a drive mechanism 625, a communication device 626, a memory 623, a power source/energy harvesting circuit 628, device sensors 684, and a reservoir 624. The wearable automatic drug delivery device 602 may be configured to perform and execute the processes described in the examples of
The memory 623 may store programming code executable by the controller 621. The programming code, for example, may enable the controller 621 to control expelling insulin from the reservoir 624 and control the administering of doses of medication based on signals from the MDA 629 or, external devices, if the MDA 629 is configured to implement the external control signals.
The reservoir 624 may be configured to store drugs, medications or therapeutic agents suitable for automated delivery, such as insulin, morphine, blood pressure medicines, chemotherapy drugs, or the like.
The device sensors 684 may include one or more of a pressure sensor, a power sensor, or the like that are communicatively coupled to the controller 621 and provide various signals. For example, the pressure sensor may be coupled to or integral with a needle/cannula insertion component (which may be part of the drive mechanism 625) or the like. In an example, the controller 621 or a processor, such as 651, may be operable to determine that a rate of drug infusion based on the indication of the fluid pressure. The rate of drug infusion may be compared to an infusion rate threshold, and the comparison result may be usable in determining an amount of insulin onboard (IOB) or a total daily insulin (TDI) amount.
In an example, the wearable automatic drug delivery device 602 includes a communication device 626, which may be a receiver, a transmitter, or a transceiver that operates according to one or more radio-frequency protocols, such as Bluetooth, Wi-Fi, a near-field communication standard, a cellular standard, or the like. The controller 621 may for example, communicate with a personal diabetes management device 605 and an analyte sensor 603 via the communication device 626.
The wearable automatic drug delivery device 602 may be attached to the body of a user, such as a patient or diabetic, at an attachment location and may deliver any therapeutic agent, including any drug or medicine, such as insulin or the like, to a user at or around the attachment location. A surface of the wearable automatic drug delivery device 602 may include an adhesive to facilitate attachment to the skin of a user as described in earlier examples.
The wearable automatic drug delivery device 602 may for example, include a reservoir 624 for storing the drug (such as insulin), a needle or cannula (not shown in this example) for delivering the drug into the body of the user (which may be done subcutaneously, intraperitoneally, or intravenously), and a drive mechanism 625 for transferring the drug from the reservoir 624 through a needle or cannula and into the user. The drive mechanism 625 may be fluidly coupled to reservoir 624, and communicatively coupled to the controller 621.
The wearable automatic drug delivery device 602 may further include a power source 628, such as a battery, a piezoelectric device, other forms of energy harvesting devices, or the like, for supplying electrical power to the drive mechanism 625 and/or other components (such as the controller 621, memory 623, and the communication device 626) of the wearable automatic drug delivery device 602.
In some examples, the wearable automatic drug delivery device 602 and/or the management device 605 may include a user interface 658, respectively, such as a keypad, a touchscreen display, levers, light-emitting diodes, buttons on a housing of the management device 605, a microphone, a camera, a speaker, a display, or the like, that is configured to allow a user to enter information and allow the management device 605 to output information for presentation to the user (e.g., alarm signals or the like). The user interface 658 may provide inputs, such as a voice input, a gesture (e.g., hand or facial) input to a camera, swipes to a touchscreen, or the like, to processor 651 which the programming code interprets.
When configured to communicate to an external device, such as the PDM 605 or the analyte sensor 604, the wearable automatic drug delivery device 602 may receive signals over the wired or wireless link 694 from the management device (PDM) 605 or 608 from the analyte sensor 604. The controller 621 of the wearable automatic drug delivery device 602 may receive and process the signals from the respective external devices as described with reference to the examples of
In an operational example, the processor 621 when executing the MDA 659 may output a control signal operable to actuate the drive mechanism 625 to deliver a carbohydrate-compensation dosage of insulin, a correction bolus, a revised basal dosage or the like as described with reference to the examples of
The smart accessory device 607 may be, for example, an Apple Watch®, other wearable smart device, including eyeglasses, provided by other manufacturers, a global positioning system-enabled wearable, a wearable fitness device, smart clothing, or the like. Similar to the management device 605, the smart accessory device 607 may also be configured to perform various functions including controlling the wearable automatic drug delivery device 602. For example, the smart accessory device 607 may include a communication device 674, a processor 671, a user interface 678 and a memory 673. The user interface 678 may be a graphical user interface presented on a touchscreen display of the smart accessory device 607. The memory 673 may store programming code to operate different functions of the smart accessory device 607 as well as an instance of the MDA 679. The processor 671 that may execute programming code, such as site MDA 679 for controlling the wearable automatic drug delivery device 602 to implement the
The analyte sensor 603 may include a controller 631, a memory 632, a sensing/measuring device 633, a user interface 637, a power source/energy harvesting circuitry 634, and a communication device 635. The analyte sensor 603 may be communicatively coupled to the processor 651 of the management device 605 or controller 621 of the wearable automatic drug delivery device 602. The memory 632 may be configured to store information and programming code, such as an instance of the MDA 636.
The analyte sensor 603 may be configured to detect multiple different analytes, such as lactate, ketones, uric acid, sodium, potassium, alcohol levels or the like, and output results of the detections, such as measurement values or the like. The analyte sensor 603 may in an example, be configured to measure a blood glucose value at a predetermined time interval, such as every 5 minutes, every cycle, or the like. The communication device 635 of analyte sensor 603 may have circuitry that operates as a transceiver for communicating the measured blood glucose values to the management device 605 over a wireless link 695 or with wearable automatic drug delivery device 602 over the wireless communication link 608. While called an analyte sensor 603, the sensing/measuring device 633 of the analyte sensor 603 may include one or more additional sensing elements, such as a glucose measurement element a heart rate monitor, a pressure sensor, or the like. The controller 631 may include discrete, specialized logic and/or components, an application-specific integrated circuit, a microcontroller or processor that executes software instructions, firmware, programming instructions stored in memory (such as memory 632), or any combination thereof.
Similar to the controller 621, the controller 631 of the analyte sensor 603 may be operable to perform many functions. For example, the controller 631 may be configured by the programming code stored in the memory 632 to manage the collection and analysis of data detected the sensing and measuring device 633.
Although the analyte sensor 603 is depicted in
The communication link 615 that couples the cloud-based services 611 to the respective devices 602, 603, 605 or 607 of system 600 may be a cellular link, a Wi-Fi link, a Bluetooth link, or a combination thereof. Services provided by cloud-based services 611 may include data storage that stores anonymized data, such as blood glucose measurement values, historical IOB or TDI, prior carbohydrate-compensation dosage, and other forms of data. In addition, the cloud-based services 611 may process the anonymized data from multiple users to provide generalized information related to TDI, insulin sensitivity, IOB and the like.
The wireless communication links 608, 691, 692, 693, 694 and 695 may be any type of wireless link operating using known wireless communication standards or proprietary standards. As an example, the wireless communication links 608, 691, 692, 693, 694 and 695 may provide communication links based on Bluetooth®, Zigbee®, Wi-Fi, a near-field communication standard, a cellular standard, or any other wireless protocol via the respective communication devices 654, 674, 626 and 635.
In some cases, a user may require more medicament than may be stored in a single drug delivery device 160; in others, it may be desirable to provide a device that can provide medicament for a longer period of time. In exemplary embodiments which may leverage the control algorithms described above, one or more supplemental devices may be used.
For example,
The feedback to the control algorithm comes from the analyte sensor located in the combined medicament delivery pump and analyte sensor 704 (or the standalone analyte sensor 708). If a meal bolus is required, the control system in the combined medicament delivery pump and analyte sensor 704 (or standalone basal device 706) can directly signal the standalone medicament pump 702 to deliver the bolus, thus preserving the insulin store of the combined medicament delivery pump and analyte sensor 704 (or standalone basal device 706) by reserving its medicament store for basal control.
The user interface control application for this system may be located on a smart mobile device (such as the controller 110) that is executing a custom software application (such as the drug delivery management application 140). The control application may be used to establish communication with the various system devices 702, 704, 706, 708.
User-specific insulin control settings may be sent to the combined medicament delivery pump and analyte sensor 704 (and/or standalone basal device 706) and/or standalone medicament pump 702 from the control application. The control application may then set up the combined medicament delivery pump and analyte sensor 704 (or standalone analyte sensor 708) after any required warm-up period, and send any required finger-stick calibrations to the system devices.
The control application is then available for the user to enter additional inputs to the system such as exercise, sleep and food intake. It is also available to view blood glucose values sourced from the analyte sensor and to enter any additional finger-stick calibrations to ensure the accuracy of the analyte sensor. Once these parameters are established the control application may not be required to maintain glucose control, as the control algorithm may be located on the combined medicament delivery pump and analyte sensor 704 (or standalone basal device 706) and may communicate directly with the standalone medicament pump 702 for bolus medicament delivery.
Due to the complexity of having multiple systems on the body controlling blood glucose levels, resource management features may be added to the control application, analyte sensor, pumps 702, 706 and/or the combination device 704 to simplify the user experience and reduce the risk of potentially hazardous conditions where the user runs low or out of a resource. For instance,
The interface may have a pictorial view of the user 802 as viewed from the front and/or back. The view 802 may show the currently active devices (a standalone medicament pump 804a, a standalone basal device 804b, and a standalone analyte sensor 804c, in this example) and their locations on the body (front and/or back). Orientation indicators (such as the words “left” and “right”) may be displayed on the pictorial view 802 in appropriate locations. When activating a new device or applying a device to the body, the user may identify, via a UI on the user's phone, for example, the location on the body where the device has been placed by the user, and the user's phone may store this information for display in a controller app on the user's phone.
Upon receiving input, such as a haptic tap from a user, on the individual devices in the pictorial view 802, the interface may be updated with a readout depicting a remaining medicament availability or lifespan of the selected device. For example, the readout may show an estimated time remaining of a medicament resource in the device's reservoir, a sensor lifespan of the analyte sensor, or a remaining lifespan of any of the devices if limited by some other resource such as power. The remaining life may be displayed in any suitable units, such as days remaining (e.g., readouts 806a, 806d, 806e) or medicament units remaining (e.g., readouts 806b, 806c).
The remaining life of the device may be displayed in color or with some other visual indicator of the remaining life. For example, the colors of the readout may change from green to yellow to red as the resources changes from 100% capacity (green) down to 50% (yellow) and 20% (red). Any other combination of colors and/or percentages that make the user properly aware of upcoming resource changes may be used.
In some embodiments, the interface may display a context-sensitive pop-up upon interaction with a user. For example, if the user selects the CGM 804c in the display, a pop-up window may appear that displays the user's glucose trend over time and/or time-in-range (i.e., the amount of time within a predetermined time period that the user has been within a predetermined target range of blood glucose values, which may be displayed as an amount of time, a percent, etc.). Upon selecting the device delivering basal doses (e.g., the delivery pump or standalone basal device 804b), a pop-up window may display a moving trend over a predetermined period of time communicating how the basal delivery amount increases and/or decreases. Upon selecting the bolus pump, a pop-up window may display the amounts of bolus doses delivered over a predetermined period of time and when those doses were delivered.
In addition, upon receiving the input selecting a particular device, the controller 110 may transmit a control signal to the associated device to trigger a feedback response from the device itself. This feedback may allow the user to confirm which device is which, which may be useful when removing a depleted resource or for troubleshooting. The feedback may be in the form of any suitable perceptible signal, such as (but not limited to) physical vibration, an audible alarm, visual light, or a combination of perceptible signals.
Furthermore, the display may depict problems or errors with particular devices. For example, if the bolus pumps shows signs of an impending occlusion, the corresponding interface element might flash yellow or red, or could pop-up an indicator such as “!”.
In this view on the user's device (e.g., the user's smartphone), the user can see each device that has been applied to the user's body, whether that device is a blood glucose monitor (e.g., a CGM), a basal pump, a bolus pump, a combined pump/analyte sensor, a ketone sensor or other type of analyte sensor, etc. The user may click or tap on an individual device and pull up options with respect to that device. Options may include activating a device, assigning a function for the device (e.g., assigning a device to deliver bolus medicament and/or basal medicament), assigning a start-up time for a pump device (e.g., when that device should start delivering bolus and/or basal medicament), calculating and/or delivering a bolus from that device, entering an automatic or a manual mode, establishing a basal profile that will deliver basal medicament at particular rates set by the user at different periods throughout the day, changing a basal delivery rate for a particular time period of the day (e.g., 12 am-7 am) or for a temporary period (e.g., 2 hours), obtaining an analyte value (e.g., a blood glucose value) from that device, obtaining delivery and/or analyte history of a device since its activation, deactivating a device (e.g., upon the device expiring or running out of a resource such as a medicament), etc.
Processing begins at block 902. Block 902 may commence (and run repeatedly) while the controller 110 is interfaced with the combined medicament delivery pump and analyte sensor 704, the standalone medicament pump 702, the basal device 706, and/or the standalone analyte sensor 708. The controller may be provided on a control device such as a smart phone or dedicated remote controller, or may be deployed on the combined medicament delivery pump and analyte sensor 704 (or the standalone analyte sensor 708)
At block 904, the controller 110 and/or standalone medicament pump 702 may detect an empty or near-empty condition (e.g., less than a predetermined threshold amount of medicament remaining) in the standalone medicament pump 702, for example. Upon detecting the empty or near-empty condition, a control signal may be transmitted to the controller 110 in block 906. The control signal may be configured to initiate a procedure at the controller 110 for removing the empty or near-empty standalone medicament pump 702, for example, from the system.
At block 908, the controller 110 may receive the control signal and may present a notification on the user interface 182 informing the user that the standalone medicament pump 702, for example, is empty or nearly empty. The notification may prompt the user to remove the standalone medicament pump 702, for example.
Optionally, when the notification is presented, the standalone medicament pump 702, for example, may be caused to vibrate, flash a status light, or present some other perceptible signal indicating to the user the identity and/or location of the standalone medicament pump 702, for example. To this end, the controller 110 may transmit a control signal to the standalone medicament pump 702, for example, configured to cause the standalone medicament pump 702 to present the perceptible signal. In this way, the user is informed of the correct device that should be removed (and the perceptible signal may serve as an alert to the user that they should check the status of the system on the controller 110). The user interface 182 may present an option for the user to cause the standalone medicament pump 702, for example, to present the perceptible signal again, so that the user can identify the standalone medicament pump 702 at a later time if they cannot immediately remove it. If this option is selected, the controller 110 may transmit another control signal to the standalone medicament pump 702 configured to cause the standalone medicament pump 702 to present the perceptible signal again.
After the user removes the old standalone medicament pump 702 (in this example), the controller 110 may unpair the old standalone medicament pump 702 from the system. At block 910, the controller 110 may transmit a control signal to the remaining medicament pump (either the combined medicament delivery pump and analyte sensor 704, or the basal device 706, depending on the system configuration), which had previously served to deliver only basal doses of the medicament to the user. The control signal may cause the remaining medicament pump to enter a different mode in which the remaining medicament pump is configured to deliver both basal and bolus doses. Alternatively, the user may tap on the pump device, as shown in and described with respect to
Alternatively, at block 912 a replacement bolus-only pump may be added to the system. The user may attach a new standalone medicament pump 702, which may be paired and provisioned with the system. The standalone medicament pump 702 may be calibrated or configured using the patient information 132, analyte sensor information 134, and/or drug delivery information 136 from the controller 110 as described above (which may include receiving a present analyte measurement value from the analyte sensor during an initialization of the standalone medicament pump 702, receiving at least one backfill value measured by the analyte sensor prior to the initialization, and calculating a dosage, such as a bolus dosage, of the medicament using the present analyte measurement value and the at least one backfill value). Other initialization and calibration techniques discussed in this application may also be applied during this provisioning process.
At block 914 the controller 110 may transmit a control signal to the above-mentioned remaining medicament pump, which may cause the remaining medicament pump to transition back into a configuration in which it delivers only basal doses. The remaining medicament pump may maintain a local control algorithm that controls delivery of the basal and/or the bolus doses. The remaining medicament pump may take over the delivery of the basal doses and may establish communication with the new standalone medicament pump 702. The remaining medicament pump may communicate directly with the standalone medicament pump 702 to control delivery of the bolus doses on the standalone medicament pump according to the remaining medicament pump's local control algorithm.
Alternatively, the controller 110 may transmit a control signal to the standalone medicament pump 702 indicating that the standalone medicament pump 702 may begin delivering bolus doses of the medicament under control of a local control algorithm located at the standalone medicament pump 702.
Processing may then proceed to block 916 and terminate.
Software related implementations of the techniques described herein, such as the processes examples described with reference to
In addition, or alternatively, while the examples may have been described with reference to a closed loop algorithmic implementation, variations of the disclosed examples may be implemented to enable open loop use. The open loop implementations allow for use of different modalities of delivery of insulin such as smart pen, syringe or the like. For example, the disclosed AP application and algorithms may be operable to perform various functions related to open loop operations, such as the generation of prompts requesting the input of information such as weight or age. Similarly, a dosage amount of insulin may be received by the AP application or algorithm from a user via a user interface. Other open-loop actions may also be implemented by adjusting user settings or the like in an AP application or algorithm.
Some examples of the disclosed device or processes may be implemented, for example, using a storage medium, a computer-readable medium, or an article of manufacture which may store an instruction or a set of instructions that, if executed by a machine (i.e., processor or controller), may cause the machine to perform a method and/or operation in accordance with examples of the disclosure. Such a machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, or the like, and may be implemented using any suitable combination of hardware and/or software. The computer-readable medium or article may include, for example, any suitable type of memory unit, memory, memory article, memory medium, storage device, storage article, storage medium and/or storage unit, for example, memory (including non-transitory memory), removable or non-removable media, erasable or non-erasable media, writeable or re-writeable media, digital or analog media, hard disk, floppy disk, Compact Disk Read Only Memory (CD-ROM), Compact Disk Recordable (CD-R), Compact Disk Rewriteable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory cards or disks, various types of Digital Versatile Disk (DVD), a tape, a cassette, or the like. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, programming code, and the like, implemented using any suitable high-level, low-level, object-oriented, visual, compiled and/or interpreted programming language. The non-transitory computer readable medium embodied programming code may cause a processor when executing the programming code to perform functions, such as those described herein.
Certain examples of the present disclosure were described above. It is, however, expressly noted that the present disclosure is not limited to those examples, but rather the intention is that additions and modifications to what was expressly described herein are also included within the scope of the disclosed examples. Moreover, it is to be understood that the features of the various examples described herein were not mutually exclusive and may exist in various combinations and permutations, even if such combinations or permutations were not made express herein, without departing from the spirit and scope of the disclosed examples. In fact, variations, modifications, and other implementations of what was described herein will occur to those of ordinary skill in the art without departing from the spirit and the scope of the disclosed examples. As such, the disclosed examples are not to be defined only by the preceding illustrative description.
Program aspects of the technology may be thought of as “products” or “articles of manufacture” typically in the form of executable code and/or associated data that is carried on or embodied in a type of non-transitory, machine readable medium. Storage type media include any or all of the tangible memory of the computers, processors or the like, or associated modules thereof, such as various semiconductor memories, tape drives, disk drives and the like, which may provide non-transitory storage at any time for the software programming. It is emphasized that the Abstract of the Disclosure is provided to allow a reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, various features are grouped together in a single example for streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed examples require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed example. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate example. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein,” respectively. Moreover, the terms “first,” “second,” “third,” and so forth, are used merely as labels and are not intended to impose numerical requirements on their objects.
The foregoing description of examples has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the present disclosure to the precise forms disclosed. Many modifications and variations are possible in light of this disclosure. It is intended that the scope of the present disclosure be limited not by this detailed description, but rather by the claims appended hereto. Future filed applications claiming priority to this application may claim the disclosed subject matter in a different manner and may generally include any set of one or more limitations as variously disclosed or otherwise demonstrated herein.
This application is a Continuation-in-Part of U.S. patent application Ser. No. 17/730,839, filed Apr. 27, 2022, which claims the benefit of U.S. Provisional Patent Application No. 63/180,777, filed Apr. 28, 2021. The contents of the aforementioned applications are incorporated herein by reference in their entirety.
| Number | Date | Country | |
|---|---|---|---|
| 63180777 | Apr 2021 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 17730839 | Apr 2022 | US |
| Child | 18629118 | US |
