Gesture-based diabetes therapy control

Abstract

Devices, systems, and techniques for controlling delivery of diabetes therapy are described. In one example, a system includes a wearable device configured to generate user activity data associated with an arm of a user; and one or more processors configured to: identify, based on the user activity data, at least one gesture indicative of preparing an insulin injection with an injection device; generating information indicative of at least one of an amount or type of insulin dose in the insulin injection by the injection device based on the at least one recognized gesture; comparing the generated information to a criterion for an appropriate insulin injection; and based on the comparison, outputting information indicating whether the criteria are met.

Description

[0001] This application is a continuation-in-part of the Inventive Patent Application entitled “Gesture-Based Diabetes Therapy Control” having an International Application Date of 2020-08-28, an International Application Number of PCT / US2020 / 048461, and an Application Number of 202080059875.2 in the People’s Republic of China, which entered the National Phase on August 28, 2020.

[0002] This application claims priority to U.S. Application No. 17 / 004,969, filed August 27, 2020, which claims the benefit of U.S. Provisional Application No. 62 / 893,717, filed August 29, 2019, and U.S. Provisional Application No. 62 / 893,722, filed August 29, 2019, the entire contents of each of which are hereby incorporated by reference herein. TECHNICAL FIELD

[0003] The present disclosure relates to medical systems, and more particularly to medical systems for therapy for diabetes. BACKGROUND

[0004] Diabetic patients receive insulin through a pump or an injection device to control the glucose level in his or her bloodstream. Naturally produced insulin can not be able to control the glucose level in a diabetic patient’s bloodstream due to insufficient insulin production and / or due to insulin resistance. To control the glucose level, a patient’s routine therapy can include doses of basal insulin and bolus insulin. Basal insulin, also known as background insulin, tends to keep blood glucose levels at a consistent level during periods of fasting and is a long- or intermediate-acting insulin. Bolus insulin can be used at meal times or other times or near meal times or other times when glucose levels can occur relatively quickly and, thus, can serve as a short- or rapid-acting form of insulin dose. SUMMARY

[0005] Devices, systems, and techniques for gesture-based control of diabetes therapy are described. In various examples, gesture-based control prevents a patient configured to deliver diabetes therapy to the patient from being administered an inappropriate and / or ineffective diabetes therapy. One or more processors (e.g., in a patient device such as an injection device for insulin delivery, a pump for insulin delivery, or another device; in a mobile or desktop computing device; and / or in one or more servers in a network cloud) can be configured to detect an impending delivery of diabetes therapy by the patient. In at least one example, the one or more processors can determine that an insulin injection is impending based on (recent) activity of the patient that includes movement (e.g., hand movement) by the patient. Various hardware / software components (e.g., accelerometers, optical sensors, gyroscopes, etc.) can capture and record activity of the patient as user activity data, and by detecting certain gestures in the user activity data, the one or more processors can predict the occurrence of an insulin injection.

[0006] Certain gestures are equivalent to insulin injections that include the gestures, in which the patient utilizes an injection device in a certain manner. If any of the patient's activity is sufficiently similar to these gestures, then the patient is likely preparing to inject insulin into him / herself. However, it can be beneficial to ensure that the correct amount of insulin type is injected before the patient injects insulin. As described in more detail, the one or more processors can generate information based on the gestures that indicates an amount of insulin and / or an insulin dose type in the insulin injection that the patient is most likely preparing. The one or more processors can compare the information that indicates the amount or type of insulin dose to criteria for a proper insulin injection (e.g., dose, whether enough time has passed between insulin injections, whether food has been consumed between insulin injections, whether the patient is using basal insulin or a bolus insulin based on the time of day, and other such examples). If the criteria are not met, then the one or more processors can output an alert so that the patient does not inject him / herself, or more generally, perform some modification to correct an impropriety associated with the insulin injection or to improve the efficacy of the insulin injection.

[0007] Although the above examples are described with respect to a patient, the techniques are not so limited. The example techniques can be performed by a caregiver (e.g., at home or at a hospital), and the example techniques can be used for the caregiver. In general, the techniques can be applicable to a user, where user is a general term referring to one or a combination of the patient and the caregiver.

[0008] In one example, the disclosure describes a system having a wearable device configured to generate user activity data associated with a user's arm and one or more processors configured to: identify, based on the user activity data, at least one gesture indicative of preparing an insulin injection with an injection device; generate, based on the at least one identified gesture, information indicative of at least one of an amount or a type of insulin dose in the insulin injection by the injection device; compare the generated information to a standard for a proper insulin injection; and based on the comparison, output information indicating whether the standard is met.

[0009] The details of one or more aspects of the disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the disclosure will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF DRAWINGS

[0010] Figure 1 is a block diagram illustrating an example system for delivering or guiding a therapy dose according to one or more examples described in this disclosure.

[0011] Figure 2 is a block diagram illustrating another example system for delivering or guiding a therapy dose according to one or more examples described in this disclosure.

[0012] Figure 3 is a block diagram illustrating another example system for delivering or guiding a therapy dose according to one or more examples described in this disclosure.

[0013] Figure 4 is a block diagram illustrating an example of a patient device according to one or more examples described in this disclosure.

[0014] Figure 5 is a block diagram illustrating an example of a wearable device according to one or more examples described in this disclosure.

[0015] Figure 6 is a flow diagram illustrating an example method of operation according to one or more examples described in this disclosure.

[0016] Figure 7A and 7B is a flow diagram illustrating another example method of operation according to one or more examples described in this disclosure. DETAILED DESCRIPTION

[0017] Devices, systems, and techniques for managing a patient's glucose levels are described in this disclosure. There can be instances in which the administration of a diabetes therapy inadvertently impacts the health of a patient, e.g., such that the patient receives an ineffective or incorrect amount or type of insulin. Because some patients self-manage a diabetes therapy (e.g., through an injection device for delivering a dose of insulin), these patients have ample opportunity to impact (e.g., counteract) their glucose levels. Given that most people have busy lives, a patient can become so engrossed in other things that he or she completely forgets to inject insulin at a recommended time. At times, a few minor distractions throughout the day can disrupt a patient's recommended injection schedule. Even if a patient remembers a scheduled insulin injection, the patient can forget the appropriate dose or type of insulin to administer. The patient can forget which settings to apply on an injection device to properly inject the appropriate amount and / or type of insulin. Even if a patient hires a caregiver to assist him / her in self-injecting insulin or to perform insulin injections, the caregiver can make a mistake in administering the diabetes therapy.

[0018] It should be noted that a variety of injection devices are described herein as being suitable for use with the devices, systems, and techniques of this disclosure. Some injection devices can be manual injection devices (e.g., syringes), while other injection devices (e.g., "smart" injection devices) can be equipped with processing circuitry and / or sensing technology. In some examples, a "smart" cap can be configured to attach to a syringe or to ride over an insulin pen. It should be noted that a cloud service (e.g., running on a server of a network cloud) can provide a number of benefits for a patient, including telemedicine services, managed care, and / or access to a network of medical professionals. The cloud service can operate with a number of devices (e.g., a patient device, a caregiver device, an injection device, and / or any other compatible computing device) to provide a remote monitoring system (e.g., CARELINK TM ), through which a user can be notified of pending inappropriate diabetes therapy (e.g., an inappropriate insulin injection), general and diabetes-specific health issues including health issues caused by inappropriate diabetes therapy, and other critical transmissions through an alert (e.g., a CAREALERT TM notification).

[0019] In the present disclosure, devices, systems, and techniques for managing a patient's glucose levels include devices, systems, and techniques for gesture-based control of diabetes therapy. As described herein, gesture-based control involves protecting a patient from the consequences of incorrect and / or ineffective diabetes therapy, e.g., in the form of an inappropriate insulin injection. By detecting one or more gestures indicative of an impending or ongoing insulin injection, devices, systems, and techniques for gesture-based control can determine whether certain aspects of the injection are inappropriate and have sufficient time to notify the user (e.g., the patient or a caregiver) of one or more of the improprieties in the patient's pending injection (e.g., the settings of the injection device) before the user completes the insulin injection. In this way, the user has an opportunity to stop the insulin injection and / or modify the settings of the device to eliminate at least one impropriety.

[0020] To illustrate by way of example, if a patient forgets a recent insulin injection and attempts to inject insulin at an inappropriate time and / or with an insufficient interval between injections, the devices, systems, and techniques described herein can output an alert indicating the inappropriate insulin injection. As an alternative, if a patient forgets to inject a scheduled injection and is about to miss a scheduled injection, the devices, systems, and techniques described herein can output an alert indicating the missed injection. One or more processors (e.g., in a mobile computing device referred to as a patient device, in a network cloud server providing cloud services, or in the injection device itself) can generate an alert containing any content type (e.g., video, audio, text) and output the alert through any mechanism (e.g., an electronic display, a haptic response (e.g., a vibration), etc.).

[0021] The one or more processors can generate the alert to notify any user of the injection device, including the patient through a patient device or the patient's family caregiver through a caregiver device. The caregiver can be a family caregiver (e.g., a family member or friend, a nurse, etc.), a medical professional (e.g., a doctor or nurse) in a medical facility (e.g., a hospital), or another professional responsible for the patient's health. The one or more processors can transmit the alert from a handheld patient device to the injection device, a network cloud server, and / or a caregiver device. As an alternative, the one or more processors can transmit the alert from a network cloud server to the injection device, a patient device, and / or a caregiver device. In some instances in which processing circuitry within the injection device executes logic (e.g., processor-executable instructions or code) for gesture-based control, the injection device can generate an alert for display on an electronic display of the injection device itself and / or transmit the alert to a patient device, a network cloud server, a caregiver device, and / or another external device to notify the patient, the cloud service, and / or the caregiver.

[0022] Even if the user prepares the insulin injection at the appropriate time, the user can prepare an injection with an ineffective dose and / or type of insulin. Some example patient gestures correspond to setting a dose and / or type on an injection device, and by detecting these gestures, the actual dose and / or type can be determined. For example, if the injection device has a dial for setting a dose, the patient can make a gesture of moving the dial a number of clicks, where each click increases the amount of insulin loaded into the chamber of the injection device. This gesture can be detected by one or more sensors in the wearable device attached to the user’s body, activity monitor, and / or the injection device itself. If the detected dose does not match the recommended dose but is within a certain range, the detected dose can be considered ineffective, while a detected dose that is outside of a certain range can be considered fatal. In some instances, the patient can not face serious consequences from receiving an ineffective dose of insulin compared to a fatal dose. In response to a prediction that an ineffective or fatal dose is about to be injected, the devices, systems, and techniques for gesture-based control can notify the patient by displaying an alert on an electronic display configured to present various types of content (e.g., text, graphical content, video content, etc.) as well as haptic and audible alerts. In some instances, the devices, systems, and techniques for gesture-based control can display data that informs the patient of which device setting(s) to modify to correct the ineffective dose.

[0023] Depending on which injection device a given diabetic patient utilizes, the injection device can implement one or more techniques to detect an insulin injection (either during preparation or after occurrence), record various information for each injection, and / or notify the patient (e.g., through a text warning or a sound alert) if there is a problem (e.g., improper) with any particular injection. Some manufacturers equip their injection devices with one or more sensors to perform the detection, recording, and notification as described above; however, some patients use injection devices that are equipped with a minimal level of sensing technology or no sensing technology at all, leaving the patient or the patient’s caregiver responsible for properly administering the patient’s diabetes therapy. An external device with sensing technology (e.g., a wearable device, a patient device, or another mobile computing device) can provide sensor data for identifying one or more gestures indicative of an insulin injection. Some injection devices (e.g., an insulin pen or syringe) described herein can be retrofitted with sensing technology (e.g., in a smart insulin pen cap).

[0024] Other injection devices, aside from those described herein, lack the ability to provide gesture control and safeguard patient health. These devices are limited in many areas, including understanding a patient's appropriate diabetes therapy in terms of dose, insulin type (e.g., bolus insulin), dosing schedule, and other parameters. Even though some injection devices can detect dose or insulin type through various means, none can operate in conjunction with a wearable device or another external device to identify dose or insulin type.

[0025] The devices, systems, and techniques described herein are configured to mitigate or entirely eliminate the limitations of injection devices described above. In some examples, one or more sensors in a device can provide data describing various user activities (e.g., patient activities or caregiver activities) to one or more processors (e.g., processing circuitry) in the same device or a different device, including movements of the user's hands and / or arms and / or the posture (e.g., position and / or orientation) of the user's hands while holding the injection device. Some example sensors can be communicatively coupled to one or more processors, while some sensors can be directly coupled to one or more processors.

[0026] Thus, one or more processors can receive user activity data from one or more internal sensors, one or more sensors in an injection device, and / or one or more sensors in another device, such as a wearable device attached to a body part of the patient. In one example, a wearable device (referred to as a smartwatch) can be attached to one of the patient's hands and equipped with an inertial measurement unit (e.g., one or more accelerometers) that can capture user activity (e.g., user movement and / or user posture) that includes gestures equivalent to an insulin injection. If the injection device is equipped with little or no sensing technology, an accelerometer in the wearable device or another external device can provide user activity data that can predict an insulin injection and / or injection device data that can confirm (or reject) the prediction of an insulin injection.

[0027] In some examples, the devices, systems, and techniques described herein can utilize data provided by an injection device to confirm a prediction of an insulin injection based on a user’s recognition of one or more gestures. To demonstrate by way of example, after recognizing a gesture for setting a dose and type on an injection device, a sensor can sense that a cartridge has been loaded into the injection device in preparation for administering an insulin injection, thereby confirming the gesture recognition. A user can provide input data (e.g., patient confirmation) confirming the insulin injection preparation. Confirmation can be achieved by injection device data provided by other devices, such as a device having a sensor for detecting an insulin dose in a syringe barrel. The sensor data can be used to predict that an insulin injection has been prepared, as well as to predict that an insulin injection has occurred (e.g., recently). The sensor for reading insulin levels in the injection device can measure a first insulin level and a second insulin level, and determine that an intervening insulin injection reduced the insulin level from the first level to the second level. One benefit of confirmation is that supporting user activity data for the prediction can be provided by an unreliable external sensor and / or contain inaccurate or incorrect sensor data; in effect, confirmation serves to mitigate the unreliability of the external sensor and the inaccuracy or incorrectness of the external sensor data. As another benefit of confirmation, the one or more processors can operate with an injection device that does not have any inertial measurement unit or other sensor. In effect, confirmation by the injection device or injection device data allows the one or more processors to rely on the wearable device for user activity data without implementing an internal sensor or relying on a sensor of the injection device.

