Location assisted glycemic control

Abstract

Location assisted glycemic control is described. A glycemic control system obtains sensor data from one or more sensors and detects a location of a user based on the sensor data. The glycemic control system predicts an activity at which the user is to perform based on a location of the user, and generates a recommendation to control a glycemic response of the user to the predicted activity. In one or more implementations, a glycemic control system causes suggestions to be displayed to control a user's glycemic response. In one or more implementations, the suggestion corresponds to administration of an amount of drug to the user to control a glycemic response to the predicted activity, and the glycemic control system transmits instructions to the drug delivery system, which causes the drug delivery system to administrate the amount of drug to the user.

Description

[0001] Related Applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 389,491, filed on July 15, 2022, and entitled “Position-Assisted Glucose Control,” the entire disclosure of which is hereby incorporated by reference. Background Art

[0003] Diabetes is a metabolic disease that affects hundreds of millions of people. For these people, monitoring blood glucose levels and regulating these levels to be within an acceptable range is important not only to mitigate long-term problems such as heart disease and visual impairment, but also to avoid the effects of hyperglycemia and hypoglycemia. Maintaining blood glucose levels within an acceptable range can be challenging because levels change almost constantly over time and in response to daily events and activities such as eating, exercising, sleeping, or stress. Summary of the invention

[0004] To overcome these problems, location-assisted blood glucose control is utilized. A blood glucose control system obtains sensor data from one or more sensors and detects a user's location based on the sensor data. The blood glucose control system predicts an activity that a user will perform based on the user's location and generates a suggestion for controlling the user's blood glucose response to the predicted activity. In one or more specific implementations, the blood glucose control system enables the suggestion for controlling the user's blood glucose response to be displayed. In one or more specific implementations, the suggestion corresponds to administering a certain amount of medication to the user to control the blood glucose response to the predicted activity, and the blood glucose control system transmits instructions to a medication delivery system, which causes the medication delivery system to administer the certain amount of medication to the user.

[0005] This Summary introduces some concepts in a simplified form that are further described in the Detailed Description below. Therefore, this Summary is not intended to identify essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Detailed description is given with reference to the accompanying drawings.

[0007] Figure 1 is an illustration of an environment in one example implementation that is operable to employ location-based blood glucose control.

[0008] Figure 2 Describes in more detail Figure 1 An example implementation of an analyte monitoring device.

[0009] Figure 3 Describes in more detail Figure 1An example implementation of a drug delivery system.

[0010] Figure 4 An example of a system that receives and processes sensor data from various sources to generate blood glucose control recommendations based on a user's location is depicted.

[0011] Figure 5 An example of mapping for location-assisted blood glucose control is depicted.

[0012] Figure 6 Depicted is an example of a user interface displaying activity notifications.

[0013] Figure 7 An additional example of a user interface displaying activity notifications is depicted.

[0014] Figure 8 An additional example of a user interface displaying activity notifications is depicted.

[0015] Fig. 9 An additional example of a user interface displaying activity notifications is depicted.

[0016] Fig.10 An example of a first combination of apparatus for implementing location-based blood glucose control is depicted.

[0017] Fig.11 An example of a second combination of apparatus for implementing location-based blood glucose control is depicted.

[0018] Fig.12 An example of a third combination of apparatus for implementing location-based blood glucose control is depicted.

[0019] Fig.13 An example of a fourth combination of means for implementing location-based blood glucose control is depicted.

[0020] Fig.14 An example of a fifth combination of means for implementing location-based blood glucose control is depicted.

[0021] Fig.15 A procedure in one example implementation of location-assisted blood glucose control is depicted.

[0022] Fig.16 An example of a system is shown that includes an example of a computing device, which represents one or more computing systems and / or devices that can implement the various techniques described herein. DETAILED DESCRIPTION

[0023] Overview

[0024] Location-assisted blood glucose control is described. According to the technology, a system for location-assisted blood glucose control is configured to detect a person's location based on sensor data, and then predict an activity that the person will perform at the location based on the person's location. In some cases, the person's location can be detected based on at least two different types of sensor data. For example, global positioning system (GPS) data obtained from a user's smart phone can be used to detect that the user is at a location corresponding to a "gym", and the signal strength of a wireless network connection associated with the gym's location can be used to confirm that the user is at the gym. As another example, at least two different types of sensor data can be used to distinguish at least two candidate locations. For example, consider that a location corresponding to a gym is "next door" to a different location corresponding to a restaurant. In this example, first sensor data (e.g., GPS data) can be used to detect whether the user is at the gym or at a restaurant, and second sensor data (e.g., wireless network signal strength) can be used to select one of the two locations in order to determine the user's current location.

[0025] Based on the detected location, the blood glucose control system predicts an activity that the user will perform at the location. In some cases, the prediction is based on historical data indicating that the user has previously performed the activity at the location or historical data indicating that other users have previously performed the activity at the location. Alternatively or additionally, the blood glucose control system predicts the activity that the user will perform at the location based on a location type (or tag) associated with the location, for example, different gyms may be associated with gym location types (or tags), and different restaurants may be associated with restaurant location types (or tags). Continuing with the example above, if the system detects that the person is in a gym, the system may predict that the person will perform an activity associated with exercising at a gym location. Conversely, if the system detects that the user is in a restaurant, the system may predict that the user will perform an activity associated with eating at a restaurant location.

[0026] It is worth noting that the performance of different activities may change the analyte level in the human body. For example, exercise may reduce a person's glucose level, while eating may increase a person's glucose level. For some users, such as users with type II diabetes, such activities may cause a person's glucose level to exceed a target range associated with a dangerous medical condition. As an example, eating a meal containing too many carbohydrates may increase a person's glucose level above the target range, causing the person to experience a hyperglycemic event, while high-intensity exercise may reduce a person's glucose level below the target range, causing the person to experience a hypoglycemic event.

[0027] Thus, in order to maintain the user's glucose level within a target range based on the performance of activities at the detected location, the system generates recommendations to control the user's glycemic 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 a gym location, the system may output a notification or alert on the person's smartphone instructing the person to consume carbohydrates before exercising at the gym. Consuming carbohydrates before exercising may cause the person's glucose level to rise before exercising so that the person's blood glucose level will remain within the target range after the glucose level drops as a result of the subsequent exercise.

[0028] In one or more specific implementations, the recommendation may correspond to a drug delivery. In this scenario, the system may control a drug delivery system (e.g., an insulin pen or pump) to deliver the drug to the person based on the recommendation. For example, based on a prediction that the person will dine at a restaurant, the system may determine a bolus dose of insulin to be delivered to the person to prevent the person's glucose level from exceeding a target range for hyperglycemia, and then transmit a control signal to the drug delivery system that causes the drug delivery system to automatically deliver a bolus dose of insulin to the person.

[0029] In some aspects, the technology described herein relates to a method comprising: obtaining sensor data from one or more sensors; detecting a location of a user based on the sensor data; predicting an activity that the user will perform at the location based on the user's location; and generating a recommendation for controlling the user's glycemic response to the predicted activity.

[0030] In some aspects, the technology described herein relates to a method wherein generating a recommendation further comprises: predicting a user's glycemic response to a predicted activity; determining whether the user's glycemic response to the predicted activity will result in an adverse health event; and in response to determining that the user's glycemic response to the predicted activity will result in an adverse health event, determining a mitigation therapy to prevent the adverse health event, wherein the recommendation includes the mitigation therapy.

[0031] In some aspects, the technology described herein relates to a method in which detecting a user's location is based on at least two different types of sensor data.

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

[0033] In some aspects, the technology described herein relates to a method in which detecting a location of a user includes: detecting at least two candidate locations of the user based on first sensor data; and selecting one of the at least two candidate locations as the location of the user based on second sensor data.

[0034] In some aspects, the technology described herein relates to a method in which a recommendation includes administering to a user an amount of a medication to control the user's glycemic response to a predicted activity.

[0035] In some aspects, the technology described herein relates to a method that also includes transmitting instructions to a drug delivery system, the instructions causing the drug delivery system to administer the amount of drug to a user.

[0036] In some aspects, the technology described herein relates to a method wherein the drug comprises insulin.

[0037] In some aspects, the technology described herein relates to a method wherein predicting an activity includes predicting a state of the activity based on a location, the state including a pre-activity state, an activity state, or a post-activity state, and wherein a suggestion is based on the state of the activity.

[0038] In some aspects, the technology described herein relates to a method that also includes: receiving additional sensor data; determining additional locations of a user based on the additional sensor data; predicting that the user is in different activity states based on the additional locations of the user; and generating additional suggestions based on the different activity states.

[0039] In some aspects, the technology described herein relates to a method that also includes displaying, on a computing device, suggestions for controlling a user's glycemic response.

[0040] In some aspects, the technology described herein relates to a method wherein the predicted activity includes exercising, eating, or sleeping.

[0041] In some aspects, the technology described herein relates to 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 one memory and a processor for performing 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 user's location; determining an amount of drug to administer to the user to control the user's glycemic response to the predicted activity; and transmitting instructions to the drug delivery system that cause the drug delivery system to deliver the amount of drug to the user.

[0042] In some aspects, the technology described herein relates to a system that also includes an analyte monitoring device for obtaining analyte data of a user, wherein the analyte monitoring device and the drug delivery system are connected in a closed loop.

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

[0044] In some aspects, the technology described herein relates to a system wherein instructions cause a drug delivery system to deliver the amount of drug to a user without user input.

[0045] In some aspects, the technology described herein relates to a system wherein the drug comprises insulin and wherein the drug delivery system comprises an insulin pump.

[0046] In some aspects, the technology described herein relates to a method comprising: detecting a location of a user 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 glycemic response to the predicted activity; determining whether the user's glycemic response to the predicted activity will result in an adverse health event; and in response to determining that the user's glycemic response to the predicted activity will result in an adverse health event, transmitting instructions to an insulin pump so that the insulin pump controls the user's glycemic response by administering insulin to the user.

