Position-assisted blood glucose control

Abstract

Location-assisted blood glucose control is described. The blood glucose control system obtains sensor data from one or more sensors and detects the user's location based on the sensor data. The blood glucose control system predicts an activity that the user will perform at that location based on the user's location and generates a recommendation for controlling the user's blood glucose response to the predicted activity. In one or more implementations, the blood glucose control system causes a recommendation for controlling the user's blood glucose response to be displayed. In one or more implementations, the recommendation corresponds to administering to the user an amount of a medicament to control the blood glucose response to the predicted activity, and the blood glucose control system communicates to the medicament delivery system an instruction to administer that amount of the medicament to the user.

Description

Technical Field

[0001] (Cross - Reference to Related Art) This application claims priority to U.S. Provisional Patent Application No. 63 / 389,491, filed on July 15, 2022, entitled "Location - Aided Glycemic Control", the entire disclosure of which is incorporated herein by reference.

Background Art

[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. Since blood glucose levels change almost constantly over time and in response to daily events and activities such as meals, exercise, sleep, and stress, it can be difficult to maintain those levels within an acceptable range.

Summary of the Invention

Means for Solving the Problems

[0003] To overcome these problems, location - aided glycemic control is utilized. A glycemic control system obtains sensor data from one or more sensors and detects a user's location based on the sensor data. The glycemic control system predicts an activity that the user will perform based on the user's location and generates recommendations for controlling the user's glycemic response to the predicted activity. In one or more implementations, the glycemic control system causes recommendations for controlling the user's glycemic response to be displayed. In one or more implementations, the recommendations correspond to administering a certain amount of a drug to the user to control the glycemic response to the predicted activity, and the glycemic control system transmits an instruction to the drug delivery system to administer that amount of the drug to the user.

[0004] The summary of this invention presents, in a simplified form, a selection of concepts that are further described in the following modes for carrying out the invention. Accordingly, the summary of this invention is not intended to identify the 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. The detailed description is presented with reference to the accompanying drawings.

Brief Description of the Drawings

[0005]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

[0006] Overview Location-assisted blood glucose control is described. According to the techniques described, a system for location-assisted blood glucose control is configured to detect a person's location based on sensor data and then, based on the person's location, predict the activities the person will perform at that location. In some cases, the person's location can be detected based on at least two different types of sensor data. As an example, Global Positioning System (GPS) data obtained from a user's smartphone can be used to detect that the user is at a location corresponding to "the gym", while the signal strength of a wireless network connection associated with the location of the gym can be used to confirm that the user is at the gym. As another example, at least two different types of sensor data may be used to distinguish between at least two candidate locations. For example, consider that the location corresponding to the gym is "next door" to a different location corresponding to a restaurant. In this example, the first sensor data (e.g., GPS data) may be used to detect that the user is at either the gym or the restaurant, while the second sensor data (e.g., wireless network signal strength) may be used to select one of these two locations to determine the user's current location.

[0007] Based on the detected location, the blood glucose control system predicts the activities the user will perform at that location. In some cases, this prediction is based on historical data indicating that the user has previously performed activities at that location, or other historical data indicating that other users have previously performed activities at that location. Alternatively or additionally, the blood glucose control system predicts the activities the user will perform at that location based on a location type (or tag) associated with the location. For example, different gyms can be associated with a gym location type (or tag), and different restaurants can be associated with a restaurant location type (or tag). Continuing with the above example, if the system detects that a person is at a gym, the system can predict that the person will perform activities associated with exercise at the gym location. In contrast, if the system detects that the user is at a restaurant, the system can predict that the user will perform activities associated with eating at the restaurant location.

[0008] In particular, the execution of different activities can change a person's analyte levels. For example, exercise can lower a person's glucose level, while a meal (eating) can raise a person's glucose level. For certain users, such as users with type II diabetes, such activities can cause a person's glucose level to exceed a target range associated with a dangerous medical condition. As an example, eating a meal with too many carbohydrates can increase a person's glucose level above the target range and cause the person to experience a hyperglycemic event, while intense exercise can decrease a person's glucose level below the target range and cause the person to experience a hypoglycemic event.

[0009] Accordingly, in order to maintain the user's glucose level within a target range based on the execution of activities at the detected location, the system generates recommendations for controlling the user's blood glucose response to the predicted activities. In some cases, the recommendations are output to the user. For example, based on the prediction that the user will perform various exercise-related activities at the gym location, the system may output a notification or warning on the person's smartphone instructing the person to consume carbohydrates before exercising at the gym. Consuming carbohydrates before exercise can raise the person's glucose level before exercise so that the person's blood glucose level remains within the target range after the subsequent decrease in glucose level caused by exercise.

[0010] In one or more implementations, the recommendations may correspond to drug delivery. In this scenario, the system may control a drug delivery system (e.g., an insulin pen or pump) to deliver a drug to the person based on the recommendations. For example, based on the prediction that the person will consume a meal at a restaurant, the system determines a bolus dose of insulin to deliver to the person to prevent the person's glucose level from exceeding the hyperglycemic target range, and then transmits a control signal to the drug delivery system to automatically deliver the bolus dose of insulin to the person to the drug delivery system.

[0011] In some aspects, the techniques described herein relate to a method that includes obtaining sensor data from one or more sensors, detecting the user's location based on the sensor data, predicting an activity that the user will perform at the location based on the user's location, and generating recommendations for controlling the user's blood glucose response to the predicted activity.

[0012] In some aspects, the techniques described herein further include generating a recommendation by predicting a user's blood glucose response to a predicted activity, determining whether the user's blood glucose response to the predicted activity will cause a health - harmful event, and determining a mitigation therapy to prevent the health - harmful event in response to determining that the user's blood glucose response to the predicted activity will cause a health - harmful event, wherein the recommendation includes the mitigation therapy.

[0013] In some aspects, the techniques described herein relate to a method, and detecting a user's location is based on at least two different types of sensor data.

[0014] In some aspects, the techniques described herein relate to a method, and detecting a user's location includes detecting the user's location based on first sensor data and verifying the user's location based on second sensor data.

[0015] In some aspects, the techniques described herein relate to a method, and detecting a user's location includes detecting at least two candidate locations of the user based on first sensor data and selecting, as the user's location, one of the at least two candidate locations based on second sensor data.

[0016] In some aspects, the techniques described herein relate to a method, and the recommendation includes administering an amount of a drug to the user to control the user's blood glucose response to a predicted activity.

[0017] In some aspects, the techniques described herein further include transmitting an instruction to a drug delivery system, and the instruction causes the drug delivery system to administer an amount of a drug to the user, with respect to the method.

[0018] In some aspects, the techniques described herein relate to a method, and the drug includes insulin.

[0019] In some aspects, the techniques described herein relate to a method that includes predicting an activity, which includes predicting a state of the activity based on a location, where the state includes a pre-activity state, an activity state, or a post-activity state, and where a recommendation is based on the state of the activity.

[0020] In some aspects, the techniques described herein further relate to a method that includes receiving additional sensor data, determining an additional location of a user based on the additional sensor data, predicting that the user is in a different activity state based on the additional location of the user, and generating an additional recommendation based on the different activity state.

[0021] In some aspects, the techniques described herein further relate to a method that includes displaying, on a computing device, a recommendation for controlling a user's blood glucose response.

[0022] In some aspects, the techniques described herein relate to a method, where the predicted activity includes exercise, a meal, or sleep.

[0023] In some aspects, the techniques described herein relate to a system that includes one or more sensors for obtaining sensor data associated with a user, a drug delivery system for administering a drug to the user, and at least a memory and a processor for performing operations, the operations including detecting a location of the user based on the sensor data, predicting an activity that the user will perform at the location based on the location of the user, determining an amount of a drug to administer to the user to control the user's blood glucose response to the predicted activity, and communicating an instruction to the drug delivery system, the instruction causing the drug delivery system to deliver the amount of the drug to the user.

[0024] In some aspects, the techniques described herein further relate to a system that includes an analyte monitoring device for obtaining analyte data of a user, where the analyte monitoring device and the drug delivery system are connected in a closed loop.

[0025] In some aspects, the technology described herein relates to a system in which the amount of the agent is determined based at least in part on the user's analyte data obtained from an analyte monitoring device.

[0026] In some aspects, the technology described herein relates to a system in which the instructions cause the drug delivery system to deliver an amount of the agent to the user without user input.

[0027] In some aspects, the technology described herein relates to a system in which the agent includes insulin and the drug delivery system includes an insulin pump.

[0028] In some aspects, the technology described herein relates to a method that includes detecting the user's location based on at least two different types of sensor data, predicting an activity that the user will perform at the location based on the user's location, predicting the user's blood glucose response to the predicted activity, determining whether the user's blood glucose response to the predicted activity will cause a health-harmful event, and transmitting to the insulin pump an instruction to control the user's blood glucose response by administering insulin to the user in response to determining that the user's blood glucose response to the predicted activity will cause a health-harmful event.

[0029] In some aspects, the technology described herein further relates to a method that includes obtaining the user's glucose measurements from a glucose monitoring device worn by the user, and predicting the user's blood glucose response to the predicted activity based at least in part on the glucose measurements.

[0030] In some aspects, the technology described herein relates to a method in which the glucose monitoring device and the insulin pump are connected in a closed loop.

[0031] In the following description, first, an exemplary environment in which the technology described in this specification can be used will be described. Next, details of exemplary implementations and examples of procedures that can be executed in the exemplary environment, as well as other environments, will be described. The execution of the exemplary procedures is not limited to the exemplary environment, and the exemplary environment is not limited to the execution of the typical procedures.

[0032] Example of Environment FIG. 1 is an illustration of environment 100 in an exemplary implementation operable to use location-based blood glucose control. The illustrated environment 100 includes a person 102 wearing an analyte monitoring device 104 and a drug delivery system 106. The illustrated environment 100 also includes an exemplary computing device 108, a blood glucose control system 110, a health monitoring platform 112, and the Internet of Things (IoT 114). The analyte monitoring device 104, the drug delivery system 106, the exemplary computing device 108, the blood glucose control system 110, the health monitoring platform 112, and the IoT 114 are communicatively coupled, including via a network 116.

[0033] (The analyte monitoring device 104, the drug delivery system 106, and one or more computing devices 108 (associated with the person 102)) may be communicatively coupled in various ways, such as by using one or more wireless communication protocols or technologies. By way of example, and without limitation, the analyte monitoring device 104, the drug delivery system 106, and 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.

[0034] Through such communicable couplings, one or more of the analyte monitoring device 104, the drug delivery system 106, and the computing device 108 may form a closed-loop system in one or more implementations. When implemented as a closed-loop system, the combination of devices is configured to provide location-based blood glucose control in a manner that eliminates or reduces user interaction involved in mitigating a health-harmful event (e.g., a blood glucose event). Alternatively, the device processes various information and makes various predictions and determinations regarding the user's location, the activities the user is performing or will perform based on the location, the blood glucose response to those activities, and the treatment (if any) required to mitigate those blood glucose responses. In a closed-loop system, the device may then provide the determined treatment without user interaction; for example, the drug delivery system 106 is controlled to administer a drug to the person 102.

[0035] In one or more implementations, the analyte monitoring device 104 is a wearable that 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 glucose of the person 102. For example, the analyte monitoring device 104 may be configured using an analyte sensor that detects one or more signals indicative of the analyte in the person 102 and enables the generation or estimation of an analyte measurement (e.g., the estimation of a glucose value). Those analyte measurements (e.g., glucose measurements) may be packaged in a corresponding manner or otherwise for communication to one or more of the computing device 108 or the drug delivery system 106 as analyte data, which is an example of sensor data 118.

[0036] In at least one implementation, the analyte monitoring device 104 is a glucose monitoring system. As an example, the analyte monitoring device 104 may be configured as a continuous glucose monitoring (``CGM'') system, for example, a wearable CGM system. As used herein, the term ``continuous'' when used in connection with analyte monitoring may refer to the ability of a device to generate measurements substantially continuously, such that the device may establish a communication link with a different device (e.g., when computing device 108 establishes a wireless connection with analyte monitoring system 104 to retrieve one or more of the measurements), etc., and 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.). However, in other implementations, the glucose monitoring device may not be ``continuous'' and instead may provide a measurement of glucose when requested. This functionality is described in more detail in connection with FIG. 2, along with further aspects of the configuration of the analyte monitoring device 104.