[0028] Figure 1 is a block diagram illustrating an example system for delivering or directing a dose of therapy, in accordance with one or more examples described in this disclosure. Figure 1 System 10A is illustrated, which includes patient 12, insulin pump 14, tubing 16, infusion set 18, sensor 20 (which can be a glucose sensor), wearable device 22, patient device 24, and cloud 26. Cloud 26 represents a local, wide-area, or global computing network that includes one or more processors 28A-28N (“one or more processors 28”). In some examples, the various components can determine a change in therapy based on a determination of a glucose level of sensor 20, and thus system 10A can be referred to as a continuous glucose monitoring (CGM) system 10A.

[0029] Patient 12 can have diabetes (e.g., Type 1 diabetes or Type 2 diabetes), and thus, patient 12’s glucose levels can not be controlled without delivery of supplemental insulin. For example, patient 12 can not produce enough insulin to control glucose levels, or the amount of insulin that patient 12 produces can be insufficient due to insulin resistance that patient 12 can have developed.

[0030] To receive supplemental insulin, the patient 12 can carry an insulin pump 14 coupled to a tubing 16 for delivering insulin into the patient 12. An infusion set 18 can be connected to the skin of the patient 12 and include a cannula that delivers insulin into the patient 12. A sensor 20 can also be coupled to the patient 12 to measure glucose levels of the patient 12. The insulin pump 14, tubing 16, infusion set 18, and sensor 20 can together form an insulin pump system. One example of an insulin pump system is the MINIMED® 670G insulin pump system by Medtronic, Inc. However, other examples of insulin pump systems can be used, and the example techniques should not be considered limited to the MINIMED® 670G insulin pump system. For example, the techniques described in this disclosure can be used for insulin pump systems that include wireless communication capabilities. However, the example techniques should not be considered limited to insulin pump systems with wireless communication capabilities, and other types of communication such as wired communication are also possible. In another example, the insulin pump 14, tubing 16, infusion set 18, and / or sensor 20 can be contained in the same housing. TM 670G insulin pump system. However, other examples of insulin pump systems can be used, and the example techniques should not be considered limited to the MINIMED TM 670G insulin pump system. For example, the techniques described in this disclosure can be used for insulin pump systems that include wireless communication capabilities. However, the example techniques should not be considered limited to insulin pump systems with wireless communication capabilities, and other types of communication such as wired communication are also possible. In another example, the insulin pump 14, tubing 16, infusion set 18, and / or sensor 20 can be contained in the same housing.

[0031] The insulin pump 14 can be a relatively small device that the patient 12 can place in different locations. For example, the patient 12 can clip the insulin pump 14 to a belt of pants worn by the patient 12. In some examples, the patient 12 can place the insulin pump 14 in a pocket for caution. In general, the insulin pump 14 can be worn in different places, and the patient 12 can place the insulin pump 14 in a certain location based on the particular clothing being worn by the patient 12.

[0032] To deliver insulin, the insulin pump 14 includes one or more reservoirs (e.g., two reservoirs). The reservoirs can be plastic cartridges that hold up to N units of insulin (e.g., up to 300 units of insulin) and lock into the insulin pump 14. The insulin pump 14 can be a battery-powered device that is powered by replaceable and / or rechargeable batteries.

[0033] The tubing 16, sometimes referred to as a catheter, connects on a first end to the reservoirs in the insulin pump 14 and on a second end to the infusion set 18. The tubing 16 can carry insulin from the reservoirs of the insulin pump 14 to the patient 12. The tubing 16 can be flexible, allowing for looping or bending to minimize concerns that the tubing 16 becomes detached from the insulin pump 14 or infusion set 18 or concerns that the tubing 16 breaks.

[0034] Infusor 18 can include a thin cannula that patient 12 inserts into a fat layer under the skin (e.g., a subcutaneous connection). Infusor 18 can rest near the stomach of patient 12. Insulin travels from a reservoir of insulin pump 14 through tubing 16 and through the cannula in infusor 18 and into patient 12. In some examples, patient 12 can use an infusor insertion device. Patient 12 can place infusor 18 into the infusor insertion device, and with a button on the infusor insertion device pressed, the infusor insertion device can insert the cannula of infusor 18 into the fat layer of patient 12, and with the cannula inserted into the fat layer of patient 12, infusor 18 can rest on top of the skin of the patient.

[0035] Sensor 20 can include a cannula inserted under the skin of patient 12, such as near the stomach of patient 12 or in the arm of patient 12 (e.g., a subcutaneous connection). Sensor 20 can be configured to measure interstitial glucose levels, which are the glucose found in the fluid between the cells of patient 12. Sensor 20 can be configured to sample glucose levels and rates of change of glucose levels over time continuously or periodically.

[0036] In one or more examples, insulin pump 14 and sensor 20, as well as Figure 1 The various components illustrated in FIG. 1 can together form a closed-loop therapy delivery system. For example, patient 12 can set a target glucose level on insulin pump 14, typically measured in milligrams per deciliter. Insulin pump 14 can receive a current glucose level from sensor 20 and, in response, can increase or decrease the amount of insulin delivered to patient 12. For example, if the current glucose level is above the target glucose level, insulin pump 14 can increase insulin. If the current glucose level is below the target glucose level, insulin pump 14 can temporarily stop delivering insulin. Insulin pump 14 can be considered an example of an automated insulin delivery (AID) device. Other examples of AID devices are possible, and the techniques described in this disclosure can be applicable to other AID devices.

[0037] For example, the insulin pump 14 and the sensor 20 can be configured to operate together to mimic some of the ways in which a healthy pancreas works. The insulin pump 14 can be configured to deliver basal insulin, which is a small amount of insulin released continuously throughout the day. At times, the glucose level can rise, such as due to eating or some other activity by the patient 12. The insulin pump 14 can be configured to deliver bolus insulin as needed in association with food intake or to correct for undesirable high glucose levels in the bloodstream. In one or more examples, if the glucose level rises above a target level, the insulin pump 14 can increase the bolus insulin to address the rise in glucose level. The insulin pump 14 can be configured to calculate the basal insulin delivery and the bolus insulin delivery and deliver the basal insulin and the bolus insulin accordingly. For example, the insulin pump 14 can determine an amount of basal insulin to deliver continuously and then determine an amount of bolus insulin to deliver to lower the glucose level in response to a rise in the glucose level due to eating or some other event.

[0038] Accordingly, in some examples, the sensor 20 can sample the glucose level and the rate of change of the glucose level over time. The sensor 20 can output the glucose level to the insulin pump 14 (e.g., over a wireless link connection such as Bluetooth or BLE). The insulin pump 14 can compare the glucose level to a target glucose level (e.g., set by the patient 12 or a clinician) and adjust the insulin dosage based on the comparison. In some examples, the sensor 20 can also output a predicted glucose level (e.g., where the glucose level is expected to be in the next 30 minutes) and the insulin pump 14 can adjust the insulin delivery based on the predicted glucose level.

[0039] As described above, the patient 12 or a clinician can set a target glucose level on the insulin pump 14. The patient 12 or the clinician can set the target glucose level on the insulin pump 14 in a variety of ways. As one example, the patient 12 or the clinician can communicate with the insulin pump 14 using the patient device 24. Examples of the patient device 24 include a mobile device, such as a smartphone or a tablet computer, a laptop computer, or the like. In some examples, the patient device 24 can be a special programmer or controller for the insulin pump 14. Although Figure 1 One patient device 24 is shown, but in some examples, there can be multiple patient devices. For example, the system 10A can include a mobile device and a controller, each of which is an example of the patient device 24. For ease of description only, the example techniques are described with respect to the patient device 24, and it is to be understood that the patient device 24 can be one or more patient devices.

[0040] The patient device 24 can also be configured to interface with the sensor 20. As one example, the patient device 24 can receive information from the sensor 20 through the insulin pump 14, where the insulin pump 14 relays information between the patient device 24 and the sensor 20. As another example, the patient device 24 can receive information (e.g., glucose levels or rates of change of glucose levels) directly from the sensor 20 (e.g., over a wireless link).

[0041] In one or more examples, the patient device 24 can display a user interface with which the patient 12 or a clinician can control the insulin pump 14. For example, the patient device 24 can display a screen that allows the patient 12 or a clinician to input a target glucose level. As another example, the patient device 24 can display a screen that outputs current and / or past glucose levels. In some examples, the patient device 24 can output notifications to the patient 12, such as notifications of a glucose level that is too high or too low and notifications regarding any actions that the patient 12 needs to take. For example, if the insulin pump 14 has a low battery, the insulin pump 14 can output a low battery indication to the patient device 24, and the patient device 24 can in turn output a notification to the patient 12 to replace or charge the battery.

[0042] Controlling the insulin pump 14 through the patient device 24 is one example, and should not be considered limiting. For example, the insulin pump 14 can include a user interface (e.g., buttons) that allows the patient 12 or a clinician to set various glucose levels for the insulin pump 14. Also, in some examples, the insulin pump 14, either by itself or in addition to the patient device 24, can be configured to output notifications to the patient 12. For example, the insulin pump 14 can output an audible or tactile output if a glucose level is too high or too low. As another example, the insulin pump 14 can output a low battery indication on a display of the insulin pump 14 if the battery is low.

[0043] The above describes example ways in which the insulin pump 14 can deliver insulin to the patient 12 based on a current glucose level (e.g., measured by the sensor 20). In some cases, there can be a therapeutic gain by proactively delivering insulin to the patient 12, rather than reacting when a glucose level becomes too high or too low.

[0044] A glucose level of the patient 12 can increase as a result of a particular user action. As one example, a glucose level of the patient 12 can increase as a result of the patient 12 engaging in an activity such as eating or exercising. In some examples, there can be a therapeutic gain if it can be determined that the patient 12 is engaging in an activity, and insulin is delivered based on the determination that the patient 12 is engaging in the activity.

[0045] For example, the patient 12 can forget to cause the insulin pump 14 to deliver insulin after eating, resulting in an insulin deficiency. Alternatively, the patient 12 can cause the insulin pump 14 to deliver insulin after eating, but can forget that the patient 12 previously caused the insulin pump 14 to deliver insulin for the same meal event, resulting in an overdose of insulin. Also, in instances where the sensor 20 is used, the insulin pump 14 can not take any action until the glucose level is greater than the target level. By actively determining that the patient 12 is engaging in an activity, the insulin pump 14 can deliver insulin in a manner such that the glucose level does not rise above the target level or rises only slightly above the target level (i.e., less than it would have risen without the active delivery of insulin). In some instances, by actively determining that the patient 12 is engaging in an activity and delivering insulin accordingly, the glucose level of the patient 12 can rise more slowly.

[0046] Although the active determination that the patient 12 is eating and the delivery of insulin accordingly is described above, the example techniques are not so limited. The example techniques can be used to actively determine an activity that the patient 12 is engaging in (e.g., eating, exercising, sleeping, driving, etc.). The insulin pump 14 can then deliver insulin based on the determination of the type of activity that the patient 12 is engaging in.

[0047] As Figure 1 As shown, the patient 12 can wear a wearable device 22. Examples of the wearable device 22 include a smart watch or a fitness tracker, either of which in some examples can be configured to be worn on the wrist or arm of the patient. In one or more examples, the wearable device 22 includes an inertial measurement unit, such as a six-axis inertial measurement unit. The six-axis inertial measurement unit can couple a 3-axis accelerometer with a 3-axis gyroscope. The accelerometer measures linear acceleration, while the gyroscope measures rotational motion. The wearable device 22 can be configured to determine one or more movement characteristics of the patient 12. Examples of the one or more movement characteristics include values related to the frequency, amplitude, trajectory, position, velocity, acceleration, and / or pattern of movement instantaneously or over time. The frequency of movement of the arm of the patient can refer to how many times the patient 12 repeats a movement (e.g., the frequency of moving back and forth between two positions) in a certain time. The wearable device 22 can be configured to determine one or more posture characteristics of the patient 12, including values related to position and / or orientation.

[0048] The patient 12 can wear the wearable device 22 on his or her wrist. However, the example techniques are not so limited. The patient 12 can wear the wearable device 22 on a finger, on the forearm, or on the bicep. In general, the patient 12 can wear the wearable device 22 anywhere that can be used to determine a gesture indicative of eating, such as a movement characteristic of the arm.

[0049] The manner in which the patient 12 is moving his or her arm (i.e., movement characteristics) can refer to the direction, angle, and orientation of the patient's 12 arm, including values related to the frequency, amplitude, trajectory, position, velocity, acceleration, and / or pattern of movement over time. As an example, if the patient 12 is eating, the patient's 12 arm will be oriented in a certain manner (e.g., the thumb facing the patient's 12 body), the angle of movement of the arm will move about 90 degrees (e.g., from the plate to the mouth), and the direction of movement of the arm will be the path from the plate to the mouth. Forward / backward, up / down, pitch, roll, yaw measurements from the wearable device 22 can indicate the manner in which the patient 12 is moving his or her arm. Also, the patient 12 can have a certain frequency at which the patient 12 moves his or her arm or a pattern in which the patient 12 moves his or her arm that is more indicative of eating than other activities such as smoking or vaping, where the patient 12 can raise his or her arm to his or her mouth.

[0050] Although the above description describes the wearable device 22 as being used to determine whether the patient 12 is eating, the wearable device 22 can be configured to detect the movement (e.g., one or more movement characteristics) of the patient's 12 arm and the movement characteristics can be used to determine the activity being performed by the patient 12. For example, the movement characteristics detected by the wearable device 22 can indicate whether the patient 12 is exercising, driving, sleeping, etc. As another example, the wearable device 22 can indicate the posture of the patient 12, which can be consistent with the posture of exercising, driving, sleeping, etc. Another term for movement characteristics can be gesture movement. Thus, the wearable device 22 can be configured to detect gesture movements (i.e., movement characteristics of the patient's 12 arm) and / or postures, where the gesture and / or postures can be part of various activities (e.g., eating, exercising, driving, sleeping, injecting insulin, etc.).