[0047] In some aspects, the technology described herein relates to a method that also includes obtaining a glucose measurement of a user from a glucose monitoring device worn by the user, wherein predicting a glycemic response further includes predicting the user's glycemic response to a predicted activity based at least in part on the glucose measurement.

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

[0049] In the following discussion, an exemplary environment in which the techniques described herein may be employed is first described. Specific implementation details and examples of procedures that may be performed in the exemplary environment and other environments are then described. Execution of the exemplary procedures is not limited to the exemplary environment, and the exemplary environment is not limited to execution of the exemplary procedures.

[0050] Environment Examples

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

[0052] Analyte monitoring device 104, drug delivery system 106, and one or more computing devices 108 (associated with person 102) may be communicatively coupled in various ways, such as by using one or more wireless communication protocols or technologies. For example, analyte monitoring device 104, drug delivery system 106, and one or more computing devices 108 may communicate with each other using one or more of radio, cellular, Wi-Fi, Bluetooth (e.g., Bluetooth low energy link), near field communication (NFC), and 5G (to name a few).

[0053] Through this communication connection, in one or more specific implementations, the analyte monitoring device 104, the drug delivery system 106, and one or more computing devices in the computing device 108 can form a closed-loop system. 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 interactions involving mitigation of adverse health events (e.g., glycemic events). Instead, the device processes various information and makes various predictions and determinations, such as about the user's location, the activities that the user is performing or will perform based on the location, the glycemic response to these activities, and the treatment (if any) required to alleviate these glycemic responses. In a closed-loop system, the device can then provide the determined treatment without user interaction, for example, the drug delivery system 106 is controlled to administer the drug to the person 102.

[0054] In one or more specific implementations, the analyte monitoring device 104 is a wearable device such that it is worn by the person 102 while the device performs various operations. Additionally or alternatively, the analyte monitoring device 104 performs one or more operations before or after being worn by the person 102. Broadly, the analyte monitoring device 104 is configured to provide measurements of an analyte (e.g., glucose) of the person 102. For example, the analyte monitoring device 104 may be configured with an analyte sensor that detects one or more signals indicating an analyte in the body of the person 102 and enables the generation of analyte measurements or estimates (e.g., estimated glucose values). These analyte measurements (e.g., glucose measurements) may correspond to one or more computing devices or drug delivery systems 106 in the computing device 108 or otherwise be packaged to be transmitted to one or more computing devices or drug delivery systems in the computing device as analyte data (which is an example of sensor data 118).

[0055] In at least one embodiment, the analyte monitoring device 104 is a glucose monitoring system. As an example, the analyte monitoring device 104 can be configured as a continuous glucose monitoring (CGM) system, such as a wearable CGM system. As used herein, the term "continuously" when used in conjunction with analyte monitoring can refer to the ability of the device to generate measurements substantially continuously, such that the device can be configured to generate analyte measurements at regular or irregular time intervals (e.g., approximately every hour, approximately every 30 minutes, approximately every 5 minutes, etc.), in response to establishing a communication connection with a different device (e.g., when the computing device 108 establishes a wireless connection with the analyte monitoring device 104 to retrieve one or more of these measurements), etc. However, in other embodiments, the glucose monitoring device may not be "continuous," but rather provide glucose measurements when requested. With respect to Figure 2 This functionality, as well as additional aspects of the configuration of the analyte monitoring device 104, are discussed in greater detail.

[0056] In addition to generating sensor data 118 (including analyte data indicating the measurement results of analytes in the body of person 102), analyte monitoring device 104 also transmits the generated sensor data 118 to, for example, computing device 108. Analyte monitoring device 104 can use analyte sensors or other sensors to transmit data in real time, such as when data is generated. Alternatively or in addition, analyte monitoring device 104 can communicate data to computing device 108 at predetermined time intervals. For example, analyte monitoring device 104 can be configured to transmit sensor data 118 to computing device 108 approximately every five minutes. Of course, without departing from the spirit or scope of the technology, the interval at which analyte monitoring device 104 transmits sensor data 118 may be different from the above examples. According to the technology, data can be communicated to computing device 108 by analyte monitoring device 104 based on other bases.

[0057] Additionally, computing device 108 may maintain sensor data 118, at least temporarily, for example, in a storage device (not shown) of computing device 108. Sensor data 118 may also be maintained in such storage device of computing device 108 or in storage device of a different device along with other associated data, such as corresponding timestamps and / or identifiers of data packets transmitted therein, to name a few examples.

[0058] As depicted, the system may include one or more computing devices 108 according to the techniques. For example, in one or more scenarios, the techniques may be implemented using a computing device 108 such as a mobile phone. Alternatively, the techniques may be implemented using multiple computing devices 108, which in at least one variation may include both wearable devices (e.g., smart watches, mouth guards, contact lenses, smart glasses, chest bands, earbuds or headphones, to name a few) and mobile phones. In such a scenario, both devices are capable of performing at least some of the same operations, such as receiving sensor data 118 from the analyte monitoring device 104 (and from other sources), generating sensor data 118 using onboard or associated sensors, transmitting the data to the glycemic control system 110 and / or health monitoring platform 112 via a network 116, displaying information related to the data, displaying information related to recommendations generated by the glycemic control system 110 and / or health monitoring platform 112, helping control other devices (e.g., controlling the drug delivery system 106), and the like. Alternatively or additionally, different devices may have different capabilities that other devices do not have or that are limited to specific devices through computing instructions.

[0059] The blood glucose control system 110 applies or recommends treatment based on determinations made by processing the sensor data 118 and by providing instructions 120, such as by providing instructions 120 to the drug delivery system 106, the computing device 108, and / or another device (e.g., an additional drug delivery system). According to the described techniques, the blood glucose control system 110 makes these determinations and applies or recommends treatment at least in part by utilizing 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.

[0060] In the example shown, the blood glucose control system 110 is depicted as including a location prediction engine 122 and a suggestion 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 technology. Although depicted as being separate from the analyte monitoring device 104, the drug delivery system 106, the computing device 108, and the health monitoring platform 112, in one or more specific implementations, at least a portion of the blood glucose control system 110 is implemented at one or more of these entities. Additionally, according to the technology, various portions of the blood glucose control system 110 may be implemented at different combinations of the analyte monitoring device 104, the drug delivery system 106, the computing device 108, and the health monitoring platform 112, or using these different combinations.

