Patent Description:
Many people suffer from Type I or Type II diabetes, in which the body does not properly regulate the blood glucose level. A continuous glucose monitor (CGM) allows the blood glucose level of a patient with diabetes to be measured on an ongoing basis, such as every few minutes. The timing and dosage of insulin to administer to the patient may be determined on the basis of measurements recorded by the CGM device. Glucose readings from CGM devices are displayed to the patient, and the patient can inject insulin or consume meals to help control the glucose level. Insulin pumps can deliver precise insulin dosages on a programmable schedule which may be adjusted by the patient or health care provider.

Hazard metrics may be derived from glucose data for assessing a hazard to the diabetic person based on a detected glucose level. For example, a known hazard metric includes the hazard function proposed in the following paper:<NPL>. The Kovatchev hazard function is defined by the equation h(g)=[<NUM>(log(g)<NUM>-<NUM>)]<NUM>, wherein g is the blood glucose concentration (in milligrams per deciliter or mg/dl) and h(g) is the corresponding penalty value. The Kovatchev function provides a static penalty (i.e., hazard) value in that the penalty depends only on the glucose level. The minimum (zero) hazard occurs at <NUM>/dl. The hazard with the glucose level approaching hypoglycemia rises significantly faster than the hazard with the glucose level approaching hyperglycemia.

The Kovatchev hazard function fails to account for the rate of change of the glucose level as well as the uncertainty associated with the measured glucose level. For example, a patient's hazard associated with <NUM>/dl and a rapidly falling blood glucose level is likely greater than the patient's hazard associated with <NUM>/dl with a constant glucose rate of change. Further, measured glucose results may be inaccurate due to sensor noise, sensor malfunction, or detachment of the sensor.

Various approaches have been made to control the glucose levels of diabetic people based on CGM glucose data. One approach for limiting the occurrence of hypoglycemic conditions includes an insulin pump shutoff algorithm that completely shuts off the basal insulin if the CGM glucose level drops below a low glucose threshold, such as <NUM> to <NUM>/dl, and later resumes the basal insulin after a few hours. However, this on/off approach adversely requires the adverse condition of crossing the low glucose threshold to occur before action is taken. Further, this approach does not take into account the speed with which the glucose is crossing the threshold, which may be problematic for patients (e.g., children, active individuals, etc.) with a high rate of glucose change.

Another approach is to alert the patient of predicted hypoglycemia, and the patient then consumes an amount of carbohydrates and waits a predetermined time period. If the system still predicts hypoglycemia the patient repeats the cycle until the system no longer predicts hypoglycemia. However, this approach makes the assumption that the patient is able to consume carbohydrates immediately upon being alerted of the predicted hypoglycemia. Further, the patient may overcorrect by consuming too many carbs, possibly leading to weight gain or to trending the glucose levels towards hyperglycemia.

Accordingly, some embodiments of the present disclosure provide a predictive approach for adjusting a therapy basal rate by mapping the risk of the estimated glucose state to an adjustment of the basal rate based on an aggressiveness factor.

Risk associated with the glucose state is based on the blood glucose level, the rate of change of the blood glucose level, and the uncertainty associated with the blood glucose level and rate of change. Further, some embodiments provide for adjusting the calculated risk for a glucose state in response to a meal bolus, an insulin bolus, and/or other events that may affect the risk of hypoglycemia or hyperglycemia.

Document <CIT> pertains to a testing method for optimizing a therapy to a diabetic patient, comprising collecting at least one sampling set of biomarker data, computing a probability distribution function, a hazard function, a risk function, and a risk value for the sampling set of biomarker data. The article <NPL> concerns the modular closed-loop control of diabetes.

Document <CIT> discloses a device for generating alerts for hypo- and hyperglycemia prevention from continuous glucose monitoring which determines a dynamic risk based on both information of glucose level and a trend obtainable from a CGM signals.

Document <CIT> is directed at CGM data and insulin delivery data which are used to generate more reliable projected alarms related to a projected glucose levels. The article<NPL> describes a dynamic risk measure from CGM data.

A blood glucose management device according to independent claim <NUM> and a method of determining a basal rate adjustment based on risk associated with a glucose state of a person with diabetes according to independent claim <NUM> are provided.

The features and advantages of the present invention will become more apparent to those skilled in the art upon consideration of the following detailed description taken in conjunction with the accompanying figures, wherein.

It will nevertheless be understood that no limitation of the scope of this disclosure is thereby intended.

As used herein, the "measured glucose values" or "measured glucose results" are the glucose levels of the person as measured by a glucose sensor; the "actual glucose level" is the actual glucose level of the person; and the "estimated glucose level" is the estimated glucose level of the person, which may be based on the measured glucose values and the probability of sensor accuracy.

The term "logic" or "control logic" or "module" as used herein may include software and/or firmware executing on one or more programmable processors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), hardwired logic, or combinations thereof. Therefore, in accordance with the embodiments, various logic may be implemented in any appropriate fashion and would remain in accordance with the embodiments herein disclosed.

<FIG> illustrates an exemplary hazard function <NUM> for calculating a static penalty value for a given glucose level. The hazard function <NUM> is defined by the following equation: <MAT> wherein g is the blood glucose level (mg/dl) shown on the x-axis, h(g) is the corresponding static penalty value shown on the y-axis, and g<NUM> and g<NUM> are glucose levels used to define a range of target glucose values (g<NUM>≤g≤g<NUM>) or a single target glucose value (g<NUM>=g<NUM>). In the illustrated embodiment, the variables α, β, and c are defined as follows: α = <NUM>, β = <NUM>, and c = <NUM>. The range of target glucose values (g<NUM>≤g≤g<NUM>) illustratively has a corresponding penalty value of zero, as shown with equation (<NUM>). With the target glucose level g<NUM>=g<NUM>=<NUM>/dl, hazard function <NUM> generates a hazard curve <NUM> corresponding to the Kovatchev function. With an exemplary target glucose range defined by g<NUM>=<NUM>/dl and g<NUM>=<NUM>/dl, hazard function <NUM> generates a hazard curve <NUM>. Hazard curve <NUM> illustratively provides penalty values for a given glucose state when the target glucose range is defined from <NUM>/dl to <NUM>/dl. Other suitable target glucose levels/ranges and penalty values corresponding to the target glucose levels/ranges may be provided with equation (<NUM>).

Referring to <FIG>, an exemplary continuous glucose monitoring (CGM) system <NUM> is illustrated for monitoring the glucose level of a person having diabetes. In particular, CGM system <NUM> is operative to collect a measured glucose value at a predetermined, adjustable interval, such as every one minute, five minutes, or at other suitable intervals. CGM system <NUM> illustratively includes a glucose sensor <NUM> having a needle or probe <NUM> that is inserted under the skin <NUM> of the person. The end of the needle <NUM> is positioned in interstitial fluid <NUM>, such as blood or another bodily fluid, such that measurements taken by glucose sensor <NUM> are based on the level of glucose in interstitial fluid <NUM>. Glucose sensor <NUM> is positioned adjacent the abdomen of the person or at another suitable location. Glucose sensor <NUM> may comprise other components as well, including but not limited to a wireless transmitter <NUM> and an antenna <NUM>. Glucose sensor <NUM> may alternatively use other suitable devices for taking measurements, such as, for example, a non-invasive device (e.g., infrared light sensor). Upon taking a measurement, glucose sensor <NUM> transmits the measured glucose value via a communication link <NUM> to a computing device <NUM>, illustratively a blood glucose management device <NUM>.