[0051] In some examples, the wearable device 22 can be configured to determine the particular activity being performed by the patient 12 based on the detected gesture (e.g., movement characteristics of the patient's 12 arm) and / or posture. For example, the wearable device 22 can be configured to determine whether the patient 12 is eating, exercising, driving, sleeping, etc. In some examples, the wearable device 22 can output information to the patient device 24 indicating the movement characteristics of the patient's 12 arm and / or the posture of the patient 12, and the patient device 24 can be configured to determine the activity being performed by the patient 12.

[0052] Wearable device 22 and / or patient device 24 may be programmed with information that wearable device 22 and / or patient device 24 may use to determine that patient 12 is performing a particular activity. For example, patient 12 may perform various activities throughout the day, where the movement characteristics of patient 12's arms may be similar to the movement characteristics of patient 12's arms for a particular activity, but patient 12 is not performing the activity. As an example, patient 12 yawning and cupping their mouth may be similar to the movement characteristics of patient 12 eating. Patient 12 picking up an object may be similar to the movement characteristics of patient 12 exercising. Furthermore, in some instances, patient 12 may be performing a particular activity, but wearable device 22 and / or patient device 24 may fail to determine that patient 12 is performing the particular activity.

[0053] Thus, in one or more instances, wearable device 22 and / or patient device 24 can "learn" to determine whether patient 12 is engaging in a particular activity. However, the computing resources of wearable device 22 and patient device 24 may be insufficient to perform the learning required to determine whether patient 12 is engaging in a particular activity. The computing resources of wearable device 26 and patient device 24 may be sufficient to perform the learning, but for ease of description only, the following description is made with respect to one or more processors 28 in cloud 26.

[0054] like Figure 1 As shown in , system 10A includes a cloud 26, which includes one or more processors 28. For example, cloud 26 includes multiple network devices (e.g., servers), and each of the multiple devices includes one or more processors. The one or more processors 28 can be processors of multiple network devices and can be located within a single network device in the network devices, or can be distributed across two or more network devices in the network devices. Cloud 26 represents a cloud infrastructure that supports one or more processors 28 on which applications or operations requested by one or more users run. For example, cloud 26 provides cloud computing to use one or more processors 28 instead of personal devices 24 or wearable devices 22 to store, manage, and process data on network devices. One or more processors 28 can share data or resources for performing calculations and can be part of a computing server, network server, database server, etc. One or more processors 28 can be in a network device (e.g., server) within a data center, or can be distributed across multiple data centers. In some cases, the data centers can be in different geographical locations.

[0055] The one or more processors 28, as well as other processing circuitry described herein, can include any one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuitry, as well as any combinations of such

[0056] The one or more processors 28 can be implemented as fixed function circuitry, programmable circuitry, or a combination thereof. Fixed function circuitry refers to circuitry that provides particular functionality and is pre-set in the operations it can perform. Programmable circuitry refers to circuitry that can be programmed to perform various tasks and provides flexible functionality in the operations it can perform. For example, programmable circuitry can execute software or firmware that cause the programmable circuitry to operate in the manner defined by instructions of the software or firmware. Fixed function circuitry can execute software instructions (e.g., to receive parameters or output parameters), but the types of operations that the fixed function circuitry performs are generally immutable. In some instances, one or more of the units can be different circuit blocks (fixed function or programmable), and in some instances, the one or more units can be integrated circuits. The one or more processors 28 can include arithmetic logic units (ALUs), elementary function units (EFUs), digital circuits, analog circuits, and / or programmable cores formed from programmable circuitry. In instances where the operations of the one or more processors 28 are performed using software executed by programmable circuitry, memory accessible to the one or more processors 28 (e.g., on a server) can store object code of the software that the one or more processors 28 receive and execute.

[0057] In some instances, the one or more processors 28 can be configured to determine a pattern from gesture movements (e.g., one or more movement characteristics determined by the wearable device 22) and configured to determine a particular activity that the patient 12 is performing. The one or more processors 28 can provide a real-time responsive cloud service that can determine the activity that the patient 12 is performing on a real-time responsive basis, and in some instances, provide a suggested therapy (e.g., an amount of an insulin dose). The cloud 26 and the patient device 24 can communicate over Wi-Fi or over a carrier network.

[0058] For example, as described above, in some instances, the wearable device 22 and / or the patient device 24 can be configured to determine that the patient 12 is performing an activity. However, in some instances, the patient device 24 can output information indicative of movement characteristics of the patient’s 12 arm’s movement to the cloud 26 and can have other contextual information, such as location or time of day. The one or more processors 28 of the cloud 26 can then determine the activity that the patient 12 is performing. The insulin pump 14 can then deliver insulin based on the determined activity of the patient 12.

[0059] An example approach is described in U.S. Patent Publication No. 2020 / 0135320 Al, in which the one or more processors 28 can be configured to determine that the patient 12 is performing an activity and determine a therapy to be delivered. Generally, the one or more processors 28 can first undergo an initial “learning” phase in which the one or more processors 28 receive information to determine a behavior pattern of the patient 12. Some of this information can be provided by the patient 12. For example, the patient 12 can be prompted or he / she can input information into the patient device 24 indicative of the patient 12 being performing a particular activity, a length of time of the activity, and other such information that the one or more processors 28 can use to predict the behavior of the patient 12. After the initial learning phase, the one or more processors 28 can still update the behavior pattern based on recently received information, but require less or no information from the patient 12.

[0060] During the initial learning phase, the patient 12 can provide information about the patient’s 12 dominant hand (e.g., right or left hand) and where the patient 12 wears the wearable device 22 (e.g., around the wrist of the right or left hand). The patient 12 can be instructed to wear the wearable device 22 on the wrist of the hand that the patient 12 uses to eat. The patient 12 can also provide information about the orientation of the wearable device 22 (e.g., the face of the wearable device 22 is on the top of the wrist or on the bottom of the wrist).

[0061] During the initial learning phase, the patient 12 can input information indicative of the patient 12 being engaged in an activity either proactively or in response to a prompt / inquiry (e.g., by the patient device 24). During this time, the wearable device 22 can continuously determine one or more movement and / or posture characteristics (e.g., gestures) of the patient 12 and output such information to the patient device 24, which communicates the information to the one or more processors 28. The one or more processors 28 can store information of one or more movement characteristics of the patient’s 12 arm’s movement during the activity to later determine whether the patient 12 is engaged in the activity (e.g., whether the received information of the manner and frequency of the patient’s 12 arm’s movement is consistent with stored information of the manner and frequency of the patient’s 12 arm’s movement when the patient 12 is known to be engaged in the activity).

[0062] The arm movement is described above as a factor in determining whether the patient 12 is participating in an activity. However, there can be various other factors that can be used alone or in combination with arm movement to determine whether the patient 12 is participating in an activity. As one example, the patient 12 can participate in an activity at regular time intervals. As another example, the patient 12 can participate in an activity at certain locations. During an initial learning phase, when the patient 12 inputs (e.g., through the patient device 24) that he or she is participating in an activity, the patient device 24 can output information about the time of day and the location of the patient 12. For example, the patient device 24 can be equipped with a positioning device, such as a global positioning system (GPS) unit, and the patient device 24 can output location information determined by the GPS unit. There can be other ways to determine location, such as based on Wi-Fi connectivity and / or access to 4G / 5G LTE, or some other form of access, such as tracking the device location of the patient device 24 based on a telecommunications database. The time of day and the location are two examples of contextual information that can be used to determine whether the patient 12 is participating in an activity.

[0063] However, there can be other examples of contextual information for the patient 12, such as sleep patterns, body temperature, stress level (e.g., based on pulse and respiration), heart rate, etc. In general, there can be various biometric sensors (e.g., for measuring temperature, pulse / heart rate, respiration rate, etc.) that can be part of the wearable device 22 or that can be separate sensors. In some examples, the biometric sensors can be part of the sensors 20.

[0064] The contextual information for the patient 12 can include conditional information. For example, the patient 12 can eat every 3 hours, but the exact time that the patient 12 eats can vary. In some examples, the conditional information can be to determine whether the patient 12 has eaten and whether a certain amount of time (e.g., 3 hours) has passed since the patient 12 ate. In general, any information that establishes a behavior pattern can be used to determine whether the patient 12 is participating in a particular activity.

[0065] The one or more processors 28 can determine whether the patient 12 is engaging in an activity based on information determined and / or collected by the wearable device 22 and the patient device 24 using artificial intelligence such as machine learning or other data analysis techniques. As one example, the one or more processors 28 can utilize neural network techniques during an initial learning phase. For example, the one or more processors 28 can receive training data from the patient 12 for training a classifier module executing on the one or more processors 28. As described above, the one or more processors 28 can receive training data based on patient confirmation when the patient device 24 and / or the wearable device 22 determine that the patient 12 is engaging in an activity based on the way and frequency of movement of the patient’s 12 arms (e.g., gestures consistent with movement of the arms while eating). The one or more processors 28 can generate and store labeled data records containing features related to movement as well as other contextual features such as time of day or location. The one or more processors 28 can train a classifier on a labeled data set containing multiple labeled data records, and the one or more processors 28 can use the trained classifier model to more accurately detect the start of a food intake event.

[0066] Other examples that can be used for neural networks include behavioral patterns. For example, the patient 12 can only eat a particular food after exercising, and always eat the particular food after exercising. The patient 12 can eat at a particular time and / or location. Although described with respect to eating, there can be various conditions that collectively indicate a behavioral pattern of the patient 12 for different activities.

[0067] As another example, the one or more processors 28 can utilize a k-means clustering technique to determine whether the patient 12 is engaged in an activity. For example, during an initial learning phase, the one or more processors 28 can receive different types of context information and form clusters, where each cluster represents a behavior of the patient 12 (e.g., eating, sleeping, walking, exercising, etc.). For example, the patient 12 can input information indicating that he or she is walking (e.g., enter the information into the patient device 24). The one or more processors 28 can utilize all of the context information received while the patient 12 is walking to form a first cluster associated with walking. The patient 12 can input information indicating that he or she is eating (e.g., enter the information into the patient device 24). The one or more processors 28 can utilize all of the context information received while the patient 12 is eating to form a second cluster associated with eating, and so on. Then, based on the received context information, the one or more processors 28 can determine which cluster aligns with the context information and determine the activity that the patient 12 is performing. As described in more detail, the type of activity and a prediction of when the activity will occur can be used to determine when to deliver an insulin therapy. Other examples of machine learning can exist, and the example techniques are not limited to any particular machine learning technique.

[0068] Various other ways can exist in which the one or more processors 28 can determine the activity that the patient 12 is performing. The present disclosure provides some example techniques for determining the activity that the patient 12 is performing, but the example techniques should not be considered limiting.

[0069] During the initial learning phase, the patient 12 can also input information about the activity that the patient 12 is performing. For example, in the case of eating, the patient 12 can input information indicating what the patient 12 is eating and / or how many carbohydrates are in the food that the patient 12 is eating. As one example, at 9:00 every morning, the patient 12 can input that he or she is eating a biscuit or input that the patient 12 is consuming 48 grams of carbohydrates.

[0070] In some examples, the one or more processors 28 can be configured to determine an amount of insulin to deliver to the patient 12 (e.g., a bolus insulin therapy dose). As one example, a memory accessible by the one or more processors 28 can store patient parameters of the patient 12 (e.g., weight, height, etc.). The memory can also store a lookup table indicating amounts of bolus insulin to deliver for different patient parameters and different types of food. The one or more processors 28 can access the memory and can determine an amount of bolus insulin for the patient 12 to receive based on the type of food that the patient 12 is eating and the patient parameters.

[0071] As another example, the one or more processors 28 can be configured to utilize a“digital twin” of the patient 12 to determine an amount of bolus insulin for the patient 12 to receive. The digital twin can be a digital replica or model of the patient 12. The digital twin can be software executing on the one or more processors 28. The digital twin can receive information as input about what the patient 12 ate for a meal. Because the digital twin is a digital replica of the patient 12, the output from the digital twin can be information about what the glucose level of the patient 12 is likely to be after the meal and a recommendation of how much bolus insulin to deliver to the patient 12 to control the rise in glucose level.

[0072] For example, the digital twin can indicate what the correct dose should have been for the patient 12 to have taken for a past meal. In one or more examples, the patient 12 can input information indicating the food that the patient 12 ate for a meal, and the one or more processors 28 can receive information about the glucose level. With the information indicating the food that the patient 12 ate and the glucose level, the one or more processors 28 can utilize the digital twin to determine what the insulin dose should have been (e.g., based on how the digital twin models how the food will affect the glucose level of the patient). Then, at a subsequent time when the patient 12 is predicted to eat the same meal, the one or more processors 28 can determine what the insulin dose should be based on the insulin dose that the digital twin has previously determined.

[0073] Thus, in one or more examples, the one or more processors 28 can utilize information about movement characteristics of arm movements, eating speed, amount of food consumed, food content, etc., while also tracking posture characteristics and other contextual information. Examples of contextual information include location information, time of day, wake-up time, amount of time since last meal, calendar events, information about people the patient 12 can be meeting with, etc. The one or more processors 28 can identify patterns and correlations between all of these various factors to determine activities that the patient 12 is performing, such as eating, walking, sleeping, driving, etc.

[0074] After the initial learning phase, the one or more processors 28 can automatically and with minimal input from the patient 12 determine that the patient 12 is performing a particular activity and determine an amount of bolus insulin to deliver based on the determination. The one or more processors 28 can output a recommendation of the amount of bolus insulin to deliver to the patient device 24. The patient device 24 can then in turn control the insulin pump 14 to deliver the determined amount of insulin. As one example, the patient device 24 can output the amount of bolus insulin to deliver to the insulin pump 14 with or without user confirmation. As another example, the patient device 24 can output a target glucose level and the insulin pump 14 can deliver insulin to achieve the target glucose level. In some examples, the one or more processors 28 can output information indicative of the target glucose level to the patient device 24 and the patient device 24 can output the information to the insulin pump 14. All of these examples can be considered examples of the one or more processors 28 determining an amount of insulin to deliver to the patient 12.

[0075] The above describes example ways of determining whether the patient 12 is performing an activity, determining an amount of insulin to deliver, and causing the amount of insulin to be delivered. The example techniques can require little to no intervention from the patient 12. In this way, the likelihood of the patient 12 receiving the correct dose of insulin at the correct time is increased and the likelihood of causing problematic human error (e.g., the patient 12 forgetting to log a meal, forgetting to take insulin, or taking insulin but forgetting that insulin has already been taken) is decreased.

[0076] While the above example techniques can be beneficial for the patient 12 to receive insulin at the correct time, the present disclosure describes example techniques to further proactively control delivery of insulin to the patient 12. For example, the above describes examples of the patient 12 wearing the insulin pump 14. However, there can be times when the patient 12 is unable to wear the insulin pump 14 and needs to manually inject insulin. There can also be times when the patient 12 does not have a dose of insulin for the reservoir of the insulin pump 14. The above described techniques for determining an amount of insulin to deliver and when to deliver the insulin can also be useful in situations where the insulin pump 14 is not available. For example, as described below with respect to Figure 2 and 3 As described in more detail, in addition to the insulin pump 14, the patient 12 can utilize an injection device, such as an insulin pen, a syringe, etc. In utilizing an injection device, the patient 12 can miss a dose or input an incorrect amount of insulin even when he / she is notified to inject himself / herself.

[0077] The present disclosure describes examples of utilizing activity data to determine gesture information indicative of a patient 12 (or possibly a caregiver) preparing for an insulin injection or actually injecting insulin. Example techniques can determine whether criteria for a proper insulin injection are met to alert the patient 12 if the criteria are not met.

[0078] In particular, the present disclosure describes example techniques for controlling delivery of therapy to a diabetic patient, where the therapy involves timely injection of an effective amount of the correct type of insulin. To implement these techniques, one or more processors 28 can first predict that an insulin injection is about to occur in response to recognition of one or more gestures indicative of an insulin injection, and then determine whether the predicted insulin injection is proper or improper for the patient 12 by comparing parameter data and other information for the insulin injection to established criteria for a proper insulin injection. The parameter data and other information can be indicative of an amount or type of insulin dose.

[0079] The established criteria can be communicated by a network server of a cloud service that controls the injection device 30, the patient device 24, or any other compatible device, and / or input by a medical professional using the injection device 30, the patient device 24, or any other compatible device as input. The established criteria can include suggested and / or effective values / classifications for various insulin injection parameters, including insulin dose, insulin type, and / or injection schedule (or alternatively, time intervals between injections). Examples of criteria for a proper insulin injection include one or more of: a number of clicks (or rotations of an insulin pen dial) used to set an insulin dose, an amount of time elapsed between insulin injections, whether the user ate between insulin injections, whether to inject basal insulin to the patient based on a time of day, or whether to inject a bolus insulin to the patient based on a time of day. Some techniques employ additional and / or different parameters, including injection site / region, trajectory, etc. If the parameter data for the insulin injection does not meet the criteria for a proper insulin injection, the one or more processors 28 can output an alert notifying the patient 12 that an improper insulin injection will occur for display on an electronic display.

[0080] In some examples, the one or more processors 28 can construct a data model configured to distinguish between user activities, such as user activities of injecting insulin and user activities of eating. In an initial learning phase, the one or more processors 28 can generate a data model for identifying any of the user activities mentioned in the present disclosure by training the data model with user activity data and injection device data. In some examples, the one or more processors 28 can employ the trained data model to predict whether the patient 12 has eaten any food based on characteristics derived from movement characteristics, posture characteristics, and other contextual information as features. In some examples, the one or more processors 28 can employ the trained data model to determine whether the patient 12 is using basal insulin or a bolus insulin is predicted.

[0081] Figure 2 FIG. 1 is a block diagram illustrating another example system for delivering or guiding therapy doses according to one or more examples described in the present disclosure. Figure 2 System 10B is illustrated that is similar to system 10A Figure 1 However, in system 10B, the patient 12 can not have an insulin pump 14. Rather, the patient 12 can utilize a manual injection device (e.g., an insulin pen or a syringe) to deliver insulin. For example, rather than the insulin pump 14 automatically delivering insulin, the patient 12 (or possibly a caregiver of the patient 12) can fill a syringe with insulin or set a dose in an insulin pen and inject himself or herself.

[0082] System 10B implementing the example techniques and apparatuses described herein protects the patient 12 from injecting himself or herself with an improper amount and / or type of insulin at an improper time. To achieve this protection, the one or more processors 28 can compare information indicative of the current time or the set amount and / or type of the pending insulin injection to criteria for proper insulin injections, and if the comparison indicates that at least one of the criteria is not met, employ a technique to stop (or delay) the pending insulin injection and / or modify the set amount and / or type of insulin. As a result, the one or more processors 28 prevent the patient from being injected with an incorrect amount and / or type of insulin and / or at an incorrect time. The consequences of improper insulin injections can range from mild discomfort to a serious decline in the patient's health. For example, if not enough time has passed between a previous insulin injection and a current insulin injection, the patient can have completely forgotten about the previous insulin injection. If the patient 12 has not eaten any food between the injections, the patient can eventually experience low glucose levels.

[0083] In system 10B, one or more processors 28 capture sensor data (i.e., user activity data) provided by one or more inertial measurement units (e.g., in wearable device 22) and indicative of various user activities. At least a portion of this user activity data captures characteristics of user movement and / or user posture while holding any injection device; examples of such characteristics include user hand movement, user hand posture (e.g., positioning / orientation), etc. The user can be patient 12, a caregiver of patient 12, or any other provider of insulin injections for patient 12. As described herein, the captured user activity data can include all user activities and is not specific to user activities involving an insulin pen or syringe or another manual injection device. For at least this reason, the user activity data can include gestures that can be mistaken for gestures indicative of an insulin injection. For example, refilling a syringe and preparing / administering an insulin injection with the syringe can involve the same or similar gestures, and any user activity indicative of such a refilling event constitutes a marker that an insulin injection did not occur.

[0084] Additionally, user activity data can include inaccuracies resulting from, for example, limitations of one or more inertial measurement units. When an inertial measurement unit in wearable device 22 generates sensor data (e.g., accelerometer data), the data is typically raw or unrefined. User activity data can be a higher-level abstraction of the sensor data generated by one or more sensors. While accelerometer data can describe two positions in three-dimensional space and movement between the positions, captured user activity data can describe the same movement in a different space or a combination of two or more movements between positions in three-dimensional space. User activity data can describe a gesture or a portion thereof as a cohesive sequence of patient movements.

[0085] For any type of injection device, one or more processors 28 implementing example techniques can build and train a data model until the data model is able to distinguish gestures indicative of an insulin injection from other patient gestures. To illustrate, an example data model can use accelerometer data to define movement characteristics (e.g., vibration, acceleration, etc.), posture characteristics (e.g., positioning and orientation), and other characteristics of a posture that holds an injection device in a particular position and / or a particular orientation to administer a diabetes therapy. The particular position and / or particular orientation can be predetermined (e.g., by a device manufacturer) and / or learned over time. The particular position and / or particular orientation can be suggested by a patient caregiver and / or determined by a medical professional to be effective (e.g., most effective) for a diabetes therapy. Another detectable gesture includes setting an insulin dose for a manual injection device (e.g., by pumping insulin into a syringe barrel, turning a dial on an insulin pen, etc.). Other detectable user activity gestures corresponding to a manual insulin injection include a gesture that moves the injection device closer to the patient’s body, a gesture that returns the manual injection device to a safe location (e.g., in a medical waste disposal unit), a gesture that removes a bubble from a manual injection device (e.g., a syringe barrel), a gesture that refills the manual injection device with a subsequent insulin dose (e.g., a refill event), etc.

[0086] A given data model for gesture detection can define one or more detectable instances of an insulin injection as any combination of the above gestures. Some gestures are ranked higher than other gestures and are given priority. Some gestures are contemporaneous, occurring frequently when insulin is injected. Some gestures are related to possible influences on the effectiveness of a diabetes therapy administered to patient 12, like the above gesture that removes a bubble from a manual injection device. Although some example techniques and systems employ multiple sensors 20, a composite posture for delivering an insulin dose by a manual injection device can be detected using data provided by a single sensor 20 known as an inertial measurement unit (e.g., an accelerometer and a gyroscope). Gesture detection of an insulin injection as described herein is beneficial to patient 12 and results are immediate when any user activity occurs or is about to occur. Patient 12 is not burdened with complex setup and / or operational tasks. In some instances, patient 12 does not perform any activity other than the corresponding user activity for injecting an insulin dose, and one or more processors 28 (and / or hardware / software components of patient device 24) predict that an insulin injection is about to occur.

[0087] It can be beneficial to ensure that the proper amount and / or correct type of insulin is injected by patient 12 or a caregiver of patient 12 prior to the injection. One or more processors 28 can generate information indicating the amount of insulin and / or the type of insulin dose in an insulin injection that patient 12 or a caregiver of patient 12 is most likely preparing based on a corresponding gesture. One or more processors can compare the information indicating the amount or type of insulin dose to criteria for a proper insulin injection. As described herein, criteria for a proper insulin injection can specify recommendations for patient’s diabetes therapy including recommended insulin dose, insulin type, dosing regimen, whether enough time has passed between insulin injections, whether food has been consumed between insulin injections, whether patient is using basal insulin or a bolus insulin based on the time of day, etc. The criteria can further specify which insulin pen settings to activate to meet the above recommendations. If the criteria are not met, one or more processors can output an alert for patient 12 or a caregiver of patient 12 not to inject patient 12 or, more generally, to perform some modification to correct an improper aspect associated with the insulin injection or to improve the efficacy of the insulin injection.

[0088] To generate the information indicating the amount of insulin and / or the type of insulin dose in the above insulin injection, one or more processors 28 can utilize a data model to detect a corresponding gesture. One example corresponding gesture for setting the insulin dose and / or type can involve the number of clicks or the amount of rotation on a dial of an insulin pen. Another example corresponding gesture for setting the insulin dose and / or type is loading a cartridge into an insulin pen or similar injection device. One or more processors 28 improve the efficiency of detecting these gestures through device confirmation and / or patient confirmation. Another example corresponding gesture for setting the insulin dose and / or type in a syringe is drawing insulin into a syringe barrel by suction. Other contextual cues can (partially) identify the type of insulin, such as the time of day and / or location. For example, long-acting insulin can typically be delivered first in the morning or before bed in the evening, while fast-acting insulin can typically be delivered before meals. Time and location cues can discern that long-acting insulin or fast-acting insulin is more likely and appropriate for respective time periods.

[0089] Processing power and other resources can be consumed in training and / or applying data models to convert user activity data into detectable gestures. While one or more processors 28 can utilize a trained data model to distinguish an insulin injection from other user activities described in user activity data, even with training, structural and functional limitations can prevent a data model from rendering accurate predictions. Other limitations associated with an inertial measurement unit in a wearable device 22 can further reduce the utility of user activity data. While an example wearable device 22 (e.g., a smartwatch) that houses one or more inertial measurement units can capture user activity data indicative of wrist and hand movements, these movements can not accurately reflect movements of a manual injection device for a variety of reasons. A patient can move, position, and / or orient a manual injection device without creating a significant amount of user activity data. A wearable device 22 can be on a different hand than the hand holding a manual injection device. As another limitation, a caregiver can administer an injection, resulting in no meaningful user activity data. In the data captured by a wearable device, there is no mechanism to explicitly identify a patient or caregiver utilizing a manual injection device or any other injection device.

[0090] To minimize the above inaccuracies in user activity data or data models provided by a wearable device 22 and / or reduce resource requirements of a detection as much as possible, one or more processors 28 can use various data sets that describe a patient’s or caregiver’s utilization of a manual injection device, an injection device 30, or any other insulin delivery device to confirm a detected gesture (e.g., a confidence level). These data sets can be referred to herein as injection device data, examples of which include user input data provided through an input mechanism and / or sensor data provided by a patient device 24, a network device of a cloud service, the insulin delivery device itself, and / or an external device of a patient 12. In fact, confirmation of any detected gesture mitigates the above limitations of a wearable device 22.

[0091] When a detected gesture can identify (e.g., predict) an insulin injection, some example devices, systems, and techniques of the present disclosure further benefit a patient 12 by indicating, in response to a possible identification (e.g., prediction) of an insulin injection, example injection device data that is at least one of a device confirmation or a patient confirmation. In a patient confirmation, a patient 12 is presented with a query about whether an insulin injection is about to occur or is occurring, and through user input, the patient 12 confirms or denies a pending or recently occurring insulin injection through any injection device embodiment that includes any manual injection device. In a device confirmation, one or more processors 28 utilize accurate data that describes an injection (e.g., user operation) of a manual injection device to confirm or reject a prediction. Figure 3

[0092] For​Figure 2 With respect to manual injection devices, one or more processors 28 can be configured to confirm or refute a prediction of an insulin injection through injection device data. Because manual injection devices can not be equipped with any sensing technology to assist in confirming or refuting such predictions, one or more processors 28 utilize another source to access injection device data. With respect to some manual injection devices, one or more processors 28 can query injection device data from patient device 24 or another device (e.g., a smart cap attached to an insulin pen, a smart phone, etc.). For example, a smart phone can incorporate sensing technology (e.g., optical or electro-optical sensors, a combination of optical sensors and LEDs, accelerometers, ambient light sensors, magnetometers, gyroscopes, cameras, etc.) to record example injection device data for recent manual injections that have occurred.

[0093] One or more processors 28 can establish various criteria (e.g., standards, thresholds, conditions, etc.) to confirm an insulin injection prediction based on user activity data provided by wearable device 22. Using a set of example criteria to confirm (or refute) any given prediction, one or more processors 28 can utilize injection device data (a more accurate source of information) as evidence to corroborate the initial gesture detection based on user activity data provided by wearable device 22. Synthesizing injection device data with user activity data provides a complete picture of a patient’s activity when utilizing any injection device. One set of example criteria can only require the above-mentioned vibration data, while another set of example criteria can require both vibration data. Additionally (or as an alternative), one or more processors 28 can compare user activity data to injection device data for various indicia that an insulin injection has not occurred, and if enough indicia are identified in the comparison, then the opposite prediction is refuted. It should be noted that machine learning concepts are incorporated into gesture detection as described herein; for at least this reason, the devices, systems, and techniques of the present disclosure can utilize established learning mechanisms to more accurately predict when an insulin injection is about to occur or is occurring, regardless of whether one or more processors 28 confirm or refute a prediction of a manual insulin injection occurrence. Some example learning mechanisms adjust a data model by, for example, adjusting insulin injection definitions by using different gestures, by adjusting feature values or defining different features for gestures, by adjusting a prediction process (e.g., a mathematical function, a probability distribution, etc.) of the data model, by adjusting a metric of the data model or a method for measuring user activity from data provided by wearable device 22 (e.g., accelerometer data), and / or by adjusting the data model in another manner.

[0094] Figure 3 is a block diagram illustrating another example system for delivering or guiding a therapy dose in accordance with one or more examples described in this disclosure. Figure 3 is illustrated similar toFigure 1 system 10A and Figure 2 system 10B. In system 10C, patient 12 can be without insulin pump 14. Rather, patient 12 can utilize injection device 30 to deliver insulin. For example, instead of insulin pump 14 automatically delivering insulin, patient 12 (or possibly a caregiver of patient 12) can utilize injection device 30 to inject himself or herself.

[0095] Injection device 30 can be different from a syringe in that injection device 30 can be a device that can communicate with patient device 24 and / or other devices in system 10C. Also, injection device 30 can contain a reservoir and can be able to deliver as much insulin as indicated by information indicating how much therapy dose is to be delivered. For example, injection device 30 can automatically set an amount of insulin based on information received from patient device 24. In some examples, injection device 30 can be similar to insulin pump 14, but not worn by patient 12. One example of injection device 30 is an insulin pen, which is sometimes also referred to as a smart insulin pen. Another example of injection device 30 can be an insulin pen with a smart cap, where the smart cap can be used to set a particular insulin dose.

[0096] The above examples describe insulin pump 14, a syringe, and injection device 30 as example ways of delivering insulin. In this disclosure, the term "insulin delivery device" can generally refer to any device used to deliver insulin. Examples of insulin delivery devices include insulin pump 14, a syringe, and injection device 30. As described, a syringe can be a device used to inject insulin, but not necessarily able to communicate or dose a particular amount of insulin. However, injection device 30 can be a device used to inject insulin, and can be able to communicate with other devices (e.g., through Bluetooth, BLE, and / or Wi-Fi) or can be able to dose a particular amount of insulin. Injection device 30 can be a powered (e.g., battery-powered) device, and a syringe can be a device that does not require power.

[0097] To provide gesture-based diabetes therapy control using an insulin delivery device (e.g., insulin pump 14, a syringe, and / or injection device 30), example techniques and systems implement a data model that defines certain user activities as gestures; examples of defined gestures include gesture groups (e.g., sequences) that, when combined, form example insulin injections of the insulin delivery device. One or more processors 28 of patient device 24 can detect data indicative of an insulin injection by comparing user (e.g., patient) movements and / or postures of defined insulin injection gestures in an example data model implementation to patient movements and / or patient postures corresponding to the gestures as patient 12 holds the insulin delivery device.

[0098] To detect gestures when the patient 12 controls the injection device 30, some example devices, systems, and techniques in this disclosure implement the same or similar data models to detect gestures when the patient 12 controls a manual injection device. One reason is that user activity data generated to record gestures of a user (e.g., the patient 12 or a caregiver of the patient 12) while holding a manual injection device can be similar to user activity data generated to record gestures of a user (e.g., the patient 12 or a caregiver of the patient 12) while holding the injection device 30. Even if the user activity data is somewhat different (e.g., in a different format), substantially the same sensors are used to record movement characteristics and / or posture characteristics of the patient’s arm and hand while utilizing (e.g., holding and operating) the injection device 30. While there can be differences in how the patient 12 performs gestures in the injection device 30 to set an insulin dose and / or type as opposed to a syringe, these differences represent movement characteristics that can be scripted as definitions for particular gestures for the injection device 30. For example, instead of loading a syringe barrel with insulin, the patient 12 operates dials and other controls on the injection device 30 to set a next insulin dose and / or type. For at least these reasons, the one or more processors 28 of the patient device 24 can apply substantially the same data models to detect postures (e.g., gestures) indicative of injecting insulin with the injection device 30 in user activity data generated from data provided by one or more (external) sensors in an external device such as the wearable device 22.

[0099] Because the same external device, wearable device 22, operates as a source of user activity data for both the manual injection device and the example of injection device 30, there can be the same limitations in predicting insulin injections by injection device 30. To mitigate and / or eliminate some or all of these limitations, one or more processors 28 of patient device 24 can execute a mechanism configured to confirm or deny a prediction that an insulin injection is about to occur or is occurring. In some examples, one or more processors 28 of patient device 24 provide a device confirmation and / or a patient confirmation. In one example, one or more processors 28 of patient device 24 can communicate a request to injection device 30 to confirm or deny a prediction of an insulin injection by way of a device confirmation and / or a patient confirmation. In turn, injection device 30 communicates a response indicating a confirmation or denial based on internal injection device data and / or input data from patient 12. If injection device 30 has been set to inject patient 12 or has injected patient 12 and recorded the injection, injection device 30 responds to the request with a positive device confirmation. On the other hand, if injection device 30 has not been set to inject patient 12 or has recently injected patient 12, injection device 30 responds to the request with a negative device denial. Injection device 30 can output a query to patient 12 as to whether patient 12 is about to be injected with insulin and, based on input data provided by the patient and indicative of the patient's 12 response, injection device 30 can respond to patient device 24 with a positive patient confirmation or a negative patient denial (e.g., a denial). In an example device confirmation, one or more processors 28 of patient device 24 communicate a query to a communication component of injection device 30 for medical record data containing a record of any recent insulin injection. If the timestamp of the recent insulin injection matches the timestamp of the prediction that an insulin injection will occur, one or more processors 28 of patient device 24 can determine that injection device 30 is confirming the prediction of the occurrence of an insulin injection. In yet another example of a device confirmation, one or more processors 28 of patient device 24 can access an application programming interface provided by injection device 30 and invoke an interface function configured to provide a confirmation or denial of a prediction of an insulin injection.

[0100] The above examples describe insulin pump 14, syringe, and injection device 30 as example ways of delivering insulin. In this disclosure, the term "insulin delivery device" can generally refer to a device for delivering insulin. Examples of insulin delivery devices include insulin pump 14, syringe, and injection device 30. As described, a syringe can be a device for injecting insulin, but not necessarily capable of communicating or dosing a specific amount of insulin. However, injection device 30 can be a device for injecting insulin, and can be capable of communicating with other devices or can be capable of dosing a specific amount of insulin. Injection device 30 can be a powered (e.g., battery powered) device, and a syringe can be a device that does not require power.

[0101] Figure 4 is a block diagram illustrating an example of a patient device in accordance with one or more examples described in this disclosure. While patient device 24 can generally be described as a handheld computing device, patient device 24 can be, for example, a laptop, a cellular phone, or a workstation. In some examples, patient device 24 can be a mobile device such as a smartphone or a tablet computer. In such examples, patient device 24 can execute an application that allows patient device 24 to perform the example techniques described in this disclosure. In some examples, patient device 24 can be a dedicated controller for communicating with insulin pump 14, injection device 30, or a smart cap for a manual injection device.

[0102] While examples are described with one patient device 24, in some examples, patient device 24 can be a combination of different devices (e.g., a mobile device and a controller). For example, a mobile device can provide access to one or more processors 28 of cloud 26 over Wi-Fi or a carrier network, and a controller can provide access to insulin pump 14. In such examples, the mobile device and the controller can communicate with each other over Bluetooth or BLE. Various combinations of mobile devices and controllers that together form patient device 24 are possible, and the example techniques should not be considered limited to any one particular configuration.

[0103] As Figure 4 illustrated in FIG. 1, patient device 24 can include processing circuitry 32, memory 34, user interface 36, telemetry circuitry 38, and power supply 39. Memory 34 can store program instructions that, when executed by processing circuitry 32, cause processing circuitry 32 to provide the functionality attributed to patient device 24 throughout this disclosure.

[0104] In some examples, the memory 34 of the patient device 24 can store a plurality of parameters, such as an amount of insulin to be delivered, a target glucose level, a delivery time, etc. The processing circuitry 32 can output the parameters stored in the memory 34 to the insulin pump 14 or the injection device 30, e.g., via the telemetry circuitry 38, to deliver insulin to the patient 12. In some examples, the processing circuitry 32 can execute a notification application stored in the memory 34 that outputs notifications to the patient 12 via the user interface 36, such as a notification to take insulin, an amount of insulin, and a time to take the insulin.

[0105] The memory 34 can include any volatile, nonvolatile, fixed, removable, magnetic, optical, or electrical media, such as RAM, ROM, hard disks, removable magnetic disks, NVRAM, EEPROM, flash memory, and the like. The processing circuitry 32 can be implemented with one or more microprocessors, DSPs, ASICs, FPGAs, programmable logic circuitry, and the like, and the functionality of the processing circuitry 32 as described herein can be

[0106] The user interface 36 can include buttons or a keypad, lights, a speaker for voice commands, and a display, such as a liquid crystal (LCD). In some examples, the display can be a touch screen. As discussed in the present disclosure, the processing circuitry 32 can present and receive information related to therapy via the user interface 36. For example, the processing circuitry 32 can receive patient input via the user interface 36. The patient input can be entered, for example, by pressing buttons or a keypad, entering text, or selecting icons from a touch screen. The patient input can be information indicative of food eaten by the patient 12, such as whether the patient 12 used insulin (e.g., via a syringe or the injection device 30) for an initial learning phase, and other such information.

[0107] Telemetry circuitry 38 includes any suitable hardware, firmware, software, or any combination thereof for communicating with another device, such as cloud 26, insulin pump 14 or infusion device 30 (if applicable), wearable device 22, and sensor 20. Telemetry circuitry 38 can receive communications with the aid of an antenna, which can be internal and / or external to patient device 24. Telemetry circuitry 38 can also be configured to communicate with another computing device through wireless communication techniques, or directly through a wired connection. Examples of local wireless communication techniques that can be employed to facilitate communication between patient device 24 and another computing device include RF communication according to the IEEE 802.11, Bluetooth, or BLE set of specifications, infrared communication, such as according to an IrDA standard, or other standard or proprietary telemetry protocols. Telemetry circuitry 38 can also provide connectivity to a carrier network for accessing cloud 26. In this manner, other devices can be able to communicate with patient device 24.

[0108] Power source 39 delivers operating power to the components of patient device 24. In some examples, power source 39 can include a battery, such as a rechargeable or non-rechargeable battery. Non-rechargeable batteries can be selected to last for several years, while rechargeable batteries can be inductively charged from an external device, for example, on a daily or weekly basis. Recharging of a rechargeable battery can be accomplished through the use of an alternating current (AC) outlet or through a proximal inductive interaction between an external charger and an inductive charging coil within patient device 24.

[0109] It can be beneficial to ensure that the proper amount and / or correct type of insulin is injected by patient 12 or a caregiver of patient 12 before an insulin injection. As described herein, there are many opportunities for a user of an insulin delivery device to administer an improper insulin injection. One or more processors of processing circuitry 32 or one or more processors 28 can access user activity data generated by one or more inertial measurement units and then generate information indicating an amount of insulin and / or a type of insulin dose in an insulin injection that patient 12 or a caregiver of patient 12 is most likely preparing based on a corresponding gesture based on the user activity data. One or more processors of processing circuitry 32 (or one or more processors 28) can identify the corresponding gesture based on movement characteristics, posture characteristics, and other instances in the user activity data. Processing circuitry 32 (or one or more processors 28) can compare the information indicating the amount or type of insulin dose to criteria for a proper insulin injection. As described herein, the criteria for a proper insulin injection can specify recommendations for patient’s diabetes therapy including a recommended insulin dose, a type of insulin, a dosing regimen, whether enough time has passed between insulin injections, whether food has been consumed between insulin injections, whether patient is to use basal insulin or a bolus insulin based on a time of day, etc. The criteria can further specify which insulin pen settings are to be activated to meet the above recommendations. The criteria can be determined by patient device 24 or cloud 26 by patient, a caregiver, or any medical professional with authority. The purpose of comparing the information for the time, amount, and / or type of an impending insulin injection to the criteria for a proper insulin injection is to prevent patient from being injected with an incorrect amount and / or type of insulin and / or at an incorrect time. The consequences of an improper insulin injection can range from mild discomfort to a serious decline in patient’s health. For example, if not enough time has passed between a previous insulin injection and a current insulin injection, patient can have completely forgotten about the previous insulin injection. If patient 12 has not consumed any food between injections, patient can eventually experience low glucose levels.

[0110] If the criteria are not met, processing circuitry 32 can output an alert so that patient 12 or a caregiver of patient 12 does not inject patient 12 or, more generally, performs some modification to correct an impropriety associated with the insulin injection or to improve the efficacy of the insulin injection. In some instances, one or more processors 28 communicate instructions to patient device 28 that direct patient device 28 to output the alert.

[0111] Figure 5is a block diagram illustrating an example of a wearable device in accordance with one or more examples described in this disclosure. As illustrated, the wearable device 22 includes processing circuitry 40, memory 42, user interface 44, telemetry circuitry 46, power source 48, and inertial measurement unit 50. The processing circuitry 40, memory 42, user interface 44, telemetry circuitry 46, and power source 48 can be similar to the processing circuitry 32, memory 34, user interface 36, telemetry circuitry 38, and power source 39 of FIG. 1, respectively. Figure 3

[0112] The inertial measurement unit 50 can include a gyroscope and / or various components for determining the pitch- roll-yaw and x-y-z coordinates of the wearable device 22. In some examples, the inertial measurement unit 50 can be considered a six-axis inertial measurement unit. For example, the inertial measurement unit 50 can couple a 3-axis accelerometer with a 3-axis gyroscope. The accelerometer can measure linear acceleration, while the gyroscope can measure rotational motion. The processing circuitry 40 can be configured to determine one or more movement characteristics based on values from the inertial measurement unit 50. For example, the processing circuitry 40 can determine whether the patient 12 is moving his or her arm up, down, left, right, forward, backward, or some combination based on values from the inertial measurement unit 50, including values related to frequency, amplitude, trajectory, positioning, velocity, acceleration, and / or movement patterns. The processing circuitry 40 can determine an orientation of the patient’s 12 arm, such as whether the back or front of the hand is facing the patient 12 or whether the side of the hand is facing the patient 12, such that the thumb is facing the patient 12 and the index finger side is visible, based on values from the inertial measurement unit 50.

[0113] As one example, when the patient 12 is eating with chopsticks, the patient 12 can orient his or her wrist in a particular manner, which can be different if the patient 12 is eating a sandwich. The frequency with which the patient 12 moves his or her arm from the positioning in which he or she takes the food to the positioning in which he or she puts the food in the mouth can be different for different types of food. For example, the frequency and movement pattern of eating with a fork can be different from eating with a spoon or a knife and fork, which can be different from eating with the hands, such as a sandwich or pizza. For all of these different food items, the movement characteristics can be different, and the output values from the inertial measurement unit 50 can be different. However, for all of the movement characteristics, one or more processors, including the processing circuitry 40 in some examples, can be configured to determine that the patient 12 is eating.

[0114] ​One or more inertial measurement units 50 can output such information (e.g., pitch- roll-yaw and x-y-z coordinates) of the arm of the patient 12 to the processing circuitry 40. The telemetry circuitry 46 can then output the information from the processing circuitry 40 to the patient device 24. The patient device 24 can forward the information to the one or more processors 28, which can use the information to determine whether the patient 12 is eating (e.g., whether a meal event is occurring).

[0115] To enable detection of gestures corresponding to insulin injection by the patient 12, the inertial measurement units 50 can generate various data (e.g., pitch-roll-yaw and xyz coordinates) indicative of the activities of the patient 12, including the patient’s utilization of the injection device 30, a manual injection device, or any other device configured to deliver diabetes therapy. The data (e.g., accelerometer data) generated by the inertial measurement units 50 can be processed into user activity data indicative of patient movements and / or patient gestures corresponding to the patient’s utilization of the injection device 30. By comparing the user activity data to data models configured to define gestures corresponding to insulin injection, the one or more processors 28 of the patient device 24 can detect one or more of these gestures, and in response to the detection, determine whether an occurrence of an insulin injection is predicted.

[0116] If the patient 12 is using a manual injection device, additional sensors provide manual injection data to confirm the prediction. If the patient 12 is using the injection device 30, instead of having to use additional sensors and other hardware / software components to acquire manual injection device data, the one or more processors 28 establish a communication channel with the injection device 30 and receive (e.g., by request) data describing operational details of one or more historical insulin injections. In this way, a prediction of an upcoming or ongoing insulin injection can be confirmed or refuted by injection device data of the manual injection device or the injection device 30.

[0117] While the above example techniques can be beneficial for patient 12 to receive insulin at the right time, the present disclosure describes example techniques to further proactively control the delivery of insulin to patient 12. Specifically, the present disclosure describes example techniques for controlling the delivery of therapy to a diabetic patient, where the therapy involves timely injection of an effective amount of the right type of insulin. To implement these techniques, one or more processors 28 can determine whether an upcoming insulin injection is appropriate or inappropriate for patient 12 by comparing various injection parameters to established criteria. As described above, the established criteria can include recommended and / or effective values / classifications for injection parameters including insulin dosage, insulin type, and / or injection schedule / time (or alternatively, time interval between injections). Some techniques employ additional and / or different parameters including injection site / region, trajectory, etc.

[0118] Once confirmed and deemed appropriate, record data for the insulin injection is stored and can include the time of injection. Ensuring timely injection of insulin prevents low glucose levels in the blood of patient 12. The same data model is continuously applied to user activity data over time, and when a subsequent insulin injection is detected, the time of the detection is compared to the recorded time of the previous injection. If the time difference is below the recommended time interval between appropriate insulin injections (i.e., too early), patient device 24 outputs an alert to warn patient 12 with text and / or audio output. For example, if patient 12 is preparing for an insulin injection, but the amount of time that has elapsed since the previous insulin injection is insufficient, patient 12 can have forgotten the previous insulin injection, and if patient 12 is not prevented from receiving the dose too early, excess insulin can build up in the bloodstream of patient 12, causing cells in patient 12 to release less glucose from the blood and / or liver of patient 12 (i.e., hypoglycemia) as they absorb too much glucose. Both of these effects are typical consequences of an inappropriate insulin injection.

[0119] Depending on the context, the meal event can or can not result in a low glucose level in the blood of the patient 12. If a meal is not detected between insulin injections, the patient 12 can end up with a low glucose level even if the subsequent insulin injection is timely. This correlation holds in some cases where the patient 12 does not receive a subsequent insulin injection at all. Continuously applying the above-described data model to user activity data streamed from the wearable device 22 can further ensure that the patient 12 eats something before a subsequent insulin injection. If the one or more processors 28 (and / or one or more processors of the patient device 24) detect a meal event and a subsequent insulin injection at the appropriate respective times based on user activity data provided by the wearable device 22, the one or more processors 28 can generate record data confirming the diabetes therapy and then store the record data as part of the patient 12’s medical history (i.e., medical record). On the other hand, if the one or more processors 28 (and / or one or more processors of the patient device 24) fail to detect a meal event before detecting a subsequent insulin injection after monitoring user activity data provided by the wearable device 22, the patient device 24 can output an alert notifying the patient 12 (or a caregiver of the patient 12) of potential impropriety in the injection. In some instances, the patient device 24 outputs data requesting that the patient 12 not perform the subsequent insulin injection at this time and / or eat before the injection. The patient device 24 can output data indicating a query of the patient 12 to answer whether the patient 12 ate between injections.

[0120] An example reason for injecting fast-acting insulin (the first insulin type) can be to compensate for carbohydrates or to correct for hyperglycemia. In correcting for hyperglycemia, a subsequent insulin dose can account for insulin-on-board from a previous injection. If the dose is given when the blood glucose of the patient 12 is normal and the one or more processors 28 fail to detect a meal within a certain time period (e.g., 15 minutes), the one or more processors 28 can output an alert to remind the patient 12 to eat something to account for the dose of insulin. If the dose is given to correct for hyperglycemia and the dose is given after a recent similar dose, the one or more processors 28 can output an alert notifying the patient 12 (and / or a caregiver of the patient 12) that the hyperglycemia can be overcompensated. The alert can further suggest that the caregiver needs to monitor the blood glucose of the patient 12 and / or that the patient 12 can need to eat something to prevent hypoglycemia.

[0121] Doses of long-acting insulin (the second insulin type) are typically delivered once per day; however, it is possible for the patient 12 to receive two long-acting doses in a short period of time or at different times of the day (e.g., a first dose in the morning and a second dose in the evening). In some examples, the one or more processors 28 can output an alert warning the patient 12 prior to administering a second subsequent dose and have enough time to prevent the dose. In other examples, if the one or more processors 28 detect an appropriate injection followed by a subsequent injection of long-acting insulin, the one or more processors 28 can output an alert notifying the patient 12 to monitor their blood glucose for the next 12-24 hours to prevent possible hypoglycemia.

[0122] In fact, while these alerts can prevent the patient 12 from being affected by the consequences of injecting insulin without a proper intervention of a meal event, some examples have the one or more processors 28 (and / or the one or more processors of the patient device 24) control the injection of the patient 12 more. For example, if the injection device 30 is communicably coupled to the one or more processors 28 (and / or the one or more processors of the patient device 24), the one or more processors 28 (and / or the one or more processors of the patient device 24) can transmit instructions to the injection device 30 to stop (or delay) a subsequent insulin injection without first detecting a meal event. If no meal event is detected and the patient 12 is preparing for a subsequent insulin injection, the one or more processors 28 (and / or the one or more processors of the patient device 24) can issue a command to lock the injection device 30 in a non-operational state. This can be performed automatically in response to detecting a subsequent insulin injection without a meal event. In other examples, the injection device 30 can automatically terminate operation of the patient 12 after determining that the patient 12 is likely to not have eaten anything before attempting a subsequent insulin injection.

[0123] Figure 6 FIG. 1 is a flow diagram illustrating example operational methods in accordance with one or more examples described in this disclosure. Figure 6 The one or more processors are described with respect to FIG. 1. The one or more processors can be the one or more processors 28, the one or more processors of the patient device 24 (e.g., the processing circuitry 32), the one or more processors of the wearable device 22 (e.g., the processing circuitry 40), the one or more processors of the insulin pump 14 (if applicable), or any combination thereof.

[0124] The one or more processors can identify at least one gesture indicative of preparing an insulin injection with an injection device based on the user activity data (60). The identification of the at least one gesture implies that an insulin injection is (recently) occurring, about to occur, or occurring. For example, the one or more processors can be a first set of one or more processors (e.g., one or more processors 28 on one or more servers of the cloud 26) that receive data indicative of user activity, including data indicative of gestures made by the patient 12 or a caregiver of the patient 12 in preparing an insulin injection with an injection device (e.g., the injection device 30). An example insulin injection can consist of one or more gestures, where each gesture is defined according to a data model configured to distinguish an insulin injection from other user activities (e.g., user activity or caregiver activity). In general, the present disclosure contemplates that user activity includes any activity of a user of an injection device. In one example, the data model includes a definition of each of a plurality of gestures (e.g., user activity gestures), and a definition of each (detectable) example of an insulin injection by the patient 12 as a combination of gestures. The data model can define an example insulin injection to include only one gesture.

[0125] Based on the at least one identified gesture, the one or more processors can generate information indicative of at least one of an amount or a type of an insulin dose in an insulin injection by the injection device (62). For example, the inertial measurement unit 50 within the wearable device 22 provides vibration data associated with movement of a dial and other instruments used to set a dose and / or a type to the one or more processors 28. The one or more processors can compare the generated information to criteria for an appropriate insulin injection (64). The criteria for an appropriate insulin injection includes any combination of: a number of clicks to set the amount of the insulin dose, an amount of time elapsed between insulin injections, whether the user ate between insulin injections, whether to inject basal insulin to the patient based on a time of day or whether to inject a bolus insulin to the patient based on a time of day. In some examples, the one or more processors determine whether the user ate based on user input and / or based on gesture data (e.g., as described above). The purpose of comparing information to criteria for a time, an amount, and / or a type set for a pending insulin injection is to prevent the patient from being injected with an incorrect amount and / or type of insulin and / or at an incorrect time. Consequences of an improper insulin injection can range from mild discomfort to a serious decline in the patient’s health. For example, if not enough time has elapsed between a previous insulin injection and a current insulin injection, the patient can have completely forgotten the previous insulin injection. If the patient 12 has not eaten any food between injections, the patient can eventually experience low glucose levels.

[0126] The one or more processors can output information indicating whether the criteria are met based on the comparison (66). In response to determining that the criteria for an appropriate insulin injection are not met, the one or more processors can output an alert comprising at least one of text, graphics, sound, or video operable to notify the user that the insulin injection is not appropriate. The present disclosure contemplates a variety of situations in which the criteria for an appropriate insulin injection are not met: the patient 12 receives an insulin injection in the following situations: 1) not enough time has passed since the previous injection; 2) not enough food in the body; 3) not an effective insulin dose (e.g., amount); and / or 4) the type of insulin in the dose is incorrect, among others. By way of example, an injection of fast-acting insulin (a type of insulin) can compensate for carbohydrates and / or correct hyperglycemia, but when the insulin dose of fast-acting insulin is under-compensated (e.g., too low of an amount) or over-compensated (e.g., too high of an amount), the one or more processors can output an alert notifying the user of the under-compensation or over-compensation, respectively. For example, if the one or more processors fail to detect a meal within a certain period of time (e.g., fifteen minutes), the one or more processors can output an alert to remind the patient 12 to eat something, e.g., to address the over-compensation of insulin. An alternative alert can suggest a subsequent injection of insulin to correct the under-compensation. The alert can be communicated to a device of a caregiver, e.g., prompting the caregiver to monitor the patient 12 for blood glucose, carbohydrates, and / or food intake.

