Automatically stopping and restarting drug delivery

Abstract

Automatic stopping and resumption of drug delivery is described. In one or more implementations, a request to stop delivery of drug to a user is received. The drug delivery system is controlled to stop delivery of drug to the user and automatically resume drug delivery to the user after a period of suspension. In one or more implementations, the drug delivery system is controlled to stop delivery of drug to the user during performance of an activity and automatically resume delivery of drug to the user after performance of the activity is completed. In one or more implementations, the drug delivery system is controlled to stop drug delivery to the user at a first time based on a location of the user and resume drug delivery to the user at a second time based on a subsequent location of the user.

Description

[Technical Field]

[0001] (Related Applications) This application claims priority under 35 U.S.C. §119(e) to U.S. Provisional Patent Application No. 63 / 400,648, filed August 24, 2022, entitled "Automatic Suspension and Resumption of Medicament Delivery," the entire disclosure of which is incorporated herein by reference. (Technical field) The present invention relates to automatic stopping and resuming of drug delivery. [Background technology]

[0002] Diabetes is a metabolic condition that affects hundreds of millions of people. For these people, monitoring blood glucose levels and regulating those levels within an acceptable range is important not only to mitigate long-term problems such as heart disease and vision loss, but also to avoid the effects of high and low glucose. Maintaining blood glucose levels within an acceptable range can be difficult, and in various cases, regulating those levels involves administering medications (e.g., insulin) throughout the day using drug delivery devices. Summary of the Invention [Means for solving the problem]

[0003] To overcome these problems, automatic stopping and resumption of drug delivery is utilized. In one or more implementations, a request to stop delivery of drug to a user is received and the drug delivery system is controlled to stop delivery of drug to the user. The drug delivery system is controlled to automatically resume delivery of drug to the user after a period of suspension. In one or more implementations, the drug delivery system is controlled to stop delivery of drug to the user during performance of an activity and automatically resume delivery of drug to the user after performance of the activity is completed. In one or more implementations, the drug delivery system is controlled to stop delivery of drug to the user at a first time based on the user's location and resume delivery of drug to the user at a second time based on the user's subsequent location.

[0004] This Summary introduces in a simplified form a selection of concepts that are further described below in the Detailed Description. As such, this Summary is not intended to identify essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. [Brief explanation of the drawings]

[0005] [Figure 1] FIG. 1 is a diagram of an environment in one exemplary implementation operable to employ automatic pausing and resumption of drug delivery. [Figure 2] 1 illustrates an example of one implementation of an analyte monitoring device in more detail. [Figure 3] 1 illustrates an exemplary implementation of a drug delivery system in more detail. [Figure 4] 1 illustrates an example system for stopping and restarting drug delivery on demand. [Figure 5] An example of a system that automatically stops drug delivery based on sensor data is shown. [Figure 6] 1 shows an example of a system that automatically resumes drug delivery based on sensor data. [Figure 7]1 illustrates an example system that automatically stops medication delivery based on a user's location determined using sensor data. [Figure 8] 1 illustrates an example system that automatically resumes medication delivery based on the user's subsequent location determined using sensor data. [Figure 9] 10 illustrates an example of a user interface displaying a delivery stop notification. [Figure 10] 10 shows an example of a user interface displaying a delivery resume notification. [Figure 11] 1 shows an example of a first combination of devices for implementing automatic stopping and resuming of drug delivery. [Figure 12] 10 shows an example of a second combination of devices for implementing automatic stopping and resuming of drug delivery. [Figure 13] 10 illustrates a procedure in one exemplary implementation for automatically pausing and resuming drug delivery after a suspension period. [Figure 14] 1 illustrates a procedure in one exemplary implementation of automatic pausing and resuming of activity-based drug delivery. [Figure 15] 10 illustrates a procedure in one exemplary implementation for automatically pausing and resuming drug delivery based on a user's location. [Figure 16] 1 illustrates an overview of example systems, including example computing devices that represent one or more computing systems and / or devices that may implement various techniques described herein. DETAILED DESCRIPTION OF THE INVENTION

[0006] overview Maintaining analyte levels (e.g., blood glucose levels) within acceptable ranges can be difficult, and in various cases, regulating those levels involves administering medication (e.g., insulin) throughout the day using a medication delivery system (e.g., an insulin pump). As part of controlling analyte levels within acceptable ranges, conventional medication delivery systems may provide the ability to manually stop and resume medication delivery. For example, a user may manually send a first command to a conventional insulin pump to stop insulin delivery, e.g., by providing user input to an application displayed on the user device, removing the insulin pump, and / or providing user input to the insulin pump itself. The user may then manually send a second command to the insulin pump to resume insulin delivery.

[0007] Using conventional systems, a user may decide to manually stop medication delivery for a variety of different reasons. In a first example, a user may decide to manually stop insulin delivery while exercising because performing exercise may dramatically drop the user's blood glucose level. Thus, in this example, the user may manually stop insulin delivery while exercising to prevent the combination of insulin delivery and exercise from causing the user's blood glucose level to drop below the target range, causing the person to experience a hypoglycemic event. Similarly, in a second example, a user may decide to manually stop insulin delivery (e.g., by removing the insulin delivery device) while bathing or playing sports. However, in both of these examples, conventional systems do not automatically resume insulin delivery but instead require the user to manually resume insulin delivery. However, in many cases, users may forget to manually resume insulin delivery, which may result in a dangerous health condition for the user; for example, if insulin delivery is not enabled, the user's blood glucose level may subsequently increase above the target range associated with hyperglycemia.

[0008] To solve these problems, automatic stopping and resumption of medication delivery is utilized. According to the described technology, a delivery device control system is configured to provide automatic stopping and / or automatic resumption of medication delivery in a manner that eliminates or reduces user interaction associated with manually stopping and resuming insulin delivery. In one or more implementations, the medication delivery system may both automatically stop and automatically resume insulin delivery based on sensor data indicative of a user's location and / or an activity being performed by the user. For example, the delivery device control system may stop and / or resume medication delivery based on the user's location determined from the sensor data. At a first time, for example, the delivery device control system determines or predicts the user's presence at the first location, and based on the user's determined or predicted presence at the first location, the delivery device control system stops medication delivery, for example, by instructing the medication delivery system (e.g., an insulin pump) to stop delivering medication to the user. Then, at a subsequent second time, the delivery device control system determines or predicts the user's presence at a second, different location (or the user's leaving the first location). Based on the determined or predicted presence of the user at 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 the stopped delivery of drug to the user.

[0009] Alternatively or additionally, the delivery device control system stops and / or resumes drug delivery based on sensor data indicative of a user activity, e.g., an activity performed by a user wearing the drug delivery system. Initially, for example, the delivery device control system determines or predicts that the user is performing an activity and stops drug delivery based on the determined or predicted activity, e.g., by instructing the drug delivery system to stop delivering drug to the user. Then, at a subsequent second time, the delivery device control system determines or predicts that the user will stop performing the activity (or the user will perform a different activity). Based on determining or predicting that the user will no longer perform the activity (or the user will perform a different activity), the delivery device control system automatically (without user input) resumes drug delivery, e.g., by instructing the drug delivery system to resume the stopped delivery of drug to the person. In at least one variation, the delivery device control system determines the activity performed by the user based at least in part on also determining the user's location. For example, the user's location (e.g., gym) can be used by the delivery device control system to infer the activity (e.g., exercise). However, in a different variation, the delivery device control system determines the activity the user performs without also determining the user's location.

[0010] In one or more implementations, the delivery device control system provides a pause feature that temporarily suspends drug delivery for a suspension period and then automatically resumes drug delivery after the suspension period has elapsed. In this implementation, rather than determining when delivery should be suspended without user input, the delivery device control system may suspend delivery based on receiving user input requesting that drug delivery be suspended. Such a request may be received via the drug delivery system in response to, for example, the user selecting a graphical control displayed via a display device of the drug delivery system or selecting a physical control (e.g., a button) of the drug delivery system. In at least one variation, the user also specifies the suspension period, i.e., how long the delivery device control system suspends drug delivery before resuming delivery. Alternatively, the user does not specify the suspension period as part of the request, and the delivery device control system determines the suspension period without the user entering it. In one or more variations, the delivery device control system automatically (without user input) resumes drug delivery in response to determining that the suspension period has elapsed. In other words, after the suspension period has elapsed, the delivery device control system resumes delivery of the medication without receiving user input close to the time at which delivery is to be resumed - i.e., the delivery device control system resumes delivery based on the maintained value specifying the suspension period.

[0011] Thus, by stopping and / or resuming drug delivery automatically and without user input, the described technology reduces or eliminates dangerous health conditions caused by conventional drug delivery systems that require users to both manually stop and manually resume insulin delivery.

[0012] In some aspects, the technology described herein relates to a system that includes one or more sensors; a medication delivery system configured to deliver a medication to a user; and a delivery device control system configured to: control the medication delivery system to stop delivery of the medication to the user in response to a request initiated by the user; automatically resume delivery of the medication to the user after a stop time has elapsed; control the medication delivery system to automatically stop delivery of the medication to the user based on first sensor data obtained from the one or more sensors; and automatically resume delivery of the medication to the user based on second sensor data obtained from the one or more sensors.

[0013] In some aspects, the technology described herein relates to a system, wherein the delivery device control system is further configured to control the medication delivery system to automatically stop delivery of medication to the user based on first sensor data indicating performance of an activity by the user, and to automatically resume delivery of medication to the user based on second sensor data indicating performance of the activity has been completed.

[0014] In some aspects, the technology described herein relates to a system, wherein the delivery device control system is further configured to control the medication delivery system to automatically stop delivery of medication to the user based on first sensor data indicating the user is at a location, and to automatically resume delivery of medication to the user based on second sensor data indicating the user is at a subsequent location.

[0015] In some aspects, the technology described herein relates to a system further including an analyte monitoring device connected to the drug delivery system to form a closed-loop system.

[0016] In some aspects, the technology described herein relates to a system, wherein the analyte monitoring device includes a wearable glucose monitoring device and the medication delivery system includes a wearable insulin pump.

[0017] In some aspects, the technology described herein relates to a system in which a delivery device control system is implemented in a computing device that is wirelessly coupled to a drug delivery system and an analyte monitoring device.

[0018] In some aspects, the technology described herein relates to a system in which a delivery device control system is implemented in an analyte monitoring device.

[0019] In some aspects, the technology described herein relates to a system in which a delivery device control system is implemented in a medication delivery system.

[0020] In some aspects, the technology described herein relates to a method that includes receiving a request to stop delivery of a medication to a user, controlling a medication delivery system to stop delivery of the medication to the user, and controlling the medication delivery system to automatically resume delivery of the medication to the user after a period of suspension.

[0021] In some aspects, the technology described herein relates to methods by which a drug delivery system automatically resumes drug delivery to a user without user interaction after a period of suspension has elapsed.

[0022] In some aspects, the technology described herein relates to methods in which a drug delivery system is connected to an analyte monitoring device and a computing device to form a closed-loop system.

[0023] In some aspects, the technology described herein relates to methods in which a request to stop delivery of a medication is received in response to a user input to a medication delivery system.

[0024] In some aspects, the technology described herein relates to methods in which a request to stop delivery of a medication is received in response to a user input to a user interface displayed on a computing device.

[0025] In some aspects, the technology described herein relates to methods in which a request to stop delivery of medication to a user includes an indication of the duration of the stoppage.

[0026] In some aspects, the technology described herein relates to methods in which the downtime corresponds to a predetermined period of time.