CGM system <NUM> further includes a therapy delivery device <NUM>, illustratively an insulin infusion pump <NUM>, for delivering therapy (e.g., insulin) to the person. Insulin pump <NUM> is in communication with management device <NUM> via a communication link <NUM>, and management device <NUM> is able to communicate bolus and basal rate information to insulin pump <NUM>. Insulin pump <NUM> includes a catheter <NUM> having a needle that is inserted through the skin <NUM> of the person for injecting the insulin. Insulin pump <NUM> is illustratively positioned adjacent the abdomen of the person or at another suitable location. Similar to glucose sensor <NUM>, infusion pump <NUM> also includes a wireless transmitter and an antenna for communication with management device <NUM>. Insulin pump <NUM> is operative to deliver basal insulin (e.g., small doses of insulin continuously or repeatedly released at a basal rate) and bolus insulin (e.g., a surge dose of insulin, such as around a meal event, for example). The bolus insulin may be delivered in response to a user input triggered by the user, or in response to a command from management device <NUM>. Similarly, the basal rate of the basal insulin is set based on user input or in response to a command from management device <NUM>. Infusion pump <NUM> may include a display for displaying pump data and a user interface providing user controls. In an alternative embodiment, insulin pump <NUM> and glucose sensor <NUM> may be provided as a single device worn by the patient, and at least a portion of the logic provided by processor <NUM> may reside on this single device. Bolus insulin may also be injected by other means, such as manually by the user via a needle.

Communication links <NUM>, <NUM> are illustratively wireless, such as a radio frequency ("RF") or other suitable wireless frequency, in which data and controls are transmitted via electromagnetic waves between sensor <NUM>, therapy delivery device <NUM>, and management device <NUM>. is one exemplary type of wireless RF communication system that uses a frequency of approximately <NUM> Gigahertz (GHz). Another exemplary type of wireless communication scheme uses infrared light, such as the systems supported by the Infrared Data Association. Other suitable types of wireless communication may be provided. Furthermore, each communication link <NUM>, <NUM> may facilitate communication between multiple devices, such as between glucose sensor <NUM>, computing device <NUM>, insulin pump <NUM>, and other suitable devices or systems. Wired links may alternatively be provided between devices of system <NUM>, such as, for example, a wired Ethernet link. Other suitable public or proprietary wired or wireless links may be used.

<FIG> illustrates an exemplary management device <NUM> of the CGM system <NUM> of <FIG>. Management device <NUM> includes at least one processing device <NUM> that executes software and/or firmware code stored in memory <NUM> of management device <NUM>. The software/firmware code contains instructions that, when executed by the processor <NUM> of management device <NUM>, causes management device <NUM> to perform the functions described herein. Management device <NUM> may alternatively include one or more application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), hardwired logic, or combinations thereof. While management device <NUM> is illustratively a glucose monitor <NUM>, other suitable management devices <NUM> may be provided, such as, for example, desktop computers, laptop computers, computer servers, personal data assistants ("PDA"), smart phones, cellular devices, tablet computers, infusion pumps, an integrated device including a glucose measurement engine and a PDA or cell phone, etc. Although management device <NUM> is illustrated as a single management device <NUM>, multiple computing devices may be used together to perform the functions of management device <NUM> described herein.

Memory <NUM> is any suitable computer readable medium that is accessible by processor <NUM>. Memory <NUM> may be a single storage device or multiple storage devices, may be located internally or externally to management device <NUM>, and may include both volatile and non-volatile media. Further, memory <NUM> may include one or both of removable and non-removable media. Exemplary memory <NUM> includes random-access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), flash memory, CD-ROM, Digital Versatile Disk (DVD) or other optical disk storage, a magnetic storage device, or any other suitable medium which is configured to store data and which is accessible by management device <NUM>.

Management device <NUM> further includes a communication device <NUM> operatively coupled to processor <NUM>. Communication device <NUM> includes any suitable wireless and/or wired communication module operative to transmit and receive data and controls over communication links <NUM>, <NUM> between device <NUM> and glucose sensor <NUM> and insulin pump <NUM>. In one embodiment, communication device <NUM> includes an antenna <NUM> (<FIG>) for receiving and/or transmitting data wirelessly over communication links <NUM>, <NUM>. Management device <NUM> stores in memory <NUM> measured glucose results and other data received from glucose sensor <NUM> and/or insulin pump <NUM> via communication device <NUM>.

Management device <NUM> includes one or more user input devices <NUM> for receiving user input. Input devices <NUM> may include pushbuttons, switches, a mouse pointer, keyboard, touchscreen, or any other suitable input device. A display <NUM> is operatively coupled to processor <NUM>. Display <NUM> may comprise any suitable display or monitor technology (e.g., liquid crystal display, etc.) configured to display information provided by processor <NUM> to a user. Processor <NUM> is configured to transmit to display <NUM> information related to the detected glucose state of the person, the risk associated with the glucose state, and basal rate and bolus information. The glucose state may include the estimated glucose level and the estimated rate-of-change of the glucose level, as well as an estimate of the quality or uncertainty of the estimated glucose level. Moreover, the displayed information may include warnings, alerts, etc. regarding whether the estimated or predicted glucose level of the person is hypoglycemic or hyperglycemic. For example, a warning may be issued if the person's glucose level falls below (or is predicted to fall below) a predetermined hypoglycemic threshold, such as <NUM> to <NUM> milligrams of glucose per deciliter of blood (mg/dl). Management device <NUM> may also be configured to tactilely communicate information or warnings to the person, such as for example by vibrating.

In one embodiment, management device <NUM> is in communication with a remote computing device, such as at a caregiver's facility or a location accessible by a caregiver, and data (e.g., glucose data or other physiological information) is transferred between them. In this embodiment, management device <NUM> and the remote device are configured to transfer physiological information through a data connection such as, for example, via the Internet, cellular communications, or the physical transfer of a memory device such as a diskette, USB key, compact disc, or other portable memory device.

Processor <NUM> includes hazard analysis logic <NUM> that calculates target return paths from a plurality of initial glucose states to a target glucose state based on cumulative penalty values. The target glucose state is illustratively an optimal or ideal glucose state having no associated hazard or risk, such as a glucose level of <NUM>/dl and a glucose rate-of-change of zero, although any suitable target glucose state may be identified. Each target return path is comprised of a plurality of intermediate glucose states that are to be encountered during a transition from the initial glucose state to the target glucose state. Cumulative penalty values, which may be calculated based on equation (<NUM>), associated with the target return paths are stored in memory <NUM> that may be used as a lookup table. For example, the cumulative penalty value for an initial glucose state is the sum of the static penalty value of the initial glucose state and the static penalty values of the intermediate glucose states along the target return path associated with the initial glucose state. In the illustrated embodiment, the static penalty values for each glucose state are provided by the hazard function <NUM> described herein with respect to <FIG>. In one embodiment, each return path is calculated such that a total estimated hazard (e.g., cumulative penalty value) associated with the initial glucose state and the intermediate glucose states along the return path is minimized.