[0127] In some examples, in response to confirmation of an insulin injection based on injection device data (e.g., device confirmation), the one or more processors can generate at least one of: (1) data recording the insulin injection for storage in patient medical data; (2) data indicating insulin injection recognition for display on an electronic display; or (3) data indicating an inappropriate insulin injection compared to criteria for an appropriate insulin injection for display on an electronic display. The injection device data can be received from and communicated by a device communicably coupled to the injection device (e.g., a smart cap for any insulin pen), a device (e.g., a smart phone) having a sensor (e.g., an optical sensor) for sensing the injection device (e.g., a syringe), or the injection device itself.

[0128] The one or more processors can process input data from the patient 12 indicating patient confirmation or patient denial. In some examples, the patient 12 communicates the input data as a response to a query submitted over a communication channel with the patient device. The patient 12 can receive the query as content presented on an electronic display of a smart device or on the injection device. In response to the patient denying the insulin injection, the one or more processors can execute a learning technique to adjust the data model. In some examples, the learning technique adjusts the data model to more accurately predict insulin injections from gestures of the patient 12 during operation of the injection device.

[0129] In some examples, the one or more processors can determine a time of a subsequent insulin injection, determine whether the user is attempting to inject insulin using the injection device based on movement detected by the wearable device prior to the time of the subsequent insulin injection, and output data that presents an alert to the user that the user has injected insulin based on a determination that the patient attempted to inject insulin using the injection device prior to the time of the subsequent insulin injection.