[0027] In some aspects, the technology described herein relates to methods wherein the agent comprises insulin.

[0028] In some aspects, the techniques described herein relate 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 stop delivery of a drug to the user while the activity is being performed, and controlling the drug delivery system to automatically resume delivery of the drug to the user after performance of the activity is complete.

[0029] In some aspects, the techniques described herein relate to a method further including detecting that performance of the activity has been completed based on additional sensor data obtained from one or more sensors.

[0030] In some aspects, the technology described herein relates to methods where the activity includes exercising, sleeping, or bathing.

[0031] In some aspects, the techniques described herein relate to a method further including detecting a location of a user based on sensor data, wherein predicting further includes predicting an activity to be performed by the user based on the location of the user.

[0032] In some aspects, the techniques described herein relate to a method in which detecting a location of a user includes detecting a location of the user based on first sensor data and confirming the location of the user based on second sensor data.

[0033] In some aspects, the techniques described herein relate to a method in which detecting a location of a user includes detecting at least two candidate locations for 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.

[0034] In some aspects, the technology described herein relates to a method, wherein predicting includes predicting a time at which an activity will begin based on sensor data.

[0035] In some aspects, the technology described herein relates to methods that further include controlling a drug delivery system to administer a bolus dose of the drug until a predicted time that the activity will begin.

[0036] In some aspects, the technology described herein relates to methods wherein the bolus dose of a pharmaceutical agent comprises a bolus dose of insulin.

[0037] In some aspects, the technology described herein relates to a method further including determining a current glucose measurement of the user based on a glucose monitor worn by the user, and determining a bolus dose of insulin based on the current glucose measurement of the user.

[0038] In some aspects, the techniques described herein relate to a method that includes controlling a drug delivery system to stop drug delivery to a user at a first time based on a location of the user, controlling the drug delivery system to resume drug delivery to the user at a second time based on a subsequent location of the user, and, in response to the resumption of drug delivery, causing the drug delivery system to deliver a dose of drug to the user.

[0039] In some aspects, the technology described herein relates to a method where controlling a drug delivery system to stop and resume drug delivery includes controlling the drug delivery system to stop and resume drug delivery automatically without user input.

[0040] In some aspects, the technology described herein relates to methods where controlling a drug delivery system to stop and resume drug delivery to a user is not based on analyte data.

[0041] In some aspects, the technology described herein relates to methods in which the dose of medication delivered to a user is based, at least in part, on analytical data.

[0042] In some aspects, the technology described herein relates to methods whereby the dose of a drug delivered to a user is based at least in part on the time interval between a first time and a second time.

[0043] In some aspects, the technology described herein relates to methods in which a dose of a drug delivered to a user is based at least in part on an activity performed by the user between a first time and a second time.

[0044] In some aspects, the technology described herein relates to methods in which activity is predicted based at least in part on the location of a user.

[0045] The following description first describes an exemplary environment in which the technology described herein may be used. Next, implementation details and example procedures that may be performed in the exemplary environment, as well as in other environments, are described. The execution of the example procedures is not limited to the exemplary environment, and the example environment is not limited to the execution of the example procedures.

[0046] Example Environment 1 is a diagram of an environment 100 in one example implementation operable to employ automatic pausing and resumption of drug delivery. The illustrated environment 100 includes a person 102, who is shown 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 an 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.

[0047] The analyte monitoring device 104 (associated with the person 102), the drug delivery system 106, and the one or more computing devices 108 may be communicatively coupled in various ways, such as by using one or more wireless communication protocols or technologies. By way of 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 wireless, cellular, Wi-Fi, Bluetooth (e.g., Bluetooth low energy link), Near-Field Communication (NFC), and 5G, to name a few.

[0048] Through such communicative coupling, one or more of the one or more analyte monitoring devices 104, the drug delivery system 106, and the computing device 108 may, in one or more implementations, form a closed-loop system. When implemented as a closed-loop system, the combination of devices is configured to provide automatic pausing and resuming of drug delivery in a manner that eliminates or reduces user interaction associated with temporarily removing the drug delivery system 106, for example, to engage in or participate in a physical activity such as basketball. Instead, the device processes various information and makes various predictions and judgments regarding the user's location based on its location and / or the activity the user is performing or will perform, and automatically pauses and resumes drug delivery. In a closed-loop system, the device may thus control the drug delivery system 106 to pause and subsequently resume delivery of drug to the person 102 without user interaction, such as without receiving user input to any control (e.g., of the drug delivery system 106 or the computing device 108) to explicitly pause or resume drug delivery.

[0049] 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, the analyte monitoring device 104 performs one or more operations before or after being worn by the person 102. Broadly, the analyte monitoring device 104 is configured to provide measurements of an analyte of the person 102, such as the 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 the generation or estimation of an analyte measurement (e.g., an estimation of a glucose level). These analyte measurements (e.g., glucose measurements) may be adapted or otherwise packaged for communication to one or more of the computing device 108 or the drug delivery system 106 as analyte data 118.

[0050] In at least one implementation, the analyte monitoring device 104 is a glucose monitoring system. As one 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 device's ability to generate measurements substantially continuously, such that the device may be configured to generate analyte measurements at regular or irregular time intervals (e.g., about every hour, about every 30 minutes, about every 5 minutes, etc.), depending on, for example, establishing a communication link with a different device (e.g., when the computing device 108 establishes a wireless connection with the analyte monitoring system 104 to retrieve one or more of the measurements). However, in other implementations, the glucose monitoring device may not be “continuous” and instead provides glucose measurements when requested. For example, the analyte monitoring device 104 may communicate a current glucose measurement to the computing device 108 in response to a request from the computing device 108. This request may be initiated in a variety of ways, such as in response to a user input to a user interface displayed by computing device 108 (and / or another device), in response to placing computing device 108 within a threshold proximity to analyte monitoring device 104, in response to computing device 108 coming into physical contact with analyte monitoring device 104, in response to a request from an application implemented on computing device 108, etc. This functionality, along with further aspects of the configuration of analyte monitoring device 104, will be described in more detail in conjunction with FIG. 2.

[0051] In addition to generating analyte data 118, the analyte monitoring device 104 also transmits the generated analyte data 118, for example, to the computing device 108. The analyte monitoring system 104 may communicate data in real time, for example, as the data is generated, using an analyte sensor. Alternatively, or additionally, the analyte monitoring device 104 may communicate data to the computing device 108 at predefined time intervals. For example, the analyte monitoring device 104 may be configured to communicate analyte data 118 to the computing device 108 approximately every five minutes. Indeed, the interval at which the analyte data 118 is communicated by the analyte monitoring device 104 may differ from the above example without departing from the spirit or scope of the described technology. In other implementations, the analyte data 118 is communicated by the analyte monitoring device 104 when requested. For example, the analyte monitoring device 104 may communicate a current analyte measurement value to the computing device 108 in response to a request from the computing device 108. This request may be initiated in a variety of ways, such as in response to user input to a user interface displayed by the computing device 108 (and / or another device), in response to placing the computing device 108 within a threshold proximity to the analyte monitoring device 104, in response to the computing device 108 coming into physical contact with the analyte monitoring device 104, in response to a request from an application implemented on the computing device, etc. Data may also be communicated by the analyte monitoring device 104 to the computing device 108 according to other bases according to the described techniques.

[0052] Additionally, the computing device 108 may at least temporarily retain the analyte data 118 and sensor data 120 received from various sources, for example, in a storage device (not shown) of the computing device 108. The analyte data 118 and sensor data 120 may also be maintained in such storage of the computing device 108 or in a storage device of a different device, along with other associated data, such as corresponding timestamps and / or identifiers of communicated data packets, to name a few.

[0053] As shown, the illustrated 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 may be performed using multiple computing devices 108, including, in at least one variation, both a wearable device (e.g., a smartwatch, a mouth guard, contact lenses, smart glasses, a chest strap, earbuds, or headphones, to name a few) and a mobile phone. In such a scenario, both of these devices may be capable of performing at least some of the same operations, such as receiving analyte data 118 from the analyte monitoring device 104, receiving sensor data 120 from various sources, generating sensor data 120 using on-board or associated sensors, communicating the data to the delivery device control system 110 and / or health monitoring platform 112 via the network 116, displaying information related to the data, displaying information related to automatic drug suspension or resumption regulated by the delivery device control system 110, and facilitating control of the drug delivery system 106. Alternatively or additionally, different devices may have different capabilities that other devices do not have or that are limited to particular devices by computing instructions.

[0054] The delivery device control system 110 controls the medication delivery system 106 to stop delivery of one or more medications and subsequently resume delivery of the one or more medications. The delivery device control system 110 controls the medication 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 medication delivery system 106, the computing device 108, and / or another device (e.g., an additional medication delivery system). In accordance with the described techniques, the delivery device control system 110 makes decisions regarding medication delivery and stops and / or resumes medication delivery, at least in part, by leveraging one or more of the computing device 108, the medication delivery system 106, the health monitoring platform 112, and the IoT 114.

[0055] Although shown as separate from the analyte monitoring device 104, the drug delivery system 106, the computing device 108, and the health monitoring platform 112, in one or more implementations, at least a portion of the delivery device control system 110 is implemented in one or more of these entities. Note that various portions of the delivery device control system 110 can be implemented with different combinations of the analyte monitoring device 104, the drug delivery system 106, the computing device 108, and the health monitoring platform 112, or in other ways, in accordance with the described techniques.