Based on the target return path for each initial glucose state, hazard control logic <NUM> calculates a plurality of risk metrics associated with each initial glucose state. The risk metrics calculated for each initial glucose state include a cumulative penalty value, an estimated total return time for a person's blood glucose to transition from the initial or current glucose state to the target glucose state along the calculated target return path, a maximum penalty value that is encountered with the glucose states along the target return path, and an estimated average penalty rate associated with the target return path. The average penalty rate for an initial glucose state is the cumulative penalty value divided by the estimated total return time. The values of the risk metrics are mapped to each glucose state and are stored as data matrices in memory <NUM>.

The surface contour plot of <FIG> illustrates the cumulative penalty risk metric calculated by hazard analysis logic <NUM>. The surface or contour illustrates the value of the cumulative penalty associated with each glucose state. Additional surface contour plots may be provided for other risk metrics, including the maximum penalty values, the estimated total return time values, and the estimated average penalty rate values. In <FIG>, a cumulative penalty surface <NUM> illustrates the cumulative penalty values calculated by logic <NUM> for a range of glucose states. The y-axis represents the blood glucose level ranging from <NUM>/dl to <NUM>/dl and the x-axis represents the glucose rate of change ranging from -<NUM>/dl/min to <NUM>/dl/min. An exemplary initial glucose state is illustrated at point A with a glucose level of <NUM>/dl and a glucose rate of change of -<NUM>/dl/min. A target return path <NUM> is illustrated from the initial glucose state at point A to the target glucose state at point O. The target return path <NUM>, calculated to minimize the cumulative penalty value of the initial glucose state, illustrates the intermediate glucose states of the calculated transition from the initial glucose state A to the target glucose state O.

Logic <NUM> further calculates risk surfaces or contours based on the cumulative penalty values. Each risk surface comprises risk values associated with the risk of each glucose state. Risk is calculated based on the cumulative penalty value and the probability of certainty of the glucose state.

Logic <NUM> of <FIG> is further operative to calculate signed risk/hazard metrics. In one embodiment, to calculate signed metrics, logic <NUM> sets the static penalty values associated with hypoglycemic glucose states, i.e., glucose states having a glucose level of less than the target glucose level, to be negative based on the following equation: <MAT> wherein g is the glucose level and Hs(g) is the signed static penalty value associated with the glucose level g. The static penalty values associated with hyperglycemic glucose states remain positive. Logic <NUM> calculates the target return path described herein by analyzing the absolute value of the signed cumulative penalties. Based on the signed penalty values, logic <NUM> is operative to generate separate risk surfaces for hyperglycemia and hypoglycemia. For example, <FIG> illustrates a risk surface associated with hyperglycemia for a glucose state B, and <FIG> illustrates the risk surface associated with a hypoglycemia for the glucose state B.

In some embodiments, inaccurate glucose measurements may result from malfunction and/or noise associated with glucose sensor <NUM>. As such, hazard analysis logic <NUM> analyzes the probability of accuracy of the detected glucose state provided with glucose sensor <NUM>. Logic <NUM> may use any suitable probability analysis tool to determine the probability of accuracy of a measured glucose result, such as a hidden Markov model. Based on the determined probability of accuracy, hazard analysis logic <NUM> estimates the glucose level and the glucose rate of change of the person using a recursive filter <NUM> (<FIG>). In particular, recursive filter <NUM>, such as a Kalman filter, for example, weights the detected glucose state, including the glucose level and rate of change, with the determined probability of glucose sensor accuracy. Based on the probability of glucose sensor accuracy, recursive filter <NUM> calculates an uncertainty measure of the estimated glucose state. The uncertainty measure is indicative of the quality of the estimated glucose state. For a series of detected glucose states, the uncertainty for each state may vary.

A risk surface may be split into a hyperglycemia-based surface and a hypoglycemica-based surface to allow for separate risk calculations. Referring to <FIG>, a risk surface <NUM> illustrates the risk values with respect to hyperglycemia, and a risk surface <NUM> illustrates the risk values with respect to hypoglycemia. Upon detection of a glucose state having the glucose level and glucose rate of change corresponding to point B of <FIG> and <FIG>, logic <NUM> is operative to calculate the probability distribution around the detected glucose state B. <FIG> illustrate two alternative distributions <NUM> and <NUM>. The smaller distribution <NUM> indicates less uncertainty associated with the detected glucose state, while the larger distribution <NUM> indicates more uncertainty. Distributions <NUM> and <NUM> are illustratively Gaussian (normal) distributions, although other suitable methods of representing uncertainty may be provided, such as a particle filter or a mixture of Gaussians, for example.

Based on the uncertainty of a detected glucose state, hazard analysis logic <NUM> calculates a risk value for that detected glucose state. The risk value is based on the cumulative penalty value of the detected glucose state and the measure of probability of accuracy. For a given cumulative penalty of a detected glucose state, the risk value calculated by logic <NUM> increases with increasing uncertainty of the detected glucose state. The calculated risk value may be displayed on display <NUM> of management device <NUM>. Further, the calculated risk value may be used to adjust therapy provided to the person with diabetes, such as adjusting the insulin basal rate, for example, as described herein.

For further description of calculating the target return paths and calculating risk metrics, see <CIT>, entitled "System and Method for Assessing Risk Associated with a Glucose State," the entire disclosure of which is incorporated by reference herein. For further description of the probability analysis tool, the recursive filter, the uncertainty calculation, and other probability and risk analysis functionalities of computing device <NUM>, see <CIT>, entitled "Methods and Systems for Processing Glucose Data Measured from a Person Having Diabetes," and <CIT>, entitled "Insulin Optimization Systems and Testing Methods with Adjusted Exit Criterion Accounting for System Noise Associated with Biomarkers," the entire disclosures of which are incorporated by reference herein.

Processor <NUM> of <FIG> further includes a bolus calculator module <NUM> that calculates bolus recommendations and a maximum allowed glucose level of a user which may be displayed to a user via display <NUM>. Management device <NUM> maintains a record in memory <NUM> of historical data for the user accumulated over time leading up to the current time. The historical data includes blood glucose history, prescription data, prior bolus recommendations, prior administered boluses, prior basal rates, glucose sensitivity factors for the user's sensitivity to insulin and carbohydrates, blood glucose responses to prior boluses and meal events, other user health and medical data, and the time stamp of each event and data recordation. The history data includes patient recorded information such as meal events, amount of carbohydrates consumed, confirmations of bolus deliveries, medications, exercise events, periods of stress, physiological events, manual insulin injections, and other health events, entered via user inputs <NUM>. Bolus calculator module <NUM> uses the historical data to more accurately and efficiently determine the recommended insulin bolus and/or carbohydrate amount.

Bolus calculator module <NUM> determines a recommended bolus, such as an insulin correction bolus or a meal bolus, particular to the user based on the current glucose state, the history data, and user input. A suggested meal bolus (e.g., carbohydrate amount) may be in response to a detected or predicted hypoglycemic condition. A suggested correction bolus of insulin may be in response to the detected glucose exceeding the maximum allowable glucose level. The actual amount of carbohydrates consumed and the actual amount of insulin administered may be confirmed by the user as information entered via user inputs <NUM> and recorded in memory <NUM> with other history data. The recommended bolus may be displayed on display <NUM>.