[0061] As discussed above and below, the glycemic control system 110 obtains sensor data 118 from a variety of sources. For example, the glycemic 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 identifiers (SSIDs) of available networks, networks to which the computing device 108 is connected, and / or networks to which the computing device 108 was previously connected), Bluetooth Low Energy (BLE) information, data generated using a cellular antenna (e.g., Long Term Evolution (LTE)), microphone data (e.g., sound data), accelerometer data, gyroscope data, magnetometer data, barometer data, ambient or internal temperature data (e.g., generated using a temperature sensor), light data (e.g., captured using a device's camera), heart rate data (e.g., generated by a smart phone and / or smart watch), proximity data (e.g., between devices), humidity data, analyte data, and drug data, to name a few. It should be understood that this list is not exhaustive, and 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.

[0062] Based on the sensor data 118, the location prediction engine 122 detects the location of a user, such as a person 102 wearing the analyte monitoring device 104. In one or more specific implementations, the location prediction engine 122 detects the location of the user based on at least two different types of sensor data 118. For example, the location prediction engine 122 detects the location of the user based on 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 sound data. In one or more specific implementations, the location prediction engine 122 uses the first sensor data to detect the location of the user and uses the second sensor data to confirm the location of the user. Alternatively or in addition, the location prediction engine 122 uses two types of sensor data to distinguish which candidate location among multiple candidate locations corresponds to the actual physical location of the user. 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 one of the at least two candidate locations as the location of the user (or eliminates all candidate locations except one candidate location).

[0063] The suggestion engine 124 predicts activities that the user will perform at the location. Examples of activities include eating, exercising, and sleeping. Of course, the system can predict other activities without departing from the spirit or scope of the technology. The system then uses the predicted activities performed by the user to generate one or more suggestions for controlling the user's glycemic response, such as the glycemic response of the person 102 to the predicted activities. For example, the suggestion engine 124 generates one or more treatment suggestions to mitigate potential adverse effects caused by the predicted activities. Examples of adverse effects include at least glucose deviations from a safe glucose range, such as hyperglycemia or hypoglycemia.

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

[0065] In one or more specific implementations, the glycemic control system 110 provides instructions 120 to notify the user of the recommended treatment. For example, the glycemic control system 110 provides instructions 120 to the computing device 108 to cause the computing device 108 to display or otherwise output the recommendation (or information indicating the recommendation). Alternatively or additionally, the glycemic control system 110 provides instructions 120 to control a device (e.g., the drug delivery system 106) to provide the recommended treatment. For example, the glycemic control system 110 provides instructions 120 to the drug delivery system 106, and the instructions cause the drug delivery system 106 to administer a certain amount of the drug to the person 102.

[0066] In one or more embodiments, the instructions cause the drug delivery system 106 to automatically administer a drug (e.g., a dose) to the person 102 without user input. In such embodiments, the device is operably connected in a closed loop. In other embodiments, the instructions instruct the drug delivery system 106 to administer a drug (e.g., a dose) to the person 102, but the system prevents delivery of the drug until confirmation input is received from the user, such as input indicating that the user allows drug delivery. Alternatively or additionally, the instructions instruct the drug delivery system 106 to administer a dose of the drug, and the drug delivery system 106 requires user interaction to transfer the dose to the body of the person 102, for example, requiring the user to position the drug delivery system 106 against the body of the person 102 and turn on the system (e.g., press a button) to administer the drug. The following description of the method and apparatus described herein is provided herein. Figure 4 One example of a blood glucose control system 110 is discussed in more detail.

[0067] As described above, in one or more specific implementations, the blood glucose control system 110 uses sensor data 118 obtained via the IoT 114. It should be understood that the IoT 114 represents various sources that can provide data describing the person 102 and / or the activities of the person 102, such as the activities of the person 102 as a user of one or more service providers, or the activities of the person 102 in the real world, such as at home, in a car, at work, in a gym, in a restaurant, or in other stores, to name a few. For example, the IoT 114 may include various devices of the user, such as mobile phones, wearable devices, cameras, laptops, etc. To this end, the IoT 114 may provide information about the user's interaction with these various devices, such as the location of these devices, the environmental and / or physical conditions at the location where the device is placed, the interaction with the network-based applications supported by the device, the interaction with the health applications supported by the device, the photos taken, the communication with other users, the online behavior, etc. The IoT 114 may also include various other real-world items (e.g., shoes, clothing, sports equipment, appliances, smart home devices, cars, etc.) configured with sensors to provide information describing behavior, such as the number of steps taken, the force of the foot on the ground, the stride, the temperature of the user (and other physiological measurements), the temperature of the user's surroundings, the type of food stored in the refrigerator, the type of food taken out of the refrigerator, driving habits, images of the user at different times of the day, etc. Such other real-world items may also provide sensor data 118 that describes the location of these items, the user's interaction with these items, the environmental and / or physical conditions at the location where the items are placed, and various other conditions.

[0068] In variations, IoT 114 may also include third parties to health monitoring platform 112, such as medical providers (e.g., medical providers of person 102) and manufacturers (e.g., manufacturers of one or more of analyte monitoring devices 104, drug delivery system 106, or computing devices 108) that can provide medical and manufacturing data, respectively, that can be utilized by glycemic control system 110. Of course, IoT 114 may include devices and sensors that can provide a large amount of data for determining location and / or activity of person 102 without departing from the spirit or scope of the described technology.

[0069] In one or more specific implementations, the blood glucose control system 110 also utilizes the resources of the health monitoring platform 112 in conjunction with location-assisted blood glucose control. For example, the health monitoring platform 112 can be configured to store data such as sensor data 118 (e.g., analyte measurements, data generated by other sensors, and data generated based on determinations 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 (not shown) in a user population. The environment 100 includes user data 126, which represents various data about one or more of these users obtained and stored by the health monitoring platform 112. Although data about one or more users is stored, the user data 126 can be obfuscated using one or more techniques so that personal identification information of the user associated with the data can remain anonymous in various scenarios where the data is used. In the illustrated environment 100, the user data 126 is shown as being stored in a storage device 128. The storage device 128 may represent one or more databases or other storage devices that are part of or accessible by the health monitoring platform 112. The storage device 128 can store user data 126 and various other data in accordance with the described techniques.

[0070] By way of example, user data 126 may include any combination of the data discussed immediately above and other data discussed above and below. For example, user data 126 may include historical data associated with one or more users, such as historical sensor data 118, determinations made based on historical sensor data 118, received user input, etc. In at least one specific implementation, such historical data may describe the user's status and / or the user's behavior, including, for example, activities that the user previously performed at a location, activities that other users previously performed at the location, and attributes of the performed activities, such as activity time, location type, physiological measurements during the activity, etc.

[0071] In one or more specific implementations, the health monitoring platform 112 includes a monitoring service 130. The monitoring service 130 can be used alone or in combination with the blood glucose control system 110. For example, the monitoring service 130 can provide one or more network-based health-related services to the user via the network 116 and the user's computing device 108 (e.g., a mobile application). The health monitoring platform 112 may include or access various computing resources, such as processing, storage, and virtual resources. These resources can be used, for example, to train, maintain, and / or deploy algorithms (e.g., machine learning algorithms) that can generate predictions associated with health monitoring by using a large amount of data collected about people 102 and users in a user population. Therefore, the monitoring service 130 can use these resources to execute algorithms and implement other functions in order to deliver network-based services to the user via the user's device. It is worth noting that one or more such algorithms or functions may require a large amount of computing resources that exceed the resources of a typical personal computing device (e.g., a mobile phone, a notebook computer, a tablet device, and a wearable device, to name a few). Nonetheless, the health monitoring platform 112 may include or otherwise have access to a threshold amount of resources required to operate such algorithms and provide such functionality, such as cloud storage, server devices, virtualized resources, etc. The health monitoring platform 112 may include various resources that the computing device 108 may utilize via the monitoring service 130 to provide a user interface or generate data for location-assisted glycemic control. In the context of continuously measuring an analyte, such as glucose, and obtaining analyte data describing such measurements, consider Figure 2 The following discussion.

[0072] Figure 2 Describes in more detail Figure 1 200 of a specific implementation of an analyte monitoring device 104. Specifically, 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 varied in various ways in a specific implementation according to the following discussion without departing from the spirit or scope of the described technology.

[0073] In this example 200, the analyte monitoring device 104 is shown to include an analyte sensor 202 (e.g., a glucose sensor) and a sensor module 204. Here, the analyte sensor 202 is depicted in a side view as having been subcutaneously inserted into the skin 206 (e.g., of the person 102). The sensor module 204 is approximately a dashed rectangle in the top view. In the illustrated example 200, the analyte monitoring device 104 also includes a transmitter 208. The use of the dashed rectangle of the sensor module 204 indicates that it can be contained in the transmitter 208 or otherwise implemented in the housing of the transmitter. Antennas and / or other hardware for enabling the transmitter 208 to generate signals for transmitting data, for example, via a wireless connection to a drug delivery system 106 or / or a computing device 108 may also be contained in the housing of the transmitter 208 or otherwise implemented in the housing of the transmitter. In this example 200, the analyte monitoring device 104 also includes an adhesive pad 210.

[0074] In operation, the analyte sensor 202, the adhesive pad 210 can be assembled to form an application assembly, wherein the application assembly is configured to be applied to the skin 206, so that the analyte sensor 202 is inserted subcutaneously as depicted. In such a scenario, the transmitter 208 can be attached to the assembly via an attachment mechanism (not shown) after the assembly is applied to the skin 206. Alternatively, the transmitter 208 can be incorporated as a part of the application assembly, so that the analyte sensor 202, the adhesive pad 210, and the transmitter 208 (with the sensor module 204) can all be applied to the skin 206 at the same time. In one or more specific implementations, a separate sensor applicator (not shown) is used to apply the application assembly to the skin 206. Different from the finger prick required for conventional blood glucose meters, the user-activated application of the analyte monitoring device 104 with a sensor applicator is almost painless and does not require blood drawing. In addition, the automatic sensor applicator generally enables people 102 to embed the analyte sensor 202 subcutaneously into the skin 206 without the assistance of a clinician or a healthcare provider.

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

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

[0077] 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 a change caused by the analyte sensor 202. For example, the analyte sensor 202 may include a glucose oxidase that reacts with glucose and oxygen to form hydrogen peroxide that can be electrochemically detected by the sensor module 204, which may include an electrode. In this example, the analyte sensor 202 may be configured as or include a glucose sensor configured to detect an analyte indicating a glucose level in blood or interstitial fluid using one or more measurement techniques. In one or more specific implementations, the analyte sensor 202 may also be configured to detect analytes indicating other markers (such as lactate levels, ketones, potassium ions) in blood or interstitial fluid, which may improve the accuracy of 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 architectures of the analyte sensor 202 to detect those analytes that are indicative of other markers.

[0078] In another example, the analyte sensor 202 (or an additional sensor of the analyte monitoring device 104 - not shown) may include a first electrical conductor and a second electrical conductor, and the sensor module 204 may electrically detect a change in the potential of the first electrical conductor and the second electrical conductor across the analyte sensor 202. In this example, the sensor module 204 and the analyte sensor 202 are configured as thermocouples so that the change in potential corresponds to a temperature change. In some examples, the sensor module 204 and the analyte sensor 202 are configured to detect a single analyte, such as glucose. In other examples, the sensor module 204 and the analyte sensor 202 are configured to detect multiple analytes using various sensing modes, such as sodium ions, potassium ions, carbon dioxide, and glucose. Alternatively or additionally, the analyte monitoring device 104 includes multiple sensors to detect not only one or more analytes (e.g., sodium ions, potassium ions, carbon dioxide, glucose, and insulin), but also one or more environmental conditions (e.g., temperature, humidity, movement). Thus, sensor module 204 and analyte sensor 202 (and any additional sensors) can 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, analyte monitoring device 104 can be configured to generate data describing a single analyte (e.g., glucose) or multiple analytes.

[0079] In one or more specific implementations, the sensor module 204 may include a processor and a memory (not shown). By utilizing the processor, the sensor module 204 may generate an analyte measurement result 212 based on the communication with the analyte sensor 202 indicating the change discussed above. Based on the above communication from the analyte sensor 202, the sensor module 204 is further configured to generate a communicable data packet including at least one analyte measurement result 212. In this example 200, the sensor data 118 represents these data packets. Additionally or alternatively, the sensor module 204 may configure the sensor data 118 to include additional data, which includes supplemental sensor information 214 by way of example. The supplemental sensor information 214 may include a sensor identifier, a sensor state, a temperature corresponding to the analyte measurement result 212, a measurement result of other analytes corresponding to the analyte measurement result 212, and the like. It should be understood that the supplemental sensor information 214 may include a variety of data that supplements at least one analyte measurement result 212 without departing from the spirit or scope of the technology.

[0080] In embodiments where the analyte monitoring device 104 is configured for wireless transmission, the transmitter 208 may transmit the sensor data 118 to the computing device in the form of a data stream. Alternatively or additionally, the sensor module 204 may buffer the analyte measurement results 212 and / or the supplemental sensor information 214 (e.g., in a memory of the sensor module 204 and / or other physical computer-readable storage medium of the analyte monitoring device 104) and cause the transmitter 208 to later transmit the buffered sensor data 118 at various regular or irregular intervals (e.g., time intervals (approximately every second, approximately every thirty seconds, approximately every minute, approximately every five minutes, approximately every hour, etc.), storage intervals (when the buffered analyte measurement results 212 and / or supplemental sensor information 214 reaches a threshold amount of data or number of measurements), etc.). It should be understood that in some embodiments, the analyte monitoring device 104 may differ from the above examples in a variety of ways without departing from the spirit or scope of the described technology.

[0081] Having discussed one example of an analyte monitoring device, consider now the following discussion of an example drug delivery system.

[0082] Figure 3 Describes in more detail Figure 1 An example implementation 300 of the drug delivery system 106 is shown.

[0083] In the example implementation 300, the drug delivery system 106 includes a drug pump 302 and an infusion set 304. Although the infusion set 304 is depicted as having a tube 306 connected to the drug pump 302, in one or more implementations, the infusion set 304 can be tubeless. For example, the drug delivery system 106 can be configured as a pen. Broadly speaking, the infusion set 304 is a device that is configured to deliver a drug pumped to the infusion set 304 by the drug pump 302 subcutaneously into the body of the person 102 for absorption by the bloodstream of the person 102. In this way, the body of the person 102 can use the delivered drug to maintain a balanced analyte level, such as maintaining within a target range of the analyte measurement result. In one or more implementations, the infusion set 304 includes a cannula inserted subcutaneously into the skin, such as at the infusion site 308 of the person 102 in the example implementation 300. Therefore, the infusion set 304 can, for example, apply a drug dose through the skin of the person 102 in a continuous manner 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 person 102 via infusion set 304. Alternatively or in addition, drug delivery system 106 may administer a drug to person 102 based on user input, such as input of one or more drug doses to be delivered received via a user interface and / or input received via computing device 108.

[0084] As shown, the infusion set 304 includes an adhesive pad that adheres the device to the person 102 for a period of time. In one or more embodiments, the infusion set 304 is applied to the infusion site 308 using a separate applicator (not shown). In operation, the applicator can insert the cannula of the infusion set 304 into the skin of the person 102 at the infusion site 308 and also adhere the adhesive pad to the infusion site 308 to adhere the infusion set 304 to the person 102 during use. In at least some specific implementations, for example, the infusion sets can be disposable, such that they are designed to be removed after a specified and / or recommended period of time and replaced with a new device applied to the person 102 and attached to the drug pump 302. In any case, the drug pump 302 is configured to deliver a dose of medication to the person 102 via an infusion set (such as the infusion set 304 shown).

[0085] In the example implementation 300, the drug pump 302 includes a communication module 310, a drug delivery control 312, a drug reservoir 314, a display module 316, a security module 318, and a battery 320. In a specific implementation, the drug pump 302 can be configured in various ways, such as being configured with some of these components, while other components are housed or otherwise implemented in a separate device. Alternatively or additionally, the drug pump 302 may include additional or alternative components without departing from the spirit or scope of the technology described herein.

[0086] The communication module 310 is configured to transmit data to other devices and receive data from other devices, such as a computing device 108. In one or more embodiments, the communication module 310 establishes a communication coupling with such other devices to enable the transmission and reception of data. For example, the communication module 310 can establish or otherwise facilitate the establishment of a communication link or channel with those other devices. The link or channel can 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, to name a few. This communication connection enables the drug pump 302 to communicate through different networks (such as network 116) and / or to communicate securely within a closed-loop system, which includes, for example, an analyte monitoring device 104 and at least one computing device 108.

[0087] Once the communicative coupling is established, the communication module 310 may enable data to be transmitted through the established coupling and / or may receive data from the other device through the established coupling. 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 further 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.

[0088] As one example, communication module 310 enables medication pump 302 to receive instructions 120 and / or other instructions from computing device 108 and / or glycemic control system 110 to control the delivery of medication to person 102. For example, communication module 310 enables medication pump 302 to receive instructions instructing medication pump 302 regarding a basal rate of insulin to be delivered to person 102, an updated basal rate of insulin, a bolus dose of insulin to be delivered to person 102 (e.g., a bolus amount over a limited time), etc. Computing device 108 may send various communications to medication delivery system 106 for controlling medication delivery without departing from the spirit or scope of the techniques described herein.

[0089] The drug delivery control 312 represents any hardware, software, and / or mechanical component of the drug pump 302 that causes the drug to be pumped (or otherwise extracted) from the drug reservoir 314 so that it flows through the infusion set 304 and enters the body of the person 102. In addition, the drug delivery control 312 is further configured to cause the drug to be pumped or otherwise extracted from the drug reservoir 314 according to the drug dosage instructions (e.g., instructions 120 from the blood glucose control system 110 specifying one or more deliveries of the drug). The drug reservoir 314 is configured to hold a certain amount of drug that can be delivered subcutaneously via the infusion set 304 by utilizing the functions of the drug pump 302. The drug reservoir 314 can be replaceable or otherwise configured so that the amount of drug can be replenished in the drug reservoir 314. Without departing from the spirit or scope of the described technology, the drug reservoir 314 can be configured in various ways (e.g., different shapes, different materials, removable in different ways, etc.).

[0090] The display module 316 is configured to display information via a display device 322 of the drug pump 302. The display module 316 can generate one or more user interfaces for display via the display device 322. For example, the display module 316 can display a user interface via the display device for establishing a wireless connection with the computing device 108. Additionally or alternatively, the display module 316 can cause the display device 322 to display analyte measurements (e.g., in a similar manner as they are displayed via a health monitoring application of the computing device 108), trend arrows (e.g., regarding trends identified in the analyte measurements), alerts (e.g., regarding analyte measurements, other physiological conditions, operability of the drug delivery system 106, operability of components of the glycemic control system 110, status of the wireless connection with the computing device 108, etc.), a pump settings interface, an indication of out of range communication from a different device (e.g., the computing device 108 or the analyte monitoring device 104), etc. The display module 316 can thus cause various information to be displayed via the display device 322 of the drug pump 302.

[0091] The safety module 318 is configured to provide one or more safeguards to control the delivery of the drug so that the delivery is harmless; in other words, so that the drug is delivered safely. For example, the safety module 318 may include or otherwise enforce delivery restrictions, such as maximum and minimum delivery rates over different time periods. These restrictions effectively prevent erroneous delivery instructions from the blood glucose control system 110 from harming the person 102, such as when an error in the transmission of the instructions affects its content or when an error in the prediction made by one or more machine learning models dangerously affects these instructions. For example, even if the instructions received from the blood glucose control system 110 instruct the drug pump 302 to deliver more than a threshold amount, the safety module 318 may also limit the amount or rate of the drug delivered by the drug pump 302 to a threshold amount or a threshold rate. Similarly, even if the instructions received from the computing device 108 instruct the drug pump 302 to deliver less than a threshold amount, the safety module 318 may also prevent the drug pump 302 from delivering less than a threshold amount of drug or delivering the drug at a rate lower than a threshold rate.

[0092] Among other things, security module 318 is configured to continue operating medication pump 302 in the absence of instructions from glycemic control system 110 or computing device 108, such as instructions describing how much medication to deliver and when to deliver. For example, security module 318 may be configured to continue operating medication pump 302 to deliver medication to person 102 when glycemic control system 110 is out of communication range. Security module 318 may access logic, default settings, or settings entered as part of a setup process, to name a few, that controls how much medication to deliver when no instructions are received from glycemic control system 110. Security module 318 may implement various additional or different safeguards to ensure that the amount of medication delivered is not harmful to person 102.

[0093] The battery 320 is configured to provide power for operating the drug pump 302, such as powering the communication module 310 to send and receive data, powering the drug delivery control 312 to deliver the drug from the drug reservoir 314 to the person 102 via the infusion set 304, powering the display module 316 to display information via the display device 322, etc. The battery 320 can be rechargeable (e.g., via a USB charging port or wirelessly) or replaceable. It should be understood that the battery 320 can be configured in a variety of ways.

[0094] Although not depicted, the drug delivery system 106 or another device (e.g., analyte monitoring device 104) may be configured with a drug sensor (e.g., an insulin sensor). Such a drug sensor may be applied to the skin or subcutaneously inserted to measure, for example, the systemic level of a drug in a person 102. Therefore, the drug sensor may be included as a part of an infusion set 304, an analyte monitoring device 104, or may be applied alone. In any case, such a sensor may be used in conjunction with a dose prediction function of a safety module 318 and / or a blood glucose control system 110. In this way, the drug measurement results generated using the drug sensor may be used to prevent or detect drug overdose, such as preventing a person receiving insulin from experiencing a hypoglycemia attack. For example, for example, if the safety module 318 detects that the drug level exceeds a predetermined threshold, the safety module 318 may shut down the drug delivery by the drug pump 302 based on the drug measurement results. Based on the drug measurement results, the blood glucose control system 110 may also or alternatively send an instruction to the drug delivery system 106, instructing it to stop drug delivery. In one or more specific implementations, the security module 318 and / or the computing device 108 may also trigger an alarm if the drug level exceeds a predetermined threshold. Physiologically, different thresholds may be determined for different people based on their drug sensitivity (e.g., insulin sensitivity), thereby triggering a shutdown, alarm, or stop of drug delivery as discussed above for different drug levels for different people.

[0095] Having considered an example of an environment and an example apparatus, consider now some examples discussing details of techniques for location-assisted glucose control according to one or more implementations.

[0096] Location-Assisted Blood Glucose Control

[0097] Figure 4 An example of a system 400 is depicted that receives and processes sensor data from various sources to generate blood glucose control recommendations based on the user's location according to the steps of one or more algorithms and thereby implements a dedicated machine. The illustrated system 400 includes Figure 1 The blood glucose control system 110 has a location prediction engine 122 and a suggestion engine 124.

[0098] In this example, the blood glucose control system 110 is depicted as obtaining sensor data 118. According to the described techniques, the blood glucose control system 110 receives sensor data 118 from various sources 402, examples of which include global positioning system (GPS) data, Wi-Fi information (e.g., service set identifier (SSID)), Bluetooth low energy (BLE) information, data generated using a cellular antenna (e.g., long term evolution (LTE)), microphone data (e.g., sound data), accelerometer data, gyroscope data, magnetometer data, barometer data, ambient or internal temperature data (e.g., generated using a temperature sensor), light data (e.g., captured using a device's camera), heart rate data (e.g., generated by a smart phone and / or smart watch), proximity data (e.g., between devices), humidity data, analyte data (one or more different analytes or different data about the same analyte from different sources), and medication data, to name a few. Additional examples of sensor data 118 from various sources 402 include, but are not limited to, measurements of various detection signals (e.g., biopotential measurements such as an electrocardiogram (ECG), electromyogram (EMG), or electroencephalogram (EEG)); accelerations experienced by a person at the location where the analyte-enhanced wearable device is worn; and optical signals, such as a photoplethysmogram (PPG) that detects changes in blood volume, measurements of various physiological conditions (e.g., perspiration, temperature, heart rate, oxygen saturation (SpO2), or indications of detected events (e.g., exceeding or falling below a threshold, detecting the presence or absence of a particular compound), to name a few. As described above, the analyte monitoring device 104, the drug delivery system 106, the computing device 108, and the IoT 114 can be sources 402 of such data. Alternatively or in addition, the blood glucose control system 110 receives sensor data 118 from other sources 402, which can include or be associated with one or more different types of sensors.

[0099] In the example shown, the sensor data 118 includes first sensor data 404 and second sensor data 406. In one or more specific implementations, the location prediction engine 122 predicts the user's location 408 based on at least two types of sensor data (e.g., the first sensor data 404 and the second sensor data 406). For example, the location prediction engine 122 predicts the user's location 408 based on GPS data and Wi-Fi information (e.g., the SSID of the network accessible to the computing device 108), based on Wi-Fi information and sound data, based on Wi-Fi information and light data, based on Wi-Fi information and heart rate data (to name a few). It should be understood that the location prediction engine 122 can be configured to receive various combinations of at least two types of data described above and below as input and process them to predict the user's location 408. Of course, in one or more specific implementations, the location prediction engine 122 can use more than two types of data (e.g., more than the first sensor data 404 and the second sensor data 406) to predict the user's location 408.

[0100] 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 a 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 smart watch. In this implementation, this is based on the assumption that the user is near the associated computing device, such as the computing device is worn by the user or carried in 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 smart watch), and then attributes the location of the device to the user. Alternatively or in addition, 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 smart watch), 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 be the case when computing device 108 is not being worn by the user or is not "on" the user, such as when the user is sleeping or showering. In one or more implementations, location prediction engine 122 generates a "coarse" prediction of the user's location 408 using first sensor data 404, and location prediction engine 122 generates a "fine" prediction of location 408 using second sensor data 406 (and based on the coarse location prediction).

[0101] 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 with a dashed line, indicating that its logic is optionally used in one or more specific implementations. According to the described technology, the location predictor 410 corresponds to the logic used by the location prediction engine 122 to predict the user's location 408 based on the sensor data 118 according to one or more algorithms, and thus implements a special-purpose machine. Without departing from the spirit or scope of the described technology, the location predictor 410 can be configured in a variety of ways. For example, the location predictor 410 can be configured as or include one or more machine learning models. Alternatively or in addition, the location predictor 410 includes or has access to a mapping of locations (e.g., restaurants, gyms, houses, stores, roads, and other businesses) to geographic coordinates, so that given precise geographic coordinates, the location predictor 410 can attribute the user's presence to the location according to the mapping.

[0102] In at least one implementation, the first sensor data 404 may not be suitable for enabling the location predictor 410 to predict the user's geographic coordinates accurately enough to distinguish between at least two adjacent locations. Instead, the first sensor data 404 may be suitable for predicting an area (e.g., a radius around a point) where the user may be located, such that the area includes at least two candidate locations. Therefore, 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 between candidate locations and select a location 408 from a plurality of candidate locations. For example, in a scenario where a restaurant and a gym are adjacent to each other, the location predictor 410 uses the second sensor data 406 to narrow down the candidate locations to select the restaurant or the gym. This is noteworthy because activities that a user engages in at different locations may have completely different effects on the user's analyte levels, for example, eating pizza may have a completely different effect on a person's glucose than exercising.

[0103] The location confirmation engine 412 is configured to confirm the location predicted by the location predictor 410. In one or more specific implementations, the location predictor 410 predicts the location 408 based on the first sensor data 404, and the location confirmation engine 412 attempts to confirm the prediction of the location 408 based on the second sensor data 406. For example, based on the second sensor data 406, the location confirmation engine 412 either confirms the prediction of the location 408 or rejects the prediction. In the scenario of rejecting the prediction, the location prediction engine 122 may prompt the user to select a location, such as selecting or confirming the predicted location from a plurality of candidate locations. In one or more other scenarios, user participation may also be requested, such as when a particular location is predicted for the user for the first time. Alternatively or in addition, the location predictor 410 predicts the location 408 based on the first sensor data 404 and the second sensor data 406, and the location confirmation engine 412 attempts to confirm the prediction of the location 408 based on the first sensor data 404 and the second sensor data 406. Alternatively or additionally, the location predictor 410 predicts a location 408 based on the first sensor data 404 and the second sensor data 406, and the location confirmation engine 412 attempts to confirm the prediction of the location 408 based on the third sensor data (not shown). Alternatively or additionally, the location predictor 410 and the location confirmation engine 412 may predict a location and attempt to confirm the predicted location based on different combinations of data, respectively, without departing from the spirit or scope of the described techniques. Furthermore, it should be understood that the location prediction engine 122 may include or otherwise access various types of logic to predict the location 408 of a user (e.g., person 102) based on the sensor data 118 according to the described techniques. In this example, the location prediction engine 122 outputs the location 408.

[0104] Given a location 408, the system 400 predicts an activity 414 of the user so that blood glucose control recommendations can be generated based on the predicted activity 414. Here, the recommendation engine 124 is depicted as obtaining the location 408. In the illustrated example, the recommendation engine 124 includes an activity predictor 416 and an activity-to-recommendation module 418. It should be understood that the recommendation engine 124 may include more, different, or fewer modules without departing from the spirit or scope of the described technology.

[0105] Activity predictor 416 is depicted as outputting activity 414. According to the described technology, activity predictor 416 determines and outputs activity 414 that a user is participating in or may be participating in based on location 408 according to one or more algorithms, and thus implements a special purpose 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 (e.g., sensor data 118) and / or based on data describing the user's interaction with the device. Examples of such sensor data 118 include sound data (e.g., indicating a sound confirming that the user is sleeping), light data (e.g., indicating a dim location associated with a higher probability that the user is sleeping), accelerometer data (e.g., indicating the positioning of the device on the nightstand associated with a higher probability that the user is sleeping), etc. Examples of such user interactions include user interactions that confirm predicted activity 414, input activities, etc. As described above and below, different activities that people participate in may have very different effects on glucose. In other words, people's blood sugar responses to different activities they participate in are different. Therefore, the suggestion engine 124 recommends different relief treatments based on the activity 414.

[0106] Examples of activities include, but are not limited to, eating, sleeping, exercising (e.g., aerobic, anaerobic, partial aerobic and partial anaerobic, high-intensity interval training, running, rowing, hiking, cycling, weight lifting, yoga, Pilates, sports, etc.), working (e.g., potentially stress-inducing), showering, going to a movie, watching television, attending an event (e.g., a sporting event or a concert), dancing, reading, cleaning, taking care of children, or driving, to name a few.

[0107] In the illustrated example, activity predictor 416 is also depicted as outputting activity state 420. In one or more specific implementations, activity state 420 is shown with a dashed line to indicate that it is optionally predicted by activity predictor 416. Activity state 420 is useful because the treatments recommended at different times relative to an activity (e.g., before, during, and after) may be different. For example, a treatment recommended before a meal may be different from a treatment recommended during or after a meal. Similarly, a treatment recommended before a workout may be different from a treatment recommended during or after a workout. Therefore, in one or more specific implementations, activity predictor 416 predicts a state before an activity, a state during an activity, or a state after an activity, and predicts activity 414.

[0108] For example, the user's location 408 may be predicted to be in a car (e.g., driving), and based on the additional user data, the activity predictor 416 may predict that the user is on the way to the gym. Examples of such additional data may include, but are not limited to, data describing the user's historical behavior, calendar data, streaming (e.g., music) data, data from a map application (e.g., outputting or determining a route to the gym, detecting that the user is traveling on a route that is accessible to the gym, etc.), data from an application associated with a location (e.g., a reservation or scheduled appointment on the application), etc. Thus, in this example, the activity predictor 416 may predict that the activity 414 is a workout, and the activity state 420 is "pre-activity" or pre-workout. The activity predictor 416 may update the activity state 420 or the activity 414 as the additional data is received. For example, in the continued example, activity predictor 416 may update activity state 420 to a “during activity state” or workout when additional data is received and processed, such as data describing that the user has parked at the gym, the user has checked into the gym, the user has selected to start a workout on a smartwatch, the user's computing device has connected to another device (e.g., a Wi-Fi connection to the gym's wireless network, a Bluetooth connection to a chest strap heart monitor), or the user has selected to start playback of a workout playlist, to name a few.