[0130] Figure 7A and 7B is a flowchart illustrating another example method of operation in accordance with one or more examples described in this disclosure. Similar to Figure 6 , Figure 7A and 7B are described with respect to one or more processors. The one or more processors can be the one or more processors 28, one or more processors of the patient device 24 (e.g., processing circuitry 32), one or more processors of the wearable device 22 (e.g., processing circuitry 40), one or more processors of the insulin pump 14 (if applicable), or any combination thereof.

[0131] As Figure 7A illustrated, the one or more processors can predict (e.g., determine) whether an insulin injection is about to occur or is occurring, for example, by identifying one or more gestures indicative of preparing an insulin injection with the injection device based on user activity data. For example, the one or more processors can determine whether an insulin injection is about to occur or is occurring based on a data model for the patient 12, where the data model is configured to distinguish insulin injections from other user activities (e.g., patient activities and / or caregiver activities). An example insulin injection can consist of multiple gestures, where each gesture is defined according to a data model configured to distinguish insulin injections from other user activities. In one example, the data model includes a definition of each of a plurality of gestures (e.g., user activity gestures), and a definition of each (detectable) example of an insulin injection by the patient 12 as a combination of gestures. The data model can define an example insulin injection to include only one gesture. If the one or more processors determine that an insulin injection is not going to occur (i.e., does not occur), the user activity can not change, and the patient 12 can continue other non-insulin injection gestures. As Figure 7A illustrated, while the gestures are made immediately before and during delivery of insulin to the patient 12 (e.g., basal insulin (e.g., baseline therapy)), the one or more processors can continuously check the user activity data to identify the defined gestures corresponding to an example insulin injection and determine (e.g., predict) that an insulin injection is about to occur or is occurring.