[0056] As discussed above and below, the delivery device control system 110 obtains the 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 medication delivery system 106, the computing device 108, the health monitoring platform 112, or the IoT 114. Examples of sensor data 120 may include, but are not limited to, Global Positioning System (GPS) data, Wi-Fi information (e.g., service set identifiers (SSIDs) of available networks, the network to which the computing device 108 is connected, and / or networks to which the computing device 108 has 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, ambient or internal temperature data (e.g., generated using a temperature sensor), light data (e.g., captured using a device's camera), heart rate data (e.g., generated by a smartphone and / or smartwatch), proximity data (e.g., between devices), humidity data, analyte data, and drug data, to name a few. It will 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.

[0057] In the depicted example, delivery device control system 110 is shown as including a location prediction engine 124. However, 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.

[0058] Based on the sensor data 120, the location prediction engine 124 detects the location of a user, e.g., a person 102 wearing the medication delivery system 106. In one or more implementations, the location prediction engine 124 detects the user's location based on at least two different types of sensor data 120. For example, the location prediction engine 124 detects the user's location based on both GPS data and Wi-Fi information (e.g., the 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 detects the user's location using first sensor data and confirms the user's location using second sensor data. Alternatively or additionally, the location prediction engine 124 uses the two types of sensor data to distinguish which of multiple candidate locations corresponds to the user's actual physical location. For example, the location prediction engine 124 detects at least two candidate locations for 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 user's location (or eliminates all but one of the candidate locations).

[0059] In one or more implementations, the delivery device control system 110 stops and / or resumes drug delivery based on the location of a user, e.g., the person 102 wearing the drug delivery system 106. At a first time, for example, the location prediction engine 124 determines or predicts the presence of the user 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 stops drug delivery, for example, by instructing the drug delivery system 106 to stop delivery of drug to the person 102. Then, at a subsequent second time, the location prediction engine 124 determines or predicts the presence of the user at a second, different location (or the user leaving the first location). Based on the determined or predicted presence of the user at the second location (or the user leaving the first location), the delivery device control system 110 automatically (without user input) resumes drug delivery, for example, by instructing the drug delivery system 106 to resume the stopped delivery of drug to the person 102.

[0060] Alternatively or additionally, the delivery device control system 110 stops and / or resumes drug delivery based on a user activity, e.g., an activity performed by the person 102 wearing the drug delivery system 106. Initially, for example, the delivery device control system 110 determines or predicts that the user is performing an activity and stops drug delivery based on the determined or predicted activity, e.g., by instructing the drug delivery system 106 to stop delivery of drug to the person 102. Then, at a subsequent second time, the delivery device control system 110 determines or predicts that the user will stop performing the activity (or the user will perform a different activity). Based on determining or predicting that the user will no longer be performing the activity (or the user will perform a different activity), the delivery device control system 110 automatically (without user input) resumes drug delivery, e.g., by instructing the drug delivery system 106 to resume the stopped delivery of drug to the person 102. In at least one variation, the delivery device control system 110 determines the activity performed by the user based at least in part on also determining the user's location. However, in a different variation, the delivery device control system 110 determines the activity the user performs without also determining the user's location.

[0061] In one or more implementations, the delivery device control system 110 determines when to stop 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 stop delivery of the drug based at least in part on the analyte data 118. Similarly, in one or more implementations, the delivery device control system 110 determines when to resume delivery of the drug based on the sensor data 120 rather than based on the 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 instruct the drug delivery system 106 accordingly), the delivery device control system 110 may also use the analyte data 118 to determine the dose of drug to deliver if delivery is resumed.

[0062] In at least one implementation, rather than determining when delivery should stop without user input, the delivery device control system 110 stops delivery based on receiving user input requesting that delivery of the medication be stopped. In one or more implementations, such a request may be received via the medication delivery system 106, for example, in response to the user selecting a graphical control displayed via a display device of the medication delivery system 106 or selecting a physical control (e.g., a button) of the medication delivery system 106. In at least one variation, the user also specifies the stop period, i.e., how long the delivery device control system 110 should stop delivery of the medication before resuming delivery. Alternatively, the user does not specify the stop period as part of the request, and the delivery device control system 110 determines the stop period without the user entering a stop period. In one or more variations, the delivery device control system 110 automatically (without user input) resumes delivery of the medication in response to determining that the stop period has elapsed. In other words, after the suspension period has elapsed, the delivery device control system 110 resumes delivery of the medication without receiving user input close to the time at which delivery is to be resumed - i.e., the delivery device control system 110 resumes delivery based on the maintained value specifying the suspension period.

[0063] As mentioned above, the delivery device control system 110, in one or more implementations, uses sensor data 120 obtained via the IoT 114. It should be understood that the IoT 114 represents various sources that can provide data describing the person 102 and / or the activities of the person 102, such as the activities of the person 102 as a user of one or more service providers, or the activities of the person 102 in the real world, e.g., at home, in a car, at work, at a gym, at a restaurant, or at other businesses, to name a few. By way of example, the IoT 114 may include the user's various devices, e.g., a mobile phone, wearable devices, a camera, a laptop, etc. To this end, the IoT 114 may be provided with information regarding the user's interactions with those various devices, such as the location of those devices, the environmental and / or physical conditions at the locations where the devices are located, 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. The IoT 114 may also include various other real-world objects (e.g., shoes, clothing, sporting equipment, appliances, smart home devices, automobiles, etc.) configured with sensors that provide information describing behavior such as household items or locations of interaction (e.g., shower, bathtub, or bed), number of steps, foot strike force, stride length, the user's body temperature (and other physiological measurements), the temperature surrounding the user, types of food stored in the refrigerator, types of food removed from the refrigerator, driving habits, images of the user at different times of day, etc. Such other real-world objects may also be provided with sensor data 120 that describes the location of those objects, user interactions with those objects, environmental and / or physical conditions in the locations where the objects are located, and various other conditions.

[0064] In variations, the IoT 114 may also include third parties to the health monitoring platform 112, such as healthcare providers (e.g., healthcare providers of the person 102) and manufacturers (e.g., manufacturers of one or more of the medication delivery systems 106 or computing devices 108) that can provide medical and manufacturing data, respectively, that can be leveraged by the delivery device control system 110. Indeed, the IoT 114 may include devices and sensors that can provide a wealth of data used to determine the location and / or activity of the person 102 without departing from the spirit or scope of the described technology.

[0065] In one or more implementations, the delivery device control system 110 also leverages the resources of the health monitoring platform 112 in connection with automatically pausing and resuming medication 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 decisions 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 representing various data obtained and stored by the health monitoring platform 112 for one or more of those users. The user data 126 is stored for one or more users, but may be obfuscated using one or more techniques so that the user's personal identification information associated with the data can be kept anonymous in various scenarios using the data. In the illustrated environment 100, the user data 126 is shown stored in a storage device 128. Storage device 128 may represent one or more databases or other storage devices included as part of or otherwise accessible to health monitoring platform 112. In accordance with the described techniques, storage device 128 may store user data 126 and various other data.

[0066] By way of example, user data 126 may include any combination of the data described above and other data discussed above and below. For example, user data 126 may include historical data related to one or more users, such as historical analyte data 118, historical sensor data 120, decisions made based on historical analyte data 118 and / or historical sensor data 120, received user inputs, etc. In at least one implementation, such historical data may describe a user's state and / or user behavior, including, for example, activities previously performed by a user at a location, activities previously performed by other users at that location, and attributes of the activities performed, such as activity duration, location type, whether the user made an input to stop drug delivery, whether the user made an input to resume drug delivery, the length of time drug delivery was stopped before being resumed, etc.

[0067] In one or more implementations, the health monitoring platform 112 includes a monitoring service 130. The monitoring service 130 may be used separately from or in conjunction with the delivery device control system 110. By way of example, the monitoring service 130 may provide one or more web-based health-related services to users via the network 116 and the users' computing devices 108, e.g., mobile applications. The health monitoring platform 112 may include or have access to various computing resources, such as processing resources, storage resources, and virtualization resources. These resources may be usable, for example, to train, maintain, and / or deploy algorithms (e.g., machine learning algorithms) that may generate predictions associated with health monitoring by using a wealth of data collected about the person 102 and users of the user population. Accordingly, the monitoring service 130 may leverage these resources to execute algorithms and implement other functions to deliver web-based services to users via their devices.

[0068] In particular, one or more such algorithms or functionalities may require an amount of computing resources that exceeds the resources of a typical personal computing device, e.g., a mobile phone, laptop, tablet device, and wearable, to name a few. However, the health monitoring platform 112 may include or otherwise access at least a threshold amount of resources, e.g., cloud storage, server devices, virtualization resources, etc., necessary to operate such algorithms and provide such functionality. The health monitoring platform 112 may also include various resources that the computing device 108 may utilize via the monitoring service 130 to automatically pause and resume medication delivery and provide notifications therefor. Consider the following description of FIG. 2 in the context of continuously measuring an analyte, e.g., glucose, and obtaining analyte data describing such measurements.

[0069] 2 illustrates in more detail an example implementation 200 of the analyte monitoring device 104. In particular, the illustrated embodiment 200 includes a top view and a corresponding side view of the analyte monitoring device 104. It should be understood that the analyte monitoring device 104 may be varied in various ways in implementation from the following description without departing from the spirit or scope of the described technology.

[0070] In this example 200, the analyte monitoring device 104 is illustrated to include an analyte sensor 202 (e.g., a glucose sensor) and a sensor module 204. Here, the analyte sensor 202 is shown in a side view inserted, for example, under the skin 206 of the human 102. The sensor module 204 is approximated as a dashed rectangle in a top view. The analyte monitoring device 104 also includes a transmitter 208 in the illustrated example 200. The use of a dashed rectangle for the sensor module 204 indicates that the sensor module may be housed or otherwise implemented within a housing of the transmitter 208. An antenna and / or other hardware used to enable the transmitter 208 to generate a signal for communicating data, for example, via a wireless connection to the drug delivery system 106 and / or the computing device 108, may also be housed or otherwise implemented within a housing of the transmitter 208. In this example 200, the analyte monitoring device 104 further includes an adhesive pad 210.

[0071] In operation, the analyte sensor 202 and adhesive pad 210 may be assembled to form an adhesive assembly configured to be applied to the skin 206 such that the analyte sensor 202 is inserted subcutaneously as shown. In such a scenario, the transmitter 208 may be attached to the assembly after affixing it to the skin 206 via an attachment mechanism (not shown). Alternatively, the transmitter 208 may be incorporated as part of the adhesive assembly, such that the analyte sensor 202, adhesive pad 210, and transmitter 208 (with sensor module 204) can be affixed to the skin 206 all at once. In one or more implementations, this adhesive assembly is affixed to the skin 206 using a separate sensor applier (not shown). Unlike the finger prick required by conventional blood glucose meters, user-initiated application of the analyte monitoring device 104 with the sensor applier is substantially painless and does not require the drawing of blood. Additionally, automatic sensor applicators generally allow the human 102 to implant the analyte sensor 202 under the skin 206 without the assistance of a clinician or healthcare provider.

[0072] Analyte monitoring device 104 can also be removed by peeling adhesive pad 210 from skin 206. It should be understood that analyte monitoring device 104 and its various components as shown are simply one exemplary form factor, and that analyte monitoring device 104 and its components can have different form factors without departing from the spirit or scope of the described technology.

[0073] In operation, the analyte sensor 202 is communicatively coupled to the sensor module 204 via at least one communication channel, which may be a wireless connection or a wired connection. Communication from the analyte sensor 202 to the sensor module 204, or from the sensor module 204 to the analyte sensor 202, may be active or passive, and these communications may be continuous (e.g., analog) or discrete (e.g., digital).

[0074] The analyte sensor 202 may be a device, molecule, and / or chemical that changes or undergoes a change in response to an event at least partially independent of the analyte sensor 202. The sensor module 204 is implemented to receive an indication of a change to or caused by the analyte sensor 202. For example, the analyte sensor 202 may include glucose oxidase, which reacts with glucose and oxygen to form hydrogen peroxide, which is electrochemically detectable by the sensor module 204, which may include electrodes. In this example, the analyte sensor 202 may be configured as or include a glucose sensor configured to detect an analyte in blood or interstitial fluid that indicates 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 indicate other markers, such as lactate levels, ketones, or ionic potassium, which may improve accuracy in 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 to analyte sensor 202 for detecting those analytes exhibiting other markers.

[0075] In another example, the analyte sensor 202 (or an additional, not shown, sensor of the analyte monitoring device 104) may include a first conductor and a second conductor, and the sensor module 204 may electrically detect a change in electrical potential across the first and second conductors of the analyte sensor 202. In this example, the sensor module 204 and the analyte sensor 202 are configured as a thermocouple, such that a change in electrical potential corresponds to a change in temperature. In some examples, the sensor module 204 and the analyte sensor 202 are configured to detect a single analyte, e.g., glucose. In other examples, the sensor module 204 and the analyte sensor 202 are configured to use multiple sensing modes to detect multiple analytes, e.g., ionic sodium, ionic potassium, carbon dioxide, and glucose. Additionally or alternatively, the analyte monitoring device 104 includes multiple sensors to detect not only one or more analytes (e.g., ionic sodium, ionic potassium, carbon dioxide, glucose, and insulin) but also one or more environmental conditions (e.g., temperature, humidity, movement). Thus, the sensor module 204 and analyte sensor 202 (and any additional sensors) may detect the presence of one or more analytes, the absence of one or more analytes, and / or changes in one or more environmental conditions. As described above, the analyte monitoring device 104 may be configured to generate data describing one or more analytes (e.g., glucose).

[0076] In one or more embodiments, the sensor module 204 may include a processor and memory (not shown). The sensor module 204 may utilize the processor to generate an analyte measurement 212 based on communication with the analyte sensor 202 indicating the change described above. Based on the communication from the analyte sensor 202, the sensor module 204 is further configured to generate communicable data packages including at least one analyte measurement 212. In this example 200, analyte data 118 represents these data packages. Additionally or alternatively, the sensor module 204 may configure the analyte data 118 to include additional data, including, by way of example, supplemental sensor information 214. The supplemental sensor information 214 may include a sensor identifier, a sensor status, a temperature corresponding to the analyte measurement 212, measurements of other analytes corresponding to the analyte measurement 212, etc. It should be understood that the supplemental sensor information 214 may include a variety of data supplemental to the at least one analyte measurement 212 without departing from the spirit or scope of the described technology.

[0077] In implementations in which the analyte monitoring device 104 is configured for wireless transmission, the transmitter 208 may transmit the analyte data 118 as a data stream to a computing device. Additionally or alternatively, the sensor module 204 may buffer the analyte measurements 212 and / or supplemental sensor information 214 (e.g., in the memory of the sensor module 204 and / or other physical computer-readable storage medium of the analyte monitoring device 104) and later cause the transmitter 208 to transmit the buffered analyte data 118 at various regular or irregular intervals, such as time intervals (approximately every 1 second, approximately every 30 seconds, approximately every 1 minute, approximately every 5 minutes, approximately every hour, etc.), storage intervals (when the buffered analyte measurements 212 and / or supplemental sensor information 214 reach a threshold amount of data or number of measurements), etc. It should be understood that in some implementations, the analyte monitoring device 104 may vary in numerous ways from the examples described above without departing from the spirit or scope of the described technology.

[0078] Having described one embodiment of an analyte monitoring device, consider the following description of one embodiment of a drug delivery system.

[0079] FIG. 3 shows an exemplary implementation 300 of the drug delivery system 106 in more detail.

[0080] In the exemplary implementation 300, the drug delivery system 106 includes a drug pump 302 and an infusion set 304. The infusion set 304 is shown with tubing 306 connected to the drug pump 302, although in one or more implementations, the infusion set 304 may be tubeless. While shown as a pump in this example, the drug delivery system 106 may be configured in a variety of ways in accordance with the described techniques, examples of which include a pen or set of pens, an inhaler, a patch, one or more syringes, and a mouthpiece.

[0081] Broadly, the infusion set 304 is a device configured to subcutaneously deliver medication pumped by the medication pump 302 to the infusion set 304 to the person 102 for absorption by the person's 102 bloodstream. In this manner, the delivered medication may be used by the person's 102 body to maintain balanced analyte levels, for example, within a target range of analyte measurements. In one or more implementations, the infusion set 304 includes a cannula that is inserted subcutaneously into the skin, such as at an infusion site 308 of the person 102 in the exemplary implementation 300. Thus, the infusion set 304 may administer doses of medication through the skin of the person 102, for example, continuously and at a programmable rate. As discussed herein, for example, basal and / or bolus doses of insulin may be administered through the skin of the person 102 via the infusion set 304. Alternatively or additionally, the medication delivery system 106 may administer medication to the person 102 based on user input, for example, input received via a user interface of one or more doses of medication to deliver and / or input received via the computing device 108.

[0082] As shown, the infusion set 304 includes an adhesive pad that affixes 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 inject the cannula of the infusion set 304 into the infusion site 308 on the skin of the person 102 and attach the adhesive pad to the infusion site 308, securing the infusion set 304 to the person 102 for a period of use. In at least some implementations, the infusion set may be disposable, designed to be removed after a prescribed and / or recommended period of time and replaced with a new set that is applied to the person 102 and attached to the drug pump 302. In either case, the drug pump 302 is configured to deliver a drug dose to the person 102 via an infusion set, such as the illustrated infusion set 304.

[0083] In exemplary implementation 300, drug pump 302 includes a communications module 310, a drug delivery control 312, a drug reservoir 314, a display module 316, a safety module 318, and a battery 320. In implementations, drug pump 302 may be configured in various ways, with some of these components housed in separate devices or otherwise implemented. Alternatively or additionally, drug pump 302 may include additional or alternative components without departing from the spirit or scope of the technology described herein.

[0084] Communications module 310 is configured to transmit data to and receive data from other devices, such as computing device 108 and / or delivery device control system 110 (which, in one or more variations, may be at least partially included in computing device 108). Communications module 310 establishes a communications link with such other devices to enable the transmission and reception of data. By way of example, communications module 310 may establish or otherwise facilitate the establishment of a communications link or channel with those other devices. The link or channel may be configured in a variety of ways, including, but not limited to, Bluetooth (e.g., a Bluetooth low energy link), near field communication (NFC), 5G or other cellular, and Wi-Fi, to name a few. Such communications link may enable drug pump 302 to communicate securely over different networks, such as network 116, and / or within a closed-loop system, for example, including analyte monitoring device 104 and at least one computing device 108.

[0085] Once a communications link is established, communications module 310 may transmit data over the established link and / or receive data from other devices over the established link. Additionally or alternatively, communications module 310 may be configured to establish a connection through a wired communications channel, such as via a USB cord connected to drug pump 302 and another device, and may be configured to transmit and / or receive data over such a wired link. Communications module 310 may be configured in various ways to enable drug pump 302 to communicate with other devices.

[0086] As one example, communications module 310 enables drug pump 302 to receive instructions 122 and / or other instructions for controlling delivery of medication to person 102 from computing device 108 and / or delivery device control system 110. For example, communications module 310 may enable drug pump 302 to receive instructions instructing drug pump 302 to stop delivery of medication to person 102 and subsequently resume delivery of medication to person 102 and deliver an amount of medication to person 102 that is determined in part based on the amount of time that delivery of medication is stopped. Alternatively or additionally, communications module 310 may enable drug pump 302 to receive instructions regarding delivery of a basal rate of insulin to person 102, updates to the basal rate of insulin, delivery of a bolus dose of insulin (e.g., a bolus dose within a limited time period) to person 102, etc. Computing device 108 may send various communications to drug delivery system 106 to control medication delivery without departing from the spirit or scope of the technology described herein.

[0087] Drug delivery controller 312 represents any hardware, software, and / or mechanical components of drug pump 302 that cause drug to be pumped (or otherwise extracted) from drug reservoir 314 so that the drug flows through infusion set 304 and into person 102. Drug delivery controller 312 is further configured to cause drug to be pumped or otherwise extracted from drug reservoir 314 in accordance with drug administration instructions, e.g., instructions 122 from delivery device control system 110 specifying stopping and / or resuming delivery of one or more of the drugs. Drug reservoir 314 is configured to contain a quantity of drug, and by utilizing the functionality of drug pump 302, the drug may be delivered subcutaneously via infusion set 304. Drug reservoir 314 may be replaceable or otherwise configured to allow a quantity of drug to be replenished in drug reservoir 314. The drug reservoir 314 may be configured in a variety of ways (eg, different shapes, different materials, different detachability, etc.) without departing from the spirit or scope of the described technology.

[0088] Display module 316 is configured to cause the display of information via a display device 322 of drug pump 302. Display module 316 may generate one or more user interfaces for display via display device 322. As an example, display module 316 may cause the display via the display device of a user interface for setting up a wireless connection with 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 that displayed via a health monitoring application on the computing device 108), trend arrows (e.g., regarding identified trends in analyte measurements), warnings (e.g., that drug delivery has been stopped, drug delivery has been resumed, or drug delivery has resumed) (e.g., regarding analyte measurements, other physiological conditions, the operability of the drug delivery system 106, the operability of components of the delivery device control system 110, the status of the wireless connection with the computing device 108, etc.), a pump setup interface, an indication of being out of communication range from a different device (e.g., the computing device 108 or the analyte monitoring device 104), etc. Accordingly, the display module 316 may cause a variety of information to be displayed via the display device 322 of the drug pump 302.

[0089] Safety module 318 is configured to provide one or more safety measures to control the delivery of the drug so that the delivery is not harmful. In other words, it ensures that the drug is delivered safely. By way of example, safety module 318 may include or otherwise implement delivery limits, such as maximum and minimum rates of delivery over different time periods. These limits are effective to prevent erroneous delivery commands from delivery device control system 110 from harming person 102, for example, if they affect the content of those transmitting commands or if errors in predictions made by one or more machine learning models have a dangerous effect on those commands. For example, safety module 318 may limit the amount or rate of drug delivered by drug pump 302 to a threshold amount or rate, even if commands received from delivery device control system 110 instruct drug pump 302 to deliver more than the threshold amount. Similarly, safety module 318 may also prevent drug pump 302 from delivering less than a threshold amount of drug or from delivering drug at less than a threshold rate, even if instructions received from computing device 108 instruct drug pump 302 to deliver less than a threshold amount.

[0090] It should be noted that safety module 318 is configured to continue operating drug pump 302 in the absence of instructions from delivery device control system 110 or computing device 108, for example, in the absence of instructions describing how much drug to deliver and when. Safety module 318 may be configured to continue operating drug pump 302 to deliver drug to person 102, for example, when delivery device control system 110 is out of communication range. Safety module 318 may access logic, default settings, or settings entered as part of a setup process, to name a few, that control how much drug drug pump 302 should deliver when instructions are not received from delivery device control system 110. Safety module 318 may implement various additional or different safeguards to ensure that the amount of drug delivered is not harmful to person 102.

[0091] Battery 320 is configured to provide power to operate drug pump 302, such as powering communications module 310 to send and receive data, powering drug delivery control unit 312 to deliver drug from drug reservoir 314 to person 102 via infusion set 304, and powering display module 316 to display information via display device 322. Battery 320 may be rechargeable (e.g., via a USB charging port or wirelessly) or replaceable. It should be appreciated that battery 320 may be configured in a variety of ways.

[0092] Although not shown, 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 the skin or inserted subcutaneously, for example, to measure systemic levels of a drug within person 102. Accordingly, the drug sensor may be included as part of infusion set 304, analyte monitoring device 104, or may be applied separately. In either case, such a sensor may be used in conjunction with safety module 318 and / or a dose prediction function. In this manner, drug measurements generated using the drug sensor may be used to prevent or detect drug ingestion, for example, to prevent a person receiving insulin from experiencing a hypoglycemic episode. By way of example, safety module 318 may shut off drug delivery by drug pump 302 based on the drug measurement, e.g., if safety module 318 detects that the level of the drug has exceeded a predetermined threshold. Based on the drug measurement, delivery device control system 110 may also, or alternatively, send a command to drug delivery system 106 to stop or temporarily halt drug delivery. In one or more implementations, the safety module 318 and / or the computing device 108 may also trigger an alert if the level of the medication exceeds a predetermined threshold. Physiologically, different thresholds may be determined for different people based on their medication sensitivity (e.g., insulin sensitivity), such that the aforementioned shutdown, alert, or cessation of medication delivery may be triggered at different medication levels for different people.

[0093] Having considered example environments and devices, we now consider some example details of techniques for automatically pausing and resuming drug delivery, according to one or more embodiments.

[0094] Automatically stopping and restarting drug delivery FIG. 4 illustrates an example system 400 for stopping and restarting drug delivery on demand.

[0095] In the illustrated example 400, the system includes a delivery device control system 110. The delivery device control system 110 is shown receiving a request 402 to stop delivery of a medication, e.g., to stop delivery of a medication via the medication delivery system 106. The request 402 includes a stop period 404 in this example, although in variations, the request may not include the stop period 404. Instead, the delivery device control system 110 may determine the stop period 404 in one or more variations.

[0096] In one or more implementations, the request 402 is responsive to or otherwise based on receipt of a user input. For example, the user input may be received via a user interface of the medication delivery system 106 or computing device 108 in association with one or more controls (e.g., buttons, menus, fields, etc.) operable to request that delivery of the medication be stopped. In variations, user input may be received in association with those same controls or one or more additional controls, etc. to specify the stop period 404. In response to receiving the request 402 (e.g., based on the user input), the delivery device control system 110 temporarily stops delivery of the medication.

[0097] In this particular example, delivery device control system 110 includes a delivery stop engine 406, a resume delivery engine 408, and a medication administration engine 410. Although delivery device control system 110 is depicted with these components, in variations, delivery device control system 110 includes more, fewer, or different components without departing from the spirit or scope of the described technology. Thus, the functionality described above and below may be performed by one or more components and / or by delivery device control system 110 different from those described herein.

[0098] According to the described technology, the delivery stop engine 406 determines a time to stop delivery of the medication to the user. In this example, for example, the delivery stop engine 406 determines to stop delivery of the medication in response to receiving the request 402, e.g., the delivery stop engine 406 determines to stop delivery of the medication substantially in real time after the request 402 is received or a certain amount of time after the request 402 is received. Alternatively or additionally, the delivery stop engine 406 is configured to process the request 402, extract the schedule time specified in the request 402 (not shown), and determine to stop delivery at the specified time.

[0099] The delivery stop engine 406 is also configured to output a delivery stop command 412. In one or more implementations, the delivery stop engine 406 or the delivery device control system 110 communicates the delivery stop command 412 to the medication delivery system 106. Broadly, the delivery stop command 412 instructs the medication delivery system 106 to stop delivering the medication at a time determined by the delivery stop engine 406. In one or more implementations, the delivery stop command 412 causes the medication delivery system 106 to stop delivering the medication substantially immediately upon receiving the command. Alternatively or additionally, the delivery stop command 412 includes a specified time to stop delivery, such that the medication delivery system 106 stops delivering the medication at the specified time.

[0100] The delivery resume engine 408 is shown to receive the pause period 404 as an input. In one or more implementations, the delivery resume engine 408 determines a time to resume delivery of the medication to the user. In this example, for example, the delivery resume engine 408 determines a time to resume delivery of the medication to the user based on the pause period 404. In one or more variations, the delivery resume engine 408 calculates a time to resume delivery of the medication based on the time for which delivery of the medication is stopped and based on the amount of time in the pause period 404, e.g., the delivery resume engine 408 adds the pause period 404 to the time for which delivery of the medication is stopped. Thus, in one or more implementations, in addition to receiving the pause period 404, the delivery resume engine 408 also receives (or otherwise has access to) the time for which delivery of the medication is stopped.

[0101] According to the described techniques, the resume delivery engine 408 outputs a resume delivery command 414 based on the determined time to resume delivery of the medication, which may further be based on the pause period 404 as described above. In one or more implementations, the resume delivery engine 408 or the delivery device control system 110 communicates the resume delivery command 414 to the medication delivery system 106. Broadly, the resume delivery command 414 instructs the medication delivery system 106 to resume delivery of the medication at a time after the time medication delivery was paused. In one or more implementations, the resume delivery command 414 causes the medication delivery system 106 to resume delivery of the medication substantially upon receiving the command. Alternatively or additionally, the resume delivery command 414 includes a specified time to resume delivery, and the medication delivery system 106 resumes delivery of the medication at the specified time, e.g., after medication delivery has been paused for the pause period 404.

[0102] In the depicted example 400, the resume delivery engine 408 is also shown to output a resume delivery instruction 418. In one or more implementations, the resume delivery instruction 418 may correspond to the resume delivery command 414 or may be a different communication. Note that the medication dosing engine 410 is shown to receive the resume delivery instruction 418. Broadly, the resume delivery instruction 418 indicates to the medication dosing engine 410 that the medication delivery system 106 is resuming delivery of medication to a user (e.g., person 102). Based on receiving the resume delivery instruction 418, the medication delivery engine 410 determines a dose of medication to deliver to the user. The medication dosage instruction 420 corresponds to the determined dose and instructs the medication delivery system 106 to deliver the determined dose, for example, after resuming delivery of medication in accordance with the resume delivery command 414. In summary, the resume delivery instructions 414 instruct the drug delivery system 106 when to resume delivery of the drug (e.g., the time to resume delivery), and the drug dosage instructions 420 instruct the drug delivery system 106 how much drug to deliver (e.g., the amount to deliver over time). Although not shown in subsequent figures, the drug dosing engine 410 may be used in various implementations to instruct the drug delivery system 106 as to how much drug to deliver before drug delivery is stopped and / or how much drug to deliver after drug delivery is resumed.

[0103] In one or more implementations, the medication dosing engine 410 determines the dosage to deliver upon resumption of delivery based on various data, including one or more of the analyte data 118, the pause duration 404, the time at which delivery is paused, the subsequent time at which delivery is resumed, and the sensor data 120, to name a few. The medication dosing engine 410 may also determine the dose to deliver based on “higher-level” determinations made from such data, such as one or more activities performed by the user while medication delivery was paused. This is because activities, such as exercise, performed by the user during the pause in medication delivery may affect the amount of medication to be delivered to the user so that suitable analyte levels are maintained. The medication dosing engine 410 may also determine the dosage 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 the pause in delivery. The medication dosing engine 410 may determine the dosage for delivery based on various data without departing from the spirit or scope of the described technology.

[0104] 5 shows an example system 500 for automatically stopping delivery of a medication 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 stops delivery of a medication based on sensor data 120. For example, the delivery device control system 110 stops delivery of a medication based on sensor data 120 and without receiving user input explicitly specifying that medication delivery should be stopped. This is in contrast to the previously described example 400, in which a request 402 to stop delivery is received.

[0105] This example 500 depicts a delivery device control system 110 acquiring sensor data 120. In accordance with the described technology, the delivery device control system 110 receives sensor data 120 from various sources 502, including, but not limited to, Global Positioning System (GPS) data, Wi-Fi information (e.g., Service Set Identifier (SS ID)), Bluetooth Low Energy (BLE) information, data generated using a cellular antenna (e.g., Long Term Evolution (LTE)), microphone data (e.g., audio 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 device's camera), 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 or different data for the same analyte from different sources), and medication data, to name a few. Additional examples of sensor data 120 from various sources 502 include, but are not limited to, measurements of various detected signals (e.g., biopotential measurements such as an electrocardiogram (ECG), electromyogram (EMG), or electroencephalogram (EEG)); acceleration experienced by a person at a position where the analyte-augmented wearable is worn; and optical signals such as a photoplethysmogram (PPG) that detects changes in blood volume), measurements of various physiological conditions (e.g., sweating, body temperature, heart rate, oxygen saturation (SpO2)), or indicia of detected events (e.g., exceeding or falling below a threshold, detecting the presence or absence of a particular compound), to name a few. As noted above, the drug delivery system 106, the computing device 108, and the IoT 114 may be sources 502 of such data. Alternatively or additionally, the delivery device control system 110 receives sensor data 120 from other sources 502, which may include or be associated with one or more sensors of various types.

[0106] In this example 500, the delivery device control system 110 includes a location prediction engine 124, an activity prediction engine 504, and a delivery stop engine 406. As described above and below, the delivery device control system 110 may, in variations, include more, fewer, or different components, and the functions discussed herein may be performed by one or more components different from those described, without departing from the spirit or scope of the described technology.

[0107] In one or more implementations, the delivery device control system 110 determines when to stop delivery of the medication based on predicting or otherwise detecting a user's location 506 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 stop delivery based on the location 506. Alternatively, or additionally, the delivery device control system 110 determines when to stop delivery based on the 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 location prediction engine 124 and the location 506 are shown with dashed lines to indicate that they are optional in at least one variation.

[0108] In the context of the illustrated embodiment 500, the location prediction engine 124 determines or otherwise predicts a location 506 of a user (e.g., person 102) based on the sensor data 120. The location prediction engine 124 outputs the location 506. The activity prediction engine 504 determines or otherwise predicts a user's activity 508, such as an activity the user is currently performing. Examples of activities include, but are not limited to, eating, sleeping, exercise (e.g., aerobic, anaerobic, partial aerobic and partial anaerobic, high-intensity interval training, running, rowing, hiking, bicycling, weightlifting, yoga, Pilates, sports, etc.), work (e.g., which may cause stress), showering, watching a movie, watching television, attending an event (e.g., a sporting event or concert), dancing, reading, cleaning, caring for children, or driving, to name a few.

[0109] As mentioned above, the activity prediction engine 504 optionally determines the user's activity 508 based on the user's location 506. By way of example, the user's presence at the gym, in the shower, in bed, and / or sitting in a chair in a workspace may be informative regarding the activity being performed 508. Alternatively or additionally, the activity prediction engine 504 determines the user's activity 508 based on sensor data 120, for example, based on heart rate data (indicative of exercise).

[0110] Based on the activity 508, the delivery stop engine 406 determines to stop delivery of the medication to the user. In one or more variations, this includes the time to stop delivery. Further, the delivery stop engine 406 outputs a delivery stop instruction 412, e.g., to stop delivery at the time. For example, the delivery stop engine 406 outputs the delivery stop instruction 412 to the medication delivery system 106, which instructs the medication delivery system 106 to stop delivering the medication to the user. The delivery stop instruction 412 is one example of an instruction 122.

[0111] With regard to 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 SSIDs of networks accessible to the computing device 108), based on both Wi-Fi information and sound data, based on both Wi-Fi information and light data, or based on both Wi-Fi information and heart rate data, to name a few. It should be understood 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 user's location 506. Indeed, the location prediction engine 124, in one or more implementations, may use more than two types of data, e.g., more than first sensor data and second sensor data, to predict the user's location 506.

[0112] In at least one implementation, the location prediction engine 124 predicts the location 506 of a user (e.g., a person 102) based on the location of the computing device 108 associated with the user. For example, the location prediction engine 124 predicts the user's location 506 based on the location of the user's mobile phone or smartwatch. In such implementations, this is based on the assumption that the user is in proximity to the associated computing device, e.g., the computing device is worn by the user or carried within 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 smartwatch) and then attributes the device's location to the user. Alternatively or additionally, 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 smartwatch) and then uses sensor data 120 obtained from the computing device 108 (e.g., proximity data, infrared data, temperature data, etc.) to further refine the location and / or determine the user's location relative to the computing device 108. This may be the case when the computing device 108 is not being worn by the user or is not "on" for the user, such as when the user is sleeping or taking a shower. In one or more implementations, the location prediction engine 124 uses first sensor data to generate a "coarse" prediction of the location 506 and uses second sensor data (and based on the coarse location prediction) to generate a "refined" prediction of the location 506.

