Patent Publication Number: US-2021178069-A1

Title: Controlling insulin delivery to a specific user by a medical device based on detected events associated with the specific user

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application claims the benefit of U.S. provisional patent application No. 62/948,004, filed Dec. 13, 2019, and U.S. provisional patent application No. 62/947,942, filed Dec. 13, 2019. 
    
    
     TECHNICAL FIELD 
     The present technology is generally related to medical devices, and more particularly to controlling insulin delivery to a specific user by a medical device based on detected events associated with the specific user. 
     BACKGROUND 
     Medical therapy delivery systems, such as fluid infusion devices, are relatively well known in the medical arts for use in delivering or dispensing an agent, such as insulin or another prescribed medication, to a patient. A typical medication infusion device includes a fluid pump mechanism and an associated drive system that actuates a plunger or piston of a fluid reservoir to deliver fluid medication from the reservoir to the body of a patient via a fluid delivery conduit between the reservoir and the body of a patient. Use of infusion pump therapy has been increasing, especially for delivering insulin to diabetic patients. 
     BRIEF SUMMARY 
     The subject matter of this disclosure generally relates to controlling insulin delivery to a specific user by a medical device based on detected events associated with the specific user. 
     One aspect of the present disclosure relates to a method, system and computer-readable medium for controlling insulin delivery to a specific user by a medical device based on detected events associated with the specific user. A database stores a classified output corresponding to each event combination. Each classified output maps a corresponding event combination to controller tuning instructions that influence delivery of insulin to either decrease the insulin delivery to the specific user, increase the insulin delivery to the specific user, or maintain the insulin delivery to the specific user at an ordinary level by maintaining the insulin delivery in a nominal state (e.g., maintain insulin delivery by the controller in a nominal state). When events associated with the specific user are detected, an event combination or combination of the detected events can be determined. The database of classified outputs can be accessed and a classified output corresponding to the detected event combination can be retrieved. A controller of the medical device can generate, based on the classified output, controller tuning instructions that influence delivery of insulin via the medical device to either decrease the insulin delivery to the specific user, increase the insulin delivery to the specific user, or maintain the insulin delivery to the specific user at an ordinary level by maintaining the insulin delivery in the nominal state (e.g., maintain insulin delivery by the controller in a nominal state). 
     In accordance with one aspect of the present disclosure, the classified output can include instructions to either: decrease insulin delivery when the combination of detected events is associated with a probability of a decreased insulin delivery demand and the probability of the decreased insulin delivery demand is greater than a first threshold, increase insulin delivery when the combination of detected events is associated with a probability of an increased insulin delivery demand and the probability of the increased insulin delivery demand is greater than a second threshold, or maintain ordinary insulin delivery by maintaining the insulin delivery in a nominal state when the probability of the decreased insulin delivery demand is less than the first threshold and the probability of the increased insulin delivery demand is less than the second threshold. 
     In accordance with one aspect of the present disclosure, the instructions from the classified output comprise therapy parameters and settings for the medical device to: decrease insulin delivery to the specific user when the combination of detected events is associated with a probability of a decreased insulin delivery demand and the probability of the decreased insulin delivery demand is greater than a first threshold, increase insulin delivery to the specific user when the combination of detected events is associated with a probability of an increased insulin delivery demand and the probability of the increased insulin delivery demand is greater than a second threshold, or maintain ordinary insulin delivery to the specific user by maintaining the insulin delivery in a nominal state when the probability of the decreased insulin delivery demand is less than the first threshold and the probability of the increased insulin delivery demand is less than the second threshold. 
     In accordance with one aspect of the present disclosure, the controller of the medical device can generate, based on the classified output, therapy parameters and settings for controlling delivery of insulin via the medical device to either increase insulin delivery to the specific user, decrease insulin delivery to the specific user, or maintain insulin delivery to the specific user at an ordinary level by maintaining the insulin delivery in the nominal state. 
     In accordance with one aspect of the present disclosure, the medical device can be controlled, based on the therapy parameters and settings to control the delivery of the insulin via the medical device, to either increase insulin delivery to the specific user, decrease insulin delivery to the specific user, or maintain insulin delivery to the specific user at the ordinary level by maintaining the insulin delivery in the nominal state. 
     In accordance with one aspect of the present disclosure, at least some of the detected events can indicate a specific condition or activity that is indicative of a physical behavior of the user. Examples of the specific conditions or activities that are indicative of the physical behavior of the user can include, but are not limited to, a meal ingestion event; a physical inactivity event; a sleep event; a physical activity event; an exercise event and a work-related event. 
     Another aspect of the present disclosure relates to a method, system and computer-readable medium for controlling insulin delivery to a specific user by a medical device based on a detected event associated with the specific user. A database stores a predefined output corresponding to each detected event. Each predefined output maps a particular detected event to therapy parameters and settings that will cause a controller of the medical device to either decrease insulin delivery to the specific user, increase the insulin delivery to the specific user, or maintain the insulin delivery to the specific user at an ordinary level by maintaining the insulin delivery in a nominal state. When an event associated with the specific user is detected, the database of predefined outputs can be accessed, and a predefined output corresponding to the detected event can be retrieved. A controller of the medical device can then apply therapy parameters and settings specified by the predefined output to control delivery of insulin via the medical device. The therapy parameters and settings specified by the predefined output cause the controller of the medical device to either decrease the insulin delivery to the specific user, increase the insulin delivery to the specific user, or maintain the insulin delivery to the specific user at the ordinary level by maintaining the insulin delivery in the nominal state. In some aspects of the present disclosure, the medical device can be controlled based on the therapy parameters and settings specified by the predefined output to control the delivery of the insulin via the medical device to either increase the insulin delivery to the specific user, decrease the insulin delivery to the specific user, or maintain the insulin delivery to the specific user at the ordinary level by maintaining the insulin delivery in the nominal state. 
     Another aspect of the present disclosure relates to a method, system and computer-readable medium for classifying detected events to generate a classified output for controlling a medical device to control insulin delivery to a specific user. Detected events associated with the specific user can be processed, for example, at a server system, to generate a classifier output for a combination of detected events that can be stored in storage as the classified output in a database of classified outputs. 
     In accordance with one aspect of the present disclosure, detected events associated with the specific user can be processed, for example, at a server system by: grouping the detected events into a combination of detected events, and classifying that combination of detected events at a classifier. For example, in accordance with one aspect of the present disclosure, the combination of detected events can be classified at the classifier by: mapping the combination of detected events to controller tuning instructions that influence delivery of insulin to either decrease the insulin delivery to the specific user, increase the insulin delivery to the specific user, or maintain the insulin delivery to the specific user at an ordinary level by maintaining the insulin delivery in a nominal state; and generating a classifier output corresponding to the combination of detected events, wherein the classifier output comprises the controller tuning instructions that influence delivery of insulin to either decrease the insulin delivery to the specific user, increase the insulin delivery to the specific user, or maintain the insulin delivery to the specific user at the ordinary level by maintaining the insulin delivery in the nominal state . 
     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 techniques described in this disclosure will be apparent from the description and drawings, and from the claims. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a simplified block diagram representation of an exemplary embodiment of a system that includes a medication delivery system that responds to changes in patient activity as indicated by the output of a gesture-based event detection system; 
         FIG. 2  is a plan view of an exemplary embodiment of an insulin infusion device that is suitable for use as the medication delivery system shown in  FIG. 1 ; 
         FIG. 3A  is a top perspective view of an embodiment of an insulin infusion device implemented as a patch pump device that is suitable for use as the medication delivery system shown in  FIG. 1 ; 
         FIG. 3B  is a perspective view of an exemplary embodiment of a smart insulin pen that is suitable for use as the medication delivery system shown in  FIG. 1 ; 
         FIG. 4  is a perspective view of an exemplary embodiment of a smart pen accessory that is suitable for use with the medication delivery system shown in  FIG. 1 ; 
         FIG. 5  is a block diagram of an exemplary embodiment of an injection pen suitable for use in the injection system of  FIG. 1 ; 
         FIG. 6  is a block diagram representation of an exemplary embodiment of a computer-based or processor-based device suitable for deployment in the system shown in  FIG. 1 ; 
         FIG. 7  is a block diagram representation of a closed loop glucose control system arranged in accordance with certain embodiments; 
         FIG. 8  is a block diagram representation of a gesture-based event detection system arranged in accordance with certain embodiments; 
         FIG. 9  is a block diagram representation of an embodiment of a gesture-informed patient management system in accordance with certain embodiments; 
         FIG. 10A  is block diagram illustrating a system for classifying detected events in accordance with certain embodiments; 
         FIG. 10B  is block diagram illustrating a system for controlling insulin delivery to a specific user of a medical device based on detected events associated with a specific user in accordance with certain embodiments; 
         FIG. 11A  is a flowchart illustrating a method for classifying detected events to generate a classified output for controlling a medical device to control insulin delivery to a specific user in accordance with certain embodiments; 
         FIG. 11B  is a flowchart illustrating a method for controlling insulin delivery to a specific user of a medical device based on detected events associated with the specific user in accordance with certain embodiments; 
         FIG. 12  is block diagram illustrating a system for controlling insulin delivery to a specific user by a medical device based on a detected event associated with the specific user in accordance with certain embodiments; 
         FIG. 13  is a flowchart illustrating a method for controlling insulin delivery to a specific user by a medical device based on a detected eating event associated with the specific user in accordance with certain embodiments; 
         FIG. 14  is a flowchart illustrating a method for controlling insulin delivery to a specific user by a medical device based on a detected event that is indicative of activity or inactivity of the specific user in accordance with certain embodiments; 
         FIG. 15  is a flowchart illustrating a method for controlling insulin delivery to a specific user by a medical device based on a work-related event associated with the specific user in accordance with certain embodiments; and 
         FIG. 16  is a flowchart illustrating a method for controlling insulin delivery to a specific user by a medical device based on an exercise-related event or other event indicative of physical activity associated with the specific user in accordance with certain embodiments. 
     
    
    
     DETAILED DESCRIPTION 
     Control schemes have been developed to allow insulin infusion devices to monitor and regulate a patient&#39;s blood glucose level in a substantially continuous and autonomous manner. An insulin infusion device can be operated in an automatic mode wherein basal insulin is delivered at a rate that is automatically adjusted for the user. Moreover, an insulin infusion device can be operated to automatically calculate, recommend, and deliver insulin boluses as needed (e.g., to compensate for meals consumed by the user). Ideally, the amount of an insulin bolus should be accurately calculated and administered to maintain the user&#39;s blood glucose within the desired range. In particular, an automatically generated and delivered insulin bolus should safely manage the user&#39;s blood glucose level and keep it above a defined threshold level. To this end, an insulin infusion device operating in an automatic mode uses continuous glucose sensor data and control algorithms to regulate the user&#39;s blood glucose, based on a target glucose setpoint setting and user-initiated meal announcements that typically include estimations of the amount of carbohydrates to be consumed in an upcoming meal. 
     The following detailed description is merely illustrative in nature and is not intended to limit the embodiments of the subject matter or the application and uses of such embodiments. As used herein, the word “exemplary” means “serving as an example, instance, or illustration.” Any implementation described herein as exemplary is not necessarily to be construed as preferred or advantageous over other implementations. Furthermore, there is no intention to be bound by any expressed or implied theory presented in the preceding technical field, background, brief summary or the following detailed description. 
     It should be understood that various aspects disclosed herein may be combined in different arrangements than the combinations specifically presented in the description and accompanying drawings. It should also be understood that, depending on the example, certain acts or events of any of the processes or methods described herein may be performed in a different sequence, may be added, merged, or left out altogether (e.g., all described acts or events may not be necessary to carry out the techniques). In addition, while certain aspects of this disclosure are described as being performed by a single module or unit for purposes of clarity, it should be understood that the techniques of this disclosure may be performed by a combination of units or modules associated with, for example, a medical device. 
     In one or more examples, the described techniques may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may 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 may include non-transitory computer-readable media, which corresponds to a tangible medium such as data storage media (e.g., RAM, ROM, EEPROM, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer). 
     Program code instructions may be configurable to be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, controllers, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Accordingly, the term “processor” as used herein may refer to any of the foregoing structure or any other physical structure suitable for implementation of the described techniques. Also, the techniques could be fully implemented in one or more circuits or logic elements. 
     Techniques and technologies may be described herein in terms of functional and/or logical block components, and with reference to symbolic representations of operations, processing tasks, and functions that may be performed by various computing components or devices. Such operations, tasks, and functions are sometimes referred to as being computer-executed, computerized, software-implemented, or computer-implemented. It should be appreciated that the various block components shown in the figures may be realized by any number of hardware, software, and/or firmware components configured to perform the specified functions. For example, an embodiment of a system or a component may employ various integrated circuit components, e.g., memory elements, digital signal processing elements, logic elements, look-up tables, or the like, which may carry out a variety of functions under the control of one or more microprocessors or other control devices. 
       FIG. 1  is a simplified block diagram representation of an exemplary embodiment of a system  100  that responds to changes in the user&#39;s activity (e.g., eating, sleeping, exercise, and/or working habits) by regulating operation of a continuous medication delivery system  102  and/or a discrete medication delivery system  103  in an appropriate manner. In certain embodiments, the continuous medication delivery system  102  and/or the discrete medication delivery system  103  responds to changes in patient activity as indicated by the output of a gesture-based event detection system  104  and/or the output of at least one ancillary sensor, detector, or measurement system  106  (hereinafter referred to as ancillary system(s)  106 ). Certain embodiments of the system  100  include, without limitation: the continuous medication delivery system  102  that delivers medication to a user; the discrete medication delivery system  103  (or device) that delivers medication to a user; an event detection system  107  that includes at least one gesture-based event detection system  104  that monitors user behavior and/or status to obtain gesture data that indicates user activity events or behavior and at least one ancillary system  106 ; at least one user device  108  that includes or cooperates with a suitably written and configured patient care application  110 ; an event classification service or application  111 ; an analyte sensor  112  to measure a physiological characteristic of the user, such that sensor data obtained from the analyte sensor  112  can be used to control, regulate, configure or otherwise influence the operation of the continuous medication delivery system  102  and/or the discrete insulin therapy system  103 ; and at least one patient history and outcomes database  114 . In accordance with certain cloud-implemented embodiments, the system includes at least one data processing system  116 , which may be in communication with any or all of the other components of the system  100 . In some examples, the discrete medication delivery system  103  includes one or more user device(s)  108 . Other configurations and topologies for the system  100  are also contemplated here, such as a system that includes additional intermediary, interface, or data repeating devices in the data path between a sending device and a receiving device. 
     As will be described in greater detail below, the event classification service (or app)  111  is provided for classifying detected events as labeled events and for classifying combinations of detected events as labeled event combinations. Depending on the embodiment, the event classification service  111  may be distributed across one or more different devices  102 ,  103 ,  104 ,  106 ,  108 ,  112 ,  114 ,  116  in the system  100  and the subject matter described herein is not limited to any particular implementation. Various embodiments of the event classification service  111  will be described in greater detail below with reference to  FIGS. 9 through 16 . 
     At least some of the components of the system  100  are communicatively coupled with one another to support data communication, signaling, and/or transmission of control commands as needed, via at least one communications network  120 . The at least one communications network  120  may support wireless data communication and/or data communication using tangible data communication links.  FIG. 1  depicts network communication links in a simplified manner. In practice, the system  100  may cooperate with and leverage any number of wireless and any number of wired data communication networks maintained or operated by various entities and providers. Accordingly, communication between the various components of the system  100  may involve multiple network links and different data communication protocols. In this regard, the network can include or cooperate with any of the following, without limitation: a local area network; a wide area network; the Internet; a personal area network; a near-field data communication link; a cellular communication network; a satellite communication network; a video services or television broadcasting network; a network onboard a vehicle; or the like. The components of the system  100  may be suitably configured to support a variety of wireless and wired data communication protocols, technologies, and techniques as needed for compatibility with the at least one communication network  120 . 
     The system  100  can support any type of continuous medication delivery system  102  and discrete medication delivery system  103  that is compatible with the features and functionality described here. The continuous medication delivery system  102  may be implemented as an electronic device that is operated to regulate the delivery of medication fluid to the user. In certain embodiments, the continuous medication delivery system  102  includes or is realized as an insulin infusion device, e.g., a portable patient-worn or patient-carried insulin pump or the like. In this case, the medication delivery system  102  is “continuous” in that it continuously measures a user&#39;s blood glucose levels and delivers insulin (or other medication) to the user. The discrete medication delivery system  103  may be realized as a user-activated or user-actuated fluid delivery device, such as a manual syringe, an injection pen, a smart insulin pen, or the like. In this case, the medication delivery system  103  is “discrete” in that it discretely delivers insulin (or other medication) to the user. 
     Both the continuous medication delivery system  102  and the discrete medication delivery system  103  can be utilized in conjunction with one or more analyte sensors. In such embodiments, the analyte sensor  112  includes or is realized as a glucose meter, a glucose sensor, or a continuous glucose monitor. For the sake of brevity, conventional techniques related to insulin infusion device operation, infusion set operation, and other functional aspects of the systems (and the individual operating components of the systems) may not be described in detail here. Examples of infusion pumps may be of the type described in, but not limited to, U.S. Pat. Nos.: 4,562,751; 4,685,903; 5,080,653; 5,505,709; 5,097,122; 6,485,465; 6,554,798; 6,558,320; 6,558,351; 6,641,533; 6,659,980; 6,752,787; 6,817,990; 6,932,584; and 7,621,893; each of which are herein incorporated by reference. 
     Generally, a fluid infusion device (such as an insulin infusion device) includes a fluid pump mechanism having a motor or other actuation arrangement that is operable to linearly displace a plunger (or stopper) of a fluid reservoir provided within the fluid infusion device to deliver a dosage of fluid medication, such as insulin, to the body of a user. Dosage commands that govern operation of the motor may be generated in an automated manner in accordance with the delivery control scheme associated with a particular operating mode, and the dosage commands may be generated in a manner that is influenced by a current (or most recent) measurement of a physiological condition in the body of the user. For a glucose control system suitable for use by diabetic patients, a closed-loop or automatic operating mode can be used to generate insulin dosage commands based on a difference between a current (or most recent) measurement of the interstitial fluid glucose level in the body of the user and a target (or reference) glucose setpoint value. In this regard, the rate of infusion may vary as the difference between a current measurement value and the target measurement value fluctuates. For purposes of explanation, the subject matter is described herein in the context of the infused fluid being insulin for regulating a glucose level of a user (or patient); however, it should be appreciated that many other fluids may be administered through infusion, and the subject matter described herein is not necessarily limited to use with insulin. 
       FIG. 2  is a plan view of an exemplary embodiment of an insulin infusion device  130  suitable for use as the medication delivery system  102  shown in  FIG. 1 . The insulin infusion device  130  is a portable medical device designed to be carried or worn by the patient. The insulin infusion device  130  is one example of a device that can be used as part of the continuous medication delivery system  102  of  FIG. 1 . The insulin infusion device  130  can deliver insulin to a user without the need for manual injections. The insulin infusion device  130  can be part of a continuous insulin therapy system that includes one or more sensors such as a continuous glucose monitor. The insulin infusion device  130  can provide fast-acting insulin through a small tube placed under the skin, delivering two types of doses: basal or “background” insulin, which can be delivered continuously in tiny doses throughout the day and night; and bolus insulin to cover an increase in blood glucose from meals and/or to correct high blood glucose levels. The insulin infusion device  130  can provide insulin based on pre-programmed basal and bolus settings. 
     The illustrated embodiment of the insulin infusion device  130  includes a housing  132  adapted to receive an insulin-containing reservoir (hidden from view in  FIG. 2 ). An opening in the housing  132  accommodates a fitting  134  (or cap) for the reservoir, with the fitting  134  being configured to mate or otherwise interface with tubing  136  of an infusion set  138  that provides a fluid path to/from the body of the user. In this manner, fluid communication from the interior of the insulin reservoir to the user is established via the tubing  136 . The illustrated version of the insulin infusion device  130  includes a human-machine interface (HMI)  140  (or user interface) that includes elements that can be manipulated by the user to administer a bolus of fluid (e.g., insulin), to change therapy settings, to change user preferences, to select display features, and the like. The insulin infusion device  130  also includes a display  142 , such as a liquid crystal display (LCD) or another suitable display technology, that can be used to present various types of information or data to the user, such as, without limitation: the current glucose level of the patient; the time; a graph or chart of the patient&#39;s glucose level versus time; device status indicators; etc. The insulin infusion device  130  may be configured and controlled to support other features and interactive functions described in more detail below. 
       FIG. 3A  is a top perspective view of an embodiment of an insulin infusion device  146  implemented as a patch pump device that is suitable for use as the medication delivery system  102  shown in  FIG. 1 . The insulin infusion device  146  can be implemented as a combination device that includes an insertable insulin delivery cannula and an insertable glucose sensor (both of which are hidden from view in  FIG. 3A ). In such an implementation, the glucose sensor may take the place of the separate analyte sensor  112  shown in  FIG. 1 . The insulin infusion device  146  is another example of a device that can be used to implement the continuous medication delivery system  102  of  FIG. 1 . In this embodiment, the insulin infusion device  146  includes a housing  148  that serves as a shell for a variety of internal components.  FIG. 3A  shows the insulin infusion device  146  with a removable fluid cartridge  150  installed and secured therein. The housing  148  is suitably configured to receive, secure, and release the removable fluid cartridge  150 . The insulin infusion device  146  includes at least one user interface feature, which can be actuated by the patient as needed. The illustrated embodiment of the insulin infusion device  146  includes a button  152  that is physically actuated. The button  152  can be a multipurpose user interface if so desired to make it easier for the user to operate the insulin infusion device  146 . In this regard, the button  152  can be used in connection with one or more of the following functions, without limitation: waking up the processor and/or electronics of the insulin infusion device  146 ; triggering an insertion mechanism to insert a fluid delivery cannula and/or an analyte sensor into the subcutaneous space or similar region of the user; configuring one or more settings of the insulin infusion device  146 ; initiating delivery of medication fluid from the fluid cartridge  150 ; initiating a fluid priming operation; disabling alerts or alarms generated by the insulin infusion device  146 ; and the like. In lieu of the button  152 , the insulin infusion device  146  can employ a slider mechanism, a pin, a lever, a switch, a touch-sensitive element, or the like. In certain embodiments, the insulin infusion device  146  may be configured and controlled to support other features and interactive functions described in more detail below. 
       FIG. 3B  is a perspective view of an exemplary embodiment of a smart insulin pen  160  suitable for use as the medication delivery system shown in  FIG. 1 . The smart insulin pen  160  is one example of a device that can be used as part of the discrete medication delivery system  103  of  FIG. 1 . The pen  160  includes an injector body  162  and a cap  164 .  FIG. 3B  shows the cap  164  removed from the injector body  162 , such that a delivery needle  166  is exposed. The pen  160  includes suitably configured electronics and processing capability to communicate with an application running on a user device, such as a smartphone, to support various functions and features such as: tracking active insulin; calculating insulin dosages (boluses); tracking insulin dosages; monitoring insulin supply levels; patient reminders and notifications; and patient status reporting. In certain embodiments, the smart insulin pen  160  can receive insulin dosage recommendations or instructions and/or recommended dosing times (or a recommended dosing schedule). Moreover, the smart insulin pen  160  may be configured and controlled to support other features and interactive functions described in more detail below. 
       FIG. 4  is a perspective view of an exemplary embodiment of a smart pen accessory  170  that is suitable for use with the medication delivery system  102  shown in  FIG. 1 . The smart pen accessory  170  is one example of a device that can be used as part of the discrete medication delivery system  103  of  FIG. 1 . In particular, the smart pen accessory  170  cooperates with a “non-smart” insulin pen that lacks the intelligence and functionality of a smart insulin pen (as described). The smart pen accessory  170  can be realized as a pen cap, a clip-on apparatus, a sleeve, or the like. The smart pen accessory  170  is attached to an insulin pen  172  such that the smart pen accessory  170  can measure the amount of insulin delivered by the insulin pen  172 . The insulin dosage data is stored by the smart pen accessory  170  along with corresponding date/time stamp information. In certain embodiments, the smart pen accessory  170  can receive, store, and process additional patient-related or therapy-related data, such as glucose data. Indeed, the smart pen accessory  170  may also support various features and functions described in the context of the smart insulin pen  160 . For example, the smart pen accessory  170  may be configured to receive insulin dosage recommendations or instructions and/or recommended dosing times (or a recommended dosing schedule). Moreover, the smart pen accessory  170  may be configured and controlled to support other features and interactive functions described in more detail below. 
       FIG. 5  depicts an exemplary embodiment of an injection pen  200  suitable for use as the discrete medication delivery system  103  of  FIG. 1  in accordance with one or more embodiments. The injection pen  200  is one example of a device that can be used as part of the discrete medication delivery system  103  of  FIG. 1 . The illustrated injection pen  200  includes, without limitation, a pen controller  202 , a communications interface  204 , a data storage element (or memory)  206 , an actuation arrangement  208 , and user interface elements  210 ,  212 . The pen controller  202  is coupled to the communications interface  204 , the memory  206 , the actuation arrangement  208 , and the user interface elements  210 ,  212 , and the pen controller  202  is suitably configured to support the operations, tasks, and/or processes described herein. In this regard, the pen controller  202  supports operation of the actuation arrangement  208  in response to manual actuation of a user interface element  212  to deliver a particular bolus amount of fluid from a fluid container  214  (e.g., a cartridge or reservoir) to an injection site in the body  104  of a patient via a needle  216 . 
     The communications interface  204  generally represents the hardware, circuitry, logic, firmware and/or other components of the injection pen  200  that are coupled to the pen controller  202  and configured to support communications between the injection pen  200  and one or more external electronic devices of an injection system  100  (e.g., the blood glucose meter  106 , the glucose sensing arrangement  108 , and/or the electronic device  110 ). In exemplary embodiments, the communications interface  204  includes or is otherwise coupled to one or more transceiver units capable of supporting wireless communications; however, in some embodiments, the communications interface  204  may be configured to support wired communications. 
     The user interface element(s)  210  generally represents the hardware, circuitry, logic, firmware and/or other components of the injection pen  200  configured to support user interactions between the pen controller  202  and a patient or user. The one or more user interface element(s)  210  associated with the injection pen  200  may include at least one input user interface element, such as, for example, a button, a keypad, a knob, a touch panel, a touchscreen, and/or the like. Additionally, the one or more user interface element(s)  210  may include at least one output user interface element, such as, for example, a display element (e.g., a light-emitting diode or the like), a display device (e.g., a liquid crystal display or the like), a speaker or another audio output device, a haptic feedback device, or the like, for providing notifications or other information to the user. In the illustrated embodiment, user interface element  212  represents an input user interface element of the injection pen  200  that is actuatable by a user to produce corresponding operation of the actuation arrangement  208  to deliver a bolus of fluid from the fluid container  214  via the needle  216 . In one or more embodiments, the input user interface element  212  is realized as a tactile depressible button that is associated with the delivery of a bolus from the injection pen  200 , and accordingly, the input user interface element  212  may alternatively be referred to herein, without limitation, as a delivery button. 
     The pen controller  202  generally represents the hardware, circuitry, logic, firmware and/or other component(s) of the injection pen  200  that is configured to determine bolus dosage commands for configuring or otherwise operating the actuation arrangement  208  to deliver fluid from the fluid container  214  and perform various additional tasks, operations, functions and/or operations described herein. Depending on the embodiment, the pen controller  202  may be implemented or realized with a general purpose processor, a microprocessor, a controller, a microcontroller, a state machine, a content addressable memory, an application specific integrated circuit, a field programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof, designed to perform the functions described herein. In this regard, the steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in firmware, in software instructions executed by the pen controller  202 , or in any practical combination thereof. 
     In exemplary embodiments, the pen controller  202  includes or otherwise accesses the data storage element or memory  206 , which may be realized using any sort of non-transitory computer-readable medium capable of storing programming instructions for execution by the pen controller  202 . The computer-executable programming instructions, when read and executed by the pen controller  202 , cause the pen controller  202  to perform the tasks, operations, functions, and processes described herein. In this regard, a control scheme or algorithm implemented by the pen controller  202  may be realized as control application code that is stored or otherwise maintained in the memory  206  and executed by the pen controller  202  to implement or otherwise provide one or more of the components in software. For example, the control application code may be executed by the controller  202  to generate a bolus wizard application  220  that calculates or otherwise determines the amount of fluid to be bolused to a patient. Similarly, the pen controller  202  may also implement or otherwise execute a command generation application  222  that converts a bolus amount from the bolus wizard application  220  into a corresponding command for operating or otherwise configuring the actuation arrangement  208  for dispensing the bolus amount from the container  214 . The illustrated pen controller  202  also implements or otherwise executes a user notification application  224  that supports interactions with the patient or other users via the user interface element(s)  210  associated with the injection pen  200 , as described in greater detail below. 
     Still referring to  FIG. 5 , the parameter registers  226  generally represent the hardware, circuitry and/or other components of the injection pen  200  that are configured to store the patient-specific physiological parameters or other control information utilized by the bolus wizard application  220  of the pen controller  202  in determining a bolus amount in a patient-specific manner. For example, the parameter registers  226  may store or otherwise maintain one or more patient-specific insulin sensitivity factor values, carbohydrate-to-insulin ratio values, insulin action speed values, target glucose values, and the like. The patient-specific insulin sensitivity factor value reflects the patient&#39;s sensitivity to insulin (e.g., an amount of drop in glucose level per unit of insulin administered). In practice, multiple different patient-specific insulin sensitivity factor values may be input by a user and stored by the injection pen  200  in association with particular time periods to support subdividing the day into multiple segments that reflect or otherwise account for diurnal variations in the patient&#39;s insulin sensitivity. The carbohydrate-to-insulin ratio value defines how many grams of carbohydrates one unit of insulin can compensate for, and similarly, multiple different carbohydrate-to-insulin ratio values may be input by a user and stored by the injection pen  200  in association with particular time periods to account for diurnal variations exhibited by the patient. The insulin action speed value represents the amount of time insulin remains active in the patient&#39;s body (e.g., the amount of time required to clear a unit of insulin). 
     In exemplary embodiments, the parameter registers  226  are capable of storing or otherwise maintaining a low target glucose value (T L ) and a high target glucose value (T H ), which are utilized when calculating the bolus amount. In this regard, the high target glucose value (T H ) is the desired glucose level that the user would like to achieve or stay below after delivering a bolus, and the low target glucose value (T L ) is the desired glucose level that the user would like to achieve or stay above after delivering a bolus. Again, multiple different sets of target glucose values may be input by a user and stored by the injection pen  200  in association with particular time periods to support subdividing the day into multiple segments. 
     In exemplary embodiments, the memory  206  also includes registers  228  (or other allocation) configured to store historical bolus data for the injection pen  200 . In this regard, the bolus data portion  228  of memory  206  stores or otherwise maintains information identifying the respective amounts of previous boluses and the respective delivery times associated with those previous boluses. As described in greater detail below in the context of  FIG. 3 , the historical bolus data for the injection pen  200  is utilized to calculate, estimate, or otherwise determine the amount of active insulin on-board (IOB) in the body  104  of the patient using the patient-specific insulin action speed value. 
     In the embodiment of  FIG. 5 , the actuation arrangement  208  generally represents the hardware, circuitry and/or other electrical, mechanical, or electromechanical components of the injection pen  200  that are configured to enable or otherwise facilitate delivering boluses of fluid from the fluid container  214  to the patient&#39;s body  104  via the needle  216 . For example, the actuation arrangement  208  may include a motor mechanically coupled to a drive train assembly configured to translate rotational motor motion into linear displacement of a slide, shaft, or the like that produces a corresponding displacement of a plunger or stopper within the fluid container  214  towards the needle  216 . In an alternative embodiment, the actuation arrangement  208  includes adjustable or configurable drive train components that are configured to selectively restrict or otherwise limit the range of motion (or amount of displacement) of the plunger or stopper within the fluid container  214 , and thereby limit the amount of fluid that may be dispensed from the injection pen  200  when an actuatable user interface element  212  of the injection pen  200  (e.g., a depressible delivery button) is manually manipulated. 
     It should be understood that  FIG. 5  is a simplified representation of the injection pen  200  for purposes of explanation and is not intended to limit the subject matter described herein in any way. In this regard, although  FIG. 5  depicts the user interface elements  210 ,  212  as being integrated with the injection pen  200 , in various alternative embodiments, one or more of the user interface element  210 ,  212  may be integrated with another device in the injection system  100  that is communicatively coupled to the injection pen  200  (e.g., the electronic device  110 ). Furthermore, although  FIG. 5  depicts the fluid container  214  being onboard the injection pen  200 , it will be appreciated that the container  214  may be physically separate from the injection pen  200  and detachable, removable or otherwise replaceable upon depletion. Similarly, although  FIG. 5  depicts the needle  216  as being separate from the injection pen  200  (e.g., a detachable or replaceable needle), in some embodiments, the needle  216  may be integrated or otherwise fixedly engaged with the housing of the injection pen  200 . Additionally, while  FIG. 5  depicts registers  226 ,  228  as being integrated with or into the memory  206 , in various embodiments, either or both of the registers  226 ,  228  may be distinct or otherwise separate from memory  206 , and the registers  226 ,  228  may be integrated with the pen controller  202  or with one another separate from the memory  206 . 
     Referring again to  FIG. 1 , the analyte sensor  112  may communicate sensor data to the continuous medication delivery system  102  and/or the discrete medication delivery system  103  for use in regulating or controlling operation of the continuous medication delivery system  102  and/or the discrete medication delivery system  103 . Alternatively or additionally, the analyte sensor  112  may communicate sensor data to one or more other components in the system  100 , such as, without limitation: a user device  108  (for use with the patient care application  110 ); a data processing system  116 ; and/or a patient history and outcomes database  114 . 
     The system  100  can support any number of user devices  108  linked to the particular user or patient. In this regard, a user device  108  may be, without limitation: a smartphone device; a laptop, desktop, or tablet computer device; a medical device; a wearable device; a global positioning system (GPS) receiver device; a system, component, or feature onboard a vehicle; a smartwatch device; a television system; a household appliance; a video game device; a media player device; or the like. For the example described here, the continuous medication delivery system  102  and/or the discrete medication delivery system  103  and the at least one user device  108  are owned by, operated by, or otherwise linked to a user/patient. Any given user device  108  can host, run, or otherwise execute the patient care application  110 . In certain embodiments, for example, the user device  108  is implemented as a smartphone with the patient care application  110  installed thereon. In accordance with another example, the patient care application  110  is implemented in the form of a website or webpage, e.g., a website of a healthcare provider, a website of the manufacturer, supplier, or retailer of the continuous medication delivery system  102  and/or the discrete medication delivery system  103 , or a web site of the manufacturer, supplier, or retailer of the analyte sensor  112 . In accordance with another example, the continuous medication delivery system  102  and/or the discrete medication delivery system  103  executes the patient care application  110  as a native function. 
     In certain embodiments, at least some of the features or output of the gesture-based event detection system  104  and/or the ancillary system(s)  106  can be used to influence features, functions, and/or therapy-related operations of the continuous medication delivery system  102  and/or the discrete medication delivery system  103 . In particular, the systems  104 ,  106  may be suitably configured and operated to generate and provide output (e.g., data, control signals, markers, or flags) that indicates whether the user&#39;s behavior or activity is out of the ordinary, unusual, or has significantly changed relative to a currently implemented or active therapy behavior pattern of the user, such that the continuous medication delivery system  102  can dynamically respond in an appropriate manner that contemplates a change in user activity. Likewise, the systems  104 ,  106  may be suitably configured and operated to generate and provide output (e.g., data, control signals, markers, or flags) to the discrete medication delivery system  103  so that the user can take actions to adjust therapy 
     As described in more detail below, the gesture-based event detection system  104  includes one or more sensors, detectors, measurement devices, and/or readers to automatically detect certain user gestures that correlate to user behavior, eating habits, work habits, or the like (e.g., work-related physical activity, commuting, eating at common meal times, sleeping, exercising, or watching television). The gesture-based event detection system  104  may communicate gesture data to the continuous medication delivery system  102  and/or the discrete medication delivery system  103 , the user device  108 , and/or the data processing system  116  for processing in an appropriate manner for use in regulating or controlling certain functions of the continuous medication delivery system  102  and/or the discrete medication delivery system  103 . For example, the gesture data may be communicated to a user device  108 , such that the user device  108  can process the gesture data and inform the user or the continuous medication delivery system  102  as needed (e.g., remotely regulate or control certain functions of the continuous medication delivery system  102 ). As another example, the gesture-based event detection system  104  may communicate the gesture data to one or more cloud computing systems or servers (such as a remote data processing system  116 ) for appropriate processing and handling in the manner described herein. 
     Similarly, an ancillary system  106  may include one or more sensors, detectors, measurement devices, and/or readers that obtain ancillary user status data that correlates to user activity, detectable behavior, eating habits, etc. In certain embodiments, an ancillary system  106  may include, cooperate with, or be realized as any of the following, without limitation: a heartrate monitor linked to the user; a blood pressure monitor linked to the user; a respiratory rate monitor linked to the user; a vital signs monitor linked to the user; an oxygen saturation monitor; an electrocardiogram (ECG or EKG) recorder that records timing and strength of the electrical signals that make the heart beat; other on-body devices (e.g., a smart ring) that measures body temperature, heart rate, accelerometer data, etc.; a microphone; a thermometer (for the user&#39;s body temperature and/or the environmental temperature); a sweat detector linked to the user; an activity tracker linked to the user; a global positioning system (GPS); a clock, calendar, or appointment application linked to the user; a pedometer linked to the user; or the like. An ancillary system  106  may be configured and operated to communicate its output (user status data) to one or more components of the system  100  for analysis, processing, and handling in the manner described herein. In certain embodiments, user status data obtained from one or more ancillary systems  106  supplements the gesture data obtained from the gesture-based event detection system  104 , such that user habits, physical behavior, and activity events are accurately and reliably detected. 
     In certain embodiments, the gesture-based event detection system  104 , the continuous medication delivery system  102 , and the discrete medication delivery system  103  are implemented as physically distinct and separate components, as depicted in  FIG. 1 . In such embodiments, the gesture-based event detection system  104  is external to the continuous medication delivery system  102  and/or the discrete medication delivery system  103  and is realized as an ancillary component, relative to the continuous medication delivery system  102  and/or the discrete medication delivery system  103 . In accordance with alternative embodiments, however, the continuous medication delivery system  102  and/or the discrete medication delivery system  103  and the gesture-based event detection system  104  can be combined into a single hardware component or provided as a set of attached hardware devices. For example, the continuous medication delivery system  102  and/or the discrete medication delivery system  103  may include the gesture-based event detection system  104  or integrate the functionality of the system  104 . Similarly, the analyte sensor  112  can be incorporated with the continuous medication delivery system  102 , the discrete medication delivery system  103  or the gesture-based event detection system  104 . These and other arrangements, deployments, and topologies of the system  100  are contemplated by this disclosure. 
     The at least one patient history and outcomes database  114  includes historical data related to the user&#39;s physical condition, physiological response to the medication regulated by the continuous medication delivery system  102  and/or the discrete medication delivery system  103 , activity patterns or related information, eating patterns and habits, work habits, and the like. In accordance with embodiments where the continuous medication delivery system  102  and/or the discrete medication delivery system  103  is an insulin infusion device and the analyte sensor  112  is a glucose meter, sensor, or monitor, the database  114  can maintain any of the following, without limitation: historical glucose data and corresponding date/time stamp information; insulin delivery and dosage information; user-entered stress markers or indicators; gesture data (provided by the gesture-based event detection system  104 ) and corresponding date/time stamp information; ancillary user status data (provided by one or more ancillary systems  106 ) and corresponding date/time stamp data; diet or food intake history for the user; and any other information that may be generated by or used by the system  100  for purposes of controlling the operation of the continuous medication delivery system  102 . In certain embodiments, the at least one patient history and outcomes database  114  can receive and maintain training data that is utilized to train, configure, and initialize the system  100  based on historical user behavior, physiological state, operation of the continuous medication delivery system  102  and/or the discrete medication delivery system  103 , and user-identified activity events. 
     A patient history and outcomes database  114  may reside at a user device  108 , at the continuous medication delivery system  102 , at the discrete medication delivery system  103 , at a data processing system  116 , or at any network-accessible location (e.g., a cloud-based database or server system). In certain embodiments, a patient history and outcomes database  114  may be included with the patient care application  110 . The patient history and outcomes database  114  enables the system  100  to generate recommendations, warnings, and guidance for the user and/or to regulate the manner in which the continuous medication delivery system  102  and/or the discrete medication delivery system  103  functions to administer therapy to the user, based on detected changes in the user&#39;s activity (which may be temporary, ongoing for an extended period of time, or somewhat permanent in nature). 
     In accordance with certain embodiments, any or all of the components shown in  FIG. 1  can be implemented as a computer-based or a processor-based device, system, or component having suitably configured hardware and software written to perform the functions and methods needed to support the features described herein. In this regard,  FIG. 6  is a simplified block diagram representation of an exemplary embodiment of a computer-based or processor-based device  300  that is suitable for deployment in the system  100  shown in  FIG. 1  (e.g., user device(s)  108 ). 
     The illustrated embodiment of the device  300  is intended to be a high-level and generic representation of one suitable platform. In this regard, any computer-based or processor-based component of the system  100  can utilize the architecture of the device  300 . The illustrated embodiment of the device  300  generally includes, without limitation: at least one controller (or processor)  302 ; a suitable amount of memory  304  that is associated with the at least one controller  302 ; device-specific items  306  (including, without limitation: hardware, software, firmware, user interface (UI), alerting, and notification features); a power supply  308  such as a disposable or rechargeable battery; a communication interface  310 ; at least one application programming interface (API)  312 ; and a display element  314 . Of course, an implementation of the device  300  may include additional elements, components, modules, and functionality configured to support various features that are unrelated to the primary subject matter described here. For example, the device  300  may include certain features and elements to support conventional functions that might be related to the particular implementation and deployment of the device  300 . In practice, the elements of the device  300  may be coupled together via at least one bus or any suitable interconnection architecture  316 . 
     The at least one controller  302  may be implemented or performed with a general purpose processor, a content addressable memory, a microcontroller unit, a digital signal processor, an application specific integrated circuit, a field programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination designed to perform the functions described here. Moreover, the at least one controller  302  may be implemented as a combination of computing devices, e.g., a combination of a digital signal processor and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a digital signal processor core, or any other such configuration. 
     The memory  304  may be realized as at least one memory element, device, module, or unit, such as: RAM memory, flash memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. In this regard, the memory  304  can be coupled to the at least one controller  302  such that the at least one controller  302  can read information from, and write information to, the memory  304 . In the alternative, the memory  304  may be integral to the at least one controller  302 . As an example, the at least one controller  302  and the memory  304  may reside in an ASIC. At least a portion of the memory  304  can be realized as a computer storage medium that is operatively associated with the at least one controller  302 , e.g., a tangible, non-transitory computer-readable medium having computer-executable instructions stored thereon. The computer-executable instructions are configurable to be executed by the at least one controller  302  to cause the at least one controller  302  to perform certain tasks, operations, functions, and processes that are specific to the particular embodiment. In this regard, the memory  304  may represent one suitable implementation of such computer-readable media. Alternatively or additionally, the device  300  could receive and cooperate with computer-readable media (not separately shown) that is realized as a portable or mobile component or platform, e.g., a portable hard drive, a USB flash drive, an optical disc, or the like. 
     The device-specific items  306  may vary from one embodiment of the device  300  to another. For example, the device-specific items  306  will support: sensor device operations when the device  300  is realized as a sensor device; smartphone features and functionality when the device  300  is realized as a smartphone; activity tracker features and functionality when the device  300  is realized as an activity tracker; smart watch features and functionality when the device  300  is realized as a smart watch; medical device features and functionality when the device is realized as a medical device; etc. In practice, certain portions or aspects of the device-specific items  306  may be implemented in one or more of the other blocks depicted in  FIG. 6 . 
     If present, the UI of the device  300  may include or cooperate with various features to allow a user to interact with the device  300 . Accordingly, the UI may include various human-to-machine interfaces, e.g., a keypad, keys, a keyboard, buttons, switches, knobs, a touchpad, a joystick, a pointing device, a virtual writing tablet, a touch screen, a microphone, or any device, component, or function that enables the user to select options, input information, or otherwise control the operation of the device  300 . The UI may include one or more graphical user interface (GUI) control elements that enable a user to manipulate or otherwise interact with an application via the display element  314 . The display element  314  and/or the device-specific items  306  may be utilized to generate, present, render, output, and/or annunciate alerts, alarms, messages, or notifications that are associated with operation of the medication delivery system  102 , associated with a status or condition of the user, associated with operation, status, or condition of the system  100 , etc. 
     The communication interface  310  facilitates data communication between the device  300  and other components as needed during the operation of the device  300 . In the context of this description, the communication interface  310  can be employed to transmit or stream device-related control data, patient-related user status (e.g., gesture data or status data), device-related status or operational data, sensor data, calibration data, and the like. It should be appreciated that the particular configuration and functionality of the communication interface  310  can vary depending on the hardware platform and specific implementation of the device  300 . In practice, an embodiment of the device  300  may support wireless data communication and/or wired data communication, using various data communication protocols. For example, the communication interface  310  could support one or more wireless data communication protocols, techniques, or methodologies, including, without limitation: RF; IrDA (infrared); Bluetooth; BLE; ZigBee (and other variants of the IEEE 802.15 protocol); IEEE 802.11 (any variation); IEEE 802.16 (WiMAX or any other variation); Direct Sequence Spread Spectrum; Frequency Hopping Spread Spectrum; cellular/wireless/cordless telecommunication protocols; wireless home network communication protocols; paging network protocols; magnetic induction; satellite data communication protocols; wireless hospital or health care facility network protocols such as those operating in the WMTS bands; GPRS; and proprietary wireless data communication protocols such as variants of Wireless USB. Moreover, the communication interface  310  could support one or more wired/cabled data communication protocols, including, without limitation: Ethernet; powerline; home network communication protocols; USB; IEEE 1394 (Firewire); hospital network communication protocols; and proprietary data communication protocols. 
     The at least one API  312  supports communication and interactions between software applications and logical components that are associated with operation of the device  300 . For example, one or more APIs  312  may be configured to facilitate compatible communication and cooperation with the patient care application  110 , and to facilitate receipt and processing of data from sources external to the device  300  (e.g., databases or remote devices and systems). 
     The display element  314  is suitably configured to enable the device  300  to render and display various screens, recommendation messages, alerts, alarms, notifications, GUIs, GUI control elements, drop down menus, auto-fill fields, text entry fields, message fields, or the like. Of course, the display element  314  may also be utilized for the display of other information during the operation of the device  300 , as is well understood. Notably, the specific configuration, operating characteristics, size, resolution, and functionality of the display element  314  can vary depending upon the implementation of the device  300 . 
     As mentioned above, the medication delivery system  102  is suitably configured and programmed to support an automatic mode to automatically control delivery of insulin to the user. In this regard,  FIG. 7  is a simplified block diagram representation of a closed loop glucose control system  400  arranged in accordance with certain embodiments. The system  400  is one example of a system that can be used as part of the continuous medication delivery system  102  of  FIG. 1 . The system  400  depicted in  FIG. 7  functions to regulate the rate of fluid infusion into a body of a user based on feedback from an analyte concentration measurement taken from the body. In particular embodiments, the system  400  is implemented as an automated control system for regulating the rate of insulin infusion into the body of a user based on a glucose concentration measurement taken from the body. The system  400  is designed to model the physiological response of the user to control an insulin infusion device  402  in an appropriate manner to release insulin  404  into the body  406  of the user in a similar concentration profile as would be created by fully functioning human ( 3 -cells when responding to changes in blood glucose concentrations in the body. Thus, the system  400  simulates the body&#39;s natural insulin response to blood glucose levels and not only makes efficient use of insulin, but also accounts for other bodily functions as well since insulin has both metabolic and mitogenic effects. 
     Certain embodiments of the system  400  include, without limitation: the insulin infusion device  402 ; a glucose sensor system  408  (e.g., the analyte sensor  112  shown in  FIG. 1 ); and at least one controller  410 , which may be incorporated in the insulin infusion device  402  as shown in  FIG. 7 . The glucose sensor system  408  generates a sensor signal  414  representative of blood glucose levels  416  in the body  406 , and provides the sensor signal  414  to the at least one controller  410 . The at least one controller  410  receives the sensor signal  414  and generates commands  420  that regulate the timing and dosage of insulin  404  delivered by the insulin infusion device  402 . The commands  420  are generated in response to various factors, variables, settings, and control algorithms utilized by the insulin infusion device  402 . For example, the commands  420  (and, therefore, the delivery of insulin  404 ) can be influenced by a target glucose setpoint value  422  that is maintained and regulated by the insulin infusion device  402 . Moreover, the commands  420  (and, therefore, the delivery of insulin  404 ) can be influenced by any number of adaptive parameters and factors  424 . The adaptive parameters and factors  424  (some of which are described with reference to  FIG. 12 ) may be associated with or used by: a therapy control algorithm of the insulin infusion device  402 ; a digital twin model of the patient, which can be used to recommend insulin dosages; a meal prediction algorithm; a user glucose prediction algorithm; or the like. 
     Generally, the glucose sensor system  408  includes a continuous glucose sensor, sensor electrical components to provide power to the sensor and generate the sensor signal  414 , a sensor communication system to carry the sensor signal  414  to the at least one controller  410 , and a sensor system housing for the electrical components and the sensor communication system. As mentioned above with reference to  FIG. 6 , the glucose sensor system  408  may be implemented as a computer-based or processor-based component having the described configuration and features. 
     Typically, the at least one controller  410  includes controller electrical components and software to generate commands for the insulin infusion device  402  based on the sensor signal  414 , the target glucose setpoint value  422 , the adaptive parameters and factors  424 , and other user-specific parameters, settings, and factors. The at least one controller  410  may include a controller communication system to receive the sensor signal  414  and issue the commands  420 . 
     Generally, the insulin infusion device  402  includes a fluid pump mechanism  428 , a fluid reservoir  430  for the medication (e.g., insulin), and an infusion tube to infuse the insulin  404  into the body  406 . In certain embodiments, the insulin infusion device  402  includes an infusion communication system to handle the commands  420  from the at least one controller  410 , electrical components and programmed logic to activate the fluid pump mechanism  428  motor according to the commands  420 , and a housing to hold the components of the insulin infusion device  402 . Accordingly, the fluid pump mechanism  428  receives the commands  420  and delivers the insulin  404  from the fluid reservoir  430  to the body  406  in accordance with the commands  420 . It should be appreciated that an embodiment of the insulin infusion device  402  can include additional elements, components, and features that may provide conventional functionality that need not be described herein. Moreover, an embodiment of the insulin infusion device  402  can include alternative elements, components, and features if so desired, as long as the intended and described functionality remains in place. In this regard, as mentioned above with reference to  FIG. 6 , the insulin infusion device  402  may be implemented as a computer-based or processor-based components having the described configuration and features, including the display element  214  or other device-specific items  206  as described. 
     The at least one controller  410  is configured and programmed to regulate the operation of the fluid pump mechanism  428  and other functions of the insulin infusion device  402 . The at least one controller  410  controls the fluid pump mechanism  428  to deliver the fluid medication (e.g., insulin) from the fluid reservoir  430  to the body  406 . As mentioned above, the at least one controller  410  can be housed in the infusion device housing, wherein the infusion communication system is an electrical trace or a wire that carries the commands  420  from the at least one controller  410  to the fluid pump mechanism  428 . In alternative embodiments, the at least one controller  410  can be housed in the sensor system housing, wherein the sensor communication system is an electrical trace or a wire that carries the sensor signal  414  from the sensor electrical components to the at least one controller  410 . In accordance with some embodiments, the at least one controller  410  has its own housing or is included in a supplemental or ancillary device. In other embodiments, the at least one controller  410 , the insulin infusion device  402 , and the glucose sensor system  408  are all located within one common housing. 
     Referring again to  FIG. 1 , the gesture-based event detection system  104  employs at least one sensor to obtain corresponding user-specific sensor data. The obtained user-specific sensor data is processed or analyzed by the gesture-based event detection system  104  and/or by another suitably configured device or component of the system  100  to determine whether the user&#39;s current behavior reflects a significant or measurable change in activity, relative to a currently implemented, active, or monitored therapy behavior pattern of the user. The obtained user-specific sensor data may also be processed or analyzed to obtain certain activity-related parameters, characteristics, and/or metadata for the user. For example, the obtained user-specific sensor data may identify, include, or indicate any or all of the following, without limitation: timestamp data corresponding to the occurrence of detected events; a type, category, or classification of the detected physical behavior or activity; location data; user posture or position information; etc. 
     The gesture-based event detection system  104  may include, cooperate with, or be realized as a motion-based physical behavior detection system, an activity-based physical behavior detection system, an image or video-based activity detection system, or the like. In certain embodiments, the system  104  may be realized as a unitary “self-contained” wearable system that communicates with one or more other components of the system  100 . For example, the system  104  can be implemented with at least one wearable device such as an activity monitor device, a smart watch device, a smart bracelet or wristband device, or the like. In some embodiments, the system  104  may be realized as at least one portable or wearable device that includes or communicates with one or more external or ancillary sensor devices, units, or components. For example, the system  104  can be implemented with a wearable or portable smart device that is linked with one or more external sensors worn or carried by the user. These and other possible deployments of the system  104  are contemplated by this disclosure. In this regard, United States patent publication number US 2020/0135320 and United States patent publication number US 2020/0289373 disclose gesture-based event detection systems that are suitable for use as the system  104 ; the entire content of these United States patent documents is incorporated by reference herein. 
       FIG. 8  is a block diagram representation of a gesture-based event detection system  500  arranged in accordance with certain embodiments. The system  500  is suitable for use with the system  100  shown  FIG. 1 . Some or all components of the gesture-based event detection system  500  can be used to implement the gesture-based event detection system  104  of  FIG. 1 . In certain embodiments, the system  500  is deployed as a wearable electronic device in the form factor of a bracelet or wristband that is worn around the wrist or arm of a user&#39;s dominant hand. The system  500  may optionally be implemented using a modular design, wherein individual components or elements include one or more subsets of the disclosed components and overall functionality. The user may choose to add specific components or elements based on personal preferences and requirements. 
     The system  500  includes a battery  502  and a power management unit (PMU)  504  to deliver power at the proper supply voltage levels to all electronic circuits and components. The PMU  504  may also include battery-recharging circuitry. The PMU  504  may also include hardware, such as switches, that allows power to specific electronics circuits and components to be cut off when not in use. 
     When there is no movement-based or gesture-based behavior event in progress, most circuitry and components in the system  500  are switched off to conserve power. Only circuitry and components that are required to detect or help predict the start of a behavior event of interest may remain enabled. For example, if no motion is being detected, all sensor circuits but an accelerometer  506  may be switched off and the accelerometer  506  may be put in a low-power wake-on-motion mode or in another lower power mode that consumes less power and uses less processing resources than its high performance active mode. A controller  508  of the system  500  may also be placed into a low-power mode to conserve power. When motion or a certain motion pattern is detected, the accelerometer  506  and/or the controller  508  may switch into a higher power mode and additional sensors such as, for example, a gyroscope  510  and/or a proximity sensor  512  may also be enabled. When a potential start of a movement-based or gesture-based event is detected, memory variables for storing event-specific parameters, such as gesture types, gesture duration, etc. can be initialized. 
     In another example, upon detection of user motion, the accelerometer  506  switches into a higher power mode, but other sensors remain switched off until the data from the accelerometer  506  indicates that the start of a behavior event has likely occurred. At that point in time, additional sensors such as the gyroscope  510  and the proximity sensor  512  may be enabled. 
     In another example, when there is no behavior event in progress, both the accelerometer  506  and gyroscope  510  are enabled but at least one of either the accelerometer  506  or the gyroscope  510  is placed in a lower power mode compared to their regular power mode. For example, the sampling rate may be reduced to conserve power. Similarly, the circuitry required to transfer data from the system  500  to a destination device may be placed in a lower power mode. For example, radio circuitry  514  could be disabled. Similarly, the circuitry required to transfer data from the system  500  may be placed in a lower power mode. For example, the radio circuitry  514  could be disabled until a possible or likely start of a behavior event has been determined. Alternatively, it may remain enabled but in a low power state to maintain the connection between the system  500  and one or more other components of the system  100 , but without transferring user status data, sensor data, or the like. 
     In yet another example, all motion-detection related circuitry may be switched off if, based on certain metadata, it is determined that the occurrence of a particular behavior event, such as a food intake event, is unlikely. This may be desirable to further conserve power. Metadata used to make this determination may, among other things, include one or more of the following: time of the day, location, ambient light levels, proximity sensing, and detection that the system  500  has been removed from the wrist or hand, detection that the system  500  is being charged, or the like. Metadata may be generated and collected by the system  500 . Alternatively, metadata may be collected by another device that is external to the system  500  and is configured to directly or indirectly exchange information with the system  500 . It is also possible that some metadata is generated and collected by the system  500 , while other metadata is generated and collected by a device that is external to the system  500 . In case some or all of the metadata is generated and collected external to the system  500 , the system  500  may periodically or from time to time power up its radio circuitry  514  to retrieve metadata related information from another device. 
     In certain embodiments, some or all of the sensors may be turned on or placed in a higher power mode if certain metadata indicates that the occurrence of a particular behavior event, such as the user beginning to work, jog, or eat, is likely. Metadata used to make this determination may, among other things, include one or more of the following: time of the day; location; ambient light levels; proximity sensing; historical user behavior patterns. Some or all of the metadata may be collected by the system  500  or by an ancillary device that cooperates or communicates with the system  500 , as mentioned above. 
     User status data used to track certain aspects of a user&#39;s behavior may be stored locally inside memory  516  of the system  500  and processed locally using the controller  508  of the system  500 . User status data may also be transferred to the medication delivery system  102 , the patient care application  110 , and/or one or more of the database  114  mentioned above with reference to  FIG. 1  (such that the user status data can be processed, analyzed, or otherwise utilized by the applications or components that receive the user status data). It is also possible that some of the processing and analysis are performed locally by the system  500 , while further processing and analysis are performed by one or more other components of the system  100 . 
     The detection of the start of a behavior event, such as the start of a work activity, may trigger the power up and/or activation of additional sensors and circuitry, such as a camera  518 . Power up and/or activation of additional sensors and circuitry may occur at the same time as the detection of the behavior event of interest or some time thereafter. Specific sensors and circuitry may be turned on only at specific times during a detected event, and may be switched off otherwise to conserve power. It is also possible that the camera  518  only gets powered up or activated upon explicit user intervention such as, for example, pushing and holding a button  520 . Releasing the button  520  may turn off the camera  518  to conserve power. 
     When the camera  518  is powered up, a projecting light source  522  may also be enabled to provide visual feedback to the user about the area that is within view of the camera or to otherwise illuminate the field of view. Alternatively, the projecting light source  522  may only be activated sometime after the camera  518  has been activated. In certain cases, additional conditions may need to be met before the projecting light source  522  is activated. Such conditions may include: the determination that the projecting light source  522  is likely aiming in the direction of the object of interest; the determination that the system  500  is not moving excessively; or the like. In some embodiments, one or more light emitting diodes (LEDs)  526  may be used as the projecting light source  522 . 
     Images may be tagged with additional information or metadata such as: camera focal information; proximity information from the proximity sensor  512 ; ambient light levels information from an ambient light sensor  524 ; timestamp information; etc. Such additional information or metadata may be used during the processing and analysis of the user status data. 
     The projecting light source  522  may also be used to communicate other information. As an example, an ancillary device may use inputs from one or more proximity sensors  512 , process those inputs to determine if the camera  518  is within the proper distance range from the object of interest, and use one or more light sources to communicate that the camera is within the proper distance range, that the user needs to increase the distance between camera and the object of interest, or that the user needs to reduce the distance between the camera and the object of interest. 
     The projecting light source  522  may also be used in combination with the ambient light sensor  524  to communicate to the user if the ambient light is insufficient or too strong for an adequate quality image capture. The projecting light source  522  may also be used to communicate information including, but not limited to, a low battery situation or a functional defect. 
     The projecting light source  522  may also be used to communicate dietary coaching information. As an example, the projecting light source  522  might, among other things, indicate if not enough or too much time has expired since a previous food intake event, or may communicate to the user how he/she is doing against specific dietary goals. 
     Signaling mechanisms to convey specific messages using one or more projecting light sources  522  may include, but are not limited to, one or more of the following: specific light intensities or light intensity patterns; specific light colors or light color patterns; specific spatial or temporal light patterns. Multiple mechanisms may also be combined to signal one specific message. 
     A microphone  528  may be used by the user to add specific or custom labels or messages to a detected event and/or image. In certain embodiments, audio captured by the microphone  528  can be processed to assist in the determination of whether the user is eating, drinking, commuting, exercising, working, or resting. Audio snippets may be processed by a voice recognition engine. 
     In certain embodiments, the accelerometer  506  (possibly combined with other sensors, including other inertial sensors) may, in addition to tracking at least one parameter that is directly related to a gesture-based behavior event, also be used to track one or more parameters that are not directly related to that particular event. Such parameters may, among other things, include physical activity, sleep, stress, or illness. 
     In addition to the particular sensors, detectors, and components mentioned above, the system  500  may include or cooperate with any number of other sensors  530  as appropriate for the particular embodiment. For example, and without limitation, the system  500  may include or cooperate with any or all of the following: a heartrate monitor; a physiological characteristic or analyte sensor; a continuous glucose monitor; a GPS receiver; and any other sensor, monitor, or detector mentioned elsewhere herein. The system  500  obtains user status data from one or more of its sensors, detectors, and sources, wherein the user status data indicates a stressful activity of the user. The user status data can be analyzed and processed by the system  500  (and/or by one or more other components of the system  100 ) to determine whether the user&#39;s current behavior is consistent with normally expected behavior or activity. In certain embodiments, the system  500  and/or an ancillary system  106  or device determines the user&#39;s activity and related behavior primarily based on the output of user-worn motion sensors, movement sensors, one or more inertial sensors (e.g., one or more accelerometers and/or one or more gyroscopes), one or more GPS sensors, one or more magnetometers, one or more force or physical pressure sensors, or the like, which are suitably configured, positioned, and arranged to measure physical movement or motion of the user&#39;s limbs, digits, joints, facial features, head, and/or other body parts. 
     In some embodiments, the system  500  includes at least one haptic interface  540  that is suitably configured and operated to provide haptic feedback as an output. The at least one haptic interface  540  generates output(s) that can be experienced by the sense of touch by the user, e.g., mechanical force, vibration, movement, temperature changes, or the like. Haptic feedback generated by the at least one haptic interface  540  may represent or be associated with one or more of the following, without limitation: reminders; alerts; confirmations; notifications; messages; numerical values (such as measurements); status indicators; or any other type of output provided by the system  500 . 
     In certain embodiments, the user status data (e.g., sensor data) is provided to a gesture recognizer unit or processor. To this end, sensor data may be sent in raw format. Alternatively, a source of sensor data may perform some processing (e.g., filtering, compression, or formatting) on raw sensor data before sending the processed sensor data to the gesture recognizer unit. The gesture recognizer unit analyzes the incoming sensor data and converts the incoming sensor data into one or more streams of corresponding gestures, which may be predetermined or otherwise classified or categorized. The gesture recognizer unit may use one or more ancillary inputs (such as the output from one or more ancillary systems  106 ) to aid in the gesture determination process. Nonlimiting examples of an ancillary input include: time of day; the probability of a specific gesture occurring based on statistical analysis of historical gesture data for that user; geographical location; heart rate; other physiological sensor inputs. Other ancillary inputs are also possible. 
     The output of the gesture recognizer unit—the detected gestures—can be sent to an event detector or processor. The event detector analyzes the incoming stream of gestures to determine if the start of an event of interest (e.g., eating a meal, going to bed, working out) has occurred, whether an event is ongoing, whether an event has ended, or the like. Although this description mentions meal detection, the gesture-based event detection system  500  may be suitably configured to monitor other types of physical behavior or activities. Such activities include, without limitation: reading; sleeping; smoking; getting dressed; driving; walking; commuting; working; exercising; turning down a bed; making a bed; brushing teeth; combing hair; talking on the phone; inhaling or injecting a medication; and activities related to hand hygiene or personal hygiene. 
       FIG. 9  is a simplified block diagram representation of an embodiment of a gesture-informed patient management system  600 . The depicted patient management system  60  includes, without limitation, one or more sensor units  602 , a gesture recognition unit  604 , an event detection unit  606 , and a patient management unit  608 . Some or all components of the gesture-informed patient management system  600  can be used to implement the gesture-based event detection system  104  of  FIG. 1 . 
     The sensor unit(s)  602  generally represent the sensor(s) embedded in, integrated with, or otherwise associated with one or more portable or wearable devices associated with a patient, such as, for example, an activity tracker, a smart watch, a wristband, a ring, a mobile phone, or a portable electronic medical device (e.g., a continuous glucose monitoring device, an infusion device, an injection pen, and/or the like). For example, in one or more exemplary embodiments, the sensor unit(s)  602  include an accelerometer (e.g., accelerometer  506 ) and a gyroscope (e.g., gyroscope  510 ) associated with a smart watch. That said, it should be appreciated the patient management system  600  is not limited to any particular type, configuration, or number of sensor unit(s)  602 , and in practice, the sensor unit(s)  602  may include one or more of the following sensing arrangements: accelerometers, gyroscopes, magnetometers, image sensors, cameras, optical sensors, proximity sensors, pressure sensors, odor sensors, gas sensors, Global Positioning Systems (GPS) receivers, microphones, galvanic skin response sensors, thermometers, ambient light sensors, UV sensors, electrodes for electromyographic (“EMG”) potential detection, bio-impedance sensors, spectrometers, glucose sensors, heart rate sensors, pulse sensors, touchscreen or capacitive sensors. In this regard, the output of the sensor unit(s)  602  may include any sort of motion data, location data, physiological data (e.g., temperature, heart rate, pulse, galvanic skin response, blood or body chemistry, and/or the like), or other sensor data depending on the sensor type. The output of the sensor unit(s)  602  may be communicated to the gesture recognition unit  604  wirelessly or via wires, in analog or digital form, directly or indirectly (e.g., intermediated by gating and/or clocking circuits, analog-to-digital converters, and/or the like). 
     The gesture recognition unit  604  generally represents a software application or component of the patient management system  600  that receives the sensor data signals from the sensor unit(s)  602  and analyzes the received sensor data to detect or otherwise identify gestures performed by the patient based on the received sensor data. In this regard, a gesture generally represents a discrete set of one or more physical movements having associated spatial and/or temporal characteristics that are distinguishable from other gestures. For example, as described in United States Patent Publication Number 2020/0289373, the gesture recognition unit  604  may utilize machine learning or other artificial techniques to map different subsets of sensor data within one or more streams of received sensor data to different gesture features, which, in turn, are then analyzed to classify or otherwise resolve the different subsets of the sensor data and corresponding gesture features into a particular combination or sequence of gestures performed by the patient. In one or more embodiments, the gesture recognition unit  604  fuses or otherwise combines concurrent or otherwise temporally-associated accelerometer data and gyroscope data to obtain an orientation vector, with the concurrent or temporally-associated combinations of accelerometer data, gyroscope data, and fused orientation vectors being input to a feature generator, which, in turn, generates a corresponding stream of gesture features, which, in turn are input to the gesture recognition model which classifies or otherwise resolves one or more streams of gesture features into corresponding gestures. In exemplary embodiments, the gesture recognition unit  604  also associates or otherwise assigns a confidence metric to each gesture based on the gesture features. In this regard, for a given stream of sensor data received by the gesture recognition unit  604 , the gesture recognition unit  604  outputs a corresponding stream of gestures and associated confidence levels. 
     In some embodiments, the gesture recognition unit  604  receives one or more ancillary inputs  605  which may influence the gesture detection or the confidence or probability assigned to detected gestures. For example, the ancillary input  605  may include operational contextual data, such as, the current time of day, the current day of the week, the current month of the year, the current location of the patient, and/or the like, along with other patient-specific data such as historical gesture data associated with the patient, a patient profile associated with the patient or other patient-specific personalization that may be utilized by the gesture recognition unit  604  to influence manner in which particular gesture features are mapped to a gesture for the particular patient. In this regard, statistical analysis of the historical gesture data and potentially other patient-specific data may be utilized to determine or otherwise assign probabilities of a specific gesture occurring based on the current operational context. It should be noted that there are any number of different types of ancillary input data that may be correlative to the occurrence or non-occurrence of a particular gesture, and the subject matter described herein is not limited to any particular type or combination of ancillary inputs  605  that may be utilized by the gesture recognition unit  604 . 
     In one or more embodiments, the executable code or programming instructions corresponding to the gesture recognition unit  604  is stored or otherwise maintained in a data storage element or memory, including any sort of random access memory (RAM), read only memory (ROM), flash memory, registers, hard disks, removable disks, magnetic or optical mass storage, or any other short or long term storage media or other non-transitory computer-readable medium, which is capable of storing programming instructions for execution by a processor or other processing system. For example, in one or more exemplary embodiments, the computer-executable programming instructions corresponding to the gesture recognition unit  604  are stored in a data storage element (e.g., memory  416 ) of a wearable electronic device including the sensor unit(s)  602 , and, when read and executed by a processing system (e.g., controller  408 ) of the wearable electronic device, the instructions cause the wearable electronic device to generate the gesture recognition unit  604  at the wearable electronic device. In this regard, in some embodiments, the wearable electronic device may transmit or otherwise provide signals or data indicating one or more streams of detected gestures and associated confidence levels to another device for further processing and/or analysis. That said, in other embodiments, the gesture recognition unit  604  may be implemented at or on a patient&#39;s mobile phone or other portable electronic device (e.g., user device  108 ) that receives sensor data signals from the sensor unit(s)  602  via a wireless network, or be implemented at or on a cloud computing system or remote server that receives the sensor data signals from the sensor unit(s)  602  via the Internet, a cellular network, or the like. 
     Still referring to  FIG. 9 , the event detection unit  606  generally represents a software application or component of the patient management system  600  that receives the detected gestures and confidence levels from the from the gesture recognition unit  604  and analyzes the received gesture data to detect or otherwise identify events or activities performed by the patient based on the received gesture data. For example, as described in United States Patent Publication Number 2020/0289373, the event detection unit  606  may utilize machine learning or other artificial techniques to map one or more streams of detected gestures and associated confidence levels into a particular event or activity being performed by the patient based on the type of gestures detected, the sequence of detected gestures, the temporal relationship between gestures and/or the confidence metrics assigned to the detected gestures. In this manner, the event detection unit  606  may map lower-level gestures into a higher-level physical behavior while filtering or otherwise deemphasizing false positives or spurious gestures. Thus, for a given stream of detected gestures received by the event detection unit  606 , the event detection unit  606  outputs an indication of a detected event or activity by the patient and an associated confidence or probability metric for the event. For example, for a sequence of detected food intake gestures may be mapped or otherwise recognized as a food intake event having a particular start time, pace, duration, and/or the like with an assigned level of confidence or probability influenced by the confidence associated with the detected food intake gestures and potentially other factors. 
     In a similar manner as described for the gesture recognition unit  604 , the event detection unit  606  may receive ancillary input  607  which may influence the event detection or the confidence or probability assigned to detected events. For example, the ancillary input  607  may include event log data associated with the patient that maintain data pertaining to historical events or activities by the patient (e.g., meals, exercise, sleep, boluses, glucose excursion events, and/or the like), with statistical analysis of the historical event log data and potentially other patient-specific data being utilized to determine or otherwise assign probabilities of a specific event occurring based on the current operational context. In this regard, if the patient habitually engages in meals at or around a certain time of day, food intake gestures occurring at that time of day consistent with the patient&#39;s historical behavior may be more likely to be mapped to a meal event or other food intake event, or the detected meal event or food intake event may be assigned a higher probability or confidence value based on the consistency with the patient&#39;s historical behavior. Again, it should be noted that there are any number of different types of ancillary input data that may be correlative to the occurrence or non-occurrence of a particular event, and the subject matter described herein is not limited to any particular type or combination of ancillary inputs  607  that may be utilized by the event detection unit  606 . 
     In one or more embodiments, the executable code or programming instructions corresponding to the event detection unit  606  is stored or otherwise maintained in a data storage element or memory, including any sort of short or long term storage media or other non-transitory computer-readable medium, which is capable of storing programming instructions for execution by a processor or other processing system. For example, in one or more exemplary embodiments, the computer-executable programming instructions corresponding to the event detection unit  606  are stored in a data storage element (e.g., memory  516 ) of a wearable electronic device including the sensor unit(s)  602 , and, when read and executed by a processing system (e.g., controller  508 ) of the wearable electronic device, the instructions cause the wearable electronic device to generate the event detection unit  606  at the wearable electronic device. In this regard, in some embodiments, the wearable electronic device may transmit or otherwise provide signals or data indicating one or more streams of detected events and associated confidence or probability levels to another device for further processing and/or analysis. That said, in other embodiments, the event detection unit  606  may be implemented at or on a patient&#39;s mobile phone or other portable electronic device (e.g., user device  108 ) or on a cloud computing system or remote server that receives gesture data signals from the gesture recognition unit  604  implemented at another device via a network. 
     Still referring to  FIG. 9 , the patient management unit  608  generally represents a software application or component of the patient management system  600  that receives the detected event data from the event detection unit  606  and automatically initiates or otherwise performs one or more actions with respect to management of the patient&#39;s physiological condition. In some embodiments, the patient management unit  608  is configurable to support one or more autonomous operating modes for an infusion device, a smart pen, or other fluid delivery device, where the patient management unit  608  calculates or otherwise determines dosage commands for operating an actuation arrangement to deliver fluid to the patient. For example, in a closed-loop operating mode, the patient management unit  608  may determine a dosage command based at least in part on a current glucose measurement value for the patient in a manner that is influenced by an event detected by the event detection unit  606 . In some embodiments, the patient management unit  608  is configurable to generate or otherwise provide user notifications or alerts via a user interface element based at least in part on a detected event. In this regard, the patient management  608  application may utilize patient-specific settings, preferences, or other notification criteria to automatically generate user notifications in a manner that is influenced by the detected event and potentially other factors (e.g., the patient&#39;s current or recent sensor glucose measurement values). 
     In one or more embodiments, the executable code or programming instructions corresponding to the patient management unit  608  is stored or otherwise maintained at one of the patient&#39;s associated devices (e.g., the patient&#39;s mobile phone, the patient&#39;s infusion device or other fluid delivery device, or the like) or at a cloud computing system or remote server. For example, the patient management unit  608  executing on the patient&#39;s phone may receive or otherwise obtain signals or data indicating detected gestures and/or events from the patient&#39;s smart watch or other wearable device, analyze the received data, and transmit or otherwise provide dosage commands or signals influenced by the detected gestured-based events to the patient&#39;s infusion device (e.g., via a wireless network) to automatically operate the infusion device to deliver insulin or another fluid or medicament to account for the detected event(s), or the patient management unit  608  may generate GUI displays or other user notifications influenced by the detected event(s) at the mobile device. That said, in other embodiments, when the patient management unit  608  is implemented at a remote server or other cloud computing system, the patient management unit  608  may transmit or otherwise provide dosage commands or signals to a device associated with the patient via a network. In yet other embodiments, the patient management unit  608  may be implemented at the patient&#39;s medical device and receive detected event data from the patient&#39;s mobile device, the patient&#39;s wearable device, or a remote server or other cloud computing system. In this regard, depending on the embodiment, the various units  604 ,  606 ,  608  may be distributed across one or more different devices  102 ,  103 ,  104 ,  106 ,  108 ,  111 ,  112 ,  114 ,  116  in a system  100  and the subject matter described herein is not limited to any particular implementation. 
       FIG. 10A  is block diagram illustrating a system  700  for classifying detected events in accordance with certain embodiments. The system  700  includes an event detection system  707  and a server system  716  that includes an event classifier  720  and storage  723 . The server system  716  includes an event classifier  720  that executes an event-to-output mapping process  722 , and storage  723 . 
     The event detection system  702  can include, for example, a gesture detection system  704 , an activity tracker device  706 , and a meal tracking system  708 , which are some of the components of the event detection system  107  described with respect to  FIG. 1 , the gesture-based event detection system  500  described with respect to  FIG. 8 , the gesture-informed patient management system  600  described with respect to  FIG. 9 . However, it should be appreciated that the gesture detection system  704 , the activity tracker device  706 , and the meal tracking system  708  are non-limiting examples of the systems and devices that can be part of the event detection system  107  of  FIG. 1 . Although not illustrated, the system  700  can also include other systems and components that can be part of the event detection system  107  of  FIG. 1 , the gesture-based event detection system  500  of  FIG. 8 , and the gesture-informed patient management system  600  of  FIG. 9 . The server system  716  (having an event classifier  720 ) can be implemented using any of the event classification service  111 , the database  114  and the data processing system  116  described with respect to  FIG. 1 . These devices and systems are described with reference to  FIGS. 1-9 , and for sake of brevity, the description of these devices and systems will not be repeated. 
     Depending on the implementation, the event detection system  707  can be implemented at the server system  716  or at another computer-based system that is distinct from the server system  716 . The event detection system  707  generates various detected events. In this particular non-limiting example, the event detection system  707  includes a gesture detection system  704 , an activity tracker device  706 , a meal tracking system  708 . In this particular non-limiting example, detected events  710  can include gesture-related events and associated data for each gesture-related event, activity-related events and associated data each activity-related event, and meal events and associated data for each meal event. 
     The server system  716  receives different detected events (and data associated with each detected event) from the event detection system  707 . As used herein, an “event” can refer to a specific condition or activity that is detectable and indicative of a physical behavior of a user (or that is associated with a physical behavior of a user). Events can be input by a user, measured or detected by a sensor-based system, or estimated or predicted by a model or system, such as a mathematical model or artificial intelligence (AI) based system. In addition, events can be recorded in a database and later used for the various purposes described herein. Each event can potentially impact physiological glucose dynamics of the specific user and can be correlated to a change in an insulin demand of the specific user and/or blood glucose levels of the specific user. As will be explained in greater detail below, the input data for detected events can include data regarding a specific condition or activity that is detectable and indicative of a physical behavior of the specific user. 
     Non-limiting examples of specific conditions or activities that are indicative of the physical behavior of the specific user can include, but are not limited to, for example, meal ingestion events and related data that describes such events including meal timing, meal duration, meal content, amounts of calories or macronutrients consumed by the specific user as part of a meal, etc.; sleep events and related data that describes such events including timing, duration, quality of sleep, etc.; physical activity events and related data (including sports activities) that describes such events including timing of physical activity, duration of physical activity, exertion levels and patterns that describe physical activity, intensity levels and patterns that describe physical activity, etc.; exercise events and related data that describes such events including timing, duration, amounts, intensity, etc. and work-related events and related data that describes such events including timing, duration, amounts, intensity, etc. 
     For example, in accordance with the embodiment illustrated in  FIG. 10A , the input data for detected events can include gesture-related event data  712  from the gesture detection system  704 , which can include meal data, exercise data, sleep data, etc.; activity-related data  714  detected using the activity tracker device  706 , which can include physical activity data, exercise data, sleep data, etc.; meal event data  715  from the meal tracking system  708 , which can include carbohydrate intake data for the specific user. 
     The detected events can be stored and processed at the server system  716 . The server system  716  can group the detected events into different combinations of detected events. For instance, in one embodiment, when multiple events are detected by the event detection system  707  these can be grouped together by the event classifier  720  and can be collectively referred to as a combination of detected events  710 . The event classifier  720  can store each detected event and each combination of detected events  710  in storage  723 . The detected events and different combinations of detected events can then be further processed at an event classifier  720  as will be described below. There is no limitation on the combination of detected events that can be detected by the event detection system  707  and processed by the event classifier  720  in ways that are not trivial humans but capable of being classified. Simple events, such as geolocation and time of the day, for example, can indicate that a user is going to lunch or going to gym which will have opposite effect. In another example, events that indicate that a user is waking up from sleep combined with blood glucose levels can indicate a potential for hyperglycemia if user wakes up for a drink of water or potential hypoglycemia if user wakes up but his blood glucose is low and therefore might consume carbohydrates. Other less trivial examples may include seasonal effects and body temperature to evaluate the chances of some mild sickness that may increase insulin demands. As another example, a user&#39;s level of physical activity combined with type of meals the user consumes can help predict potential hyperglycemia or potential hypoglycemia overnight. As another example, a user&#39;s heartrate and activity can be mapped to stress which may increase insulin demand. 
     Each detected event can potentially impact physiological glucose dynamics of the specific user, and hence a user&#39;s insulin demand. An event can be correlated, for example, to a change in one or more of an insulin demand (including predicted insulin demand) of the specific user and/or blood glucose levels of the specific user. Each detected event (or combination of detected events) can be associated with a probability of a decreased insulin delivery demand, a probability of an increased insulin delivery demand for that event (or particular combination of detected events), or a probability that insulin delivery demand will not change. As such, detected events can be used to predict periods or increases or decreased insulin demand. 
     The event classifier  720  executes an event-to-output mapping process  722  that processes each combination of detected events (also referred to herein as “event combination”) to predict an impact on blood glucose levels and insulin demand of a specific user, and maps each combination of detected events to a corresponding classifier output  724 . 
     For example, in one embodiment, the event-to-output mapping process  722  of the event classifier  720  can map the combinations of detected events to a probability of an increased insulin delivery demand for the specific user or a probability of a decreased insulin delivery demand for the specific user. The event classifier  720  can compute a probability for each combination of detected events including physiological conditions that indicate a likelihood of hypoglycemia, physiological conditions that indicate a likelihood of hyperglycemia, or physiological conditions that indicate a nominal condition. The computed likelihood of hyperglycemia and hypoglycemia can be further divided into mild and severe likelihoods. Based on these predicted physiological conditions, an action taken by the controller could be more or less insulin delivery, but not just limited to insulin delivery. At times suspending insulin delivery may not be enough and other actions should be taken (e.g., taking carbs during exercise). 
     For example, in one implementation, the classifier output  724  can include instructions to either: decrease insulin delivery when the combination of detected events is associated with the probability of the decreased insulin delivery demand and the probability of the decreased insulin delivery demand is greater than the first threshold; increase insulin delivery when the combination of detected events is associated with the probability of the increased insulin delivery demand and the probability of the increased insulin delivery demand is greater than the second threshold; or maintain ordinary or nominal insulin delivery by maintaining the insulin delivery in a nominal state (e.g., maintain insulin delivery by the controller in a nominal state) when the probability of the decreased insulin delivery demand is less than the first threshold and the probability of the increased insulin delivery demand is less than the second threshold. 
     Each classifier output  724  includes information for controlling the medical device  702  to either increase insulin delivery to the specific user by a certain amount, leave insulin delivery to the specific user at its normal or ordinary level by maintaining the insulin delivery in a nominal state (e.g., maintain insulin delivery by the controller in a nominal state), or decrease insulin delivery to the specific user by a certain amount. 
     In some embodiments, the classifier output  724  can include or be processed to derive therapy parameters and settings that can cause the controller  726  of the medical device  702  to either: decrease insulin delivery when the combination of detected events is associated with the probability of the decreased insulin delivery demand and the probability of the decreased insulin delivery demand is greater than the first threshold, increase insulin delivery when the combination of detected events is associated with the probability of the increased insulin delivery demand and the probability of the increased insulin delivery demand is greater than the second threshold, or maintain ordinary insulin delivery by maintaining the insulin delivery in a nominal state when the probability of the decreased insulin delivery demand is less than the first threshold and the probability of the increased insulin delivery demand is less than the second threshold (e.g., maintain insulin delivery by the controller in a nominal state). 
     In some embodiments, insulin delivery demand can be associated with a predicted glycemic outcome. For instance, in some cases, the insulin delivery demand can be associated with a predicted glycemic outcome that indicates: a probability of an upcoming hyperglycemic condition that would increase insulin delivery demand when the probability is greater than or equal to a threshold, or a probability of an upcoming hypoglycemic condition that would reduce insulin delivery demand when the probability is greater than or equal to another threshold. As will be explained below, when a particular event combination collectively indicates that the probability of a hypoglycemic condition is more likely to occur or be coming up (e.g., greater than or equal to a threshold), then the controller  726  can switch to a more conservative mode and deliver less insulin. When a particular event combination collectively indicates that the probability of a hyperglycemic condition is more to occur or be coming up (e.g., greater than or equal to a threshold), then the controller  726  can switch to a more aggressive mode and deliver more insulin. In other cases, the insulin delivery demand is not associated with a predicted glycemic outcome. 
     In some embodiments, once a particular, pre-defined event category has been identified (based on detected events and/or historical patterns, and depending on how the category has been classified, such as high likelihood of hyperglycemia, or high likelihood of hypoglycemia, the controller can be made more or less conservative based on the particular, pre-defined event category. This can be achieved by combination of multiple factors, some of which are: adjusting setpoint(s), adjusting constraints on insulin delivery, adjusting some of the parameters of the controller, etc. 
     Referring again to  FIG. 10A , the classifier outputs  724  generated by the event-to-output mapping process  722  can be stored in storage  723  of the server system  716  to create a database of classified outputs. To explain further, when the classifier outputs  724  that were generated by the event classifier  720  are stored in the database they can be referred to as “classified” outputs. Each “classified” output includes all of the information that makes up its corresponding classifier output plus additional identifying information that associates it with a particular event combination. In other words, the database can store a corresponding classified output for each event combination. As will be explained below, once the database of classified outputs is created, and an event combination is detected, the database can be accessed to retrieve a corresponding classified output. 
     The implementation of the classifier  720  can vary depending on the embodiment. In general terms, the classifier  720  can be implemented using any number of machine learning algorithms and statistical models that will now be described below. Machine learning (ML) algorithms and statistical models can relying on patterns and inference instead of using explicit instructions. Machine learning algorithms build a mathematical model based on sample data, known as “training data,” in order to make predictions or decisions without being explicitly programmed to perform the task. For example, supervised learning algorithms build a mathematical model of a set of data that contains both the inputs and the desired outputs. The data is known as training data and consists of a set of training examples. Each training example has one or more inputs and a desired output, also known as a supervisory signal. In the case of semi-supervised learning algorithms, some of the training examples are missing the desired output. In the mathematical model, each training example is represented by an array or vector, and the training data by a matrix. Through iterative optimization of an objective function, supervised learning algorithms learn a function that can be used to predict the output associated with new inputs. An optimal function will allow the algorithm to correctly determine the output for inputs that were not a part of the training data. An algorithm that improves the accuracy of its outputs or predictions over time is said to have learned to perform that task. Supervised learning algorithms include classification and regression. Classification algorithms are used when the outputs are restricted to a limited set of values, and regression algorithms are used when the outputs may have any numerical value within a range. Similarity learning is an area of supervised machine learning closely related to regression and classification, but the goal is to learn from examples using a similarity function that measures how similar or related two objects are. 
     In predictive modeling and other types of data analytics, ensemble methods can use multiple machine learning algorithms to obtain better predictive performance than could be obtained from any of the constituent learning algorithms alone. An ensemble is a supervised learning algorithm because it can be trained and then used to make predictions. The trained ensemble, therefore, represents a single hypothesis that is not necessarily contained within the hypothesis space of the models from which it is built. Thus, ensembles can be shown to have more flexibility in the functions they can represent. An ensemble model can include a set of individually trained classifiers (such as neural networks or decision trees) whose predictions are combined. 
     For instance, one common example of ensemble modeling is a random forest model which is a type of analytical model that leverages multiple decision trees and is designed to predict outcomes based on different variables and rules. A random forest model blends decision trees that may analyze different sample data, evaluate different factors or weight common variables differently. The results of the various decision trees are then either converted into a simple average or aggregated through further weighting. The emergence of Hadoop and other big data technologies has allowed greater volumes of data to be stored and analyzed, which can allow analytical models to be run on different data samples. 
     Depending on the implementation, any number of machine learning models can be combined to optimize the ensemble model. Examples of machine learning algorithms or models that can be implemented at the machine learning model can include, but are not limited to: regression models such as linear regression, logistic regression, and K-means clustering; one or more decision tree models (e.g., a random forest model); one or more support vector machines; one or more artificial neural networks; one or more deep learning networks (e.g., at least one recurrent neural network, sequence to sequence mapping using deep learning, sequence encoding using deep learning, etc.); fuzzy logic based models; genetic programming models; Bayesian networks or other Bayesian techniques, probabilistic machine learning models; Gaussian processing models; Hidden Markov models; time series methods such as Autoregressive Moving Average (ARMA) models, Autoregressive Integrated Moving Average (ARIMA) models, Autoregressive conditional heteroskedasticity (ARCH) models; generalized autoregressive conditional heteroskedasticity (GARCH) models; moving-average (MA) models or other models; and heuristically derived combinations of any of the above, etc. The types of machine learning algorithms differ in their approach, the type of data they input and output, and the type of task or problem that they are intended to solve. 
     A Hidden Markov model (HMM) is a statistical Markov model in which the system being modeled is assumed to be a Markov process with unobserved (hidden) states. An HMI can be considered as the simplest dynamic Bayesian network. A Bayesian network, belief network or directed acyclic graphical model is a probabilistic graphical model that represents a set of random variables and their conditional independence with a directed acyclic graph (DAG). Bayesian networks that model sequences of variables are called dynamic Bayesian networks. Generalizations of Bayesian networks that can represent and solve decision problems under uncertainty are called influence diagrams. 
     Support vector machines (SVMs), also known as support vector networks, are a set of related supervised learning methods used for classification and regression. Given a set of training examples, each marked as belonging to one of two categories, an SVM training algorithm builds a model that predicts whether a new example falls into one category or the other. An SVM training algorithm is a non-probabilistic, binary, linear classifier. In addition to performing linear classification, SVMs can efficiently perform a non-linear classification using what is called the kernel trick, implicitly mapping their inputs into high-dimensional feature spaces. 
     Decision tree learning uses a decision tree as a predictive model to go from observations about an item (represented in the branches) to conclusions about the item&#39;s target value (represented in the leaves). Tree models where the target variable can take a discrete set of values are called classification trees; in these tree structures, leaves represent class labels and branches represent conjunctions of features that lead to those class labels. Decision trees where the target variable can take continuous values (typically real numbers) are called regression trees. In decision analysis, a decision tree can be used to visually and explicitly represent decisions and decision making. 
     Deep learning algorithms can refer to a collection of algorithms used in machine learning, that are used to model high-level abstractions and data through the use of model architectures, which are composed of multiple nonlinear transformations. Deep learning is a specific approach used for building and training neural networks. Deep learning consists of multiple hidden layers in an artificial neural network. Examples of deep learning algorithms can include, for example, Siamese networks, transfer learning, recurrent neural networks (RNNs), long short term memory (LSTM) networks, convolutional neural networks (CNNs), transformers, etc. For instance, deep learning approaches can make use of autoregressive Recurrent Neural Networks (RNN), such as the long short-term memory (LSTM) and the Gated Recurrent Unit (GRU). One neural network architecture for time series forecasting using RNNs (and variants) is an autoregressive seq 2 seq neural network architecture, which acts as an autoencoder. 
     In some embodiments, the ensemble model can include one or more deep learning algorithms. It should be noted that any number of different machine learning techniques may also be utilized. Depending on the implementation, the ensemble model can be implemented as a bootstrap aggregating ensemble algorithm (also referred to as a bagging classifier method), as a boosting ensemble algorithm or classifier algorithm, as a stacking ensemble algorithm or classifier algorithm, as bucket of models ensemble algorithms, as Bayes optimal classifier algorithms, as Bayesian parameter averaging algorithms, as Bayesian model combination algorithms, etc. 
     Bootstrap aggregating, often abbreviated as bagging, involves having each model in the ensemble vote with equal weight. In order to promote model variance, bagging trains each model in the ensemble using a randomly drawn subset of the training set. As an example, the random forest algorithm combines random decision trees with bagging to achieve very high classification accuracy. A bagging classifier or ensemble method creates individuals for its ensemble by training each classifier on a random redistribution of the training set. Each classifier&#39;s training set can be generated by randomly drawing, with replacement, N examples—where N is the size of the original training set; many of the original examples may be repeated in the resulting training set while others may be left out. Each individual classifier in the ensemble is generated with a different random sampling of the training set. Bagging is effective on “unstable” learning algorithms (e.g., neural networks and decision trees), where small changes in the training set result in large changes in predictions. 
     By contrast, boosting involves incrementally building an ensemble by training each new model instance to emphasize the training instances that previous models mis-classified. In some cases, boosting has been shown to yield better accuracy than bagging, but it also tends to be more likely to over-fit the training data. A boosting classifier can refer to a family of methods that can be used to produce a series of classifiers. The training set used for each member of the series is chosen based on the performance of the earlier classifier(s) in the series. In boosting, examples that are incorrectly predicted by previous classifiers in the series are chosen more often than examples that were correctly predicted. Thus, boosting attempts to produce new classifiers that are better able to predict examples for which the current ensemble&#39;s performance is poor. A common implementation of boosting is Adaboost, although some newer algorithms are reported to achieve better results. 
     Stacking (sometimes called stacked generalization) involves training a learning algorithm to combine the predictions of several other learning algorithms. Stacking works in two phases: multiple base classifiers are used to predict the class, and then a new learner is used to combine their predictions with the aim of reducing the generalization error. First, all of the other algorithms are trained using the available data, then a combiner algorithm is trained to make a final prediction using all the predictions of the other algorithms as additional inputs. If an arbitrary combiner algorithm is used, then stacking can theoretically represent any of the ensemble techniques described in this article, although, in practice, a logistic regression model is often used as the combiner. 
     A “bucket of models” is an ensemble technique in which a model selection algorithm is used to choose the best model for each problem. When tested with only one problem, a bucket of models can produce no better results than the best model in the set, but when evaluated across many problems, it will typically produce much better results, on average, than any model in the set. One common approach used for model-selection is cross-validation selection (sometimes called a “bake-off contest”). Cross-validation selection can be summed up as try them all with the training set and pick the one that works best. Gating is a generalization of Cross-Validation Selection. It involves training another learning model to decide which of the models in the bucket is best-suited to solve the problem. Often, a perceptron is used for the gating model. It can be used to pick the “best” model, or it can be used to give a linear weight to the predictions from each model in the bucket. When a bucket of models is used with a large set of problems, it may be desirable to avoid training some of the models that take a long time to train. Landmark learning is a meta-learning approach that seeks to solve this problem. It involves training only the fast (but imprecise) algorithms in the bucket, and then using the performance of these algorithms to help determine which slow (but accurate) algorithm is most likely to do best. 
     The Bayes optimal classifier is a classification technique. It is an ensemble of all the hypotheses in the hypothesis space. On average, no other ensemble can outperform it. The naive Bayes optimal classifier is a version of this that assumes that the data is conditionally independent on the class and makes the computation more feasible. Each hypothesis is given a vote proportional to the likelihood that the training dataset would be sampled from a system if that hypothesis were true. To facilitate training data of finite size, the vote of each hypothesis is also multiplied by the prior probability of that hypothesis. The hypothesis represented by the Bayes optimal classifier, however, is the optimal hypothesis in ensemble space (the space of all possible ensembles. 
     Bayesian parameter averaging (BPA) is an ensemble technique that seeks to approximate the Bayes optimal classifier by sampling hypotheses from the hypothesis space and combining them using Bayes&#39; law. Unlike the Bayes optimal classifier, Bayesian model averaging (BMA) can be practically implemented. Hypotheses are typically sampled using a Monte Carlo sampling technique such as MCMC. For example, Gibbs sampling may be used to draw hypotheses that are representative of a distribution. It has been shown that under certain circumstances, when hypotheses are drawn in this manner and averaged according to Bayes&#39; law, this technique has an expected error that is bounded to be at most twice the expected error of the Bayes optimal classifier. 
     Bayesian model combination (BMC) is an algorithmic correction to Bayesian model averaging (BMA). Instead of sampling each model in the ensemble individually, it samples from the space of possible ensembles (with model weightings drawn randomly from a Dirichlet distribution having uniform parameters). This modification overcomes the tendency of BMA to converge toward giving all of the weight to a single model. Although BMC is somewhat more computationally expensive than BMA, it tends to yield dramatically better results. The results from BMC have been shown to be better on average (with statistical significance) than BMA, and bagging. The use of Bayes&#39; law to compute model weights necessitates computing the probability of the data given each model. Typically, none of the models in the ensemble are exactly the distribution from which the training data were generated, so all of them correctly receive a value close to zero for this term. This would work well if the ensemble were big enough to sample the entire model-space, but such is rarely possible. Consequently, each pattern in the training data will cause the ensemble weight to shift toward the model in the ensemble that is closest to the distribution of the training data. It essentially reduces to an unnecessarily complex method for doing model selection. The possible weightings for an ensemble can be visualized as lying on a simplex. At each vertex of the simplex, all of the weight is given to a single model in the ensemble. BMA converges toward the vertex that is closest to the distribution of the training data. By contrast, BMC converges toward the point where this distribution projects onto the simplex. In other words, instead of selecting the one model that is closest to the generating distribution, it seeks the combination of models that is closest to the generating distribution. The results from BMA can often be approximated by using cross-validation to select the best model from a bucket of models. Likewise, the results from BMC may be approximated by using cross-validation to select the best ensemble combination from a random sampling of possible weightings. 
     Referring again to  FIG. 10 , each labeled event and each labeled event combination can be stored in storage  728  as a database of labeled events and labeled event combinations. Selected ones of the labeled events and/or selected ones of the labeled event combinations can be processed at a client application  740  to generate an output result. The client application  740  can vary depending on the implementation, and can include any number of different client applications. In the context of insulin therapy management, non-limiting examples of client applications that can be improved or optimized by enriching the input data (e.g., using selected ones of the labeled events and/or labeled event combinations) can include, but are not limited to: a mathematical model that represents the physiology of a user, a controller for an insulin infusion device, a healthcare management application (e.g., for insulin therapy management), an application for calibrating an insulin therapy system of a user, etc. 
     When the client application  740  is a controller for an insulin infusion device  702 , selected ones of the labeled events and/or labeled event combinations can be processed at the controller to generate one or more therapy parameters for controlling delivery of insulin via the insulin infusion device  702 . Non-limiting examples of therapy parameters can include a basal profile, an active insulin time, an insulin sensitivity factor of the user, an insulin-to-carbohydrate ratio for the user, and the like. The controller can then generate, based on the one or more therapy parameters, controller tuning instructions that influence delivery of insulin via the insulin infusion device  702 . Non-limiting examples of therapy parameters can include a basal profile, an active insulin time, an insulin sensitivity factor of the user, an insulin-to-carbohydrate ratio for the user, etc. 
     As used herein, the term “basal insulin” can refer to a therapy setting for an insulin infusion device that specifies an hourly, continuous infusion of insulin delivered automatically by an insulin infusion device based on preprogrammed profiles and personalized rates set in the insulin infusion device. The insulin infusion device delivers a daily infusion of insulin that typically covers “background” insulin needs during periods of fasting (e.g., overnight and between meals). The basal profile can include at least one basal rate setting for the user that indicates a rate of continuous insulin infusion delivered to the user to keep blood glucose of the user stable during fasting periods. As used herein, the term “basal rate” can refer to a therapy setting for an insulin infusion device that provides a delivery rate that indicates a continuous infusion of insulin to keep blood glucose stable, for example, between meals and during the night for a specific patient. Basal insulin mimics pancreatic insulin delivery, which meets all the body&#39;s non-food related insulin needs. A basal rate profile can define a plurality of basal rates corresponding to a plurality of time segments (e.g., during a 24-hour day). As used herein, the term “a maximum basal rate” can refer to a therapy setting for an insulin infusion device that specifies a maximum amount of basal insulin that an insulin infusion device should deliver at one time for a specific patient. 
     As used herein, the term “active insulin” or “insulin on board (IOB)” can refer to bolus insulin that has been delivered to a user&#39;s body, but that has not yet been used by the patient. For example, active insulin can refer to how much insulin is still active inside the body from the previous bolus dose. Stated differently, the active insulin time can indicate an amount of time a bolus of insulin remains active in a user after injection. As used herein, the term “active insulin time” can refer to a therapy setting for an insulin infusion device that specifies a duration of insulin action in a specific user&#39;s body, or an amount of time insulin remains working in a specific user&#39;s body after a bolus of rapid acting insulin. Active insulin time (sometime also referred to as duration of insulin action (DIA)) can refer to how long a bolus of insulin takes to be absorbed by a user&#39;s body and finish lowering blood glucose. The time starts when a bolus is given and ends when the bolus is no longer lowering blood glucose levels. An accurate active insulin time can help minimize insulin stacking and low blood sugar (hypoglycemia), which can happen when boluses are given too close together. Active insulin time varies from person to person. As used herein, the term “a maximum bolus limit” can refer to a therapy setting for an insulin infusion device that specifies a maximum amount of bolus insulin that an insulin infusion device should deliver at one time for a specific patient. 
     As used herein, the term “insulin sensitivity factor (ISF)” or “correction factor” can refer to a therapy setting for an insulin infusion device that specifies an amount that a specific user&#39;s blood glucose (BG) level (e.g., in mg/dL or mmol/L) is reduced by one unit of insulin. In other words, ISF can indicate how much one unit of insulin is expected to lower blood sugar, and can describe the amount of bolus that is delivered per 1 mg/dL deviation of glucose from a target glucose value. 
     As used herein, the term “insulin-to-carbohydrate ratio” can refer to a therapy setting for an insulin infusion device that specifies an amount of insulin required to cover a given number of carbohydrates. For instance, the insulin-to-carbohydrate ratio can indicate an amount of bolus insulin that is delivered per one unit of carbohydrate intake. In other words, insulin-to-carbohydrate ratio can refer to the number of grams of carbohydrates “covered” by one unit of insulin. By contrast, the carbohydrate-to-insulin ratio for a user indicates a ratio of an amount of carbohydrates in grams covered by one unit of insulin. 
     As used herein, the term “total daily dose (TDD)” can refer to a number on insulin units that a user of an insulin infusion device uses (e.g., on average) per day. The total daily dose of insulin can be computed based on the total basal insulin delivered to the user and total bolus insulin delivered to the user. As used herein, the term “bolus insulin” can refer to a therapy setting for an insulin infusion device that specifies a dose of insulin for a specific patient that is needed to cover an expected rise in blood glucose (such as the rise after a meal or a snack) or to lower a high blood glucose down to target range. Target blood glucose or “target range” indicates a desired blood glucose level. It can be entered into an insulin infusion device as a single target for the entire day (e.g., 120 mg/dl) or as a range (e.g., 100-120 mg/dl). Many insulin infusion devices have a built-in bolus calculator that calculates how much insulin to take for a meal or for correcting blood sugars. Bolus calculator settings can include: target blood glucose/range; insulin-to-carbohydrate ratio (I:C) or carbohydrate-to-insulin (C:I) ratio; insulin sensitivity factor (ISF) or correction factor; active insulin time or duration of insulin action (DIA), and insulin on board (IOB). 
     The total daily dose may be computed using insulin delivery data, including basal insulin and insulin bolus amounts, along with their associated time data (time/date stamps). The total daily dose can be used to compute the patient&#39;s insulin sensitivity factor (ISF), which is expressed in mg/dL/Unit, and/or insulin-to-carbohydrate ratio (I:C). 
       FIG. 10B  is block diagram illustrating a system  750  for controlling insulin delivery to a specific user of a medical device based on detected events associated with a specific user in accordance with certain embodiments. The system  750  includes an event detection system  707 , a medical device  702  (e.g., an insulin infusion device) of a user, an optional user device  708  and a server system  716  that includes storage  723  that stores a database  740  of classified outputs. As will be explained below, the medical device  702  of the user can be controlled based on classified outputs stored in the database  740 . The classified outputs correspond to the classifier outputs  724  that were generated by the event classifier  720  of  FIG. 10A . 
     The medical device  702  includes a controller  726  and an insulin delivery system  730 . The medical device  702  can be implemented using a continuous insulin therapy system  102  or a discrete insulin therapy system  103  as described with respect to  FIG. 1 , the insulin infusion device  146  of  FIG. 3A , the smart insulin pen  160  described with respect to  FIG. 3B , the smart pen accessory  170  described with respect to  FIG. 4 , or the injection pen  200  described with respect to  FIG. 5 . The medical device  702  can also be implemented in conjunction with an analyte sensor (not illustrated in  FIG. 10B ), such as the analyte sensor  112  described with respect to  FIG. 1 , the glucose sensor system  408  described with respect to  FIG. 7  and/or a continuous glucose monitoring device of  FIG. 9 . 
     Although  FIG. 10B  illustrates one embodiment where the database  740  shown as being located at a remote server system  716 , it should be appreciated that the server system  716  and/or the database  740 , can be implemented at the medical device  702 , at the event detection system  707 , or at the user device  708  depending on the implementation. 
     For example, in one implementation, the database  740  of classified outputs can be stored at the medical device  702 . This way, when the medical device  702  receives an indication that a particular combination of events has been detected, an application at the medical device  702  can retrieve the corresponding classified output for that particular combination of detected events. 
     In some embodiments, the database  740  of classified outputs can be stored at another device (such as user device  708 ) associated with the medical device  702 . This way, when a particular combination of events is detected, an application at the other device  708  can retrieve the corresponding classified output for that particular combination of detected events, and provide it to the medical device  702 . 
     In some embodiments, when a particular combination of events is detected, an application at the medical device  702  or another device  708  associated with the medical device  702  can retrieve a corresponding classified output from a database  740  maintained at a remote server system  716 . 
     Each time a combination of events (or “event combination”) is detected, the database  740  of classified outputs can be accessed to retrieve a particular classified output corresponding to that combination of events. Each classified output  724  that is retrieved can be processed by the controller  726  of the medical device  702 . 
     Based on the classified output  724 , the controller  726  of the medical device  702  can generate corresponding controller tuning instructions that influence delivery of insulin by the insulin deliver system  730  of the medical device  702  to control delivery of insulin via the medical device  702 . The controller  726  can generate commands  728  that instruct the insulin deliver system  730  to either increase insulin delivery to the specific user by a certain amount, decrease insulin delivery to the specific user by a certain amount, or leave insulin delivery to the specific user at its normal or ordinary level by maintaining the insulin delivery in a nominal state (e.g., maintain insulin delivery by the controller in a nominal state), as explained above. 
     In some embodiments, the classified output  724  can include or be processed to derive therapy parameters and settings that can be applied at the controller  726  to either: decrease insulin delivery when the combination of detected events is associated with the probability of the decreased insulin delivery demand and the probability of the decreased insulin delivery demand is greater than the first threshold, increase insulin delivery when the combination of detected events is associated with the probability of the increased insulin delivery demand and the probability of the increased insulin delivery demand is greater than the second threshold, or maintain ordinary insulin delivery by maintaining the insulin delivery in a nominal state when the probability of the decreased insulin delivery demand is less than the first threshold and the probability of the increased insulin delivery demand is less than the second threshold (e.g., maintain insulin delivery by the controller in a nominal state). In this implementation, based on the classified output  724  the controller of the medical device  702  can generate therapy parameters and settings for controlling delivery of insulin via the medical device, and the insulin delivery system  730  can control delivery of the insulin via the medical device to either increase insulin delivery to the specific user, decrease insulin delivery to the specific user, or leave insulin delivery to the specific user at an ordinary level by maintaining the insulin delivery in a nominal state (e.g., maintain insulin delivery by the controller in a nominal state). 
       FIG. 11A  is a flowchart illustrating a method  800  for classifying detected events to generate a classified output for controlling a medical device to control insulin delivery to a specific user in accordance with certain embodiments. In the description that follows, one iteration of the method  800  will be described, however, it should be appreciated that any number of iterations of method  800  can be performed to build a database of classified outputs for different combination of detected events. 
     The method begins at  802 , where the event detection system  707  receives user-specific event data from one or more measurement devices. The measurement devices can include, for example, the gesture-based event detection system  104  and/or the ancillary system(s)  106  that are described above with reference to  FIG. 1 . 
     At  804 , the event detection system  707  processes the specific user-specific event data to detect events associated with the specific user and generates various detected events and associated data for each detected event. The detected events can be specific conditions or activities that are indicative of a physical behavior of the user, such as, a meal ingestion event; a physical inactivity event; a sleep event; a physical activity event; an exercise event and a work-related event. 
     At  806 , the event classifier  720  can group the detected events into a combination  710  of detected events. At  808 , an event-to-output mapping process  722  of the event classifier  720  can map the combination of detected events to controller tuning instructions that influence delivery of insulin to either decrease the insulin delivery to the specific user, increase the insulin delivery to the specific user, or keep the insulin delivery to the specific user at an ordinary level by maintaining the insulin delivery in a nominal state (e.g., maintain insulin delivery by the controller in a nominal state). 
     For example in one embodiment, the classifier output  724  can include instructions to either: decrease insulin delivery when the combination of detected events is associated with the probability of the decreased insulin delivery demand and the probability of the decreased insulin delivery demand is greater than the first threshold; increase insulin delivery when the combination of detected events is associated with the probability of the increased insulin delivery demand and the probability of the increased insulin delivery demand is greater than the second threshold; or maintain ordinary insulin delivery by maintaining the insulin delivery in a nominal state when the probability of the decreased insulin delivery demand is less than the first threshold and the probability of the increased insulin delivery demand is less than the second threshold (e.g., maintain insulin delivery by the controller in a nominal state). 
     In some embodiments, the instructions from the classifier output  724  can include or be processed to derive therapy parameters and settings to either: decrease insulin delivery when the combination of detected events is associated with the probability of the decreased insulin delivery demand and the probability of the decreased insulin delivery demand is greater than the first threshold, increase insulin delivery when the combination of detected events is associated with the probability of the increased insulin delivery demand and the probability of the increased insulin delivery demand is greater than the second threshold, or maintain ordinary insulin delivery by maintaining the insulin delivery in a nominal state when the probability of the decreased insulin delivery demand is less than the first threshold and the probability of the increased insulin delivery demand is less than the second threshold (e.g., maintain insulin delivery by the controller in a nominal state). 
     At  810 , the event-to-output mapping process  722  of the event classifier  720  can generate a classifier output  724  corresponding to the combination of detected events. The classifier output can include the controller tuning instructions that influence delivery of insulin to either decrease the insulin delivery to the specific user, increase the insulin delivery to the specific user, or keep the insulin delivery to the specific user at an ordinary level by maintaining the insulin delivery in a nominal state (e.g., maintain insulin delivery by the controller in a nominal state). For example, in one embodiment, the classifier output  724  include instructions to either: decrease insulin delivery, increase insulin delivery, or maintain ordinary insulin delivery by maintaining the insulin delivery in a nominal state (e.g., maintain insulin delivery by the controller in a nominal state). 
     At  812 , the event-to-output mapping process  722  of the event classifier  720  can store the classifier output  724  for the combination of detected events in a database that is maintained in storage  723 . When the classifier outputs are stored in the database they can be referred to as “classified” outputs. The method  800  then loops back to  802  where the process repeats for each combination of detected events so that the database of classified outputs can be developed. As will be explained below, the classified outputs that are stored in the database  740  can subsequently accessed and used to control a medical device  702  when a corresponding combination of events is detected. Each classified output can either increase insulin delivery to the specific user, decrease insulin delivery to the specific user to the specific user, or leave insulin delivery to the specific user at its ordinary level by maintaining the insulin delivery in a nominal state (e.g., maintain insulin delivery by the controller in a nominal state). 
       FIG. 11B  is a flowchart illustrating a method  820  for controlling insulin delivery to a specific user of a medical device  702  based on detected events associated with the specific user in accordance with certain embodiments. In the description that follows, one iteration of the method  820  will be described, however, it should be appreciated that any number of iterations of method  820  can be performed each time a combination of events (that has been classified is detected). 
     The method  820  begins at  822  when the combination of events associated with a specific user is detected. To explain further, a number of individual events can be detected within a period and grouped together as a combination of detected events or “event combination.” At  824 , a particular event combination is determined that corresponds to the combination of events that was detected at  822 . As will be explained further below, the particular event combination can be used to retrieve a corresponding classified out from the database  740 . 
     At  826 , the database  740  of classified outputs is accessed. The database  740  stores a classified output corresponding to each event combination (e.g., each combination of detected events). Each classified output corresponds to a particular event combination (or combination of detected events), and maps that particular event combination to controller tuning instructions that influence delivery of insulin to either decrease the insulin delivery to the specific user, increase the insulin delivery to the specific user, or keep the insulin delivery to the specific user at an ordinary level by maintaining the insulin delivery in a nominal state (e.g., maintain insulin delivery by the controller in a nominal state). 
     At  828 , a particular classified output  724  corresponding to that event combination is retrieved from the database. 
     In one implementation, the database of classified outputs can be stored at the medical device  702 . This way, when the medical device  702  receives an indication that a particular combination of events (or “event combination”) has been detected, an application at the medical device  702  can retrieve the corresponding classified output  724  for that particular combination of detected events. In some embodiments, the database of classified outputs can be stored at another device associated with the medical device  702 . This way, when a particular combination of events is detected, the application can retrieve the corresponding classified output  724  for that particular combination of detected events, and provide it to the medical device  702 . In some embodiments, when a particular combination of events is detected, an application at the medical device  702  or another device associated with the medical device  702 , can retrieve a corresponding classified output  724  from a database maintained at a remote server system. 
     At  830 , based on the classified output  724 , the controller  726  of the medical device  702  can generate control commands  728  that are sent to the insulin delivery system  730  to control delivery of insulin via the medical device  702 . The controller tuning instructions influence delivery of insulin and can be used to generate control commands  728  that instruct the insulin deliver system  730  to either decrease insulin delivery to the specific user, increase insulin delivery to the specific user, or leave insulin delivery to the specific user at an ordinary level by maintaining the insulin delivery in a nominal state (e.g., maintain insulin delivery by the controller in a nominal state). 
       FIG. 12  is block diagram illustrating a system  900  for controlling insulin delivery to a specific user by a medical device  902  based on a detected event associated with the specific user in accordance with certain embodiments. The system  900  includes an event detection system  907 , a medical device  902  (e.g., an insulin infusion device) of a user, an optional user device  908  and a server system  916  that includes storage  923  that stores a database  940 . The event detection system  907 , the medical device  902 , the optional user device  908  and the server system  916  are all described above with reference to  FIG. 10B , and for sake of brevity the description of those devices and systems will not be repeated here. As will be explained below, the medical device  902  of the user can be controlled based on predefined outputs stored in the database  940  of predefined outputs. The database  940  stores a predefined output corresponding to each detected event. Each predefined output maps a particular detected event to corresponding therapy parameters and settings that will cause a controller  926  of the medical device  902  to either decrease the insulin delivery to the specific user, increase the insulin delivery to the specific user, or keep the insulin delivery to the specific user at an ordinary level by maintaining the insulin delivery in a nominal state (e.g., maintain insulin delivery by the controller in a nominal state). 
     When an event associated with the specific user is detected by the event detection system  907 , it can be sent to the medical device  902 , the optional user device  908  and/or the server system  916 . At least some of the detected events can be or indicate a specific condition or activity that is indicative of a physical behavior of the user. In response to the detected event, the database  940  of predefined outputs can be accessed, and a predefined output corresponding to the detected event can be retrieved that maps that particular detected event to therapy parameters and settings that will cause the controller  926  of the medical device  902  to either decrease the insulin delivery to the specific user, increase the insulin delivery to the specific user, or keep the insulin delivery to the specific user at an ordinary level by maintaining the insulin delivery in a nominal state (e.g., maintain insulin delivery by the controller in a nominal state). Based on the predefined output the controller  926  of the medical device  902  can apply the therapy parameters and settings specified by that predefined output to control delivery of insulin via the medical device  902  automatically (e.g., without further user input) or after user confirmation. The therapy parameters and settings that cause the controller  926  of the medical device  902  to either decrease the insulin delivery to the specific user, increase the insulin delivery to the specific user, or keep the insulin delivery to the specific user at an ordinary level by maintaining the insulin delivery in a nominal state (e.g., maintain insulin delivery by the controller in a nominal state). The medical device  902  can then be controlled based on the therapy parameters and settings to control the delivery of the insulin by either increasing insulin delivery to the specific user, decreasing insulin delivery to the specific user, or leaving insulin delivery to the specific user at the ordinary level by maintaining the insulin delivery in a nominal state (e.g., maintain insulin delivery by the controller in a nominal state). 
     Although  FIG. 12  illustrates one embodiment where the database  940  shown as being located at a remote server system  916 , it should be appreciated that the server system  916  and/or the database  940 , can be implemented at the medical device  902 , at the event detection system  907 , or at the user device  908  depending on the implementation. 
     Thus, in one implementation, the database  940  of predefined outputs can be stored at the medical device  902 . This way, when the medical device  902  receives an indication that an event has been detected, an application at the medical device  902  can retrieve the corresponding predefined output  924  for that detected event. 
     In some embodiments, the database  940  of predefined outputs can be stored at another device (such as user device  908 ) associated with the medical device  902 . This way, when an event is detected, an application at the other device  908  can retrieve the corresponding predefined output  924  for that detected event, and provide it to the medical device  902 . 
     In some embodiments, when an event is detected, the database  940  can be accessed by an application at the medical device  902  or another device  908  associated with the medical device  902 , and a corresponding predefined output can be retrieved from a database  940  maintained at a remote server system  916 . 
     Therapy parameters and settings specified by a predefined output can include any number of parameters and settings. Some non-limiting examples can include, for example, a basal profile and characteristics thereof, such as, basal rate settings for the user for different time segments and a maximum basal rate bolus insulin that specifies a dose of insulin for needed to cover an expected rise in blood glucose or to lower a high blood glucose down to target range that indicates a desired blood glucose level, an insulin-to-carbohydrate ratio (I:C) or carbohydrate-to-insulin (C:I) ratio; insulin sensitivity factor (ISF) or correction factor; active insulin time or duration of insulin action (DIA), insulin on board (IOB), etc. 
     The system  900  of  FIG. 12  can be applied to any specific event. As mention above, in some cases, an event can be or indicate a specific condition or activity that is indicative of a physical behavior of the user. Each specific event can be pre-classified and directly mapped to therapy parameters and/or settings for the controller  926  of the medical device  902 . Some non-limiting examples of specific conditions or activities that are indicative of the physical behavior of the user can include a meal ingestion event, a sleep event, a physical activity event, an exercise event and a work-related event. In some embodiments, specific gesture event(s) can be associated with or indicative of inactivity (e.g., sleep, indications of inactivity such as sitting for long periods of time, watching television, reading, working on a computer, etc.) Some non-limiting examples of specific events will now be described with reference to  FIGS. 13-16 . 
     To mitigate postprandial hyperglycemia, a user can deliver additional insulin on top of their basal or background insulin. This can be achieved by delivering a meal bolus (e.g., calculated by counting carbohydrates consumed by the user preferably prior to eating). However, counting carbohydrates consumed and delivering a meal bolus at the time of eating can be time-consuming, burdensome or inconvenient to the user. As such, in some cases, a user may forget or skip these steps, which in turn causes elevated blood glucose levels. 
     To help address these issues, a method is provided for detecting an eating event and automatically taking action to help mitigate postprandial hyperglycemia for the user. For instance, when an eating event is detected, a medical device, such as an insulin pump, can be automatically controlled take additional action to mitigate postprandial hyperglycemia and bring blood glucose levels into a target range. 
       FIG. 13  is a flowchart illustrating a method  1000  for controlling insulin delivery to a specific user by a medical device based on a detected eating event (or “meal” event) associated with the specific user in accordance with certain embodiments. In accordance with method  1000 , therapy parameters and/or settings for the controller  926  of the medical device  902  can be modified in response to a detected eating event. 
     The method  1000  begins at  1002 , when an event detection system  907  receives user-specific event data from one or more measurement devices. At  1002 , based on the user-specific event data, the event detection system  907  can detect an eating event associated with the user (e.g., an eating gesture indicative of meal ingestion by the user). The detected eating event is directly mapped to one or more pre-defined therapy parameters and/or settings for the controller  926  of the medical device  902 . For example, In some embodiments of method  1000 , each gesture event that is indicative of or associated with meal ingestion or eating can be mapped directly to therapy parameters and/or settings for the controller  926 . 
     At  1006 , a predefined output, corresponding to the detected eating event, can be retrieved. The predefined output maps that particular detected eating event to therapy parameters and settings that will cause the controller  926  of the medical device  902  to either increase the insulin delivery to the specific user, or keep the insulin delivery to the specific user at an ordinary level by maintaining the insulin delivery in a nominal state (e.g., maintain insulin delivery by the controller in a nominal state). At  1008 , based on the predefined output, the controller  926  of the medical device  902  can apply the pre-defined therapy parameters and settings (as specified by that predefined output) to control delivery of insulin to the specific user via the medical device  902  automatically (e.g., without further user input) or after user confirmation. The medical device  902  can then be controlled based on controller tuning instructions that influence delivery of insulin and result in commands from the controller  926  to control the delivery of the insulin by either increasing insulin delivery to the specific user, decreasing insulin delivery to the specific user, or leaving insulin delivery to the specific user at the ordinary level by maintaining the insulin delivery in a nominal state (e.g., maintain insulin delivery by the controller in a nominal state). 
     The therapy parameters and settings can cause the controller  926  of the medical device  902  to increase the insulin delivery to the specific user to mitigate potential hyperglycemia due to absorption of carbohydrates from the meal consumed as part of the eating event (or keep the insulin delivery to the specific user at an ordinary level by maintaining the insulin delivery in a nominal state in the event hyperglycemia is not a concern based on the specifics of the eating event). In one implementation, to increase the insulin delivery to the specific user to mitigate potential hyperglycemia, the controller  926  can, for example, decrease a setpoint/target of the controller  926  for a certain period of time, or increase the upper limit for auto basal insulin delivery to allow more insulin to be delivered by a feedback control algorithm, deliver boluses triggered by each bite gesture, or take any other actions to mitigate potential hyperglycemia. All these actions could be taken without involving the user, therefore without introducing any burden, and still provide the necessary therapy required during postprandial stage. 
     In addition, while consuming a meal normally increase the likelihood of hyperglycemia, in the event that a hypoglycemic condition is predicted for some reason, the detected eating event can be mapped to one or more pre-defined therapy parameters and settings (as specified by that predefined output) that will decrease insulin delivery to mitigate potential hypoglycemia. In one implementation, to decrease the insulin delivery to the specific user to mitigate potential hypoglycemia, the controller  926  can, for example, increase a setpoint/target of the controller  926  for a certain period of time, or decrease the upper limit for auto basal insulin delivery so that less insulin is delivered by a feedback control algorithm, reduce the frequency of boluses delivered, or take any other actions to mitigate potential hypoglycemia. 
       FIG. 14  is a flowchart illustrating a method  1100  for controlling insulin delivery to a specific user by a medical device based on a detected event that is indicative of activity or inactivity of the specific user in accordance with certain embodiments. In accordance with method  1100 , therapy parameters and/or settings for the controller  926  of the medical device  902  can be modified in response to the detected event that is indicative of activity or inactivity (e.g., sleep, indications of activity or inactivity such as work, exercise, sitting for long periods of time, watching television, reading, working on a computer, etc., meal ingestion, etc.) associated with the specific user. 
     The method  1100  begins at  1102 , when an event detection system  907  receives user-specific event data from one or more measurement devices. At  1102 , based on the user-specific event data, the event detection system  907  can detect an eating event associated with the user (e.g., gestures indicative of inactivity of the specific user, gestures indicative of activity of the specific user). 
     At  1106 , a predefined output, corresponding to the detected event that is indicative of activity or inactivity of the specific user, can be retrieved. The predefined output maps that particular detected event to therapy parameters and settings that will cause the controller  926  of the medical device  902  to either decrease the insulin delivery to the specific user, increase the insulin delivery to the specific user, or keep the insulin delivery to the specific user at an ordinary level by maintaining the insulin delivery in a nominal state (e.g., maintain insulin delivery by the controller in a nominal state). 
     Each detected event that is indicative of activity of the specific user can be directly mapped to one or more pre-defined therapy parameters and/or settings for the controller  926  of the medical device  902 . Similarly, each detected event that is indicative of inactivity of the specific user can be directly mapped to one or more pre-defined therapy parameters and/or settings for the controller  926  of the medical device  902 . For instance, in some embodiments of method  1100 , each gesture event that is indicative of or associated with inactivity of the user (e.g., sleeping or other indications of inactivity such as sitting for long periods of time, watching television, reading, working on a computer, etc.) can be mapped directly to therapy parameters and/or settings for the controller  926 . 
     At  1108 , based on the predefined output, the controller  926  of the medical device  902  can apply the pre-defined therapy parameters and settings (as specified by that predefined output) to control delivery of insulin to the specific user via the medical device  902  automatically (e.g., without further user input) or after user confirmation. The therapy parameters and settings can cause the controller  926  of the medical device  902  to either decrease the insulin delivery to the specific user, increase the insulin delivery to the specific user, or keep the insulin delivery to the specific user at an ordinary level by maintaining the insulin delivery in a nominal state. The medical device  902  can then be controlled based on the therapy parameters and settings to control the delivery of the insulin by either increasing insulin delivery to the specific user, decreasing insulin delivery to the specific user, or leaving insulin delivery to the specific user at the ordinary level by maintaining the insulin delivery in a nominal state. 
     The predefined therapy parameters and settings (as specified by that predefined output) can cause the controller  926  of the medical device  902  to increase the insulin delivery to the specific user to mitigate potential hyperglycemia. In one implementation, to increase the insulin delivery to the specific user to mitigate potential hyperglycemia, the controller  926  can, for example, decrease a setpoint/target of the controller  926  for a certain period of time, or increase the upper limit for auto basal insulin delivery to allow more insulin to be delivered by a feedback control algorithm, deliver boluses triggered by each gesture, or take any other actions to mitigate potential hyperglycemia. 
     By contrast, the pre-defined therapy parameters and settings (as specified by that predefined output) can cause the controller  926  of the medical device  902  to decrease the insulin delivery to the specific user to mitigate potential hypoglycemia. For example, when an event is detected that indicates that a user is in an inactive state, the amount of insulin that is delivered can be constrained to help prevent “stacking” of insulin. This way, when the user becomes active and their insulin absorption rate increases, there will not be an overabundance of insulin released into their system. The controller  926  can, for example, increase a setpoint/target of the controller  926  for a certain period of time, or decrease the upper limit for auto basal insulin delivery so that less insulin is delivered by a feedback control algorithm, reduce the frequency of boluses delivered, or take any other actions to mitigate potential hypoglycemia. 
     Different jobs require different levels of concentration. For example, driving a car, operating machinery, and flying an airplane require a much higher level of mental awareness than performing some of the other jobs, such as certain kinds of desk jobs. In terms of glycemic control, a user may have different priorities while performing his/her duties, some of which require more elevated levels of attention than at other times. Hypoglycemia may have a serious negative impact in maintaining elevated levels of awareness. In such cases, it would be desirable to provide an automated insulin delivery system which can detect periods of the day that require higher attention and down-regulate the aggressiveness of insulin therapy to make a user less prone to hypoglycemia. 
       FIG. 15  is a flowchart illustrating a method  1200  for controlling insulin delivery to a specific user by a medical device based on a work-related event associated with the specific user in accordance with certain embodiments. In accordance with method  1200 , therapy parameters and/or settings for the controller  926  of the medical device  902  can be modified in response to the work-related event that is detected. 
     The method  1200  begins at  1202 , when the event detection system  907  receives user-specific event data from one or more measurement devices. At  1202 , based on the user-specific event data, the event detection system  907  can detect a work-related event associated with the user (e.g., a work-related gesture indicative of a work-related activity being performed by the user). 
     At  1206 , a predefined output, corresponding to the work-related event that was detected, can be retrieved. The predefined output maps that particular work-related event to therapy parameters and settings that will cause the controller  926  of the medical device  902  to either decrease the insulin delivery to the specific user, increase the insulin delivery to the specific user, or keep the insulin delivery to the specific user at an ordinary level by maintaining the insulin delivery in a nominal state. The detected work-related event is directly mapped to one or more pre-defined therapy parameters and/or settings for the controller  926  of the medical device  902 . For example, In some embodiments of method  1200 , each gesture event that is indicative of or associated with work-related activities of the user can be mapped directly to therapy parameters and/or settings for the controller  926 . 
     At  1208 , based on the predefined output, the controller  926  of the medical device  902  can apply the pre-defined therapy parameters and settings (as specified by that predefined output) to control delivery of insulin to the specific user via the medical device  902  automatically (e.g., without further user input) or after user confirmation. The therapy parameters and settings can cause the controller  926  of the medical device  902  to either decrease the insulin delivery to the specific user, increase the insulin delivery to the specific user, or keep the insulin delivery to the specific user at an ordinary level by maintaining the insulin delivery in a nominal state. The medical device  902  can then be controlled based on the therapy parameters and settings to control the delivery of the insulin by either increasing insulin delivery to the specific user, decreasing insulin delivery to the specific user, or leaving insulin delivery to the specific user at the ordinary level by maintaining the insulin delivery in the nominal state. 
     The predefined therapy parameters and settings (as specified by that predefined output) can cause the controller  926  of the medical device  902  to increase the insulin delivery to the specific user to mitigate potential hyperglycemia. In one implementation, to increase the insulin delivery to the specific user to mitigate potential hyperglycemia, the controller  926  can, for example, decrease a setpoint/target of the controller  926  for a certain period of time, or increase the upper limit for auto basal insulin delivery to allow more insulin to be delivered by a feedback control algorithm, deliver boluses triggered by each gesture (or absence of gestures), or take any other actions to mitigate potential hyperglycemia. 
     By contrast, the pre-defined therapy parameters and settings (as specified by that predefined output) can cause the controller  926  of the medical device  902  to decrease the insulin delivery to the specific user to mitigate potential hypoglycemia. The controller  926  can, for example, increase a setpoint/target of the controller  926  for a certain period of time, or decrease the upper limit for auto basal insulin delivery so that less insulin is delivered by a feedback control algorithm, reduce the frequency of boluses delivered, or take any other actions to mitigate potential hypoglycemia. This can be useful, for example, when the system detects work-related activities that require a higher level of mental awareness. In such cases, the setpoint/target of the controller  926  can be increased for a certain period of time in order to minimize hypoglycemia. 
     Physical activity, such as exercise, as an effect on a user&#39;s glycemic levels. Most physical activity, in the form of sports or other aerobic activities, tends to lower a user&#39;s blood glucose levels, and therefore has potential for causing hypoglycemia. However, anaerobic activities, such as weightlifting, may lead to hyperglycemia. As such, to provide for better protection against hypoglycemia or hyperglycemia, it would be desirable to be able to adjust insulin delivery to a user based on the type of activity they are performing. 
       FIG. 16  is a flowchart illustrating a method  1300  for controlling insulin delivery to a specific user by a medical device based on a type of exercise-related event (or other event indicative of physical activity) associated with the specific user in accordance with certain embodiments. In accordance with method  1300 , therapy parameters and/or settings for the controller  926  of the medical device  902  can be modified in response to exercise-related events that are detected. 
     The method  1300  begins at  1302 , when an event detection system  907  receives user-specific event data from one or more measurement devices. At  1302 , based on the user-specific event data, the event detection system  907  can detect a type of exercise-related event associated with the user (e.g., type of sports activity requiring aerobic, anaerobic, or mixed exercise). This detection could be done, for example, based on gestures indicative of a specific type of exercise or physical activity being performed by the user, information from an activity tracker that is indicative of a specific type of exercise or physical activity being performed by the user, etc. 
     At  1306 , a predefined output can be retrieved that corresponds to the type of exercise-related event that was detected. The predefined output maps that particular exercise-related event to therapy parameters and settings that will cause the controller  926  of the medical device  902  to either decrease the insulin delivery to the specific user, increase the insulin delivery to the specific user, or keep the insulin delivery to the specific user at an ordinary level by maintaining the insulin delivery in a nominal state. The detected exercise-related event is directly mapped to one or more pre-defined therapy parameters and/or settings for the controller  926  of the medical device  902 . For example, In some embodiments of method  1300 , each gestures that are indicative of or associated with a type of exercise-related activity (or other physical activity) being performed by the user can be mapped directly to therapy parameters and/or settings for the controller  926 . 
     At  1308 , based on the predefined output, the controller  926  of the medical device  902  can apply the pre-defined therapy parameters and settings (as specified by that predefined output) to control delivery of insulin to the specific user via the medical device  902  automatically (e.g., without further user input) or after user confirmation. The therapy parameters and settings can cause the controller  926  of the medical device  902  to either decrease the insulin delivery to the specific user, increase the insulin delivery to the specific user, or keep the insulin delivery to the specific user at an ordinary level by maintaining the insulin delivery in a nominal state. The medical device  902  can then be controlled based on the therapy parameters and settings to control the delivery of the insulin by either increasing insulin delivery to the specific user, decreasing insulin delivery to the specific user, or leaving insulin delivery to the specific user at the ordinary level by maintaining the insulin delivery in a nominal state. 
     When a user is performing an anaerobic activity, blood glucose can increase and there is a higher risk of hyperglycemia or a hyperglycemic condition occurring. The predefined therapy parameters and settings (as specified by that predefined output) can cause the controller  926  of the medical device  902  to increase the insulin delivery to the specific user to mitigate the risk of hyperglycemia. In one implementation, to increase the insulin delivery to the specific user to mitigate potential hypoglycemia, the controller  926  can, for example, decrease a setpoint/target of the controller  926  for a certain period of time, or increase the upper limit for auto basal insulin delivery to allow more insulin to be delivered by a feedback control algorithm, deliver boluses triggered by each gesture, or take any other actions to mitigate potential hyperglycemia. 
     By contrast, when a user is performing an aerobic activity, blood glucose can decrease and there is a higher risk of a hypoglycemic condition occurring. The pre-defined therapy parameters and settings (as specified by that predefined output) can cause the controller  926  of the medical device  902  to decrease the insulin delivery to the specific user to mitigate the risk of hypoglycemia. The controller  926  can, for example, increase a setpoint/target of the controller  926  for a certain period of time, or decrease the upper limit for auto basal insulin delivery so that less insulin is delivered by a feedback control algorithm, reduce the frequency of boluses delivered, or take any other actions to mitigate potential hypoglycemia. 
     The various tasks performed in connection with a process disclosed herein may be performed by software, hardware, firmware, or any combination thereof. It should be appreciated that an embodiment of an illustrated process may include any number of additional or alternative tasks, the tasks shown in the figures need not be performed in the illustrated order, and a disclosed process may be incorporated into a more comprehensive procedure or process having additional functionality not described in detail herein. Moreover, one or more of the tasks shown in a figure could be omitted from an embodiment of the depicted process as long as the intended overall functionality remains intact. 
     While at least one exemplary embodiment has been presented in the foregoing detailed description, it should be appreciated that a vast number of variations exist. It should also be appreciated that the exemplary embodiment or embodiments described herein are not intended to limit the scope, applicability, or configuration of the claimed subject matter in any way. Rather, the foregoing detailed description will provide those skilled in the art with a convenient road map for implementing the described embodiment or embodiments. It should be understood that various changes can be made in the function and arrangement of elements without departing from the scope defined by the claims, which includes known equivalents and foreseeable equivalents at the time of filing this patent application.