Referring to <FIG>, an exemplary CGM trace <NUM> is illustrated, wherein the x-axis represents time in minutes and the y-axis represents glucose in mg/dl. CGM trace <NUM> comprises a series of detected glucose levels measured over a period. In the illustrated embodiment, CGM trace <NUM> represents filtered glucose levels, i.e., glucose levels that are estimated based on the measured glucose levels weighted with the probably of sensor accuracy. A most recent estimated glucose level <NUM> has an associated negative rate of change indicated with arrow <NUM>. Bolus calculator module <NUM> determines the target glucose level <NUM> and a target range of glucose levels indicated with an upper glucose limit <NUM> and a lower glucose limit <NUM>. For illustrative purposes, target glucose level <NUM> is <NUM>/dl, upper glucose limit <NUM> is <NUM>/dl, and lower glucose limit <NUM> is <NUM>/dl, although other suitable values may be provided. Module <NUM> may determine target glucose level <NUM> and limits <NUM>, <NUM> based at least in part on the user's history data described herein. Management device <NUM> uses the trending glucose data of CGM trace <NUM> to recommend corrective action to move the blood glucose towards the target glucose level <NUM>. The target glucose level <NUM> of <FIG> corresponds to the maximum allowed glucose before time t<NUM> and after time t<NUM>, i.e., when there has not been any recent meals or correction boluses. Between times t<NUM> and t<NUM>, the maximum allowed glucose is adjusted based on a meal event <NUM> or other suitable events.

At time t<NUM>, meal event <NUM> occurs when the user consumes a meal and enters carbohydrate data into management device <NUM> indicating the amount of carbohydrates consumed with the meal. In some instances, an insulin bolus is administered at about the time of the meal event <NUM> to offset the expected increase in glucose levels resulting from the meal. Bolus calculator module <NUM> determines a projected glucose level rise and a duration of the glucose rise based on the carbohydrates consumed, the insulin correction bolus (if administered), and the user's historical data related to glucose swings following meals and insulin injections. Based on the projected glucose rise, module <NUM> determines an allowed rise value <NUM>, an offset time value <NUM>, and an acting time value <NUM>. The allowed rise value <NUM> may be based on other events, such as a glucagon injection, exercise, sleep, driving, or time of day, for example.

The allowed rise value <NUM> is the amount by which the glucose level of the user may be allowed to increase with respect to the target glucose level <NUM> as a result of the carbohydrate intake and insulin bolus. In some embodiments, the allowed rise value <NUM> is the combination of a correction delta glucose value <NUM> resulting from an insulin bolus and a meal rise value <NUM> resulting from the meal event <NUM>. The correction delta glucose value <NUM> is the difference between the current glucose level and the target glucose level <NUM> at the time of the insulin bolus to allow time for the glucose level to decrease following insulin. As illustrated, the allowed rise value <NUM> is constant (see line <NUM>) for a first predetermined amount of time after the meal and insulin administration, i.e., offset time <NUM>, and then decreases linearly (see slope <NUM>) following the offset time <NUM>. The total time that the meal and insulin dose have an effect on the bG levels of a patient is the acting time <NUM>. <FIG> illustrates a trapezoid-shaped graph <NUM> of the allowed rise value <NUM> accounting for the effect of a dose of insulin and meal event.

The maximum allowed glucose increases based on allowed rise value <NUM> and follows plot <NUM> of <FIG>. As such, bolus calculator module <NUM> expands the range of allowable glucose levels after a meal event for the duration of the acting time <NUM> according to plot <NUM>. The allowed rise value <NUM> illustratively has an initial height of <NUM>/dl, but could have other suitable heights based on the meal size, the insulin, and the user's typical reactions to boluses from the historical data. In some embodiments, for meal events above a threshold amount of carbohydrates, the meal rise value <NUM> is fixed. As one example, the offset time <NUM> is about two hours, and the acting time <NUM> is about three to five hours, depending on the user, the meal size, and the insulin bolus.

For further description of the bolus calculator module <NUM>, see <CIT>, entitled "Handheld Diabetes Management Device with Bolus Calculator," and <CIT>, entitled "Insulin Pump and Methods for Operating the Insulin Pump," the entire disclosures of which are incorporated by reference herein.

As described above, hazard analysis logic <NUM> may generate separate risk surfaces for hyperglycemic risk and hypoglycemic risk based on the signed penalty values provided with equation (<NUM>). Using the hyperglycemic risk surface (e.g., surface <NUM> of <FIG>), hazard analysis logic <NUM> is operative to temporarily adjust the hyperglycemic risk metric associated with the glucose states following a meal bolus and/or insulin bolus to correspond to the allowed rise value <NUM> and acting time <NUM> of <FIG>. Logic <NUM> determines a theoretical glucose level by reducing the current glucose level by the amount of the allowed rise value <NUM> for the duration of acting time <NUM>. The allowed rise value <NUM> used to shift the glucose level includes the correction meal rise value or the correction delta glucose value, or both values if both correction events occurred. Logic <NUM> then determines the risk metric associated with the theoretical glucose level and applies that risk metric to the current glucose level.

For example, <FIG> illustrates the estimated glucose state B of <FIG> shifted down to a theoretical glucose state B' by a glucose amount <NUM>, which corresponds to the allowed rise value <NUM> of <FIG>. Thus, the temporary elevation in the maximum allowed glucose provided in <FIG> reduces the hyperglycemic risk metrics associated with the glucose states following a meal, and logic <NUM> does not consider the temporary elevation in glucose after a meal as additional hyperglycemic risk if the rise is within allowable limits for a limited duration.

Alternatively, logic <NUM> may shift the hyperglycemic risk surface <NUM> upwards by shift amount <NUM> corresponding to the allowed rise value <NUM>, as illustrated with hyperglycemic risk surface <NUM>' of <FIG>. As a result, the risk metrics associated with glucose states after the meal do not greatly increase despite the increased glucose levels resulting from the meal. While <FIG> illustrate hyperglycemic risk based on cumulative penalty values (and uncertainty), other risk metrics may be adjusted similarly such as the maximum penalty value, the estimate time to return to the target glucose state, and the mean penalty rate described herein.

Logic <NUM> may further adjust the calculated risk associated with a estimated glucose state based on other events that potentially affect risk, such as a glucagon injection, exercise, sleep, driving, or time of day, for example.

In some embodiments, the hypoglycemic risk metrics associated with a glucose state may also be shifted as a result of the meal event and insulin bolus. For example, the hypoglycemic risk surface <NUM> illustrated in <FIG> may be shifted up if the correction insulin bolus amount exceeds the recommended dose. In this scenario, the excess insulin increases the risk of hypoglycemia. Excess insulin may also result from a manual bolus. The difference between the actual correction bolus and recommended correction bolus is converted to a glucose value using an insulin sensitivity factor. This glucose value then becomes the risk adjustment applied to the glucose state for hypo risk. The offset time and acting time remain the same. The glucose state may also be shifted due to a recent glucagon injection.

Referring again to <FIG>, management device <NUM> further includes basal rate adjustment logic <NUM> operative to calculate and adjust a basal rate based on the current glucose state and the risk associated with the current glucose state. Management device <NUM> transmits an adjustment to the basal rate in a control signal to insulin pump <NUM> via communication link <NUM>, and insulin pump <NUM> adjusts the current insulin basal rate based on the adjustment. Alternatively, the adjusted basal rate may be displayed to the user, and the user manually adjusts the basal rate of insulin pump <NUM>. In the illustrated embodiment, the adjustment is a percent reduction to the initial, unadjusted basal rate based on a risk of hypoglycemia. Basal rate adjustments may also be made based on risk of hyperglycemic conditions.