[0113] The location prediction engine 124 may be configured in various ways without departing from the spirit or scope of the described technology. For example, the location prediction engine 124 may be configured as or include one or more machine learning models. Alternatively or additionally, the location prediction engine 124 may include or have access to a mapping of locations (e.g., restaurants, gyms, homes, stores, roads, and other businesses) to geographic coordinates, such that, given precise geographic coordinates, the location predictor 124 may attribute a user's presence to a location according to the mapping.

[0114] In at least one embodiment, the first portion of the sensor data 120 may not be suitable for predicting the user's geographic coordinates with sufficient accuracy for the location prediction engine 124 to identify at least two nearby locations. Instead, the first portion of the sensor data 120 may be suitable for predicting an area (e.g., a radius around a point) where the user is likely to be located, such that the area includes at least two candidate locations. Thus, in one or more implementations, the location prediction engine 124 uses at least a second portion of the sensor data 120 to identify candidate locations and select a location 506 from the multiple candidate locations. For example, in a scenario where a bedroom and a bathroom are adjacent, the location prediction engine 124 uses the second portion of the sensor data 120 to narrow down the candidate locations and select either the bedroom or the bathroom. This is noteworthy because activities that a user participates in at different locations may be associated with the cessation of medication delivery (e.g., bathing in the bathroom) or the cessation of medication delivery (e.g., sleeping in the bedroom). Similarly, consider an example where a restaurant and a gym are both located in a long, narrow shopping center. In this scenario, it is important to be able to determine whether the user is at the gym (and exercising) or at a restaurant (and eating) because insulin may need to be suppressed if the user is exercising but increased if the user is eating.