[0109] Based on the activity 414, and in at least one implementation, based on the activity state 420, the activity-to-suggestion module 418 generates a suggestion 422. In one or more implementations, the activity-to-suggestion module 418 predicts a user's glycemic response 424 to the predicted activity 414, determines that the user's glycemic response 424 to the predicted activity will result in an adverse health event, and determines a mitigation therapy 426 to prevent or mitigate the adverse health event corresponding to the glycemic response 424. For example, the adverse health event may include a hypoglycemic event, a hyperglycemic event, and any other potentially harmful event associated with the user's glucose level. The activity-to-suggestion module 418 then generates a suggestion 422 to provide the user (e.g., person 102) with a mitigation therapy 426 and / or a notification of the mitigation therapy 426. The activity-to-suggestion module 418 can be configured in a variety of ways without departing from the spirit or scope of the described technology.

[0110] Therefore, it should be understood that in some configurations, the blood glucose control system 110 continuously detects the user's location 408 and predicts an activity 414 associated with the location. However, not all activities cause a blood glucose response 424 that may lead to an adverse health event. Therefore, in one or more specific implementations, a suggestion 422 to control a blood glucose response 424 is generated only when the blood glucose control system 110 determines that an activity will cause a blood glucose response 424 and the blood glucose response will lead to an adverse health event. For example, the blood glucose control system 110 may determine that the user is in her office and predict that the user will perform an activity associated with the user's office, such as writing an email. However, in this case, the blood glucose control system 110 may determine that the activity will not cause a blood glucose response 424 that leads to an adverse health event. Therefore, in this case, even if the activity is predicted, the blood glucose control system will not generate a suggestion 422.