[0037] In addition to generating sensor data 118 (including analyte data indicative of measurements of the analyte in person 102), the analyte monitoring device 104 transmits the generated sensor data 118 to, for example, computing device 108. The analyte monitoring system 104 may transmit the data in real time, e.g., as the data is generated, using an analyte sensor or other sensors. Alternatively or additionally, the analyte monitoring device 104 may transmit the data to the computing device 108 at predefined time intervals. For example, the analyte monitoring device 104 may be configured to transmit the sensor data 118 to the computing device 108 approximately every 5 minutes. Indeed, the interval at which the sensor data 118 is transmitted by the analyte monitoring device 104 may differ from the above example without departing from the spirit or scope of the described technology. The data may be communicated from the analyte monitoring device 104 to the computing device 108 according to other bases of the described technology.

[0038] Note that the computing device 108 may maintain the sensor data 118 at least temporarily, for example, in a storage device (not shown) of the computing device 108. The sensor data 118 may also be maintained in such a storage device of the computing device 108 or in a storage device of a different device, along with other relevant data such as, for example, corresponding timestamps and / or identifiers of the data packets being communicated.

[0039] As shown, the system to be described may include one or more computing devices 108 according to the techniques to be described. In one or more scenarios, for example, the techniques described may be implemented using a computing device 108 such as a mobile phone. Alternatively, the techniques described may be implemented using multiple computing devices 108, and in at least one variant, may include both a wearable device (e.g., a smartwatch, a mouse guard, a contact lens, smart glasses, a chest strap, earbuds, or headphones, etc.) and a mobile phone. In such a scenario, both of these devices may perform at least some of the same operations for purposes such as receiving sensor data 118 from the analyte monitoring device 104 (and from other sources), generating sensor data 118 using sensors on board or associated therewith, transmitting data over the network 116 to the blood glucose control system 110 and / or the health monitoring platform 112, displaying information related to the data, displaying information related to recommendations generated by the blood glucose control system 110 and / or the health monitoring platform 112, facilitating the control of other devices (e.g., controlling the drug delivery system 106), etc. Alternatively or additionally, different devices may have different capabilities that other devices do not have or that are limited to a particular device by computing instructions.

[0040] The blood glucose control system 110, by processing sensor data 118 and by providing instructions 120, for example, by providing the instructions 120 to the drug delivery system 106, the computing device 108, and / or another device (e.g., an additional drug delivery system), makes a determination based on which treatment is to be administered or recommended. According to the techniques described, the blood glucose control system 110 makes those determinations, at least in part, by leveraging one or more of the computing device 108, the analyte monitoring device 104, the drug delivery system 106, the blood glucose control system 110, and the IoT 114, to cause treatment to be administered or recommended.

[0041] In the illustrated example, the blood glucose control system 110 is shown as including a location prediction engine 122 and a recommendation engine 124. It should be understood that the blood glucose control system 110 may include more, fewer, or different components without departing from the spirit or scope of the techniques described. Although the analyte monitoring device 104, the drug delivery system 106, the computing device 108, and the health monitoring platform 112 are shown as separate, in one or more implementations, at least a portion of the blood glucose control system 110 is implemented in one or more of those entities. Additionally, various portions of the blood glucose control system 110 can be implemented using different combinations of the analyte monitoring device 104, the drug delivery system 106, the computing device 108, and the health monitoring platform 112, or otherwise, in accordance with the techniques described.

[0042] As discussed above and below, the blood glucose control system 110 obtains sensor data 118 from various sources. For example, the blood glucose control system 110 obtains sensor data 118 from one or more of the analyte monitoring device 104, the drug delivery system 106, the computing device 108, the health monitoring platform 112, or the IoT 114. Examples of sensor data 118 include, but are not limited to, global positioning system (GPS) data, Wi-Fi information (e.g., service set identifier (SSID) of available networks, the network to which the computing device 108 is connected, and / or the networks to which the computing device 108 has previously been connected), 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), optical 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 pharmaceutical data. This list is not exhaustive, and it will be understood that the blood glucose 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.

[0043] Based on the sensor data 118, the location prediction engine 122 detects the location of the user, e.g., the person 102 wearing the analyte monitoring device 104. In one or more implementations, the location prediction engine 122 detects the user's location based on at least two different types of sensor data 118. For example, the location prediction engine 122 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 122 uses the first sensor data to detect the user's location and the second sensor data to confirm the user's location. Alternatively or additionally, the location prediction engine 122 uses two types of sensor data to distinguish which of a plurality of candidate locations corresponds to the user's actual physical location. For example, the location prediction engine 122 detects at least two candidate locations of the user based on the first sensor data. Based on the second sensor data, the location prediction engine 122 selects (or excludes all but one of the candidate locations) one of the at least two candidate locations as the user's location.

[0044] The recommendation engine 124 predicts the activities that the user performs at that location. Examples of activities include eating, exercising, and sleeping. Certainly, the system may predict other activities without departing from the spirit or scope of the technology described. Next, the system uses the activities predicted to be performed by the user to generate one or more recommendations for controlling the user's blood glucose response, e.g., the blood glucose response of the person 102 to the predicted activities. For example, the recommendation engine 124 generates recommendations for one or more therapies to mitigate potential adverse effects resulting from the predicted activities. Examples of adverse effects include glucose excursions from at least the safe glucose range, e.g., hyperglycemia or hypoglycemia.

[0045] As discussed above and below, the recommendation engine 124 may also use the "activity state" to generate such recommendations. This is because the therapy recommended before an activity may be different from the therapy recommended during or after the activity. As an example, the therapy recommended before a meal may be different from the therapy recommended during and after the meal. In at least one implementation, the activity state may include a pre-activity state, an activity state (e.g., during the activity), and a post-activity state. The activity state may be defined in other ways, in a variant form, for example, based on patterns identified in the analyte data.

[0046] In one or more implementations, the blood glucose control system 110 provides instructions 120 for notifying the user about the recommended treatment. For example, the blood glucose control system 110 provides the instructions 120 to the computing device 108 to cause the computing device 108 to display the recommendation (or information indicating the recommendation) or output it in some other way. Additionally or alternatively, the blood glucose control system 110 provides instructions 120 for controlling a device (e.g., the drug delivery system 106) to provide the recommended treatment. For example, the blood glucose control system 110 provides the instructions 120 to the drug delivery system 106, and the instructions cause the drug delivery system 106 to administer an amount of the drug to the person 102.

[0047] In one or more implementations, the instructions cause the drug delivery system 106 to automatically administer a drug (e.g., a certain dosage) to the person 102 without user input. In such an implementation, the device is operably connected in a closed loop. In other implementations, the instructions direct the drug delivery system 106 to administer a drug (e.g., a certain dosage) to the person 102, but the system prevents the drug from being delivered until a verification input, e.g., an input indicating that the user permits the drug to be delivered, is received from the user. Alternatively or additionally, the instructions direct the drug delivery system 106 to administer a certain dosage of the drug, and the drug delivery system 106 requires user interaction to transfer the dosage into the person 102's body. For example, the user is required to position the drug delivery system 106 against the person 102's body and activate the system (e.g., by pressing a button) to administer the drug. An example of the blood glucose control system 110 is described in more detail below with reference to FIG. 4.

[0048] As described above, the blood glucose control system 110 uses sensor data 118 obtained via the IoT 114 in one or more implementations. The IoT 114 represents various sources that can provide data describing the person 102 and / or the activities of the person 102. For example, to name a few, 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, such as at home, in a car, at work, at a gym, at a restaurant, or other stores, etc. It should be understood that. As an example, the IoT 114 may include various devices of the user, such as a mobile phone, a wearable device, a camera, a laptop, etc. For this purpose, the IoT 114 provides information regarding the user's interactions with those various devices, such as the location of those devices, the environment and / or physical state at the location where the devices are placed, the interaction with web-based applications supported by the devices, the interaction with health applications supported by the devices, the photos taken, other communications with other users, online behavior, etc. The IoT 114 may also include various other real-world items (such as shoes, clothing, sports equipment, household appliances, smart home devices, automobiles, etc.) configured with sensors that provide information describing behaviors such as the number of steps, the force with which the feet kick the ground, the stride, the user's body temperature (and other physiological measurements), the temperature around the user, the types of food stored in the refrigerator, the types of food taken out of the refrigerator, driving habits, the user's image at various times of the day, etc. Such other real-world items may also provide sensor data 118 that describes the location of those items, the user interactions with those items, the environment and / or physical conditions at the location where the items are placed, as well as various other conditions.