[0115] With regard to how the activity prediction engine 504 predicts an activity 508 in which the user is or is likely to 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 or user interaction to confirm the activity 508 (other than that used to determine the location 506). In at least one other variation, the activity prediction engine 504 predicts the activity 508 based on the predicted location 506 and at least one other type of data, such as sensor data 120 and / or data describing the user's interaction with the device. Examples of such sensor data 120 include sound data (e.g., indicative of sounds confirming the user is asleep), light data (e.g., indicative of a dark location associated with a higher likelihood that the user is asleep), accelerometer data (e.g., indicative of the device's location on the nightstand associated with a higher likelihood that the user is asleep), etc. Examples of such user interactions include user interactions to confirm a predicted activity 508, to input an activity, etc. As described above, in one or more implementations, the location prediction engine 124 predicts an activity 508 based on the sensor data 120 without receiving a predicted or otherwise determined location 506.

[0116] It will be appreciated that in some configurations, the location prediction engine 124 detects the user's location 506 in real time (or substantially in real time) as the user's location changes, 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 stopping medication delivery. Thus, in one or more implementations, the delivery stop engine 406 generates the delivery stop instruction 412 only if the predicted activity 508 is associated with stopping medication delivery (and medication delivery has not already been stopped).

[0117] In one or more implementations, the delivery stop engine 406 is configured as a machine learning model that receives the activity 508 (and, in some implementations, the activity state) as input and outputs the delivery stop instruction 412. In such implementations, the delivery stop engine 406 may be trained using training data that pairs the activity (and, in some implementations, the activity state) with a tag that indicates whether to deliver medication while the activity is being performed or a tag that indicates not to deliver medication while the activity is being performed. As an example, the machine learning model may be exposed to (e.g., receive as input) an activity and attempt to output an instruction on whether to administer medication during that activity. The system may then compare the output with the tag paired with the input in the training data. Based on this comparison, the internal weights of the machine learning model may be adjusted. For example, if the output matches the tag paired in the training data, the weight may be adjusted (e.g., strengthened) to promote the output during future iterations. However, if the output does not match the tag paired in the training data, the weight may be adjusted to suppress the output during future iterations. The machine learning model may thus be trained over multiple iterations.