[0111] In one or more implementations, for example, the activity-to-suggestion module 418 is configured as a machine learning model that receives the activity 414 (and the activity state 420 in some implementations) as input and outputs a recommendation 422. In such implementations, the activity-to-suggestion module 418 may be trained using training data that pairs the activity (and the activity state in some implementations) with clinically recommended treatments. For example, the machine learning model may be exposed to the activity (e.g., receiving it as input) and attempt to output a mitigation treatment recommendation. The system may then compare the output with the recommended treatment paired with the input in the training data. Based on the comparison, the internal weights of the machine learning model may be adjusted. For example, if the output matches the paired treatment in the training data, the weight may be adjusted (e.g., strengthened) to encourage the output during future iterations. However, if the output does not match the paired treatment in the training data, or is identified as being harmful to the user's health given the activity, the weight may be adjusted to discourage the output during future iterations. Thus, the machine learning model may be trained over multiple iterations.

[0112] Alternatively or in addition, the activity-to-suggestion module 418 may obtain blood glucose responses 424 and relief treatments 426, such as from activities (and states in some specific implementations) to mappings of blood glucose responses 424 and relief treatments 426 to these activities. For example, the library may include mappings that map different activities to corresponding blood glucose responses 424 and one or more corresponding relief treatments. For example, this information may be stored in a database. In one or more specific implementations, the mapping may be approved by one or more clinicians. For example, one or more clinicians may approve or otherwise provide a suggested relief treatment 426 for an activity 414 because the activity may cause a specific blood glucose response 424, and the suggested relief treatment 426 is clinically recommended to relieve the blood glucose response.