[0049] In a variant form, the IoT 114 may also include third parties to the health monitoring platform 112, such as healthcare providers (e.g., the healthcare provider of person 102) and manufacturers (e.g., one or more manufacturers of the analyte monitoring device 104, the drug delivery system 106, or the computing device 108) that can each provide medical data and manufacturing data that can be utilized by the blood glucose control system 110. Indeed, the IoT 114 may include devices and sensors that can provide rich data used to determine the location and / or activities of person 102 without departing from the spirit or scope of the described technology.

[0050] In one or more implementations, the blood glucose control system 110 also utilizes the resources of the health monitoring platform 112 in connection with location-assisted blood glucose control. For example, the health monitoring platform 112 may be configured to store data such as sensor data 118 (e.g., analyte measurements, data generated by other sensors, and data generated based on decisions made using analyte measurements and / or data generated by other sensors), instructions 120, user profile data associated with a user (e.g., person 102), and / or user profile data associated with one or more other users of a user population (not shown). The environment 100 includes user data 126 that represents various data acquired and stored by the health monitoring platform 112 for one or more of those users. The user data 126 may be stored for one or more users, but the personally identifiable information of the users associated with the data may be obfuscated using one or more techniques so that it can be kept anonymous in various scenarios in which the data is used. In the illustrated environment 100, the user data 126 is shown stored in the storage device 128. The storage device 128 may represent one or more databases or other storage devices that are included as part of, or otherwise accessible to, the health monitoring platform 112. According to the techniques described, the storage device 128 is capable of storing the user data 126 and various other data.

[0051] As an example, the user data 126 may include any combination of the data described above and other data discussed above and below. For example, the user data 126 may include historical data associated with one or more users, such as historical sensor data 118, decisions made based on the historical sensor data 118, received user inputs, etc. In at least one implementation, such historical data may describe the user's state and / or behavior of the user, activities performed by the user, activities previously performed by other users at that location, and attributes of the activities performed, such as activity time, location type, physiological measurements during the activity, etc.

[0052] 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 connection with the blood glucose control system 110. By way of example, the monitoring service 130 may provide a user with one or more web-based health-related services via the network 116 and the user's computing device 108, such as a mobile application. The health monitoring platform 112 may include or have access to various computing resources such as processing resources, storage device resources, and virtual resources. Those resources may be used, for example, to train, maintain, and / or deploy algorithms (e.g., machine learning algorithms), which may generate predictions associated with health monitoring by using rich data collected about the person 102 and users in the user population. Thus, the monitoring service 130 may utilize those resources to execute algorithms and implement other functions to deliver web-based services to the user via those devices. In particular, one or more such algorithms or functions may require an amount of computing resources beyond that of typical personal computing devices, such as, by way of example, mobile phones, laptops, tablet devices, and wearable resources. Nevertheless, the health monitoring platform 112 includes or can otherwise access at least a threshold amount of resources necessary to operate such algorithms and provide such functions, such as cloud storage, server devices, virtualization resources, etc. The health monitoring platform 112 may include various resources that the computing device 108 can utilize via the monitoring service 130 to provide a user interface or generate data for location-assisted blood glucose control. Consider the following description of FIG. 2 in the context of continuously measuring an analyte, such as glucose, and obtaining analyte data that describes such measurements.

[0053] Figure 2 shows in more detail an example 200 of an implementation of the analyte monitoring device 104 of FIG. 1. In particular, the illustrated example 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 can be modified in various ways in the embodiments from the following description without departing from the spirit or scope of the described technology.

[0054] In this example 200, the analyte monitoring device 104 is shown as including 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, for example, inserted under the skin 206 of the person 102. The sensor module 204 is approximated as a dashed-line rectangle in the top view. The analyte monitoring device 104 also includes a transmitter 208 in the illustrated example 200. By using a dashed-line rectangle for the sensor module 204, it is shown that the sensor module can be housed within the housing of the transmitter 208 or implemented in other ways. The 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 within the housing of the transmitter 208 or implemented in other ways. In this example 200, the analyte monitoring device 104 further includes an adhesive pad 210.

[0055] During operation, the analyte sensor 202 and the adhesive pad 210 may be assembled to form an attachment assembly that is configured to be applied to the skin 206 such that the analyte sensor 202 is subcutaneously inserted as shown. In such a scenario, the transmitter 208 may be attached to the assembly after being attached to the skin 206 via an attachment mechanism (not shown). Alternatively, the transmitter 208 may be incorporated as part of the attachment assembly, whereby the analyte sensor 202, the adhesive pad 210, and the transmitter 208 (having the sensor module 204) can all be attached to the skin 206 at once. In one or more implementations, this attachment assembly is attached to the skin 206 using a separate sensor applicator (not shown). Unlike finger pricking required by conventional blood glucose meters, the user-initiated attachment of the analyte monitoring device 104 having a sensor applicator is substantially painless and does not require blood sampling. Further, an automated sensor applicator generally enables a person 102 to implant the analyte sensor 202 under the skin 206 without the assistance of a clinician or healthcare provider.

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

[0057] During operation, the analyte sensor 202 is communicatively coupled to the sensor module 204 via at least one communication channel that can be a wireless or wired connection. Communication from the analyte sensor 202 to the sensor module 204, or from the sensor module 204 to the analyte sensor 202, can be performed actively or passively, and these communications can be continuous (e.g., analog) or discrete (e.g., digital).

[0058] The analyte sensor 202 may be a device, molecule, and / or chemical substance that changes or causes a change in response to an event that is at least partially independent of the analyte sensor 202. The sensor module 204 is implemented to receive an indication of a change in the analyte sensor 202 or an indication of a change caused by the analyte sensor 202. For example, the analyte sensor 202 may include glucose oxidase that reacts with glucose and oxygen to form hydrogen peroxide that is electrochemically detectable by a sensor module 204 that 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, thereby improving the accuracy rate in identifying or predicting glucose-based events (e.g., hyperglycemia or hypoglycemia). Additionally or alternatively, the analyte monitoring device 104 may include additional sensors and / or architecture to the analyte sensor 202 for detecting those analytes that indicate other markers.

[0059] In another example, the analyte sensor 202 (or an additional sensor of the analyte monitoring device 104 not shown) may include a first conductor and a second conductor, and the sensor module 204 may electrically detect a change in the potential at both ends of the first conductor and the second conductor of the analyte sensor 202. In this example, the sensor module 204 and the analyte sensor 202 are configured as a thermocouple such that the potential change corresponds to a temperature change. In some examples, the sensor module 204 and the analyte sensor 202 are configured to detect a single analyte, such as glucose. In other examples, the sensor module 204 and the analyte sensor 202 are configured to use various sensing modes to detect multiple analytes, such as ionic sodium, ionic potassium, carbon dioxide, and glucose. Additionally or alternatively, the analyte monitoring device 104 includes a plurality of sensors for detecting not only one or more analytes (such as ionic sodium, ionic potassium, carbon dioxide, glucose, and insulin) but also one or more environmental conditions (such as temperature, humidity, movement). Thus, the sensor module 204 and the 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 a change in one or more environmental conditions. As described above, the analyte monitoring device 104 may be configured to generate data describing more than one analyte (such as glucose).

[0060] In one or more embodiments, the sensor module 204 may include a processor and memory (not shown). This sensor module 204 may generate an analyte measurement 212 based on communication with the analyte sensor 202 that exhibits the changes described above by leveraging the processor. Based on the above-described communication from the analyte sensor 202, the sensor module 204 is further configured to generate a communicable data package that includes at least one analyte measurement 212. In this example 200, the sensor data 118 represents these data packages. Additionally or alternatively, the sensor module 204 may configure the analyte data 118 to include additional data, such as, by way of example, supplementary sensor information 214. The supplementary sensor information 214 may include a sensor identifier, sensor status, temperature corresponding to the analyte measurement 212, measurements of other analytes corresponding to the analyte measurement 212, and the like. It should be understood that the supplementary sensor information 214 may include various data that supplement at least one analyte measurement 212 without departing from the spirit or scope of the techniques described.

[0061] In embodiments where the analyte monitoring device 104 is configured for wireless transmission, the transmitter 208 may transmit the sensor data 118 as a data stream to a computing device. Additionally or alternatively, the sensor module 204 may buffer the analyte measurement 212 and / or the supplementary sensor information 214 (e.g., in the memory of the sensor module 204 and / or other physical computer-readable storage media of the analyte monitoring device 104), and later cause the buffered sensor data 118 to be transmitted to the transmitter 208 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 1 hour, etc.), storage intervals (when the buffered analyte measurements 212 and / or supplementary sensor information 214 reach a threshold amount of data or number of measurements), and the like. 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 techniques described.

[0062] Although examples of analyte monitoring devices have been described, the following description of an example of a drug delivery system will next be considered.

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

[0064] 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 a tube 306 connected to the drug pump 302, but in one or more implementations, the infusion set 304 may be tubeless. The drug delivery system 106 may be configured, for example, as a pen. Broadly speaking, the infusion set 304 is a device configured to subcutaneously deliver to the person 102 a drug pumped into the infusion set 304 by the drug pump 302 for absorption by the bloodstream of the person 102. In this way, the delivered drug may be used by the body of the person 102 to maintain a balanced analyte level, for example, within a target range of analyte measurements. In one or more implementations, the infusion set 304 includes a cannula that is subcutaneously inserted into the skin, such as at the infusion site 308 of the person 102, in the exemplary implementation 300. Thus, the infusion set 304 may be administered a dose of the drug through the skin of the person 102, for example, continuously and at a programmable rate. As discussed herein, for example, a basal dose and / or a bolus dose of insulin may be administered through the skin of the person 102 via the infusion set 304. Alternatively or additionally, the drug delivery system 106 may administer a drug to the person 102 based on user input, such as input received via a user interface for one or more doses of the drug to be delivered, and / or input received via the computing device 108.

[0065] As shown, the infusion set 304 includes an adhesive pad that attaches the device to the person 102 over 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). During operation, this applicator may inject the cannula of the infusion set 304 into the infusion site 308 on the skin of the person 102 and also attach the adhesive pad to the infusion site 308 to secure the infusion set 304 to the person 102 over the period of use. In at least some implementations, for example, the infusion set may be disposable such that it is removed after a defined and / or recommended period and replaced with a new set that is applied to the person 102 and attached to the drug pump 302. In any 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.