Referring to <FIG>, a flow diagram <NUM> of an exemplary method performed by management device <NUM> is illustrated for determining and implementing the adjustment to the basal rate based on the calculated risk of a glucose state. Reference is made to <FIG> throughout the description of <FIG>. In the illustrated embodiment, the method of <FIG> is repeated for each glucose measurement to provide a continuously adjusted basal rate during periods of hypoglycemic risk. The operations of <FIG> are illustratively performed by at least hazard analysis logic <NUM>, bolus calculator module <NUM>, and basal rate adjustment logic <NUM> of processor <NUM>.

At block <NUM>, basal rate adjustment logic <NUM> identifies the current basal rate of insulin being administered to the patient by insulin pump <NUM> as the initial or reference basal rate. For example, the current basal rate at insulin pump <NUM> may be monitored by management device <NUM> via communication link <NUM> or input by a user. The current, non-adjusted basal rate is stored in memory <NUM> as the reference basal rate.

Referring to blocks <NUM> and <NUM>, management device <NUM> receives a glucose measurement from glucose sensor <NUM> and determines the current blood glucose state of the person based on the glucose measurement, as described herein. The estimated glucose state includes the glucose level, the rate of change of the glucose level, and the measure of uncertainty or probability of accuracy. In the illustrated embodiment, hazard analysis logic <NUM> calculates the estimated (filtered) glucose level and rate of change based on the uncertainty measure, as described herein. At blocks <NUM> and <NUM>, hazard analysis logic <NUM> calculates the hyperglycemic risk and the hypoglycemic risk associated with the estimated glucose state. In particular, logic <NUM> calculates separate hyperglycemic and hypoglycemic risk values based on the signed risk surfaces of <FIG>. In the illustrated embodiment, the hypoglycemia risk is a negative value and the hyperglycemia risk is a positive value. If a meal bolus and/or insulin bolus (or another event affecting risk) was recently delivered to the patient, logic <NUM> optionally adjusts the hyperglycemic risk of the estimated glucose state at block <NUM> based on the allowed rise value <NUM> (<FIG>) described herein. In some embodiments, the adjusted hyperglycemic risk results in logic <NUM> being more responsive when an insulin bolus has been administered to the patient by adjusting the basal rate sooner and more aggressively than if an insulin bolus had not been administered. As such, the adjusted hyperglycemic risk increases the aggressiveness of the basal rate adjustment.

At block <NUM>, hazard analysis logic <NUM> calculates the total current risk by summing the hyperglycemic risk and the hypoglycemic risk. If the resulting sum is a negative value, then the current glucose state has an associated hypoglycemic risk. Based on the total current risk, basal rate adjustment logic <NUM> calculates an adjustment to the current basal rate at block <NUM>. Block <NUM> corresponds to blocks <NUM>-<NUM> of <FIG>. In some embodiments, if the resulting sum is positive, then the current glucose state has an associated hyperglycemic risk and the basal rate is not reduced.

At block <NUM>, basal rate adjustment logic <NUM> selects a first reference glucose state corresponding to a basal shutoff of insulin pump <NUM>. In the illustrated embodiment, the first reference glucose state is selected to have a low glucose level at or near a minimum hypoglycemic condition, such as <NUM>/dl or <NUM>/dl or another suitable glucose level. The glucose rate of change of the first reference glucose state is illustratively zero, although another suitable glucose rate of change may be selected. Accordingly, the first reference glucose state is identified as a glucose state at which insulin pump <NUM> shuts off to stop the basal insulin.

At block <NUM>, basal rate adjustment logic <NUM> selects a second reference glucose state corresponding to a glucose level and rate of change having no or minimal associated hypoglycemic risk and thereby no required adjustment to the current basal rate of insulin pump <NUM>. In the illustrated embodiment, the second reference glucose state is selected to have a target glucose level of <NUM>/dl and zero glucose rate of change. Other suitable glucose states may be selected as the second reference glucose state. For example, the second reference glucose state may have a different glucose level with zero or nonzero associated risk.

At block <NUM>, basal rate adjustment logic <NUM> determines the risk value associated with each of the first and second reference glucose states. The risk may be determined based on the risk surfaces stored in memory <NUM> and described herein. In the illustrated embodiment, the risks determined at block <NUM> each include the sum of the hypoglycemic risk and hyperglycemic risk for the corresponding reference glucose state. The risk value associated with the first reference glucose state is a negative value due to the hypoglycemic glucose level. For example, the risk value may be between -<NUM> and -<NUM> for a first reference glucose state having a glucose level of <NUM> or <NUM>/dl and zero rate of change. As described above, the risk value associated with the second reference state is zero or some minimal value. Other suitable risk values may be provided depending on the selected reference glucose states and the user's associated risk surfaces and scale.

In the illustrated embodiment, the first and second reference glucose states each have a glucose rate of change of zero. Accordingly, the risk values determined for each reference state corresponds to the risk of the corresponding glucose level at zero rate of change (constant level). Other suitable reference states may be selected that have different glucose levels and nonzero glucose rates of change.

At block <NUM>, basal rate adjustment logic <NUM> calculates an adjustment to the reference basal rate identified at block <NUM> based on the total current risk from block <NUM> and the risks of the reference glucose states from block <NUM>. In particular, basal rate adjustment logic <NUM> calculates a percentage or fractional reduction of the reference basal rate according to the following equation: <MAT> wherein BM(R) is the adjustment factor (basal multiplier) of the reference basal rate, R is the current total risk calculated in block <NUM>, R<NUM>% is the risk value associated with the first reference glucose state, and R<NUM>% is the risk associated with the second reference glucose state. When the risk value R of the current glucose state is greater than or equal to the risk value R<NUM>% associated with the second reference glucose state, the adjustment factor is <NUM> resulting in no change to the current basal rate. In the illustrated embodiment, R<NUM>% is zero resulting in no basal rate adjustment made for a glucose state having a positive risk. When the risk value R is less than or equal to the risk value R<NUM>% associated with the first reference glucose state, which indicates a greater risk than the risk of the minimum glucose threshold, the adjustment factor is <NUM> resulting in a complete basal shutoff of pump <NUM> to stop insulin delivery. When the risk value R is between the risk R<NUM>% associated with the first reference glucose state and the risk R<NUM>% associated with the second reference glucose state, the adjustment factor is determined according to Equation (<NUM>).

At block <NUM>, basal rate adjustment logic <NUM> determines whether the adjustment factor results in an adjustment to the reference basal rate, i.e., if the adjustment factor is less than <NUM>. If no adjustment at block <NUM>, the method returns to block <NUM> to again determine the current basal rate. If there is an adjustment at block <NUM>, basal rate adjustment logic <NUM> calculates an adjusted basal rate at block <NUM> based on the reference basal rate and the adjustment factor, and management device <NUM> transmits a control signal to insulin pump <NUM> to cause pump <NUM> to deliver insulin at the adjusted basal rate. Alternatively, management device <NUM> may display the adjusted basal rate to the user to prompt the user for manual adjustment of the insulin pump <NUM>. Following block <NUM>, the method returns to block <NUM> and repeatedly executes until the adjusted basal rate returns to the unadjusted reference basal rate. In some embodiments, the implementation of the adjusted basal rate may be overridden by the user via manual control of the insulin pump <NUM>.