[0113] This information may be input into the system (e.g., into a database) and maintained. In one or more specific implementations, such mapping may be maintained in a computer-readable storage medium of a user's computing device 108 (e.g., a user's mobile phone). Alternatively or in addition, the mapping may be maintained away 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. When new treatments and activities are added and / or the treatments mapped to various activities are updated, for example, when a clinician recommends a different treatment for an activity than previously recommended clinically, either or both of the remote and local mappings may be updated. In one or more specific implementations, the mapping may be personalized for the user, such as mapping an activity to a treatment that was previously effective for the user to control the user's blood glucose response to the activity. In such specific implementations, the mapping may be provided by the user (e.g., via the user's input to the user's computing device), a health care provider (e.g., via a health care provider portal), or determined by the system based on sensor data 118 (e.g., analyte data describing that the user's analyte level remains within the range and / or that no harmful deviation occurs).

[0114] Thus, the recommendations 422 are configured to provide or notify the user of a mitigation treatment 426 to mitigate the glycemic response 424 to the activity 414 predicted based on the user's location 408. The recommendations 422 may include one or more of a variety of treatments to control the user's glycemic response 424 to the predicted activity 414. By way of example and not limitation, the recommendations 422 may include dosages and / or timings of one or more medications, activities to perform (e.g., exercise, contact a health care professional, interrupt activity, rest) and / or timings of these activities, amounts and / or timings of one or more foods to ingest (e.g., drink a few ounces of juice or take a pill), etc. The recommendations may suggest a variety of treatments without departing from the spirit or scope of the described technology.

[0115] Based on the recommendation 422, the controller 428 outputs instructions 120. For example, the controller 428 provides the instructions 120 to the drug delivery system 106, the computing device 108, and / or another device (e.g., an additional drug delivery system). In one or more specific implementations, the controller 428 provides the instructions 120 to notify the user of the recommended relief therapy 426. For example, the controller 428 provides the instructions 120 to the computing device 108 to cause the computing device 108 to display or otherwise output the recommendation 422 (or information indicating the recommendation 422). Examples of notifications that may be output by the computing device 108 will be referred to in detail below. Figures 6 to 9 Discuss in more detail.

[0116] Alternatively or additionally, the controller 428 provides instructions 120 to control a device (e.g., the drug delivery system 106) to provide the suggested relief therapy 426. For example, the controller 428 provides instructions 120 to the drug delivery system 106, and the instructions cause the drug delivery system 106 to administer a certain amount of drug to the person 102.

[0117] In one or more specific implementations, the instruction 120 causes the drug delivery system 106 to automatically administer a drug (e.g., a dose) to the person 102 without user input. In this specific implementation, the device is operably connected in a closed loop. In other specific implementations, the instruction 120 instructs the drug delivery system 106 to administer a drug (e.g., a dose) to the person 102, but before receiving a confirmation input from the user, such as an input indicating that the user allows drug delivery, the system will prevent the delivery of the drug. Alternatively or additionally, the instruction 120 instructs the drug delivery system 106 to administer a dose of the drug, and the drug delivery system 106 requires user interaction to transfer the dose to the body of the person 102, for example, requiring the user to position the drug delivery system 106 against the body of the person 102 and turn on the system (e.g., press a button) to administer the drug.

[0118] Figure 5 An example 500 of a mapping for location-assisted blood glucose control is depicted. In particular, the illustrated example 500 includes a health event map 502 and a suggestion map 504. In one or more implementations, the health event map 502 and the suggestion map 504 are stored in a storage device accessible to the blood glucose control system 110 (or its components), such as a computer-readable storage medium stored in the computing device 108, the blood glucose control system 110, and / or the health monitoring platform 112. For example, in one or more implementations, the health event map 502 and / or the suggestion map 504 may be configured as a file and / or a database. In the illustrated example, the health event map 502 maps locations to activities and blood glucose responses, and the suggestion map 504 maps activities to suggestions. It should be understood that the mappings used in conjunction with the described techniques may map information different from that depicted without departing from their spirit or scope.

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

[0120] Here, suggestion map 504 includes fields for activity 512, activity state 514, glycemic response 516, and suggestion 518. Thus, suggestion map 504 includes entries, where each entry specifies an activity 512 and an activity state 514. For activity state 514 of activity 512, the map includes possible glycemic response 516 and suggestion 518 for controlling the glycemic response (e.g., mitigating any deleterious effects of the glycemic response). In one or more implementations, activity-to-suggestion module 418 can utilize suggestion map 504 to generate suggestion 422 based on activity 414 and activity state 420. In the context of outputting a notification of information corresponding to suggestion 422, consider the following example.

[0121] Figure 6 An example of a user interface for displaying activity notifications is depicted. The illustrated example 600 includes Figure 1 FIG. 6 is an example of a computing device 108 of FIG. 1 that displays an example user interface 602 via a display device (eg, a touch screen). Here, the user interface 602 includes an activity notification 604 indicating that the activity predictor 416 detected the activity 414.

[0122] In this example, the activity corresponds to a predicted workout based on sensor data 118, which indicates that the user is heading to a gym to work out, such as the user driving or walking to the gym. Activity notification 604 also includes a suggestion 422 that instructs the user to consume 50 grams of carbohydrates to mitigate the likelihood that the user will experience a hypoglycemic event caused by the exercise. For example, exercise may lower the user's glucose level, so consuming 50 grams of carbohydrates before exercising may increase the user's glucose level so that the user's glucose level does not fall below a hypoglycemic threshold after the exercise.

[0123] Figure 7 An additional example of a user interface for displaying activity notifications is depicted. Similar to illustrated example 600, illustrated example 700 includes Figure 1108, which displays an example user interface 702 via a display device (e.g., a touch screen). Here, the user interface 702 includes an activity notification 704 indicating that the activity predictor 416 detected the activity 414. The notification 704 corresponds to the activity 414 detected in the activity predictor 416. Figure 6 A second notification is displayed after notification 604 of , which again includes a suggestion 422 that the user consume 50 grams of carbohydrates to mitigate the likelihood that the user will experience a hypoglycemic event caused by exercise.

[0124] Notification 704 may be displayed based on additional sensor data 118 indicating that the user has now arrived at the gym location or is closer to the gym location than when notification 604 was displayed. Notification 704 more aggressively advises the user to consume 50 grams of carbohydrates to prevent a hypoglycemic event than notification 604. For example, notification 704 includes the title "Urgent" and further advises the user to "consume 50 grams of carbohydrates as soon as possible to prevent post-exercise hypoglycemia." Notably, the blood glucose control system increases the aggressiveness of suggestion 422 because the user is now closer to the time to start the activity.

[0125] Figure 8 An additional example of a user interface for displaying activity notifications is depicted. Similar to the illustrated examples 600 and 700, the illustrated example 800 includes a user interface from Figure 1 An example of a computing device 108 of FIG. 100 is shown, which displays an example user interface 802 via a display device (e.g., a touch screen). Here, the user interface 802 includes an activity notification 804 indicating that the activity 414 has been completed. In this case, the activity predictor 416 has detected that the user has completed the exercise activity and is now 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 in a gym location. 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 exercise. In this case, the notification 804 instructs the blood glucose control system 110 to reduce the amount of insulin administered to the user over the next two hours. This is done because exercise may cause the user's glucose level to decrease, and therefore reduce insulin to prevent the user from experiencing a hypoglycemic event caused by the combination of insulin and exercise.