[0066] In an exemplary implementation 300, the drug pump 302 includes a communication module 310, a drug delivery controller 312, a drug reservoir 314, a display module 316, a safety module 318, and a battery 320. In an implementation, the drug pump 302 may be configured in various ways such that some of these components are housed together with others being housed in separate devices or implemented in other ways. Alternatively or additionally, the drug pump 302 may include additional or alternative components without departing from the spirit or scope of the techniques described herein.

[0067] The communication module 310 is configured to transmit and receive data with other devices such as the computing device 108. In one or more implementations, the communication module 310 establishes a communication link with such other devices to enable the transmission and reception of data. By way of example, the communication module 310 may facilitate the establishment of a communication link or channel with those other devices, or in some other way. The link or channel may be configured in various ways including, but not limited to, Bluetooth (e.g., Bluetooth Low Energy link), Near Field Communication (NFC), 5G or other cellular, and Wi-Fi. Such a communication link enables the drug pump 302 to communicate securely via different networks such as the network 116 and / or within a closed-loop system including, for example, the analyte monitoring device 104 and at least one computing device 108.

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

[0069] As an example, the communication module 310 enables the drug pump 302 to receive instructions 120 and / or other instructions from the computing device 108 and / or the blood glucose control system 110 for controlling the delivery of drugs to the person 102. For example, the communication module 310 enables the drug pump 302 to receive instructions that command the drug pump 302 regarding the delivery of the basal rate of insulin to the person 102, the update of the basal rate of insulin, the delivery of a bolus dose of insulin to the person 102 (e.g., the amount to be bolused within a limited time), and the like. The computing device 108 may transmit various communications to the drug delivery system 106 to control drug delivery without departing from the spirit or scope of the techniques described herein.

[0070] The drug delivery control unit 312 represents any hardware, software, and / or mechanical components of the drug pump 302 that cause the drug to be pumped (or otherwise extracted) from the drug reservoir 314 so that the drug flows into the person 102 through the infusion set 304. Further, the drug delivery control unit 312 is further configured to pump (or otherwise extract) the drug from the drug reservoir 314 in accordance with a drug dosage instruction, e.g., an instruction 120 from the blood glucose control system 110 that specifies one or more deliveries of the drug. The drug reservoir 314 is configured to contain an amount of the drug, and by utilizing the function of the drug pump 302, the drug may be delivered subcutaneously via the infusion set 304. The drug reservoir 314 may be replaceable so that an amount of the drug can be replenished into the drug reservoir 314, or may be configured in some other way. The drug reservoir 314 may be configured in various ways (e.g., different shapes, different materials, different removability, etc.) without departing from the spirit or scope of the techniques described.

[0071] The display module 316 is configured to display information via the display device 322 of the drug pump 302. The display module 316 may generate one or more user interfaces for display via the display device 322. By way of example, the display module 316 may cause a display via the display device of a user interface for setting up a wireless connection with the computing device 108. Additionally or alternatively, the display module 316 may cause the display device 322 to display analyte measurements (e.g., in a manner similar to that displayed via the health monitoring application of the computing device 108), trend arrows (e.g., related to an identified trend in analyte measurements), warnings (e.g., related to analyte measurements, other physiological states, the operability of the drug delivery system 106, the operability of components of the blood glucose 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), and the like. Thus, the display module 316 may display various information via the display device 322 of the drug pump 302.

[0072] The safety module 318 is configured to provide one or more safety measures for controlling the delivery of the drug so that the delivery is not harmful. In other words, it ensures the safe delivery of the drug. As an example, the safety module 318 may include delivery limitations such as a maximum speed and a minimum speed of delivery over different periods, or may be implemented in other ways. These limitations are effective to prevent an incorrect delivery command from the blood glucose control system 110 from harming the person 102, for example, when they affect the content of the commands being sent, or when an error in a prediction made by one or more machine learning models has a dangerous impact on those commands. For example, even if the command received from the blood glucose control system 110 instructs the drug pump 302 to deliver an amount exceeding a threshold amount, the safety module 318 may limit the amount or speed of the drug delivered by the drug pump 302 to the threshold amount or threshold speed. Similarly, even if the command received from the computing device 108 instructs the drug pump 302 to deliver an amount less than the threshold amount, the safety module 318 may prevent the drug pump 302 from delivering a drug amount less than the threshold amount or delivering the drug at a speed less than the threshold speed.

[0073] Note that the safety module 318 is configured to keep the drug pump 302 operating when there is no command from the blood glucose control system 110 or the computing device 108, for example, when there is no command explaining how much drug to deliver and when. The safety module 318 may be configured to keep the drug pump 302 operating to deliver the drug to the person 102, for example, when the blood glucose control system 110 is out of communication range. The safety module 318 may access logic, default settings, or settings entered as part of a setup process that control how much drug the drug pump 302 should deliver when no command has been received from the blood glucose control system 110. The safety module 318 may perform various additional or different safeguards to ensure that the amount of drug delivered is not harmful to the person 102.

[0074] The battery 320 is configured to supply power to operate the drug pump 302, for example, to supply power to the communication module 310 to transmit and receive data, to supply power to the drug delivery control unit 312 to deliver a drug from the drug reservoir 314 to the person 102 via the infusion set 304, and to supply power to the display module 316 to display information via the display device 322. The battery 320 may be rechargeable or replaceable (e.g., via a USB charging port or wirelessly). It should be understood that the battery 320 may be configured in various ways.

