EVENT DETECTION FOR DRUG DELIVERY SYSTEM

Abstract

A drug delivery device may include an Inertial Measurement Unit (IMU) is provided. The IMU may include an accelerometer, a magnetometer, or a gyroscope. Motion parameters may be detected when the drug delivery device is shipped, being prepared for activation for use, or during use. The IMU may provide data indicative of a rapid deceleration, such as when a package containing the drug delivery device is dropped, or some other physical event experienced by the drug delivery device. The drug delivery device may also include internal or external pressure sensors or a blood glucose sensor that may coordinate with the IMU to provide additional feedback regarding the status of the device or user. A controller of the drug delivery device may generate a response depending on the particular parameters being monitored or may change device operational parameters as a result of detected system events.

Description

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. application Ser. No. 16/599,729, filed on Oct. 11, 2019, which claims priority to U.S. Provisional Application No. 62/744,229, filed on Oct. 11, 2018, the entire contents of which are incorporated herein by reference.

TECHNICAL FIELD

The examples generally relate to medication delivery. More particularly, examples relate to managing operation of a wearable drug delivery device based on detected system events.

BACKGROUND

Many conventional drug delivery devices fail to include sensors that may determine an operational status of the drug delivery device or status of the user of the drug delivery device. As a result, these conventional drug delivery devices typically place burdensome requirements on the users to assess and confirm proper operation of the devices or a status of the user. Users often find these requirements inconvenient and time-consuming.

Accordingly, there is a need for a drug delivery device that includes sensors for accurately determining the operational status of the device and health status of the user to obviate the need to place burdensome requirements on the user to do so directly.

SUMMARY

A method is disclosed that includes detecting motion of a needle deployment component. The detected motion of the needle deployment component may be compared to a number of movement profiles. An operational mode of the needle deployment component may be determined based on the comparison. A notification indicating the determined operational mode of the needle deployment component may be generated. An input may be received in response to the generated notification. The needle deployment component may be activated based on the received input.

An apparatus is disclosed that includes a storage device, a user interface, a needle deployment component, and a processor. The storage device operable to store a number of movement profiles, the movement profiles storing motion parameters value indicative of motion of a needle deployment component. The processor, at least a portion of which is implemented in circuitry coupled to the storage device and the user interface. The processor operable to perform functions. The functions include detecting motion of the needle deployment component. The processor is operable to compare the detected motion of the needle deployment component to each movement profile of the plurality of movement profiles and determine an operational mode of the needle deployment component based on the comparison. A notification is generated indicating the determined operational mode of the needle deployment component and the generated notification is presented on the user interface. Operational parameters are adjusted based on the determined operational mode of the needle deployment component.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example of an inertial measurement unit (IMU).

FIG. 2 illustrates an example of a drug delivery device incorporating the example IMU of FIG. 1.

FIG. 3 illustrates an example of process that evaluates motion parameters monitored by the IMU example of FIG. 1.

FIG. 4 illustrates an example of a process for determining an operational state of a drug delivery device.

FIG. 5 illustrates an example of another process that determines another operational state of a drug delivery device, such as that illustrated in the example of FIG. 2.

DETAILED DESCRIPTION

This disclosure presents various systems, components, and methods for detecting events experienced by a drug delivery device worn by a user or events experienced by the user and responding to the detected system events. Each of the systems, components, and methods disclosed herein provides one or more advantages over conventional systems, components, and methods.

An example include a body worn drug delivery device that includes an Inertial Measurement Unit (IMU). The IMU may include the capabilities of an accelerometer, a magnetometer, and/or a gyroscope for detecting various parameters indicative of the working status of the drug delivery device and/or a user wearing the device. The drug delivery device may also include internal or external pressure sensors or a blood glucose sensor that may coordinate with the IMU to provide additional feedback regarding the status of the device or user. The drug delivery device may also include a total insulin delivery sensor that may coordinate with other sensors on the device to provide additional feedback on the operational state of the drug delivery device. The drug device may send a variety of alerts to the user and/or a caregiver depending on the particular parameters being monitored or may change device operational parameters as a result of detected system events. Other examples are disclosed and described.

FIG. 1 illustrates an example of an inertial measurement unit (IMU) 102. The IMU 102 may include an accelerometer 104, a magnetometer 106, output connections 107 and a gyroscope 108. The IMU 102 may combine the features and capabilities of the accelerometer 104, the magnetometer 106, and the gyroscope 108 for detecting various operational parameters of a device in which the IMU 102 is integrated. In an example, the IMU 102 may be integrated into a drug delivery device such as, for example, a wearable or on-body drug delivery device. Each of the accelerometer 104, the magnetometer 106, and the gyroscope 108 may be coupled to the output connections 107. The output connections 107 may include connections to a controller (shown in another example) or processor for evaluation and additional manipulation or processing as described with reference to other examples.

The accelerometer 104 may generate one or more signals indicative of, for example, a detected or measured acceleration force. The magnetometer 106 may generate one or more signals indicative of, for example, a detected or measured magnetic field. The gyroscope 108 may generate one or more signals indicative of, for example, an orientation of the gyroscope 108, the IMU 102, or a device in which either component is integrated. The signals generated by the accelerometer 104, the magnetometer 106, and the gyroscope 108 may be provided to other components and devices (e.g., a controller or processor) and/or may be stored (e.g., within a non-transitory computer readable memory). In an example, the IMU 102 may detect a motion, a movement, or a position of a device in which it is incorporated (or of a user wearing the device in which the IMU is integrated).

FIG. 2 illustrates an example of a drug delivery system that includes an example of a drug delivery device 202. The drug delivery system 200 may include the drug delivery device 202, a remote device 218 and a blood glucose sensor 216.

The drug delivery device 202 may be a wearable or on-body drug delivery device that is worn by a patient or user on the body of the user. As shown in FIG. 2, the drug delivery device 202 may include the IMU 102, a user interface 227, a pressure sensor 214, an extraction mechanism 206, a memory 223, a heart rate monitor 237, a controller 210, reservoir 204, needle deployment 208, communication device 226. The IMU 102 may be operable to detect of various parameters that may be indicative of the working status (e.g., operational status) of the drug delivery device 202 and/or the health status user of the drug delivery device 202. In an example, the health status of the user of the drug delivery device 202 may include a status of any physical condition of the user including, for example, a motion or position of the user.

In an example, the drug delivery device 202 may also include, or may be coupled to, a number of different sensors (e.g., internal and/or external pressure sensors) that may coordinate with the IMU 102 to provide additional feedback regarding the status of the drug delivery device 202 or the user and/or any events experienced by the drug delivery device 202 or the user (e.g., system events). In an example, the drug delivery device 202 may coordinate with the IMU 102 to send a variety of alerts to the user and/or a caregiver of the user based on any monitored parameter or characteristic of the drug delivery device 202 or detected characteristic of the user (e.g., heart rate or unaffected blood glucose measurement value). In an example, the drug delivery device 202 may coordinate with the IMU 102 to change operational parameters of the drug delivery device 202 based on any monitored parameter or characteristic of the drug delivery device 202 or the user.

The drug delivery device 202 may, for example, also include a heart rate monitor 237 that monitors the user heart rate. The monitored heart rate may be provided to the controller 210, which may use the provided heart rate in the determination of insulin doses or the like.