<FIG> illustrates a graph <NUM> of an exemplary basal rate adjustment factor (multiplier) based on the detected glucose level for the case where the rate of change of the glucose level is zero mg/dl/min. In <FIG>, the first reference glucose state is identified as a glucose level of <NUM>/dl with zero rate of change, and the second reference glucose state is identified as a glucose level of <NUM>/dl with zero rate of change. Based on the risk R<NUM>% associated with the first reference glucose state and the risk R<NUM>% associated with the second reference glucose state, the basal rate multiplier is determined according to Equation (<NUM>). As such, for any glucose state having any glucose level and any glucose rate of change, the risk associated with that glucose state may be mapped to a basal rate adjustment according to Equation (<NUM>).

As one example, a current risk R of -<NUM>, a first reference risk R<NUM>% of -<NUM>, and a second reference risk R<NUM>% of zero results in an adjustment factor of <NUM>/<NUM> or <NUM>% according to Equation (<NUM>). Accordingly, basal rate adjustment logic <NUM> multiplies the reference basal rate by an adjustment factor of <NUM> and communicates the adjusted basal rate to insulin pump <NUM>.

Referring to <FIG>, a flow diagram <NUM> of another exemplary method performed by management device <NUM> of <FIG> is illustrated for calculating an adjustment to a basal rate based on risk associated with a glucose state of a person with diabetes. Reference is made to <FIG> and <FIG> throughout the description of <FIG>. At block <NUM>, management device <NUM> receives a signal representative of at least one glucose measurement. At block <NUM>, management device <NUM> detects a glucose state of the person based on the signal. The detected glucose state includes a glucose level of the person and a rate of change of the glucose level, as described herein. At block <NUM>, management device <NUM> determines a current risk metric associated with the detected glucose state. The current risk metric indicates a risk of at least one of a hypoglycemic condition and a hyperglycemic condition of the person. In some embodiments, the risk metric is the risk value calculated based on the glucose level, the rate of change, and the associated uncertainty, as described herein.

At block <NUM>, management device <NUM> identifies a reference glucose state and a reference risk metric (e.g., risk R<NUM>%) associated with the reference glucose state. At block <NUM>, management device <NUM> calculates an adjustment to a basal rate of a therapy delivery device (e.g., insulin pump <NUM>) based on the current risk metric associated with the detected glucose state and the reference risk metric associated with the reference glucose level. In the illustrated embodiment, management device <NUM> further identifies a second reference glucose state and a second reference risk metric (e.g., risk R<NUM>%) associated with the second reference glucose state, and the adjustment to the basal rate is calculated further based on the second reference risk metric. In response to the hypoglycemic risk indicated by the current risk metric R being less than a hypoglycemic risk indicated by the reference risk metric R<NUM>% and greater than a hypoglycemic risk indicated by the second reference risk metric R<NUM>%, management device <NUM> generates a control signal to instruct the therapy delivery device to adjust the basal rate based on the calculated adjustment. In response to the hypoglycemic risk indicated by the current risk metric being less than a hypoglycemic risk indicated by the second reference risk metric R<NUM>%, management device <NUM> generates a control signal instructing the therapy delivery device to deliver therapy to the person at the basal rate.

In some embodiments, management device <NUM> displays to a user, on a graphical user interface such as display <NUM>, graphical data representative of the calculated adjustment to the basal rate.

In some embodiments when the current risk falls between the risks of the first and second reference glucose values, the partial shutoff of insulin pump <NUM> serves to reduce the likelihood of the glucose state crossing the minimum allowed hypoglycemic condition (e.g., <NUM> to <NUM>/dl). In some embodiments when the full shutoff of insulin pump <NUM> occurs (when the current hypoglycemic risk is greater than the hypoglycemic risk of the first reference glucose state), basal rate adjustment logic <NUM> implements a pump shutoff sequence. In particular, logic <NUM> generates a notification to the patient after the pump <NUM> has been shut off for a predetermined time lapse, such as <NUM> minutes or another suitable time lapse. The notification alerts the patient that the pump <NUM> has been shut-off and that it may be advisable to take some action. A notification may also be provided immediately after the pump <NUM> is first shut off. A notification may include a displayed warning via graphical data on display <NUM>, an audible warning (send audible signal to a speaker device), and/or a vibration warning (send vibration command signal to a vibration device). If the basal rate remains in complete shutoff for longer than a threshold time lapse (e.g., <NUM> hours), then the basal rate adjustment logic <NUM> may be disabled, and the user receives a notification of such an event.

A predictive notification may also be given to the patient prior to pump shutoff if the risk exceeds a risk threshold and the glucose level is below a glucose threshold. An exemplary risk threshold is <NUM> times the risk metric R<NUM>%, and an exemplary glucose level threshold is <NUM>/dl.

If a patient responds or acknowledges a notification (e.g., via a user input <NUM>), basal rate adjustment logic <NUM> displays a message on display <NUM> requesting that the patient eats a recommended amount of rescue carbohydrates, takes a blood glucose reading, and/or calibrates the glucose sensor if necessary. If the patient does not respond to the notification, the pump remains shut off and the blood glucose level is expected to slowly rise. If the patient does not respond to the notification after a further time lapse, and the glucose level continues to be low and/or descending further into hypoglycemia, logic <NUM> may generate and transmit an alarm to a glucagon kit so that the patient or care provider can be alerted to immediately inject some glucagon. The glucagon kit, which includes a computing device such as a processor and transceiver to receive and respond to the alarm, is in communication with management device <NUM> via any suitable communication link described herein.

In some embodiments, a temporary basal rate (TBR) is used to implement the basal rate adjustment described herein. The TBR is defined by the basal multiplier BM(R) from Equation (<NUM>) above as well as a duration for implementing the basal multiplier. Basal rate adjustment logic <NUM> determines the duration d for implementing the basal multiplier and a default duration dmax of the basal multiplier if communication with therapy delivery device <NUM> fails or is disrupted. In this embodiment, basal rate adjustment logic <NUM> determines the basal multiplier based on the risk calculated for a predicted glucose level at a time in the future. The following equations apply: <MAT> <MAT> wherein ĝ<NUM> is the predicted glucose value at the time t̂<NUM> in the future, g<NUM> is the current estimated glucose level, and ġ<NUM> is the rate of change of the current estimated glucose level. In one embodiment, the predicted rate of change associated with the predicted glucose level ĝ<NUM> is assumed to be constant (equal to ġ<NUM>). Hazard analysis logic <NUM> calculates the risk R for the predicted glucose level ĝ<NUM> and rate of change ġ<NUM>, and the basal multiplier BM(R) is calculated based on this predicted risk R according to Equation (<NUM>) above.

After a TBR has been commanded by basal rate adjustment logic <NUM>, the TBR is not updated in this embodiment until at least d time has passed. If the blood glucose management device <NUM> loses communication with therapy delivery device <NUM>, the TBR remains in effect until dmax time has passed. <FIG> illustrates an exemplary CGM trace <NUM> relative to a target glucose level <NUM>, wherein the x-axis represents time in minutes and the y-axis represents glucose in mg/dl. CGM trace <NUM> includes a current estimated glucose level g<NUM> and a predicted glucose level ĝ<NUM>. A basal multiplier <NUM> having an update rate of <NUM> minutes (d = <NUM> minutes) is illustrated along the bottom of the graph of <FIG>. Before time t<NUM>, the basal multiplier <NUM> is equal to <NUM> resulting in no adjustment to the current basal rate. At time t<NUM>, the basal multiplier <NUM> is about <NUM> for duration d until time t<NUM>. At time t<NUM> a new basal multiplier <NUM> of about <NUM> is calculated based on the predicted glucose level ĝ<NUM> and the current glucose level g<NUM>, as described above. The basal multiplier <NUM> of <NUM> is configured for implementation for duration d until time t<NUM>, or for duration dmax if communication is lost with therapy delivery device <NUM>.