[0075] Although not shown, the drug delivery system 106 or another device (e.g., the 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 the systemic level of the drug within the person 102. Thus, the drug sensor may be included as part of the infusion set 304, the analyte monitoring device 104, or may be applied separately. In any case, such a sensor may be used in connection with the safety module 318 and / or the dose prediction function of the blood glucose control system 110. In this way, the drug measurement values generated using the drug sensor can be used to prevent or detect drug ingestion, for example, to prevent a person receiving insulin from experiencing a hypoglycemic episode. As an example, the safety module 318 may block drug delivery by the drug pump 302 based on the drug measurement values if the safety module 318 detects that the level of the drug has exceeded a predetermined threshold. Based on the drug measurement values, the blood glucose control system 110 may also or alternatively send commands to the drug delivery system 106 to stop drug delivery. In one or more implementations, the safety module 318 and / or the computing device 108 may also trigger a warning if the level of the drug exceeds a predetermined threshold. Physiologically, different thresholds may be determined for different people based on that person's drug sensitivity (e.g., insulin sensitivity), such that the above-described shutdown, warning, or stop of drug delivery may be triggered at different drug levels for different people.

[0076] Having considered examples of the environment and the device, next, some examples of the details of the techniques for location-assisted blood glucose control according to one or more implementations will be considered.

[0077] Location-Assisted Blood Glucose Control FIG. 4 shows an example of a system 400 that receives and processes sensor data from various sources and generates recommendations for blood glucose control based on a user's location according to the steps of one or more algorithms, and thus implements a dedicated machine. The illustrated system 400 includes a blood glucose control system 110 having a position prediction engine 122 and a recommendation engine 124 from FIG. 1.

[0078] In this example, the blood glucose control system 110 is shown as obtaining sensor data 118. According to the described technology, the blood glucose control system 110 receives sensor data 118 from various sources 402, and examples of such include, but are not limited to, Global Positioning System (GPS) data, Wi-Fi information (e.g., Service Set Identifier (SSID)), Bluetooth Low Energy (BLE) information, data generated using a cellular antenna (e.g., Long Term Evolution (LTE)), microphone data (e.g., voice data), accelerometer data, gyroscope data, magnetometer data, barometer data, ambient or internal temperature data (e.g., generated using a temperature sensor), optical 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 (different data regarding one or more different analytes or the same analyte from different sources), and drug data. Additional examples of sensor data 118 from various sources 402 include, but are not limited to, measurements of various detected signals (e.g., biopotential measurements such as electrocardiogram (ECG), electromyogram (EMG), or electroencephalogram (EEG)), acceleration experienced by a person at the location where the analyte-enhanced wearable is worn, and optical signals such as photoplethysmogram (PPG) that detects changes in blood volume, measurements of various physiological states (e.g., sweating, body temperature, heart rate, oxygen saturation (SpO2)), or signs of detected events (e.g., exceeding or falling below a threshold, detecting the presence or absence of a specific compound). As described above, the analyte monitoring device 104, drug delivery system 106, computing device 108, and IoT 114 may be sources 402 of such data. Alternatively or additionally, the blood glucose control system 110 receives sensor data 118 from other sources 402 that may include or be associated with one or more various types of sensors.

[0079] In the illustrated example, the sensor data 118 includes first sensor data 404 and second sensor data 406. In one or more implementations, the location prediction engine 122 predicts the user's location 408 based on at least two types of sensor data, such as the first sensor data 404 and the second sensor data 406. For example, the location prediction engine 122, by way of several examples, predicts the user's location 408 based on both GPS data and Wi-Fi information (e.g., the SSID of the network accessible to the computing device 108), based on both Wi-Fi information and audio data, based on both Wi-Fi information and optical data, based on both Wi-Fi information and heart rate data. It should be understood that the location prediction engine 122 may be configured to receive and process various combinations of at least two types of data, as described above and below, as inputs to predict the user's location 408. Indeed, in one or more implementations, the location prediction engine 122 may use more than two types of data, such as more than the first sensor data 404 and the second sensor data 406, to predict the user's location 408.

[0080] In at least one implementation, the location prediction engine 122 predicts the location 408 of a user (e.g., person 102) based on the location of the computing device 108 associated with the user. For example, the location prediction engine 122 predicts the location 408 of the user based on the location of the user's mobile phone or smartwatch. In such an implementation, this is based on the assumption that the user is in proximity to the computing device associated with the user, 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 122 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 location of the device to the user. Alternatively or additionally, the location prediction engine 122 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 118 (e.g., proximity data, infrared data, temperature data, etc.) obtained from the computing device 108 to further refine the location and / or determine the user's location relative to the computing device 108. This may apply when the computing device 108 is not worn by the user, or when the user is asleep or taking a shower, etc., i.e., when it is not "on" for the user. In one or more implementations, the location prediction engine 122 uses first sensor data 404 to generate a "coarse" prediction of the user's location 408, and the location prediction engine 122 uses second sensor data 406 to generate a "refined" prediction of the location 408 (and based on the coarse location prediction).

[0081] In the illustrated example, the location prediction engine 122 includes a location predictor 410 and a location confirmation engine 412. The location confirmation engine 412 is shown in dashed lines, indicating that its logic is optionally used in one or more implementations. According to the techniques described, the location predictor 410 corresponds to the logic used by the location prediction engine 122 to predict the user's location 408 based on sensor data 118 according to one or more algorithms and thus implements a dedicated machine. The location predictor 410 may be configured in various ways without departing from the spirit or scope of the techniques described herein. For example, the location predictor 410 may be configured as, or include, one or more machine learning models. Alternatively or additionally, the location predictor 410 includes, or has access to, a mapping to the geographical coordinates of locations (e.g., restaurants, gyms, homes, stores, roads, and other businesses), such that when accurate geographical coordinates are provided, the location predictor 410 may attribute the user's presence to a location according to the mapping.

[0082] In at least one implementation, the first sensor data 404 may not be suitable for the location predictor 410 to accurately predict the user's geographical coordinates to distinguish at least two proximity locations. Instead, the first sensor data 404 may be suitable for predicting the area (e.g., the 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 122 (e.g., the location predictor 410) uses at least the second sensor data 406 to distinguish candidate locations and select the location 408 from among the plurality of candidate locations. For example, when a restaurant and a gym are adjacent, the location prediction unit 410 uses the second sensor data 406 to narrow down the candidate locations and select either the restaurant or the gym. This is noteworthy because activities that a user participates in at different locations can have dramatically different effects on the user's analyte levels. For example, eating pizza can have a dramatically different effect on a person's glucose than exercise.

[0083] The position confirmation engine 412 is configured to confirm the position predicted by the position predictor 410. In one or more implementations, the position predictor 410 predicts a position 408 based on the first sensor data 404, and the position confirmation engine 412 attempts to confirm the prediction of the position 408 based on the second sensor data 406. For example, based on the second sensor data 406, the position confirmation engine 412 either confirms the prediction of the position 408 or rejects the prediction. In a scenario where the prediction is rejected, the position prediction engine 122 may prompt the user to select a position, such as to select from a plurality of candidate positions or to confirm the predicted position. User involvement may also be required in one or more other scenarios, such as when a particular position is first predicted for the user. Alternatively or additionally, the position predictor 410 predicts the position 408 based on both the first sensor data 404 and the second sensor data 406, and the position confirmation engine 412 attempts to confirm the prediction of the position 408 based on both the first sensor data 404 and the second sensor data 406. Alternatively or additionally, the position predictor 410 predicts the position 408 based on both the first sensor data 404 and the second sensor data 406, and the position confirmation engine 412 attempts to confirm the prediction of the position 408 based on a third sensor data (not shown). Alternatively or additionally, the position predictor 410 and the position confirmation engine 412 may attempt to predict a position and confirm the predicted position, respectively, based on different combinations of data, without departing from the spirit or scope of the technology described. Further, it should be understood that the position prediction engine 122 may include various types of logic for predicting the position 408 of a user (e.g., person 102) based on the sensor data 118, or otherwise have access thereto, in accordance with the technology described. In this example, the position prediction engine 122 outputs the position 408.

[0084] When location 408 is provided, system 400 may predict a user's activity 414 and generate recommendations for blood glucose control based on the predicted activity 414. Here, the manner in which recommendation engine 124 obtains location 408 is shown. In the illustrated example, recommendation engine 124 includes an activity predictor 416 and an activity - recommendation module 418. It should be understood that recommendation engine 124 may include more, different, or fewer modules without departing from the spirit or scope of the described technology.

[0085] Activity predictor 416 is shown as outputting activity 414. According to the technology being described, activity predictor 416 determines and outputs activity 414 that the user is engaged in or is likely to be engaged in based on location 408 according to one or more algorithms, and thus implements a dedicated machine. In one or more variations, activity predictor 416 predicts activity 414 based on predicted location 408 without using other sensor data 118 (e.g., analyte data) or user interaction to confirm the activity. In at least one other variation, activity predictor 416 predicts activity 414 based on predicted location 408 and at least one other type of data, such as sensor data 118, and / or data describing user interaction with the device. Examples of such sensor data 118 include audio data (e.g., indicating sounds that confirm the user is sleeping), light data (e.g., indicating a dark location associated with a higher likelihood that the user is sleeping), accelerometer data (e.g., indicating the position of the device on a nightstand associated with a higher likelihood that the user is sleeping), etc. Examples of such user interaction include user interaction for confirming the predicted activity 414, entering an activity, etc. As described above and below, different activities that a person engages in can have very different effects on glucose. In other words, a person's blood glucose response is different for different activities they engage in. As a result, recommendation engine 124 recommends different relaxation therapies based on activity 414.

[0086] Examples of activities include, but are not limited to, eating, sleeping, exercising (e.g., aerobic exercise, anaerobic exercise, partial aerobic exercise and partial anaerobic exercise, high-intensity interval training, running, rowing, hiking, cycling, weightlifting, yoga, Pilates, sports, etc.), working (e.g., which may cause stress), taking a shower, watching a movie, watching TV, participating in an event (e.g., a sports event or a concert), dancing, reading, cleaning, taking care of children, or driving.

[0087] In the illustrated example, the activity predictor 416 is also shown to output an activity state 420. The activity state 420 is shown with a dashed line to indicate that it is optionally predicted by the activity predictor 416 in one or more implementations. The activity state 420 is useful because the treatments recommended for different times (e.g., before, during, and after) of an activity can be different. For example, the therapy recommended before eating may be different from the therapy recommended during or after eating. Similarly, the treatment recommended before exercise may be different from the treatment recommended during or after exercise. Thus, in one or more implementations, the activity predictor 416 predicts the activity 414 and also predicts the pre-activity state, in-activity state, or post-activity state.

[0088] As an example, the user's location 408 may be predicted as being in a vehicle (e.g., while driving), and based on additional user data, the activity predictor 416 may predict that the user is on the way to the gym. Examples of such additional data include, but are not limited to, data describing the user's historical behavior, calendar data, streaming (e.g., music) data, data from a mapping application (e.g., outputting or determining a route to the gym, detecting that the user is driving on a route that can lead to the gym, etc.), data from an application associated with the location (e.g., a reservation or scheduled appointment on the application), and the like. Thus, in this example, the activity predictor 416 may predict that the activity 414 is in motion and that the activity state 420 is "pre-activity" or pre-exercise. When additional data is received, the activity predictor 416 may update the activity state 420 or the activity 414. In a subsequent example, for instance, some examples include data such as the user parked the car at the gym, the user checked in at the gym, the user selected to start exercising with a smartwatch, the user's computing device connected to another device (e.g., established a Wi-Fi connection with the gym's wireless network, established a Bluetooth connection with a chest strap heart monitor), or the user selected to start playing an exercise playlist. When such additional data is received and processed, the activity predictor 416 may update the activity state 420 to "during activity state" or during exercise.

[0089] Based on activity 414 and, in at least one implementation, activity state 420, activity-recommendation module 418 generates a recommendation 422. In one or more implementations, activity-recommendation module 418 predicts a user's blood glucose response 424 to a predicted activity 414, determines that the user's blood glucose response 424 to the predicted activity causes a health-harmful event, and determines a mitigation therapy 426 to prevent or mitigate the health-harmful event corresponding to blood glucose response 424. The health-harmful event may include, for example, a hypoglycemic event, a hyperglycemic event, and any other potentially harmful event associated with the user's glucose level. Next, activity-recommendation module 418 generates a recommendation 422 and provides the mitigation therapy 426 and / or a notification of the mitigation therapy 426 to the user (e.g., person 102). Activity-recommendation module 418 may be configured in various ways without departing from the spirit or scope of the techniques described herein.

[0090] Thus, in some configurations, it should be understood that blood glucose control system 110 continuously detects a user's location 408 and predicts an activity 414 associated with that location. However, not all activities cause a blood glucose response 424, which may result in a health-harmful event. Thus, in one or more implementations, a recommendation 422 for controlling blood glucose response 424 is generated only if blood glucose control system 110 determines that the activity causes a blood glucose response 424 that results in a health-harmful event. As an example, blood glucose control system 110 may determine that the user is at their office and predict that the user is performing an activity associated with the user's office, such as writing an email. However, in this case, blood glucose control system 110 may be determined not to cause a blood glucose response 424 that results in a health-harmful event. Thus, in this case, blood glucose control system may not generate a recommendation 422 even if the activity is predicted.

[0091] In one or more implementations, for example, the activity-recommendation module 418 is configured as a machine learning model that receives, as input, an activity 414 (and in some implementations, an activity state 420), and outputs a recommendation 422. In such an implementation, the activity-recommendation module 418 can be trained using training data that pairs an activity (and in some implementations, an activity state) with a clinically recommended therapy. As an example, the machine learning model may be exposed to an activity (e.g., receive it as input) and attempt to output a recommendation for relaxation therapy. Next, the system may compare the output to the recommended treatment paired with the input in the training data. Based on this comparison, the internal weights of the machine learning model can be adjusted. For example, if the output matches the treatment paired in the training data, the weights may be adjusted (e.g., strengthened) to promote the output during future iterations. However, if the output does not match the treatment paired in the training data or is identified as harmful to the health of the user given the activity, the weights may be adjusted to suppress the output during future iterations. The machine learning model may thus be trained over a number of iterations.

[0092] Alternatively or additionally, the activity-recommendation module 418 may obtain a blood glucose response 424 and a relaxation therapy 426, for example, from an activity (and in some implementations, a state), from a mapping of those activities and relaxation therapies 426 to a blood glucose response 424. As an example, the library may include mappings that map different activities to respective blood glucose responses 424 and one or more respective relaxation therapies. This information may be stored, for example, in a database. In one or more implementations, the mapping may be approved by one or more clinicians. For example, since an activity may be likely to cause a particular blood glucose response 424 and the recommended relaxation therapy 426 is clinically recommended to mitigate the blood glucose response, one or more clinicians may provide, approve, or otherwise the recommended relaxation therapy 426 for the activity 414.

[0093] This information may be input into and maintained by the system (e.g., in a database). In one or more implementations, such mapping may be maintained within a computer-readable storage medium of the user's computing device 108 (e.g., the user's cellular phone). Alternatively or additionally, the mapping may be maintained separate from the computing device 108, such as in a database associated with the blood glucose control system 110 and / or the health monitoring platform 112. Either or both of the remote mapping and the local mapping may be updated when new treatments and activities are added and / or when the treatments mapped to various activities are updated, e.g., when a clinician recommends a treatment different from what was previously clinically recommended for an activity. In one or more implementations, the mapping may be personalized for the user, e.g., to map activities to treatments that were previously performed for the user to control the user's blood glucose response to the activity. In such an implementation, the mapping may be provided by the user (e.g., via user input to 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 118 (e.g., analyte data describing that the user's analyte levels remained within range and / or no harmful deviation occurred).