[0132] AsFigure 7A Further shown, the one or more processors can detect (e.g., determine) whether a gesture component for setting a dose, such as a gesture for setting a dose of insulin, is about to occur or is occurring (70). For example, the one or more processors can determine whether any gesture containing the above-mentioned gesture components for setting a dose of insulin is about to occur or is occurring based on user activity data indicative of one or more movement characteristics, posture characteristics (e.g., position and / or orientation), and other characteristics detected by the wearable device 22. These characteristics and other contextual information can be processed from sensor data generated by the wearable device 22. If the one or more processors detect that a gesture for setting a dose is about to occur or is occurring (70 is a branch), the one or more processors can determine a diabetes therapy dose and / or type (74). For example, the one or more processors can determine an amount and / or type of insulin dose based on data from an inertial measurement unit (e.g., vibration data). If either the insulin dose or the dose type deviates from a standard indicative of an appropriate amount, dose type, or time to deliver the insulin dose, such a determination is deferred until after prediction and at least until after device or patient confirmation. Such deferral conserves resources and provides sufficient time to alert the patient 12 and / or correct the insulin injection. If the one or more processors do not detect a gesture for setting a dose (70 is a no branch), the one or more processors can determine that an insulin injection is not ready or will not occur.

[0133] The one or more processors can detect (e.g., determine) whether a gesture for moving the injection device closer to the patient’s 12 body (another insulin injection gesture component) is about to occur or is occurring (76). Similar to other gestures, a gesture for moving the injection device closer to the patient’s 12 body can be detected if user activity data including patient movement characteristics and / or patient posture characteristics match a data model definition for the gesture. If the one or more processors fail to detect a gesture for moving the injection device closer to the patient’s 12 body in the user activity data (or other contextual data) (76 is a no branch), the one or more processors can wait for an alternative gesture or predict no injection after a suitable wait time (78). If the one or more processors detect that a gesture for moving the injection device closer to the patient’s 12 body is about to occur or is occurring (76 is a yes branch), the one or more processors can continue to detect (e.g., determine) whether a gesture for holding the injection device in a particular position / orientation (another gesture corresponding to an insulin injection) is about to occur or is occurring (80).