In some embodiments, rather than continuous basal multiplier values, the basal multiplier may be limited to a specified incremental size, TBRinc, such that the final basal multiplier BMinc is given by the following equation: <MAT> wherein the increment size TBRinc may be <NUM>%, <NUM>%, <NUM>% or any other suitable increment size, and the "round" function rounds to a specified nearest decimal place or to a whole number. As described above, <FIG> illustrates a graph of a continuous basal multiplier. <FIG> illustrates a graph of a rounded incremental basal multiplier <NUM> based on the rounding Equation (<NUM>). As with <FIG>, the first reference glucose state is identified as a glucose level of <NUM>/dl with zero rate of change, and the second reference glucose state is identified as a glucose level of <NUM>/dl with zero rate of change. TBRinc is illustratively a <NUM>% increment in <FIG>. Based on the risk R<NUM>% associated with the first reference glucose state and the risk R<NUM>% associated with the second reference glucose state, the basal rate multiplier is determined according to Equations (<NUM>) and (<NUM>).

Alternatively, the basal multiplier may be limited to an incremental size TBRinc using a floor function that converts the continuous basal multiplier to an incremental basal multiplier, according to the following equation: <MAT> wherein the "floor" function rounds down to the previous decimal place or whole number (e.g., floor (<NUM>) = floor(<NUM>) = <NUM>) and the "max" function outputs the greater of <NUM> and the floor function result, thereby avoiding a negative basal multiplier. <FIG> illustrates the graph of the basal multiplier of <FIG> modified as an incremental basal multiplier <NUM> based on the flooring Equation (<NUM>). TBRinc is illustratively a <NUM>% increment in <FIG>. Based on the risk R<NUM>% associated with the first reference glucose state and the risk R<NUM>% associated with the second reference glucose state, the basal rate multiplier is determined according to Equations (<NUM>) and (<NUM>).

As described above, <FIG> illustrate respective hyper and hypo risk surfaces having state uncertainty. In some embodiments, the uncertainty of the glucose measurement may be convolved with the risk surfaces of <FIG> to create a risk lookup matrix where the uncertainty is constant or close to constant. The risk calculation process may include looking up the risk value in the convolved risk lookup matrix. For example, <FIG> illustrates a hyper risk surface <NUM> that is convolved from risk surface <NUM> of <FIG> assuming constant uncertainty. Similarly, <FIG> illustrates a hypo risk surface <NUM> that is convolved from risk surface <NUM> of <FIG> assuming constant uncertainty. The risk values of risk surfaces <NUM> and <NUM> are stored in a risk lookup matrix in memory <NUM> of <FIG>, where the convolved risk may be determined by looking up a particular glucose state.

In some embodiments, the full risk lookup matrix may not be used due to memory constraints. As such, a reduced risk matrix may be provided. The full risk lookup matrix is subsampled by first applying the uncertainty convolution to the full risk lookup matrix (i.e., <FIG>) and then selecting the appropriate subsamples. The resulting subsampled matrix has fewer stored glucose states and associated risk values. For example, an exemplary original size of the full risk matrix is <NUM> cells by <NUM> cells, each cell storing a risk value for a corresponding glucose state, to cover glucose levels ranging from <NUM>/dl to <NUM>/dl and rates of change ranging from -<NUM>/dl/min to <NUM>/dl/min. In one embodiment, the glucose level range is initially reduced to <NUM> to <NUM>/dl and the glucose rate of change range is reduced to -<NUM> to <NUM>/dl/min, resulting in a reduced risk matrix size of <NUM> cells by <NUM> cells. Logic <NUM> adjusts the risk value of any glucose state falling outside this range to the risk value of the nearest glucose state in the range. The risk matrix may be further subsampled to any suitable reduced size by using a subsampling factor. Exemplary subsample matrices include sizes of <NUM> cells by <NUM> cells (using a subsample factor of <NUM>), <NUM> cells by <NUM> cells (using a subsample factor of <NUM>), <NUM> cells by <NUM> cells (using a subsample factor of <NUM>), <NUM> cells by <NUM> cells (using a subsample factor of <NUM>), and <NUM> cells by <NUM> cells (using a subsample factor of <NUM>), although other suitable sizes may be provided. The memory space occupied by the subsampled risk matrix is reduced with each reduction in matrix size. Each subsampled risk matrix has a central (target) glucose rate of change of zero mg/dl/min. A subsample size may be selected to provide risk results as close as possible to the full risk matrix results while reducing memory consumption per system constraints.

After the risk matrix is subsampled to the desired size, a risk value for a detected glucose state is determined from the subsampled risk matrix using various techniques. In the illustrated embodiment, either of two methods of interpolating a risk value from the subsampled risk matrix may be implemented by hazard analysis logic <NUM> of <FIG>. A nearest neighbor algorithm selects the risk value for the glucose state closest to the current detected glucose state. A bilinear interpolation method calculates an interpolated risk value using bilinear interpolation when the current detected glucose state falls within the subsampled range of glucose states. In either method, logic <NUM> adjusts the risk value of any glucose state falling outside the subsampled range of glucose states to the risk value of the nearest glucose state within the range.

The interpolation technique may be selected based on experimental data and simulation that provide the most accurate results as compared with the full risk matrix. In some embodiments, the bilinear interpolation produces interpolated risk values that are more accurate than the nearest neighbor values as the size of the subsampled matrix decreases due to the widening gap between subsampled glucose states.

<FIG> illustrates a portion <NUM> of a risk surface subsampled at the circular points <NUM>, which represent subsampled glucose states. In <FIG>, the risk values are interpolated from the subsampled circular points <NUM> using the nearest neighbor algorithm. <FIG> illustrates a portion <NUM> of the risk surface with the risk values interpolated from the subsampled circular points <NUM> using the bilinear interpolation algorithm. In <FIG>, the glucose level (mg/dl) is on the x-axis, the rate of glucose change (mg/dl/min) is on the y-axis, and the risk value is on the z-axis. In the embodiments illustrated in <FIG>, the bilinear interpolation method produces a smoother risk surface that more closely resembles the full risk matrix as compared with the nearest neighbor algorithm.

<FIG> illustrates several representations <NUM>, <NUM>, <NUM>, and <NUM> of subsampled risk surfaces following interpolation. The samples are represented by the vertices of the rectangles or cells <NUM>, as best illustrated in risk surfaces <NUM> and <NUM>. Risk surface <NUM> has a size of <NUM> cells by <NUM> cells, risk surface <NUM> has a size of <NUM> cells by <NUM> cells, risk surface <NUM> has a size of <NUM> cells by <NUM> cells, and risk surface <NUM> has a size of <NUM> cells by <NUM> cells.