[0094] Accordingly, recommendation 422 is configured to provide or notify the user of a mitigation therapy 426 for mitigating the blood glucose response 424 to the activity 414 predicted based on the user's location 408. Recommendation 422 may include one or more of various therapies for controlling the user's blood glucose response 424 to the predicted activity 414. By way of non-limiting example, recommendation 422 may include the dosage and / or timing of one or more drugs, activities to perform (e.g., exercise, contact with a medical professional, interruption of an activity, rest) and / or the timing of those activities, the amount and / or timing of one or more foods to consume (e.g., drink a few ounces of juice or take a tablet), etc. The recommendation may be recommended with various therapies without departing from the spirit or scope of the technology described herein.

[0095] Based on recommendation 422, controller 428 outputs command 120. For example, controller 428 provides command 120 to drug delivery system 106, computing device 108, and / or another device (e.g., an additional drug delivery system). In one or more implementations, controller 428 provides command 120 for notifying the user about the recommended mitigation therapy 426. For example, controller 428 provides to computing device 108 a command 120 to cause computing device 108 to display or otherwise output recommendation 422 (or information indicative of recommendation 422). Examples of notifications that may be output by computing device 108 are described in more detail in connection with FIGS. 6-9.

[0096] Additionally or alternatively, controller 428 provides command 120 for controlling a device (e.g., drug delivery system 106) to provide the recommended mitigation therapy 426. For example, controller 428 provides command 120 to drug delivery system 106, and the command causes drug delivery system 106 to administer an amount of drug to person 102.

[0097] In one or more implementations, instruction 120 causes drug delivery system 106 to automatically administer a drug (e.g., a certain dosage) to person 102 without user input. In such an implementation, the device is operably connected in a closed loop. In other implementations, instruction 120 instructs drug delivery system 106 to administer a drug (e.g., a certain dosage) to person 102, but the system prevents the drug from being delivered until a verification input, e.g., an input indicating that the user permits the drug to be delivered, is received from the user. Alternatively or additionally, instruction 120 instructs drug delivery system 106 to administer a dosage of the drug, and drug delivery system 106 requires user interaction to transfer the dosage into person 102's body. For example, the user is required to position drug delivery system 106 against person 102's body and activate the system (e.g., by pressing a button) to administer the drug.

[0098] FIG. 5 shows an example 500 of a mapping for position-assisted blood glucose control. In particular, the illustrated example 500 includes a health event mapping 502 and a recommendation mapping 504. In one or more implementations, health event mapping 502 and recommendation mapping 504 are stored in a storage device accessible to blood glucose control system 110 (or a component thereof), such as a computer-readable storage medium of computing device 108, blood glucose control system 110, and / or health monitoring platform 112. For example, health event mapping 502 and / or recommendation mapping 504 may be configured as a file and / or a database in one or more implementations. In the illustrated example, health event mapping 502 maps position to activity and blood glucose response, and recommendation mapping 504 maps activity to recommendations. It should be understood that the mappings used in connection with the described techniques may map different information than that shown without departing from their spirit or scope.

[0099] In this example, the health event mapping 502 includes fields for a location 506, an activity 508, and a blood glucose response 510. Thus, the health event mapping 502 includes entries, each of which specifies a location 506, and for the location 506 of the entry, an activity 508 and a blood glucose response 510 for the activity 508 are specified. For example, it should be understood that a location in the mapping may be associated with multiple entries since multiple different activities may be performed at that location. An example of such a location is a home where a user can sleep, eat, and exercise. Thus, the location may be more specific, e.g., a kitchen, a bedroom, or a garage. As an example, the activity predictor 416 may utilize the health event mapping 502 to determine an activity 414 based on a predicted location 408.

[0100] Here, the recommendation mapping 504 includes fields for an activity 512, an activity state 514, a blood glucose response 516, and a recommendation 518. Thus, the recommendation mapping 504 includes entries, each of which specifies an activity 512 and an activity state 514. For the activity state 514 of the activity 512, the mapping includes a possible blood glucose response 516 and a recommendation 518 for controlling the blood glucose response, e.g., for mitigating any adverse effects of the blood glucose response. In one or more implementations, the activity - recommendation module 418 may utilize the recommendation mapping 504 to generate a recommendation 422 based on the activity 414 and the activity state 420. Consider the following example in the context of a notification that outputs information corresponding to the recommendation 422.

[0101] FIG. 6 shows an example of a user interface that displays an activity notification. The illustrated example 600 includes an example of a computing device 108 that displays an example of a user interface 602 via a display device, e.g., a touch screen, from FIG. 1. Here, the user interface 602 includes an activity notification 604 indicating that the activity 414 has been detected by the activity predictor 416.

[0102] In this example, the activity corresponds to an exercise predicted based on sensor data 118 indicating that the user is moving to the gym to exercise, e.g., the user is driving or walking to the gym. Activity notification 604 also includes a recommendation 422 instructing the user to consume 50 grams of carbohydrates to reduce the likelihood that the user will experience a hypoglycemic event caused by the exercise. For example, exercise reduces the user's glucose level, and thus consuming 50 grams of carbohydrates before exercise can raise the user's glucose level so that the user's glucose level does not fall below the hypoglycemic threshold after exercise.

[0103] FIG. 7 shows an additional example of a user interface that displays an activity notification. Similar to the illustrated example 600, the illustrated example 700 includes an example of a computing device 108 that displays an example of a user interface 702 via a display device, e.g., a touch screen, from FIG. 1. Here, the user interface 702 includes an activity notification 704 indicating that activity 414 has been detected by activity predictor 416. Notification 704 corresponds to a second notification that is displayed following notification 604 of FIG. 6 and also includes a recommendation 422 that the user consume 50 grams of carbohydrates to reduce the likelihood that the user will experience a hypoglycemic event caused by the exercise.

[0104] Notification 704 may be displayed based on additional sensor data 118 indicating that the user has arrived at the current location of the gym or is closer to the location of the gym than when notification 604 was displayed. Compared to notification 604, notification 704 more aggressively recommends that the user consume 50 grams of carbohydrates to prevent a hypoglycemic event. For example, notification 704 includes a heading "Emergency" and also recommends that the user consume 50 grams of carbohydrates "as soon as possible to prevent post - exercise hypoglycemia". Notably, here, because the user is closer to the time of starting the activity, the blood glucose control system has increased the aggressiveness of recommendation 422.

[0105] FIG. 8 shows an example of an addition to the user interface for displaying activity notifications. Similar to the illustrated examples 600 and 700, the illustrated example 800 includes an example of a computing device 108 that displays an example of a user interface 802 via a display device, e.g., a touch screen, from FIG. 1. Here, the user interface 802 includes an activity notification 804 indicating that activity 414 has been completed. In this case, the activity predictor 416 has detected that the user has completed a physical activity and is currently in a post-exercise state. The activity predictor 416 may detect that the user has completed the activity, for example, based on sensor data 118 indicating that the user is no longer at the location of the gym. Alternatively or additionally, the activity predictor may use other sensor data 118, such as heart rate data indicating that the user's heart rate has decreased and / or accelerometer data indicating that the user is no longer exercising, to determine that the user has completed the activity. In this case, the notification 804 indicates that the blood glucose control system 110 has reduced the amount of insulin to be administered to the user over the next two hours. This is because exercise can potentially lower the user's glucose level, and thus insulin is reduced to prevent the user from experiencing a hypoglycemic event caused by the combination of insulin and exercise.

[0106] FIG. 9 shows an additional example 900 of a user interface for displaying activity notifications. Similar to the illustrated examples 600, 700, and 800, the illustrated example 900 includes an example of a computing device 108 that displays an example of a user interface 902 via a display device, e.g., a touch screen, from FIG. 1. Here, the user interface 902 includes an activity notification 904 indicating that activity 414 has been detected.

[0107] In this example, the activity is determined by activity predictor 416 based on sensor data 118 indicating that the user is at the location of a restaurant, corresponding to the user eating a meal at the restaurant. In this case, notification 904 indicates that the blood glucose control system 110 is increasing the large instantaneous dose of insulin administered to the user. This is done because eating a meal at a restaurant can increase the user's glucose level, and thus increasing the insulin to prevent the user from experiencing hyperglycemic events caused by the combination of insulin and eating a meal at a restaurant.

[0108] In particular, notifications 604, 704, 804, and 904 are shown as being displayed on the home screen of the user's smartphone. However, it should be understood that the notifications can be displayed in a variety of different ways and on a variety of different types of devices without departing from the spirit or scope of the technology described.

[0109] FIG. 10 shows an example 1000 of a first combination of devices for performing location-based blood glucose control. The illustrated example 1000 includes a computing device 108 having an analyte monitoring device 104, a drug delivery system 106, and a blood glucose control system 110.

[0110] According to the described technology, 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 (such as BLE), to perform any of the blood glucose control techniques based on the above and below positions. In a variant, the analyte monitoring device 104, the drug delivery system 106, and the computing device 108 are operatively connected to implement position-assisted blood glucose control 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 (such as an insulin pump) having an infusion set that is applied to the person 102 and delivers a drug via the infusion set at the insertion site.

[0111] As a closed-loop system, the analyte monitoring device 104, the drug delivery system 106, and the computing device 108 are configured to monitor the analyte of the person 102 wearing the analyte monitoring device 104, recommend a treatment based on the activities predicted to be participated in by the person 102 at the predicted position, and administer the recommended treatment (for example, via the drug delivery system 106) without user interaction.

[0112] In contrast, in a partially open system, the user may be required to verify the treatment before it is administered by the system. For example, the user may be required to provide approval of the recommended drug dosage via the display of the drug delivery system 106 or the computing device 108 before it is automatically administered by the drug delivery system 106. Once verified, the drug delivery system 106 may administer a certain dosage of the drug recommended by the blood glucose control system 110. In an open system, the blood glucose control system 110 may simply output (e.g., display) the recommended therapy via the computing device 108 (e.g., the display of the computing device 108). To administer the recommended dosage of the drug in an open system, the user may provide an input specifying the recommended drug dosage to the drug delivery system 106 and select a control (e.g., a displayed control) for the drug delivery system 106 to administer the dosage. In contrast to the system of Example 1000, which may be connected to operate in a closed-loop configuration that excludes user interaction, consider the following example where the drug delivery system 106 is configured as a pen.