[0118] Alternatively or additionally, the delivery halt engine 406 may obtain an indication of whether the activity 508 corresponds to an activity for which a drug should be delivered or an activity for which a drug should not be delivered, such as from a mapping of activities (and in some implementations, states) to delivery or non-delivery of a drug. By way of example, a library may include mappings that map different activities to delivery or non-delivery of a drug. This information may be stored, for example, in a database. In one or more implementations, the mappings may be approved by one or more clinicians.

[0119] This information may be entered into and maintained in the system (e.g., in a database). In one or more implementations, such a 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 additionally, 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. As new activities are added, either or both of the remote and local mappings may be updated. In one or more implementations, the mapping may be personalized to the user, such as to map activities to the user's historical actions to, for example, stop or resume drug delivery. In such implementations, the mapping may be provided by the user (e.g., via user input on the user's computing device), by a healthcare provider (e.g., via a healthcare provider portal), or determined by the system based on sensor data.

[0120] 6 shows an example system 600 for automatically resuming medication delivery based on sensor data. The illustrated embodiment 600 includes a delivery device control system 110.

[0121] In this example 600, the delivery device control system 110 automatically resumes delivery of the medication based on the sensor data 120. For example, the delivery device control system 110 resumes delivery of the medication based on the sensor data 120 and without explicitly receiving user input to resume medication delivery. This is in contrast to the previous example 400, in which the request to stop delivery 402 includes the stop period 404, such that the time to resume delivery is determinable based on the stop period 404.

[0122] In this example 600, the delivery device control system 110 is shown acquiring sensor data 120, which, as described above, the delivery device control system 110 may acquire from various sources 502. Additionally, the delivery device control system 110 includes a location prediction engine 124, an activity prediction engine 504, and a delivery resume engine 408. As noted above and below, the delivery device control system 110 may, in variations, include more, fewer, or different components, and the functions discussed herein may be performed by one or more components different from those described, without departing from the spirit or scope of the described technology.

[0123] In one or more implementations, the delivery device control system 110 determines when to resume drug delivery 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 location 506 based on which drug delivery was automatically stopped. In one example, for example, location 506 corresponds to a shower, and the subsequent location 602 corresponds to a location other than the shower, e.g., a location that is not a shower, a closet, or a bedroom. In another example, location 506 corresponds to a gym, and the subsequent location 602 corresponds to a location other than the gym, e.g., a parking lot for the gym, a locker room in the same facility as the gym, or on a road driving away from the gym.

[0124] Similarly, in one or more implementations, the subsequent activity 604 is different from the activity 508 at which drug delivery was automatically stopped. In one example, for example, the activity 508 corresponds to showering, and the subsequent activity 604 corresponds to an activity other than showering, such as not showering, brushing hair, or grooming. In one example, for example, the activity 508 corresponds to playing basketball, and the subsequent activity 604 corresponds to an activity other than playing basketball, such as not playing basketball, walking to the locker room, walking to a parking lot, or driving a car.

[0125] In one or more implementations, the activity prediction engine 504 determines the 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 location prediction engine 124 and the subsequent location 602 are shown with dashed lines to indicate that they are optional in at least one variation.

[0126] 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 location prediction engine 124 outputs the subsequent location 602. The activity prediction engine 504 determines or otherwise predicts a subsequent activity 604 of the user, such as an activity the user is currently performing. In one or more implementations, the subsequent activity 604 indicates that the user has finished performing or is no longer performing the activity 508, e.g., an "activity state" that is different from a state "during" the activity 508 (or "mid-activity"). Alternatively or additionally, the subsequent activity 604 corresponds to a different activity performed by the user.

[0127] Based on the subsequent activity 604, the resume delivery engine 408 determines to resume delivery of the medication to the user. Further, the resume delivery engine 408 outputs a resume delivery instruction 414, e.g., to automatically resume delivery of the medication without user interaction to resume delivery. For example, the resume delivery engine 408 outputs the resume delivery instruction 414 to the medication delivery system 106, which instruction causes the medication delivery system 106 to resume delivery of the medication to the user (e.g., person 102). The resume delivery instruction 414 is one example of an instruction 122.

[0128] With regard to how the location prediction engine 124 predicts the next location 602, the location prediction engine 124 may do so in a manner similar to how the location prediction engine 124 predicts location 506. The activity prediction engine 504 may also predict a subsequent activity 604, similar to how the activity prediction engine 504 predicts an activity 508. Notably, not all activities are associated with resumption of medication delivery. Thus, in one or more implementations, the resume delivery engine 408 generates the resume delivery instruction 414 only if the predicted subsequent activity 604 is associated with resumption of medication delivery (and medication delivery has not yet resumed).

[0129] In one or more implementations, the resume delivery engine 408 is configured as a machine learning model that receives the subsequent activity 604 (and in some implementations, the activity state) as input and outputs the resume delivery instruction 414. In such implementations, the resume delivery engine 408 may be trained using training data that pairs the activity (and in some implementations, the activity state) with a tag that indicates that the medication is to be delivered while the activity is being performed, or a tag that indicates that the medication is not to be delivered while the activity is being performed.

[0130] Alternatively or additionally, the delivery resume engine 408 may obtain an indication of whether the subsequent activity 604 corresponds to an activity for which a drug should be delivered or an activity for which a drug should not be delivered, such as from a mapping of activities (and, in some implementations, states) to delivery or non-delivery of a drug. By way of example, a library may include mappings that map different activities to delivery or non-delivery of a drug. This information may be stored, for example, in a database. In one or more implementations, the mappings may be approved by one or more clinicians. In the context of using the determined locations to stop and resume delivery of a drug (e.g., without determining an activity), consider the following discussion of FIGS. 7 and 8.

[0131] FIG. 7 illustrates an example system 700 that automatically stops medication delivery based on a user's location determined using sensor data.

[0132] The illustrated example 700 includes a delivery device control system 110. In this example 700, the delivery device control system 110 automatically stops medication delivery based on a location 506, as determined based on sensor data 120. In contrast to example 500, the delivery stop engine 406 is shown receiving the location 506 rather than an activity. This represents that in one or more implementations, the delivery device control system 110 is configured to determine when to stop medication delivery based solely on the location 506, for example, without using an activity 508. As described above and below, the location prediction engine 124 predicts the user's location 506 based on the sensor data 120, which may be obtained from any of a variety of sources 502.

[0133] Based on the position 506, the delivery stop engine 406 determines to stop delivery of the medication to the user. In one or more variations, this includes the time to stop delivery. Further, the delivery stop engine 406 outputs a delivery stop command 412 to cause delivery to stop, for example, automatically at that time. For example, the delivery stop engine 406 outputs the delivery stop command 412 to the medication delivery system 106, which commands the medication delivery system 106 to stop delivering the medication to the user. As described above, the delivery stop command 412 is one example of an command 122.

[0134] FIG. 8 illustrates an example system 800 that automatically resumes medication delivery based on the user's subsequent location determined using sensor data.

[0135] The illustrated example 800 includes a delivery device control system 110. In this example 800, the delivery device control system 110 automatically resumes medication delivery based on a subsequent location 602 determined based on sensor data 120. In contrast to example 600, the delivery resume engine 408 is shown receiving the subsequent location 602 rather than a subsequent activity. This represents that in one or more implementations, the delivery device control system 110 is configured to determine when to resume medication delivery based solely on the user's subsequent location 602, for example, without using a subsequent activity 604. As described above and below, the location prediction engine 124 predicts the user's subsequent location 602 based on sensor data 120, which may be obtained from any of a variety of sources 502.

[0136] Based on the subsequent position 602, the resume delivery engine 408 determines to resume delivery of the medication to the user. In one or more variations, this includes the time to resume delivery. Further, the resume delivery engine 408 outputs a resume delivery instruction 414, e.g., to automatically resume delivery at that time. For example, the resume delivery engine 408 outputs the resume delivery instruction 414 to the medication delivery system 106, which instruction causes the medication delivery system 106 to resume delivery of the medication to the user. As mentioned above, the resume delivery instruction 414 is one example of an instruction 122. Examples of user interfaces that may be output in connection with automatically stopping and resuming delivery of a medication are discussed immediately below.

[0137] 9 shows an example user interface 900 for displaying a stop delivery notification. The illustrated example 900 includes an embodiment of a computing device 108 displaying an example user interface 902 via a display device, e.g., a touchscreen.