[0134] If the one or more processors do not detect the above-mentioned gesture of holding the injection device in the user activity data (or other contextual data) (NO branch of 80), the one or more processors can monitor the user activity data for an alternative gesture corresponding to an insulin injection for a wait time (82). In some examples, the wait time cannot exceed the amount of time taken to administer an insulin injection.

[0135] If the one or more processors do detect the gesture of holding the injection device in a particular position / orientation (YES branch of 80), the one or more processors monitor the user activity data for additional gestures and / or markers of nonoccurrence for a wait time (84). The one or more processors can identify the above-mentioned gesture corresponding to an insulin injection, but there can be user activity data indicating indicators, there can be user activity data indicating patient movement and / or patient gestures that contradict the prediction of an insulin injection. For example, the above-mentioned gesture can not correspond to an actual injection if there is no insulin in the injection device. If certain additional gestures are detected (e.g., a gesture of clearing air bubbles in the insulin), where these gestures also correspond to an insulin injection, the detection contradicts any identification of a marker of nonoccurrence.

[0136] The one or more processors can determine whether the predicted insulin injection is about to occur or is occurring based on the detection of the above-mentioned gesture as a component of a composite insulin injection gesture and any markers of nonoccurrence of the insulin injection gesture (86). If the one or more processors predict the occurrence of an insulin injection (YES branch of 86), the one or more processors enter into a state of monitoring the user activity data for a marker of insulin injection (90). The marker of insulin injection can be a marker of the injection of insulin into the patient 12, such as a marker of the injection of insulin into the injection device 30. Figure 7B If the one or more processors are unable to predict the occurrence of an insulin injection (NO branch of 86), the one or more processors detect a refill event or another user activity gesture in place of an insulin injection (88). For example, if sufficient markers of nonoccurrence are identified based on the user activity data, the one or more processors can determine that the above-mentioned detection of the insulin injection gesture component was a false positive. One example of sufficient markers of nonoccurrence is a refill event, where the injection device 30 is refilled with another insulin cartridge. Another example of sufficient markers of nonoccurrence is recent activity of the patient 12 without the injection device.

[0137] If the injection device 30 is not available, the patient 12 can utilize a syringe to deliver the partial therapy dose. For example, the one or more processors can output information of the insulin dose and / or type to the patient device 24, and the patient 12 can then use a syringe to deliver the partial therapy dose based on the information output by the patient device 24 through the user interface 36.

[0138] Turning to Figure 7BAfter the one or more processors predict the pending diabetes therapy in the form of an insulin injection, the one or more processors can confirm the prediction of the impending or ongoing insulin injection (86).

[0139] For example, the one or more processors can predict (e.g., determine) whether an insulin injection is impending or ongoing based on one or more movement characteristics, posture characteristics (e.g., position and / or orientation), and other characteristics detected by the wearable device 22. These characteristics and other contextual information can be acquired / captured (and then processed) into user activity data and compared to data models that define each posture corresponding to an example insulin injection.

[0140] Referring to Figure 7A If the one or more processors predict that an insulin injection is impending or ongoing, the one or more processors perform a mechanism for confirming or rejecting the prediction based on injection device data (90). If the prediction of an insulin injection occurring cannot be confirmed and / or is rejected (NO branch of 90), the one or more processors can perform a machine learning mechanism to adjust the data models to more accurately predict no injection (i.e., no occurrence) for the captured user activity data and general insulin injections (92). Additionally, the one or more processors can continue to monitor for insulin injections in the user activity data.

[0141] If the prediction of an insulin injection occurring is confirmed (YES branch of 90), the one or more processors can determine whether the criteria for a proper insulin injection are met (94). For example, the one or more processors can apply each criterion to the parameters of the predicted insulin injection to determine satisfaction or dissatisfaction. Such parameters include insulin dosage, insulin type, injection time, etc. Thus, the criteria include correct (e.g., suggested and / or valid) versions of the same parameters, and if the number of criteria met is insufficient, the one or more processors can identify that an improper insulin injection is impending or ongoing. These parameters can be determined from the user activity data used for the prediction and insulin injection data. The criteria can be predetermined or learned over time.

[0142] If the criteria are met (YES branch of 94), the one or more processors can store a record of the pending insulin injection in medical record data (96). Prior to storing the medical record data, the one or more processors can wait until the device or patient confirms.

[0143] If the criteria are not met (NO branch of 94), the one or more processors can determine whether to modify the pending inappropriate insulin injection (98). In some examples, if the one or more processors determine to modify the pending inappropriate insulin injection (YES branch of 98), the one or more processors can output various information to the patient device 24 and / or the injection device 30 on an electronic display of the patient device 24; one example of the output information includes information (e.g., content) describing modifications to correct the impropriety in the pending insulin injection and / or to improve efficacy (100). In some examples, the electronic display can be included in the user interface 36 of the patient device 24. The one or more processors can output a correct insulin dose and / or insulin dose type on the electronic display to attempt to modify the pending inappropriate insulin dose and / or type, respectively. In some examples, the one or more processors (e.g., in the patient device 24 or in a network server in the cloud 26) can output data to direct the injection device 30 to automatically correct the insulin dose and / or insulin dose type or to prevent the insulin injection from occurring. The one or more processors can output a suggested and / or effective orientation / position to hold the injection device 30 or a manual injection device prior to administering the insulin.

[0144] As another example, the one or more processors can output information to be followed for the patient 12 or a caregiver of the patient 12, where the output information can include a set of instructions for properly administering a diabetes therapy to the patient. The set of instructions can indicate a correct insulin type, an appropriate dose of the correct insulin type, a safe injection area to receive the appropriate dose of the correct insulin type, a recommended trajectory to move the injection device to inject the appropriate dose of the correct insulin, an orientation or position to hold the injection device prior to following the recommended trajectory to reach the safe injection area (e.g., site), an injection time (or time window), and / or a time interval between insulin injections. The one or more processors can output data including a graphical representation of the appropriate insulin injection on an electronic display of the user interface 36. In some examples, the one or more processors of the patient device 24 communicate data indicating content of the set of instructions and / or the graphical representation to a device maintained by a caregiver of the patient. To assist the caregiver in administering the diabetes therapy, the graphical representation and / or the set of instructions can be displayed as output on an electronic display of the device maintained by the caregiver.

[0145] If the one or more processors determine not to modify the inappropriate insulin injection (NO branch of 98), the one or more processors output an alert that the insulin injection is inappropriate (102). In response to determining that the insulin injection does not satisfy the criteria for an appropriate insulin injection, the one or more processors can output any combination of text, graphics, sound, video, and / or other content types in the alert on the electronic display of the patient device 24 that is operable to notify the patient 12 that the insulin injection is inappropriate. For example, if the one or more processors determine that preventing or delaying the inappropriate insulin injection is more beneficial than modifying the injection, the one or more processors can output such an alert to notify the patient 12 that the insulin injection is inappropriate. For example, if the current time does not comply with the injection schedule recommended for the patient 12, the injection is untimely and will be prevented or delayed by the alert. The alert can contain text as well as a sound warning. As another example, if not enough time has passed between the previous injection, the subsequent injection is inappropriate and will be prevented or delayed by the alert. In another example, the patient device 24 or a network device on the cloud 26 can transmit an instruction to the injection device 30 to stop the pending inappropriate insulin injection.

[0146] As described above, there can be various sensors for measuring different context information. Some example ways in which the sensor information can be utilized are provided below. For example, based on movement characteristics, the one or more processors 28 can determine the amount and timing of insulin delivery. In some examples, the one or more processors 28 can not issue a prompt to the patient 12 based on sensor data, such as a low battery or other type of alert, such as if the glucose is slightly out of range, such as if the patient 12 is driving or sleeping. The sensor can indicate a change in temperature, and the one or more processors 28 can set a target glucose level based on the temperature. The sensor can indicate that the patient 12 is exercising, and the one or more processors 28 can set a target glucose level based on whether the patient 12 is exercising and whether the patient 12 is performing aerobic or anaerobic exercise.

[0147] In some examples, the time at which the patient device 24 and / or the wearable device 22 outputs information (e.g., broadcasts) to the one or more processors 28 can be based on context information of the patient 12, such as biometrics, location, and time of day. In some examples, the patient device 24 and / or the wearable device 22 can output information in a power-saving manner (e.g., broadcasts can be reduced during sleep).

[0148] There can be other ways in which location information of the patient 12 is utilized to help control glucose levels. As one example, the patient device 24 can output information of a food or food company that provides products that help treat diabetes based on the location of the patient 12 being that the patient 12 is at a grocery store.

[0149] Various examples described below can be utilized together or in combination.

[0150] Example 1: A system for controlling delivery of diabetes therapy, the system comprising: a wearable device configured to generate user activity data associated with an arm of a user; and one or more processors configured to: identify, based on the user activity data, at least one gesture indicative of preparation of an insulin injection with an injection device; generate, based on the at least one identified gesture, information indicative of at least one of an amount or a type of an insulin dose in the insulin injection by the injection device; compare the generated information to a standard for a proper insulin injection; and based on the comparison, output information indicating whether the standard is met.

[0151] Example 2. The system of Example 1, wherein to identify the at least one gesture, the one or more processors are configured to: identify, based on the user activity data, at least one of: (1) a first gesture to set at least one of the amount or the type of the dose in the insulin injection; (2) a second gesture to move the injection device closer to a patient’s body; or (3) a third gesture to hold the injection device in a particular position or a particular orientation.