[0113] FIG. 11 shows an example 1100 of a second combination of devices for performing location-based blood glucose control. The illustrated example 1100 includes an analyte monitoring device 104, a drug delivery system 106, and a computing device 108 having a blood glucose control system 110. However, in contrast to Example 1000, in the illustrated example 1100, the drug delivery system 106 is configured as a pen (e.g., an insulin pen) rather than a wearable pump.

[0114] Since the drug delivery system 106 is configured as a pen, the system in the illustrated example 1100 necessarily involves user interaction. Such interactions may also include, for example, interactions for positioning the pen at a location where the drug stored in the pen can be administered to a person, and interactions for initiating the administration of the drug (e.g., pressing a button). Thus, when the analyte monitoring device 104, the drug delivery system 106, and the computing device 108 are configured as in example 1100, these devices can be operably connected to implement position-assisted blood glucose control as an open-loop system or a partially open-loop system.

[0115] FIG. 12 shows an example 1200 of a third combination of devices for implementing position-based blood glucose control. The illustrated example 1200 includes an analyte monitoring device 104 and a computing device 108 having a blood glucose control system 110.

[0116] However, the illustrated example 1200 does not include the drug delivery system 106. This represents a configuration where the analyte monitoring device 104 and the computing device 108 are not operably connected to the drug delivery system 106. In such a configuration, the blood glucose control system 110 does not transmit the instruction 120 to the drug delivery system 106. Instead, the blood glucose control system 110 transmits the instruction 120 regarding the recommended therapy, such as outputting (e.g., displaying) the drug dosage and / or other recommended actions, to the computing device 108. In such an implementation, the user may interact with the drug delivery system 106 to specify and / or administer the drug dosage, such as when the drug delivery system 106 is a syringe that the user fills with the drug (from a separate container) and injects into the user's body. In at least one variant of the exemplary 1200 configuration, the sensor data 118 may include analyte data. The blood glucose control system 110 may use such analyte data to use the predicted location and the activity at that location and generate recommendations for palliative treatment. In contrast to this example, consider the following examples of FIGS. 13 and 14 that do not include the analyte monitoring device 104.

[0117] FIG. 13 shows an example 1300 of a fourth combination of devices for performing location-based blood glucose control. The illustrated example 1200 includes the drug delivery system 106 and a computing device 108 having a blood glucose control system 110.

[0118] However, the illustrated example 1300 does not include the analyte monitoring device 104. This represents a scenario where 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 blood glucose control system 110 can generate recommendations for treatment without using analyte data. Instead, the blood glucose control system 110 is associated with the computing device 108 and predicts the location of the user wearing the drug delivery system 106 (e.g., a pump), and the blood glucose control system 110 uses other data to predict the user's activity at that location. Examples of such other data have been described above and may include, for example, GPS data and data generated by other sensors of the computing device. Based on the location and activity predictions generated by the blood glucose control system 110 using this other data, the blood glucose control system 110 may further generate recommendations for palliative therapy 426.

[0119] As shown in the embodiment of FIG. 10, the drug delivery system 106 and the computing device 108 may be operably connected to implement location-assisted blood glucose control as a closed-loop system, an open-loop system, or a partially open-loop system. As a closed-loop system, for example, the drug delivery system 106 and the computing device 108 enable treatment to be recommended based on the predicted activity of the person 102 wearing the drug delivery system 106 at the predicted location, and are configured to administer the recommended treatment (e.g., via the drug delivery system 106).

[0120] In contrast, in a partially open system, the user may be required to verify the treatment before it is administered by the system. For example, the user may be required to provide verification of the recommended drug dosage via the display of the drug delivery system 106 or the computing device 108 before it is automatically administered by the drug delivery system 106. Once verified, the drug delivery system 106 may administer a certain dosage of the drug recommended by the blood glucose control system 110.

[0121] In an open system, the blood glucose control system 110 may simply output (e.g., display) the recommended therapy via the computing device 108 (e.g., the display of the computing device 108). To administer the recommended dosage of the drug in an open system, the user may provide an input specifying the recommended drug dosage to the drug delivery system 106 and select a control (e.g., a displayed control) for causing the drug delivery system 106 to administer the dosage. In contrast to the system of Example 1300, which may be connected to operate in a closed-loop configuration that eliminates user interaction, consider the following example in which the drug delivery system 106 is configured as a pen.

[0122] FIG. 14 shows an example 1400 of a fifth combination of devices for performing location-based blood glucose control. The illustrated example 1200 includes a drug delivery system 106 and a computing device 108 having a blood glucose control system 110. In contrast to Example 1300, in Example 1400, the drug delivery system 106 is configured as a pen (e.g., an insulin pen) rather than a wearable pump.

[0123] However, similar to the illustrated Example 1300, Example 1400 does not include the analyte monitoring device 104. This represents a scenario where the drug delivery system 106 (e.g., a pen) and the computing device 108 are not operably connected to the analyte monitoring device 104. In such a configuration, the blood glucose control system 110 can generate recommendations for treatment without using analyte data. Instead, the blood glucose control system 110 predicts the location of the user associated with the computing device 108 and the drug delivery system 106 (e.g., a pen), and uses other data to predict the user's activity at that location. Examples of such other data have been described above.

[0124] Based on the location and activity predictions generated by the blood glucose control system 110 using such other data, the blood glucose control system 110 may further generate recommendations for palliative therapy 426. Instructions 120 for administering such treatment may be communicated to the drug delivery system 106 configured as a pen (e.g., a certain dose to be delivered), but at some point, user interaction is required to administer the drug to the user. As described above, such user interaction may simply involve positioning the pen on the body of the person to whom the drug is to be delivered and selecting the control for administering the drug. Alternatively, such user interaction may involve verifying the recommended dose and then positioning the pen on the body of the person to whom the drug is to be delivered and selecting the control for administering the drug.

[0125] Exemplary details of the technology related to location-assisted blood glucose control have been discussed. Next, some examples of procedures are considered to show additional aspects of these technologies.

[0126] Exemplary Procedures This section describes an example of a procedure for position-assisted blood glucose control. The aspects of the procedure may be implemented in hardware, firmware, software, or combinations thereof. The procedure is shown as a set of blocks that specify operations to be performed by one or more devices, and is not necessarily limited to the order shown for performing the operations by each block. In at least some implementations, the treatment is performed by a blood glucose control system such as the blood glucose control system 110.

[0127] FIG. 15 is a flowchart showing an algorithm executable by a blood glucose control system to provide position-assisted recommendations for controlling blood glucose response, as a step-by-step procedure 1500 following a work procedure.

[0128] Sensor data is obtained from one or more sensors (block 1502). By way of example, the blood glucose control system 110 obtains sensor data 118 from one or more sensors. According to the described technology, the blood glucose control system 110 may receive sensor data 118 from various sources 402, examples of which include, but are not limited to, Global Positioning System (GPS) data, Wi-Fi information (e.g., Service Set Identifier (SSID)), Bluetooth® Low Energy (BLE) information, data generated using a cellular antenna (e.g., Long Term Evolution (LTE)), microphone data (e.g., sound data), accelerometer data, gyroscope data, magnetometer data, barometer data, ambient or internal temperature data (e.g., generated using a temperature sensor), optical 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 (different data regarding one or more different analytes or the same analyte from different sources), and drug data.

[0129] The user's location is detected based on sensor data (block 1504). As an example, based on sensor data 118, location prediction engine 122 detects the location 408 of the user, e.g., person 102 wearing analyte monitoring device 104. In one or more implementations, location prediction engine 122 detects the user's location 408 based on at least two different types of sensor data 118. For example, location prediction engine 122 detects the user's location 408 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, location prediction engine 122 uses a first sensor data to detect the user's location and a second sensor data to confirm the user's location. Alternatively or additionally, location prediction engine 122 uses two types of sensor data to distinguish which of a plurality of candidate locations corresponds to the user's actual physical location. For example, location prediction engine 122 detects at least two candidate locations of the user based on the first sensor data. Based on the second sensor data, location prediction engine 122 selects (or excludes all but one of the candidate locations) one of the at least two candidate locations as the user's location.

[0130] The activities that the user performs at that location are predicted based on the user's location (block 1506). As an example, recommendation engine 124 predicts the activity 414 that the user performs at location 408. Examples of activities include eating, exercising, and sleeping. Certainly, the system may predict other activities without departing from the spirit or scope of the described technology.

[0131] Recommendations are generated (block 1508) to control a user's blood glucose response to a predicted activity. As an example, the recommendation engine 124 of the blood glucose control system 110 generates a recommendation 422 to manage the user's blood glucose response 424 to the predicted activity 414. In other words, the blood glucose control system 110 uses the activity 414 predicted to be performed by the user to generate one or more recommendations 422 to control the user's blood glucose response 424, e.g., the blood glucose response of person 102 to the predicted activity. For example, the recommendation engine 124 generates a recommendation 422 for one or more therapies to mitigate potential adverse effects resulting from the predicted activity 414. Examples of adverse effects include glucose excursions from at least a safe glucose range, e.g., hyperglycemia or hypoglycemia.

[0132] Having described examples of procedures according to one or more implementations, we now consider examples of systems and devices that can be utilized to implement the various techniques described herein.

[0133] Exemplary Systems and Devices FIG. 16 generally at 1600 shows an example of a system that includes an example of a computing device 1602 representing one or more computing systems and / or devices capable of implementing the various techniques described herein. This is illustrated by including the blood glucose control system 110. The computing device 1602 can be, for example, a server of a service provider, 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.

[0134] 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 that are communicatively coupled to each other. Although not shown, the computing device 1602 may further include a system bus or other data and command transfer system that couples the various components to each other. 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 that utilizes any of a variety of bus architectures. Various other examples, such as control lines and data lines, are also contemplated.

