The present application claims priority from U.S. c. ≡119 (e) to U.S. provisional patent application No. 63/400,648, filed on 8/24 of 2022 and entitled "Automatic Suspension and Resumption of MEDICAMENT DELIVERY", the entire disclosure of which is hereby incorporated by reference.
Detailed Description
SUMMARY
Maintaining analyte levels (e.g., blood glucose levels) within acceptable ranges can be challenging, and in various cases, adjusting those levels involves administering a drug (e.g., insulin) throughout the day using a drug delivery system (e.g., insulin pump). Conventional drug delivery systems may provide the ability to manually suspend and resume drug delivery as part of controlling analyte levels within an acceptable range. For example, the user may manually send a first command to the conventional insulin pump to halt insulin delivery, such as by providing user input to an application program displayed on the user device, removing the insulin pump, and/or providing user input to the insulin pump itself. Then, at a later time, the user may manually send a second command to the insulin pump to resume insulin delivery.
The user may decide to manually pause drug delivery for a variety of different reasons using conventional systems. In a first example, the user may decide to manually pause insulin delivery during an exercise because performing the exercise may drastically reduce the user's blood glucose level. Thus, in this example, the user may manually pause insulin delivery during the workout to prevent the combination of insulin delivery and workout from causing the user's blood glucose level to drop below the target range, resulting in the person experiencing a hypoglycemic event. Similarly, in a second example, the user may decide to manually pause insulin delivery (e.g., by removing the insulin delivery device) during a bath or while exercising. However, in both examples, conventional systems do not automatically resume insulin delivery, but rather require the user to manually resume insulin delivery. However, in many cases, the user may forget to manually resume insulin delivery, which may lead to dangerous health conditions for the user, for example, if insulin delivery is not enabled, the user's blood glucose level may then rise above the target range associated with hyperglycemia.
To address these problems, automatic suspension and resumption of drug delivery is utilized. In accordance with the described techniques, the delivery device control system is configured to provide automatic suspension and/or resumption of drug delivery in a manner that eliminates or reduces user interaction associated with manual suspension and resumption of insulin delivery. In one or more implementations, the drug delivery system may automatically pause and automatically resume insulin delivery based on sensor data indicating the user's location and/or the activity the user is performing. For example, the delivery device control system may suspend and/or resume drug delivery based on the user's location determined from the sensor data. For example, at a first time, the delivery device control system determines or predicts that the user is present at the first location and, based on the determined or predicted presence of the user at the first location, the delivery device control system pauses drug delivery, for example, by instructing the drug delivery system (e.g., insulin pump) to pause drug delivery to the user. Then, at a second, subsequent time, the delivery device control system determines or predicts that the user is present at a second, different location (or that the user is away from the first location). Based on the determined or predicted presence of the user in the second location (or the user leaving the first location), the delivery device control system automatically (without user input) resumes drug delivery, for example, by instructing the drug delivery system to resume suspended drug delivery to the user.
Alternatively or in addition, the delivery device control system pauses and/or resumes drug delivery based on sensor data indicative of an activity of a user (e.g., an activity performed by a user wearing the drug delivery system). For example, at a first time, the delivery device control system determines or predicts that the user is performing an activity and, based on the determined or predicted activity, pauses drug delivery, for example, by instructing the drug delivery system to pause delivery of the drug to the user. Then, at a second, subsequent time, the delivery device control system determines or predicts that the user is stopped performing the activity (or that the user is performing a different activity). Based on determining or predicting that the user is no longer performing an activity (or that the user is performing a different activity), the delivery device control system automatically (without user input) resumes drug delivery, for example, by instructing the drug delivery system to resume suspended drug delivery to the person. In at least one variation, the delivery device control system further determines the activity performed by the user based at least in part on determining the location of the user. For example, the user's location (e.g., in a gym) may be used by the delivery device control system to infer an activity (e.g., exercise). However, in different variations, the delivery device control system determines the activity performed by the user, and not the location of the user.
In one or more implementations, the delivery device control system provides a temporary suspension feature that temporarily suspends drug delivery for a suspension period of time and then automatically resumes drug delivery after the suspension period of time has elapsed. In this implementation, the delivery device control system may suspend delivery based on receiving user input requesting to suspend delivery of the drug, rather than determining when to suspend delivery without user input. Such a request may be received via the drug delivery system, for example, in response to a user selecting a graphical control displayed via a display device of the drug delivery system or selecting a physical control (e.g., button) of the drug delivery system. In at least one variation, the user also specifies a pause period, i.e., how long the delivery device control system will pause the delivery of the drug before resuming delivery. Alternatively, the user does not designate the pause period as part of the request, and the delivery device control system determines the pause period without requiring the user to enter the pause period. In one or more variations, the delivery device control system automatically resumes delivery of the drug (without user input) in response to determining that the pause period has elapsed. In other words, after the pause period has elapsed, the delivery device control system resumes delivery of the drug without receiving user input near the time at which delivery was resumed-the delivery device control system resumes delivery based on the hold value specifying the pause period.
Thus, by automatically suspending and/or resuming drug delivery without user input, the described techniques reduce or eliminate dangerous health conditions caused by conventional drug delivery systems that require a user to manually suspend and manually resume insulin delivery.
In some aspects, the technology described herein relates to a system comprising one or more sensors, a drug delivery system configured to deliver a drug to a user, and a delivery device control system configured to control the drug delivery system to suspend delivery of the drug to the user in response to a request initiated by the user and to automatically resume delivery of the drug to the user after a suspension period has elapsed, and to control the drug delivery system to automatically suspend delivery of the drug to the user based on first sensor data obtained from the one or more sensors and to automatically resume delivery of the drug to the user based on second sensor data obtained from the one or more sensors.
In some aspects, the technology described herein relates to a system wherein the delivery device control system is further configured to control the drug delivery system to automatically suspend delivery of the drug to the user based on first sensor data indicating that the user is performing an activity, and to automatically resume delivery of the drug to the user based on second sensor data indicating that the performance of the activity is completed.
In some aspects, the technology described herein relates to a system wherein the delivery device control system is further configured to control the drug delivery system to automatically suspend delivery of the drug to the user based on first sensor data indicating that the user is at a location, and to automatically resume delivery of the drug to the user based on second sensor data indicating that the user is at a subsequent location.
In some aspects, the technology described herein relates to a system that further includes an analyte monitoring device connected to the drug delivery system to form a closed loop system.
In some aspects, the technology described herein relates to a system wherein the analyte monitoring device comprises a wearable glucose monitoring device, and wherein the drug delivery system comprises a wearable insulin pump.
In some aspects, the technology described herein relates to a system wherein the delivery device control system is implemented at a computing device that is wirelessly coupled to the drug delivery system and the analyte monitoring device.
In some aspects, the technology described herein relates to a system wherein the delivery device control system is implemented at the analyte monitoring device.
In some aspects, the technology described herein relates to a system wherein the delivery device control system is implemented at the drug delivery system.
In some aspects, the technology described herein relates to a method that includes receiving a request to pause delivery of a drug to a user, controlling a drug delivery system to pause delivery of the drug to the user, and controlling the drug delivery system to automatically resume drug delivery to the user after a pause period.
In some aspects, the technology described herein relates to a method wherein the drug delivery system automatically resumes drug delivery to the user after the pause period has elapsed without user interaction.
In some aspects, the technology described herein relates to a method wherein the drug delivery system is connected to an analyte monitoring device and a computing device to form a closed loop system.
In some aspects, the technology described herein relates to a method wherein the request to suspend delivery of the drug is received in response to user input to the drug delivery system.
In some aspects, the techniques described herein relate to a method in which a request to suspend delivery of the drug is received in response to user input to a user interface displayed at the computing device.
In some aspects, the techniques described herein relate to a method wherein the request to pause delivery of the drug to the user includes an indication of the pause period.
In some aspects, the techniques described herein relate to a method in which the pause period corresponds to a predetermined period.
In some aspects, the technology described herein relates to a method wherein the drug comprises insulin.
In some aspects, the technology described herein relates to a method that includes obtaining sensor data from one or more sensors, predicting an activity to be performed by a user based on the sensor data, controlling a drug delivery system to suspend delivery of a drug to the user during performance of the activity, and controlling the drug delivery system to automatically resume delivery of the drug to the user after performance of the activity is completed.
In some aspects, the techniques described herein relate to a method that further includes detecting completion of execution of the activity based on additional sensor data obtained from the one or more sensors.
In some aspects, the technology described herein relates to a method wherein the activity comprises exercise, sleep, or bathing.
In some aspects, the techniques described herein relate to a method that further includes detecting a location of a user based on the sensor data, wherein the predicting further includes predicting an activity to be performed by the user based on the location of the user.
In some aspects, the technology described herein relates to a method wherein detecting the location of the user comprises detecting the location of the user based on first sensor data and confirming the location of the user based on second sensor data.
In some aspects, the technology described herein relates to a method wherein detecting the location of the user includes detecting at least two candidate locations of the user based on first sensor data and selecting one of the at least two candidate locations as the location of the user based on second sensor data.
In some aspects, the techniques described herein relate to a method wherein the predicting includes predicting a time at which the activity will begin based on the sensor data.
In some aspects, the techniques described herein relate to a method further comprising controlling the drug delivery system to administer a bolus dose of the drug to a predicted time at which the activity will begin.
In some aspects, the technology described herein relates to a method wherein the bolus dose of the drug comprises a bolus dose of insulin.
In some aspects, the technology described herein relates to a method further comprising determining a current glucose measurement for the user based on a glucose monitor worn by the user, and determining a bolus dose of insulin based on the current glucose measurement for the user.
In some aspects, the technology described herein relates to a method that includes controlling a drug delivery system to suspend drug delivery to a user at a first time based on the user's location, controlling the drug delivery system to resume drug delivery to the user at a second time based on the user's subsequent location, and causing the drug delivery system to deliver a dose of drug to the user in response to resuming drug delivery.
In some aspects, the technology described herein relates to a method wherein controlling the drug delivery system to suspend and resume drug delivery comprises controlling the drug delivery system to automatically suspend and resume drug delivery without user input.
In some aspects, the technology described herein relates to a method wherein controlling the drug delivery system to suspend and resume drug delivery to the user is not based on analyte data.
In some aspects, the technology described herein relates to a method wherein the dose of drug delivered to the user is based at least in part on the analyte data.
In some aspects, the technology described herein relates to a method wherein the dose of drug delivered to the user is based at least in part on a time interval between the first time and the second time.
In some aspects, the techniques described herein relate to a method in which the dose of medication delivered to the user is based at least in part on an activity performed by the user between the first time and the second time.
In some aspects, the techniques described herein relate to a method in which the activity is predicted based at least in part on the location of the user.
In the following discussion, an exemplary environment is first described in which the techniques described herein may be employed. Examples of specific implementation details and programs that may be executed in the exemplary environment are then described as well as in other environments. The execution of the exemplary program is not limited to the exemplary environment, and the exemplary environment is not limited to the execution of the exemplary program.
Examples of environments
Fig. 1 is an illustration of an environment 100 in an example implementation that is operable to employ automatic suspension and resumption of drug delivery. The illustrated environment 100 includes a person 102 depicted wearing an analyte monitoring device 104 and a drug delivery system 106. The illustrated environment 100 also includes an example computing device 108, a delivery device control system 110, a health monitoring platform 112, and the internet of things (IoT 114). The analyte monitoring device 104, the drug delivery system 106, the example computing device 108, the delivery device control system 110, the health monitoring platform 112, and the IoT 114 are communicatively coupled, such as via a network 116.
The analyte monitoring device 104, the drug delivery system 106, and the one or more computing devices 108 (associated with the person 102) may be communicatively coupled in various ways, such as through the use of one or more wireless communication protocols or techniques. For example, the analyte monitoring device 104, the drug delivery system 106, and the one or more computing devices 108 may communicate with each other using one or more of radio, cellular, wi-Fi, bluetooth (e.g., bluetooth low energy link), near Field Communication (NFC), and 5G, to name a few.
In one or more implementations, through such communicative coupling, one or more of the analyte monitoring device 104, the drug delivery system 106, and the one or more computing devices 108 may form a closed-loop system. When implemented as a closed-loop system, the combination of devices is configured to provide automatic suspension and resumption of drug delivery in a manner that eliminates or reduces user interaction associated with temporarily removing drug delivery system 106 (such as bathing or engaging in athletic activities, e.g., basketball). Rather, these devices process various information and make various predictions and determinations, such as regarding the user's location and/or the activities the user is performing or will perform based on that location, to automatically suspend and resume drug delivery. In a closed-loop system, these devices may thus control drug delivery system 106 to pause and subsequently resume delivery of the drug to person 102 without user interaction, such as without receiving user input to any controls for explicitly pausing or resuming drug delivery (e.g., controls of drug delivery system 106 or computing device 108).
In one or more implementations, the analyte monitoring device 104 is wearable such that it is worn by the person 102 while the device performs various operations. Additionally or alternatively, analyte monitoring device 104 performs one or more operations before or after being worn by person 102. In broad terms, the analyte monitoring device 104 is configured to provide a measurement of an analyte of the person 102 (e.g., glucose of the person 102). For example, the analyte monitoring device 104 may be configured with an analyte sensor that detects one or more signals indicative of an analyte in the person 102 and enables generation of analyte measurements or estimates (e.g., estimated glucose values). Those analyte measurements (e.g., glucose measurements) may correspond to or otherwise be packaged for transmission as analyte data 118 to one or more of the computing device 108 or the drug delivery system 106.
In at least one implementation, the analyte monitoring device 104 is a glucose monitoring system. As an example, the analyte monitoring device 104 may be configured as a Continuous Glucose Monitoring (CGM) system, e.g., a wearable CGM system. As used herein, the term "continuous" when used in connection with analyte monitoring may refer to the ability of a device to substantially continuously generate measurements such that the device may be configured to generate analyte measurements at regular or irregular intervals (e.g., about every hour, about every 30 minutes, about every 5 minutes, etc.) or the like in response to establishing a communicative coupling with a different device (e.g., when the computing device 108 establishes a wireless connection with the analyte monitoring device 104 to retrieve one or more of these measurements). However, in other implementations, the glucose monitoring device may not be "continuous" but rather provide glucose measurements upon request. For example, analyte monitoring device 104 may transmit the current glucose measurement to computing device 108 in response to a request from computing device 108. The request may be initiated in a variety of different manners, such as in response to a user input to a user interface displayed by computing device 108 (and/or a different device), in response to placing computing device 108 within a threshold proximity of analyte monitoring device 104, in response to computing device 108 making physical contact with analyte monitoring device 104, in response to a request from an application implemented at computing device 108, and so forth. Additional aspects of this functionality and the configuration of analyte monitoring device 104 are discussed in more detail with respect to fig. 2.
In addition to generating analyte data 118, analyte monitoring device 104 also transmits the generated analyte data 118 to, for example, computing device 108. Analyte monitoring device 104 may transmit data in real-time, for example, as data is generated using an analyte sensor. Alternatively or in addition, the analyte monitoring device 104 may transmit data to the computing device 108 at predefined time intervals. For example, the analyte monitoring device 104 may be configured to transmit the analyte data 118 to the computing device 108 approximately every five minutes. Of course, the interval at which analyte data 118 is transmitted by analyte monitoring device 104 may be different from the above examples without departing from the spirit or scope of the described technology. In other implementations, the analyte data 118 is transmitted by the analyte monitoring device 104 when requested. For example, the analyte monitoring device 104 device may transmit the current analyte measurement to the computing device 108 in response to a request from the computing device 108. The request may be initiated in a variety of different manners, such as in response to a user input to a user interface displayed by the computing device 108 (and/or a different device), in response to placing the computing device 108 within a threshold proximity of the analyte monitoring device 104, in response to the computing device 108 making physical contact with the analyte monitoring device 104, in response to a request from an application implemented at the computing device, and so forth. In accordance with the described techniques, data may be transmitted by analyte monitoring device 104 to computing device 108 on other bases.
Additionally, the computing device 108 may at least temporarily store the analyte data 118 and the sensor data 120 received from the various sources in, for example, a storage device (not shown) of the computing device 108. Analyte data 118 and sensor data 120 may also be stored with other associated data in such storage of computing device 108 or in storage of a different device, such as with a corresponding timestamp and/or identifier of the data packet being transmitted, to name a few.
As depicted, the described system may include one or more computing devices 108 in accordance with the described techniques. In one or more scenarios, for example, the described techniques may be implemented using a computing device 108, such as a mobile phone. Alternatively, the described techniques can be implemented using a plurality of computing devices 108 that include both wearable devices (e.g., smart watches, gear guards, contact lenses, smart glasses, chest bands, earplugs, or headphones, to name a few) and mobile phones in at least one variation. In such a scenario, the two devices may be capable of performing at least some of the same operations, such as receiving analyte data 118 from analyte monitoring device 104, receiving sensor data 120 from various sources, generating sensor data 120 using onboard or associated sensors, transmitting data to delivery device control system 110 and/or health monitoring platform 112 via network 116, displaying information related to the data, displaying information related to automatic drug suspension or resumption regulated by delivery device control system 110, facilitating control of drug delivery system 106, and the like. Alternatively or in addition, different devices may have different capabilities that other devices do not have or are limited to a given device by computing instructions.
Delivery device control system 110 controls drug delivery system 106 to suspend delivery of the one or more drugs and subsequently resume delivery of the one or more drugs. The delivery device control system 110 controls the drug delivery system 106 at least in part by processing the sensor data 120 and by providing instructions 122, such as by providing the instructions 122 to the drug delivery system 106, the computing device 108, and/or another device (e.g., an additional drug delivery system). In accordance with the described techniques, the delivery device control system 110 makes and suspends and/or resumes a determination regarding drug delivery at least in part by utilizing one or more of the computing device 108, the drug delivery system 106, the health monitoring platform 112, and the IoT 114.
Although depicted as separate from the analyte monitoring device 104, drug delivery system 106, computing device 108, and health monitoring platform 112, in one or more implementations, at least a portion of the delivery device control system 110 is implemented at one or more of those entities. Additionally, various portions of the delivery device control system 110 can be implemented at or otherwise using different combinations of the analyte monitoring device 104, the drug delivery system 106, the computing device 108, and the health monitoring platform 112, in accordance with the described techniques.
As discussed above and below, the delivery device control system 110 obtains sensor data 120 from various sources. For example, the delivery device control system 110 obtains the sensor data 120 from one or more of the drug delivery system 106, the computing device 108, the health monitoring platform 112, or the IoT 114. Examples of sensor data 120 include, but are not limited to, global Positioning System (GPS) data, wi-Fi information (e.g., service Set Identifiers (SSID) of an available network, a network to which computing device 108 is connected, and/or a network to which computing device 108 is previously connected), bluetooth Low Energy (BLE) information, data generated using a cellular antenna (e.g., long Term Evolution (LTE)), microphone data (e.g., sound data), accelerometer data, gyroscope data, magnetometer data, barometer data, environmental or internal temperature data (e.g., generated using a temperature sensor), light data (e.g., captured using a camera of the device), heart rate data (e.g., generated by a smart phone and/or a smart watch), proximity data (e.g., between devices), humidity data, analyte data, and medication data, to name a few. It should be understood that this list is not exhaustive and that the delivery device control system 110 may receive a variety of other data (some of which are discussed above and below) without departing from the spirit or scope of the described technology.
In the illustrated example, the delivery device control system 110 is depicted as including a position prediction engine 124. However, the delivery device control system 110 may include more, fewer, or different components without departing from the spirit or scope of the described technology. Some examples of various configurations of delivery device control system 110 are discussed below.
Based on the sensor data 120, the position prediction engine 124 detects the position of a user (e.g., the person 102 wearing the drug delivery system 106). In one or more implementations, the location prediction engine 124 detects the location of the user based on at least two different types of sensor data 120. For example, the location prediction engine 124 detects the location of the user based on both GPS data and Wi-Fi information (e.g., SSID to which the user's computing device 108 is connected) or based on Wi-Fi information and voice data. In one or more implementations, the location prediction engine 124 uses the first sensor data to detect the location of the user and the second sensor data to confirm the location of the user. Alternatively or in addition, the location prediction engine 124 uses both types of sensor data to distinguish which of a plurality of candidate locations corresponds to the actual physical location of the user. For example, the location prediction engine 124 detects at least two candidate locations of the user based on the first sensor data. Based on the second sensor data, the location prediction engine 124 selects one of the at least two candidate locations as the location of the user (or eliminates all but one of the candidate locations).
In one or more implementations, the delivery device control system 110 pauses and/or resumes drug delivery based on the location of the user (e.g., the person 102 wearing the drug delivery system 106). For example, at a first time, the location prediction engine 124 determines or predicts that the user is present at the first location, and based on the determined or predicted presence of the user at the first location, the delivery device control system 110 pauses drug delivery, for example, by instructing the drug delivery system 106 to pause delivery of the drug to the person 102. Then, at a second, subsequent time, the location prediction engine 124 determines or predicts that the user is present at a second, different location (or that the user is away from the first location). Based on the determined or predicted presence of the user in the second location (or the user leaving the first location), delivery device control system 110 automatically (without user input) resumes drug delivery, for example, by instructing drug delivery system 106 to resume delivery of the paused drug to person 102.
Alternatively or in addition, delivery device control system 110 pauses and/or resumes drug delivery based on the user's activity (e.g., activity performed by person 102 wearing drug delivery system 106). For example, at a first time, delivery device control system 110 determines or predicts that the user is performing an activity and, based on the determined or predicted activity, pauses drug delivery, for example, by instructing drug delivery system 106 to pause delivery of the drug to person 102. Then, at a second, subsequent time, the delivery device control system 110 determines or predicts that the user is stopped performing the activity (or that the user is performing a different activity). Based on determining or predicting that the user is no longer performing an activity (or that the user is performing a different activity), delivery device control system 110 automatically (without user input) resumes drug delivery, for example, by instructing drug delivery system 106 to resume delivery of the paused drug to person 102. In at least one variation, the delivery device control system 110 also determines the activity performed by the user based at least in part on determining the location of the user. However, in different variations, the delivery device control system 110 determines the activity performed by the user, and not the location of the user.
In one or more implementations, the delivery device control system 110 determines when to suspend delivery of the drug based on the sensor data 120, rather than based on the analyte data 118. In other implementations, the delivery device control system 110 determines when to suspend delivery of the drug based at least in part on the analyte data 118. Also, in one or more implementations, delivery device control system 110 determines when to resume delivery of the drug based on sensor data 120, rather than based on analyte data 118. However, in other implementations, the delivery device control system 110 determines when to resume delivery of the drug based at least in part on the analyte data 118. Regardless of whether the delivery device control system 110 uses the analyte data 118 to determine when to resume drug delivery (and instructs the drug delivery system 106 accordingly), the delivery device control system 110 may use the analyte data 118 to determine the dose of drug to be delivered when delivery resumes.
In at least one implementation, rather than determining when to suspend delivery without user input, delivery device control system 110 suspends delivery based on receiving user input requesting to suspend delivery of a drug. In one or more implementations, such a request may be received via drug delivery system 106, for example, in response to a user selecting a graphical control displayed via a display device of drug delivery system 106 or selecting a physical control (e.g., button) of drug delivery system 106. In at least one variation, the user also specifies a pause period, i.e., how long delivery of the drug will be paused by the delivery device control system 110 before resuming delivery. Alternatively, the user does not specify a pause period as part of the request, and the delivery device control system 110 determines the pause period without requiring the user to enter the pause period. In one or more variations, the delivery device control system 110 automatically resumes delivery of the drug (without user input) in response to determining that the pause period has elapsed. In other words, after the pause period has elapsed, the delivery device control system 110 resumes delivery of the drug without receiving user input near the time at which delivery was resumed-the delivery device control system 110 resumes delivery based on the hold value specifying the pause period.
As described above, in one or more implementations, the delivery device control system 110 uses the sensor data 120 obtained via the IoT 114. It should be appreciated that the IoT 114 represents various sources capable of providing data describing the activity of the person 102 and/or the person 102, such as the activity of the person 102 as a user of one or more service providers or the activity of the person 102 in the real world (e.g., at home, in a car, at a workplace, in a gym, in a restaurant, or in other store, to name a few). For example, the IoT 114 may include various devices of the user, such as mobile phones, wearable devices, cameras, laptops, and the like. To this end, the IoT 114 may provide information regarding the user's interactions with those various devices, e.g., the location of those devices, the environment and/or physical conditions at the location where the devices are placed, interactions with web-based applications supported by the devices, interactions with health applications supported by the devices, photographs taken, communications with other users, online behavior, etc. IoT 114 may also include various other real-world items (e.g., shoes, clothing, sporting equipment, appliances, smart home devices, automobiles, etc.) configured with sensors to provide information describing behaviors, such as home items or locations with which to interact (e.g., shower, bath, or on bed), number of steps taken, force of stepping on the ground, stride length, temperature of the user (and other physiological measurements), temperature of the user's surroundings, type of food stored in the refrigerator, type of food removed from the refrigerator, driving habits, images of the user at different times of the day, etc. Such other real world items may also provide sensor data 120 describing the location of those items, the user's interactions with those items, the environmental and/or physical conditions at the location where the items are placed, and various other conditions.
In variations, the IoT 114 may also include third parties to the health monitoring platform 112, such as a medical provider (e.g., the medical provider of the person 102) and a manufacturer (e.g., the manufacturer of the drug delivery system 106 or one or more computing devices 108) capable of providing medical and manufacturing data, respectively, that may be utilized by the delivery device control system 110. Of course, the IoT 114 may include devices and sensors capable of providing a large amount of data for determining the location and/or activity of the person 102 without departing from the spirit or scope of the described technology.
In one or more implementations, the delivery device control system 110 also utilizes the resources of the health monitoring platform 112 in conjunction with automatic suspension and resumption of drug delivery. For example, the health monitoring platform 112 may be configured to store data, such as analyte data 118, sensor data 120 (e.g., data generated by various sensors and data generated based on determinations made using the data generated by the various sensors), instructions 122, user profile data associated with a user (e.g., person 102), and/or user profile data associated with one or more other users of a user population (not shown). The environment 100 includes user data 126 that represents various data obtained and stored by the health monitoring platform 112 regarding one or more of these users. Although data is stored regarding one or more users, user data 126 may be obfuscated using one or more techniques such that the personal identification information of the user associated with the data may remain anonymous in various scenarios in which the data is used. In the illustrated environment 100, user data 126 is shown as being stored in a storage device 128. The storage 128 may represent one or more databases or other storage devices included as part of or otherwise accessible by the health monitoring platform 112. The storage 128 is capable of storing user data 126 and various other data in accordance with the described techniques.
For example, the user data 126 may include any combination of the data discussed immediately above and other data discussed above and below. For example, the user data 126 may include historical data associated with one or more users, such as historical analyte data 118, historical sensor data 120, determinations made based on historical analyte data 118 and/or historical sensor data 120, received user inputs, and the like. In at least one implementation, such historical data may describe the user's condition and/or the user's behavior, including, for example, activities that the user previously performed at a location, activities that other users now performed at the location, and attributes of the activities performed, such as time of activity, type of location, whether the user provided input to pause drug delivery, whether the user provided input to resume drug delivery, the amount of time that drug delivery was paused before resuming, and so forth.
In one or more implementations, the health monitoring platform 112 includes a monitoring service 130. The monitoring service 130 may be used alone or in combination with the delivery device control system 110. For example, the monitoring service 130 may provide one or more web-based health-related services to the user via the network 116 and its computing device 108 (e.g., mobile application). Health monitoring platform 112 may include or have access to various computing resources, such as processing, storage, and virtual resources. These resources may be used, for example, to train, maintain, and/or deploy algorithms (e.g., machine learning algorithms) that may generate predictions associated with health monitoring using a large amount of data collected about the people 102 and users of the user population. Thus, the monitoring service 130 may utilize these resources to perform algorithms and implement other functions to provide web-based services to users via their devices.
Notably, one or more such algorithms or functions may require an amount of computing resources that exceeds the resources of typical personal computing devices (e.g., mobile phones, laptops, tablet devices, and wearable devices, to name a few). However, the health monitoring platform 112 may include or otherwise have access to at least a threshold amount of resources, such as cloud storage, server devices, virtualized resources, etc., required to operate such algorithms and provide such functionality. The health monitoring platform 112 may include a variety of resources that the computing device 108 may utilize via the monitoring service 130 to automatically suspend and resume drug delivery and provide notification regarding doing so. In the context of continuously measuring an analyte such as glucose and obtaining analyte data describing such measurements, consider the following discussion of FIG. 2.
Fig. 2 depicts an example 200 of a specific implementation of analyte monitoring device 104 in more detail. In particular, the illustrated example 200 includes a top view and a corresponding side view of the analyte monitoring device 104. It should be appreciated that the analyte monitoring device 104 may be varied in implementation in a variety of ways in accordance with the following discussion without departing from the spirit or scope of the described technology.
In this example 200, the analyte monitoring device 104 is illustrated as including an analyte sensor 202 (e.g., a glucose sensor) and a sensor module 204. Here, analyte sensor 202 is depicted in a side view as having been subcutaneously inserted into skin 206 (e.g., of person 102). The sensor module 204 is approximately a dashed rectangle in top view. In the illustrated example 200, the analyte monitoring device 104 further includes a transmitter 208. The use of the dashed rectangle of the sensor module 204 indicates that it may be housed in the transmitter 208 or otherwise implemented within the housing of the transmitter. Antennas and/or other hardware for enabling the transmitter 208 to generate signals for transmitting data to the drug delivery system 106 and/or the computing device 108, e.g., via a wireless connection, may also be housed or otherwise implemented within the housing of the transmitter 208. In this example 200, the analyte monitoring device 104 further includes an adhesive pad 210.
In operation, the analyte sensor 202, the bond pad 210, can be assembled to form an application assembly, wherein the application assembly is configured to be applied to the skin 206 such that the analyte sensor 202 is subcutaneously inserted as depicted. In such a scenario, the emitter 208 may be attached to the component via an attachment mechanism (not shown) after the component is applied to the skin 206. Alternatively, the emitter 208 may be incorporated as part of the application assembly such that the analyte sensor 202, the adhesive pad 210, and the emitter 208 (with the sensor module 204) may all be applied to the skin 206 at the same time. In one or more implementations, the application assembly is applied to the skin 206 using a separate sensor applicator (not shown). Unlike the finger stick required for conventional blood glucose meters, user initiated application of analyte monitoring device 104 with a sensor applicator is almost painless and does not require blood drawing. Furthermore, automatic sensor applicators typically enable the person 102 to subcutaneously embed the analyte sensor 202 into the skin 206 without the assistance of a clinician or healthcare provider.
The analyte monitoring device 104 may also be removed by peeling the adhesive pad 210 away from the skin 206. It should be understood that the analyte monitoring device 104 and its various components as shown are merely one example form factor, and that the analyte monitoring device 104 and its components may have different form factors without departing from the spirit or scope of the described technology.
In operation, analyte sensor 202 is communicatively coupled to sensor module 204 via at least one communication channel, which may be a wireless connection or a wired connection. Communication from analyte sensor 202 to sensor module 204 or from sensor module 204 to analyte sensor 202 may be accomplished actively or passively, and may be continuous (e.g., analog) or discrete (e.g., digital).
Analyte sensor 202 may be a device, molecule, and/or chemical that changes or causes a change in response to an event that is at least partially independent of analyte sensor 202. The sensor module 204 is implemented to receive an indication of a change in the analyte sensor 202 or a change caused by the analyte sensor 202. For example, the analyte sensor 202 may include a glucose oxidase that reacts with glucose and oxygen to form hydrogen peroxide that can be electrochemically detected by the sensor module 204, which may include electrodes. In this example, analyte sensor 202 may be configured to or include a glucose sensor configured to detect an analyte in blood or interstitial fluid indicative of a glucose level using one or more measurement techniques. In one or more implementations, the analyte sensor 202 may also be configured to detect analytes in blood or interstitial fluid that are indicative of other markers (such as lactate levels, ketones, ionic potassium), which may improve the accuracy of identifying or predicting glucose-based events (e.g., hyperglycemia or hypoglycemia). Additionally or alternatively, analyte monitoring device 104 may include additional sensors and/or architecture of analyte sensor 202 to detect those analytes indicative of other markers.
In another example, the analyte sensor 202 (or an additional sensor of the analyte monitoring device 104—not shown) may include a first electrical conductor and a second electrical conductor, and the sensor module 204 may electrically detect a change in potential across the first electrical conductor and the second electrical conductor of the analyte sensor 202. In this example, the sensor module 204 and the analyte sensor 202 are configured as thermocouples such that the change in potential corresponds to a temperature change. In some examples, the sensor module 204 and the analyte sensor 202 are configured to detect a single analyte, such as glucose. In other examples, the sensor module 204 and analyte sensor 202 are configured to detect a variety of analytes, such as sodium ions, potassium ions, carbon dioxide, and glucose, using a variety of different sensing modes. Alternatively or additionally, analyte monitoring device 104 includes a plurality of sensors to detect not only one or more analytes (e.g., sodium ions, potassium ions, carbon dioxide, glucose, and insulin), but also one or more environmental conditions (e.g., temperature, moisture, movement). Thus, the sensor module 204 and the analyte sensor 202 (as well as any additional sensors) may detect the presence of one or more analytes, the absence of one or more analytes, and/or a change in one or more environmental conditions. As described above, the analyte monitoring device 104 may be configured to generate data describing a single analyte (e.g., glucose) or multiple analytes.
In one or more implementations, the sensor module 204 can include a processor and memory (not shown). By utilizing a processor, the sensor module 204 may generate analyte measurements 212 based on communication with the analyte sensor 202 indicating the changes discussed above. Based on the above-described communication from analyte sensor 202, sensor module 204 is further configured to generate a communicable data packet including at least one analyte measurement 212. In this example 200, the analyte data 118 represents these data packets. Additionally or alternatively, the sensor module 204 may configure the analyte data 118 to include additional data including, for example, supplemental sensor information 214. Supplemental sensor information 214 may include a sensor identifier, a sensor status, a temperature corresponding to analyte measurement 212, measurements of other analytes corresponding to analyte measurement 212, and the like. It should be appreciated that supplementing the sensor information 214 may include supplementing a variety of data of the at least one analyte measurement 212 without departing from the spirit or scope of the described technology.
In implementations where analyte monitoring device 104 is configured for wireless transmission, transmitter 208 may transmit analyte data 118 as a data stream to a computing device. Alternatively or additionally, the sensor module 204 may buffer the analyte measurements 212 and/or the supplemental sensor information 214 (e.g., in a memory of the sensor module 204 and/or other physical computer-readable storage medium of the analyte monitoring device 104), and cause the transmitter 208 to transmit the buffered analyte data 118 at various regular or irregular intervals (e.g., time intervals (about every second, about every thirty seconds, about every minute, about every five minutes, about every hour, etc.), storage intervals (when the buffered analyte measurements 212 and/or the supplemental sensor information 214 reach a threshold data amount or measurement amount), etc.). It should be appreciated that in implementations, the analyte monitoring device 104 may differ from the examples described above in a variety of ways without departing from the spirit or scope of the described technology.
Having discussed one example of an analyte monitoring device, consider now the following discussion of one example drug delivery system.
Fig. 3 depicts an example implementation 300 of drug delivery system 106 in more detail.
In the example implementation 300, the drug delivery system 106 includes a drug pump 302 and an infusion set 304. Although the infusion set 304 is depicted as having a tubing 306 connected to the drug pump 302, in one or more implementations, the infusion set 304 may be tubing-less. Although depicted as a pump in this example, drug delivery system 106 may be configured in various ways in accordance with the described techniques, examples of which include a pen or a set of pens, an inhaler, a patch, one or more syringes, and a mouthpiece.
Broadly, the infusion set 304 is a device configured to deliver a drug (pumped by the drug pump 302 to the infusion set 304) subcutaneously into the person 102 for absorption by the blood flow of the person 102. In this way, the body of the person 102 may use the delivered drug to maintain the equilibrated analyte level within a target range, for example, for analyte measurement. In one or more implementations, the infusion set 304 includes a cannula that is subcutaneously inserted into the skin, such as at the infusion site 308 of the person 102 in the example implementation 300. Thus, the infusion set 304 may administer a dose of medication through the skin of the person 102 in, for example, a continuous manner and at a programmable rate. As discussed herein, for example, a basal dose and/or bolus dose of insulin may be administered through the skin of the person 102 via the infusion set 304. Alternatively or in addition, the drug delivery system 106 may administer the drug to the person 102 based on user input (e.g., input received via a user interface of one or more doses of the drug to be delivered and/or input received via the computing device 108).
As shown, the infusion set 304 includes an adhesive pad for adhering the device to the person 102 for a period of time. In one or more implementations, the infusion set 304 is applied to the infusion site 308 using a separate applicator (not shown). In operation, the applicator may insert the cannula of the infusion set 304 into the skin of the person 102 at the infusion site 308, and also affix an adhesive pad to the infusion site 308 to affix the infusion set 304 to the person 102 during use. In at least some implementations, the infusers may be disposable such that they are designed for removal after a prescribed and/or recommended period of time and for replacement with a new infuser applied to person 102 and attached to drug pump 302. In any event, the drug pump 302 is configured to deliver a drug dose to the person 102 through an infusion set (such as the illustrated infusion set 304).
In the example implementation 300, the drug pump 302 includes a communication module 310, a drug delivery control 312, a drug reservoir 314, a display module 316, a security module 318, and a battery 320. In implementations, the drug pump 302 may be configured in various ways, such as with some of these components, while other components are housed or otherwise implemented in a separate device. Alternatively or additionally, drug pump 302 may include additional or alternative components without departing from the spirit or scope of the techniques described herein.
The communication module 310 is configured to transmit data to and receive data from other devices, such as the computing device 108 and/or the delivery device control system 110 (which may be at least partially included at the computing device 108 in one or more variations). The communication module 310 may establish or otherwise facilitate establishing communication links or channels with those other devices the links or channels may be configured in a variety of ways including, but not limited to, bluetooth (e.g., bluetooth low energy link), near Field Communication (NFC), 5G or other cellular and Wi-Fi, such communicative coupling enables the drug pump 302 to securely communicate over different networks (such as network 116) and/or within a closed-loop system including, for example, the analyte monitoring device 104 and the at least one computing device 108, to name a few.
Once the communicative coupling is established, the communication module 310 may cause data to be transmitted over the established coupling and/or may receive data from other devices over the established coupling. Additionally or alternatively, the communication module 310 may be configured to establish a connection over a wired communication channel (such as via a USB wire connected to the drug pump 302 and another device), and also configured to transmit and/or receive data over such wired coupling. The communication module 310 may be configured in various ways to enable the drug pump 302 to communicate with other devices.
As one example, the communication module 310 enables the drug pump 302 to receive instructions 122 and/or other instructions from the computing device 108 and/or the delivery device control system 110 for controlling the delivery of a drug to the person 102. For example, the communication module 310 enables the drug pump 302 to receive instructions that instruct the drug pump 302 to suspend delivery of a drug to the person 102, subsequently resume delivery of the drug to the person 102, deliver an amount of the drug to the person 102 determined based in part on an amount of time to suspend delivery of the drug, and so forth. Alternatively or in addition, the communication module 310 enables the drug pump 302 to receive instructions regarding the basal rate of insulin delivery to the person 102, updating the basal rate of insulin, delivering bolus doses of insulin (e.g., bolus amounts over a limited time) to the person 102, and the like. The computing device 108 may send various communications to the drug delivery system 106 for controlling drug delivery without departing from the spirit or scope of the techniques described herein.
Drug delivery control 312 represents any hardware, software, and/or mechanical component of drug pump 302 that causes drug to be pumped (or otherwise extracted) from drug reservoir 314 such that drug flows through infusion set 304 and into person 102. In addition, the drug delivery control 312 is also configured to cause the drug to be pumped or otherwise extracted from the drug reservoir 314 according to drug dosage instructions (e.g., instructions 122 from the delivery device control system 110) that specify suspension and/or resumption of one or more delivery of the drug. The drug reservoir 314 is configured to hold an amount of drug that may be delivered subcutaneously via the infusion set 304 by utilizing the function of the drug pump 302. The drug reservoir 314 may be replaceable or otherwise configured such that the quantity of drug may be replenished into the drug reservoir 314. The drug reservoir 314 may be configured in a variety of ways (e.g., different shapes, different materials, differently removable, etc.) without departing from the spirit or scope of the described technology.
The display module 316 is configured to cause information to be displayed via a display device 322 of the drug pump 302. The display module 316 may generate one or more user interfaces for display via the display device 322. For example, the display module 316 may display a user interface via a display device for establishing a wireless connection with the computing device 108. Additionally or alternatively, the display module 316 may cause the display device 322 to display analyte measurements (e.g., in a manner similar to displaying analyte measurements via a health monitoring application of the computing device 108), trend arrows (e.g., regarding trends identified in analyte measurements), alarms (e.g., drug delivery paused, drug delivery is or has resumed, regarding analyte measurements, other physiological conditions, operability of the drug delivery system 106, operability of components of the delivery device control system 110, status of wireless connection with the computing device 108, etc.), pump setup interfaces, indications of communication ranges out of different devices (e.g., the computing device 108 or the analyte monitoring device 104), etc. Accordingly, the display module 316 may cause various information to be displayed via the display device 322 of the drug pump 302.
The safety module 318 is configured to provide one or more protective measures to control the delivery of the drug so that the delivery is not harmful, in other words, so that the drug is safely delivered. For example, the security module 318 may include or otherwise enforce delivery limits, such as maximum and minimum delivery rates over different time periods. These limitations are effective to prevent erroneous delivery instructions from delivery device control system 110 from injuring person 102, such as when errors in transmitting instructions affect their content, or when errors in predictions made by one or more machine learning models dangerously affect those instructions. For example, the safety module 318 may limit the amount or rate of drug delivered by the drug pump 302 to a threshold amount or threshold rate even though the instructions received from the delivery device control system 110 indicate that the drug pump 302 delivers more than the threshold amount. Similarly, the safety module 318 may also prevent the drug pump 302 from delivering less than a threshold amount of drug or delivering drug at less than a threshold rate, even if the instructions received from the computing device 108 indicate that the drug pump 302 delivers less than a threshold amount.
Further, the safety module 318 is configured to continue operating the drug pump 302 in the absence of instructions from the delivery device control system 110 or the computing device 108, such as in the absence of instructions describing how much drug to deliver and when to deliver. For example, the safety module 318 may be configured to continue to operate the drug pump 302 to deliver the drug to the person 102 when the delivery device control system 110 is out of communication range. The security module 318 may access logic, default settings, or settings entered as part of a setup process that controls how much drug the drug pump 302 is to deliver when no instruction is received from the delivery device control system 110, to name a few. The security module 318 may perform various additional or different protective measures to ensure that the amount of drug delivered is not harmful to the person 102.
The battery 320 is configured to provide power for operating the drug pump 302, such as powering the communication module 310 to send and receive data, powering the drug delivery control 312 to cause drug to be delivered from the drug reservoir 314 to the person 102 via the infusion set 304, powering the display module 316 to display information via the display device 322, and so forth. The battery 320 may be rechargeable (e.g., via a USB charging port or wirelessly) or replaceable. It should be appreciated that the battery 320 may be configured in a variety of ways.
Although not depicted, the drug delivery system 106 or another device (e.g., analyte monitoring device 104) may be configured with a drug sensor (e.g., an insulin sensor). Such a drug sensor may be applied to skin or subcutaneous insertion to measure systemic levels of a drug (e.g., in the human 102). Thus, the drug sensor may be included as part of the infusion set 304, the analyte monitoring device 104, or may be applied separately. In any event, such a sensor may be used in conjunction with the safety module 318 and/or with the dose prediction function. In this way, the drug measurements generated using the drug sensor may be used to prevent or detect an overdose of the drug, e.g., to prevent a person receiving insulin from experiencing a hypoglycemic episode. For example, if the safety module 318 detects that the drug level exceeds a predetermined threshold, the safety module 318 may stop drug delivery by the drug pump 302 based on the drug measurement. Based on the drug measurements, the delivery device control system 110 may also or alternatively send instructions to the drug delivery system 106 instructing it to stop or temporarily suspend drug delivery. In one or more implementations, the security module 318 and/or the computing device 108 may also trigger an alarm if the drug level exceeds a predetermined threshold. Physiologically, different thresholds may be determined for different people based on their drug sensitivity (e.g., insulin sensitivity) so that the above-described shut down, alarm, or cessation of drug delivery may be triggered for different drug levels of different people.
Having considered examples of environments and example devices, consider now a discussion of some examples of details of techniques for automatically suspending and resuming drug delivery in accordance with one or more implementations.
Automatic suspension and resumption of drug delivery
Fig. 4 depicts an example 400 of a system for suspending and resuming delivery of a drug based on a request.
In the illustrated example 400, the system includes a delivery device control system 110. Delivery device control system 110 is depicted as obtaining a request 402 to pause the delivery of a drug, such as pausing the delivery of a drug via drug delivery system 106. In this example, the request 402 includes a pause period 404, however, in a variant, the request may not include the pause period 404. Instead, the delivery device control system 110 may determine the pause period 404 in one or more variations.
In one or more implementations, the request 402 is responsive to or otherwise based on receiving user input. For example, user input may be received via a user interface of the drug delivery system 106 or the computing device 108 in connection with one or more controls (e.g., buttons, menus, fields, etc.) that may be used to request suspension of delivery of the drug. In a variation, user input may be received to specify a pause period 404, such as a pause period associated with these same controls or one or more additional controls. In response to receiving request 402 (e.g., based on user input), delivery device control system 110 temporarily suspends delivery of the drug.
In this particular example, the delivery device control system 110 includes a pause delivery engine 406, a resume delivery engine 408, and a drug quantification engine 410. Although the delivery device control system 110 is depicted as having these components, in variations, the delivery device control system 110 includes more, fewer, or different components without departing from the spirit or scope of the described technology. Thus, the functions described above and below may be performed by one or more components other than those described herein and/or by the delivery device control system 110.
In accordance with the described techniques, pause delivery engine 406 determines when to pause the delivery of the drug to the user. In this example, for example, the pause delivery engine 406 determines to pause the delivery of the drug in response to receiving the request 402, e.g., the pause delivery engine 406 determines to pause the delivery of the drug in substantially real time after receiving the request 402 or after a certain amount of time after receiving the request 402. Alternatively or in addition, the pause delivery engine 406 is configured to process the request 402, extract a predetermined time (not shown) specified in the request 402, and determine to pause delivery at the specified time.
The pause delivery engine 406 is also configured to output pause delivery instructions 412. In one or more implementations, the pause delivery engine 406 or the delivery device control system 110 communicates pause delivery instructions 412 to the drug delivery system 106. Broadly, pause delivery instructions 412 instruct drug delivery system 106 to pause the delivery of the drug at a time determined by pause delivery engine 406. In one or more implementations, the pause delivery instructions 412 cause the drug delivery system 106 to pause delivery of the drug substantially immediately upon receipt of the instructions. Alternatively or in addition, pause delivery instructions 412 include a specified pause delivery time such that drug delivery system 106 pauses delivery of the drug at the specified time.
Resume delivery engine 408 is depicted as receiving as input a pause period 404. In one or more implementations, the resume delivery engine 408 determines when to resume delivery of the drug to the user. In this example, for example, resume delivery engine 408 determines a time to resume delivery of the drug to the user based on pause period 404. In one or more variations, resume delivery engine 408 calculates a time to resume drug delivery based on the time of drug delivery suspension and based on the amount of time of suspension period 404, e.g., resume delivery engine 408 adds suspension period 404 to the time of drug delivery suspension. Thus, in one or more implementations, in addition to receiving the pause period 404, the resume delivery engine 408 also receives (or otherwise accesses) a time of the drug delivery pause.
In accordance with the described techniques, resume delivery engine 408 outputs resume delivery instructions 414 based on the determined time to resume drug delivery, which may also be based on pause period 404 as described above. In one or more implementations, the resume delivery engine 408 or the delivery device control system 110 communicates resume delivery instructions 414 to the drug delivery system 106. Broadly, resume delivery instructions 414 instruct drug delivery system 106 to resume delivery of the drug at a time after the drug delivery suspension time. In one or more implementations, resume delivery instructions 414 cause drug delivery system 106 to substantially resume delivery of the drug upon receipt of the instructions. Alternatively or in addition, resume delivery instructions 414 include a specified resume delivery time such that drug delivery system 106 resumes drug delivery at the specified time (e.g., after delivery of the drug has been paused for pause period 404).
In the illustrated example 400, the resume delivery engine 408 is also depicted as outputting a resume delivery indication 418. In one or more implementations, resume delivery indication 418 may correspond to resume delivery instruction 414, or it may be a different communication. In addition, the drug quantification engine 410 is depicted as receiving a resume delivery indication 418. Broadly, resume delivery indication 418 indicates to drug quantification engine 410 that drug delivery system 106 is resuming delivery of a drug to a user (e.g., person 102). Based on receiving resume delivery indication 418, drug delivery engine 410 determines a dose of drug to be delivered to the user. Drug dose instructions 420 correspond to the determined dose and instruct drug delivery system 106 to deliver the determined dose after it resumes delivery of the drug, e.g., according to resume delivery instructions 414. In short, resume delivery instructions 414 indicate when drug delivery system 106 resumes delivery of the drug (e.g., time to resume delivery), and drug dosage instructions 420 indicate how much drug delivery system 106 delivers (e.g., amount delivered over time). Although not depicted in the subsequent illustrations, the drug quantification engine 410 may be used in various implementations to instruct the drug delivery system 106 as to how much drug to deliver before suspending delivery of the drug and/or how much drug to deliver after resuming delivery of the drug.
In one or more implementations, the drug quantification engine 410 determines the dose delivered at the time of resumption of delivery based on various data including one or more of the analyte data 118, the pause period 404, the time at which delivery was paused, the subsequent time at which delivery was resumed, and the sensor data 120, to name a few. The drug quantification engine 410 may also determine the dose to be delivered based on a "higher level" determination made from such data, such as one or more activities performed by the user while suspending the delivery of the drug. This is because the activity (such as exercise) performed by the user during the suspension of drug delivery can affect how much drug should be delivered to the user to maintain the proper analyte level. The medication dosing engine 410 may also determine a dose based on historical data about the user and/or historical data of at least one other user associated with one or more activities performed during a delivery pause. The drug quantification engine 410 may determine the delivered dose based on various data without departing from the spirit or scope of the described technology.
Fig. 5 depicts an example 500 of a system for automatically suspending delivery of a drug based on sensor data. The illustrated example 500 includes a delivery device control system 110. In this example 500, the delivery device control system 110 automatically pauses delivery of the drug based on the sensor data 120. For example, delivery device control system 110 pauses delivery of the drug based on sensor data 120 and without receiving user input explicitly specifying to pause drug delivery. This is in contrast to the previously discussed example 400 of receiving a request 402 to pause delivery.
In this example 500, the delivery device control system 110 is depicted as obtaining sensor data 120. In accordance with the described techniques, the delivery device control system 110 receives sensor data 120 from various sources 502, examples of which include Global Positioning System (GPS) data, wi-Fi information (e.g., service Set Identifier (SSID)), bluetooth Low Energy (BLE) information, data generated using a cellular antenna (e.g., long Term Evolution (LTE)), microphone data (e.g., sound data), accelerometer data, gyroscope data, magnetometer data, barometer data, ambient or internal temperature data (e.g., generated using a temperature sensor), light data (e.g., captured using a camera of the device), heart rate data (e.g., generated by a smartphone and/or smartwatch), proximity data (e.g., between devices), humidity data, analyte data (one or more different analytes from different sources or different data regarding the same analyte), and drug data, to name a few. Additional examples of sensors 120 from various sources 502 include, but are not limited to, measurements of various detected signals (e.g., biopotential measurements such as Electrocardiogram (ECG), electromyogram (EMG), or electroencephalogram (EEG)), accelerations experienced by a person at a location where the analyte enhancing wearable device is worn, and optical signals such as photoplethysmogram (PPG) detecting changes in blood volume, measurements of various physiological conditions (e.g., perspiration, temperature, heart rate, oxygen saturation (SpO2), or indications of detected events (e.g., exceeding or falling below a threshold, detecting the presence or absence of a particular compound), just to name a few examples.
In this example 500, the delivery device control system 110 includes a location prediction engine 124, an activity prediction engine 504, and a pause delivery engine 406. As described above and below, the delivery device control system 110 may include more, fewer, or different components in variations, and the functions discussed herein may be performed by one or more components different than those described, without departing from the spirit or scope of the described technology.
In one or more implementations, the delivery device control system 110 determines when to suspend delivery of the drug based on predicting or otherwise detecting a location 506 of the user and predicting or otherwise detecting an activity 508 being performed by the user. In one or more implementations, the delivery device control system 110 determines when to suspend delivery based on the location 506. Alternatively or in addition, delivery device control system 110 determines when to suspend delivery based on activity 508. In one or more implementations, the activity 508 is determined based on the location 506, while in at least one other implementation, the activity is determined without using the user's location 506. In the illustrated example 500, the position prediction engine 124 and the position 506 are depicted with dashed lines to indicate that they are optional in at least one variation.
In the context of the illustrated example 500, the location prediction engine 124 determines or otherwise predicts a location 506 of a user (e.g., the person 102) based on the sensor data 120. The position prediction engine 124 outputs a position 506. The activity prediction engine 504 determines or otherwise predicts an activity 508 of the user, such as an activity the user is performing at the current time. Examples of activities include, but are not limited to, eating, sleeping, exercising (e.g., aerobic, anaerobic, partially aerobic and partially anaerobic, high intensity intermittent training, running, rowing, hiking, cycling, weightlifting, yoga, prayer lifting, sports, etc.), working (e.g., potentially stress), bathing or showering, watching a movie, watching television, attending to an activity (e.g., sporting event or concert), dancing, reading, cleaning, taking care of a child or driving, to name a few.
As described above, the activity prediction engine 504 optionally determines the user's activity 508 based on the user's location 506. For example, the presence of a user in a gym, shower, bed, and/or chair sitting in a workspace may provide information regarding the activity 508 being performed. Alternatively or in addition, activity prediction engine 504 determines activity 508 of the user based on sensor data 120, such as based on heart rate data (indicative of exercise).
Based on activity 508, pause delivery engine 406 determines to pause delivery of the drug to the user. In one or more variations, this includes pausing the time of delivery. In addition, pause delivery engine 406 outputs pause delivery instruction 412 to pause delivery at that time, for example. For example, pause delivery engine 406 outputs pause delivery instructions 412 to drug delivery system 106, and the instructions cause drug delivery system 106 to pause delivery of the drug to the user. Pause delivery instruction 412 is one example of instruction 122.
In terms of how the location prediction engine 124 predicts the user's location 506, in one or more implementations, the location prediction engine 124 predicts the location 506 based on at least two types of sensor data (e.g., first sensor data and second sensor data). For example, the location prediction engine 124 predicts the location 506 based on both GPS data and Wi-Fi information (e.g., the S SID of a network accessible to the computing device 108), based on both Wi-Fi information and sound data, based on both Wi-Fi information and light data, based on both Wi-Fi information and heart rate data, to name a few. It should be appreciated that the location prediction engine 124 may be configured to receive and process various combinations of at least two types of data described above and below as inputs to predict the location 506 of the user. Of course, in one or more implementations, the location prediction engine 124 may use more than two types of data (e.g., more than the first sensor data and the second sensor data) to predict the location 506 of the user.
In at least one implementation, the location prediction engine 124 predicts a location 506 of a user (e.g., the person 102) based on a location of the computing device 108 associated with the user. For example, the location prediction engine 124 predicts the location 506 of the user based on the location of the user's mobile phone or smart watch. In such implementations, this is based on the assumption that the user is in close proximity to the associated computing device, e.g., the computing device is worn by the user or carried in the user's clothing or accessories. In other words, the location prediction engine 124 predicts (or detects) the location of the user's computing device 108 (e.g., the user's mobile phone or smart watch) and then attributes the location of the device to the user. Alternatively or in addition, the location prediction engine 124 predicts (or detects) the location of the user's computing device 108 (e.g., the user's mobile phone or smart watch) and then uses sensor data 120 (e.g., proximity data, infrared data, temperature data, etc.) obtained from the computing device 108 (or other sources) to further refine the location and/or determine the location of the user relative to the computing device 108. This may be the case when the computing device 108 is not worn by the user or is not "on" the user, such as when the user is sleeping or showering. In one or more implementations, the position prediction engine 124 generates a "coarse" prediction of the position 506 using the first sensor data and generates a "fine" prediction of the position 506 using the second sensor data (and based on the coarse position prediction).
The location prediction engine 124 may be configured in a variety of ways without departing from the spirit or scope of the described technology. For example, the position prediction engine 124 may be configured as or include one or more machine learning models. Alternatively or in addition, the location prediction engine 124 includes or has access to a mapping of locations (e.g., restaurants, gyms, houses, shops, roads and other businesses) to geographic coordinates such that given precise geographic coordinates, the location prediction engine 124 can attribute the presence of a user to a location according to the mapping.
In at least one implementation, the first portion of the sensor data 120 may not be suitable for enabling the location prediction engine 124 to predict geographic coordinates of the user with sufficient accuracy to distinguish between at least two adjacent locations. Conversely, the first portion of the sensor data 120 may be adapted to predict an area (e.g., a radius around a point) in which the user may be located such that the area includes at least two candidate locations. Thus, in one or more implementations, the position prediction engine 124 uses at least a second portion of the sensor data 120 to distinguish between candidate positions and select the position 506 from a plurality of candidate positions. For example, in a scenario where the bedroom and bathroom are adjacent to each other, the position prediction engine 124 uses the second portion of the sensor data 120 to narrow down the candidate position to select the bedroom or bathroom. This is notable because activities in which the user participates at different locations may be associated with suspending the delivery of a medication (e.g., bathing in a bathroom) or delivering a medication (e.g., sleeping in a bedroom). Similarly, consider the example where both restaurants and gyms are located in a shopping mall along a street. In this case, it is important to be able to determine whether the user is in a gym (and exercising) or in a restaurant (and eating) because insulin may need to be suppressed if the user is exercising and increased if the user is eating.
To the extent that the activity prediction engine 504 predicts an activity 508 in which the user is participating or may be participating, in one or more implementations, the activity prediction engine 504 determines and outputs the activity 508 based on the location 506. In one or more variations, the activity prediction engine 504 predicts the activity 508 based on the predicted location 506 without using other sensor data 120 (as compared to determining the location 506) or user interactions to confirm the activity 508. In at least one other variation, activity prediction engine 504 predicts activity 508 based on predicted location 506 and at least one other type of data (e.g., sensor data 120) and/or based on data describing user interactions with the device. Examples of such sensor data 120 include sound data (e.g., indicating a sound confirming that the user is sleeping), light data (e.g., indicating a dark location associated with a higher likelihood that the user is sleeping), accelerometer data (e.g., indicating a location of a device on a bedside table associated with a higher likelihood that the user is sleeping), and so forth. Examples of such user interactions include user interactions that confirm predicted activities 508, input activities, and the like. As described above, in one or more implementations, the location prediction engine 124 predicts the activity 508 based on the sensor data 120 without receiving the predicted or otherwise determined location 506.
It should be appreciated that in some configurations, as the user's location changes, the location prediction engine 124 detects the user's location 506 in real-time (or substantially in real-time) and/or the activity prediction engine 504 predicts the activity 508 being performed by the user in real-time (or substantially in real-time). Notably, not all activities are associated with suspending drug delivery. Thus, in one or more implementations, pause delivery engine 406 generates pause delivery instruction 412 only if predicted activity 508 is associated with pausing drug delivery (and delivery of the drug has not been paused).
In one or more implementations, the pause delivery engine 406 is configured to receive the activity 508 (and in some implementations the active state) as input and output a machine learning model of the pause delivery instruction 412. In such implementations, pause delivery engine 406 may be trained using training data that pairs an activity (and in some implementations an activity state) with a tag that indicates that a drug is delivered while the activity is being performed or a tag that indicates that a drug is not being delivered while the activity is being performed. For example, the machine learning model may be exposed to an activity (e.g., receive the activity as input) and attempt to output an indication of whether or not to deliver the drug during the activity. The system may then compare the output to tags in the training data paired with the input. Based on the comparison, the internal weights of the machine learning model may be adjusted. For example, if the output matches a paired tag in the training data, the weights may be adjusted (e.g., emphasized) to encourage output during future iterations. However, if the output does not match a paired tag in the training data, the weights may be adjusted to block the output during future iterations. Thus, the machine learning model may be trained through multiple iterations.
Alternatively or in addition, pause delivery engine 406 may obtain an indication of whether activity 508 corresponds to an activity during which a drug is delivered or an activity during which a drug is not delivered, such as a mapping from activity (and in some implementations, status) to delivery or not delivery of a drug. For example, the library may include a mapping that maps different activities to delivery or non-delivery of drugs. For example, the information may be stored in a database. In one or more implementations, the mapping may be approved by one or more clinicians.
This information may be entered into the system (e.g., into a database) and maintained. In one or more implementations, such mapping may be maintained in a computer-readable storage medium of the user's computing device 108 (e.g., the user's mobile phone). Alternatively or in addition, the mapping may be maintained remotely from the computing device 108, such as in a database associated with the delivery device control system 110 and/or the health monitoring platform 112. Either or both of the remote map and the local map may be updated as new activity is added. In one or more implementations, the mapping may be personalized to the user, for example, to map activities to historical actions of the user to pause or resume drug delivery. In such implementations, the mapping may be provided by the user (e.g., via user input to the user's computing device), the healthcare provider (e.g., via a healthcare provider portal), or determined by the system based on the sensor data.
Fig. 6 depicts an example 600 of a system for automatically resuming delivery of a drug based on sensor data. The illustrated example 600 includes a delivery device control system 110.
In this example 600, the delivery device control system 110 automatically resumes delivery of the drug based on the sensor data 120. For example, delivery device control system 110 resumes delivery of the drug based on sensor data 120 and without receiving user input explicitly resuming delivery of the drug. This is in contrast to the previously discussed example 400, in which the request 402 to pause delivery includes a pause period 404, such that the time to resume delivery can be determined based on the pause period 404.
In this example 600, the delivery device control system 110 is depicted as obtaining sensor data 120, as described above, the delivery device control system 110 may obtain sensor data from various sources 502. In addition, the delivery device control system 110 includes a location prediction engine 124, an activity prediction engine 504, and a resume delivery engine 408. As described above and below, the delivery device control system 110 may include more, fewer, or different components in variations, and the functions discussed herein may be performed by one or more components different than those described, without departing from the spirit or scope of the described technology.
In one or more implementations, the delivery device control system 110 determines when to resume delivery of the drug based on predicting or otherwise detecting a subsequent location 602 of the user and predicting or otherwise detecting a subsequent activity 604 being performed by the user. In one or more implementations, the subsequent location 602 is different from the location 506 based on which drug delivery is automatically paused. In one example, for example, location 506 corresponds to a shower, and subsequent location 602 corresponds to a location different from the shower, e.g., not a shower, a washroom, or a bedroom. In another example, location 506 corresponds to a gym, and subsequent location 602 corresponds to a location different from the gym, e.g., a parking lot of the gym, a changing room in the same facility as the gym, or on a road off the gym.
Similarly, in one or more implementations, the subsequent activity 604 differs from the activity 508 based on which drug delivery is automatically paused. In one example, for example, activity 508 corresponds to a shower, and subsequent activity 604 corresponds to an activity different from the shower, e.g., not showering, combing, or dressing. In one example, for example, activity 508 corresponds to playing basketball, and subsequent activity 604 corresponds to an activity other than playing basketball, such as not playing basketball, walking to a dressing room, walking to a parking lot, or driving a car.
In one or more implementations, the activity prediction engine 504 determines a subsequent activity 604 based at least in part on the subsequent location 602, while in at least one other implementation, the subsequent activity 604 is determined without using the user's subsequent location 602. In the illustrated example 600, the position prediction engine 124 and the subsequent position 602 are depicted with dashed lines to indicate that they are optional in at least one variation.
In the context of the illustrated example 600, the location prediction engine 124 determines or otherwise predicts a subsequent location 602 of a user (e.g., person 102) based on the sensor data 120. The position prediction engine 124 outputs a subsequent position 602. The activity prediction engine 504 determines or otherwise predicts a subsequent activity 604 of the user, such as an activity the user is performing at the current time. In one or more implementations, the subsequent activity 604 is an indication that the user is finished performing or no longer performing the activity 508, e.g., an "activity state" that is different from the state of "during" (or "middle of activity") the activity 508 ". Alternatively or in addition, the subsequent activity 604 corresponds to a different activity performed by the user.
Based on the subsequent activity 604, the resume delivery engine 408 determines to resume delivery of the drug to the user. In addition, resume delivery engine 408 outputs resume delivery instructions 414 to cause delivery of the drug to resume automatically, e.g., without user interaction to resume delivery. For example, resume delivery engine 408 outputs resume delivery instructions 414 to drug delivery system 106, and the instructions cause drug delivery system 106 to resume delivery of the drug to the user (e.g., person 102). Resume delivery instruction 414 is one example of instruction 122.
The position prediction engine 124 may do so in a similar manner as the position prediction engine 124 predicts the position 506 in terms of how the position prediction engine 124 predicts the subsequent position 602. The activity prediction engine 504 may also predict the subsequent activity 508 in a similar manner as the activity prediction engine 504 predicts the activity 604. Notably, not all activities are associated with resuming drug delivery. Thus, in one or more implementations, resume delivery engine 408 generates resume delivery instructions 414 only if predicted subsequent activity 604 is associated with resuming drug delivery (and delivery of the drug has not been resumed).
In one or more implementations, the resume delivery engine 408 is configured to receive the subsequent activity 604 (and in some implementations the active state) as input and output a machine learning model of the resume delivery instructions 414. In such implementations, the resume delivery engine 408 may be trained using training data that pairs an activity (and in some implementations an activity state) with a tag that indicates that a drug was delivered while the activity was performed or a tag that indicates that a drug was not delivered while the activity was performed.
Alternatively or in addition, the resume delivery engine 408 may obtain an indication of whether the subsequent activity 604 corresponds to an activity during which the drug was delivered or an activity during which the drug was not delivered, such as a mapping from activity (and in some implementations, status) to delivery or not delivery of the drug. For example, the library may include a mapping that maps different activities to delivery or non-delivery of drugs. For example, the information may be stored in a database. In one or more implementations, the mapping may be approved by one or more clinicians. The following discussion of fig. 7 and 8 is considered in the context of using the determined location to pause and resume delivery of a drug (e.g., an uncertain activity).
Fig. 7 depicts an example 700 of a system for automatically suspending delivery of a drug based on a location of a user determined using sensor data.
The illustrated example 700 includes a delivery device control system 110. In this example 700, the delivery device control system 110 automatically pauses delivery of the drug based on the location 506 as determined based on the sensor data 120. In contrast to example 500, pause delivery engine 406 is depicted as receiving location 506 instead of being active. This means that in one or more implementations, the delivery device control system 110 is configured to determine when to suspend delivery of the drug based solely on the location 506 (e.g., without using the activity 508). As discussed above and below, the location prediction engine 124 predicts the location 506 of the user based on the sensor data 120 available from any of the various sources 502.
Based on location 506, pause delivery engine 406 determines to pause delivery of the drug to the user. In one or more variations, this includes pausing the time of delivery. In addition, pause delivery engine 406 outputs pause delivery instruction 412 to cause delivery to be automatically paused, for example, at that time. For example, pause delivery engine 406 outputs pause delivery instructions 412 to drug delivery system 106, and the instructions cause drug delivery system 106 to pause delivery of the drug to the user. As described above, pause pass instruction 412 is one example of instruction 122.
Fig. 8 depicts an example 800 of a system for automatically resuming delivery of a drug based on a subsequent location of a user determined using sensor data.
The illustrated example 800 includes a delivery device control system 110. In this example 800, the delivery device control system 110 automatically resumes delivery of the drug based on the subsequent location 602 as determined based on the sensor data 120. In contrast to example 600, resume delivery engine 408 is depicted as receiving subsequent location 602 instead of subsequent activity. This means that in one or more implementations, the delivery device control system 110 is configured to determine when to resume delivery of the drug based solely on the user's subsequent location 602 (e.g., without using the subsequent activity 604). As discussed above and below, the location prediction engine 124 predicts the user's subsequent location 602 based on the sensor data 120 available from any of the various sources 502.
Based on the subsequent location 602, the resume delivery engine 408 determines to resume delivery of the drug to the user. In one or more variations, this includes resuming the time of delivery. In addition, resume delivery engine 408 outputs resume delivery instructions 414 to cause delivery to resume automatically, for example, at that time. For example, resume delivery engine 408 outputs resume delivery instructions 414 to drug delivery system 106, and the instructions cause drug delivery system 106 to resume delivery of the drug to the user. As described above, resume delivery instruction 414 is one example of instruction 122. Examples of user interfaces that may be output in connection with automatically suspending and resuming delivery of a drug are discussed below.
Fig. 9 depicts an example 900 of a user interface displaying a delivery pause notification. The illustrated example 900 includes an example in which the computing device 108 displays an example user interface 902 via a display device (e.g., a touch screen).
Here, the user interface 902 includes a delivery suspension notification 904 indicating that delivery of the drug has been automatically suspended (e.g., via the drug delivery system 106). The delivery pause notification 904 informs the user of the pause because the user may not know that the delivery of the drug has been paused due to the automatic pause. Although the delivery pause notification 904 is depicted as being output (e.g., displayed) by the computing device 108, it should be understood that the delivery pause notification 904 may be output by any one or more of the analyte monitoring device 104, the drug delivery system 106, or the computing device 108. Delivery suspension notification 904 may also be output by one or more additional devices without departing from the spirit or scope of the described technology. Further, although the delivery suspension notification 904 is illustrated as being displayed in this example 900, the delivery suspension notification 904 may be otherwise output and/or combined with other outputs such as audio output (e.g., via a speaker) and tactile output (e.g., vibration) without departing from the spirit or scope of the described technology.
In this example, the activity corresponds to a predicted bath based on the sensor data 120, which indicates, for example, that the user is in a bathtub or shower (e.g., location 506), exposed to water and/or soap, is using a product and/or item associated with the bath, and so forth. Additionally or alternatively, the sensor data 120 includes sound data, e.g., capturing one or more sounds of a bath or shower.
Fig. 10 depicts an example 1000 of a user interface displaying a delivery resume notification. The illustrated example 1000 includes an example in which the computing device 108 displays an example user interface 1002 via a display device (e.g., a touch screen).
Here, the user interface 1002 includes a delivery resume notification 1004 that indicates that delivery of the drug has been resumed automatically (e.g., via the drug delivery system 106). Delivery restoration notification 1004 notifies the user of the restored delivery because the user may not know that the delivery of the drug has been restored due to the automatic restoration. Although the delivery restoration notification 1004 is depicted as being output (e.g., displayed) by the computing device 108, it should be understood that the delivery restoration notification 1004 may be output by any one or more of the analyte monitoring device 104, the drug delivery system 106, or the computing device 108. Delivery resume notification 1004 may also be output by one or more additional devices without departing from the spirit or scope of the described technology. Further, although the delivery restoration notification 1004 is illustrated as being displayed in this example 1000, the delivery restoration notification 1004 may be otherwise output and/or combined with other outputs such as audio output (e.g., via a speaker) and tactile output (e.g., vibration) without departing from the spirit or scope of the described technology.
In this example, the subsequent activity corresponds to a prediction that the user is no longer bathed based on the sensor data 120, indicating, for example, that the user is not in a bathtub or shower (e.g., subsequent location 602), is not exposed to water and/or soap, is not using products and/or items associated with bathing, and so forth. Additionally or alternatively, the sensor data 120 includes sound data, e.g., capturing one or more sounds corresponding to post-bath or post-shower activities or one or more sounds indicating that the user is no longer bathing or showering.
Fig. 11 depicts an example 1100 of a first combination of devices for enabling automatic suspension and resumption of drug delivery. The illustrated example 1100 includes an analyte monitoring device 104, a drug delivery system 106, and a computing device 108 having a delivery device control system 110.
In accordance with the described techniques, analyte monitoring device 104, drug delivery system 106, and computing device 108 may be communicatively coupled, for example, by network 116 or via some other wireless connection (e.g., BLE), to implement any of the automatic suspension and resumption techniques of drug delivery described above and below. In variations, analyte monitoring device 104, drug delivery system 106, and computing device 108 are operably connected to implement automatic suspension and resumption of drug delivery as a closed loop system, an open loop system, or a partially open loop system. In this example, drug delivery system 106 is depicted as having a wearable pump (e.g., an insulin pump) applied to an infusion set of person 102, and delivering a drug via the infusion set at an insertion site.
As a closed loop system, analyte monitoring device 104, drug delivery system 106, and computing device 108 are configured to monitor an analyte of person 102 wearing analyte monitoring device 104, and cause drug delivery system 106 to automatically suspend delivery of a drug based on one or more of location 506 of person 102 and/or activities in which person 102 is predicted to participate without user interaction. Likewise, when implemented as a closed-loop system, analyte monitoring device 104, drug delivery system 106, and computing device 108 are configured to cause drug delivery system 106 to automatically resume delivery of the drug based on one or more of location 506 of person 102 and/or activities in which person 102 is predicted to participate without user interaction.
In contrast, in a partially open system, a user may be required to verify a pause in drug delivery before the system pauses drug delivery, e.g., the user may be required to provide approval of a proposed drug delivery pause via the display of analyte monitoring device 104, drug delivery system 106, and/or computing device 108 before drug delivery is automatically paused by drug delivery system 106. Once validated, the drug delivery system 106 may suspend delivery of the drug as suggested by the delivery device control system 110. In a partially open system, the user may also be required to verify the restoration of drug delivery before the system resumes drug delivery, e.g., the user may be required to provide approval for suggested drug delivery restoration via the display of analyte monitoring device 104, drug delivery system 106, and/or computing device 108 before drug delivery is automatically restored by drug delivery system 106.
In an open system, delivery device control system 110 may simply cause one or more controls to be output (e.g., displayed via analyte monitoring device 104, drug delivery system 106, or computing device 108) that a user may interact with to generate request 402 to pause the delivery of a drug via drug delivery system 106.
Fig. 12 depicts an example 1200 of a second combination of means for achieving automatic suspension and resumption of drug delivery. The illustrated example 1200 includes a drug delivery system 106 and a computing device 108 having a delivery device control system 110.
However, the illustrated example 1200 does not include the analyte monitoring device 104. This represents a scenario in which drug delivery system 106 and computing device 108 are not operably connected to analyte monitoring device 104. In such a configuration, the delivery device control system 110 is able to determine to automatically suspend and resume delivery of the drug without using the analyte data 118. Instead, the delivery device control system 110 predicts a location 506 of a user associated with the computing device 108 and wearing the drug delivery system 106 (e.g., pump), and/or the delivery device control system 110 predicts an activity 508 of the user using other data (e.g., sensor data 120). Examples of such other data are discussed above, but may include, for example, GPS data and data generated by other sensors of the computing device. Based on the position and/or activity predictions generated by the delivery device control system 110 using this other data, the delivery device control system 110 may further control the drug delivery system 106 to automatically pause and resume delivery of the drug.
Similar to the example illustrated in fig. 11, the drug delivery system 106 and the computing device 108 may be operably connected to implement automatic suspension and resumption of drug delivery as a closed loop system, an open loop system, or a partially open loop system.
Having discussed exemplary details of techniques for automatic suspension and resumption of drug delivery, some examples of procedures are now considered to illustrate additional aspects of these techniques.
Example procedure
This section describes examples of procedures for automatic suspension and resumption of drug delivery. Aspects of the program may be implemented in hardware, firmware, or software, or a combination thereof. A program is illustrated as a set of blocks that specify operations performed by one or more devices and are not necessarily limited to the orders shown for performing the operations by the respective blocks. In at least some implementations, the procedure is performed by a blood glucose control system (such as delivery device control system 110).
Fig. 13 depicts a procedure 1300 in an example implementation of an automatic suspension of drug delivery and resumption after a suspension period.
A request to suspend delivery of a drug to a user is received (block 1302). For example, the delivery device control system 110 receives a request 402 to pause the delivery of a drug. In one or more implementations, the request 402 is responsive to or otherwise based on receiving user input. For example, user input may be received via a user interface of the drug delivery system 106 or the computing device 108 in connection with one or more controls (e.g., buttons, menus, fields, etc.) that may be used to request suspension of delivery of the drug.
The drug delivery system is controlled to suspend delivery of the drug to the user (block 1304). For example, in response to receiving request 402 (e.g., based on user input), delivery device control system 110 suspends delivery of the drug. In one or more implementations, the pause delivery engine 406 of the delivery device control system 110 determines when drug delivery will pause and outputs pause delivery instructions 412. The pause delivery instruction is transmitted to the drug delivery system 106. Broadly, pause delivery instructions 412 instruct drug delivery system 106 to pause the delivery of the drug at a time determined by pause delivery engine 406.
The drug delivery system is controlled to automatically resume delivery of the drug to the user after a pause period (block 1306). For example, the delivery device control system 110 controls the drug delivery system 106 to automatically resume drug delivery to the user after the pause period 404. In one or more implementations, the pause period 404 is specified by the user and received with the request 402. Alternatively, the pause period 404 may correspond to a predetermined period of time, such as 15 minutes, 30 minutes, 45 minutes, etc. To resume drug delivery, resume delivery engine 408 of delivery device control system 110 outputs resume delivery instructions 414 that are transmitted to drug delivery system 106. Broadly, resume delivery instructions 414 instruct drug delivery system 106 to resume delivery of the drug at a time after the drug delivery suspension time.
Fig. 14 depicts a procedure 1400 in an example implementation of automatic suspension and resumption of activity-based drug delivery.
Sensor data is obtained from one or more sensors (block 1402). For example, the delivery device control system 110 obtains sensor data 120. In accordance with the described techniques, the delivery device control system 110 may be configured to receive sensor data 120 from a variety of different sources 502.
Activities to be performed by the user are predicted based on the sensor data (block 1404). For example, activity prediction engine 504 of delivery device control system 110 predicts activity 508 that the user will perform based on sensor data 120. In one or more implementations, the activity 508 is predicted based on the sensor data 120 indicating the user's location 506. For example, the presence of a user in a gym, shower, bed, and/or chair sitting in a workspace may provide important information regarding the activity 508 being performed. Alternatively or in addition, activity prediction engine 504 determines activity 508 of the user based on other sensor data 120 (such as based on heart rate data of the user indicating that the user is exercising).
The drug delivery system is controlled to suspend delivery of the drug to the user during performance of the activity (block 1406). For example, based on activity 508, pause delivery engine 406 of delivery device control system 110 determines to pause delivery of the drug to the user and outputs pause delivery instruction 412 to pause delivery. For example, pause delivery engine 406 outputs pause delivery instructions 412 to drug delivery system 106, and the instructions instruct drug delivery system 106 to pause delivery of the drug to the user.
The drug delivery system is controlled to automatically resume delivery of the drug to the user after performance of the activity is completed (block 1408). For example, delivery device control system 110 controls drug delivery system 106 to resume delivery of the drug to the user after performance of activity 508 is completed. In one or more implementations, the activity prediction engine 504 determines that the user has performed an activity and communicates the activity performed instructions to the resume delivery engine 408. The resume delivery engine 408 of the delivery device control system 110 outputs resume delivery instructions 414 that are transmitted to the drug delivery system 106. Broadly, resume delivery instructions 414 instruct drug delivery system 106 to resume delivery of the drug.
Fig. 15 depicts a procedure 1500 in an example implementation of automatic suspension and resumption of drug delivery based on a user's location.
The drug delivery system is controlled to suspend drug delivery to the user at a first time based on the location of the user (block 1502). For example, the delivery device control system controls the drug delivery system 106 to suspend drug delivery to the user at a first time based on the user's location 506. As discussed above and below, the location prediction engine 124 predicts the location 506 of the user based on sensor data 120 available from any of a variety of sources 502. In one or more implementations, based on the location 506, the pause delivery engine 406 determines to pause delivery of the drug to the user. In one or more variations, this includes pausing the time of delivery. In addition, pause delivery engine 406 outputs pause delivery instruction 412 to cause delivery to be automatically paused, for example, at that time. For example, pause delivery engine 406 outputs pause delivery instructions 412 to drug delivery system 106, and the instructions cause drug delivery system 106 to pause delivery of the drug to the user. As described above, pause pass instruction 412 is one example of instruction 122.
The drug delivery system is controlled to resume drug delivery to the user at a second time based on the subsequent location of the user (block 1504). For example, delivery device control system 110 automatically resumes delivery of the drug based on subsequent location 602. As discussed above and below, the location prediction engine 124 predicts the user's subsequent location 602 based on sensor data 120 available from any of a variety of sources 502. In one or more implementations, resume delivery engine 408 outputs resume delivery instructions 414 to cause delivery to resume automatically, for example, at that time. For example, resume delivery engine 408 outputs resume delivery instructions 414 to drug delivery system 106, and the instructions cause drug delivery system 106 to resume delivery of the drug to the user.
In response to resuming drug delivery, the drug delivery system is controlled to deliver the drug to the user (block 1506). For example, in response to resuming drug delivery, the delivery device control system controls the drug delivery system 106 to deliver the drug to the user.
Having described examples of processes in accordance with one or more implementations, consider now examples of systems and apparatuses that can be used to implement the various techniques described herein.
Example systems and apparatus
Fig. 16 illustrates an example of a system, generally indicated at 1600, that includes an example of a computing device 1602 that represents one or more computing systems and/or devices that can implement the various techniques described herein. This is illustrated by the inclusion of a delivery device control system 110. For example, computing device 1602 may be a server of a service provider, a device associated with a client (e.g., a client device), a system-on-chip, and/or any other suitable computing device or computing system.
The example computing device 1602 as shown includes a processing system 1604, one or more computer-readable media 1606, and one or more I/O interfaces 1608 communicatively coupled to each other. Although not shown, the computing device 1602 may also include a system bus or other data and command transmission system that couples the various components to one another. A system bus may include any of several different bus structures or combinations thereof, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and/or a processor or local bus that utilizes any of a variety of bus architectures. A variety of other examples are also contemplated, such as control lines and data lines.
The processing system 1604 represents functionality that performs one or more operations using hardware. Thus, the processing system 1604 is illustrated as including hardware elements 1610 that can be configured as processors, functional blocks, and the like. This may include implementation in hardware as application specific integrated circuits or other logic devices formed using one or more semiconductors. The hardware elements 1610 are not limited by the materials from which they are formed or the processing mechanisms employed therein. For example, the processor may be comprised of semiconductors and/or transistors, such as electronic Integrated Circuits (ICs). In this context, the processor-executable instructions may be electronically-executable instructions.
The computer-readable medium 1606 is illustrated as including memory/storage 1612. Memory/storage 1612 represents memory/storage capacity associated with one or more computer-readable media. Memory/storage 1612 may include volatile media (such as Random Access Memory (RAM)) and/or nonvolatile media (such as Read Only Memory (ROM), flash memory, optical disks, magnetic disks, and so forth). Memory/storage 1612 may include fixed media (e.g., RAM, ROM, a fixed hard drive, etc.) and removable media (e.g., flash memory, a removable hard drive, an optical disk, and so forth). The computer-readable medium 1606 may be configured in a variety of other ways as described further below.
Input/output interface 1608 represents functionality that allows a user to input commands and information to computing device 1602, and also allows information to be presented to the user and/or other components or devices using various input/output devices. Examples of input devices include keyboards, cursor control devices (e.g., a mouse), microphones, scanners, touch functionality (e.g., capacitive sensors or other sensors configured to detect physical touches), cameras (e.g., which may employ visible wavelengths or non-visible wavelengths (such as infrared frequencies) to recognize movement as gestures that do not involve touches), and so forth. Examples of output devices include a display device (e.g., monitor or projector), speakers, printer, network card, haptic response device, and the like. Accordingly, the computing device 1602 may be configured to support user interaction in a variety of ways as described further below.
Various techniques may be described herein in the general context of software, hardware elements, or program modules. Generally, such modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The terms "module," "function," and "component" as used herein generally represent software, firmware, hardware, or a combination thereof. The features of the techniques described herein are platform-independent, meaning that the techniques may be implemented on a variety of commercial computing platforms having a variety of processors.
Implementations of the described modules and techniques may be stored on or transmitted across some form of computer readable media. Computer readable media can include a variety of media that can be accessed by the computing device 1602. By way of example, and not limitation, computer-readable media may comprise "computer-readable storage media" and "computer-readable signal media".
'Computer-readable storage medium' may refer to media and/or devices capable of storing information permanently and/or non-temporarily, rather than just a signal transmission, carrier wave, or signal itself. Thus, computer-readable storage media refers to non-signal bearing media. Computer-readable storage media include hardware, such as volatile and nonvolatile, removable and non-removable media and/or storage devices, implemented in methods or techniques suitable for storage of information such as computer-readable instructions, data structures, program modules, logic elements/circuits, or other data. Examples of a computer-readable storage medium may include, but are not limited to RAM, ROM, EEPROM, flash memory or other storage technologies, CD-ROM, digital Versatile Disks (DVD) or other optical storage, hard disk, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other storage devices, tangible media, or articles of manufacture adapted to store the desired information and which may be accessed by a computer.
'Computer-readable signal medium' may refer to a signal bearing medium configured to transmit instructions to hardware of the computing device 1602, such as via a network. Signal media may typically be embodied in a modulated data signal, such as a carrier wave, data signal, or other transport mechanism, and include computer readable instructions, data structures, program modules, or other data. Signal media also include any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.
As previously described, hardware elements 1610 and computer-readable media 1606 represent modules, programmable device logic, and/or fixed device logic that may be implemented in hardware in some embodiments to implement at least some aspects of the techniques described herein (such as executing one or more instructions). The hardware may include integrated circuits or systems on a chip, application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs), complex Programmable Logic Devices (CPLDs), and other embodied components in silicon or other hardware. In this context, the hardware may operate as a processing device executing program tasks defined by instructions and/or logic embodied by the hardware, as well as hardware for storing instructions for execution (e.g., the previously described computer-readable storage medium).
Combinations of the foregoing may also be employed to implement the various techniques described herein. Thus, software, hardware, or executable modules may be implemented as one or more instructions and/or logic components embodied on some form of computer readable storage medium and/or implemented by one or more hardware elements 1610. The computing device 1602 may be configured to implement specific instructions and/or functions corresponding to software and/or hardware modules. Thus, implementations of modules that can be executed by the computing device 1602 as software can be at least partially implemented in hardware, for example, through use of computer-readable storage media and/or hardware elements 1610 of the processing system 1604. The instructions and/or functions may be capable of being executed/operated on by one or more articles of manufacture (e.g., one or more computing devices 1602 and/or processing systems 1604) to implement the techniques, modules, and examples described herein.
The techniques described herein may be supported by various configurations of computing device 1602 and are not limited to the specific examples of techniques described herein. This functionality may also be implemented in whole or in part through the "cloud" 1614 using a distributed system, such as via platform 1616 as described below.
The cloud 1614 includes and/or represents a platform 1616 for resources 1618. The platform 1616 abstracts underlying functionality of hardware (e.g., servers) and software resources of the cloud 1614. The resources 1618 may include applications and/or data that can be utilized when executing computer processes on servers remote from the computing device 1602. The resources 1618 may also include services provided over the internet and/or over a user network (such as a cellular or Wi-Fi network).
The platform 1616 may abstract resources and functions to connect the computing device 1602 with other computing devices. The platform 1616 may also be used to abstract scaling of resources to provide a corresponding level of scaling to encountered demand for resources 1618 implemented via the platform 1616. Thus, in an interconnect implementation, the implementation of the functionality described herein may be distributed throughout system 1600. For example, the functionality may be implemented in part on the computing device 1602 and via the platform 1616 that abstracts the functionality of the cloud 1614.
Conclusion(s)
Although the systems and techniques have been described in language specific to structural features and/or methodological acts, it is to be understood that the systems and techniques defined in the appended claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claimed subject matter.