[0152] Example 3. The system of Examples 1-2, wherein the standard for a proper insulin injection comprises one or more of: a number of clicks to set the amount of the insulin dose, an amount of time elapsed between insulin injections, whether the user ate between insulin injections, whether to inject basal insulin to the patient based on a time of day or whether to inject a bolus insulin to the patient based on a time of day.

[0153] Example 4: The system of Examples 1-3, wherein to output information indicating whether the standard is met, the one or more processors are configured to:

[0154] in response to determining that the standard for a proper insulin injection is not met, output an alert comprising at least one of text, graphics, sound, or video, the alert operable to notify the user that the insulin injection is not proper.

[0155] Example 5: The system of Examples 1-4, wherein the wearable device comprises:

[0156] one or more inertial measurement units to generate at least a portion of the user activity data.

[0157] Example 6: The system of examples 1-5, wherein the one or more processors are configured to receive confirmation of the insulin injection from at least one of the injection device, a device communicatively coupled with the injection device, or a device having a sensor for sensing the injection device.

[0158] Example 7: The system of examples 1-6, further comprising a patient device, wherein the patient device includes the one or more processors.

[0159] Example 8: The system of examples 1-7, wherein the one or more processors are further configured to: determine a time of a subsequent insulin injection; determine whether the user attempted to inject insulin using the injection device based on movement detected by the wearable device prior to the time of the subsequent insulin injection; and based on the determination that the patient attempted to inject insulin using the injection device prior to the time of the subsequent insulin injection, output data that presents the user with an alert that the user has injected insulin.

[0160] Example 9: The system of examples 1-8, wherein the one or more processors are further configured to: output data indicating a modification to correct an impropriety associated with the insulin injection or to increase efficacy of the insulin injection based on the comparison indicating that the criteria are not met.

[0161] Example 10: The system of examples 1-9, wherein the one or more processors are further configured to: based on the comparison indicating that the criteria are not met, output data that directs the injection device to automatically modify the insulin injection or prevent the insulin injection.

[0162] Example 11: The system of examples 1-10, wherein the one or more processors are further configured to: generate data that presents a set of instructions for a patient to properly administer the therapy, the set of instructions indicating a correct insulin type, an appropriate dose of the correct insulin type, a safe injection area to receive the appropriate dose of the correct insulin type, a suggested trajectory to move the injection device to inject the appropriate dose of the correct insulin type, a recommended orientation or position of the injection device to maintain before reaching the safe injection area following the suggested trajectory, and a time interval between insulin injections.

[0163] Example 12: The system of examples 1-11, wherein the one or more processors are further configured to: communicate the data that presents the set of instructions to a device for the patient maintained by a caregiver, wherein the set of instructions is displayed as output on an electronic display of the device maintained by the caregiver.

[0164] Example 13: A method comprising: identifying, by one or more processors, at least one gesture indicative of preparing an insulin injection with an injection device based on user activity data, wherein a wearable device is configured to generate the user activity data associated with a user’s arm; generating, by the one or more processors, information indicative of at least one of an amount or a type of an insulin dose in the insulin injection by the injection device based on the at least one identified gesture; comparing, by the one or more processors, the generated information to a standard for a proper insulin injection; and outputting, by the one or more processors, information indicating whether the standard is met based on the comparison.

[0165] Example 14: The method of example 13, wherein identifying the at least one gesture further comprises: identifying, based on the user activity data, at least one of: (1) a first gesture for setting at least one of the amount or the type of the dose in the insulin injection; (2) a second gesture for moving the injection device closer to a patient’s body; or (3) a third gesture for holding the injection device in a particular position or a particular orientation.

[0166] Example 15: The method of examples 13-14, wherein the standard for a proper insulin injection comprises one or more of: a number of clicks for setting the insulin dose, an amount of time elapsed between insulin injections, whether the user ate between insulin injections, whether to inject basal insulin to the patient based on a time of day or whether to inject a bolus insulin to the patient based on a time of day.

[0167] Example 16: The method of examples 13-15, wherein outputting information indicating whether the standard is met further comprises: in response to determining that the standard for a proper insulin injection is not met, outputting an alert comprising at least one of a text, a graphic, a sound, or a video for notifying the user that the insulin injection is not proper.

[0168] Example 17: The method of examples 13-16, further comprising: receiving a confirmation of the insulin injection from at least one of the injection device, a device communicatively coupled with the injection device, or a device having a sensor for sensing the injection device.

[0169] Example 18: The method of Examples 13-17, further comprising: determining a time of a subsequent insulin injection; determining, based on movement detected by the wearable device prior to the time of the subsequent insulin injection, whether the user attempted to inject insulin using the injection device; and based on the determination that the patient attempted to inject insulin using the injection device prior to the time of the subsequent insulin injection, outputting data that presents the user with an alert that the user has injected insulin.

[0170] Example 19: The method of Examples 13-18, further comprising: outputting data indicating a modification to correct an impropriety associated with the insulin injection or to increase efficacy of the insulin injection based on the comparison indicating that the criteria are not met.

[0171] Example 20: A computer-readable storage medium having stored thereon instructions that, when executed, cause one or more processors to: identify, based on user activity data, at least one gesture indicative of preparing an insulin injection with an injection device, wherein a wearable device is configured to generate the user activity data associated with a user’s arm; generate, based on the at least one identified gesture, information indicative of at least one of an amount or a type of an insulin dose in the insulin injection by the injection device; compare the generated information to criteria for a proper insulin injection; and based on the comparison, output information indicating whether the criteria are met.

[0172] Various aspects of these techniques can be implemented within one or more processors, including one or more microprocessors, DSPs, ASICs, FPGAs, or any other equivalent integrated or discrete logic circuitry, as well as any combinations of such components, embodied in programmers, such as physician or patient programmers, electrical stimulators, or other devices. The term “processor” or “processing circuitry” can generally refer to any of the foregoing logic circuitry, alone or in combination with other logic circuitry or any other equivalent circuitry.

[0173] In one or more examples, the functions described in this disclosure can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions can be stored as one or more instructions or code on a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media can include computer-readable storage media forming a tangible, non-transitory medium. The instructions can be executed by one or more processors, such as one or more DSPs, ASICs, FPGAs, general purpose microprocessors, or other equivalent integrated or discrete logic circuitry. Accordingly, as used herein the term “processor” can refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described herein.

[0174] Additionally, in some aspects, the functions described herein can be implemented in hardware and / or software modules. Depiction of different features as modules or units is intended to highlight different functional aspects and does not necessarily imply that such modules or units must be realized by separate hardware or software components. Rather, functionality associated with one or more modules or units can be performed by separate hardware or software components, or integrated within common or separate hardware or software components. Also, the techniques could be fully implemented in one or more circuits or logic elements. The techniques of the present disclosure can be implemented in a wide variety of devices or apparatuses, including one or more processors 28 of cloud 26, one or more processors of patient device 24, one or more processors of wearable device 22, one or more processors of insulin pump 14, or some combination thereof. The one or more processors can be one or more integrated circuits (ICs) and / or discrete circuitry residing in various locations in the example systems described in this disclosure.

[0175] One or more processors or processing circuitry for example the example techniques described in this disclosure can be implemented as fixed function circuitry, programmable circuitry, or a combination thereof. Fixed function circuitry refers to circuitry that provides particular functionality and is pre-set on what operations can be performed. Programmable circuitry refers to circuitry that can be programmed to perform various tasks and provides flexible functionality in what operations can be performed. For example, programmable circuitry can execute software or firmware that cause the programmable circuitry to operate in a manner defined by instructions of the software or firmware. Fixed function circuitry can execute software instructions (e.g., to receive parameters or output parameters), but the types of operations that the fixed function circuitry performs are generally immutable. In some instances, one or more of the units can be different circuit blocks (fixed function or programmable), and in some instances, the one or more units can be integrated circuits. Processors or processing circuitry can include arithmetic logic units (ALUs), elementary function units (EFUs), digital circuits, analog circuits, and / or programmable cores made of programmable circuitry. In instances where the operations of the processor or processing circuitry are performed using software executed by programmable circuitry, memory accessible to the processor or processing circuitry can store object code of the software that the processor or processing circuitry receives and executes.

[0176] Various aspects of the disclosure have been described. These and other aspects are within the scope of the following claims.

Claims

1. A system for determining an insulin injection by a user, the system comprising: One or more processors configured to: receiving user activity data of the user; identifying at least one gesture indicating preparation for the insulin injection using an injection device based on the user activity data; and Based on at least one recognized gesture, it is determined whether an insulin injection for the user is about to occur or is occurring.

2. The system of claim 1, wherein: The one or more processors are configured to: Whether the insulin injection is about to occur or is occurring is determined based on a data model of the user, wherein the data model is configured to distinguish the insulin injection from one or more activities of the user other than the insulin injection.

3. The system of claim 2, wherein: The user model includes a definition for each of the at least one gesture and a definition for each insulin injection performed by the user that includes at least one gesture.

4. The system of claim 1, wherein: The one or more processors are configured to: determining whether a gesture for setting a dose occurred or is occurring; In response to determining that a gesture for setting a dose is about to occur or is occurring, at least one of an amount or a type of insulin dose for the insulin injection via the injection device is determined.

5. The system of claim 4, wherein: The one or more processors are configured to: A determination is made as to whether a gesture for moving the injection device closer to the user's body is imminent or is occurring.

6. The system of claim 5, wherein: The one or more processors are configured to: In response to determining that the gesture for moving the injection device closer to the user's body is about to occur or is occurring, determining whether a gesture for maintaining the injection device in a position or orientation is about to occur or is occurring; In response to determining that no gesture for moving the injection device closer to the user's body is about to occur or is occurring, the user activity data is monitored for at least one alternative gesture associated with the insulin injection or predicting no insulin injection after a predetermined wait time.

7. The system of claim 6, wherein: The one or more processors are configured to: In response to determining that the gesture for maintaining the injection device in a position or orientation is about to occur or is occurring, monitoring the user activity data for at least one of the following: at least one additional gesture associated with the insulin injection, or an indication that the insulin injection has not occurred within a predetermined wait time; In response to determining that no gesture for maintaining the injection device in a position or orientation is about to occur or is occurring, the user activity data is monitored for at least one alternative gesture associated with the insulin injection within a predetermined wait time.

8. The system of any one of claims 1 to 7, wherein: The one or more processors are configured to: In response to failing to determine the occurrence of the insulin injection, detecting a refill event or a user activity gesture that replaces the insulin injection; and In response to the refill event or the user activity gesture being detected in place of the insulin injection, detecting the at least one gesture indicative of the insulin injection is determined to be a false positive.

9. The system of any one of claims 1 to 7, wherein: The one or more processors are configured to: In response to determining that the insulin injection occurred, the determination that the insulin injection occurred is confirmed or denied based on the injection device data.

10. The system according to any one of claims 1 to 7, wherein: The system further includes a wearable device wearable by the user and configured to generate the user activity data.

11. A method for determining an insulin injection by a user, the method comprising: receiving, by one or more processors, user activity data of the user; identifying, by the one or more processors based on the user activity data, at least one gesture indicating preparation for the insulin injection using an injection device; as well as Based on at least one recognized gesture, the one or more processors determine whether an insulin injection for the user is about to occur or is occurring.

12. The method of claim 11, further comprising: Determining, by the one or more processors, whether the insulin injection is about to occur or is occurring based on a data model of the user, wherein the data model is configured to distinguish the insulin injection from one or more activities of the user other than the insulin injection.

13. The method of claim 12, wherein: The data model includes a definition for each of the at least one gesture and a definition for each insulin injection performed by the user that includes at least one gesture.

14. The method of claim 11, further comprising: determining, by the one or more processors, whether a gesture for setting a dose has occurred or is occurring; In response to determining that a gesture for setting a dose is about to occur or is occurring, at least one of an amount or a type of insulin dose for the insulin injection via the injection device is determined by the one or more processors.

15. The method of claim 14, further comprising: A determination is made, by the one or more processors, whether a gesture to move the injection device closer to the user's body is imminent or is occurring.

16. The method of claim 15, further comprising: In response to determining that the gesture for moving the injection device closer to the user's body is about to occur or is occurring, determining, by the one or more processors, whether a gesture for maintaining the injection device in a position or orientation is about to occur or is occurring; In response to determining that no gesture for moving the injection device closer to the user's body is about to occur or is occurring, the one or more processors monitor the user activity data for at least one alternative gesture associated with the insulin injection or predicting no insulin injection after a predetermined wait time.

17. The method of claim 16, further comprising: In response to determining that the gesture for maintaining the injection device in a position or orientation is about to occur or is occurring, monitoring, by the one or more processors, the user activity data for at least one of: at least one additional gesture associated with the insulin injection, or an indication that the insulin injection has not occurred within a predetermined wait time; In response to determining that no gesture for maintaining the injection device in a position or orientation is about to occur or is occurring, the one or more processors monitor the user activity data for at least one alternative gesture associated with the insulin injection within a predetermined wait time.

18. The method of any one of claims 11 to 17, further comprising: In response to failing to determine occurrence of the insulin injection, detecting, by the one or more processors, a refill event or a user activity gesture in lieu of the insulin injection; as well as In response to the refill event or the user activity gesture being detected in lieu of the insulin injection, it is determined, by the one or more processors, that the detection of the at least one gesture indicative of the insulin injection is a false positive.

19. The method of any one of claims 11 to 17, further comprising: In response to determining that the insulin injection occurred, the one or more processors confirm or deny the determination that the insulin injection occurred based on the injection device data.

20. The method of any one of claims 11-17, further comprising receiving the user activity data from a wearable device, wherein the wearable device is wearable by the user and is configured to generate the user activity data.

21. A computer-readable storage medium having stored thereon instructions that, when executed, cause one or more processors to perform the method of any one of claims 11-20.

Images