[0135] The processing system 1604 represents functionality for performing one or more operations using hardware. Thus, the processing system 1604 is illustrated as including hardware elements 1610 that may be configured as a processor, functional blocks, etc. This may include implementations within the hardware as an application specific integrated circuit or other logic device formed using one or more semiconductors. The hardware elements 1610 are not limited by the materials from which they are formed or the processing mechanisms employed therein. For example, a processor may be formed of semiconductors and / or transistors (e.g., may be configured as an electronic integrated circuit (IC). In such a context, processor-executable instructions may be electronically executable instructions.

[0136] Computer-readable medium 1606 is illustrated as including memory / storage device 1612. Memory / storage device 1612 represents the memory / storage capacity associated with one or more computer-readable media. Memory / storage device 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 device 1612 may include fixed media (e.g., RAM, ROM, fixed hard drive, etc.) as well as removable media (e.g., flash memory, removable hard drive, optical disk, etc.). Computer-readable medium 1606 may be configured in various other ways as further described below.

[0137] Input / output interface 1608 represents the function that enables a user to input commands and information into computing device 1602 and also enables information to be presented to the user and / or other components or devices using various input / output devices. Examples of input devices include a keyboard, a cursor control device (e.g., a mouse), a microphone, a scanner, a touch function (e.g., a capacitive sensor or other sensor configured to detect physical contact), a camera (e.g., one that can recognize movement as a non-contact gesture using visible wavelengths or non-visible wavelengths such as infrared frequencies), etc. Examples of output devices include display devices (e.g., a monitor or a projector), speakers, printers, network cards, tactile response devices, etc. Thus, computing device 1602 may be configured in various ways to support user interaction as further described below.

[0138] In this specification, various techniques may be described in the general context of software, hardware elements, or program modules. Generally, such modules may include routines, programs, objects, elements, components, data structures, etc., that perform specific tasks or implement specific abstract data types. As used in this specification, the terms "module," "function," and "component" generally represent software, firmware, hardware, or combinations thereof. The features of the techniques described herein are platform-independent, meaning that the techniques can be implemented on a variety of commercial computing platforms having a variety of processors.

[0139] Implementations of the described modules and techniques may be stored on or transmitted via some form of computer-readable medium. The computer-readable medium may include various media that can be accessed by computing device 1602. By way of example and not limitation, the computer-readable medium may include "computer-readable storage media" and "computer-readable signal media".

[0140] A "computer-readable storage medium" may refer to a medium and / or device that enables persistent and / or non-transitory storage of information, as contrasted with mere signal transmission, carrier waves, or signals themselves. 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 a storage device implemented in a suitable method or technology for storing information such as computer-readable instructions, data structures, program modules, logic elements / circuits, or other data. Examples of computer-readable storage media include RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disk (DVD) or other optical storage devices, hard disks, magnetic cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or other storage devices, tangible media, or products suitable for storing desired information and accessible by a computer, but are not limited thereto.

[0141] A "computer-readable signal medium" may refer to a signal-bearing medium configured to transmit instructions to the hardware of computing device 1602 via a network or the like. A signal medium 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. A signal medium also includes any information delivery medium. The term "modulated data signal" means a signal having one or more of those 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 wired networks or direct wired connections, and wireless media such as acoustic, RF, infrared, and other wireless media.

[0142] As previously described, hardware element 1610 and computer-readable medium 1606 may be used in some embodiments to implement at least some aspects of the techniques described herein, such as to execute one or more instructions, in the form of hardware-implemented modules, programmable device logic, and / or fixed device logic. Hardware may include components of an integrated circuit or on-chip system, application specific integrated circuit (ASIC), field programmable gate array (FPGA), complex programmable logic device (CPLD), and other implementations in silicon or other hardware. In this context, hardware may be operated as a processing device that defines program tasks by instructions and / or logic embodied by the hardware, as well as hardware utilized to store instructions for execution, e.g., the previously described computer-readable storage medium.

[0143] Using the foregoing combinations, various techniques described herein may be implemented. Thus, 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 functions corresponding to software and / or hardware modules. Thus, an implementation form of a module executable as software by computing device 1602 may be achieved at least in part in hardware, for example, via the use of a computer-readable storage medium and / or the hardware elements 1610 of processing system 1604. Instructions and / or functions may be executable / operable by one or more articles of manufacture (e.g., one or more computing devices 1602 and / or processing systems 1604) for implementing the techniques, modules, and examples described herein.

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

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

[0146] The platform 1616 may abstract the resources and functionality for connecting the computing device 1602 to other computing devices. The platform 1616 may also abstract the scaling of resources and play a role in providing a scale level that responds to the demand faced by the resources 1618 implemented via the platform 1616. Thus, in embodiments of interconnected devices, the implementation of the functionality described herein may be distributed across the entire system 1600. For example, the functionality may be implemented, in part, on the computing device 1602 and also via the platform 1616 that abstracts the functionality of the cloud 1614.

[0147] Item 1. A method, comprising: obtaining sensor data from one or more sensors; detecting a user's position based on the sensor data; predicting an activity that the user will perform at the position; and generating a recommendation for controlling the user's blood glucose response to the predicted activity.

[0148] Item 2. The method according to item 1, wherein generating the recommendation further comprises predicting the user's blood glucose response to the predicted activity, determining whether the user's blood glucose response to the predicted activity will cause a health - harmful event, and determining a relaxation therapy for preventing the health - harmful event in response to determining that the user's blood glucose response to the predicted activity will cause a health - harmful event, and the recommendation includes the relaxation therapy.

[0149] Item 3. The method according to item 1 or 2, wherein detecting the user's position is based on at least two different types of sensor data.

[0150] Item 4. The method according to any one of items 1 to 3, wherein detecting the user's position comprises detecting the user's position based on first sensor data and confirming the user's position based on second sensor data.

[0151] Item 5. The method according to any one of items 1 to 4, wherein detecting the user's position comprises detecting at least two candidate positions of the user based on first sensor data and selecting one of the at least two candidate positions as the user's position based on second sensor data.

[0152] Item 6. The method according to any one of items 1 to 5, wherein predicting the activity includes predicting the state of the activity based on the position, the state including a pre - activity state, an activity state, or a post - activity state, and the recommendation is based on the state of the activity.

[0153] The method according to any one of items 1 to 6, further comprising causing a recommendation for controlling a user's blood glucose response to be displayed on a computing device.

[0154] Item 8. A system comprising: one or more sensors for obtaining sensor data associated with a user; a drug delivery system for administering a drug to the user; and at least a memory and a processor for performing operations, the operations including detecting the user's position based on the sensor data, predicting an activity that the user will perform at the position based on the user's position, determining an amount of the drug to be administered to the user to control the user's blood glucose response to the predicted activity, and transmitting an instruction to the drug delivery system, the instruction causing the drug delivery system to deliver the amount of the drug to the user.

[0155] Item 9. The system according to item 8, further comprising an analyte monitoring device for obtaining the user's analyte data, and the analyte monitoring device and the drug delivery system are connected in a closed loop.

[0156] Item 10. The system according to item 8 or 9, wherein the instruction causes the drug delivery system to deliver the amount of the drug to the user without user input.

[0157] Conclusion Although the systems and techniques are described in a language specific to structural features and / or methodological acts, it should be understood that the systems and techniques defined in the appended claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms for implementing the claimed subject matter.

Description of Reference Numerals

[0158] 100 Environment 102 Person 104 Analyte Monitoring Device 106 Drug Delivery System 108 Computing Device 110 Blood glucose control system 112 Health monitoring platform 114 Internet of Things 116 Network 118 Sensor data 120 Command 122 Location prediction engine 124 Recommendation engine 126 User data 128 Memory device 130 Monitoring service 200 Example 202 Analyte sensor 204 Sensor module 206 Skin 208 Transmitter 210 Adhesive pad 212 Analyte measurement value 214 Supplementary sensor information 300 Implementation form 302 Drug pump 304 Infusion set 306 Tube 308 Infusion site 310 Communication module 312 Drug delivery control unit 314 Drug reservoir 316 Display module 318 Safety module 320 Battery 322 Display device 400 System 402 Source 404 First sensor data 406 Second sensor data 408 Location 410 Location predictor 412 Location confirmation engine 414 Activity 416 Activity predictor 418 Activity - recommendation module 420 Activity state 422 Recommendation 424 Blood glucose response 426 Palliative care 428 Controller 500 cases 502 Health event mapping 504 Recommended mapping 506 Location 508 Activity 510 Blood glucose response 512 Activity 514 Activity state 516 Blood glucose response 518 Recommendation 600, 700, 800, 900 cases 602, 702, 802, 902 User interface 604, 704, 804, 904 Notification 1500 procedures 1602 Computing device 1604 Processing system 1606 Computer-readable medium 1608 I / O interface 1610 Hardware elements 1612 Memory / storage device 1614 Cloud 1616 Platform 1618 Resource

Claims

1. A method comprising: obtaining sensor data from one or more sensors; detecting a user's position based on the sensor data; predicting an activity that the user will perform at the position based on the user's position; generating a recommendation for controlling the user's blood glucose response to the predicted activity.

2. The generating of the recommendation further comprises: predicting the user's blood glucose response to the predicted activity; determining whether the user's blood glucose response to the predicted activity will cause a health - harmful event; in response to determining that the user's blood glucose response to the predicted activity will cause the health - harmful event, determining a relaxation therapy for preventing the health - harmful event, wherein the recommendation includes the relaxation therapy.

3. The method according to claim 1 or 2, wherein the detecting of the user's position is based on at least two different types of sensor data.

4. The method according to any one of claims 1 to 3, wherein the detecting of the user's position includes detecting the user's position based on first sensor data and confirming the user's position based on second sensor data.

5. The detecting of the user's position includes: detecting at least two candidate positions of the user based on first sensor data; selecting, based on second sensor data, one of the at least two candidate positions as the user's position.

6. The predicting of the activity includes predicting a state of the activity based on the position, the state including a pre - activity state, an activity state, or a post - activity state, and the recommendation being based on the state of the activity.

7. The method according to any one of claims 1 to 6, further comprising displaying the recommendation for controlling the user's blood glucose response on a computing device.

8. A system comprising: one or more sensors for obtaining sensor data associated with a user; A drug delivery system for administering a drug to the user, comprising at least a memory and a processor for executing operations, the operations comprising: detecting the user's position based on the sensor data; predicting an activity that the user will perform at the position based on the user's position; determining the amount of the drug to be administered to the user to control the user's blood glucose response to the predicted activity; transmitting an instruction to the drug delivery system, the instruction causing the drug delivery system to deliver the amount of the drug to the user. **Claim 9** The system according to claim 8, further comprising an analyte monitoring device for acquiring the user's analyte data, wherein the analyte monitoring device and the drug delivery system are connected in a closed loop. **Claim 10** The system according to claim 8 or 9, wherein the instruction causes the drug delivery system to deliver the amount of the drug to the user without user input.

Images