The wearable drug delivery device 202 may also include a user interface 227. The user interface 227 may include any mechanism for the user to input data to the drug delivery device 202, such as, for example, a button, a knob, a switch, a touch-screen display, or any other user interaction component. The user interface 227 may include any mechanism for the drug delivery device 202 to relay data to the user and may include, for example, a display, a touch-screen display, or any means for providing a visual, audible, or tactile (e.g., vibrational) output (e.g., as an alert). The user interface 227 may also include a number of additional components not specifically shown in FIG. 2 for sake brevity and explanation. For example, the user interface 227 may include a one or more user input or output components for receiving inputs from or providing outputs to a user or a caregiver (e.g., a parent or nurse), a display that outputs a visible alert, a speaker that outputs an audible, or a vibration device that outputs tactile indicators to alert a user or a caregiver of an operational status, a form of notification, or the like.

As shown in FIG. 2, the drug delivery device 202 may include a reservoir 204 configured to store or hold a liquid or fluid. The stored liquid may be any type of drug or therapeutic agent, such as insulin or morphine. In an example, the drug delivery device 202 may be an insulin delivery device and the reservoir 204 may be configured to store insulin. The drug delivery device 202 may further include a drug extraction mechanism or component 206 and a needle deployment mechanism or component 208. The extraction mechanism 206 may extract the liquid drug stored in the reservoir 204. In an example, the extraction mechanism 206 may include a pump or a plunger (not shown).