[0138] Here, the user interface 902 includes a delivery stop notification 904 indicating that delivery of the medication (e.g., via the medication delivery system 106) has automatically stopped. The delivery stop notification 904 notifies the user of the stoppage, as the user may not be aware that medication delivery has stopped due to the automatic stoppage. While the delivery stop notification 904 is shown as being output (e.g., displayed) by the computing device 108, it should be understood that the delivery stop notification 904 may be output by any one or more of the analyte monitoring device 104, the medication delivery system 106, or the computing device 108. The delivery stop notification 904 may also be output by one or more additional devices without departing from the spirit or scope of the described technology. Furthermore, while the delivery stop notification 904 is shown in this example 900 as being displayed, the delivery stop notification 904 may be output in other manners 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.

[0139] In this example, the activity corresponds to bathing predicted based on sensor data 120, which may indicate, for example, the user being in a bathtub or shower (e.g., location 506), being exposed to water and / or soap, using products and / or items associated with bathing, etc. Additionally or alternatively, sensor data 120 may include sound data capturing, for example, one or more sounds of bathing or showering.

[0140] 10 illustrates an example user interface 1000 displaying a resumed delivery notification. The illustrated embodiment 1000 includes an embodiment of a computing device 108 displaying an example user interface 1002 via a display device, e.g., a touchscreen.

[0141] Here, the user interface 1002 includes a delivery resumed notification 1004 indicating that delivery of the medication (e.g., via the medication delivery system 106) has automatically resumed. The delivery resumed notification 1004 notifies the user of the resumed delivery, as the user may not be aware that medication delivery has resumed due to the automatic resumption. While the delivery resumed notification 1004 is shown as being output (e.g., displayed) by the computing device 108, it should be understood that the delivery resumed notification 1004 may be output by any one or more of the analyte monitoring device 104, the medication delivery system 106, or the computing device 108. The delivery resumed notification 1004 may also be output by one or more additional devices without departing from the spirit or scope of the described technology. Additionally, although delivery resume notification 1004 is shown as being displayed in this example 1000, delivery resume notification 1004 may be output in other manners 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.

[0142] In this example, the subsequent activity corresponds to a prediction based on sensor data 120 that the user is no longer bathing, which may indicate, for example, that the user is no longer in the bathtub or shower (e.g., subsequent location 602), is no longer exposed to water and / or soap, is no longer using bath-related products and / or items, etc. Additionally or alternatively, sensor data 120 includes sound data capturing, for example, one or more sounds corresponding to post-bath or post-shower activity or one or more sounds indicating that the user is no longer bathing or showering.

[0143] 11 illustrates a first example combination of devices for implementing automatic pausing and resuming of drug delivery 1100. The illustrated embodiment 1100 includes an analyte monitoring device 104, a drug delivery system 106, and a computing device 108 having a delivery device control system 110.

[0144] According to the described techniques, the analyte monitoring device 104, the drug delivery system 106, and the computing device 108 may be communicatively coupled, for example, via the network 116 or via some other wireless connection (e.g., BLE), to implement any of the automatic pausing and resuming of drug delivery techniques described above and below. In variations, the analyte monitoring device 104, the drug delivery system 106, and the computing device 108 are operatively connected to implement automatic pausing and resuming of drug delivery as a closed-loop system, an open-loop system, or a partially open-loop system. In this example, the drug delivery system 106 is shown as a wearable pump (e.g., an insulin pump) having an infusion set applied to the person 102 and delivering drug via the infusion set at an insertion site.

[0145] As a closed-loop system, the analyte monitoring device 104, the drug delivery system 106, and the computing device 108 are configured to monitor analytes of the person 102 wearing the analyte monitoring device 104 and to automatically cause the drug delivery system 106 to stop delivering the drug based on one or more of the location 506 of the person 102 and / or an activity that the person 102 is predicted to engage in without user interaction. Similarly, the analyte monitoring device 104, the drug delivery system 106, and the computing device 108, when implemented as a closed-loop system, are configured to automatically cause the drug delivery system 106 to resume delivering the drug based on one or more of the location 506 of the person 102 and / or an activity that the person 102 is predicted to engage in without user interaction.

[0146] In contrast, a partially opened system may require the user to confirm the cessation of drug delivery before it is stopped by the system, e.g., the user may be required to provide approval for the recommended cessation of drug delivery via the displays of the analyte monitoring device 104, the drug delivery system 106, and / or the computing device 108, before it is automatically stopped by the drug delivery system 106. Once validated, the drug delivery system 106 may stop delivering the drug as recommended by the delivery device control system 110. A partially opened system may also require the user to confirm the resumption of drug delivery before it is resumed by the system, e.g., the user may be required to provide approval for the recommended resumption of drug delivery via the displays of the analyte monitoring device 104, the drug delivery system 106, and / or the computing device 108, before it is automatically resumed by the drug delivery system 106.

[0147] In an open system, the delivery device control system 110 may simply output one or more controls (e.g., displayed via the analyte monitoring device 104, the drug delivery system 106, or the computing device 108) that a user may interact with to generate a request 402 to stop delivery of the drug via the drug delivery system 106.

[0148] 12 illustrates a second example combination of devices for implementing automatic pausing and resuming of drug delivery 1200. The illustrated embodiment 1200 includes a drug delivery system 106 and a computing device 108 having a delivery device control system 110.

[0149] However, the illustrated embodiment 1200 does not include the analyte monitoring device 104. This represents a scenario in which the drug delivery system 106 and the computing device 108 are not operably connected to the analyte monitoring device 104. In such a configuration, the delivery device control system 110 can determine to automatically stop and resume drug delivery without using the analyte data 118. Instead, the delivery device control system 110 is associated with the computing device 108 and predicts the location 506 of a user wearing the drug delivery system 106 (e.g., a pump), and / or the delivery device control system 110 uses other data, e.g., sensor data 120, to predict the user's activity 508. Examples of such other data are described above but may include, for example, GPS data and data generated by other sensors in the computing device. Based on the location 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 stop and resume drug delivery.

[0150] As in the example shown in FIG. 11, the drug delivery system 106 and computing device 108 may be operably connected to implement automatic stopping and resumption of drug delivery as a closed-loop system, an open-loop system, or a partially open-loop system.

[0151] Having described exemplary details of a technique for automatically pausing and resuming drug delivery, we now consider some example procedures to illustrate additional aspects of this technique.

[0152] Exemplary Procedure This section describes example procedures for automatically stopping and resuming drug delivery. Aspects of the procedures may be implemented in hardware, firmware, software, or a combination thereof. The procedures are illustrated as a set of blocks specifying operations to be performed by one or more devices and are not necessarily limited to the order shown for performing the operations by each block. In at least some implementations, the procedures are performed by a delivery device control system, such as delivery device control system 110.

[0153] FIG. 13 illustrates a procedure 1300 in one exemplary implementation of automatic suspension and resumption of drug delivery after a suspension period.

[0154] A request to stop delivery of medication to a user is received (block 1302). By way of example, the delivery device control system 110 receives the request 402 to stop delivery of medication. In one or more implementations, the request 402 is responsive to or otherwise based on receipt of user input. For example, the user input may be received via a user interface of the medication delivery system 106 or computing device 108 in association with one or more controls (e.g., buttons, menus, fields, etc.) operable to request that delivery of medication be stopped.

[0155] The medication delivery system is controlled to stop delivery of the medication to the user (block 1304). By way of example, in response to receiving the request 402 (e.g., based on user input), the delivery device control system 110 stops delivery of the medication. In one or more implementations, a delivery stop engine 406 of the delivery device control system 110 determines a time when delivery of the medication should be stopped and outputs a delivery stop command 412. The delivery stop command is communicated to the medication delivery system 106. Broadly, the delivery stop command 412 instructs the medication delivery system 106 to stop delivering the medication at the time determined by the delivery stop engine 406.

[0156] The drug delivery system is controlled to automatically resume drug delivery to the user after the suspension period (block 1306). By way of example, the delivery device control system 110 controls the drug delivery system 106 to automatically resume drug delivery to the user after the suspension period 404. In one or more implementations, the suspension period 404 is specified by the user and received with the request 402. Alternatively, the suspension period 404 may correspond to a predetermined period of time, e.g., 15 minutes, 30 minutes, 45 minutes, etc. To resume drug delivery, a delivery resume engine 408 of the delivery device control system 110 outputs a delivery resume command 414 that is communicated to the drug delivery system 106. Broadly, the delivery resume command 414 instructs the drug delivery system 106 to resume delivery of the drug at a time after the time drug delivery was suspended.

[0157] FIG. 14 illustrates a procedure 1400 in one exemplary implementation of automatic pausing and resuming of drug delivery based on activity.

[0158] Sensor data is acquired from one or more sensors (block 1402). By way of example, the delivery device control system 110 acquires the sensor data 120. In accordance with the described techniques, the delivery device control system 110 can be configured to receive the sensor data 120 from a variety of different sources 502.

[0159] An activity to be performed by the user is predicted based on the sensor data (block 1404). For example, the activity prediction engine 504 of the delivery device control system 110 predicts an activity 508 to be performed by the user based on the 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 user's presence at the gym, in the shower, in bed, and / or sitting in a chair in a workspace may provide significant information regarding the activity 508 being performed. Alternatively or additionally, the activity prediction engine 504 determines the user's activity 508 based on other sensor data 120, such as based on the user's heart rate data indicating that the user is exercising.

[0160] The medication delivery system is controlled to stop delivery of medication to the user while the activity is being performed (block 1406). For example, based on the activity 508, the delivery stop engine 406 of the delivery device control system 110 determines to stop delivery of medication to the user and outputs a delivery stop command 412 to stop the delivery. For example, the delivery stop engine 406 outputs the delivery stop command 412 to the medication delivery system 106, the command instructing the medication delivery system 106 to deliver the medication to the user.

[0161] The medication delivery system is controlled to automatically resume delivery of medication to the user after performance of the activity is completed (block 1408). By way of example, the delivery device control system 110 controls the medication delivery system 106 to resume delivery of medication to the user after performance of the activity 508 is fully completed. In one or more implementations, the activity prediction engine 504 determines that the activity has been performed by the user and communicates an activity execution instruction to the delivery resume engine 408. The delivery resume engine 408 of the delivery device control system 110 outputs a delivery resume instruction 414 that is communicated to the medication delivery system 106. Broadly, the delivery resume instruction 414 instructs the medication delivery system 106 to resume delivery of medication.

[0162] FIG. 15 illustrates a procedure 1500 in one exemplary implementation of automatic pausing and resuming of drug delivery based on a user's location.

[0163] The medication delivery system is controlled to stop medication delivery to the user at a first time based on the user's location (block 1502). For example, the delivery device control system controls the medication delivery system 106 to stop medication delivery to the user at a first time based on the user's location 506. As described above and below, the location prediction engine 124 predicts the user's location 506 based on sensor data 120, which may be obtained from any of a variety of different sources 502. In one or more implementations, based on the location 506, the delivery stop engine 406 determines to stop delivery of medication to the user. In one or more variations, this includes a time to stop delivery. Further, the delivery stop engine 406 outputs a delivery stop command 412 to cause delivery to stop, for example, automatically at that time. For example, the delivery stop engine 406 outputs the delivery stop command 412 to the medication delivery system 106, causing the medication delivery system 106 to stop delivering medication to the user. As described above, the delivery stop command 412 is one example of an command 122.