[0126] Fig. 9 An additional example 900 of a user interface displaying an activity notification is depicted. Similar to the illustrated examples 600, 700, and 800, the illustrated example 900 includes a user interface from Figure 1108, which displays an example user interface 902 via a display device (e.g., a touch screen). Here, the user interface 902 includes an activity notification 904 indicating that the activity 414 was detected.

[0127] In this example, the activity corresponds to the user eating at a restaurant, and is determined by the activity predictor 416 based on the sensor data 118 indicating that the user is at a restaurant location. In this case, the notification 904 indicates that the blood glucose control system 110 is increasing the bolus dose of insulin administered to the user. This is done because eating at a restaurant may cause the user's glucose level to increase, and therefore the insulin is increased to prevent the user from experiencing a hyperglycemic event caused by the combination of insulin and eating at a restaurant.

[0128] It is noteworthy that notifications 604, 704, 804, and 904 are depicted as being displayed on the home screen of a user's smartphone. However, it should be understood that notifications may 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.

[0129] Fig.10 An example 1000 of a first combination of devices for implementing location-based glycemic control is depicted. The illustrated example 1000 includes an analyte monitoring device 104, a drug delivery system 106, and a computing device 108 having a glycemic control system 110.

[0130] According to the technology, analyte monitoring device 104, drug delivery system 106 and computing device 108 can be communicatively connected, for example, via network 116 or via some other wireless connection (e.g., BLE), to realize any of the location-based blood glucose control technologies described above and below. In a variation, analyte monitoring device 104, drug delivery system 106 and computing device 108 are operably connected to realize location-assisted blood glucose control as a closed-loop system, an open-loop system or a partially open-loop system. In this example, drug delivery system 106 is depicted as a wearable pump (e.g., an insulin pump) with an infusion set, which is applied to people 102 and delivers drugs via the infusion set at the insertion site.

[0131] As a closed-loop system, analyte monitoring device 104, drug delivery system 106, and computing device 108 are configured to monitor an analyte of person 102 wearing analyte monitoring device 104, recommend a therapy based on the activity predicted to be engaged in by person 102 at the predicted location, and administer the recommended therapy (e.g., via drug delivery system 106) without user interaction.

[0132] In contrast, in a partially open system, the user may be required to confirm the treatment before the system administers the treatment, for example, the user may be required to provide approval of the recommended drug dose 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 confirmed, the drug delivery system 106 can administer the drug dose recommended by the glycemic control system 110. In an open system, the glycemic control system 110 can simply output (e.g., display) the recommended treatment via the computing device 108 (e.g., the display of the computing device 108). In order to administer the recommended dose of the drug in the open system, the user can provide input to the drug delivery system 106 specifying the recommended drug dose, and select a control (e.g., a displayed control) to cause the drug delivery system 106 to administer the dose. As a contrast to the system in example 1000 that can 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.

[0133] Fig.11 An example 1100 of a second combination of devices for implementing location-based glycemic control is depicted. The illustrated example 1100 includes an analyte monitoring device 104, a drug delivery system 106, and a computing device 108 having a glycemic control system 110. However, in contrast to the 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.

[0134] Because the drug delivery system 106 is configured as a pen, the system in the illustrated example 1100 necessarily involves user interaction. Such interactions may include, for example, interactions to position the pen in a position where the drug stored in the pen can be administered to a person and interactions to initiate drug administration (e.g., pressing a button). Therefore, when the analyte monitoring device 104, the drug delivery system 106, and the computing device 108 are configured as in the example 1100, these devices may be operably connected to implement position-assisted glycemic control as an open-loop system or a partial open-loop system.

[0135] Fig.12 An example 1200 of a third combination of devices for implementing location-based blood glucose control is depicted. The illustrated example 1200 includes an analyte monitoring device 104 and a computing device 108 having a blood glucose control system 110.

[0136] However, the illustrated example 1200 does not include the drug delivery system 106. This represents a configuration in which 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 glycemic control system 110 does not transmit instructions 120 to the drug delivery system 106. Instead, the glycemic control system 110 transmits instructions 120 regarding a suggested treatment to the computing device 108, such as outputting (e.g., displaying) a drug dosage and / or other suggested actions. In this specific implementation, a user may interact with the drug delivery system 106 to specify and / or administer a drug dosage, such as when the drug delivery system 106 is a syringe that the user fills with a drug (from a separate container) and injects the drug into his or her body. In at least one variation of the example 1200 configuration, the sensor data 118 may include analyte data. The glycemic control system 110 may use such analyte data as well as using a predicted location and activity at that location to generate a relief treatment recommendation. In contrast to this example, consider Fig.13 and Fig.14 The following examples do not include analyte monitoring device 104.

[0137] Fig.13 An example 1300 of a fourth combination of devices for implementing location-based blood glucose control is depicted. The illustrated example 1200 includes a medication delivery system 106 and a computing device 108 having a blood glucose control system 110 .

[0138] However, the illustrated example 1300 does not include the analyte monitoring device 104. This represents a scenario in which the drug delivery system 106 and the computing device 108 are not operably connected to the analyte monitoring device 104. In such a configuration, the blood glucose control system 110 is able to generate treatment recommendations without using analyte data. Instead, the blood glucose control system 110 predicts the location of a user who is associated with the computing device 108 and wears the drug delivery system 106 (e.g., a pump), and the blood glucose control system 110 uses other data to predict the user's activities at that location. Examples of such other data are discussed above, but may also 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 the other data, the blood glucose control system 110 may further generate recommendations for relief treatment 426.

[0139] Similar to Fig.10In the illustrated example, the drug delivery system 106 and the computing device 108 may be operably connected to implement location-assisted glycemic 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 are configured to enable a therapy to be suggested based on a predicted activity that the person 102 wearing the drug delivery system 106 will engage in at a predicted location, and the suggested therapy to be administered (e.g., via the drug delivery system 106) without user interaction.

[0140] In contrast, in a partially open system, the user may be required to confirm the treatment before the system administers the treatment, e.g., the user may be required to provide confirmation of a suggested drug dose via a display of the drug delivery system 106 or computing device 108 before it is automatically administered by the drug delivery system 106. Once confirmed, the drug delivery system 106 may administer the drug dose suggested by the glycemic control system 110.

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

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

[0143] However, similar to the illustrated example 1300, the example 1400 does not include the analyte monitoring device 104. This represents a scenario where the drug delivery system 106 (e.g., pen) and the computing device 108 are not operably connected to the analyte monitoring device 104. In such a configuration, the glycemic control system 110 is able to generate treatment recommendations without using analyte data. Instead, the glycemic control system 110 predicts the location of a user associated with the computing device 108 and the drug delivery system 106 (e.g., pen), and uses other data to predict the user's activities at that location. Examples of such other data are discussed above.

[0144] Based on the location and activity predictions generated by the blood glucose control system 110 using the other data, the blood glucose control system 110 may further generate a suggestion for a relief treatment 426. Although instructions 120 for administering such treatments may be transmitted to the drug delivery system 106 configured as a pen (e.g., a dose to be delivered), at some point, user interaction is required in order 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 a control to administer the drug. Alternatively, such user interaction may involve confirming the recommended dose, then positioning the pen on the body of the person to whom the drug is to be delivered and selecting a control to administer the drug.

[0145] Having discussed exemplary details of the technology for location-assisted glucose control, consider now some examples of procedures that illustrate additional aspects of the technology.

[0146] Sample Program

[0147] This section describes an example of a program for location-assisted blood glucose control. Aspects of the program may be implemented in hardware, firmware, or software, or a combination thereof. The program is shown as a set of blocks that specify operations performed by one or more devices and is not necessarily limited to the order shown for performing the operations by the various blocks. In at least some implementations, the program is executed by a blood glucose control system (such as blood glucose control system 110).

[0148] Fig.15 is a flow chart depicting an algorithm as a step-by-step procedure 1500 that may be executed by a blood glucose control system to provide location-assistance recommendations for controlling blood glucose response.