The needle deployment component 208 may include a needle (not shown) and any other fluid path components, such as a cannula (not shown), for coupling the reservoir 204 containing the stored liquid drug to the user. In an example, the needle deployment component 208 may include a needle (not shown) and a cannula (not shown). The needle may provide initial access to the user (e.g., by piercing a layer of the user's skin) and may then be retracted leaving the cannula coupled to the user. The needle deployment component 208 may include a drive mechanism (not shown) for mechanically driving the needle and the cannula forward toward a user to pierce the skin of the user and to then mechanically retract the needle, leaving the cannula coupled to the user. With the cannula coupled to the user, a fluid path is provided via tubing coupled to the cannula and the reservoir 204.

In an example, the cannula may form a portion of a fluid path component coupling the reservoir 204 to the user. The needle deployment component 208 may be activated to deploy and retract the needle (and cannula) in response to a user input or instruction (e.g., after the drug delivery device 202 is attached or coupled to the user). In an example, the drug delivery device 202 may receive an input, for example, via the communications interface 212, that activates the needle deployment component 208. The needle deployment component is configured, in response to being activated, to provide a fluid path by driving a needle and a cannula (not shown) into the skin of a user and to retract the needle leaving the cannula coupled to the user. After the needle deployment component 208 the fluid path to the user is provided, the extraction mechanism 206 may be operable to expel the stored liquid drug (not shown) from the reservoir 204 to provide the liquid drug to the user via the fluid path. The fluid path may include tubing (not shown) coupling the drug delivery device 202 to the user (e.g., tubing coupling the cannula to the reservoir 204).

The drug delivery device 202 may further include a controller 210 and a communications interface 212. The controller 210 may be implemented in hardware, software, or any combination thereof. The controller 210 may be a processor. The controller 210 may direct operation of the drug delivery device 202. The controller 210 may receive data or information indicative of the operational status of the drug delivery device 202 and/or the status of the user from the IMU 102, as well as from any other sensor of the drug delivery device 202 or sensor coupled thereto.

The controller 210 may process the data from the IMU 102 or any sensor to determine if an alert or other communication is to be issued to the user and/or a caregiver of the user. The controller 210 may process the data from the IMU 102 or any other coupled sensor to determine if an alert or other communication is to be issued to the user and/or a caregiver of the user or if an operational mode of the drug delivery device 202 is to be adjusted. The controller 210 may provide the alert, for example, through the communications interface 212. The communications interface 226 may provide a communications link to one or more management devices physically separated from the drug delivery device 202 including, for example, a remote device 218 of the user and/or a caregiver of the user (e.g., a parent). The controller 210 may provide the alert through the communications interface 212. The communications interface 212 may be operable to provide a communications link to one or more remote devices physically separated from the drug delivery device 202 including, for example, a remote device 218 of the user and/or the caregiver. The communication links (shown as lightning bolts) provided by the communications interface 212 may include any wired or wireless communication link operating according to any known communications protocol or standard, such as Bluetooth®, LTE, 802.11x family, or the like.

In an example, the drug delivery device 202 may include a pressure sensor 214. The pressure sensor 214 may be coupled to the reservoir 204, the extraction mechanism 206, the needle deployment component 208, and/or any portion of the fluid path coupling the reservoir 204 to the user. The pressure sensor 214 may detect pressure and/or pressure changes within of the aforementioned components and/or the fluid path and/or may detect any drive resistance in providing the stored liquid drug to the user. The data and information related to the detected pressure and/or pressure changes provided by the pressure sensor 214 may be used separately or in combination with other data from other sensors by the controller 210 to determine an occlusion in the fluid path, an absorption issue, an insertion site issue, or the like. The controller 210 may use the pressure sensor 214 data or information separately or in combination with other data or information from other sensors, such as the IMU 102 or blood glucose sensor 216, or other devices, such as the remote device 218.

For reference, FIG. 2 further shows the drug delivery device 202 in relation to a glucose monitor 216 such as, for example, a continuous glucose monitor (CGM). The CGM 216 may be physically separate from the drug delivery device 202 or may be an integrated component thereof. The CGM 216 may provide the controller 210 with data indicative of measured or detected blood glucose (BG) levels of the user. The blood glucose sensor 216 or CGM 216 may include a processor 241, a memory 243, a sensing or measuring device 244, and a communication device 246. For example, the processor 241 may be operable to provide blood glucose measurements obtained from the sensing or measuring device 244 to the drug delivery device 202 via the communication device 246. The communication device 246 may exchange signals with the communication interface 212 of the drug delivery device 202 via wired communication link 277 or wireless communication link 287.

FIG. 2 further shows an example of a remote device 218. The remote device 218 may be maintained and operated by the user or the caregiver. The remote device 218 may contain analog and/or digital circuitry that may be implemented as a processor 261 (or controller) for executing processes to manage a user's blood glucose levels and for controlling the delivery of the drug or therapeutic agent to the user. The processor 261 may also be operable to execute programming code stored in the memory 263. For example, the memory 263 may be operable to store an artificial pancreas application (not shown) that may be executed by the processor 261. The communication device 264 may be a receiver, a transmitter, or a transceiver that operates according to one or more radio-frequency protocols. For example, the communication device 264 may include a cellular transceiver and a Bluetooth transceiver that enables the management device 206 to communicate with a data network via the cellular transceiver and with the sensor 204 and the wearable drug delivery device 202. The remote device 218 may control operation of the drug delivery device 202 and/or may be used to review data or other information indicative of an operational status of the drug delivery device 202 or a status of the user via, for example, a user interface 268. The remote device 218 may be used to direct operations of the drug delivery device 202. The remote device 218 may receive alerts, notifications, or other communications from the drug delivery device 202 over any known wired or wireless communications standard or protocol communication links, such as wired communication link 278 or wireless communication link 288. In an example, the remote device 218 may be a dedicated diabetes management controller or may be a smartphone or other consumer electronic device including, for example, a desktop, laptop, or tablet. The remote device 218 may communicate with the blood glucose sensor 216 via communication links, such as wired communication link 278 or wireless communication link 288.

The drug delivery device 202 may include a number of additional components not specifically shown in FIG. 2 for simplicity including, for example, a user input interaction component (e.g., one or more user input features for receiving input from the user or the caregiver), a user output interaction component (e.g., a display or one or more visible, audible, or tactile indicators for providing an output to the user or the caregiver), a power supply (e.g., a battery), and a storage device (e.g., a memory device for storing data or executable instructions implemented by a processor).

In an example, the IMU 102 may measure acceleration, measure changes in velocity, and/or measure changes in a position of the drug delivery device 102 that may be indicative of the drug delivery device 202 being damaged (e.g., dropped or hit) or its connection with the user being compromised, prior to use or during use. In an example, the IMU 102 may monitor and measure these parameters and may provide them to the controller 210. The controller 210 may compare the received data to one or more predetermined thresholds that indicate likely damage to the drug delivery device 202. In another example, the IMU 102 may detect and measure the parameters, may compare the detected data to the one or more predetermined thresholds that indicate likely damage to the drug delivery device 202, and may output an indication to the controller 210 whether one or more of the predetermined thresholds has been exceeded by the detected data.

For example, when data relating to acceleration, velocity, and/or position of the drug delivery device 202 exceeds one or more of the damage thresholds (e.g., a velocity change threshold or an acceleration change threshold, such as an acceleration at or greater than gravity of 9.8 mg/dL followed by a sudden negative acceleration indicating a drop of the pod), the controller 210 may determine that damage to one or more components of the drug delivery device 202 has occurred or has likely occurred. In response to the determination that damage has occurred or may have likely occurred, the controller 210 may provide one or more alerts to the user or the caregiver indicating that the needle deployment component 208 or another component of the drug delivery device 202 may be damaged and/or may not operate properly. In an example, the alert may be provided to a device operated by the user or a caregiver, such as, for example, the remote device 218. In an example, the alert may indicate that the drug delivery device 202 should be discarded and/or replaced.

FIG. 3 illustrates an example of a process 300 for determining that a fault or damage has occurred to a drug delivery device. The illustrated example of the process 300 is described with reference to the system of FIG. 2. In the example of FIG. 3, the process 300 enables the determination that a fault in drug delivery device 202 and/or damage of the drug delivery device 202 has occurred based on parameters monitored by the IMU 102. The occurrence of a fault or damage to the drug delivery device 202 may be determined prior to the drug delivery device 202 being in an activated operational state (i.e., unpackaged and positioned for delivery of a drug to the user) or in a pre-activated operational ready state (i.e., not unpackaged or, if unpackaged, not yet positioned for delivery of a drug to the user, such as either the pod/device is on the body but the needle is not yet injected, or having the pod opened and filled but not yet put on the body).

At 302, one or more parameters that may indicate possible damage to the drug delivery device 202 may be monitored by the IMU 102. The parameters may include an acceleration of or a change in acceleration of the drug delivery device 202, a particular velocity or a change in velocity (derived from data provided by or as provided by the accelerometer 104) of the drug delivery device 202, and/or a position or a change in a position (derived from data provided by or as provided by the gyroscope 108) of the drug delivery device 202, or a change in a magnetic field (derived from data provided by or as provided by the magnetometer 106), or a combination of data or information provided by 104, 106 or 108. The parameters may be detected and/or measured by the IMU 102. The parameters may be monitored by the IMU 102 when the drug delivery device 202 is in the activated state of operation (i.e., unpackaged and positioned for delivery a drug to the user) or the pre-activated state of operation (i.e., not unpackaged or, if unpackages, not yet positioned for delivery of a drug to the user). In an example of determining whether damage has occurred prior to use of the drug delivery device 202, the IMU 102 and/or the controller 221 may be minimally powered so the IMU 102 may obtain and provide movement data to the controller 221 and the controller 221 can store the movement data and/or process the movement data. For example, with reference to FIG. 2, the IMU 102 and a controller 210 of the drug delivery device 202 may be supplied with power from a power supply (not shown) while in a pre-activated mode (e.g., prior to activation of the needle deployment component while in the packaging (during shipping, for example, or before first use)) enabling the accelerometer 104, magnetometer 106, and/or gyroscope 108 of the IMU 102 to provide signals representative of detected parameters related to motion to the controller 210, which the controller 210 is operable to evaluate the detected motion parameters to detect motion of the needle deployment component 208. Alternatively, the IMU 102 may be operable to evaluate the detected motion parameters to detect motion of the needle deployment component 208 after activation of the needle deployment component 208. For example, the IMU 102 components, such as the accelerometer 104, magnetometer 106 and the gyroscope 108, may include memory components and logic circuitry or a processor (not shown) that is operable to execute code to perform calculations and other functions, such as evaluating detected motion parameters with respect to motion thresholds stored in the memory component.

In an example, when the IMU 102 or controller 210 detects motion, the motion may be determined in one or more directions of movement of the needle deployment component 208 relative to three orthogonal reference axes (e.g., X, Y and Z). In addition, the IMU 102 and/or the controller is operable, when detecting motion of the needle deployment component 208, to determine an amount of movement for each of the determined one or more directions of movement. Alternatively, or in addition, when the IMU 102 detects motion and the respective detected motion parameters are provided to the controller 210, the IMU 102 or controller 210 may determine a timing of the detected motion in each of the determined one or more directions of movement, a duration of the detected motion in each of the determined one or more directions of movement, a sequence of the detected motion in each of the one or more directions of movement, or the like.

At 304, the controller 210 or the IMU 102 may be operable to evaluate the detected parameters by, for example, comparing the detected motion-related parameters to predetermined movement parameter thresholds stored in a memory (not shown) coupled to the controller 210. The comparison of detected motion-related parameters (e.g., types of motion that have certain characteristics) of the drug delivery device 202 to the predetermined movement parameter thresholds may be performed by the IMU 102 and/or the controller 210. In an example, the thresholds may be predetermined or pre-set based on an operational status of the drug delivery device 202 and may indicate—for example, when exceeded—that the drug delivery device 202 is damaged, likely damaged, or is likely to not operate properly based on a detected or measured parameter relating to acceleration, velocity, and/or position of the drug delivery device 202 (or any change thereof) that, for example, meets or exceeds one or more of the predetermined thresholds.

For example, the controller 210 or the IMU 102 may be further operable to compare the detected motion of the needle deployment component to a first operational mode profile or movement thresholds to determine an operational mode of the needle deployment component 208. For example, the controller 210 or the IMU 102 may determine that the needle deployment component 208 is operating under a first operational mode. The first operational mode may correspond to an operational state of the needle deployment component 208 in which the needle deployment component 208 is operating properly. Alternatively, or in addition, the controller 210 or the IMU 102 may, for example, be operable to determine that the needle deployment component 208 is operating under a second operational mode that corresponds to an erroneous operational state of the needle deployment component 208.

As an alternative to predetermined thresholds for the motion-related parameters or certain characteristics of types of detected motion, the memory coupled to the controller 210 may be operable to store a number of movement profiles related to different faults or damage to drug delivery device 202 as well as specific components, such as the needle extraction module 208, the needle extraction mechanism 206, the reservoir 204, and the like.

In addition, or alternatively, the controller 210 or the IMU 102 may be operable to compare the motion-related parameters or certain characteristics of types of detected motion of the needle deployment component to an early deployment profile. The early deployment profile may be one of the number of movement profiles stored in the memory. The early deployment profile may include acceleration, velocity and position parameters relating to movement of the needle deployment component prior to attachment of a drug delivery device containing the needle deployment component to a user.

In addition, or alternatively, the controller 210 or the IMU 102 may be operable to compare the detected motion of the needle deployment component to a partial deployment profile, which may be one of the number of movement profiles stored in the memory of the drug delivery device 202. The partial deployment profile may include acceleration, velocity and position parameters relating to movement of the needle deployment component when a needle has not retracted after being inserted into a user.

In addition, or alternatively, the controller 210 or the IMU 102 may be operable to compare the detected motion of the needle deployment component to a partial deployment profile, which may be one of the number of movement profiles stored in the memory of the drug delivery device 202. The partial deployment profile may include acceleration, velocity and position parameters relating to movement of the needle deployment component when a needle has not retracted after being inserted into a user.

In addition, or alternatively, the controller 210 or the IMU 102 may be operable to compare the detected motion of the needle deployment component to a non-deployment profile, which may be one of the number of movement profiles stored in the memory of the drug delivery device 202. The non-deployment profile may include acceleration, velocity and position parameters relating to movement of the needle deployment component when not activating in response to an attempted activation of the needle deployment component.

In addition, or alternatively, the controller 210 or the IMU 102 may be operable to compare the detected motion of the needle deployment component to a full deployment profile, which may be one of the number of movement profiles stored in the memory of the drug delivery device 202. The full deployment profile may include acceleration, velocity and position parameters relating to movement of the needle deployment component when driving a needle and a cannula into the user and then retracting the needle leaving the cannula coupled to the user.

At 306, after determining that one or more detected parameters exceed one or more corresponding predetermined thresholds, as set out in the respective profiles, indicative of damage or improper operation (or a high likelihood thereof), the controller 210 or the IMU 102 may take remedial action. For example, the controller 210 or the IMU 102 may be operable to generate a notification or an alert. An alert may be provided to the user and/or the caregiver through the communications interface 212 and may be provided to a remote device 218 of the user and/or the caregiver. The alert may also include providing a visual, audible, and/or tactile indication through a speaker, vibration device light-emitting diode, or the like (not shown) coupled to the controller 210 of the drug delivery device 202. For example, the alert may indicate the determination that the drug delivery device 202 has likely been damaged and/or may not operate properly, for example, due to being dropped, being hit, slept on, or the like. In an example, the alert may indicate or suggest that the drug delivery device 202 should not be used and/or should be replaced. Alternatively, or in addition, a notification may be generated and output by drug delivery device 202 indicating the determination that the drug delivery device 202 has likely been damaged and/or may not operate properly, for example, due to being dropped, being hit, slept on, or the like. The notification may be transmitted wirelessly to the remote device 218 to be presented to a user or caregiver. The notification may be intended to be presented on the remote device 218 via at least one of a visual, an audible, or a tactile notification.

At 308, the controller 210 may restrict operation of the drug delivery device 202. For example, the controller 210 after issuing an alert or providing a notification for presentation to a user, may, at 308, deactivate or restrict an activated drug delivery device 202 based on a response received via an input device, or due to a lack of a response from an input device. For example, the received input may indicate that the drug delivery device 202 is going to be disposed of within a short time frame (e.g., 1 hour or the like). In response to the received input, the controller 221 may enter a restricted operational mode in which it does not provide any control commands to the extraction mechanism 206 or prevent the system from recommending any changes in the current system settings. In another example, it may have been determined that the drug delivery device 202 was damaged prior to activation. In such a situation, the alert generated by the controller 212 at 306 may have indicated the damaged drug delivery device, and the controller 212 may enter the restricted operational mode and no longer provide control commands to the extraction mechanism 206, the needle deployment component 208, or both.

In an example, the drug delivery device 202 may include a heart rate monitor and/or a skin temperature monitor as part of the IMU 102, controller 210 or another component within the drug delivery device 202 that may be used to confirm (or separately determine) that the drug delivery device 202 or the user has experienced an event the severity of which rendered the needle deployment component 208 inoperable. In an example, data from the heart rate monitor and/or the skin temperature monitor may be used to confirm that the needle deployment component 208 is inoperable and a need to issue an alert to that effect at 306. In this example, if the heart rate monitor and/or the skin temperature monitor indicates values that are out of standard norms of the human body, it may indicate that the needle is actually not deployed in the human tissue.

For some drug delivery devices, no mechanism or component is provided that may determine when the needle of the conventional drug delivery device is deployed—or if the needle or cannula properly deployed and provides a fluid path to the user. As a result, these types of drug delivery devices typically send a message to the user and/or the caregiver approximately 90 minutes after activation requesting that the user and/or the caregiver confirm that this type of drug delivery device is operating properly. For example, a conventional drug delivery device may request the user to confirm that that user's BG levels are within an acceptable range approximately 90 minutes after the conventional drug delivery device is activated. Many users find this request message annoying and inconvenient. Further, using BG levels to confirm proper deployment of the needle may be limited for confirming proper operation of a needle insertion/deployment mechanism as BG levels may be within an acceptable range for any number of reasons even when a needle/cannula did not deploy properly.

The drug delivery device 202 and the IMU 102 described herein provide a more accurate and reliable manner for detecting and confirming proper operation of the drug delivery device 202 including proper deployment of a needle/cannula using the needle deployment component 208. When activated to deploy a needle and a cannula and to then retract only the needle, the needle deployment component 208 may move in a number of directions and may cause the drug delivery device 202 to also move in a number of directions. The IMU 102 may detect and measure the movement of the needle deployment component 208 as well as the drug delivery device 202 and/or any other component thereof. The measured or detected movement may be in any direction (e.g., along each of three orthogonal reference axes commonly referred to as the x, y, and z directions for describing movement in three-dimensions). The movement may be detected according to direction, an amount or amplitude of the movement, a sequence of the movement, when the movement occurs, and the duration of the movement in any direction.

This detected movement may then be compared to one or more stored profiles associated with different activations of the needle deployment component 208. Each profile may vary in terms of the movement, amount of movement, sequence of movement, timing, and duration. By comparing the detected movements of the needle deployment component 208 (and/or any other component of the drug delivery device 202) to the one or more predetermined profiles, a determination may be made if the needle deployment component 208 activated properly and without error or if one or more errors occurred.

In an example, multiple different movement or accelerometer profiles associated with operation of the needle deployment component 208 (e.g., various operational scenarios) may be known and/or stored in a memory for comparison including, for example: (1) an early deployment profile—the IMU 102 may detect movement of the needle deployment component 208 prior to the drug delivery device 202 being attached or coupled to the user; (2) a partial deployment profile—the IMU 102 may detect that a full deployment/insertion of the needle was not completed (e.g., the needle may be inserted but was not fully retracted); (3) a non-deployment profile—the IMU 102 may detect that the needle deployment component 208 did not properly activate to insert and retract a needle; and (4) a full/proper deployment profile—the IMU 102 may detect that the needle deployment component 208 properly activated, and properly inserted and retracted a needle into the user as desired.

Each of these example of profiles may include characteristic features relating to direction of movement, amount of movement, time of movement, sequence of movement, and duration of movement and may vary according to these features. By comparing the detected movement of the needle deployment component 208 (e.g., after activation), the IMU 102 and/or the controller 210 may determine what type of deployment occurred. In this way, a more accurate and reliable approach to determining the operational status of the drug delivery device 202 may be determined.

As disclosed herein, each of the profiles may be associated with a mode of operation of the needle deployment component 208 and/or the drug delivery device 202. Based on the comparison of the detected motion or movement of the needle deployment component 208 by the IMU 102, a determination of the resulting mode of the drug delivery device 202 may be made substantially at the time of attempted or actual activation of the needle deployment component 208. The determined mode may then be communicated or provided to the user or caregiver essentially contemporaneously with the user's attempt to activate the drug delivery device 202. In this way, the user may learn immediately after activation of the needle deployment component 208 if the needle and/or needle deployment component 208 was operated properly or if an error in operation occurred. This obviates the need for the 90 minute checkup message to confirm proper operation relied on by conventional drug delivery devices.

FIG. 4 illustrates an example of a method of operation 400 of an apparatus. The apparatus may be operable to determine an operational state or mode of the needle deployment component 208 based on parameters monitored by the IMU 102. At 402, the IMU 102 may detect and/or measure movement of the needle deployment component 208, the drug delivery device 202, and/or any subcomponent thereof. The IMU 102 may detect and/or measure a direction of movement (e.g., in any direction), an amount of movement in a particular direction (e.g., an amplitude of the movement), a sequence of the detected movement (e.g., an order in which each detected movement occurs), a timing of the movement (e.g., when any particular movement occurs), a duration of the movement (e.g., how long each movement lasts), and what component is moving (e.g., the needle deployment component 208 by direct movement and/or a component coupled to the needle deployment component 208 by indirect/responsive movement). In an example, the IMU 102 may be operable to determine the motion of the needle deployment component and to generate one or more signals indicative of the determined motion of the needle deployment component. The one or more generated signals provided to a processor, such as controller 210. The one or more signals may, for example, be related to one or more of a measure of a direction of movement, an amount of movement in a particular direction, a sequence of the detected movement, a timing of the movement, a duration of the movement, or what component is moving. For example, the IMU may be operable to determine one or more directions of movement of the needle deployment component relative to three orthogonal reference axes. Alternatively, or in addition, the IMU may be operable to determine an amount of movement for each of the determined one or more directions of movement. Alternatively, or in addition, the IMU may be operable to determine a timing for each of the determined one or more directions of movement. Alternatively, or in addition, the IMU may be operable to determine a duration for each of the determined one or more directions of movement. Alternatively, or in addition, the IMU may be operable to determine a sequence of the determined one or more directions of movement.

At 404, the detected parameters from 402 may be compared to one or more movement profiles. The movement profiles may be known (e.g., the motion in particular axes of movement, timing of the particular motion, duration of motion, sequences of motion and the like) and stored and may be associated with a number of events that may be experienced by the needle deployment component 208 including, for example, those described herein: (1) early deployment; (2) partial deployment; (3) no deployment; and (4) full deployment. Each profile may specify a direction of movement, a duration of movement, an amount of movement, a sequence of movement, as well as what component is being profiled. The comparison may be made, for example, by comparing the movement parameters of the profiles to the parameters detected by the IMU 102. In an example, the movement parameters detected by the IMU 102 may be compared to one or more thresholds associated with each of the detected parameters. In a further example, the processor or controller may be operable to compare the detected motion of the needle deployment component to an early deployment profile. In the example, the early deployment profile may be related to movement of the needle deployment component prior to a drug delivery device containing the needle deployment component being attached to the user.

In a further example, the processor may be operable to compare the detected motion of the needle deployment component to a partial deployment profile. In the example, the partial deployment profile may be related to a needle failing to retract after being inserted into the user.

In a further example, the processor may be operable to compare the detected motion of the needle deployment component to a non-deployment profile. In the example, the non-deployment profile may be related to the needle deployment component failing to activate in response to the user attempting to activate the needle deployment component.

In another example, the processor may be operable to compare the detected motion of the needle deployment component to a full deployment profile. In the example, the full deployment profile may be related to the needle deployment component driving a needle and a cannula into the user, retracting the needle, and leaving the cannula coupled to the user.

At 406, an operational mode of the needle deployment component 208 may be determined based on the comparison from step 404 described above. Specifically, the operational mode may be based on a determination as to whether the needle deployment component 208 properly deployed and retracted a needle while leaving a cannula coupled to a user (e.g., movement matched full deployment profile), or if one or more errors occurred during activation of the needle deployment component 208 (e.g., movement matched non-deployment profile). For example, the processor or controller 210 may be operable to determine that the detected motion matches at least one of the movement profiles of: full deployment profile, the non-deployment profile, the early deployment profile, and the partial deployment profile. In an example, the operational profile for a certain mode (e.g., may be selected as the likely operational mode of the needle deployment component 208 based on how similarly the detected parameters from the IMU 102 match the characteristics of the movement profile modes described herein.

In an example, one of a number of different operational modes may be determined. In an example, either a first operational mode or a second operational mode may be determined with the first operational mode relating to proper or desired operation of the needle deployment component 208 and the second operational mode relating to improper or erroneous operation of the needle deployment component 208. In an example, multiple different operational modes may be specified with at least each of the four profiles described above equating to at least one operational mode.

At 408, the determined operational mode of the needle deployment component 208 may be communicated or provided to the user and/or the caregiver. The communication may be provided to the user and/or the caregiver through the communications interface 212 and may be provided to a remote device of the user and/or the caregiver (e.g., the remote device 218). The communication may also include providing a visual, audible, and/or tactile (e.g., vibrational) indication through the drug delivery device 202. The communication may indicate a likely operational mode of the needle deployment component 208 such that the user and/or the caregiver know, essentially at the same time as an attempted activation of the needle deployment component 208, whether the activation was successful and proper or if one or more errors occurred.

At 410, the controller 210 may adjust operational parameters of the drug delivery device based on the determined operation mode of the needle deployment component 208. For example, the controller 210 may set insulin delivery dosages to zero, so that no control commands are provided to the extraction mechanism 206. Alternatively, the controller 210 may modify the maximum delivery dose to a lower or higher value than standard if the needle deployment component is in a high-risk deployment mode, such as being placed in a region with scar tissue which may indicate the need, for example, for a 50% reduction in maximum delivery dose due to increased risk of occlusion, or, for example, a 150% increase in maximum delivery dose due to higher possibility of user not receiving the full insulin dosage required. Other operational parameters may prevent the actuation of the drive system of the needle deployment component 208 or the like.

In an example, the IMU 102 may detect when a user of the drug delivery device 202 is asleep or is awake. Based on such a determination, the drug delivery device 202 may adjust drug delivery and/or may adjust alert levels for notifying the user or the caregiver of certain operational states of the drug delivery device 202 or the user.

In an example, the drug delivery device 202 may include or may be in communication with a CGM, such as the CGM 216. Based on a determination of whether the user is asleep or awake by the IMU 102, the drug delivery device 202 may automatically adjust an insulin delivery rate to the user (e.g., basal insulin delivery) and/or may automatically adjust one or more thresholds (e.g., blood glucose thresholds) at which an alert may be communicated to the user or the caregiver.

In general, the drug delivery device 202 may include multiple insulin delivery rates at which the drug delivery device 202 is capable of providing insulin to the user. One of the rates may be selected based on the determined activity level of the user. As an example, a lower delivery rate may be selected when the user is determined to be asleep. Further, the drug delivery device 202 may include multiple alert settings having associated thresholds that vary with each alert level. One of the alert settings may be selected based on the determined activity level of the user. As an example, a higher threshold (e.g., BG value) may be selected when the user is determined to be asleep. In an example, when the user's glucose variability is very low for an extended period of time, a lower activity level may be detected and may also inform alert settings. For example, data provided from the accelerometer 104 may confirm low activity of the user as suspected based on the user's low glucose variability over a period of time, which may be used to adjust alert settings.

In an example, when it is determined that the user is awake, insulin delivery levels and alert levels may be set in the range of 70-80 mg/dL (for example, such that if blood glucose levels dip below or rise above the range an alert may be issued). Additionally, when it is determined that the user is asleep, insulin delivery levels and alert levels may be set in the range of 90-100 mg/dL (for example, such that if blood glucose levels dip below or rise above the range an alert may be issued). Different notification or alert levels could be set for the caregiver.

In an example, the IMU 102 may detect patterns in the activity of the user. For example, the IMU 102 may determine based on sensed movement when the user is likely asleep, likely awake, and likely awake but inactive (e.g., initially after waking or just prior to sleeping). The controller 210 may correlate typical blood glucose variations for the user with the determined activity levels of the user and may adjust insulin delivery levels and/or alert levels accordingly.

In an example, even when the IMU 102 does not detect that the user is asleep, operational settings of the drug delivery device 202 may be changed to the higher detection and/or alert settings during hours when the user normally sleeps. For automated insulin delivery (e.g., operating as an automatic pancreas), the user's target blood glucose (or setpoint) may be changed automatically based on sleep detection. For open loop basal-bolus therapy, the sleep detection may automatically trigger a different basal rate.

As disclosed herein, the pressure sensor 214 may be coupled to any portion of the fluid path coupling the liquid drug stored in the reservoir 204 to the user. The controller 210 may receive data from the pressure sensor 214 along with data from the IMU 102 and the CGM 216 to detect and/or predict occlusion or absorption issues and to better detect false alarms related thereto. The controller 210 may receive data from these sources and may implement prediction matching algorithms to detect different issues or events that the drug delivery device 202 or the user may be experiencing.

In an example, when the pressure sensor 214 detects drive resistance or increased pressure within any portion of the fluid path, the controller 210 may compare data from the IMU 102 and the CGM 216 to determine if an occlusion has been detected or if another issue is occurring. For example, if blood glucose levels of the user are not as expected (e.g., higher or lower than expected but not yet crossing a threshold triggering an alarm), then early detection of an occlusion or other blockage in absorption may be detected. The controller 210 may process motion data from the IMU 102 to determine if the user is moving and active or is stationary. Blood glucose levels may be determined to not be as expected by the controller 210 based on the amount of insulin that should have been delivered (e.g., blood glucose levels are not decreasing, or are not decreasing at the expected rate).

Upon processing the data from the IMU 102, if the user is determined to be largely stationary and not moving, then the controller 210 may determine that the user may be sitting or lying down in a way that is putting pressure on a portion of the fluid path or tubing connecting the drug delivery device 202 to the user. The controller 210 may then issue a notification to the user regarding the issue and request that the user check the fluid path connection or to move around (e.g., to remove the blockage or kink in the tubing).

Once the IMU 102 detects movement of the user in response to the notification, the controller 210 may determine if data from the pressure sensor 214 indicates a drop in pressure (e.g., data indicating no further occlusion or blockage issue). If pressure appears to be returning to normal operational levels, and blood glucose readings for the user return to more normal operational levels, then the controller 210 may determine that the issue has been resolved and was likely caused by a temporary blockage of the fluid path (e.g., perhaps the user was sitting on the tubing).

Alternatively, if the pressure reading data from the pressure sensor 214 returns to normal operating levels but the blood glucose levels of the user continue to be out of range of normal operation or are trending to be out of range, then the controller 210 may determine that the infusion site of the user may be experiencing a problem. For example, the cannula inserted into the user may be dislodged or otherwise positioned incorrectly (e.g., in a manner that prevents absorption). Under such a scenario, the controller 210 may issue a notification or alarm to the user or the caregiver to check the infusion site to determine if the cannula has become dislodged, the drug delivery device 202 has come detached from the user, or if any drug is leaking from the drug delivery device 202.

Additionally, if the pressure reading data from the pressure sensor 214 does not lower after the IMU 102 detects that the user moves around after the initial notification from the controller 210, then the controller 210 may determine that an occlusion or other blockage is indeed occurring to the fluid path (e.g., internal to the drug delivery device 202). The controller 210 may then issue more a serious notification indicating that a likely blockage is occurring.

In an example, when it is determined the user is likely asleep based on data from the IMU 102 and the controller 210 determines that the user may be positioned on top of tubing coupling the drug delivery device 202 to the user, then the controller 210 may issue a notification or alarm to the user that wakes the user—in order to notify the user to move so as to remove the blockage of the tubing.

By correlating motion data from the IMU 102, pressure data from the pressure sensor 214, and blood glucose levels of the user from the CGM, the controller 210 may more efficiently and reliably detect actual occlusion issues and false alarms related thereto.

FIG. 5 illustrates an example of a process 500 for more accurately determining an occlusion or absorption issue and distinguishing the same from a false alarm. At 502, the controller 210 may receive pressure data from the pressure sensor 214. For example, the controller 210 may receiving a first signal indicating a pressure of a fluid path coupling a reservoir storing a liquid drug to a user. The pressure sensor 214 may detect any drive resistance or pressure increase within any portion of the fluid path coupled to the user. The pressure sensor 214 may generate one or more signals indicating the same and may provide the signals to the controller 210. Based on the received data and/or signals from the pressure sensor 214, the controller 210 may determine that an abnormal increase in pressure has been detected. In an example, the controller 210 may compare the received data from the pressure sensor to one or more predetermined thresholds.

At 504, the controller 210 may receive BG data from the CGM 216. For example, the controller 210 may receive a second signal indicating a blood glucose level of the user. The CGM 216 may measure or detect BG levels of the user and may generate one or more signals indicating the same. The generated signals may be provided to the controller 210. Based on the received data from the CGM 216, the controller 210 may determine if BG levels are as expected or deviate from a predicted level based on, for example, an amount of insulin that has been delivered to the user. The controller 210 may determine if a severe deviation from expected BG levels is occurring or if BG levels are within an acceptable range. If a severe deviation from expected BG levels is occurring, the controller 210 may issue an immediate notification to the user indicating the same.

If BG levels remain in a tolerable range, then the controller 210 at 506 may receive motion data from the IMU 102. For example, the controller 210 may receive a third signal indicating a motion of the user. Data from the IMU 102 may indicate if the user is in motion or is inactive. In an example described herein, determining a direction of movement may involve determining motion in any three-dimensional direction for example with reference to three orthogonal reference axes commonly referred to as the x, y, and z directions. Accordingly, directions may be along any axes (e.g., in the x axes) and in any direction (e.g., forward or in the positive direction) and directions may be along any combination of axes (e.g., such that a direction is a combination of components along two different axes). Determining an amount of movement may involve determining a distance travelled or an amount of displacement in a particular direction. Determining a timing of a movement may involve determining a time at which movement in a particular direction starts or stops relative to a universal time or relative to motion of other objects or motion in other directions. Determining a duration of movement may involve determining how long movement in a particular direction lasts. Determining a sequence of movement may involve determining an order in which movements in different directions occur. For example, a first direction of movement may be in the negative y direction and subsequently in a positive z direction. Further, determining the movement of an object or component as described herein may further include determining a velocity or acceleration of the object or component.

For example, if the user is inactive, and the BG levels of the user are within an acceptable range, the controller 210 may determine that the user may be sitting, laying (if sleeping), or the like on the tubing connecting the drug delivery device 202 to the user in a manner that blocks or otherwise prevents delivery of the drug to the user.

At 508, the controller 210 may issue a notification to the user based on an evaluation of the first, second, and third signals. The controller 210 upon evaluation of the first, second and third signals, the controller 210 may determine that when the pressure exceeds a first pressure threshold, the blood glucose level is trending outside of a first range, and the motion indicates the user is inactive, the initial notification to comprise an initial alert indicating that tubing connecting a drug delivery device to the user is likely blocked and requesting the user to move to unblock the tubing. For example, the controller 210 may, in response to the evaluation of the received first, second and third signals, issue an initial notification to the user based on the first, second, and third signals. The notification may be provided, as an example, to the remote device 218. The notification may indicate that a blockage in the tubing is suspected and may request that the user check the tubing or otherwise move to adjust the routing of the tubing. In another example, the controller 210 may issue an additional notification. The additional notification may include an additional alert indicating that an occlusion has been detected within the drug delivery device when the pressure continues to exceed the first pressure threshold after the user has moved in response to the initial notification. Alternatively, or in addition, the additional alert may indicate that an infusion site may be dislodged when the pressure drops below the first threshold and the blood glucose level continues trending outside of the first range. Alternatively, or in addition, the additional alert may indicate that an infusion site may be dislodged when the pressure drops below the first threshold and the blood glucose level continues trending outside of the first range. Alternatively, or in addition, the additional alert may indicate proper operation of the drug delivery device when the pressure drops below the first threshold the blood glucose level is trending inside of the first range. The controller 210 may be operable to wirelessly transmit, via the communications interface 212, the initial notification as a message to one or more remote devices, such as remote device 218. Alternatively, or in addition, the initial notification may be provided a visual alert, an audible alert, and/or a vibrational alert from the drug delivery device 202.

At 510, the controller 210 may recheck pressure data from the pressure sensor 214, BG data from the CGM sensor 216, and motion data from the IMU 102. These data may be rechecked after a predetermined period of time after the notification is received by the user and/or the user responds to the notification request. If the pressure data indicates that no blockage or other occlusion is being detected but the BG values are trending out of a desired range, then the controller 210 may determine that an issue with absorption of the drug may be occurring. As a result, at 512, the controller 210 may issue a second notification to the user indicating that an issue with the infusion site may be occurring and may request the user to check for errors at the infusion site or any leakage of the drug.

If the pressure data continues to trend in a manner that indicates pressure is continuing to increase or is not lowering, then the controller 210 may determine that an occlusion issue is occurring, for example internal to the drug delivery device 202. As a result, at 512, the controller 210 may issue a second notification to the user indicating that an occlusion or blockage issue is occurring.

If the pressure data returns to a normal operable range and the BG data returns to a normal operable range, then the controller 210 may determine that the issue related to possible blockage in the tubing has been resolved. Accordingly, the controller 210 may not issue a second notification at 512 or alternatively may issue a notification indicating that the detected problem has been resolved.

In an example, the user may receive an alert from the drug delivery device 202 (e.g., transmitted to and received on the user's smartphone 218 or conveyed by a noise or vibration from the drug delivery device 202). The alert may indicate that a bolus injection of insulin is needed. At times, it may be inconvenient, socially awkward, or physically impossible for the user to access their smartphone or remote control device 218 to send a response signal to confirm the bolus delivery. Under such situations, it may be easier and/or less socially awkward for the user to engage or interact with a user interaction feature or other sensor on the drug delivery device 202 that may be used to confirm the bolus delivery or other action for which confirmation is requested.

In an example, the user may respond to a notification or alert by tapping on the drug delivery device 202. The tapping by the user may be detected by the IMU 102. The tapping that may be registered by the IMU 102 may be determined to indicate acknowledgement or confirmation of the bolus delivery by the user. In an example, the tapping or touching sequence may be set to a specific sequence of tapping, duration, or type of touching (or may be customized) to convey confirmation by the user and to avoid inadvertent confirmation (e.g., through some other alternative or accidental contact with the drug delivery device 202). In an example, the drug delivery device 202 may be programmed by a user or the caregiver to recognize a particular sequence of touching or tapping by the user as indicating confirmation by the user.

In an example, the drug delivery device 202 may include a sensor for detecting a fingerprint of the user (or a fingerprint of the caregiver or other authorized individual) or some other biometric of the user. For example, the fingerprint sensor may be used by the user to register a confirmation to a bolus delivery alert by the controller 210 as described herein.

In response to any confirmation signal from the user, the drug delivery device 202 may indicate through a notification that the command or acknowledgement from the user has been received and the action (e.g., bolus delivery) is being undertaken. In various example, any external sensor or user interface component positioned on the drug delivery device 202 may provide a redundant means for determining the user is inactive and/or asleep.

At 514, the controller 210 may adjust operational parameters of the drug delivery device based on an input received automatically, or in response to the second notification issued to a user. For example, the controller 210 may set insulin delivery dosages to zero, so that no control commands are provided to the extraction mechanism 206 or modify allowable ranges of insulin deliveries to within tighter or looser bounds than normally allowable, such as reducing maximum insulin delivery dosages by the user to approximately 50% of standard settings or increasing maximum delivery dosages by the user to approximately 150% of standard settings. Other operational parameters may prevent the actuation of the drive system of the needle deployment component 208 or the like. Alternatively, the controller 210 may reduce an amount of insulin to be delivered temporarily to ensure that the drug delivery device 202 is operating properly.

In an example, the features and/or functions of the IMU 102 may be implemented by the processor/controller 210. In an example, the IMU 102 may be a separate component from the processor/controller 210. The IMU 102 may be implemented in hardware, software, or any combination thereof.

An example of an apparatus operable to provide the example method 500 of FIG. 5 may be structurally similar to the drug delivery device 202 of FIG. 2. For example, the apparatus include a processor, a storage device, a pressure sensor, a blood glucose sensor, an inertial measurement unit (IMU), and a needle deployment component. In the example, the pressure sensor may be operable to detect pressure in a fluid path between a reservoir storing a liquid drug and cannula configured to couple to a user. The needle deployment component may include the cannula and other components for coupling the cannula to the user. In an example, the pressure sensor may be operable to generate a first signal indicative of a pressure of the fluid path. The blood glucose sensor may be coupled to the user and may be configured to generate a second signal indicative of a blood glucose level of the user. The IMU may be configured to generate a third signal indicative of a motion of the user. The processor may be coupled to the storage device and may be implemented in circuitry operable to perform functions as described herein. The processor may be configured to issue an initial notification for presentation to the user based on the first, second, and third signals. The drug delivery device 202 may include visual, auditory, vibrational components that are operable to provide visible, audible and tactile alerts in response to receipt of the initial notification from the processor.

In an example, the initial notification issued by the processor may include an initial alert indicating that tubing connecting a drug delivery device to the user is likely blocked (i.e., occluded) when the pressure exceeds a first pressure threshold, the blood glucose level is trending outside of a first range, and the motion indicates the user is inactive. The processor may also generate a prompt for receipt by a user requesting that the tubing be unblocked.

In addition, or alternatively, the processor may be operable to issue an additional notification comprising an additional alert indicating that an occlusion has been detected within the drug delivery device when the pressure continues to exceed the first pressure threshold after the user has moved in response to the initial notification.

In addition, or alternatively, the processor may be operable issue an additional notification including an additional alert indicating that an infusion site may be dislodged when the pressure drops below the first threshold and the blood glucose level continues trending outside of the first range.

In addition, or alternatively, the processor may be operable to issue an additional notification including an additional alert indicating proper operation of the drug delivery device when the pressure drops below the first threshold the blood glucose level is trending inside of the first range.

Certain examples of the present disclosed subject matter were described above. It is, however, expressly noted that the present disclosed subject matter 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 subject matter. Moreover, it is to be understood that the features of the 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 subject matter. 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 subject matter. As such, the disclosed subject matter is not to be defined only by the preceding illustrative description.

Claims

1.-20. (canceled)

21. An on-body drug delivery device, comprising:

a communication interface operable to communicate with a glucose sensor;

an inertial measurement unit comprising at least one of an accelerometer or a gyroscope; and

a controller, at least a portion of which is implemented in circuitry coupled to the communication interface and the inertial measurement unit, wherein the controller is operable to: determine that glucose measurements received from the communication interface are changing; generate an alert requesting confirmation of a change to drug delivery; receive, via the inertial measurement unit, an indication responsive to the requested confirmation; and determine a response based on the received indication.

22. The on-body drug delivery device of claim 21, wherein the inertial measurement unit is further operable to detect an occurrence of one or more taps or touches on the on-body drug delivery device, and the controller is further operable to determine whether the occurrence of the one or more taps or touches on the on-body drug delivery device matches a pre-programmed sequence of taps or touches.

23. The on-body drug delivery device of claim 22, wherein the controller is further operable to:

receive, from the inertial measurement unit, the detected occurrence of the one or more taps or touches; and

generate a notification confirming a bolus delivery has been or will be delivered.

24. The on-body drug delivery device of claim 21, wherein the controller is further operable to:

determine that the received indication is confirmation that a meal has been ingested.

25. The on-body drug delivery device of claim 21, wherein the controller, when generating the alert requesting confirmation of a change to drug delivery, is operable to:

forward a message, via the communication interface, to a remote device.

26. The on-body drug delivery device of claim 21, wherein the controller, when determining the response based on the received indication, is further operable to:

cause a change to drug delivery; and

generate a notification that a change to drug delivery has been undertaken.

27. The on-body drug delivery device of claim 21, wherein the controller, based on the determined response, is further operable to:

cause a vibration to be emitted from the on-body drug delivery device indicating that a bolus injection is needed.

28. The on-body drug delivery device of claim 27, wherein the controller is further operable to:

receive, via the inertial measurement unit, a further indication confirming delivery of the bolus injection.

29. The on-body drug delivery device of claim 21, wherein the alert requesting confirmation is an audible alert.

30. An on-body drug delivery device, comprising:

a drug reservoir operable to hold a liquid drug;

an inertial measurement unit operable to detect taps or touches on the on-body drug delivery device;

an output device operable to output alerts, and

a controller, wherein the controller is operable to:

generate, via the output device, an alert that a change to drug delivery is needed;

receive, via the inertial measurement unit, a signal regarding a sequence of one or more taps or touches to the on-body drug delivery device; and

compare the sequence of one or more taps or touches to the on-body drug delivery device to one or more pre-programmed sequences; and

based on the comparison, carry out a change to drug delivery if the sequence of one or more taps or touches to the on-body drug delivery device matches a pre-programmed sequence that corresponds to the change to drug delivery.

31. The on-body drug delivery device of claim 30, wherein the change to drug delivery is a bolus injection.

32. The on-body drug delivery device of claim 30, wherein the alert is an indication that a glucose level has risen and the change to drug delivery is a bolus injection of the liquid drug.

33. The on-body drug delivery device of claim 30, wherein the output device comprises:

a speaker that is operable to output the generated alert as an audible alert.

34. The on-body drug delivery device of claim 30, wherein the output device comprises:

a vibration device that is operable to output the generated alert as a tactile indicator.

35. The on-body drug delivery device of claim 30, further comprising:

a communication interface operable to receive communications via a wireless communication link, wherein the communication interface is coupled to the controller.

36. The on-body drug delivery device of claim 35, wherein the communication interface is further operable to:

provide the controller with glucose measurements received by the communication interface from a glucose monitor.

37. The on-body drug delivery device of claim 36, wherein the controller is further operable to:

receive the glucose measurements from the communication interface; and

determine based on the received glucose measurements whether to generate the alert that a change to drug delivery is needed.

38. A drug delivery system, comprising:

a glucose sensor including a sensing device and a communication device, wherein the sensing device is operable to measure glucose and the communication device is operable to transmit data indicative of the measured glucose; and

an on-body drug delivery device including:

a drug reservoir operable to hold a liquid drug;

an inertial measurement unit operable to detect taps or touches on the on-body drug delivery device; and

a controller, wherein the controller is operable to:

receive the data indicative of the measured glucose;

based on the received data, generate a haptic or audible alert;

receive, via the inertial measurement unit, data indicative of a sequence of one or more taps or touches on the on-body drug delivery device; and

generate a response based on the received data indicative of the sequence of one or more taps or touches on the on-body drug delivery device.

39. The drug delivery system of claim 38, the on-body drug delivery device further comprising:

a speaker or a vibration device, wherein the speaker is operable to output the audible alert, and the vibration device is operable to output the haptic alert.

40. The drug delivery system of claim 38, wherein the alert is an indication that a glucose level has risen and the response is a bolus injection of the liquid drug.