[0164] The medication delivery system is controlled to resume medication delivery to the user at a second time based on the user's subsequent location (block 1504). For example, the delivery device control system 110 automatically resumes medication delivery based on the subsequent location 602. As described above and below, the location prediction engine 124 predicts the user's subsequent location 602 based on sensor data 120, which may be obtained from any of a variety of different sources 502. In one or more implementations, the delivery resume engine 408 outputs a delivery resume instruction 414 to, for example, automatically resume delivery at that time. For example, the delivery resume engine 408 outputs the delivery resume instruction 414 to the medication delivery system 106, which instructs the medication delivery system 106 to resume delivery of medication to the user.

[0165] In response to the resumption of drug delivery, the drug delivery system is controlled to deliver the drug to the user (block 1506). By way of example, in response to the resumption of drug delivery, the delivery device control system controls the drug delivery system 106 to deliver the drug to the user.

[0166] Having described example procedures according to one or more implementations, we now turn to example systems and devices that may be utilized to implement the various techniques described herein.

[0167] Exemplary Systems and Devices 16 shows an embodiment of a system, generally at 1600, including an example computing device 1602, which represents one or more computing systems and / or devices that may perform the various techniques described herein. This is illustrated through the inclusion of delivery device control system 110. Computing device 1602 may be, for example, a service provider's server, a device associated with a client (e.g., a client device), an on-chip system, and / or any other suitable computing device or computing system.

[0168] The illustrated exemplary computing device 1602 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 further include a system bus or other data and instruction transfer system that couples various components together. The system bus may include any one or combination of different bus structures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and / or a processor or local bus utilizing any of a variety of bus architectures. Various other examples, such as control and data lines, are also contemplated.

[0169] Processing system 1604 represents functionality for performing one or more operations using hardware. Accordingly, processing system 1604 is illustrated as including hardware elements 1610, which may be configured as a processor, functional blocks, etc. This may also include implementation in hardware as an application-specific integrated circuit or other logic device formed using one or more semiconductors. Hardware elements 1610 are not limited by the material from which they are formed or the processing mechanisms employed therein. For example, a processor may be comprised of semiconductor(s) and / or transistors (e.g., an electronic integrated circuit (IC)). In this context, processor-executable instructions may be electronically executable instructions.

[0170] 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 non-volatile media (such as read-only memory (ROM), flash memory, optical disks, magnetic disks, etc.). Memory / storage 1612 may include fixed media (e.g., RAM, ROM, fixed hard drives, etc.) as well as removable media (e.g., flash memory, removable hard drives, optical disks, etc.). Computer-readable medium 1606 may also be configured in a variety of other ways, as described further below.

[0171] Input / output interface(s) 1608 represent functionality that allows a user to input commands and information into computing device 1602 and that allows information to be presented to a user and / or other components or devices using various input / output devices. Example input devices include a keyboard, a cursor control device (e.g., a mouse), a microphone, a scanner, touch functionality (e.g., a capacitive or other sensor configured to detect physical contact), a camera (e.g., employing visible wavelengths or non-visible wavelengths such as infrared frequencies to recognize movements as contactless gestures), etc. Examples of output devices include a display device (e.g., a monitor or projector), speakers, a printer, a network card, a tactile response device, etc. Accordingly, computing device 1602 may be configured in a variety of ways to support user interaction, as described further below.

[0172] Various technologies may be described herein in the general context of software, hardware elements, or program modules. Generally, such modules include routines, programs, objects, elements, components, data structures, etc. that perform particular tasks or implement particular abstract data types. As used herein, the terms "module," "functionality," and "component" generally refer to software, firmware, hardware, or combinations thereof. Aspects of the technology described herein are platform-independent, meaning that the technology can be implemented on a variety of commercial computing platforms having a variety of processors.

[0173] An implementation of the described modules and techniques may be stored on or transmitted across some form of computer-readable media. Computer-readable media may include a variety of media that can be accessed by computing device 1602. By way of example, and not limitation, computer-readable media may include “computer-readable storage media” and “computer-readable signal media.”

[0174] A "computer-readable storage medium" may refer to a medium and / or device that enables persistent and / or non-transitory storage of information, as opposed to merely a signal transmission, carrier wave, or signal itself. Thus, a computer-readable storage medium refers to a non-signal-bearing medium. A computer-readable storage medium includes hardware, such as volatile and non-volatile, removable and non-removable media, and / or storage devices implemented in any method or technology suitable for storing information, such as computer-readable instructions, data structures, program modules, logic elements / circuits, or other data. Examples of computer-readable storage media may include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disk (DVD) or other optical storage, hard disk, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device, or other storage device, tangible media, or any article of manufacture suitable for storing the desired information and that can be accessed by a computer.

[0175] A "computer-readable signal medium" may refer to a signal-bearing medium configured to transmit instructions to hardware in the computing device 1602, such as over a network. Signal media may typically embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, data signal, or other transport mechanism. Signal media also includes 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 include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media.

[0176] As previously described, hardware elements 1610 and computer-readable media 1606 represent modules, programmable device logic, and / or fixed device logic implemented in hardware that may be used in some embodiments to implement at least some aspects of the technology described herein, such as to execute one or more instructions. Hardware may include integrated circuits or components of on-chip systems, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), and other implementations in silicon or other hardware. In this context, hardware may operate as a processing device that executes program tasks defined by instructions and / or logic embodied in the hardware, as well as hardware utilized to store instructions for execution, such as the computer-readable storage media previously described.

[0177] A combination of the foregoing may be used to implement the various techniques described herein. Accordingly, software, hardware, or executable modules may be implemented on some form of computer-readable storage medium and / or as one or more instructions and / or logic embodied by one or more hardware elements 1610. Computing device 1602 may be configured to implement specific instructions and / or functionality corresponding to the software and / or hardware modules. Thus, implementation of modules executable as software by computing device 1602 may be achieved at least partially in hardware, for example, through the use of computer-readable storage media and / or hardware elements 1610 of processing system 1604. The instructions and / or functionality may be executable / operable by one or more articles of manufacture (e.g., one or more computing devices 1602 and / or processing system 1604) to implement the techniques, modules, and examples described herein.

[0178] The techniques described herein may be supported by various configurations of computing device 1602 and are not limited to any particular implementation of the techniques described herein. This functionality may also be implemented in whole or in part through the use of a distributed system, such as on a "cloud" 1614 via platform 1616, as described below.

[0179] Cloud 1614 includes and / or represents a platform 1616 for resources 1618. Platform 1616 abstracts the underlying functionality of the hardware (e.g., servers) and software resources of cloud 1614. Resources 1618 may include applications and / or data that may be utilized while computer processing is running on a server remote from computing device 1602. Resources 1618 may also include services provided over the Internet and / or over a subscriber network, such as a cellular network or Wi-Fi network.

[0180] Platform 1616 may abstract resources and functionality for connecting computing device 1602 with other computing devices. Platform 1616 may also serve to abstract resource scaling, providing a level of scale corresponding to demand faced by resources 1618 implemented via platform 1616. Thus, in embodiments of interconnected devices, implementations of functionality described herein may be distributed throughout system 1600. For example, functionality may be implemented partially on computing device 1602 as well as via platform 1616, which abstracts functionality of cloud 1614.

[0181] conclusion 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 particular features or acts described. Rather, the particular features and acts are disclosed as exemplary forms of implementing the claimed subject matter. [Explanation of symbols]

[0182] 100 Environment 102 people 104 Analyte Monitoring Devices 106 Drug Delivery Systems 108 Computing Devices 110 Delivery Device Control System 112 Health Monitoring Platform 114 Internet of Things 116 Network 118 Analyte Data 120 Sensor Data 122 Command 124 Location Prediction Engine 126 User Data 128 storage devices 130 Monitoring Services 200 Examples 202 Analyte Sensor 204 Sensor Module 206 Skin 208 Transmitter 210 adhesive pad 212 Analyte Measurements 214 Supplementary Sensor Information 300 Implementation 302 Chemical Pump 304 Infusion Set 306 Tube 308 Injection site 310 Communication Module 312 Drug delivery control unit 314 Drug Reservoir 316 Display Module 318 Safety Module 320 Battery 322 Display Devices 400 Examples 402 request 404 Suspension Period 406 Delivery Stop Engine 408 Resume Delivery Engine 410 Drug Delivery Engine 412 Order to stop delivery 414 Order to resume service 420 Drug Dosage Orders 500 Examples 502 Source 504 Activity Prediction Engine 506 position 508 activities 600 Examples 602 Subsequent Position 604 Subsequent Activities 900 Examples 902 User Interface 904 Notice of suspension of delivery 1000 Examples 1002 User Interface 1004 Notification of resumption of delivery 1100 Example 1200 Example 1300 steps 1400 steps 1500 steps 1600 System 1602 Computing Devices 1604 Processing System 1606 Computer-readable medium 1608 I / O interface 1610 Hardware Elements 1612 Memory / Storage 1614 Cloud 1616 Platform 1618 resources

Claims

1. 1. A system comprising: one or more sensors; a medication delivery system configured to deliver a medication to a user; 1. A delivery device control system, comprising: controlling the medication delivery system to suspend delivery of the medication to the user in response to a request initiated by the user and to automatically resume delivery of the medication to the user after a suspension period has elapsed; a delivery device control system configured to control the medication delivery system to automatically stop delivery of the medication to the user based on first sensor data acquired from the one or more sensors, and to automatically resume delivery of the medication to the user based on second sensor data acquired from the one or more sensors.

2. 2. The system of claim 1, wherein the delivery device control system is further configured to control the medication delivery system to automatically stop delivery of the medication to the user based on the first sensor data indicating performance of an activity by the user, and to automatically resume delivery of the medication to the user based on the second sensor data indicating performance of the activity has been completed.

3. 3. The system of claim 1 or 2, wherein the delivery device control system is further configured to control the medication delivery system to automatically stop delivery of the medication to the user based on the first sensor data indicating the user is at a certain location, and to automatically resume delivery of the medication to the user based on second sensor data indicating the user is at a subsequent location.

4. The system of any one of claims 1 to 3, further comprising an analyte monitoring device connected to the drug delivery system to form a closed loop system.

5. 5. The system of claim 4, wherein the analyte monitoring device includes a wearable glucose monitoring device and the drug delivery system comprises a wearable insulin pump.

6. The system of claim 4 , wherein the delivery device control system is implemented in a computing device wirelessly coupled to the medication delivery system and the analyte monitoring device.

7. The system of claim 4 , wherein the delivery device control system is implemented in the analyte monitoring device.

8. The system of any one of claims 1 to 7, wherein the delivery device control system is implemented in the medication delivery system.

9. 1. A method, comprising: receiving a request to stop delivery of medication to a user; controlling a medication delivery system to stop delivery of the medication to the user; and controlling the drug delivery system to automatically resume drug delivery to the user after a period of inactivity.

10. 10. The method of claim 9, wherein the drug delivery system automatically resumes drug delivery to the user after the suspension period has elapsed, without user interaction.

11. 11. The method of claim 9 or 10, wherein the drug delivery system is connected to an analyte monitoring device and a computing device to form a closed loop system.

12. The method of claim 11 , wherein the request to stop delivery of the medication is received in response to a user input to the medication delivery system.

13. 12. The method of claim 11, wherein the request to stop delivery of the medication is received in response to a user input to a user interface displayed on the computing device.

14. The method of any one of claims 9 to 13, wherein the request to stop delivery of the medication to the user includes an indication of the duration of the stoppage.

15. The method of any one of claims 9 to 14, wherein the agent comprises insulin.

Images