While the present disclosure has been described herein with respect to insulin basal rates, other suitable basal rates may be adjusted based on the methods of <FIG> and <FIG>. For example, other therapies for controlling glucose levels of diabetic people may be administered according to a basal rate which may be adjusted according to the embodiments disclosed herein.

While various embodiments of devices, systems, methods, and non-transitory computer readable medium for analyzing a glucose state and for calculating a basal rate adjustment have been described in detail herein, the embodiments are merely offered by way of nonlimiting examples of the disclosure described herein. It will therefore be understood that various changes and modifications may be made, and equivalents may be substituted for elements thereof, without departing from the scope of the disclosure. Indeed, this disclosure is not intended to be exhaustive or to limit the scope of the disclosure.

Further, in describing representative embodiments, the disclosure may have presented a method and/or process as a particular sequence of steps. However, to the extent that the method or process does not rely on the particular order of steps set forth herein, the method or process should not be limited to the particular sequence of steps described. Other sequences of steps may be possible. Therefore, the particular order of the steps disclosed herein should not be construed as limitations of the present disclosure. In addition, disclosure directed to a method and/or process should not be limited to the performance of their steps in the order written. Such sequences may be varied and still remain within the scope of the present disclosure.

In an example not part of the invention as claimed, a method of determining a basal rate adjustment based on risk associated with a glucose state of a person with diabetes may be provided, the method comprising:.

The calculating may comprise mapping the current risk metric to a percent reduction of the basal rate based on the reference risk metric.

The reference glucose state may include a glucose level corresponding to a hypoglycemic condition.

The current risk metric may be determined based on at least one penalty value associated with the detected glucose state and a probability of accuracy of the detected glucose state, and the at least one penalty value is indicative of a hazard associated with the detected glucose state.

The current risk metric may be determined based on a target transition from the current glucose state to the target glucose state, the target transition comprising at least one intermediate glucose state associated with a return to the target glucose state.

The current risk metric may be determined based on a cumulative penalty value weighted with a probability of accuracy of the detected glucose state, the cumulative penalty value including a sum of penalty values associated with a plurality of intermediate glucose states of the target transition to the target glucose state, each penalty value being indicative of a hazard associated with the corresponding intermediate glucose state.

The method may further comprise, in response to the risk indicated by the current risk metric being greater than a risk indicated by the reference risk metric, generating a control signal to instruct the therapy delivery device to stop delivering therapy to the person.

The method may further comprise, following a predetermined time lapse after instructing the therapy delivery device to stop delivering therapy, generating a notification that the therapy delivery device has been stopped, the notification including at least one of graphical data displayed on a graphical user interface, an audible signal, and a vibration signal.

The method may further comprise identifying a second reference glucose state and a second reference risk metric associated with the second reference glucose state, wherein a glucose level of the second reference glucose state is greater than a glucose level of the reference glucose state, and the at least one computing device calculates the adjustment to the basal rate further based on the second reference risk metric.

The method may further comprise displaying to a user, on a graphical user interface, graphical data representative of the calculated adjustment to the basal rate.

The method may further comprise transmitting a control signal to instruct the therapy delivery device to adjust the basal rate based on the calculated adjustment.

The therapy delivery device may include an insulin pump for delivering insulin to the person with diabetes and the therapy delivery device may be in communication with the at least one computing device for receiving the calculated adjustment of the basal rate.

The method may further comprise, prior to calculating the adjustment to the basal rate,.

Adjusting the current risk metric may include increasing a target glucose level of the target glucose state based on the at least one of the correction meal rise value and the correction delta glucose value, and determining the current risk metric based on the increased target glucose level.

In an example not part of the invention as claimed, a blood glucose management device configured to determine a basal rate adjustment based on risk associated with a glucose state of a person with diabetes may be provided, the device comprising:.

The at least one processing device may calculate the adjustment by mapping the current risk metric to a percent reduction of the basal rate based on the reference risk metric.

The executable instructions may further cause the at least one processing device to transmit a control signal to instruct the therapy delivery device to adjust the basal rate based on the calculated adjustment.

The at least one processing device may determine the current risk metric based on at least one penalty value associated with the detected glucose state and a probability of accuracy of the detected glucose state, and the at least one penalty value is indicative of a hazard associated with the detected glucose state.

The at least one processing device may determine the current risk metric based on a target transition from the current glucose state to a target glucose state, the target transition comprises at least one intermediate glucose state associated with a return to the target glucose state, and the current risk metric is determined by the at least one processing device further based on a cumulative penalty value weighted with a probability of accuracy of the detected glucose state, wherein the cumulative penalty value includes a sum of penalty values associated with a plurality of intermediate glucose states of the target transition to the target glucose state, and each penalty value is indicative of a hazard associated with the corresponding intermediate glucose state.

The executable instructions may further cause the at least one processing device to, in response to the risk indicated by the current risk metric being greater than a risk indicated by the reference risk metric, generate a control signal to instruct the therapy delivery device to stop delivering therapy to the person.

The executable instructions may further cause the at least one processing device to, following a predetermined time lapse after instructing the therapy delivery device to stop delivering therapy, generate a notification that the therapy delivery device has been stopped, the notification including at least one of graphical data displayed on a graphical user interface, an audible signal, and a vibration signal.

The executable instructions may further cause the at least one processing device to identify a second reference glucose state and a second reference risk metric associated with the second reference glucose state, wherein a glucose level of the second reference glucose state is greater than a glucose level of the reference glucose state, and the adjustment to the basal rate is calculated by the at least one processing device further based on the second reference risk metric.

The executable instructions may further cause the at least one processing device to.

The executable instructions may further cause the at least one processing device to generate graphical data representative of the calculated adjustment to the basal rate and to display the graphical data on a display in communication with the at least one processing device.

Claim 1:
A blood glucose management device (<NUM>) configured to determine a basal rate adjustment based on risk associated with a glucose state of a person with diabetes, the device (<NUM>) comprising:
- a non-transitory computer-readable medium (<NUM>) storing executable instructions; and
- at least one processing device (<NUM>) configured to execute the executable instructions such that, when executed by the at least one processing device (<NUM>), the executable instructions cause the at least one processing device (<NUM>) to:
- receive a signal representative of at least one glucose measurement;
- detect a glucose state of the person based on the signal, the detected glucose state including a glucose level of the person and a rate of change of the glucose level;
- determine a current risk metric associated with the detected glucose state, the current risk metric indicating a risk of at least one of a hypoglycemic condition and a hyperglycemic condition of the person;
- identify a first reference glucose state, which includes a glucose level corresponding to a hypoglycemic condition, and a first reference risk metric associated with the first reference glucose state;
- identify a second reference glucose state, corresponding to a glucose level and rate of change having no or minimal associated hypoglycemic risk, and a second reference risk metric associated with the second reference glucose state, wherein a glucose level of the second reference glucose state is greater than a glucose level of the first reference glucose state,
- in response to the risk indicated by the current risk metric being greater than a risk indicated by the first reference risk metric and less than a risk indicated by the second reference risk metric, calculate an adjustment to a basal rate of a therapy delivery device (<NUM>) as a difference between the risk indicated by the current risk metric and the risk indicated by the first reference risk metric divided by a difference between the risk indicated by the second reference risk and the risk indicated by the first reference risk, and
- in response to the risk indicated by the current risk metric being less than or equal to the risk indicated by the first reference risk metric, generate a control signal to instruct the therapy delivery device (<NUM>) to stop delivering therapy to the person.