[0149] Sensor data is obtained from one or more sensors (block 1502). For example, the blood glucose control system 110 obtains sensor data 118 from one or more sensors. According to the described techniques, the blood glucose control system 110 can receive sensor data 118 from various sources 402, examples of which include global positioning system (GPS) data, Wi-Fi information (e.g., service set identifier (SSID)), Bluetooth low energy (BLE) information, data generated using a cellular antenna (e.g., long term evolution (LTE)), microphone data (e.g., sound data), accelerometer data, gyroscope data, magnetometer data, barometer data, ambient or internal temperature data (e.g., generated using a temperature sensor), light data (e.g., captured using a device's camera), heart rate data (e.g., generated by a smart phone and / or smart watch), proximity data (e.g., between devices), humidity data, analyte data (one or more different analytes or different data about the same analyte from different sources), and medication data, to name a few.

[0150] The location of the user is detected based on the sensor data (block 1504). For example, based on the sensor data 118, the location prediction engine 122 detects the location 408 of a user, such as a person 102 wearing the analyte monitoring device 104. In one or more specific implementations, the location prediction engine 122 detects the location 408 of the user based on at least two different types of sensor data 118. For example, the location prediction engine 122 detects the location 408 of the user based on 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 sound data. In one or more specific implementations, the location prediction engine 122 uses the first sensor data to detect the location of the user and uses the second sensor data to confirm the location of the user. Alternatively or in addition, the location prediction engine 122 uses two types of sensor data to distinguish which candidate location of a plurality of candidate locations corresponds to the actual physical location of the user. 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 one of the at least two candidate locations as the location of the user (or eliminates all candidate locations except one candidate location).

[0151] Based on the user's location, an activity that the user will perform at the location is predicted (block 1506). For example, the suggestion engine 124 predicts the activity 414 that the user will perform at the location 408. Examples of activities include eating, exercising, and sleeping. Of course, the system can predict other activities without departing from the spirit or scope of the described technology.

[0152] Generate suggestions for controlling the glycemic response of the user to the predicted activity (block 1508). For example, the suggestion engine 124 of the glycemic control system 110 generates suggestions 422 for controlling the glycemic response 424 of the user to the predicted activity 414. In other words, the glycemic control system 110 uses the predicted activity 414 performed by the user to generate one or more suggestions 422 for controlling the glycemic response 424 of the user, such as the glycemic response of the person 102 to the predicted activity. For example, the suggestion engine 124 generates suggestions 422 for one or more treatments to mitigate potential adverse effects resulting from the predicted activity 414. Examples of adverse effects include at least glucose deviations from a safe glucose range, such as hyperglycemia or hypoglycemia.

[0153] Having described examples of processes according to one or more implementations, consider now examples of systems and apparatus that can be used to implement the various techniques described herein.

[0154] Example Systems and Devices

[0155] Fig.16An example of a system, generally indicated at 1600, is shown that includes an example of a computing device 1602, which represents one or more computing systems and / or devices that can implement the various techniques described herein. This is illustrated by including a blood glucose control system 110. For example, the computing device 1602 can be a server of a service provider, a device associated with a client (e.g., a client device), a system on a chip, and / or any other suitable computing device or computing system.

[0156] The example computing device 1602 shown 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 also 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 of a variety of bus structures or a combination thereof, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and / or a processor or local bus that utilizes any of a variety of bus architectures. A variety of other examples, such as control lines and data lines, may also be envisioned.

[0157] Processing system 1604 represents the functionality of performing one or more operations using hardware. Therefore, processing system 1604 is shown as including hardware elements 1610 that can be configured as processors, functional blocks, etc. This can include other logic devices implemented in hardware as application specific integrated circuits or formed using one or more semiconductors. 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 composed of semiconductors and / or transistors (e.g., electronic integrated circuits (ICs)). In this context, processor executable instructions may be electronic executable instructions.

[0158] Computer readable media 1606 is shown to include memory / storage 1612. Memory / storage 1612 represents memory / storage capacity associated with one or more computer readable media. Memory / storage 1612 may include volatile media (such as random access memory (RAM)) and / or non-volatile media (such as read-only memory (ROM), flash memory, optical disks, magnetic disks, etc.). Memory / storage 1612 may include fixed media (e.g., RAM, ROM, fixed hard drive, etc.) and removable media (e.g., flash memory, removable hard drive, optical disk, etc.). Computer readable media 1606 may be configured in a variety of other ways as further described below.

[0159] Input / output interface 1608 represents functionality that allows a user to input commands and information to computing device 1602 and also allows information to be presented to the user and / or other components or devices using various input / output devices. Examples of input devices include a keyboard, a cursor control device (e.g., a mouse), a microphone, a scanner, touch functionality (e.g., a capacitive sensor or other sensor configured to detect physical touch), a camera (e.g., which may employ visible wavelengths or invisible wavelengths (such as infrared frequencies) to recognize movement as gestures that do not involve touch), etc. Examples of output devices include a display device (e.g., a monitor or projector), a speaker, a printer, a network card, a tactile response device, etc. Thus, computing device 1602 may be configured in a variety of ways as further described below to support user interaction.

[0160] Various techniques may be described herein in the general context of software, hardware elements, or program modules. Generally, such modules include routines, programs, objects, elements, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The terms "module," "function," and "component" as used herein generally refer to software, firmware, hardware, or a combination thereof. A feature of the techniques described herein is that they are platform-independent, meaning that the techniques can be implemented on a variety of commercial computing platforms with a variety of processors.

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

[0162] "Computer-readable storage media" may refer to media and / or devices capable of storing information persistently and / or non-transitorily, rather than merely signal transmissions, carrier waves, or signals themselves. Thus, computer-readable storage media refers to non-signal bearing media. Computer-readable storage media include hardware such as volatile and non-volatile, removable and non-removable media and / or storage devices implemented in a method or technology suitable for storing information such as computer-readable instructions, data structures, program modules, logic elements / circuits, or other data. Examples of computer-readable storage media may include, but are not limited to, RAM, ROM, EEPROM, flash memory or other storage technology, CD-ROM, digital versatile disks (DVD) or other optical storage devices, hard disks, cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or other storage devices, tangible media, or articles of manufacture suitable for storing the desired information and accessible by a computer.

[0163] "Computer-readable signal media" may refer to signal-bearing media that is configured to transmit instructions to the hardware of the computing device 1602, such as via a network. Signal media typically may embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave, data signal, or other transport mechanism. Signal media also include any information delivery media. The term "modulated data signal" refers to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic media, RF media, infrared media, and other wireless media.

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

[0165] Combinations of the foregoing may also be employed to implement the various techniques described herein. Thus, software, hardware, or executable modules may be implemented as one or more instructions and / or logic embodied on some form of computer-readable storage media and / or 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, a specific implementation of a module executable as software by computing device 1602 may be implemented, for example, at least in part, in hardware using computer-readable storage media and / or hardware elements 1610 of processing system 1604. Instructions and / or functions may be executed / operated by one or more articles (e.g., one or more computing devices 1602 and / or processing systems 1604) to implement the techniques, modules, and examples described herein.

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

[0167] 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 may be utilized when executing computer processing on a server remote from the computing device 1602. The resources 1618 may also include services provided via the Internet and / or through a user network (such as a cellular or Wi-Fi network).

[0168] The platform 1616 can abstract resources and functions to connect the computing device 1602 with other computing devices. The platform 1616 can also be used to abstract the scaling of resources to provide corresponding scaling levels to meet the demand for resources 1618 implemented via the platform 1616. Therefore, in an interconnected device embodiment, the specific implementation of the functions described herein can be distributed throughout the system 1600. For example, the functions can be implemented in part on the computing device 1602 and implemented via the platform 1616 that abstracts the functions of the cloud 1614.

[0169] Clause 1. A method comprising: obtaining sensor data from one or more sensors; detecting a location of a user based on the sensor data; predicting an activity that the user will perform at the location based on the location of the user; and generating recommendations for controlling the user's blood sugar response to the predicted activity.

[0170] Clause 2. A method according to clause 1, wherein generating the recommendation further comprises: predicting the user's blood sugar response to the predicted activity; determining whether the user's blood sugar response to the predicted activity will result in an adverse health event; and in response to determining that the user's blood sugar response to the predicted activity will result in the adverse health event, determining a relief treatment to prevent the adverse health event, wherein the recommendation includes the relief treatment.

[0171] Clause 3. The method of clause 1 or 2, wherein detecting the location of the user is based on at least two different types of sensor data.

[0172] Clause 4. The method of any one of clauses 1 to 3, wherein detecting the location of the user comprises detecting the location of the user based on first sensor data, and confirming the location of the user based on second sensor data.

[0173] Clause 5. A method according to any one of clauses 1 to 4, wherein detecting the location of the user comprises: detecting at least two candidate locations of the user based on first sensor data; and selecting one of the at least two candidate locations as the location of the user based on second sensor data.

[0174] Clause 6. A method according to any one of clauses 1 to 5, wherein predicting the activity includes predicting a state of the activity based on the location, the state including a pre-activity state, an activity state, or a post-activity state, and wherein the recommendation is based on the state of the activity.

[0175] Clause 7. The method of any one of Clauses 1 to 6, further comprising displaying, on a computing device, the suggestions for controlling the glycemic response of the user.

[0176] 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 one memory and a processor for performing operations comprising: 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 the drug to be administered to the user to control the user's glycemic response to the predicted activity; and transmitting instructions to the drug delivery system, causing the drug delivery system to deliver the amount of the drug to the user.

[0177] Clause 9. The system of clause 8, further comprising an analyte monitoring device for obtaining analyte data of the user, wherein the analyte monitoring device and the drug delivery system are connected in a closed loop.

[0178] Clause 10. The system of clause 8 or 9, wherein the instructions cause the drug delivery system to deliver the amount of the drug to the user without user input.

[0179] in conclusion

[0180] Although the systems and techniques have been described in 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 or acts are disclosed as example forms of implementing the claimed subject matter.

Claims

1. A method, comprising: obtaining sensor data from one or more sensors; Based on the sensor data, detecting a user's location; Based on the location of the user, predicting an activity that the user will perform at the location; as well as Recommendations are generated for controlling the user's glycemic response to the predicted activity.

2. The method of claim 1, wherein generating the suggestion further comprises: predicting the glycemic response of the user to the predicted activity; determining whether the glycemic response of the user to the predicted activity will result in an adverse health event; as well as In response to determining that the glycemic response of the user to the predicted activity will result in the adverse health event, determining a mitigation therapy to prevent the adverse health event, wherein the recommendation includes the mitigation therapy. The method according to claim 1 , wherein detecting the position of the user is based on at least two different types of sensor data. 4 . The method according to claim 1 , wherein detecting the location of the user comprises detecting the location of the user based on first sensor data, and confirming the location of the user based on second sensor data.

5. The method according to any one of claims 1 to 4, wherein detecting the location of the user comprises: detecting at least two candidate locations of the user based on first sensor data; and selecting one of the at least two candidate locations as the location of the user based on second sensor data.

6. The method according to any one of claims 1 to 5, wherein predicting the activity comprises predicting a state of the activity based on the location, the state comprising a pre-activity state, an activity state, or a post-activity state, and wherein the suggestion is based on the state of the activity.

7. The method of any one of claims 1 to 6, further comprising displaying the suggestions for controlling the glycemic response of the user 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; as well as At least one memory and one processor, the one processor being configured to perform operations, the operations comprising: detecting a location of the user based on the sensor data; Based on the location of the user, predicting an activity that the user will perform at the location; determining an amount of the medication to administer to the user to control the user's glycemic response to the predicted activity; and Instructions are transmitted to the drug delivery system, the instructions causing the drug delivery system to deliver the amount of the drug to the user.

9. The system according to claim 8, further comprising an analyte monitoring device for obtaining analyte data of the user, wherein the analyte monitoring device and the drug delivery system are connected in a closed loop.

10. The system of claim 8 or 9, wherein the instructions cause the drug delivery system to deliver the amount of the drug to the user without user input.

Images