System and method for decision support

Abstract

To provide systems and methods to provide guidance to a user regarding management of a physiologic condition such as diabetes.SOLUTION: The determination may be based upon a patient glucose concentration level. The glucose concentration level may be provided to a stored model to determine a state. The guidance may be determined based at least in part on the determined state.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] TECHNICAL FIELD This development relates generally to medical devices, such as analyte sensors, including systems and methods for providing therapeutic decision support using the medical devices. [Background technology]

[0002] Diabetes is a metabolic condition associated with the body's production or use of insulin, a hormone that enables the body to use glucose for energy or store it as fat.

[0003] When a person eats a meal containing carbohydrates, the food is processed by the digestive system which produces glucose in the person's blood. The blood sugar can be used for energy or stored as fat. The body normally maintains blood sugar levels in a range that provides enough energy to support bodily functions and avoids problems that can occur if glucose levels are too high or too low. Regulation of blood sugar levels depends on the production and use of insulin, which regulates the movement of blood sugar into cells.

[0004] If the body does not produce enough insulin, or if the body cannot effectively use the insulin that is present, blood glucose levels can rise above the normal range. Higher than normal blood glucose levels are referred to as "hyperglycemia". Chronic hyperglycemia can lead to many health problems, including cardiovascular disease, eye problems such as cataracts, nerve damage (neuropathy), and kidney damage. Hyperglycemia can also lead to acute problems such as diabetic ketoacidosis - a condition in which the body becomes too acidic due to the presence of glucose in the blood and ketones, which are produced when the body cannot use glucose. A condition in which blood glucose levels are lower than normal is referred to as "hypoglycemia". Severe hypoglycemia can cause acute episodes, which can lead to seizures and death.

[0005] Diabetics can receive insulin to manage their blood glucose levels. Insulin can be received, for example, by manual injection with a needle. Wearable insulin pumps are also available. Diet and exercise also affect blood glucose levels.

[0006] The condition of diabetes is sometimes referred to as "Type 1" and "Type 2." Type 1 diabetes patients are normally able to use insulin when it is present, but because of problems with the insulin-producing beta cells in the pancreas, the body is unable to produce enough insulin. Type 2 diabetes patients are able to produce insulin, but have reduced sensitivity to insulin, making the patient "insulin resistant." As a result, even though insulin is present in the body, it is not used sufficiently by the patient's body to effectively regulate blood sugar levels.

[0007] This Background is provided to introduce a brief context for the Summary and Detailed Description that follow. This Background is not intended to aid in determining the scope of the claimed subject matter, nor is it to be considered as limiting the claimed subject matter to implementations that solve any or all of the disadvantages or problems discussed above. Summary of the Invention [Means for solving the problem]

[0008] This document describes, among other things, systems and methods for determining delivery or decision time of patient or caregiver decision support guidance.

[0009] An example (e.g., “Example 1”) of the subject matter (e.g., methods or systems) may include measuring, determining, or receiving first real-time data related to a patient, determining a state in which the patient is using at least in part the model and the first real-time data, determining a guidance message based at least in part on the determined state, and providing the determined personalized guidance message via a user interface at a time calculated to enable intervention prior to transition to an undesirable physiological state.

[0010] In Example 2, the subject matter of Example 1 can be configured such that determining the guidance message is further based on a timing of determining the guidance message or a time associated with the determined condition.

[0011] In Example 3, the subject matter of Example 1 or Example 2 can be configured such that the model includes a state indicating the convenience or availability of the patient to participate in the intervention.

[0012] In Example 4, the subject matter of any one or any combination of Examples 1-3 can be configured such that the guidance message is based at least in part on a predicted transition to an undesirable physiological state.

[0013] In Example 5, the subject matter of any one or any combination of Examples 1-4 can be configured such that the guidance message is based at least in part on a determination that a predicted transition from the current state to the predicted state is a low probability transition.

[0014] In Example 6, the subject matter of any one or any combination of Examples 1-5 can be configured such that the model includes a physiological model of the patient, and determining the patient state is based at least on applying the first real-time data to the physiological model of the patient.

[0015] In Example 7, the subject matter of any one or any combination of Examples 1-6 can be configured such that the model includes a behavioral model.

[0016] In Example 8, the subject matter of any one or any combination of Examples 1-7 can be configured such that the behavioral model is based on machine learning characteristics of the patient, and the machine learning characteristics are based on behavioral or contextual patterns.

[0017] In Example 9, the subject matter of any one or any combination of Examples 1-8 can be configured such that the behavioral model is based on a set of one or more steps determined to be likely to be performed by the patient.

[0018] In Example 10, the subject matter of any one or any combination of Examples 1-9 can be configured such that the behavioral model is based on a set of one or more objectives determined to be likely achievable by the patient.

[0019] In Example 11, the subject matter of any one or any combination of Examples 1-10 can be configured to include a behavioral model, where the model is a pattern.

[0020] In Example 12, the subject matter of any one or any combination of Examples 1-11 can be configured such that the model includes a physiological model of the patient based on the physiological patterns and a behavioral model based on the behavioral patterns.

[0021] In Example 13, the subject matter of any one or any combination of Examples 1-12 can be configured such that the first real-time data indicates a deviation from an expected behavioral pattern.

[0022] In Example 14, the subject matter of any one or any combination of Examples 1-13 can be configured such that the behavioral model indicates a tendency to overcorrect in meals related to mealtimes, the first real-time data indicates that the mealtime is imminent, and the guidance message corresponds to an undercorrection of the mealtime.

[0023] In Example 15, the subject matter of any one or any combination of Examples 1-14 can be configured such that the model includes behavioral patterns including long-term behavioral patterns related to current behavior and long-term behavioral patterns based on short-term behavioral patterns.

[0024] In Example 16, the subject matter of Example 15 can be configured such that the behavioral model is based on long-term behavioral patterns and further based on short-term behavioral patterns.

[0025] In Example 17, the subject matter of Example 16 can be configured such that the short-term behavioral patterns are based on one or more selected from the group consisting of engagement with a mobile device, accelerometer data, frequency of checking glucose levels, calendar data, and any combination thereof.

[0026] In Example 18, the subject matter of any one or any combination of Examples 1-17 can be configured such that the state is based in part on a measurement model.

[0027] In Example 19, the subject matter of Example 18 can be configured such that the measurement model is based on a continuous glucose concentration monitoring system associated with the patient.

[0028] In Example 20, the subject matter of any one or any combination of Examples 1-19 may further include measuring glucose concentration data following providing the guidance message and using the measured subsequent data to improve one or more models.

[0029] In Example 21, the subject matter of any one or any combination of Examples 1-19 can be configured such that glucose concentration data measured after provision is fed back into a measurement model, or a behavioral model, or a patient physiological model, or a combination thereof.

[0030] In Example 22, the subject matter of any one or any combination of Examples 1-21 can be configured such that the model includes a pattern selected from the group consisting of a physiological pattern, a contextual pattern, or a behavioral pattern, or a combination of these patterns.

[0031] In Example 23, the subject matter of any one or any combination of Examples 1-22 can be configured such that the physiological pattern is based on a physiological model.

[0032] In Example 24, the subject matter of any one or any combination of Examples 1-23 can be configured such that the model is based on a combination of patterns selected from the group consisting of physiological patterns, contextual patterns, or behavioral patterns.

[0033] In Example 25, the subject matter of any one or any combination of Examples 1-24 may be configured such that determining the guidance message includes determining a plurality of guidance messages based on the status and the first real-time data, and selecting one of the plurality of guidance messages further determined based further on the status and the first real-time data.

[0034] In Example 26, the subject matter of Example 25 can be configured such that the selection is further based on a ranking scheme, a prioritization scheme, or based on a comparison of the plurality of guidance messages to one or more associated thresholds.

[0035] In Example 27, the subject matter of any one or any combination of Examples 1-26 can further include determining a predicted diabetic response for the patient based on the condition and the first real-time data, wherein the guidance message is personalized for the patient further based on the predicted diabetic response, and an actionable message is provided to the patient calculated to move the predicted diabetic response toward a desired diabetic response.

[0036] In Example 28, subject example 27 can be configured such that a desired diabetic response is associated with the condition and the first real-time data, and the desired diabetic response is selected from the group consisting of an improved diabetic response, a potential improved diabetic response, an ideal response, or an optimized response.

[0037] In Example 29, the subject matter of any one or any combination of Examples 1-28 can be configured such that the guidance message is based on a functional relationship between an expected diabetic response and a desired diabetic response.

[0038] In Example 30, the subject matter of Example 29 can be configured such that the functional relationship is the difference between a glucose concentration level associated with an expected diabetic response and a glucose concentration level associated with a desired diabetic response.

[0039] In Example 31, the subject matter of Example 30 can be configured such that the glucose concentration level associated with a desired diabetic response is a target glucose concentration level or a target glucose concentration range.

[0040] In Example 32, the subject matter of any one or any combination of Examples 29-31 can be configured such that the functional relationship is based on whether the predicted diabetic response matches predetermined conditions associated with the desired diabetic response.

[0041] In Example 33, the subject matter of Example 32 can be configured such that the predetermined condition is a target glucose concentration level, a target glucose concentration range, a glucose concentration signal signature, a rate of change associated with a glucose concentration level, or a combination thereof.

[0042] In Example 34, the subject matter of any one or any combination of Examples 1-33 can be configured such that the guidance message further includes one or more reasons related to the functional relationship so that the patient can be informed as to why the guidance message is being provided.

[0043] In Example 35, the subject matter of any one or any combination of Examples 1-34 can be configured such that the guidance message includes an actionable prompt.

[0044] In Example 36, the subject matter of Example 34 can be configured such that the guidance message includes actionable prompts calculated to move the patient's glucose concentration level toward a target level or range.

[0045] In Example 37, the subject matter of any one or any combination of Examples 1-36 can be configured such that the guidance message includes an affirmation of a current behavior associated with the patient.

[0046] In Example 38, the subject matter of any one or any combination of Examples 1-37 can be configured such that the first real-time data is measured, received, or determined by a smartphone.

[0047] In Example 39, the subject matter of any one or any combination of Examples 1-38 can be configured such that the first real-time data is measured, received, or determined by a wearable device.

[0048] In Example 40, the subject matter of any one or any combination of Examples 1-39 can be configured such that the first real-time data is measured, received, or determined by a wearable device in combination with a smartphone.

[0049] In Example 41, the subject matter of any one or any combination of Examples 1-40 can be configured such that the first real-time data is measured, received, or determined by an external device.

[0050] In Example 42, the subject matter of Example 41 can be configured such that the external device is an accelerometer.

[0051] In Example 43, the subject matter of any one or any combination of Examples 1-42 can be configured such that the first real-time data includes a time of day, a characteristic or signature signal measured by an accelerometer, or a location determined by a GPS circuit.

[0052] In Example 44, the subject matter of any one or any combination of Examples 1-43 can be configured such that the first real-time data includes a change in state.

[0053] In Example 45, the subject matter of any one or any combination of Examples 1-44 can be configured such that the change in state is detected by a clock, an accelerometer, or a GPS circuit.

[0054] In Example 46, the subject matter of any one or any combination of Examples 1-45 can be configured such that the first real-time data includes a user request for a decision support prompt.

[0055] In Example 47, the subject matter of any one or any combination of Examples 1-46 can be configured such that the first real-time data includes data received from a continuous glucose concentration monitoring system.

[0056] In Example 48, the subject matter of any one or any combination of Examples 1-47 can further include measuring, determining, or receiving second real-time data, the second real-time data being used in determining a condition in which the patient is.

[0057] In Example 49, the subject matter of any one or any combination of Examples 1-48 can be configured to occur when a determined personalized guidance message is calculated to be useful in managing a patient's glucose concentration level.

[0058] Example 50 is a system comprising a glucose concentration sensor configured to detect a glucose concentration level of a patient, a communications circuit configured to receive the patient's glucose concentration level from the glucose concentration sensor, a memory circuit including a stored model, and a processor configured to receive the patient's glucose concentration level and execute the stored instructions to apply the patient's glucose concentration level to the stored model to determine a condition, and to determine a guidance message based at least in part on the determined condition.

[0059] In Example 51, the subject matter of Example 50 optionally includes wherein the processor is also configured to determine the guidance message based at least in part on a temporal pattern.

[0060] In Example 52, the subject matter of any one or more of Examples 50-51 optionally includes wherein the model includes a physiological model and determining the state includes determining a physiological state.

[0061] In Example 53, the subject matter of Example 52 optionally includes the processor being further configured to determine a behavioral state and determine the guidance message based at least in part on the behavioral state.

[0062] In Example 54, the subject matter of any one or more of Examples 50-53 optionally includes the processor being further configured to provide a treatment recommendation based at least in part on the determined condition.

[0063] In Example 55, the subject matter of any one or more of Examples 50-54 optionally includes where the system includes a mobile device, the mobile device including a memory circuit and a processor.

[0064] In Example 56, the subject matter of Example 55 optionally includes wherein the mobile device includes a communication circuit, and wherein the glucose concentration sensor includes a glucose concentration sensor communication circuit configured to communicate with the communication circuit.

[0065] In Example 57, the subject matter of Example 56 optionally includes the mobile device communication circuitry including a first wireless transceiver, the glucose concentration sensor communication circuitry including a second wireless transceiver, and the mobile device communication circuitry and the glucose concentration sensor communication circuitry communicating using a wireless communication protocol.

[0066] In Example 58, the subject matter of any one or more of Examples 55-57 optionally includes the mobile device including a user interface configured to provide a guidance message.

[0067] In Example 59, the subject matter of Example 58 optionally includes the mobile device being configured to receive user input via a user interface, and the processor being configured to receive the user input and apply both the user input and the patient's glucose concentration level to the model to determine the state.

[0068] In Example 60, the subject matter of any one or more of Examples 55-59 optionally includes an insulin delivery system.

[0069] In Example 61, the subject matter of Example 60 optionally includes wherein the insulin delivery system includes an insulin pump.

[0070] In Example 62, the subject matter of any one or more of Examples 60-61 optionally includes where the insulin delivery system includes an insulin pen.

[0071] In Example 63, the subject matter of any one or more of Examples 50-62 optionally includes a user interface configured to provide guidance messages to the patient.

[0072] Example 64 is a method of delivering physiological glucose concentration management guidance comprising receiving data indicative of a glucose concentration level, determining a state by applying the data to a model, and determining a guidance message based at least in part on the state and the temporal pattern.

[0073] In Example 65, the subject matter of Example 64 optionally includes wherein the temporal pattern includes a learned pattern of patient behavior.

[0074] In Example 66, the subject matter of any one or more of Examples 64-65 optionally includes that the temporal pattern includes a calendar.

[0075] In Example 67, the subject matter of Example 66 optionally includes determining the guidance message based at least in part on an upcoming event in a calendar.

[0076] In Example 68, the subject matter of Example 67 optionally includes determining the guidance message based at least in part on an expected change in insulin sensitivity calculated based at least in part on an upcoming event in a calendar.

[0077] In Example 69, the subject matter of any one or more of Examples 64-68 optionally includes, wherein the model includes a physiological model, and wherein determining the state includes determining a physiological state, and wherein determining the guidance message includes determining from the temporal pattern and the physiological pattern that a transition to an undesirable physiological state is likely to occur.

[0078] In Example 70, the subject matter of Example 69 includes, if desired, determining the guidance message includes determining an intervention to avoid a transition to the undesirable physiological state and determining, based at least in part on the temporal pattern, a delivery time of the guidance message to enable intervention to prevent the transition.

[0079] In Example 71, the subject matter of any one or more of Examples 64-70 optionally includes determining a delivery time for delivering the guidance message using a temporal pattern.

[0080] In Example 72, the subject matter of Example 71 optionally includes where determining the delivery time includes selecting the delivery time when the host is more likely to be available based at least in part on a temporal pattern.

[0081] In Example 73, the subject matter of any one or more of Examples 71-72 optionally includes determining the delivery time including identifying an upcoming period of time during which the patient is unavailable and selecting a time to deliver the guidance message prior to the period of time during which the patient is unavailable.

[0082] In Example 74, the subject matter of any one or more of Examples 64-73 optionally includes determining the guidance message includes identifying periods of patient unavailability based at least in part on the temporal pattern, and the guidance message is calculated to promote stability of glucose concentrations during the periods of unavailability.

[0083] In Example 75, the subject matter of any one or more of Examples 64-74 optionally includes determining an engagement state, determining a messaging frequency based at least in part on the engagement state, and determining a time for delivering a guidance message based at least in part on the messaging frequency.

[0084] In Example 76, the subject matter of Example 75 includes, if desired, determining that an engagement state has changed to a changed engagement state, determining a new messaging frequency based at least in part on the changed engagement state, determining a second guidance message, and determining a second time for delivering the second guidance based at least in part on the new messaging frequency.

[0085] In Example 77, the subject matter of any one or more of Examples 64-76 optionally includes where the condition is a disease state describing a host disease stage.

[0086] In Example 78, the subject matter of Example 77 optionally includes receiving second data indicative of a second glucose concentration level, determining a second disease state describing at least in part a second host disease stage by applying the second data to a model, and determining a second guidance message based at least in part on the second disease state.

[0087] In Example 79, the subject matter of any one or more of Examples 64-78 optionally includes where determining the condition includes determining a physiological condition.

[0088] In Example 80, the subject matter of Example 79 optionally includes where determining the physiological state includes determining an insulin state, an energy absorption state, and an energy expenditure state.

[0089] In Example 81, the subject matter of any one or more of Examples 64-80 may optionally include receiving a behavioral input, and determining the state may include applying both the data and the behavioral input to a model.

[0090] In Example 82, the subject matter of Example 81 optionally includes where receiving the behavioral input includes receiving patient activity information.

[0091] Example 83 is a method of delivering physiological glucose concentration management guidance comprising receiving data indicative of a glucose concentration, determining a physiological state using the data, determining a behavioral state, determining a guidance message based at least in part on the physiological state and the behavioral state, and delivering the guidance message using a user interface.

[0092] In Example 84, the subject matter of Example 83 includes determining a time to deliver guidance to enable timely intervention to affect glucose concentrations, if necessary.

[0093] In Example 85, the subject matter of any one or more of Examples 83-84 optionally includes determining a level of interest in guidance based at least in part on behavioral and physiological states.

[0094] In Example 86, the subject matter of Example 85 optionally includes determining a level of interest in the treatment guidance based at least in part on a user request for prior guidance.

[0095] In Example 87, the subject matter of any one or more of Examples 83-86 optionally includes where determining the behavioral state includes receiving a behavioral input and applying the behavioral input to a behavioral state model.

[0096] In Example 88, the subject matter of any one or more of Examples 83-87 optionally includes determining the behavioral state includes checking a user calendar for scheduled events.

[0097] In Example 89, the subject matter of any one or more of Examples 83-88 optionally includes where determining the physiological state includes applying the data to a physiological state model.

[0098] In Example 90, the subject matter of Example 89 optionally includes wherein the physiological state model includes a glucose concentration level.

[0099] In Example 91, the subject matter of Example 90 optionally includes where the physiological state model further includes one or more of an insulin state, an energy absorption state, and an energy expenditure state.

[0100] In Example 92, the subject matter of any one or more of Examples 83-91 optionally includes determining a measurement state, where the measurement state includes precision or accuracy of the data indicative of the glucose concentration.

[0101] In Example 93, the subject matter of any one or more of Examples 83-92 optionally further comprises determining that a low probability physiological state transition is likely to occur, wherein the guidance message provides advance notice of the low probability physiological state transition.

[0102] In Example 94, the subject matter of Example 93 optionally includes where the low probability physiological state transition includes a transition to a low glucose concentration level or a high glucose concentration level.

[0103] In Example 95, the subject matter of any one or more of Examples 93-94 optionally includes determining that a low probability physiological state transition is likely to occur at an inconvenient time, and the guidance message provides advance warning of the predicted low probability physiological state transition to enable intervention to avoid the low probability physiological state transition.

[0104] In Example 96, the subject matter of Example 95 includes, if desired, determining that a low probability physiological state transition is likely to occur at an inconvenient time includes applying the behavioral input to a behavioral state model.

[0105] In Example 97, the subject matter of any one or more of Examples 83-96 optionally includes receiving an additional physiological parameter, and a physiological condition is determined using both the data and the additional physiological parameter.

[0106] In Example 98, the subject matter of Example 97 optionally includes wherein the additional physiological parameters include body temperature, heart rate, or respiratory rate.

[0107] In Example 99, the subject matter of any one or more of Examples 83-98 optionally includes receiving, during a learning period, learning data describing at least one of the physiological state or behavioral state, wherein at least one of the physiological state or behavioral state is determined after the learning period using the learning data.

[0108] Example 100 is a method for determining and providing a personalized, useful, calculated guidance message to a patient for diabetes medical management, comprising receiving data associated with the patient, the data including a real-time glucose concentration level, determining a patient state by applying the data to a state model, and providing a treatment recommendation based at least in part on the determined state.

[0109] In Example 101, the subject matter of Example 100 optionally includes where the patient status includes an insulin on-board status, an insulin sensitivity status, and a food consumption status.

[0110] In Example 102, the subject matter of any one or more of Examples 100-101 optionally includes where the state model is a probabilistic state model.

[0111] In Example 103, the subject matter of Example 102 optionally includes wherein the state model includes state transition probabilities that are learned from retrospective data.

[0112] In Example 104, the subject matter of any one or more of Examples 100-103 optionally includes refining the condition model using data received after delivery of the treatment recommendation.

[0113] Example 105 is a method of providing decision support functionality to a user, comprising loading the model into a memory of a computing environment, receiving data indicative of a glucose concentration value of the user, and displaying the calculated insight on a user interface of the computing environment, where the insight is calculated using at least the model and the data indicative of the glucose concentration value.

[0114] In example 106, the subject matter of example 105 optionally includes causing the display to be initiated by a user request.

[0115] In Example 107, the subject matter of Example 106 optionally includes the user request being associated with data input of a planned activity, and the calculated insights indicating user behavior calculated by one or more models to result in a desired outcome associated with the glucose concentration value.

[0116] In Example 108, the subject matter of Example 107 optionally includes the desired result being a glucose concentration value within a predetermined target range.

[0117] In Example 109, the subject matter of any one or more of Examples 107-108 optionally includes where the desired result is a glucose concentration value having a rate of change within a predetermined target range.

[0118] In Example 110, the subject matter of any one or more of Examples 107-109 optionally includes where the planned activity is a meal and the calculated insight is a calculated or predicted effect of the meal on glucose concentration values.

[0119] In Example 111, the subject matter of any one or more of Examples 107-110 optionally includes wherein the displayed calculated insight includes an interactive recommendation and at least one factor used in determining the interactive recommendation.

[0120] In Example 112, the subject matter of any one or more of Examples 105-111 optionally includes causing the display of the calculated insight to be triggered by the occurrence of an event matching a predetermined condition.

[0121] In Example 113, the subject matter of any one or more of Examples 105-112 optionally includes causing the display of the calculated insight to be initiated by the occurrence of an event matching a calculated condition, the calculated condition being calculated at least in part based on a model, or data indicative of a glucose concentration value, or a combination thereof.

[0122] In Example 114, the subject matter of Example 113 includes, if necessary, adjusting the warnings and / or alarms to have additional sensitivity for a period of time after the treatment adjustment if the treatment adjustment exposes the user to more risk than was present prior to the treatment adjustment.

[0123] In Example 115, the subject matter of any one or more of Examples 113-114 optionally includes detecting when a period exists following a potential treatment decision that triggers more frequent instantiation of the CGM app than prior to the potential treatment decision, and increasing the frequency of decision support messaging.

[0124] In Example 116, the subject matter of any one or more of Examples 113-115 optionally includes that the messaging is to the user or the user's followers.

[0125] In Example 117, the subject matter of any one or more of Examples 105-116 optionally includes using the received data to detect the occurrence of a trend associated with the recognized pattern.

[0126] In Example 118, the subject matter of any one or more of Examples 105-117 optionally includes receiving data from an external data source.

[0127] In Example 119, the subject matter of Example 118 optionally includes where the external data source is an insulin pen or pump and the calculated insights include information regarding insulin onboarding.

[0128] In Example 120, the subject matter of Example 119 optionally includes the external data source being an insulin pen or pump and the calculated insight being represented by two values, one indicating usage when the user has exercise planned and the other indicating usage when the user has no exercise planned.

[0129] In Example 121, the subject matter of any one or more of Examples 119-120 optionally includes where the external data source is an accelerometer and the calculated insight includes information regarding the impact of exercise on glucose concentration values.

[0130] In Example 122, the subject matter of any one or more of Examples 119-121 optionally includes where the external data source is a camera or a GPS receiver and the calculated insights include information regarding the effect of meal size and composition on glucose concentration values.

[0131] In Example 123, the subject matter of any one or more of Examples 119-122 optionally includes where the external data source is a user interface, where the user interface is configured to receive data regarding a user's goal, and where the calculated insights include a percentage of time in a goal range and an indication of the goal range.

[0132] In Example 124, the subject matter of any one or more of Examples 105-123 optionally includes loading a measurement model of a continuous glucose concentration monitoring system associated with the user into a memory of the computing environment, wherein the calculated insight is further based on the measurement model.

[0133] In Example 125, the subject matter of Example 124 optionally includes wherein the calculated insight is calculated using an algorithm based at least in part on glucose concentration variability or the likelihood and / or severity of glucose concentration variability.

[0134] In Example 126, the subject matter of any one or more of Examples 105-125 optionally includes causing the display to be based on a calculation that is performed periodically.

[0135] In Example 127, the subject matter of Example 126 optionally includes determining the period based on a series of meal times that occur substantially simultaneously.

[0136] In Example 128, the subject matter of any one or more of Examples 126-127 optionally includes determining a cycle based on a series of similar glycemic responses.

[0137] In Example 129, the subject matter of Example 128 optionally includes where the similar glycemic response is a spike.

[0138] In Example 130, the subject matter of any one or more of Examples 126-129 optionally includes determining a cycle based on a series of similar dosing strategies.

[0139] In Example 131, the subject matter of any one or more of Examples 126-130 optionally includes determining a period based on a series of unreliable results in which the glucose concentration level has drifted a specified percentage or amount away from a target zone following a potential treatment decision.

[0140] In Example 132, the subject matter of any one or more of Examples 105-131 optionally includes where the display of the calculated insight includes a display of a probability cone based on the user's prior data.

[0141] In Example 133, the subject matter of any one or more of Examples 105-132 optionally includes where the display of the calculated insight includes a display of a probability cone based on population data.

[0142] In Example 134, the subject matter of Example 133 optionally includes that population data is extracted from people who have one or more demographic characteristics in common with the user.

[0143] In Example 135, the subject matter of any one or more of Examples 105-134 optionally includes where the display of the calculated insight includes a display of two separate trend indicators, one determined using data measured on weekdays and the other determined using data measured on weekends.

[0144] In Example 136, the subject matter of any one or more of Examples 105-135 optionally includes that the insight is computed by the computing environment.

[0145] In Example 137, the subject matter of any one or more of Examples 105-136 optionally includes that the insights are calculated by a connected server.

[0146] In Example 138, the subject matter of any one or more of Examples 105-137 optionally includes where the model includes a physiological model and a behavioral model.

[0147] In Example 139, the subject matter of Example 138 optionally includes, wherein the behavioral model is configured to determine a level of the cause of concern, the level of the cause of concern being selected from the group consisting of concerns about a physiological condition, consequences of a treatment decision, and / or a potential future condition.

[0148] In Example 140, the subject matter of Example 139 includes, as appropriate, determining concern regarding a physiological condition by detecting a frequency at which a diabetes-related application is checked or by detecting a frequency at which SMBG values ​​are entered.

[0149] In Example 141, the subject matter of any one or more of Examples 139-140 optionally includes, where the behavioral model is configured to determine a level of an engagement factor, and the level of engagement factor is selected from the group consisting of reaction time, level of therapeutic activity, and / or type of support.

[0150] In Example 142, the subject matter of any one or more of Examples 139-141 optionally includes where the computing environment is a mobile device and the method further includes learning, by a second computer system, the physiological model, and where loading the model into the memory of the computing environment includes loading the learned physiological model into the mobile device.

[0151] In Example 143, the subject matter of Example 142 optionally includes learning the behavioral model by a second computer system, and loading the model into a memory of the computing environment includes loading the learned behavioral model into the mobile device.

[0152] In Example 144, the subject matter of any one or more of Examples 142-143 optionally includes the mobile device determining the calculated insight without requiring access to a second computer system.

[0153] Example 145 is a system including a glucose concentration sensor configured to detect a host glucose concentration, a communications circuit configured to receive a host glucose concentration from the glucose concentration sensor, a memory circuit including a stored model, and a processor configured to receive host glucose concentration data sensed by the glucose concentration sensor, determine a host status change associated with the host glucose concentration data, determine a guidance message based at least in part on the host status change, and deliver the guidance message via a user interface.

[0154] In Example 146, the subject matter of Example 145 optionally includes the processor being further configured to determine that the host state change is atypical, and determining the guidance message is based at least in part on the atypicality of the state change.

[0155] In Example 147, the subject matter of any one or more of Examples 145-146 optionally includes determining the host state change comprising determining from the model that a low probability state transition has occurred or is likely to occur, and determining the guidance message based at least in part on a determination that a low probability state transition has occurred or is likely to occur.

[0156] In Example 148, the subject matter of any one or more of Examples 145-147 optionally includes determining the host state change comprises identifying a likely transition to an undesirable host state, wherein a guidance message is determined and delivered at a time such that the host can intervene to avoid the transition to the undesirable host state.

[0157] In Example 149, the subject matter of any one or more of Examples 145-148 optionally includes where the system includes a mobile device, the mobile device including a memory circuit and a processor.

[0158] In Example 150, the subject matter of Example 149 optionally includes wherein the mobile device includes a communication circuit and the glucose concentration sensor includes a glucose concentration sensor communication circuit configured to communicate with the communication circuit.

[0159] In Example 151, the subject matter of any one or more of Examples 149-150 optionally includes the mobile device communication circuitry including a first wireless transceiver, the glucose concentration sensor communication circuitry including a second wireless transceiver, and the mobile device communication circuitry and the glucose concentration sensor communication circuitry communicating using a wireless communication protocol.

[0160] In Example 152, the subject matter of any one or more of Examples 145-151 optionally includes an insulin delivery system.

[0161] In Example 153, the subject matter of any one or more of Examples 145-152 optionally includes, where the state change is from a first disease state describing a first host disease stage to a second disease state indicative of a second host disease stage, and the processor is further configured to determine a second guidance message based at least in part on the second disease stage.

[0162] Example 154 is a method of delivering physiological glucose concentration management guidance comprising receiving data indicative of a glucose concentration, determining a patient state by applying the data to a model, determining whether the patient state is atypical, determining a guidance message based on the atypicality of the patient state, and delivering the guidance message via a user interface.

[0163] In Example 155, the subject matter of Example 154 optionally includes where determining whether the patient condition is atypical includes determining whether the patient condition is atypical for a given set of conditions.

[0164] In Example 156, the subject matter of any one or more of Examples 154-155 optionally includes determining whether the patient condition is atypical includes determining whether a low likelihood state transition has occurred.

[0165] In Example 157, the subject matter of any one or more of Examples 154-156 optionally includes determining whether a guidance message is predicted to occur.

[0166] In Example 158, the subject matter of any one or more of Examples 154-157 optionally includes determining the patient state including determining a physiological state and a behavioral state, and determining whether the physiological state is atypical for the determined behavioral state.

[0167] In Example 159, the subject matter of any one or more of Examples 154-158 optionally includes determining whether the patient condition is atypical includes identifying a blood glucose concentration level that deviates from a controlled blood glucose concentration range over a time or situation when the blood glucose concentration is normally within the controlled range.

[0168] In Example 160, the subject matter of any one or more of Examples 154-159 optionally includes determining whether the patient condition is atypical includes identifying blood glucose concentration trends that lead to hyper- or hypo-glycemic conditions over time or in certain circumstances when blood glucose concentrations are normally within a controlled range.

[0169] In Example 161, the subject matter of any one or more of Examples 154-160 optionally includes determining whether the patient condition is atypical includes predicting a shift to a low blood glucose concentration condition at one time or in some situations when blood glucose concentrations are normally well controlled.

[0170] Example 162 is a method of delivering physiological glucose concentration management guidance comprising receiving data indicative of a glucose concentration, determining a patient state by applying the data to a model, determining from the model that a low probability state transition has occurred or is likely to occur, and delivering a guidance message via a user interface based on a determination that a low probability state transition has occurred or is likely to occur.

[0171] In Example 163, the subject matter of Example 162 optionally includes the method determining that a low probability state transition is likely to occur, and the guidance message providing advance notification of the low probability state transition.

[0172] In Example 164, the subject matter of any one or more of Examples 162-163 optionally includes where the low probability physiological state transition includes a transition to a low glucose concentration level or a high glucose concentration level.

[0173] In Example 165, the subject matter of any one or more of Examples 162-164 optionally includes determining the guidance message includes determining that a low probability state transition is likely to occur at an inconvenient time.

[0174] In example 166, the subject matter of example 165 optionally includes a reference to a user calendar of scheduled events to determine that a low probability state transition is likely to occur at an inconvenient time.

[0175] In Example 167, the subject matter of any one or more of Examples 165-166 optionally includes a reference to a behavioral state model to determine that low probability state transitions are likely to occur at inconvenient times.

[0176] In Example 168, the subject matter of any one or more of Examples 162-167 optionally includes delivering the guidance message including determining a period of time during which a patient or caregiver is likely to take action to prevent a low probability state transition, and delivering the guidance message during the determined period of time.

[0177] In Example 169, the subject matter of Example 168 optionally includes determining a period during which the patient is likely to take action to prevent a low probability state transition by referencing a calendar of scheduled events.

[0178] In Example 170, the subject matter of any one or more of Examples 168-169 optionally includes determining a period during which a patient or caregiver is likely to take action to prevent a low probability state transition includes using the model.

[0179] In Example 171, the subject matter of any one or more of Examples 168-170 optionally includes where using the model includes using patterns of user activity or user location information to determine periods of time when the patient or caregiver is likely to be available.

[0180] Example 172 is a method of delivering physiological glucose concentration management guidance comprising receiving data indicative of a glucose concentration; receiving one or more behavioral, environmental, or contextual inputs; identifying a likelihood of a transition to an undesirable patient state by applying the data and the one or more behavioral, environmental, or contextual inputs to a model; and determining a guidance message based on the likelihood of the transition to the undesirable patient state, wherein the guidance message is determined and delivered at a time such that a patient can intervene to avoid the transition to the undesirable patient state.

[0181] In Example 173, the subject matter of Example 172 optionally includes where receiving the behavioral, environmental, or contextual input includes receiving accelerometer data.

[0182] In Example 174, the subject matter of any one or more of Examples 172-173 optionally includes where receiving the behavioral, environmental, or contextual input includes receiving information about a scheduled event from a calendar.

[0183] In Example 175, the subject matter of any one or more of Examples 172-174 optionally includes where receiving the behavioral, environmental, or contextual input includes receiving input from a user via a user interface.

[0184] In Example 176, the subject matter of any one or more of Examples 172-175 optionally includes where receiving the behavioral, environmental, or contextual input includes receiving information from a user regarding completion, initiation, or anticipation of an exercise.

[0185] In Example 177, the subject matter of any one or more of Examples 172-176 optionally includes where receiving the behavioral, environmental, or contextual input includes detecting that the user is driving.

[0186] In Example 178, the subject matter of any one or more of Examples 172-177 optionally includes where receiving the one or more behavioral, environmental, or contextual inputs includes receiving location information.

[0187] In Example 179, the subject matter of any one or more of Examples 172-178 optionally includes where receiving the one or more behavioral, environmental, or contextual inputs includes receiving an ambient temperature or an ambient pressure.

[0188] In Example 180, the subject matter of any one or more of Examples 172-179 optionally includes receiving a temperature, heart rate, or respiration rate.

[0189] In example 181, the subject matter of example 180 optionally includes learning a model based on one or more patterns in the received information.

[0190] In Example 182, the subject matter of Example 181 optionally includes where training the model includes learning a pattern of insulin sensitivity as a function of time.

[0191] In Example 183, the subject matter of Example 182 optionally includes where training the model includes learning a pattern of insulin sensitivity as a function of time elapsed after a period of physical exercise.

[0192] In Example 184, the subject matter of any one or more of Examples 172-183 optionally includes determining a user query and providing the user query to a user, where behavioral, environmental, or contextual input is received in response to the user query.

[0193] In Example 185, the subject matter of any one or more of Examples 172-184 optionally includes where receiving data indicative of the glucose concentration includes receiving data from a continuous glucose concentration monitoring system.

[0194] Example 186 is a system comprising a glucose concentration sensor configured to detect a host glucose concentration, a communications circuit configured to receive the host glucose concentration from the glucose concentration sensor, a memory circuit including a stored model, and a processor configured to access data associated with the host, use the data to determine a state of the host, determine a guidance message based at least in part on the determined state, select a time to provide the guidance message, and provide the guidance message via a user interface at the selected time.

[0195] In Example 187, the subject matter of Example 186 includes a time being calculated to allow for intervention, if necessary, before the host transitions into an undesirable physiological state.

[0196] In Example 188, the subject matter of any one or more of Examples 186-187 optionally includes determining the guidance message based at least in part on a personalized behavioral model of the host, and the time is calculated to be useful to the host in managing the diabetes treatment.

[0197] In Example 189, the subject matter of any one or more of Examples 186-188 optionally includes determining the state based at least in part on a model of patient physiology and a model of patient behavior.

[0198] Example 190 is a method of delivering physiological glucose concentration management guidance comprising measuring, determining, or receiving first real-time data associated with a patient; determining a state of the patient at least in part using a model and the first real-time data; determining a personalized guidance message, the guidance message based at least in part on the determined state; and providing the determined personalized guidance message via a user interface at a time calculated to enable intervention prior to a transition to an undesirable physiological state.

[0199] In Example 191, the subject matter of Example 190 optionally includes determining the guidance message further based on a timing for determining the guidance message or a time associated with the determined condition.

[0200] In Example 192, the subject matter of any one or more of Examples 190-191 optionally includes wherein the model includes a state indicating the convenience or availability of the patient to participate in the intervention.

[0201] In Example 193, the subject matter of any one or more of Examples 190-192 optionally includes the guidance message being based at least in part on a predicted transition to an undesirable physiological state.

[0202] In Example 194, the subject matter of Example 193 optionally includes the guidance message being based at least in part on a determination that the predicted transition from the current state to the predicted state is a low probability transition.

[0203] In Example 195, the subject matter of any one or more of Examples 190-194 optionally includes, where the model includes a physiological model of the patient, and determining the patient's state is based on applying at least the first real-time data to the physiological model of the patient.

[0204] In Example 196, the subject matter of Example 195 optionally includes wherein the model further includes a behavioral model.

[0205] In Example 197, the subject matter of Example 196 optionally includes where the behavioral model is based on machine learning characteristics of the patient, and the machine learning characteristics are based on behavioral or contextual patterns.

[0206] In Example 198, the subject matter of any one or more of Examples 196-197 optionally includes basing the behavioral model on a set of one or more steps determined to be likely to be performed by the patient.

[0207] In Example 199, the subject matter of any one or more of Examples 196-198 optionally includes basing the behavioral model on a set of one or more goals determined to be likely achievable by the patient.

[0208] In Example 200, the subject matter of any one or more of Examples 196-199 optionally includes that the behavioral model is a pattern.

[0209] In Example 201, the subject matter of any one or more of Examples 196-200 optionally includes where the physiological model of the patient is based on physiological patterns and the behavioral model is based on behavioral patterns.

[0210] In Example 202, the subject matter of Example 201 optionally includes the first real-time data indicating a deviation from an expected behavioral pattern.

[0211] In example 203, the subject matter of example 202 optionally includes, where the behavioral model indicates a tendency to overcorrect for meals associated with mealtimes, the first real-time data indicates that the mealtime is imminent, and the guidance message corresponds to a reduction in overcorrection at mealtimes.

[0212] In Example 204, the subject matter of Example 203 optionally includes where the behavioral patterns include long-term behavioral patterns based on long-term patterns of behavior and short-term behavioral patterns related to current behavior.

[0213] In Example 205, the subject matter of Example 204 optionally includes the behavioral model being based on long-term behavioral patterns and further based on short-term behavioral patterns.

[0214] In Example 206, the subject matter of Example 205 optionally includes wherein the short-term behavioral patterns are based on one or more selected from the group consisting of engagement with a mobile device, accelerometer data, frequency of checking glucose levels, calendar data, and combinations thereof.

[0215] In Example 207, the subject matter of any one or more of Examples 190-206 optionally includes determining the state further based on a measurement model.

[0216] In Example 208, the subject matter of Example 207 optionally includes where the measurement model is based on a continuous glucose concentration monitoring system associated with the patient.

[0217] In Example 209, the subject matter of Example 208 optionally includes measuring glucose concentration data after determining the guidance message and using the measured subsequent data to improve one or more models.

[0218] In Example 210, the subject matter of Example 209 optionally includes feeding back measured glucose concentration data subsequent to the determination into a measurement model or a behavioral model or a patient physiological model, or a combination thereof.

[0219] In Example 211, the subject matter of any one or more of Examples 190-210 optionally includes where the model includes a pattern selected from the group consisting of a physiological pattern, a contextual pattern, a behavioral pattern, or a combination thereof.

[0220] In Example 212, the subject matter of Example 211 optionally includes where the physiological pattern is based on a physiological model.

[0221] In Example 213, the subject matter of any one or more of Examples 190-212 optionally includes where the model is based on a combination of patterns selected from the group consisting of physiological patterns, contextual patterns, or behavioral patterns.

[0222] In Example 214, the subject matter of any one or more of Examples 190-213 optionally includes determining a guidance message further comprising determining a plurality of guidance messages based on the state and the first real-time data, and selecting one of the determined plurality of guidance messages further based on the state and the first real-time data.

[0223] In Example 215, the subject matter of Example 214 optionally includes wherein the selection is further based on a ranking scheme, a prioritization scheme, or based on a comparison of the plurality of guidance messages to one or more associated thresholds.

[0224] In Example 216, the subject matter of any one or more of Examples 190-215 optionally includes determining a predicted diabetic response for the patient based on the condition and the first real-time data, and a guidance message is further personalized to the patient based on the predicted diabetic response, and the patient is provided with an actionable message calculated to move the predicted diabetic response toward a desired diabetic response.

[0225] In Example 217, the subject matter of Example 216 optionally includes, wherein a desired diabetic response is associated with the condition and the first real-time data, and the desired diabetic response is selected from the group consisting of an improved diabetic response, a potential improved diabetic response, an ideal response, or an optimized response.

[0226] In Example 218, the subject matter of Example 217 optionally includes that the guidance message is based on a functional relationship between an expected diabetic response and a desired diabetic response.

[0227] In Example 219, the subject matter of Example 218 optionally includes the functional relationship being the difference between a glucose concentration level associated with an expected diabetic response and a glucose concentration level associated with a desired diabetic response.

[0228] In Example 220, the subject matter of Example 219 optionally includes that the glucose concentration level associated with the desired diabetic response is a target glucose concentration level or a target glucose concentration range.

[0229] In Example 221, the subject matter of Example 220 optionally includes that the functional relationship is based on whether the predicted diabetic response matches a predetermined condition associated with the desired diabetic response.

[0230] In Example 222, the subject matter of Example 221 optionally includes the predetermined condition being a target glucose concentration level, a target glucose concentration range, a glucose concentration signal signature, or a rate of change associated with a glucose concentration level.

[0231] In Example 223, the subject matter of any one or more of Examples 217-222 optionally includes that the guidance message further includes one or more reasons related to the functional relationship so that the patient can be informed as to why the guidance message is being provided.

[0232] In Example 224, the subject matter of any one or more of Examples 190-223 optionally includes that the guidance message includes an actionable prompt.

[0233] In Example 225, the subject matter of Example 224 optionally includes the guidance message including actionable prompts calculated to move the patient's glucose concentration level toward a target level or range.

[0234] In Example 226, the subject matter of any one or more of Examples 190-225 optionally includes the guidance message including an affirmation of a current action associated with the patient.

[0235] In Example 227, the subject matter of any one or more of Examples 190-226 optionally includes the first real-time data being measured, received, or determined by a smartphone.

[0236] In Example 228, the subject matter of any one or more of Examples 190-227 optionally includes the first real-time data being measured, received, or determined by a wearable device.

[0237] In Example 229, the subject matter of any one or more of Examples 190-228 optionally includes the first real-time data being measured, received, or determined by a wearable device in combination with a smartphone.

[0238] In Example 230, the subject matter of any one or more of Examples 190-229 optionally includes the first real-time data being measured, received, or determined by an external device.

[0239] In Example 231, the subject matter of Example 230 optionally includes where the external device is an accelerometer.

[0240] In Example 232, the subject matter of any one or more of Examples 190-231 optionally includes where the first real-time data is a time of day, a characteristic or signature signal measured by an accelerometer, or a location determined by a GPS circuit.

[0241] In Example 233, the subject matter of any one or more of Examples 190-232 optionally includes where the first real-time data is a change in state.

[0242] In Example 234, the subject matter of Example 233 optionally includes the change in state being detected by a clock, an accelerometer, or a GPS circuit.

[0243] In Example 235, the subject matter of any one or more of Examples 190-234 optionally includes where the first real-time data is a user request for a decision support prompt.

[0244] In Example 236, the subject matter of any one or more of Examples 190-235 optionally includes receiving the first real-time data from a continuous glucose concentration monitoring system.

[0245] In Example 237, the subject matter of any one or more of Examples 190-236 optionally includes measuring, determining, or receiving second real-time data, which is used in determining a condition of the patient.

[0246] In Example 238, the subject matter of any one or more of Examples 190-237 includes providing a determined personalized guidance message, as needed, when calculated to be useful in managing the patient's glucose concentration level.

[0247] In Example 239, the subject matter of any one or more of Examples 190-238 optionally includes that the condition is a disease state describing a stage of the patient's disease.

[0248] In Example 240, the subject matter of Example 239 optionally includes measuring, determining, or receiving second real-time data indicative of a second glucose concentration level, determining a second disease state at least partially describing a stage of the second patient's disease by applying the second data to a model, and determining a second guidance message based at least in part on the second disease state.

[0249] In Example 241, the subject matter of any one or more of Examples 190-240 optionally includes, where the state is an engagement state, further comprising determining a messaging frequency based at least in part on the engagement state, and determining a time for providing the personalized guidance message based at least in part on the messaging frequency.

[0250] In Example 242, the subject matter of any one or more of Examples 190-241 optionally includes receiving training data during a training period and determining a patient condition based at least in part on the training data.

[0251] Example 243 is a method of determining and delivering a calculated guidance message that is personalized and useful to a patient in managing the treatment of diabetes, comprising: learning a personalized behavioral model of a patient; receiving real-time data; determining a personalized guidance message to be provided to the patient, the determination being based at least in part on a time of determination of the personalized guidance message and the personalized behavioral model of the patient; and determining a delivery time for providing the personalized guidance message using the learned personalized behavioral model, wherein the delivery time is calculated to be useful to the patient in managing the treatment of the patient's diabetes.

[0252] In Example 244, the subject matter of Example 243 optionally includes where learning the personalized behavioral model of the patient includes machine learning a first characteristic of the patient.

[0253] In Example 245, the subject matter of Example 244 optionally includes where the first characteristic is a pattern selected from the group consisting of a physiological pattern, a contextual pattern, or a behavioral pattern, or a combination of these patterns.

[0254] In Example 246, the subject matter of Example 245 includes optionally delivering a personalized guidance message at a delivery time.

[0255] Example 247 is a method of determining and providing a personalized and useful computed guidance message to a patient in diabetes care management, comprising measuring, determining, or receiving first real-time data related to a patient; using models to determine a state of the patient based on a physiological model, a behavioral model, and a measurement model of the patient, where the state is determined by the patient's physiological model and behavioral model and the real-time data; determining a guidance message, where the guidance message is personalized to the patient based on at least the determined state, whereby the determined state and use of the multiple models enable personalization of the guidance message; and providing the determined personalized guidance message via a user interface such that the provision is calculated to be useful to the patient in the diabetes care management.

[0256] In Example 248, the subject matter of Example 247 optionally includes receiving the first real-time data being a glucose concentration value.

[0257] In Example 249, the subject matter of Example 248 optionally includes receiving the first real-time data being a time of day.

[0258] In Example 250, the subject matter of any one or more of Examples 248-249 optionally includes that the patient's physiological model is a state model including one or more of a glucose concentration state, an insulin on-board state, and an insulin sensitivity state, an energy absorption state, or an energy consumption state.

[0259] In Example 251, the subject matter of any one or more of Examples 248-250 optionally includes training a model from a set of input data.

[0260] In Example 252, the subject matter of Example 251 optionally includes where the set of input data includes one or more of clock time, time of day, glucose concentration level, insulin on board, patient activity, patient health, day of the week, day of the month, day of the year, location, food consumed, or beverage consumed.

[0261] In Example 253, the subject matter of any one or more of Examples 251-252 optionally includes determining a deviation from an expected state after delivering a personalized guidance message and adapting the model based on additional input information.

[0262] In Example 254, the subject matter of Example 253 optionally includes wherein the set of input data includes information received via a user interface.

[0263] In Example 255, the subject matter of any one or more of Examples 247-254 includes, if desired, providing the determined personalized guidance message includes providing the personalized guidance message in a user interface.

[0264] This summary is intended to provide an overview of the subject matter of this patent application. It is not intended to provide an exclusive or exhaustive description of the disclosure. The detailed description is included to provide further information regarding this patent application. Other aspects of the present disclosure will be apparent to those skilled in the art upon reading and understanding the following detailed description and viewing the drawings that form a part hereof, each of which should not be construed in a limiting sense.

[0265] In the drawings, which are not necessarily drawn to scale, like reference numbers may describe like components in different views. Like reference numbers with different letter suffixes may represent different instances of the like components. The drawings illustrate generally, by way of example, but not by way of limitation, various embodiments discussed in the present document. [Brief description of the drawings]

[0266] [Figure 1] 1 illustrates an exemplary system for delivering guidance to a patient. [Figure 2A] FIG. 2 is a diagram of the model shown in FIG. 1. [Figure 2B] FIG. 10 provides a more detailed view of example model inputs and example states that can be determined by applying the inputs to the model. [Figure 3A] FIG. 1 is an exemplary timeline diagram associated with a patient. [Figure 3B] FIG. 1 is an exemplary schedule of a caregiver and a child patient. [Figure 3C] FIG. 1 is a diagram of the patient's wakefulness / sleep state. [Figure 3D] FIG. 13 is a diagram of determining a patient's availability (or convenience) to participate in an intervention based on other conditions. [Figure 4] FIG. 1 is a diagram of various categories of inputs coupled to various categories of outputs via a decision step or module. [Figure 5A] 4 is a flowchart illustrating an example method for determining user guidance. [Figure 5B] 4 is a flowchart illustrating an example method for determining user guidance. [Figure 6] 4 is a flowchart illustrating an example method for determining user guidance. [Figure 7] 4 is a flowchart illustrating an example method for determining user guidance. [Figure 8] 4 is a flowchart illustrating an example method for determining user guidance. [Figure 9] 4 is a flowchart illustrating an example method for determining user guidance. [Figure 10] 4 is a flowchart illustrating an example method for determining user guidance. [Figure 11] 4 is a flowchart illustrating an example method for determining user guidance. [Figure 12]4 is a flow chart illustrating an example method for determining user guidance. [Figure 13] 4 is a flow chart illustrating an example method for determining user guidance. [Figure 14] 1 is a flow chart illustrating a method for converting a non-sharp input into a quantifiable measure. [Figure 15] 1 illustrates the use of one type of correlated parameter, e.g., food sensitivity, within a system model in determining meal bolus decision support. [Figure 16a] 1 illustrates the various inputs that can be used in a decision support application / function. [Figure 16b] 1 illustrates the various inputs that can be used in a decision support application / function. [Figure 16c] 1 illustrates the various inputs that can be used in a decision support application / function. [Figure 16d] 1 illustrates the various inputs that can be used in a decision support application / function. [Figure 16e] 1 illustrates the various inputs that can be used in a decision support application / function. [Fig. 16f] 1 illustrates the various inputs that can be used in a decision support application / function. [Figure 17] It shows various physical sources of input data. [Figure 18A] This demonstrates an unconventional way of acquiring dietary data. [Figure 18B] This demonstrates an unconventional way of acquiring dietary data. [Figure 19] 1 is a flow chart for obtaining signal signature information that can be used as input for decision support, for example, for state definition and determination. [Figure 20] 1 is a chart showing gastric emptying duration that can serve as an input to decision support, for example, for defining and determining conditions. [Figure 21]A chart showing modes, e.g., modes of operation of a CGM, which can also be used as input to decision support, e.g., for defining and determining states. [Figure 22A] A user input to adjust the threshold level is shown. [Figure 22B] A user input to adjust the threshold level is shown. [Diagram 23] FIG. 1 is a diagram of an example system in which the methods described herein can be implemented. [Figure 24] 1 is a block diagram of an example machine capable of executing any one or more of the techniques (eg, methodologies) described herein. [Figure 25A] FIG. 13 is an exemplary user interface that allows a user to select carbohydrate and fat content on a graph. [Figure 25B] FIG. 13 is an exemplary user interface that allows a user to select carbohydrate and fat content on a graph. [Figure 26] 1 illustrates an exemplary user interface in which alerts can be configured. [Figure 27A] FIG. 13 is a diagram of a user interface showing predicted data for a selected carbohydrate intake. [Figure 27B] FIG. 13 is a diagram of a user interface showing predicted data for a selected carbohydrate intake. [Figure 28] 1 is a diagram of an example guidance delivered on a user interface of a mobile device. [Figure 29] 1 is a diagram of an example guidance delivered on a user interface of a mobile device. [Diagram 30] 1 is a diagram of an example guidance delivered on a user interface of a mobile device. [Figure 31A] FIG. 13 is an exemplary glucose post-prandial trend diagram without timely decision support guidance. [Figure 31B] FIG. 13 is an exemplary glucose post-prandial trend with timely decision support guidance. [Figure 32A] FIG. 13 illustrates an exemplary postprandial insulin trend distribution pattern without decision support guidance. [Figure 32B] FIG. 13 illustrates an exemplary postprandial insulin trend distribution pattern with decision support guidance. [Diagram 33] FIG. 1 is an exemplary glucose trend diagram including interventions to address hypoglycemic events. [Diagram 34] 2 illustrates an exemplary user interface of the device. [Diagram 35] 2 illustrates an exemplary user interface of the device. [Diagram 36] 2 illustrates an exemplary user interface of the device. [Figure 37] 2 illustrates an exemplary user interface of the device. [Figure 38] FIG. 2 is another diagram of the model shown in FIG. [Figure 39] 1 is a flow chart illustrating an example of a process flow that may be performed by a decision support system to respond to changes in the disease stage of a host. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0267] Managing diabetes can pose complex challenges to patients, clinicians, and caregivers as a confluence of many factors can affect a patient's blood glucose levels and blood glucose trends. The inventors have recognized that, among other things, intensive insulin users can benefit from real-time guidance that is determined or delivered at a time calculated to be useful to the patient or caregiver. Determining the timing of such guidance can be supported by a technology system that processes data and patterns to determine timing. For example, by using technology tools such as sensors, data models, and patient interface devices, the system can determine times that are calculated to be within a time window when the patient or caregiver is likely available to receive and act on the guidance or would otherwise find the guidance useful. In some examples, the system can learn user preferences or behavioral characteristics or patterns and use the preferences, characteristics, or patterns to determine the timing of guidance. By delivering guidance at a time calculated to be useful to the user, management of physiological glucose levels can be improved.

[0268] Overview The guidance and the system that determines the time to deliver the guidance calculated to be useful to the user (e.g., patient, caregiver, or clinician) can help the user sleep better, for example, to get uninterrupted sleep so that glucose levels are managed, or to avoid highs and lows during sleep with peace of mind, or to know to improve sleep by acting on the guidance before sleep, or to know when there is a potential problem that needs to be addressed. The system can alternatively or additionally help the user eat better, for example, with guidance from a decision support system, having the confidence that the patient will stay in range no matter what they eat, or will stay in range after a meal, regardless of what they did leading up to the meal, or the peace of mind of knowing that their treatment is safe and effective. The system may alternatively or additionally help the user live better (e.g., improve quality of life), for example by knowing when the user needs to pay attention to diabetic issues (e.g., glucose levels), or when they need to adapt to unexpected events during the day while keeping glucose levels under control, or by recognizing potential or likely excursions in advance and knowing when they can react or respond to the excursion without overcompensating or overeating (e.g., overeating carbohydrates).

[0269] In some examples, the delivered guidance can help patients, caregivers, or healthcare providers improve lifestyle or clinical / patient outcomes by addressing various challenges such as overnight glycemic control (e.g., reducing the incidence of hypoglycemic events or hyperglycemic excursions), prandial and post-prandial glycemic control (e.g., using historical information and trends to increase glycemic control), hyperglycemic correction (e.g., increasing time in target zone while avoiding hypoglycemic events from overcorrection), hypoglycemic treatment (e.g., addressing hypoglycemia while avoiding "rebound" hyperglycemia), exercise, and other health factors. The system can provide therapy optimization tools that learn the patient's physiology and behavior and calculate guidance to help the patient identify optimal or desired therapy parameters such as basal insulin requirements, insulin-to-carbohydrate ratios, correction factors, or changes in insulin sensitivity with exercise. Decision support tools can help patients respond to issues in real time, for example, by predicting hypoglycemic or hyperglycemic events or trends, addressing occurring or potential hypoglycemic or hyperglycemic events or trends, and providing therapy recommendations to monitor how blood glucose, physiology, or behavior respond in real time. This kind of calculated guidance and support can reduce the cognitive burden on patients, caregivers, or medical professionals.

[0270] Physiological sensors such as continuous glucose monitoring can provide useful data that patients, caregivers, or medical professionals can use to manage glucose levels, but the data may require significant processing to develop an effective strategy for glucose management. The sheer volume of data, and the recognition of correlations between data types, trends, events, and outcomes, can far exceed human processing capabilities. This is especially impactful when decisions regarding treatment or response to physiological conditions are being made in real time. The integration of real-time or recent data with historical data and patterns can provide useful guidance in making real-time decisions regarding treatment. Technology tools can process this information to provide decision support guidance calculated to be helpful for a particular patient with a particular condition or in a particular situation at a particular time. Technology tools can also reduce the cognitive burden on human decision makers by making repeated calculations throughout the day to determine when to delay or deliver guidance.

[0271] The decision support system can be particularly useful in developing pre-sleep guidance to increase the likelihood that glucose levels will be controlled during sleep. For example, the system can use algorithms or models to determine whether a hyperglycemic or hypoglycemic event is possible or likely and develop guidance, which can include, for example, pre-sleep behavioral items such as insulin delivery, eating food (e.g., fast carbohydrates, slow carbohydrates, or carbohydrates combined with protein), or setting an alarm to check status or confirm guidance at a specific time. The system can also use algorithms or models to provide context-dependent alerts. For example, the system can recognize from human input or sensor input or behavioral patterns that a user is asleep or about to sleep and take sleep activity into account when calculating the time to deliver an alert or warning. In some examples, the system can delay delivery of the alert or guidance (e.g., until a risk condition is met or an intervention time window opens) to avoid unnecessarily waking the patient or caregiver. In some examples, the system can calculate the time to deliver guidance (and alerts that may wake the patient or time provider) to increase the likelihood that a more disruptive intervention is unavailable. For example, the system may determine that a query is desirable (e.g., checking for low pressure, or checking fever or blood glucose or other physiological sensors) or that a basal or bolus adjustment is necessary, e.g., to avoid a hyperglycemic event with timely delivery of insulin via injection or pump, or to avoid a hypoglycemic event by reducing delivery of insulin via the pump and avoiding waking the patient at a later time to deliver carbohydrates via food or drink.

[0272] A decision support system configured to calculate guidance and timing of guidance can also aid in transitioning to a new therapy or a new environment, or disease progression over time (e.g., changes in pancreatic function or fading of the "honeymoon" period of partial pancreatic function, changes in treatment routines for patients with type II diabetes, etc.), for example, by providing guidance regarding potential outcomes, notification when a decision may be needed, or guidance regarding the potential impact of a therapeutic intervention or behavioral decision (e.g., exercise, rest, or eating).

[0273] The decision support system may collect patterns and other information related to eating behavior (e.g., number of meals per day, distribution of meal sizes across meals and snacks, size of treatments for hypoglycemic excursions, or number of repeat treatments for hypoglycemic events), insulin dosing information (e.g., bolus and basal dosing patterns, pump settings or injection patterns, number of boluses per day, amount of trend adjustments, pre-meal bolus patterns, behavioral boluses before and after correction, number of correction boluses per day), behavioral patterns (presence and accuracy of carbohydrate counts, incidence of activity in response to hyperglycemia or non-response, or need for correction boluses, status, threshold or need for correction (e.g., glucose levels, combinations of trends and levels, foods or other factors), recognition of insulin on-board, timing of insulin, pre-meal "pre-bolus" patterns and their duration, errors in insulin delivery or therapeutic interventions, exercise timing, exercise duration, and exercise intensity, physiological response to activity. A variety of information sources may be used to determine guidance, such as: physiological response; physiological factors (pattern of response to insulin, carbohydrates and other foods, tendency to "rebound" to high glycemic states after low glucose, effect of illness or medication on insulin sensitivity or glucose levels); responsiveness to guidance (time to acknowledge an alert or alarm, behavior in response to an alert or alarm (e.g., eating, sleeping or exercising); and glycemic outcome (e.g., percentage of time below one or more glucose concentration thresholds (e.g., less than 70 mg / dL, less than 50 mg / dL), percentage of time above one or more glucose concentration thresholds (e.g., greater than 180 mg / DL, greater than 250 mg / DL), and number of events below or above one or more thresholds), disease stage and / or type of treatment (e.g., Type I honeymoon period, Type II prediabetes stage, Type II oral medication stage, Type II basal insulin stage). Additional exemplary inputs are described below.

[0274] The decision support system may communicate or interact with other systems, such as a glucose delivery device (eg, a pump or smart pen) and other analytical systems.

[0275] Exemplary embodiments disclosed herein relate to the use of glucose sensors to measure the concentration of glucose or another analyte or the concentration of a substance indicative of its presence. In some embodiments, the glucose sensor is a continuous device, e.g., a subcutaneous, transdermal, transcutaneous, non-invasive intraocular and / or intravascular (e.g., intravenous) device. In some embodiments, the device can analyze multiple intermittent blood samples. The glucose sensor can use any method of glucose measurement, including enzymatic, chemical, physical, electrochemical, optical, photochemical, fluorescence-based, spectrophotometric, spectroscopy (e.g., optical absorption spectroscopy, Raman spectroscopy, etc.), polarimetry, calorimetry, iontophoresis, radiometric, etc.

[0276] The glucose sensor can provide a data stream indicative of the concentration of the analyte in the host using any known detection method, including invasive, minimally invasive, and non-invasive sensing techniques. The data stream is typically a raw data signal that is used to provide a useful value of the analyte to a user, such as a patient or a healthcare professional (HCP, e.g., physician, doctor, nurse, caregiver) who may be using the sensor.

[0277] While many of the descriptions and examples are directed to glucose sensors capable of measuring the concentration of glucose in a host, the systems and methods of the embodiments may be applied to any measurable analyte. Some exemplary embodiments described below utilize an implantable glucose sensor. However, it should be understood that the devices and methods described herein may be applied to any device capable of detecting the concentration of an analyte and providing an output signal representative of the concentration of the analyte.

[0278] In some embodiments, the analyte sensor is an implantable glucose sensor, such as those described with reference to U.S. Patent Application Publication No. 6,001,067 and U.S. Patent Application Publication No. 2011-0027127. In some embodiments, the analyte sensor is a transcutaneous glucose sensor, such as those described with reference to U.S. Patent Application Publication No. 2006-0020187. In still other embodiments, the analyte sensor is a dual electrode analyte sensor, such as those described with reference to U.S. Patent Application Publication No. 2009-0137887. In still other embodiments, the sensor is configured to be implanted within a host vessel or outside the body, as described in U.S. Patent Application Publication No. 2007-0027385. These patents and publications are incorporated herein by reference in their entirety.

[0279] Systems and methods for decision support using lifestyle factors are described in U.S. patent application Ser. No. 15 / 417,008, entitled "Systems and Methods for Decision Support Using Lifestyle Factors," which claims the benefit of U.S. Provisional Patent Application Ser. No. 62 / 289,825, filed Feb. 1, 2016, both of which are incorporated by reference in their entireties herein.

[0280] Exemplary System Overview Delivering guidance at a time, or in a context that encourages timely action of such guidance, can promote effective diabetes management and reduce the burden of managing glycemic levels. This may be due, at least in part, to the relevance of the guidance, or the availability or interest of the patient or caregiver to receive and act on it. In various examples, real-time data, models or other pattern information, patient input, and other sources of sensor and user-specific information can be used to determine the time to determine and deliver the guidance.

[0281] An exemplary decision support system can determine a guidance time calculated to be useful to a user, such as a patient or caregiver, taking into account data including various data sources, such as physiological sensors, historical information, and other information about the patient or caregiver. The time can be calculated, for example, based on timing factors or patterns, or based on the occurrence of a situation that can be recognized from a previously observed pattern. The situation can be, for example, physiological, behavioral / contextual, or both. In some examples, the guidance decision or timing can be calculated to be useful to a user, taking into account the recurrence of a situation similar to the known pattern, with reference to known patterns and associated glucose control trends.

[0282] In some examples, the exemplary real-time decision support systems and methods can provide guidance to a patient in real time, i.e., at times calculated to be useful to the patient and when the patient can intervene in glucose management to avoid undesirable glucose levels or trends. The timing of delivery of such real-time guidance can be determined using, for example, information from a calendar, physiological sensors, or contextual sensors such as GPS or wireless connectivity, such that guidance can be delivered at times calculated to be useful or possible for the user.

[0283] An exemplary real-time decision support system can include a source of real-time information about the patient, such as a continuous glucose monitor ("CGM," described further below). The continuous glucose monitor can provide information about the patient's glucose level ("CGM data") at regular intervals, such as once per minute or once per five minutes, or on demand. The information can be pushed by the CGM or can be pulled by an external device, such as a smartphone or other handheld device that is held or swept over the sensor.

[0284] An exemplary real-time decision support system may also include a processing system that receives information such as CGM data and insulin delivery, calorie consumption, activity, health or disease state, condition, environment, patient behavior, or other sensed or user-entered information related to health. The CGM data and other data may be combined and processed to generate guidance for delivery to the patient. Guidance may be generated based on timing factors such as timing of insulin delivery, calories consumed, type of calories consumed, information regarding absorption or digestion time of type or amount or combination of food or beverage, exercise timing and post-exercise oxygen or calorie consumption, and the patient's availability or convenience to participate in an intervention such as insulin delivery or changes in delivery or changes in exercise or diet.

[0285] Model In some examples, a model can be constructed to process the CGM data and other information. The model can be, for example, a state model. One or more states can be determined by applying one or more inputs to the model. The states can be predefined or learned from analysis of the data, or both. In some examples, the decision support system can be driven by a combination of outputs of at least two models: (1) a physiological state model, and (2) a behavioral or contextual model. In some examples, the decision support can be driven by at least three models, for example, 1) a physiological model and separate behavioral and contextual models, or 2) a physiological, behavioral / contextual, and measurement model (described further below). Other variations with multiple models and sub-models are also possible.

[0286] Physiological Models In some examples, the patient's physiological state can be determined by applying one or more inputs to a physiological model. The one or more physiological states can be used to determine the patient's guidance, the timing of the guidance, or both. For example, one or more inputs (see, e.g., FIG. 2B, and FIG. 14-FIG. 16 and their descriptions, described in detail below) can be applied to a model or models to determine the patient's physiological state. The physiological state can include, for example, a glucose concentration level (e.g., glucose concentration in blood glucose or other bodily fluids such as interstitial fluid), a drop or rise in the glucose concentration level (i.e., glucose trend), or a rate of drop or rise in the glucose concentration level (e.g., slope or high level derivative). The determined physiological state can also be or include an activity level (e.g., movement detected from an accelerometer, heart rate sensor, or respiration sensor), metabolic drive (e.g., glucose consumption rate), and insulin resistance (e.g., in response to stress hormone secretion, illness, or high blood sugar levels), insulin sensitivity (described in detail below), insulin onboard, insulin time to act, insulin action time, carbohydrate to insulin ratio. Other physiological conditions are possible. Behavioral or Contextual Models

[0287] The behavioral model or the contextual model may be related and, in some examples, combined into a single model. The behavioral model may relate to the user's decisions, while the contextual model may relate to the user's environment (such as location). In some examples, the behavioral model may include contextual aspects (e.g., a user's location is usually the result of a user's choice, so location can be considered a subset of behavior). In other examples, two separate models may be provided to account for behavioral and contextual factors.

[0288] In some examples, a behavioral or contextual state can be determined by applying an input to a behavioral model. The behavioral or contextual state can be used to determine guidance, timing of guidance, or both. The behavioral or contextual state (e.g., unavailable or concerned about hypoglycemia) can be determined by applying an input to a behavioral or contextual model. The input to the behavioral model can include a determined physiological state. Other inputs to the behavioral or contextual model can include user-specified inputs, real-time parameters (e.g., clock values), measured or sensed data, calendar information, stored pattern information (e.g., time-correlated inputs or states), or outputs from other models. User-provided inputs to the behavioral or contextual models can include indications of a host's course of treatment and / or disease stage in some examples. Additional inputs are described below and illustrated in FIGS. 2B and 14-16. In some examples, the behavioral model may include aspects of the context. In other examples, aspects of the context may form other models.

[0289] Measurement Model The measurement model may at least partially evaluate or confirm the reliability of one or more measurement inputs, such as CGM data or information from a CGM model, glucometer data received via a user interface (e.g., from a finger prick sensor) or from a smart meter (e.g., configured with communication capabilities to transmit or send values), measured blood glucose dosing information (e.g., dosage information received from an insulin "smart" pen configured to track and communicate dosing information), insulin dosage information received from a pump, or insulin data entered by a user via a user interface (e.g., amount of insulin injected via a needle or pump). Measurement conditions obtained from the measurement mode may be provided as inputs to other models.

[0290] Guidance and timing decisions The decision support engine can determine user (patient or caregiver, such as a parent or clinician) guidance and timing of guidance decisions or delivery based at least in part on the state of the one or more models, and provide guidance to the user via a user interface, such as a mobile device. The decision support engine can provide "real-time" guidance based on recent information (e.g., recent CGM data) that the user can use to influence blood glucose trends (e.g., avoid high or low glucose concentration trends or levels).

[0291] Using machine learning to determine state and guidance In some examples, machine learning methods can be used a priori to identify possible states. In other words, the domain of possible states can be estimated from a set of data. For example, a "post-activity state" can be identified as a state of increased insulin sensitivity up to a certain period (e.g., 8 hours) after exercise. Then, in real time, the system can use real-time exercise data (e.g., activity data, heart rate, or respiration) to confirm that the user is entering such a state and provide guidance for the user to take less insulin than usual due to the increased insulin sensitivity. Machine learning can also be used to identify a set of input variables that lead to a consistent insulin sensitivity model that can be applied when in that state. In other examples, machine learning techniques can be used to determine that a patient always ignores alerts during certain times of the day (e.g., from 3:00 p.m. to 5:00 p.m.), and therefore the system can turn off non-critical alerts during those times and trigger a risk report as guidance just before the period (e.g., just before 3:00 p.m.) or deliver a pre-alert to the user to prepare the user for periods when alerts tend to be ignored.

[0292] Exemplary System 1 illustrates an example system 100 for determining guidance and timing of guidance using sensor inputs and models. The system can process physiological inputs, for example inputs related to management of glucose concentration levels, to determine a calculated time for determining or delivering guidance that is useful to a patient or other user.

[0293] The system 100 can include a decision support engine 104 that processes information about the patient (e.g., received real-time sensor data) and combines the sensor information with patterns, e.g., temporal, physiological, or behavioral patterns, or a combination thereof, to generate output that can be provided as guidance or processed to create guidance. The decision support engine 104 can generate various outputs that can be provided to the patient 102 as guidance via the user interface 108, used to determine guidance, or used to determine the timing of guidance. The guidance can include, for example, diabetes treatment guidance.

[0294] Example Input Example implementation of a decision support engine One or more sensors 106 may be associated with a patient to provide information about the patient to the decision support engine 104. The sensor 106 may include, for example, an analyte sensor, such as a glucose sensor as described above. The sensor 106 may be a bodily fluid sensor, such as a transdermal sensor, a contact lens sensor or a skin sensor, or an implantable sensor configured to measure the quality of interstitial fluid or blood. For example, the sensor 106 may be a subcutaneous, transdermal, transcutaneous, non-invasive intraocular and / or intravascular glucose sensor, as described above. In some examples, the sensor may be a glucose sensor, such as ... TM , Abbot TM (For example, Libre TM Sensor), or Medtronic TM(For example, Enlite TMThe sensor 106 may be a wearable or implantable sensor connected to the patient 102, such as a continuous glucose monitoring sensor available from a wearable or implantable sensor (e.g., ...). Other types of sensors may also be associated with the patient, such as a heart rate sensor, a respiration sensor, other types of analyte sensors, motion sensors (e.g., an accelerometer), posture sensors (e.g., a three-axis accelerometer), or acoustic sensors (e.g., for capturing ambient or internal sounds). The sensor 106 may be, for example, wearable on a watch, eyeglasses, contact lenses, a patch wristband, ankle band, or other wearable item, or may be incorporated into a handheld device (e.g., a smartphone), or may be incorporated into other sensors, such as a continuous glucose monitor sensor. In some examples, the sensor 106 may include a multi-sensor patch that may detect, for example, glucose levels, heart rate, respiration (e.g., using impedance), activity (e.g., using an accelerometer), posture (e.g., using an accelerometer), galvanic skin response, tissue fluid levels (e.g., using impedance or pressure). In some examples, an array or network of sensors may be associated with the patient. One or more sensors 106 can communicate with a local device 108, which can be, for example, a mobile device such as a smartphone, via wired or wireless (e.g., Bluetooth, Zigbee, Z-Wave, NFC) communication. The system can learn the joint distribution of signals from various sensors (e.g., from sensors on a multi-sensor patch or from networked sensors or groups of sensors).The system can use the historical data or knowledge of the joint distribution of the signals (e.g., how the sensor signals relate to each other or move together) to A) determine or impute missing sensor data points (e.g., using a model or algorithm or calculation, as described further below), or B) predict future blood glucose concentration levels, or C) detect sensor failure or problems with CGM sensor performance based on the joint signals recorded in real time and historical information, or D) estimate the number of carbohydrates, fats, proteins or other substances ingested, or any combination thereof, based on the sensor information.

[0295] The decision support engine 104 can receive sensed information 120. The sensed information 120 can include, for example, physiological data such as CGM data from a CGM sensor, activity data (e.g., from an accelerometer), heart rate, or any of the other physiological functions described herein. The sensed information can be sensed by one or more sensors 106, a local device 108, or other sensor devices. The sensed information can also be non-physiological data, such as location information (e.g., GPS) or connectivity information (e.g., Wi-Fi).

[0296] Inputs to the decision support engine 104 can also include insulin data 122. The insulin data can be obtained, for example, from an insulin delivery device such as a pump, or received from a smart pen configured to track insulin delivery and communicate insulin delivery information to the system, for example, via wireless communication to a smart device that can relay the information to the decision support engine. The insulin data can also be received from a user, for example, a patient or caregiver, via a user interface on a smartphone or other computing device.

[0297] The decision support engine 104 can also receive other information 124, such as meal, sleep, or calendar information, which can include sensed information (e.g., sleep detected using an accelerometer or physiological sensors), learned information (e.g., temporal patterns), or information provided by the user via a user interface (e.g., meal and schedule information). Additional inputs that can be received by the decision support engine 104 are described with reference to FIGS. 2A, 2B, and 14-16. Additional details of example system components are described with reference to FIGS. 23-24. Meal and carbohydrate information can be received via a user interface of a device (e.g., a smart mobile device) paired with the CGM, or can be received from a different application or other device (e.g., carbohydrate information can be pulled from a health app or an app or device associated with the pump).

[0298] Example implementation of a decision support engine The decision support engine can include one or more models 110. The one or more models 110 can include, for example, state models. In one example, a "virtual patient" model can include known information about a patient, formed from known factors, or based on a template model derived from population data, or learned from information about the patient, or a combination thereof. The models can reflect, for example, physiological information and behavioral information. Physiological information can include factors such as, for example, glucose or insulin sensitivity, physical activity or response to stress, illness, fatigue or rest, growth rate (e.g., in children), or basal metabolism. Behavioral information can include factors such as, for example, food and beverage intake, exercise, insulin administration, schedule as described in a calendar appointment, interest in guidance, and the like. In a state model, factors such as these can be represented as states, which can be discrete (e.g., high, medium, low) or continuous (e.g., determined by a function). The one or more models 110 can include patterns, which can include, for example, physiological patterns, contextual patterns, or behavioral patterns, or combinations of these patterns. The physiological patterns can be based on a physiological model, for example.

[0299] In some examples, two or more models may work together to determine guidance. For example, the physiological model 112 and the behavioral model 114 may interact to determine glucose management guidance that accounts for both the patient's physiology and the patient's behavior. In some examples, the output of one model may be the input to the other model. In various configurations, the models 112, 114 may be independent or the models may be sub-models of the model virtual patient model 110. In some examples, the models may also interact with a measurement model 116, which may be, for example, a continuous glucose monitoring model. The measurement model may include factors such as sensor accuracy, calibration factor, time since insertion, time since calibration (for systems that use calibration), sensor status (e.g., sensor or sensor failure), communication status (e.g., signal loss), etc.

[0300] In various examples, the decision support engine 104 can reside on a remote resource 109, a local device 108, or a combination thereof (e.g., a "hybrid configuration"). The decision support engine 104 can reside on or be connected to one or more remote resources 109 (e.g., a cloud server) by a network such as a cellular network, a Wi-Fi network, the Internet, or a combination thereof. The cloud server 109 can collect and store information received from the sensors 106. The cloud server can also collect other information such as user calendar information, e.g., information received from a patient's or patient caregiver's calendar. In some examples, the decision support engine 104 can reside on a device near the patient, e.g., the local device 118. In some examples, the decision support engine 104 can reside on a local device but receive assistance or periodic updates from a remote system. In an example of a hybrid configuration, the decision support engine 104 can be distributed between the local device 118 and the remote system. For example, initial processing can be performed on a local device (e.g., a smartphone) and more complex processing requests can be routed to a remote resource that may have greater processing power. A hybrid configuration can maintain or improve performance of the local device 108 by avoiding overloading the local device with overly complex processing tasks. A hybrid configuration can also improve system performance because some tasks can be performed quickly without network access by the local device 108, but more complex tasks are possible by leveraging the greater processing power of the remote resource 109.

[0301] As a practical matter, it may also be desirable to avoid overloading the remote resource 109 with requests from a large number of patients. In one example, the local device can periodically (e.g., in real time, or according to a schedule, or when a connection is available, or any combination thereof) transmit data to the remote resource 109, and the remote resource can evaluate the data for a particular user periodically, such as once per hour or once per day. The remote resource 109 can, for example, examine the received data, or a dataset that is augmented with or includes the received data, to look for problems or potential insights. The remote resource 109 can, for example, update a model to reflect or take into account new data. In various examples, the remote resource can send updates (e.g., pushed by the remote resource 109 or as requested by the local device 108) to the local device to address problems, insights, or model updates learned from new data or an expanded dataset.

[0302] Exemplary determination of timing of guidance by a decision support engine The decision support engine can process various inputs, e.g., apply the inputs to one or more models, and determine a time for guidance that is calculated to be useful to the user. In various examples, the timing of the guidance can be calculated to enable the user to improve the user's sleep experience, eating experience, or quality of life. For example, the system can identify potentially problematic patterns and determine a time to deliver guidance, where the guidance delivery time is calculated to avoid sleep interruptions, or to maintain glycemic control while providing the user flexibility in meal choices and timing, or to provide sufficient advance notice of a potential problem (e.g., high glucose fluctuations or low glucose levels) so the user can adapt their behavior or respond to the problem in a timely manner.

[0303] In one example, the system can promote healthy or uninterrupted sleep by determining that a problem is likely to occur when the user is likely to be asleep (e.g., 2:00 AM) and calculating a time to deliver guidance when the user is likely to be available (e.g., 9:00 PM). The system can recommend actions such as eating a pre-sleep snack to avoid nighttime lows to avoid the need to wake the user during the night. In one example, the system can receive glucose values ​​and determine based on a patient learning model that the patient is likely to have a hypoglycemic event when the user (caregiver or patient) is likely to be asleep and determine the guidance and the time to provide the guidance so as not to disturb the patient's or caregiver's sleep.

[0304] In other examples, the system can determine a pattern of overnight blood glucose concentration levels or trends and delivery guidance for modifying actions or treatments. For example, the system can recommend a basal dose increase if the system detects a pattern of glucose levels rising overnight such that the glucose concentration levels or trends meet a condition (e.g., above a specified value (e.g., 130 mg / DL or a change of a specified amount (e.g., an increase of more than 30 mg / dL or 40 mg / dL during sleep or during a specified period related to sleep (e.g., 12:00 to 5:00 AM))). In other examples, the system can recommend a basal dose decrease when the system detects a pattern of glucose concentration levels decreasing a specified amount or rate or otherwise meets a condition.

[0305] In other examples, the system can support mealtime decisions by providing the user with flexibility in decisions about what and when to eat while providing guidance calculated to help maintain glycemic control. In one example, the system can determine that glucose levels tend to be higher before mealtimes and determine a time to deliver guidance regarding a pre-meal correction bolus to avoid having to delay the meal when the mealtime arrives. For example, the system can determine that the user needs to "pre-bolus" a specified amount of time before a meal (e.g., deliver insulin 20 minutes before starting the meal), and the system can determine a time to deliver guidance to deliver the bolus so that the meal can begin at a planned time or a time that is consistent with a learned pattern. In some examples, the length of the pre-bolus window (the time from administration of the insulin bolus to the start of eating) can be determined by the system, and the timing of the guidance can be calculated to give the user a time that corresponds to the calculated pre-bolus window. For example, the system can determine that a 30-minute pre-bolus is needed to affect high glucose levels before the patient eats their next meal. In one example, the system can deliver guidance 30 minutes before a planned meal to prompt the user to deliver a pre-bolus. In other examples, the system can provide additional time for the user to accommodate the pre-bolus, for example, the system can determine that pre-bolus guidance will be delivered 60 minutes before a meal to allow 30 minutes advance notice of the need to deliver a pre-bolus 30 minutes before a meal.

[0306] In other mealtime examples, the system can calculate the time to deliver guidance during or after a meal. For example, the system can determine that insulin is rising faster than normal and that guidance should be given to deliver an additional dose of insulin. In one example, the system can calculate the time to deliver guidance to optimize glucose control. For example, the system can determine that guidance should be given during a meal to deliver additional insulin. In another example, the system can calculate the time to deliver guidance to avoid interrupting a meal. This can be accomplished, for example, by consulting the user calendar, or based on patterns of behavior (e.g., average meal times), by using physiological sensors (e.g., activity sensors), or by using location information (e.g., detecting that the user has left a restaurant).

[0307] In some examples, the system can be designed to improve the quality of life of a patient or caregiver by calculating the time to deliver guidance to provide sufficient advance notice of a potential problem (e.g., high glucose fluctuations or low glucose levels) so that the user can adapt their behavior or respond to the problem in a timely manner. For example, the system can determine that an excursion (e.g., a high glucose trend) is likely to occur and determine the time to deliver guidance that allows the user to take corrective action (e.g., provide a correction bolus or exercise) to counter the likely excursion. In some examples, the system can calculate and / or make predictable the time for delivering guidance so that the user can focus on other activities and predict the delivery of the guidance. For example, the system can deliver guidance every two hours during the day. In some examples, the system can determine a recurring schedule for delivery guidance. In some examples, the system can deliver guidance regarding the need for user vigilance for glucose management. For example, the system can calculate the probability of the need for user intervention (e.g., determine the risk of blood glucose concentration levels falling outside a specified range) and notify the user when a condition is met (e.g., the probability is above a threshold). In some examples, the system may periodically notify the user that no intervention is required (e.g., "Looking Good: Blood Glucose Levels are Well Controlled").

[0308] In some examples, the system can deliver guidance on when to check the system for further guidance. For example, the system can receive meal information, such as meal contents and expected or actual (current or past) meal times, and advise the user to check back for further guidance within a specified time, such as "check back in 30 minutes for further guidance." In other examples, the system can deliver pre-sleep guidance, such as "eat a light snack and check back 10 minutes after eating," and prompt the user to check back after pre-sleep activities are completed.

[0309] In some examples, the timing of the guidance can be calculated based in part on user-defined preferences, such as a preference for whether the user wants to be interrupted during a meal, or the conditions under which the user wants to be interrupted, or the time periods during which the user prefers to be interrupted or not interrupted.

[0310] In some examples, the timing of guidance can be provided in relation to current user activity based on real-time data and patterns learned from past activity. For example, to determine a helpful time to deliver guidance, the system can integrate real-time physiological data (e.g., CGM data) with known physiological and behavioral patterns (e.g., models) to determine both the nature of the guidance and the timing of the guidance. The system can, for example, learn glucose responses after a particular meal. If real-time data suggests that the user is about to eat the same or a similar meal (e.g., determined from GPS information or a Wi-Fi connection to a restaurant), insights can be delivered based on patterns learned from past activity. In other examples, real-time data can suggest that the user is about to sleep or has a meeting approaching, and such data can be used to determine the time to deliver guidance, for example, the real-time information can indicate that decision support should be taken immediately or sooner than otherwise to avoid interrupting upcoming activities (e.g., sleep or a meeting).

[0311] In some examples, the timing of the guidance determination can balance the need for data to determine the state with the need for timely action and the need to avoid unnecessary or excessive interruptions to the patient. Generally, as time passes, more data is available to obtain a curve fit to the pattern or to apply against the model, which allows more accurate conclusions to be drawn regarding the state, probability, or appropriate guidance. For example, four hours after a meal, most of the data regarding the body's response to the meal is known. However, after one hour, the full response is still unknown, but it is generally possible to identify how much the user ate or whether the insulin delivered was appropriate for the meal consumed. After two and a half hours, these determinations can be made even more accurately. In some cases, the user can administer a correction bolus, or the user is instructed to eat more, for example, because the patient did not take in as much as they thought they would, and may now be at risk for trending toward low glucose levels. This additional information regarding food intake or insulin administration can also be processed by the system. In this example, the timing of delivering guidance can be determined based on the information that becomes available after the meal. This can include one or more of food consumption information, insulin information, glucose level information, other physiological information (e.g., activity), and known physiological patterns (e.g., from physiological models). Timing can also be based on user settings that can be learned from data (e.g., settings regarding frequency or timing of alerts, e.g., alert more frequently / less frequently, or alert earlier / later, or alert according to a predetermined or learned schedule), which can be learned from data (e.g., as states) or entered as user input.

[0312] Returning to the post-meal example above, it may be determined when to trigger the alert, somewhere between the time the user eats and the time the alert is triggered. This determination may take into account the fact that if the alert is delayed, e.g., waiting for the system to decide on guidance or delivery of guidance, the guidance, or the underlying condition on which the guidance may be determined, is likely to become more accurate over time. However, if the system waits too long, the optimal or desirable window of opportunity to deliver guidance and administer therapy may have passed while the system waits for data to accumulate, e.g., undesirable glucose trends or insulin sensitivity levels may occur. As glucose levels rise above the normal range, the patient's body may tend to become insulin resistant, which may make it more difficult to use insulin to bring glucose levels back into the normal range, and therefore, larger doses of insulin may be required. Larger doses of insulin may increase the risk of the patient trending toward low glucose levels when insulin resistance (and high glucose levels) are eventually overcome. On the other hand, if glucose levels tend to be too low, glucose may be administered too late or may lead to an over-reaction by the patient (e.g., administering too many carbohydrates too quickly) or the patient's body (e.g., releasing glycogen by the body), which may then lead to high glucose levels (sometimes referred to as the Somogyi effect). In more extreme cases, acute risks may occur and alternative options such as administration of glucagon may be necessary. In severe cases, the patient's ability to follow or participate in subsequent guidance may be reduced, as the patient may lose cognitive abilities or consciousness at very low glucose levels.

[0313] User convenience may also be considered in determining the timing of guidance. For example, if a user knows that they will be attending a meeting in 2 hours, the system may provide a warning before the meeting, even if the determined condition or guidance is less accurate than would normally be accepted (e.g., an optimal balance between data accumulation and risk avoidance has not been achieved), to avoid disturbing the user during the meeting, or to ensure that guidance is delivered when intervention is feasible. In some examples, if the user is caught in a situation where they do not need to respond to the warning, the system may provide an option to receive an early warning, even if the warning or guidance is somewhat less accurate, via, for example, a one-time user input, or adjustment of a user-controlled setting, that may correlate or interact with the calendar. For example, if the system knows or has access to the user's calendar, the system may provide such a prompt and option on its own ("Would you like an early warning before your meeting every Tuesday afternoon?"). In other examples, the system may receive a request from the user (e.g., in the form of user-requested insights, as further described below).

[0314] In some examples, state models can be used to balance factors of urgency and inconvenience. For example, a state can include a risk level or probability of transitioning to an undesirable state (e.g., risk or probability of trending toward a blood glucose level below 40 mg / Dl or above 180 mg / Dl), and the system can control guidance decisions or delivery to keep the risk level or probability within specified parameters while avoiding inconvenient notification times where possible.

[0315] The system may also take into account the user's sleep schedule. For example, if the user is known to go to bed within four hours of having a meal, but the glycemic response to the meal is not yet known, the system can provide guidance to do something before going to bed to improve those situations or to avoid the risk of trending towards undesirable conditions or glucose levels. For example, the system can deliver pre-sleep guidance to administer a correction bolus or make a basic adjustment to avoid persistent high glucose levels or trends towards high glucose levels, or to avoid waking the user for overnight interventions. In another example, the system can deliver guidance to eat a snack before going to bed to reduce the risk of low glucose levels.

[0316] Example output-guidance format The guidance output from the decision support engine 104 may include, for example, text (e.g., "Monitor for unexpected low glucose levels"), sounds (e.g., tones or speech), or graphics or animations such as predicted or actual insulin graphs, or probability cones indicating a range of possible outcomes from an assumed or completed action, such as exercise, food consumption, insulin delivery, or a combination thereof. The probability cones may indicate a range of potential outcomes over time, with the range of outcomes expanding over time; i.e., a wider range of options become possible (or statistical conditions can be met). The guidance may include warnings, recommendations, or other useful information.

[0317] In some examples, the guidance recommendation screen can show factors included in the guidance decision and allow the user to adjust the assumptions or weightings applied to each factor. For example, an interactive recommendation can include an action to deliver 4 units of insulin in the next 15 minutes and a set of factors used in the decision (pasta has 40g of carbohydrates, patient's activity level after lunch is typically moderate, and current glucose level is normal but declining). These factors can be adjusted by the user if the assumptions need to be changed. In some examples, CGM insulin and meal / carb data can be post-processed to determine the best possible insulin control. In some examples, the system can intentionally introduce a time-limited bias to reflect pending changes that are occurring or may occur. For example, the system can intentionally skew blood glucose levels low immediately after insulin is administered to reduce the likelihood of overcorrection for a limited time.

[0318] In various examples or guidance, decision support requests can use text, email, app notification, phone call, or other means of communication. In some examples, the best mode can be selected by the user or the system based on the context. For example, the system can use voice while the patient is driving and view messages while in a meeting. In some examples, guidance and decision support requests can be voice enabled using automatic speech recognition and natural language understanding.

[0319] Various types of guidance insights are possible. For example, guidance output can include, for example, event-driven insights 126, user-requested insights 128, or periodic insights 130. Event-driven insights 126 can include, for example, time, context, or physiological event-driven insights driven by underlying algorithms that identify decision points, such as useful times for delivering actionable guidance. User-requested insights 128 can include, for example, guidance for a particular treatment decision at a particular time, such as a pre-meal insulin delivery, or a user request in anticipation of an event, such as a meeting, physical activity, or sleep, and the decision support engine 104 can provide the guidance in response to the request. Such guidance can include, for example, a recommended basal or bolus insulin dose or scheme, or an amount of exercise, or a plan to monitor or intervene at a particular time or time range. Periodic (non-real-time) insights 130 can summarize patterns, diet, or treatment decisions over several days. For example, periodic insights may include retrospective summaries at the end of a period such as a day, week, month, or quarter, post-workout summaries, summaries after a period of time (e.g., by number of hours, or morning or afternoon or evening), or variations thereof.

[0320] Examples of event-driven insights 126, user-requested insights 128, and periodic insights 130 are described in further detail below.

[0321] Event-Driven Insights Time, context, or event-driven insights can be driven by a determined state or state transition, a physical event, a location, a timing pattern (such as a calendar), or any combination thereof. For example, insights can be triggered at least in part by a physiological event, such as a pattern of glycemic events, which can include, for example, rapidly dropping glucose levels after a meal or during exercise, or rapidly rising glucose levels (e.g., after a meal or snack, or a stressful event).

[0322] The insights can take the form of personalized guidance messages with specific relevance to currently occurring events or patterns. The personalized guidance messages can be based on information learned about the patient, which can be embodied or reflected by one or more models of the patient. In one example, the system can detect patterns preceding hypoglycemic and hyperglycemic events and alert the user in sufficient time to take action. In another example, therapy adjustments can set context-driven alerts: for example, if a therapy adjustment is made, such as an increase in basal rate, that can be determined to increase the risk of nighttime low glucose levels, low glucose warnings can be made more sensitive at night for a specified period of time, such as the next two weeks, or a personalized guidance message informing the user of the possibility of nighttime low glucose levels can be delivered every night or more frequently or under a wider range of conditions than before the adjustment. In other examples, a treatment decision or treatment event (e.g., forgetting to administer insulin before a meal, e.g., missing a “pre-bolus”) can be determined to be likely to warrant increased vigilance (e.g., checking CGM data or recognizing a potential need to provide treatment) during a time window following the decision or event that can be communicated via a guidance message, or during a window in which a guidance message can be delivered under a broader set of conditions (e.g., a lower threshold for providing event-driven guidance). In some examples, event-driven alerts can be set based on cumulative glycemic risk or glycemic exposure, e.g., food or calorie or carbohydrate consumption can be tracked and insulin / glycemic imbalances can be detected, which can be communicated via personal guidance ("your food and beverage consumption may be higher than expected") or can form the basis of a personal guidance message ("depending on your eating and drinking patterns, more insulin may be needed"). In some examples, the personal guidance message can offer a range of choices stratified by risk and reward.

[0323] In some examples, the decision support engine can determine the bolus recommendation (meal bolus or correction) and determine the time to determine the recommendation. The timing of the bolus determination and delivery of guidance can be calculated to balance the need for guidance with the interest in avoiding interruptions to the patient / user and the need for sufficient data to accurately determine the bolus information. In one example, manual input and learned or planned input (e.g., meal information) may be fed into the bolus calculator. The bolus calculator can be generic or personalized, e.g., specific to the user's current diabetes status. The bolus calculator can output a recommended dose and the system can observe the glucose level after the user administers the recommended dose. Based on the historical data, a typical glycemic response in a particular situation can be known, allowing for a comparison of real-time data with historical data or patterns derived from historical data. For example, if a user ingests 60g of carbohydrates and takes a particular amount of insulin, the resulting glucose levels and the trend occurring over time can be known from historical data or patterns (e.g., 120mg / dL glucose level 30 minutes after the meal, rising slowly (e.g., 2mg / dL every 5 minutes)). In certain cases, the user indicates that they ate a particular meal or amount of carbohydrates (e.g., 60 carbohydrates), but the glucose values ​​produce a different level or trend than the previous profile (e.g., 160mg / dL glucose level and steadily rising (e.g., 10mg / dL every 5 minutes)), the system can query the user to obtain corrected meal information or determine the number of carbohydrates the user actually ingested based on the glucose signal and current guidance or query ("Did you eat something else?" or "Did you not eat chicken?"). The system can also take into account the presence of other foods that may affect glucose trends, such as absorption rates (e.g. fast carbohydrates such as foods with large amounts of sugar or refined sugars vs. slow carbohydrates such as pasta) and protein and fat, which slow down the absorption rate of carbohydrates consumed along with protein and fat.

[0324] In an example using a state model, the patient's state may initially be in a first state (e.g., eat 60 carbohydrates) and the system may subsequently determine that the patient is actually in a different state (e.g., eat 90 carbohydrates). In other examples, the patient's state may initially be in a first state (e.g., eat 60 carbohydrates) and so dose accordingly, but the patient's state is later determined to be in a state of X carbohydrate count error (e.g., 30 grams of carbohydrates), in which case the system may provide decision support guidance such as a correction bolus to avoid a low or high.

[0325] In some examples, the time to deliver guidance regarding a correction bolus may be determined using a physiological model, a behavioral model, or both. For example, a range of acceptable times for delivery of a correction bolus can be determined using a physiological model, and a range of convenient times for delivery guidance or a correction bolus can be determined using a behavioral model using, for example, learned pattern information, or using a calendar showing meeting schedules or class schedules, such that guidance can be timed to be delivered during or near the end of a class or meeting.

[0326] User Demand Insights User-requested insights can include receiving input from a user (e.g., through a smartphone app) for decision support for impending diabetes decisions such as, for example, "How much insulin should I bolus before this meal?" or "Should I have a snack before my bike ride?". In one example, a personalized guidance response can include an interactive recommendation (e.g., "Deliver 4 units of insulin") and can also optionally include a set of factors used in the decision (e.g., "A portion of pasta has 40g of carbohydrates, activity level after lunch is typically moderate, and current blood glucose level is normal but declining"). In some examples, factors can be adjusted by the user if assumptions need to be changed (e.g., to arrive at a different dose).

[0327] In some examples, previous user request insights can be used as inputs to the model, and the model can learn or adapt to situations in which a user is likely to request insights. This information can be integrated into the model and decision support engine, e.g., to predict requests and proactively provide guidance to the user, so that the system can provide personalized guidance for situations and times when the user is likely to need guidance. For example, if the user frequently requests guidance before a weekly bike ride (e.g., determined from learned behavioral patterns), or while eating at a particular restaurant (e.g., determined from the patient's calendar), or after completing a physical workout (determined from an activity sensor, an associated smartwatch, or a calendar), the system can determine that personalized guidance is needed at certain times and deliver guidance relevant to the current situation or typical pattern. User request insights can also be used to educate the model based on information implicit in the user's requests. For example, if a user requests decision support before exercising, the system can gather that the user tends to exercise at certain times, and can reveal exercise timing patterns (e.g., performed on Monday, Wednesday, and Friday mornings), especially if a series of related user requests are obtained over a period of time.

[0328] In some examples, the system can receive a user request for decision support for a future activity (e.g., exercise, driving, eating, or sleeping), and the system can provide suggested treatment adjustments or preparation steps as guidance. For example, the guidance can include basal insulin changes, bolus insulin calculations, and recommended snack amounts (e.g., change basal by x amount before starting exercise or eat 15 grams of carbohydrates before bed). In some examples, the system (e.g., model) can learn from the results of the guidance and make adjustments specific to the individual, e.g., the system can learn how much exercise changes glucose. In some examples, patient-specific information, such as basal rates and insulin-to-carb ratios for specific meals and times of day, can be entered by a clinician into an electronic medical record (EMR) system and retrieved and used by the system to inform or educate the model or aid in the development of a response to the patient's request for guidance.

[0329] In one example, the system can receive a user request for pre-sleep guidance. The request can be received, for example, via a decision support smartphone app. The system can provide guidance regarding one or more actions the user should take or consider before going to bed, such as eating a snack, delivering a dose of insulin, setting an alarm clock, or setting an alert setting for a continuous glucose monitor. The system can also provide a description of the risk or reason for the guidance. For example, the system can inform the user of the risk of a "late and low" glucose level due to an exercise session, or the risk of a low glucose level due to a reported insulin dose that the system estimated to be too high for a given meal or set of circumstances, or the risk of a low or high glucose level based on a trend analysis. In some examples, the system can inform the user of a time or range of time when a problem may occur, such as "a low glucose level is likely to occur around midnight." In some examples, the system can suggest that the user recheck the guidance at a later time (e.g., check the smartphone decision support app for the latest guidance), which can occur, for example, if the system determines that additional information (e.g., additional CGM trend data) can be particularly helpful in determining the guidance, improving the confidence of the guidance, or determining an expected event.

[0330] In one example, a user can provide a photo of an upcoming meal or scan a restaurant menu and the system can provide guidance on the estimated effect on blood glucose or insulin dosing recommendations. For example, a mobile device (e.g., smartphone) application can be configured to scan a menu and convert meal items into estimated glycemic impacts. In one example, a user may be prompted to position the smart device camera over a menu and the glucose information for the menu items may be presented on the user interface, for example, next to the menu items the user viewed on the screen. This can be accomplished, for example, using text recognition and a lookup table of glucose values ​​for a particular type of meal or establishment. In some examples, meals that are considered "healthy" or "unhealthy" may be highlighted, indicated with text or symbols, or identified in the user interface, for example, using augmented reality (AR) where the menu is the subject of augmentation. In some examples, predicted glycemic impacts or variations (e.g., "72g carbs" or "BG>200") or required insulin bolus (e.g., 6 units) may be presented. In some examples, a predicted trend graph, or summary metrics such as glycemic load may be presented. In some examples, the predicted excursions can be personalized by learning from historical data or profiling the patient and incorporating such information into a physiological model as needed so that the glucose impact is personalized to the patient. In other examples, a proposed workout (e.g., a 30 minute moderate run, or 5 sets of deadlifts, or a 1 hour swim) is provided as an input (e.g., entered into a smartphone app) and expected results such as a glucose profile can be predicted (e.g., by applying the workout as an input to a model) and displayed in a user interface. Results may be provided, for example, as probability cones to provide the user with information about potential ranges of glycemic response.

[0331] In some examples, the guidance can include a bolus recommendation that can include two numbers reflecting a decision tree, for example, one bolus number assuming the user exercises as planned and a second bolus number assuming the exercise is not completed. In some examples, the guidance can include an amount of insulin onboard, which can be the amount of insulin determined to be the activity in the body as determined by a predefined algorithm (e.g., based on population-based or theoretical data) or as determined by a model (in which case the insulin onboard can be patient-specific). The insulin onboard guidance can be provided upon a user request or in response to an event, such as a determination that insulin onboard is likely to cause low glucose levels or a determination that the amount of insulin onboard may be insufficient to control glucose levels (i.e., high glucose levels may occur). In some examples, the guidance can reflect a predefined or user-defined goal, such as a predefined blood glucose range (e.g., 70-150 mg / dL range) or a percentage of time that glucose levels are in a defined range (e.g., 80% of the 70-150 mg / dL range). For example, guidance can include suggested changes (eg, afternoon exercise or changes to insulin dosage) to move the user toward a goal.

[0332] In other examples, input from a user can initiate a glucose tolerance test or other type of self-assessment, e.g., a well-characterized meal is eaten and the glucose response is tracked. The results of the test or assessment can be communicated via guidance messages (e.g., "Blood glucose remained within range" or "Blood glucose spiked soon - consider longer pre-bolus time").

[0333] Regular insights Periodic insights can also be provided as guidance. For example, guidance can be provided according to a periodic schedule, such as weekly updates, or when it is determined that sufficient data is available to provide a reliable summary, such as 10 low carb breakfasts vs. 10 high carb breakfasts to provide comparative analysis, averages, graphs, probability zones, or other information regarding diabetes management. In one example, meals or foods can be grouped by types with similar glycemic responses in terms of magnitude and time course ("spike vs. slow"). In another example, meals or foods may be grouped by similar insulin administration strategies, such as which meals require a correction bolus. In another example, the decision support engine can summarize types of decisions that yield less reliable results in a manner that promotes education ("low carb breakfast ideas") or medical review (e.g., consulting a physician about management strategies). The decision support engine can compile summaries of such information (e.g., problematic meals) in anticipation of a physician visit, including successes and concerns.

[0334] In some examples, the decision support engine can provide schedule-based trend information. For example, an individual's schedule may be different on weekends and weekdays. This difference in schedule can be reflected in the patient's glucose levels, or the patient's interest or availability in managing glucose levels, or the patient's goals or thresholds for notifications. In some examples, the periodic insights can be presented in a manner that differentiates based on the schedule, e.g., weekend trends and weekday trends can be presented separately. The guidance can also include separate treatment or action suggestions for different parts of a person's schedule, e.g., different basal patterns can be suggested based on knowledge of the schedule. In various examples, the schedule is learned by the model informed by the patient's or caregiver's calendar, based on user input via a user interface (e.g., answering questions on a smartphone), or a combination thereof.

[0335] The various insight examples described above can be converted into different types of insights, for example the examples described as event-driven insights can be provided as user requested insights, which can be provided as event-driven insights by application of algorithms or models that determine the conditions and timing for delivery of insights as guidance.

[0336] “Real-time” does not necessarily mean immediate, but interventions can impact short-term outcomes based on recent data or trends, as opposed to retrospective information presented to assess opportunities for overall behavior or treatment improvement. Input and model interactions

[0337] FIG. 2A is a diagram of an example configuration of the model 110 shown in FIG. 1. FIG. 38 is a diagram of another example of the configuration shown in FIG. 2A. The patient 102 is interested in controlling a true glucose level 160, which can be measured by a sensor 152. The physiological model 112, the behavioral model 114, and the measurement model 116 process inputs and generate outputs (e.g., states), which may be provided to the patient as guidance or may be used to determine the guidance of the patient 102 as well as the time to determine or deliver the guidance. The guidance can be delivered via a guidance module 150.

[0338] The sensor system 152 can measure physiological parameters such as glucose level, activity, heart rate, respiration, or body temperature, or contextual parameters such as ambient temperature, pressure, or location. The sensor system 150 can include multiple sensors integrated into a single device (e.g., a watch), or a group of multi-sensor devices (e.g., a watch and a wearable sensor), or the sensors can reside in individual other devices, which may or may not communicate with each other. For simplicity, the sensors that provide the data inputs are referred to simply as the "sensor system." The sensor system 152 can include a continuous glucose monitor (provided in more detail below) that can be configured to measure a glucose level that is calculated to be indicative of a true glucose level 160.

[0339] Data from the sensor system 152 can be provided as input to the physiological model 112 or the behavioral model 114, or both. The physiological model 112 can also receive input from the patient 102, input from the measurement model 154 (described below), input from the behavioral model 112 (such as activity or stress state), or information regarding drug delivery 156 (e.g., insulin delivery), which can be received via user input from the patient or from a delivery device such as an insulin pump or insulin pen. The physiological model can also use other inputs. A detailed description of the inputs and outputs of the physiological model is provided below in connection with FIG. 2B, and a number of inputs are shown and described in FIGS. 14-16. The physiological model may provide as output physiological state information such as current or predicted glucose levels or trends, insulin-to-carbohydrate ratio (ICR), insulin sensitivity factor (ISF), basal rate, or insulin on board (IOB), all of which may influence the true glucose level 160, as well as insulin delivery decisions or recommendations made by the guidance module 150 or the patient 102 or caregiver or clinician.

[0340] The physiological model 112 or the behavioral model 114 may also receive information received from the patient, such as calendar information from a computer system such as a smartphone, user input regarding a particular activity or exercise, or user input regarding food consumed. The behavioral model may also receive as input guidance information delivered to the patient, as well as sensor data. The behavioral model may also receive output from the physiological model. The behavioral model may process various inputs to determine a current patient state or predict a future patient state, which may include, for example, exercise, sleep, potential for intervention, interest in receiving guidance, and other information regarding the patient's activities, interests, or behavior. The behavioral model may also receive context information or determine current or predicted context information as a state (e.g., in a meeting or driving home), which may be used to determine the timing of guidance or delivery of guidance. A detailed description of the inputs and outputs of the behavioral model is provided below in connection with FIG. 2B, and a number of inputs are shown and described in FIGS. 14-16. A measurement model 154 may be included in the system, if desired. Data from the sensor system 152 can be provided to a measurement model 154 that can process the sensor data to assess the precision or accuracy of the data, for example to determine the likelihood that a measured glucose level matches a true glucose level. The sensor system can use statistical techniques such as variability or variance of the sensor data points, trend information, historical information, and information provided by behavioral models, physiological models, and other sensors to assess whether one or more sensor data points are likely to be accurate or inaccurate. For example, if successive blood glucose data vary widely or reveal a pattern that does not reflect a normal physiological pattern (e.g., 90 mg / dl, 112 mg / dl, 96 mg / dl, 121 mg / dl in successive 5 minute increments), the measurement model can determine that the sensor data is relatively inaccurate. Other sensor data can also be evaluated. Sensor data can be evaluated based on data that falls outside of the range of estimates.For example, if an ambient temperature of -5°C is detected in July, the model may conclude that the sensor readings are inaccurate, especially if location information is available. In other examples, activity information may be processed, including correlating aspects of the measurement model with aspects of the behavioral model, to determine correlations with likely actual activity. For example, accelerometer information may be processed to assess whether movement is overly rhythmic (which may indicate mechanical movement, e.g., a bumpy ride, as opposed to exercise) or outside of expected ranges (e.g., a relatively sedentary person who is active for 3 hours). Output from the measurement model (e.g., accuracy state information) may be provided to the behavioral model 114 or physiological model 112 for integration with other information to determine physiological or behavioral state.

[0341] The guidance module 150 can deliver guidance information to the patient 102, for example, via a user interface on a mobile device such as a smartphone. In some examples, the guidance module 150 can determine guidance based on information (e.g., conditions) provided by the physiological model 112 and the behavioral model 114 and determine a time to provide the guidance that is calculated to be useful to the patient. In other examples, the guidance and delivery time may be determined by a model, such as the behavioral model 114, and the guidance module 150 may provide the determined guidance at the determined time. In various examples, the guidance module 150 may reside, for example, on the mobile device 108, or may reside on a computer system that is remote or local to the patient and can deliver guidance to the patient via a user interface on the mobile device 108 or other device.

[0342] Exemplary Model FIG. 2B provides a more detailed view of exemplary model inputs and exemplary states that can be determined by applying the inputs to the models. The physiological model 112, behavioral model 114, and measurement model 116 of FIG. 2B are shown with exemplary inputs and states for each model. Exemplary inputs are shown on the left and exemplary determined states are shown on the right. FIGS. 14-16 below provide a more comprehensive description of the inputs, any of which can be applied to one or more models. The states can be identified by a physician or expert or learned by the models via machine learning. Each state can have two or more (possibly multiple) state values, e.g., discrete numeric, range, or qualitative values ​​(high / medium / low or stable / unstable). The states can be determined by applying one or more of the sources of input data to the models. Although three models are shown, one skilled in the art will understand that the models can be integrated into one or two models or decomposed into a larger number of models or sub-models.

[0343] Physiological Models Food consumption can be provided as input to the physiological model 112. Food consumption information can include information about meals, snacks, and beverages, such as size, content (carbohydrates, fat, protein), order of consumption, and time of consumption. Food consumption can be provided by the user manually entering, providing a photo in an application configured to recognize food types and amounts, or scanning a barcode or menu. In various examples, meal sizes can be entered manually as calories, quantities ("3 cookies"), menu items ("royale with cheese"), or food exchanges (1 fruit, 1 dairy). In some examples, meals can also be entered with items or combinations typical of the user for this time or context (e.g., weekday breakfast at home, weekend brunch at a restaurant). In some examples, meal information may be received via a convenient user interface. For example, as shown in FIG. 25A and FIG. 25B, a user interface user 2500 can allow the user to indicate the amount of fat and carbohydrates (and optionally, protein) in each meal by touching the amount of fat and carbohydrates (and optionally, protein) in a graph 2502 (or other graphical user interface element). Figure 25A shows a selected point 2504 on a graph 2502 with high carbohydrate (78 grams) and low fat (1.6 grams) content. Figure 25B shows a selected point 2506 on a graph 2502 with high carbohydrate (78 grams) and low fat (1.6 grams) content. Figure 25B shows a selected point 2506 on a graph 2502 with low carbohydrate (3 grams) and relatively high fat (20 grams) content. Examples of meals with similar nutritional content (e.g., carbohydrate to fat ratio) can be displayed in the user interface.

[0344] Activity can also be provided as an input to the physiological model. Activity information may be provided, for example, by an accelerometer sensor on a wearable device such as a watch, fitness tracker, or patch.

[0345] Patient demographics such as age, height, weight, body mass index, body composition (e.g., % body fat), stature, build, or other information can also be provided as input via the user interface, or by interfacing with an electronic source such as an electronic medical record, or from a measuring device such as a wireless scale, e.g., Bluetooth enabled, or a camera, which can communicate with the mobile device 108 to provide patient data.

[0346] Insulin delivery can be received by the model via a wireless connection of a smart pen, or via user input, or from an insulin pump. Insulin delivery information can include insulin amount and delivery time. Other parameters such as insulin action time or duration of insulin action can also be received as input.

[0347] The physiological model 112 can also receive user input via a user interface, such as the smart device 108. Such user input can include mental state or stressor information, the implementation of a treatment, such as the use of glucagon to stimulate hepatic release of glycogen in response to hypoglycemia, a recommended basal rate or insulin-to-carbohydrate ratio (e.g., received from a clinician), or a recorded activity (e.g., intensity, duration, and completion or start time).

[0348] Inputs can also be received from sensors such as physiological sensors that detect heart rate, respiration, oxygen saturation, or temperature (e.g., to detect illness). Electromagnetic sensors can also detect low-power RF electromagnetic fields emitted from objects or tools in contact with or in close proximity to an object, providing information about a patient's activity or location. Glucose level information can also be provided as an input, for example, via a continuous glucose monitoring (CGM) system providing CGM data. Inputs can also be received from sensors that measure peripheral neuropathy using tactile responses such as smart pill dispensers that track when customers take their medication, blood ketone meters, laboratory measured or estimated A1C, other measurements for long-term control, or the haptic capabilities of smartphones, or specialized devices.

[0349] The state of the measurement model or the behavioral model can also be provided as input.

[0350] The time can also be provided as an input, such as the time of day or the time from a real-time clock.

[0351] In some examples, model inputs can be inferred from, for example, one or more historical user inputs (e.g., food diaries), geolocation information, insulin administration, CGM function (rising blood glucose levels), or time of day. In some examples, the model can operate in a learning mode, where a database of information (historical or real-time) is collected. Causes or effects, or both, can be inferred from the database. Patterns can also be inferred from the database, such as patterns associated with particular meals or meal types or activities, or insulin action times or duration of insulin action, or combinations thereof.

[0352] Physiological status One or more physiological states can be determined by applying inputs to a physiological model. Metabolic rate can include basal metabolic rate (e.g., energy consumed at rest) as well as active metabolism, e.g., energy consumed by activity, e.g., exercise, activity, or movement. In some examples, basal metabolic rate and active metabolism can be tracked as separate states. Activity level can also be determined, e.g., based on activity sensors or other physiological sensors. Activity level states can include, e.g., four states: sleep, rest, activity, and exercise. Insulin sensitivity can be determined using historical data, real-time data, or a combination thereof, and can be based, e.g., on food consumption, insulin delivery, and resulting glucose levels. Insulin onboard can be determined using insulin delivery information and known or learned (e.g., from patient data) insulin time-action profiles that can account for both basal metabolic rate (insulin updates to keep the body running) and insulin usage driven by activity and food consumption. Meal states can include, e.g., fasting, pre-meal, meal, post-meal response, or steady state. Dietary status may also include on-board nutrition, e.g., meals, snacks, or beverages consumed, and may be determined, e.g., from food consumption information, meal time information, and digestibility information associated with food type, amount, and order (e.g., which food / beverage was eaten first). Health and illness may be determined, e.g., from physiological sensors (e.g., temperature), activity sensors, or a combination thereof, based on user input (e.g., pregnancy information or known illness information). Exemplary health states may include, e.g., healthy, sick, rest, and fatigue. Glucose levels may be determined from sensor information (e.g., CGM data), optionally in combination with a measurement model state. In some examples, when CGM data is unavailable or of uncertain reliability, e.g., based on historical information regarding glucose levels in a particular situation, e.g., given a combination of food consumption, insulin, and activity, glucose level state may also be determined from a model.The degree of glycemic control (not shown) can also be determined as a state and can be based, for example, on glucose levels, variability in glucose levels, or insulin administration patterns. A confidence level can be applied to one or more states (e.g., high, medium, low, or numerical confidence).

[0353] In some examples, transitions between states can be important decision points for determining guidance, or times to determine or deliver guidance. For example, a user may need guidance specifically when transitioning between states. For example, guidance may be needed while waiting for a glucose response after a meal, or in deciding what to do before exercising. These state transitions, or predicted state transitions, can be identified by the system (e.g., using the model) and used to determine the times to determine or deliver guidance. Examples of these state transitions can include active → rest → exercise → sleep, or healthy → sick → rest → fatigue, or a change in the degree of glycemic control (e.g., a change in glucose level, a change in insulin sensitivity, a change in insulin dosage), or a transition to pregnancy. In some examples, the physiological model 112 also includes disease stage states, such as a type II diabetes patient. Examples of disease stage states for a type II diabetes patient can include a prediabetes stage, an oral treatment stage, and a basal insulin treatment stage. The insights provided by the decision support engine can vary for a host of different disease stages, for example, as described herein.

[0354] Modeling kinetic and potential energy flows In one example, the physiology model 112 can characterize the flow of energy in the human body, which can include the effects of meals, exercise, glucose and insulin, and other hormones such as cortisol and adrenaline. Energy inputs can include meals and snacks (characterized by time, size, and type), and glucose production by the liver (e.g., the "dawn effect" in which the body releases energy in the early morning, or the release of energy by the liver to counter low blood glucose levels). Energy outputs can include energy expenditure due to activities such as exercise, glycogen replacement by muscles or liver, and glucose uptake driven by insulin. Insulin time-action profiles can take into account the separate effects of basal (e.g., resting) metabolism and active metabolism (e.g., due to activity / exercise). The model 112 can be tailored to the subject's physiology using user inputs, measurements (e.g., CGM patterns and fitness tracker or accelerometer), and inferences, e.g., learning patterns and associations from the data.

[0355] At a high level, the physiological model can track energy input, energy output, and determine one or more physiological states. This energy signature aspect of the physiological model can be used to predict future glycemic states (e.g., high glucose levels, low glucose levels, rising glucose trends, falling glucose trends). The physiological model can also interact with behavioral models and guidance modules (such as decision support apps) to determine when the user needs context-specific guidance (advice, warnings, alerts, etc.), such as transitioning from rest to exercise or from healthy to sick.

[0356] Behavioral Model The behavioral model can reflect the behavior, preferences, schedule, and other information about the user. Referring again to FIG. 2B, the input to the behavioral model can include user input, such as input via a user interface regarding activity, level of interest in guidance, or location. The input to the behavioral model can also include calendar information, such as availability and activity information received from a calendar application on a computer or smartphone. The input can also include activity, such as information from an activity sensor, such as an accelerometer on a watch or fitness band. The input to the behavioral model can also include location (e.g., GPS), time (e.g., from a real-time clock), prior guidance to the user, and physiological state. Additional inputs are also possible.

[0357] The states of the behavioral model can include the availability or convenience (e.g., available / unavailable or convenient / inconvenient) of an intervention, which can be inferred from a calendar or estimated schedule, or from learned patterns of the patient's or caregiver's schedule. The availability or convenience state can also include the caregiver's proximity to the patient, which can be inferred from location or calendar information.

[0358] Behavioral model states can also include risk tolerance (e.g., comfort with a tendency to low blood glucose levels, which may depend on experience with intervention or likelihood of caregiver intervention), interest in guidance, activity state (e.g., whether exercising, which can be inferred from a calendar or activity sensor), sleep state (e.g., asleep or resting or awake, inferred from an activity sensor, calendar, or other information), appetite (e.g., which can be inferred from eating patterns).

[0359] Engagement (or level of engagement) can also be determined as a state of a behavioral model. For example, engagement factors can include the user's response to the decision support in terms of time, activity, and type of support (user-requested, context-generated, regular). Engagement states can include, for example, the type of guidance that tends to prompt an action, the action the user participates in, which may be correlated with time (e.g., no walking from 9 to 5) and activity (e.g., no finger-prick blood glucose testing while running). Engagement level states can also reflect the time the user is engaged in receiving or following the guidance (e.g., when a short time suggests ignoring the guidance). Engagement states can also include the type of communication that can be associated with an activity or schedule, such as learning the appropriate mode of interacting with the user depending on the time of day or location. For example, a user can get display messages on a clock or phone during a meeting, audio messages in a car, and hierarchical messages based on urgency while sleeping, where urgent messages are accompanied by a sound or vibration and less urgent messages are silently displayed on the display or clock. In some examples, the engagement level logic and schemes applied above may also be applied to caregivers (e.g., data followers of smart devices) to notify them of the need to intervene or to notify the patient or other caregivers that they are aware of or in control of the situation.

[0360] The level of concern state can also be determined by a behavioral model. For example, the system can determine situations that may cause concern about a current physiological state, the outcome of a treatment decision, or a potential future condition, and determine the level of concern based on the presence or absence or likelihood of such situations. For example, the way in which a patient displays CGM values ​​or guidance, or the device on which the information is displayed, the way in which the information is displayed (such as on a watch or phone, or in a full screen display, or interacting only with a notification screen that may provide less information), can indicate the level of concern (whereas asking for more information or looking for less useful information indicates more concern). The frequency with which CGM data or guidance is checked or requested, or the frequency with which the user stops checking, can also indicate the level of concern (higher frequency indicates higher concern). Other factors that may be considered in determining the level of concern may include self-monitored blood glucose readings (e.g., finger prick sensor readings), requests for decision support and the circumstances surrounding such requests (e.g., restaurant meals vs. home-cooked meals), when insulin adjustments were made (basal, meal, post-prandial), consumption of snacks or fast acting carbohydrates to avoid hypoglycemia, the presence or attention of a caregiver (e.g., data follower) monitoring blood glucose levels or responding to data updates, or patterns of alerts. In some examples, the concern level or alert preferences can be learned via a model or set by user input based on actual or virtual data, as shown in the exemplary user interface 2602 shown in FIG. 26.

[0361] The state of concern level can be based on the time period the user is concerned about (e.g., time of day, post-meal period, post-exercise period, or specific days of the week or month, or derived from calendar events, e.g., holidays, school events, etc.). Time periods can also be applied to caregivers (e.g., data followers). The level of concern for a time period can be derived, for example, from user input or learned from user behavior. The level of concern can also reflect the user's goals, for example, a focus on the user's level of concern regarding alarms and lows, or maximizing time in range, or both.

[0362] The behavioral model can also include induction states, which can include, for example, insulin induction states (e.g., deliver X units of insulin or increase or decrease the basal rate) and carbohydrate consumption induction states (e.g., eat X grams of carbohydrates).

[0363] In some examples, generation of guidance messages or other information for the patient can occur as part of the behavioral model (e.g., as an output state from the model). For clarity and simplicity of explanation, guidance generation is described separately below.

[0364] Measurement Model The measurement model can provide information about a sensor measurement, such as a CGM sensor measurement. The measurement model can provide, for example, an indication of the accuracy of the data from the sensor.

[0365] CGM measurement models can add context to glucose values ​​and patterns generated from sensor data. Models can allow for a variety of data types. For example, confidence limits can be determined for data values ​​or data sets. Confidence limits can be presented to the user or provided as input to other models. Models can provide precise boundaries for, for example, adjusting for day of use (e.g., newly implanted vs. aging sensors, which may become inaccurate), adherence to calibration schedules, effects of lag at high rates of change (both due to physiological lag in the movement of glucose levels in interstitial fluid), and sensor lag due to sensors only taking measurements periodically, e.g., every 5 minutes. Measurement models can also monitor the consistency of blood glucose measurements with CGM measurements as an indicator of the reliability of blood glucose measurements, CGM measurements, or both. Similar principles can be applied to other data sources to assess accuracy, consistency, or variability.

[0366] 2B, the measurement model can receive user input, sensor data, and calibration information as inputs and determine sensor accuracy (e.g., high, medium, low), sensor data reliability, or sensor status (e.g., warm-up / active status, time since insertion or time until replacement, or sensor connectivity). Other sources of measurement model input data can include data configured to enable factory calibration or calibration other than user intervention.

[0367] Deciding on the timing of guidance In various examples, the guidance and timing of the guidance can be determined based on a state model or other input. For example, the guidance can be determined from one or more physiological or behavioral states, or a combination thereof. The determination of the guidance or the timing of the delivery of the guidance can also be determined from physiological and behavioral states. In some examples, multiple or multiple states can be used to determine the guidance and timing of the guidance. In various examples, the guidance and timing of the delivery of the guidance can be performed by a behavioral model or by a guidance module that uses state information, such as states from a behavioral model and a physiological model.

[0368] study In some examples, the system can go into a "learning mode" where the system observes physiological or behavioral data. For example, the system can collect CGM values, blood glucose measurements, insulin doses, meals, activities, medications, stress levels, sleep patterns, hormone cycles, location (e.g., via GPS) and other information to build an information set from which patterns can be inferred. The system can determine, for example, basal doses, insulin sensitivity, insulin-to-carbohydrate ratio, insulin action duration, or boluses for commonly used meals. In one example, a protocol may be followed in collaboration with the patient's engagement, which may include tracking factors such as carbohydrate intake and insulin administration. The resulting glucose levels or trends can be determined for the patient, especially if the patient is newly diagnosed or treated. Because some factors, such as insulin sensitivity, change throughout the day, in some examples, the protocol can be tracked several times at different times of the day to obtain a correlation between the desired parameter (e.g., insulin sensitivity) and time of day. Carbohydrate-to-glucose ratios can also be determined, for example, by determining how much the patient's glucose level increases per gram of carbohydrate, accounting for the underlying basal rate.

[0369] In one example, for a basal test, the user is asked to select days when the BG is in a specified range (e.g., between 80-250), and can plan to skip meals, manage their diet so that the previous meal is not high fat or very high carbohydrate, avoid exercise or other things that may affect blood glucose levels. The system can receive input from the user to initiate the basal test. The system can then evaluate blood glucose concentration levels for a period of time (e.g., 3 hours) after the last meal. If blood glucose levels are stable for a period of time, the system can declare that the basal rate is correct. If there is a period of time in which BG is increasing or decreasing, the basal rate affecting that period can be changed in small safe increments until blood glucose is stable throughout the period. In some examples, this process can be repeated until a full 24 hours (or more, e.g., a week) has been covered with a successful basal test.

[0370] If blood glucose is within a specified range, for the insulin-to-carbohydrate ratio test, the user is prompted to select a time when blood glucose is within a specified range (e.g., between 80-250) for at least a specified amount of time (e.g., 4 hours) since the last meal, a time free of exercise, stress, or other influences that may affect blood glucose levels, and to eat a specific meal with known carbohydrate content and a moderate glycemic index. In some examples, the system may prompt the user to eat a specific food or prompt the user to consume a nutritionally labeled food and take a photo to confirm. With the carbohydrate content confidently established and other causes of glucose variability minimized, the system may determine the patient's ICR. In some examples, the process may be run multiple times to allow the system to adjust to the correct ICR. This may be accomplished, for example, by making small, safe run-to-run modifications until the meal contents are adequately covered (i.e., until the system identifies an appropriate insulin dose that produces stable glucose levels in the desired range).

[0371] In other examples, to estimate the insulin sensitivity factor (ISF), the user can select a specified time (e.g., 4 hours) since their last meal and be asked to avoid exercise or other behaviors that would affect glucose levels. The system can then prompt the user to take a correction bolus. The system can then monitor the glucose response and use the response to determine the insulin sensitivity factor. In some examples, this process can be repeated two or more times until the correct ISF value is determined.

[0372] In some instances, a basal rate is determined first to allow for accurate estimation of ISF and ICR and ISF. In some instances, the decision support system can determine an appropriate time period for determining the basal rate, ISF, or ICR instead of, or in addition to, requiring patient involvement or cooperation.

[0373] The system can integrate various conditions and learn interrelationships of conditions. For example, the system can track exercise intensity and duration, glucose levels, insulin doses, and learn how exercise affects glucose sensitivity. The determined glucose sensitivity can be provided as guidance or used to determine other conditions or as input to algorithms to determine guidance. The system can also reference or build a nutritional database and link the database to the patient (e.g., tracking how the patient responds to a particular meal or type of food). The system can also track insulin sensitivity and patterns of insulin use, for example, to predict changes in insulin sensitivity or insulin use patterns. The system can also track a recent history of glycemic control, which can be used to predict future control, or the user's stress response that may affect insulin sensitivity (e.g., the body releases cortisol in response to stress, constituting the body's insulin resistance).

[0374] In one example, the system can learn when patients make treatment decisions and how patients and caregivers (e.g., data followers on smartphones) track the outcome of the decisions. The system can then predict when the patient is likely to make similar decisions and provide such information as guidance to help them make the decisions. The system can also predict the desired outcome and provide a confirmation notice (e.g., "Well done! Peak after breakfast was 140 mg / dL and is now stable and in range") or recognize that the desired outcome has not been achieved ("Still 220 mg / dL after 3 unit bolus at 7am and rising").

[0375] In some examples, the system can identify situations or patterns of interest (e.g., common situations such as meals, exercise regimens, or holidays) or receive identification of such situations or patterns from a user to create more precise guidance or timing of guidance for the identified situations that is more effective. For example, the system can obtain information about the identified situations by requesting user input or by overseeing "experiments" to allow for the collection of larger amounts of data or more precise data. The additional data can be used to improve the guidance or timing of guidance for the identified situations.

[0376] situation In some examples, the content and timing of the guidance can be determined by a state. For example, it can be determined to deliver guidance to consume carbohydrates in response to the occurrence of a particular glucose state, such as a glucose level or trend that meets a particular condition. In some examples, the state can be based on a combination of parameters, such as movement and glucose. For example, a "low glucose movement" state can correspond to a glucose level that meets a condition (e.g., a glucose level below a threshold) and predicted movement (e.g., from a pattern or calendar) or detected movement (e.g., from a physiological sensor or accelerometer). In some examples, the model can be based on multiple or multiple states. For example, the model can include one or more of a glucose state, an exercise state, a health / sickness state, and a sleep / wake state. In some examples, the system can combine or use multiple models to determine the guidance and when to deliver the guidance.

[0377] In some examples, state transitions can be detected using the model and used to generate guidance or notifications to the patient. Some physiological state transitions (e.g., sick / healthy) can occur over a period of days or weeks, while others can occur in hours or minutes (e.g., glucose levels or trends). In some examples, guidance can be delivered when state transition conditions are met. For example, if it is determined that the patient is trending to low glucose levels and is likely to transition to an exercise state or exercise soon (e.g., using patterns or based on park or gym location), guidance can give a partial carbohydrate consumption. In some examples, a combination of state transitions can trigger guidance (e.g., transitions from normal glucose to low glucose and transitions from sedentary to active / exercise state).

[0378] The probability of a state transition can be used to determine guidance, or whether and when to deliver guidance. For example, guidance may be determined and delivered when a probability of a transition to an undesirable state is detected. In some examples, guidance can be determined and delivered only if one or more additional conditions are met, such as when an availability state or a level of concern state meets specified conditions.

[0379] In some examples, the system can deliver guidance when a specified combination of state conditions are met or when a specified combination of state transitions occur or are calculated to be likely to occur. For example, guidance can be delivered when both glucose and exercise states meet specified conditions, e.g., guidance can be delivered when a low glucose state exists or is likely and the patient is about to exercise or has completed an exercise session. In some examples, the system determines the messaging frequency for providing insights or guidance based on state conditions, such as the engagement state of the host.

[0380] In some examples, the system may tailor guidance based on the severity of the situation, the level of concern, and the level of engagement. For example, the decision to withhold guidance or deliver guidance may be determined based in part on the behavioral model's concern or engagement state level at a particular time. If the level of concern or level of engagement is relatively low, delivery of guidance may be postponed until a time when the user is more available or more convenient for the user. In situations where the level of concern or level of engagement is high, guidance may be delivered even when inconvenient. For example, guidance regarding emergency situations may be delivered even if the user is in a meeting, but guidance regarding relatively routine (e.g., low concern / engagement) issues may be postponed until after the meeting. In this manner, the messaging frequency of insights and / or guidance delivered to hosts with engagement states indicating low levels of engagement may be reduced. This may prevent hosts with low engagement states from being overwhelmed with guidance. As the host's level of engagement changes, the frequency of guidance may also change. For example, the host may respond to an initial low frequency guidance by increasing engagement, such as reaching an engagement state indicating a higher level of engagement. If this occurs, the frequency may be increased. For example, the delivery of guidance may not be postponed and / or may be postponed for a shorter period of time than when the host is in an engagement state indicating a lower level of engagement, and when the host's engagement state changes to indicate a lower level of engagement, the frequency of delivery of guidance may be reduced.

[0381] Guidance Examples In various examples, the guidance is determined at least in part based on time. For example, the guidance can be based on clock time, or time of day (e.g., zones such as morning, afternoon, evening, night, etc.). Insulin sensitivity tends to vary based on several overlapping functions of time. For example, diabetic patients tend to be more insulin resistant in the morning due to factors such as other hormones secreted by the body in the morning. The guidance can be based at least in part on time of day to account for insulin sensitivity that varies over time. The guidance can also vary over time based on patient behavior, such as exercise routines, daily eating habits, meal schedules, etc. Other physiological parameters (e.g., stress, alcohol consumption, heat exposure, adrenaline-inducing events such as sports competition, etc.) can also be time-dependent.

[0382] In various examples, the determined guidance can include guidance on how to respond to a particular situation (e.g., a detected or predicted hypoglycemic event or hyperglycemic excursion), or more general guidance regarding treatment or action (e.g., the rate of change of insulin to carbohydrate for a particular meal (e.g., lunch) or to exercise in a particular time frame (e.g., "Consider taking a brisk walk after breakfast to increase insulin sensitivity").

[0383] In some examples, information determined from physiological or behavioral models can be used to suggest alternative approaches to common patterns. For example, the system can determine that the user tends to over- or under-correct in certain situations, such as at certain times or after certain meals, and guidance can be provided when the system detects a pattern associated with correction errors. In some cases, the system can simulate what would happen with an alternative therapy approach or compare historical approaches. For example, an alternative approach can be provided as guidance after an over- or under-correction occurs. In other examples, predictive trends can be presented for a proposed action. For example, the user can input a proposed insulin dose or snack or meal via a user interface, and the system can display a predictive trend. In the example shown in FIG. 27A, the user can be presented with a user interface 2702 including a scroll dial 2704 that can enable selection of a carbohydrate amount, and the system can present a predictive trend 2706 showing likely outcomes from a snack containing the selected amount of carbohydrates. In another example, as shown in Figure 27B, the user can input a suggested carbohydrate value, a suggested insulin dose, and the system can present a user interface 2720 showing three curves, one curve 2708 for the scenario where carbohydrates are taken but insulin is not administered, one curve 2710 for the scenario where insulin is administered but carbohydrates are not taken, and an estimated glucose value curve 2712 for when both glucose and insulin are administered. In some examples, the dial shown in Figure 27A can be provided on the user interface 2720 shown in Figure 27B. The predicted insulin trend is shown as a line, although in other examples, a probability cone may be shown instead of a line.

[0384] In some examples, the system may provide guidance for a level of readiness at night to ensure the user is not prone to low glucose levels at night, reduce nighttime alerts, reduce nighttime hypoglycemic events, and provide comfort to the user at night. To develop long range (e.g., 6-10 hours) or reliable predictions for states or state transitions, the system may obtain more information from the patient or sensors or perform additional processing to increase the likelihood that the guidance will allow for a full night's sleep without interrupting to eat or deliver insulin. The nighttime readiness feature may provide guidance to take actions before going to bed, such as, for example, eating carbohydrates or administering insulin before going to bed.

[0385] In some examples, the system can exchange data with a clinical supervision platform. The system can provide, receive, or exchange sensor data, patient data, or prescription or dosing information with the clinical supervision platform. In some examples, the guidance can be checked (e.g., by a human clinician or an algorithm) against the clinical supervision platform before the guidance is delivered to the patient. In some examples, the guidance, and optionally also data such as the resulting blood glucose curve, can be provided to the clinical supervision platform after delivery to the patient, allowing adjustments or feedback from the clinician, such as changes in insulin type, dosage, timing, or allowing for the formation or optimization of future guidance.

[0386] In some examples, the decision support system can include a diabetes management supervisor that can be configured to provide overall guidance or feedback. The diabetes management supervisor can, for example, quantify diabetes management overall. This can include metrics of effectiveness of control of estimated blood glucose levels measured against specified conditions, criteria, or standards such as a measure of time (e.g., percent) in a specified blood glucose range.

[0387] Treatment parameters The decision support system may also provide guidance regarding treatment parameters. For example, the system may identify when changes in basal rate, ICR, ISF, or IOB are necessary. The system may also request testing, for example, if the type or amount of required change cannot be identified within a specified metric (e.g., confidence level). Real-world data may pose the following challenges to determining treatment parameters: In theory, if the basal rate is correct and the ISF is known (or is assumed to have a known relationship to other treatment parameters), the bolus can be determined with acceptable accuracy. Similarly, if the ICR and ISF are correct and carbohydrate estimates are assumed to be accurate (at least on average), the basal rate can be fine-tuned within acceptable limits. However, real-world conditions may be filled with uncertainties, complexities, and overlapping elements, and errors may exist in all parameters, making the ideal scenarios described above rare or difficult to recognize. To address this systemic complexity, the decision support system may include models or algorithms that learn or detect specific basal rates, ICRs, ISFs, or insulin onboard periods that are inappropriate from collected data. In some examples, parameters can be determined retrospectively from days or weeks of data, and the determined parameters can be evaluated for accuracy as additional data is collected. The decision support system can also use models or algorithms and learned parameters or historical data in combination with real-time or recent data to generate guidance and calculate the time to deliver the guidance.

[0388] In one example, in noisy data with multiple overlapping effects, an inappropriate basal rate can be identified by identifying one or more patterns of repeated lows or highs over a specified time (e.g., 4 hours) after a meal (i.e., after the effects of food and reduced basal dose). Similarly, an inappropriate ICR can be identified by identifying repeated low or high glucose levels over a specified time (e.g., 2-4 hours) after a meal (while food and basal insulin are still active) in incidents where the repeated lows / highs did not occur for longer than a second specified time (e.g., 4 hours) after the same meal (suggesting that the basal rate is correct).

[0389] The decision support system can take into account whether low or high glucose levels occur with different amounts of carbohydrates, correction factors, or initial glucose levels. In one example, if the glucose level is within range before the meal (e.g., without an on-board correction bolus) but out of range after the meal, the error may possibly be due to an improper ICR. In some examples, glucose trends of meals with different characteristics can be compared to verify or improve inaccuracies detected in the ICR. For example, if a collection of patterns of low-trending glucose levels reveals that the more carbohydrates there are, the faster the glucose level trends or the lower the glucose level, it can be inferred that the ICR is likely too high (i.e., too much insulin is delivered due to a high ICR, and the effect of a high ICR is amplified with the amount of carbohydrates, resulting in a faster low glucose trend or lower glucose levels). Similarly, if a collection of patterns of trending high glucose levels reveals that the higher the carbohydrate count, the faster or higher the glucose levels rise, it can be inferred that the trend for high glucose is likely due to an ICR that is too low (i.e., not enough insulin is being delivered, resulting in high glucose levels, an effect amplified as the carbohydrate count increases).

[0390] Insulin Sensitivity Factors In another example, the decision support system can provide guidance regarding insulin sensitivity. For example, the system can track and report insulin sensitivity or changes or trends in insulin sensitivity. The decision support system can also provide fault detection (described further below) to assist the user in determining whether a problem is caused by a treatment parameter or a system fault (e.g., to distinguish an insulin sensitivity problem from a hardware failure problem). Guidance regarding insulin sensitivity can be particularly useful when a patient experiences changes in insulin sensitivity. For example, during "normal" conditions, a patient's diabetes can be well controlled by estimating and using "treatment" parameters such as basal rate, ICR, ISF, and insulin time action. However, stress, illness, changes in athletic activity, hormone cycles, etc. can cause changes in insulin sensitivity, altering the effects of insulin in the body and also affecting many or all of the "treatment" parameters (ICR, ISF, etc.), which can have a dramatic effect on the patient's glucose levels. In one example, in noisy data with multiple overlapping effects, the decision support system can identify an improper ISF based on the occurrence of low or high instances for a specified time (e.g., 2-4 hours) after a correction bolus in the absence of a detected basal error or a detected ICR error. For example, the system can identify an erroneous ISF from a pattern of low (or high) glucose levels after a correction bolus that is not responsive to a meal error. In another example, if glucose levels are low (or high) after a meal with a correction bolus, but there is no glucose excursion after a meal without a correction bolus, the system can determine that an erroneous ISF is likely due to the occurrence of low or high instances after a meal with a correction bolus, but there is no glucose excursion after a meal without a correction bolus.

[0391] To detect changes in insulin sensitivity, the decision support system can use models or algorithms that can identify changes in glucose patterns in real time (using retrospective data). In some examples, the decision support system can use models or algorithms to distinguish between different types of changes in glucose patterns (e.g., insulin sensitivity, insulin delivery issues, sensor issues, etc.). For changes in insulin sensitivity, the decision support system can suggest appropriate percentage changes to all "treatment" parameters. The system can identify when insulin sensitivity returns to baseline and suggest returning the parameters to baseline. The system can distinguish between normal and abnormal conditions, such as normal and altered ISF caused by stress, or normal and abnormal insulin infusion conditions. In some examples, the system can detect changes using various data sources (sensor glucose readings, sensor raw data, fingerstick data, insulin, carbohydrate, pump occlusion alarm parameters, date of last infusion set change) and provide guidance based on recognized patterns in the data.

[0392] Fault Detection Additionally, system “faults” such as insulin delivery problems (e.g., injection site problems) or sensor problems can cause unexpected changes in glucose patterns. Decision support systems can use models or algorithms based on patterns of glucose or other data to identify faults. Identifying the beginning and end of such fault states can help patients and their physicians take appropriate measures to keep glucose levels within acceptable limits and avoid changes in other factors (e.g., ISF) to address glycemic fluctuations in the event of an unrecognized system fault that is causing glucose control problems.

[0393] In some instances, the decision support system may identify instances of repeated low, high, or out-of-range values ​​that cannot be reliably attributed to the ICR, basal rate, or ISF and that do not prompt a basal, ICR, or ISF "test," and provide additional, less overlapping, impactful data to allow parameter setting issues to be more accurately estimated.

[0394] Setting your insulin pump basal rate In some instances, the decision support system can assist in setting and fine-tuning the basal rate of the insulin pump. Basal rates can vary significantly throughout the day. For example, a relatively high basal rate may be needed early in the morning, while a lower basal rate may be needed in the afternoon. Some insulin pumps allow different basal rates to be set every 30 minutes, allowing for 48 basal rate parameters per day. The initial setup of these parameters can be very time consuming and there can be a lot of uncertainty in the first dose. Without a proper basal rate, it is very difficult to estimate the ICR and ISF parameters and learn these parameters retrospectively. CGM data can be particularly helpful in fine-tuning the basal rate parameters, as consecutive measurements can help pinpoint the exact times when different basal rates are needed. In some instances, the system can use the CGM data or blood glucose patterns to determine basal rate adjustments.

[0395] In various examples, the decision support system can combine the CGM data with other data to determine or refine the bolus rate. For example, the decision support system can evaluate estimated glucose levels received from the CGM sensor during the night, or during periods when other factors are not affecting the glucose levels determined from the sensor or behavioral data, to determine guidance regarding adjustments to one or more basal rates. Overnight determinations may be more accurate or easier to determine because the issue of basal rate adjustments is not complicated by diet or physical activity. In some examples, the decision support system guides the patient through a testing protocol that limits the number of variables that may affect glucose levels (e.g., limiting or adjusting exercise, stress, and carbohydrate consumption), allowing for accurate determination of basal rates.

[0396] Multiple daily injections In some instances, the decision support system can determine guidance for multiple daily insulin injections. The body's insulin needs can vary widely during the day. For example, secretion of hormones that affect hepatic glucose secretion (e.g., glucagon secretion by the pancreas) and secretion of hormones that increase insulin resistance (decreasing insulin sensitivity) can cause fluctuations in insulin needs. For example, a pattern called the dawn phenomenon tends to increase insulin levels in the morning. This can be caused, for example, by secretion of growth hormone and other hormones that increase blood glucose levels, dietary problems, or the body's response to nocturnal hypoglycemia (the Somogyi effect). These effects can be present in any patient, but can be particularly challenging in patients who use multiple daily injections (MDIs) of insulin, because there is a finite number of times per day that insulin can be injected and a practical lower limit on the size of the dose that can be delivered.

[0397] Decision support systems can provide guidance (to patients or clinicians) regarding the size, type, and timing of insulin injections. Patients who use multiple daily insulin injections (MDIs) can use one or more days of long- or intermediate-acting insulin injections to provide insulin in the background for 24 hours. The timing and dosage of intermediate or long-acting insulins vary by the insulin action (how quickly the insulin begins to act), peak, and duration of action, which can vary with insulin type and dose size. Long-acting insulins (such as insulin glargine and insulin measurements) can provide a relatively stable flow of insulin and a consistent absorption pattern. Intermediate-acting insulins can provide peak and intermediate durations of action and can help address patterns of insulin demand. For example, NPH insulin is an intermediate-acting insulin that can provide background insulin for up to 24 hours, but is much more effective (i.e., more insulin is present in the bloodstream) from 4 to 8 hours after injection and less effective from 16 to 24 hours after injection.

[0398] Intermediate-acting insulins such as NPH can help counter the dawn phenomenon. It is important to time the delivery of NPH to match its peak action to peak basal needs. Additionally, when using intermediate-acting insulins, it may be important to eat at specific times or to fit a meal schedule to avoid lows at specific times (e.g., when insulin action peaks). Managing glucose levels can be further complicated because some insulins may be absorbed at different rates on different days or may have unpredictable peaks.

[0399] Various forms of long-acting or intermediate-acting insulin can be combined to simulate the body's basal insulin secretion pattern (such as in the absence of diabetes). For example, it may be useful to combine glargine or detemir once daily at night with NPH, at a lower dose to better match the body's basal requirements. However, the insulin coverage provided by intermediate- or long-acting insulins or combinations often does not adequately match the body's basal insulin needs, so fine-tuning and careful timing of insulin delivery and meals may be important. It may also be important to accommodate day-to-day variations.

[0400] The decision support system can provide guidance in determining insulin dosing and timing to address recognized patterns (e.g., dawn phenomenon). The system can also provide guidance in addressing day-to-day variations. For example, the decision support system can detect one or more patterns from retrospective data that suggest a multiple daily injection regimen is not adequately meeting a person's basal insulin needs. This information may be provided to the patient or to a clinician who may recommend a change in dosage or regimen, or prescribe a different type or brand of insulin. In some examples, the decision support system can operate as a communication tool between the patient and clinician, allowing the clinician to better understand insulin and glucose patterns (e.g., the system can provide guidance that a patient experiences low insulin on weekend mornings when breakfast tends to be later).

[0401] In some examples, the decision support system can provide tools to identify mismatches between intermediate and long-acting insulin absorption rates and basal insulin needs. For example, the mismatch can be determined from patterns of high or low glucose levels. In some examples, the decision support system can take into account other factors, such as exercise and eating, so that patterns can be identified from noisy data. In some examples, the decision support system can identify recurring events, such as hypoglycemia or hyperglycemia caused by inadequate coverage of basal needs, and provide guidance on possible solutions (e.g., eating at specific times of the day or considering changes in dosage or injection timing).

[0402] In some instances, the decision support system can identify a particular phenomenon of interest, such as the dawn phenomenon or the Somogyi phenomenon. In some instances, the decision support system can suggest a correction or suggest a physician inquiry. For example, the Somogyi phenomenon can be addressed by lowering the basal insulin dose, and the dawn phenomenon can be addressed by using an NPH insulin that peaks in the morning or by using a rapid-acting insulin in the morning.

[0403] In some examples, the decision support system can identify when basal needs are not being adequately met by any combination of MDI therapies. In some examples, the decision support system can provide an indication of the success of basal therapies. The decision support system can, for example, evaluate whether stable blood glucose levels are achieved during sleep (e.g., a change of 30 mg / dl or less, assuming no complicating factors are present, such as if the patient did not eat, took fast-acting insulin, or exercised shortly before sleep).

[0404] The decision support system can also determine when a single basal injection is insufficient (based on glucose levels and time of injection) and determine guidance to consider (e.g., query a clinician) for additional injections (e.g., injecting basal insulin twice a day to achieve a "two-wave" pattern of insulin action) or introduction of other types of insulin (e.g., adding intermediate-acting insulin). The decision support system can include basal testing functionality (e.g., an application operable on the smart device) and can identify when basal testing is necessary or recommended. Basal testing can include, for example, periods of relative inactivity and periods of fasting or highly predictable or controlled eating to reveal underlying basal needs. In some examples, the system can also determine guidance on how basal requirements can be matched by behavior, such as, for example, combinations of basal injections, or injections combined with meals, or exercise.

[0405] Predicting future blood glucose levels In some examples, the decision support system can predict blood glucose levels in advance for a specified period of time (e.g., 30 minutes, several hours, or 6 hours). Predictions of blood glucose levels can be based on, for example, meal information (e.g., amount consumed, time consumed, carbohydrate and fat or protein content, absorption rate (fast, medium, slow carbohydrate), food estimate reliability), bolus information (time, insulin action, and bolus type (regular or dual wave), basal rate, exercise, CGM data, blood glucose levels (e.g., fingerstick data), alcohol consumption, stress factors (e.g., behavioral or calendar based), or time of day.

[0406] The decision support system can predict blood glucose levels in real time to provide advance notice of potential hypoglycemic or hyperglycemic events before they occur. The predicted glucose levels may be used, for example, to generate warnings or alerts to the user. The predicted glucose levels can also be used to provide early guidance to provide a correction bolus before a hyperglycemic event occurs or before the patient becomes insulin resistant due to high glucose levels.

[0407] The decision support system may also retrospectively or hypothetically determine predicted glucose levels to evaluate treatment or model parameters (ensuring that the model parameters are stable). In some examples, the system may compare predicted values ​​to actual values ​​to evaluate model parameters.

[0408] In some examples, if the system has high confidence in the model (e.g., model parameters have been evaluated for validation or accuracy), it can use the model to test scenarios and predicted outcomes and evaluate whether the patient or clinician should consider adjusting treatment parameters such as insulin-to-carbohydrate ratio or insulin sensitivity factor. For example, the system can run various "tests" against the model that may be burdensome or time-consuming for the patient to actually perform (because food, activity, or insulin delivery must be tightly controlled), and use the results of the tests to determine guidance or timing of guidance, or to select one or more tests for the patient to actually perform (e.g., deliver guidance "Insulin-to-carbohydrate ratio may not be correct: perform test at next meal" or "Basal rate may not be correct: perform fasting basal test as soon as possible"). In one example, the system can determine what happens (according to the model) if a meal is not ingested. If the predicted blood glucose level rises, a higher basal rate may be needed, and if the predicted blood glucose level falls, a lower basal rate may be needed. In another example, if the basal rate is assumed to be correct, the system can determine what will happen if a meal is ingested: if the predicted blood glucose level returns to the target glucose level after a specified time (e.g., 4 hours) after the meal, the ICR can be considered correct. If not, the ICR can require adjustment (e.g., if the underlying basal rate is assumed to be correct, high glucose levels more than 4 hours after a meal suggest that the ICR is too low). In another example, the system can determine what will happen if a specified amount (e.g., 1 unit) of insulin is given, assuming the basal rate is correct, and the system can use this information to suggest updating the insulin sensitivity factor. In another example, the system can assume a normal absorption meal and a correct basal rate, and the system can determine when the predicted glucose level reaches a stable value and use this to determine the duration of insulin on-board.In some examples, the decision support system can use the model to predict recurrent low or high glucose levels (e.g., using time based on patterns observed over time). In some examples, the decision support system can use the model to identify the Somogyi phenomenon or the dawn phenomenon.

[0409] Bolus determination The decision support system can develop guidance for the delivery of insulin boluses. For example, the system can also include a model or curve-based correction bolus calculator. The system can estimate an individual-specific post-meal curve, including curve estimation parameters such as peak time, carbohydrate-dependent peak height, and curve "width," based on factors such as meal content and insulin dose and duration. In some examples, the decision support system can first go through a learning period to collect data to estimate the curve. The decision support system can use the curve estimation in real time to predict deviations from the meal curve estimate. Deviations from the predicted curve can be used to predict and avoid hypoglycemic events or to predict and treat potential hyperglycemic fluctuations. In some examples, two or more estimated curves can be combined to account for meal overlaps. Corrections can also be made to take into account deviations caused by exercise or other factors. In some examples, a similar approach can be applied to blood glucose prediction models, where guidance is based on deviations from the model rather than deviations from the curve. For example, deviations from the output expected by the model can indicate that the input parameters (e.g., meal size) were incorrect and that appropriate corrections (e.g., re-estimation of meal size or delivery of a correction bolus) are required. The detected deviations may be provided as guidance, or additionally or alternatively, remedial steps (eg, re-estimating meal size or delivering a correction bolus) may be suggested as guidance.

[0410] motion Exercise can affect blood glucose levels immediately (e.g., almost immediately) and can affect blood glucose levels for up to 48 hours after the exercise is completed. The decision support system can provide recommendations on what to do before, during, or after exercise. For example, the decision support system can provide guidance on treatment parameters to account for the effects of exercise. The decision support system can also retrospectively learn and improve exercise recommendations. In one example, the system can receive an exercise plan from a user (e.g., a patient) that can include the type of exercise to be performed, the intensity of the exercise, and the duration of the exercise, and the system can create and deliver guidance based on the received exercise plan. In one example, the system can provide guidance that the patient will need a particular size snack. If the exercise is pre-planned (e.g., communicated to the decision support system) at least one hour in advance, the system can suggest a temporary basal rate to account for the effects of the exercise. The system can also suggest possible temporary basal changes if the exercise lasts (or takes place) for more than one hour. Because exercise can increase blood glucose (e.g., due to adrenaline secretion causing glycogen release) or decrease blood glucose (due to activity), the system can take into account the type of exercise (e.g., competition vs. training). In some examples, the effects of exercise can be monitored using CGM or other sensors, and changes in treatment strategy can be learned on a "case-by-case" basis (e.g., intense morning runs vs. leisurely afternoon cycling) to improve guidance and outcomes over time.

[0411] In some examples, the system can identify optimal temporary basal percentages for various types of exercise, intensities, durations, and start times, and deliver guidance that reflects this knowledge. The system can also identify optimal meal contents (e.g., carbohydrate amount and type, or fat content) for various types of exercise, intensities, durations, and start times. In some examples, the system can also determine percent activity adjustments for input into a bolus calculator.

[0412] Example Timeline FIG. 3A is an illustration of an exemplary timeline 300 associated with a patient. It is assumed that the patient engaged in an activity for a period of time, followed by a meal, and insulin was delivered. After the meal, the patient is available for a period of time, followed by a meeting, then another availability period, followed by another meeting. The decision support engine can take into account the patient's schedule in determining when to deliver guidance and what guidance to deliver. For example, through access to the patient's calendar or through learning the patient's temporal patterns from the data, the decision support engine can recognize a period of availability after a meal and before a meeting, and deliver guidance during this availability period accordingly. The guidance can also take into account an upcoming meeting and the length of the meeting to determine guidance calculated to avoid interruptions during the meeting. For example, the decision support engine can suggest a correction bolus large enough to control insulin while managing the risk of low glucose levels occurring during the meeting. In another example, the decision support engine can suggest a pre-meeting snack to maintain glucose levels through the meeting. In some examples, if the decision support engine knows (e.g., through a user-specified setting) that it is easier to consume a small snack during a meeting than to manage insulin (e.g., if the patient injects insulin using a needle or pen), it may err on the side of allowing glucose levels to drift low. On the other hand, if it knows that it is easier to administer insulin than to consume a snack (e.g., if the user receives insulin via a pump), the guidance may be determined to err on the side of a high glucose trend.

[0413] FIG. 3B is an illustration of an example schedule for a caregiver (e.g., parent) (top) and a pediatric patient (bottom). In one example, the decision support engine can recognize periods of caregiver availability and periods of caregiver absence or unavailability from calendar information, user input, sensor information (e.g., GPS), or learned patterns. The decision support engine can determine guidance to increase the likelihood of stable glucose levels when the caregiver is unavailable. The decision support engine can also determine the time to deliver guidance based on the caregiver's availability, for example, providing guidance during an availability period early in a basketball game, or deferring guidance until an availability period at the end of the game (if possible).

[0414] 3C is a diagram of a patient's awake / sleep states. The decision support engine can determine when to deliver guidance when the patient is awake, e.g., before sleep, or during awake hours at night, as can be determined using, for example, activity or other sensors on the watch, a fitness tracker, or other wearable or patient-aware device.

[0415] FIG. 3D is an illustration of determining a patient's availability (or convenience) to participate in an intervention based on other conditions. Initially, the patient is asleep and unavailable. Once sleep is over, the patient is available (as determined by schedule information, GPS, or connectivity via in-vehicle wireless connectivity) until the commute begins. Once the commute is over, the patient is available until the meeting begins. Once the meeting is over, the patient is available again. Deciding on the timing of guidance

[0416] 4 is a schematic diagram of a guidance decision. A guidance decision module 402 can receive input 404 and determine one or more outputs 404 related to guidance. The decision module 402 can include a model or pattern to which the input 404 is applied. In some examples, the decision module can include or be part of a behavioral model. The input can be determined by state outputs from other applications or models such as physiological or behavioral models.

[0417] The user's availability can be received as an input. Availability can include, for example, availability of a schedule determined by a calendar, a learned or known pattern, a user input, or inference. Availability can include actual availability or accessibility (such as a communication connection or type of connection), or user convenience, which can be determined or inferred from user activity, for example. The time until the next period of availability can also be received as an input, and can be determined, for example, from a known, inferred, or user-provided schedule or a determined pattern of availability. If availability is relatively low or inconsistent, it can favor determining and delivering guidance during the period of availability. A short wait until the next availability period can favor not delivering guidance during the current availability window because another availability window will open soon. A long wait until the next availability period can favor delivery of guidance during the current window because if guidance is not delivered in the current window, a long wait would be required to deliver the guidance or the system would interrupt the user at an inconvenient time.

[0418] The urgency of the action may also be received as an input. The urgency of the action may depend, for example, on the patient's physiological state or the nature of the guidance, or both. For example, the urgency of the action may be high if the user is trending rapidly toward low blood glucose values, especially in situations where the user may not notice the trend. The urgency of the action may be medium if the user is trending slowly toward low blood glucose values, or if the user is trending toward high blood glucose values ​​at a moderate rate. If the action is desired, the urgency of the action may be relatively low, but the physiological risk to the patient is low. In other examples, the urgency of the action may be determined to be high if carbohydrate intake is required to avoid low blood glucose values, medium if an injection of insulin is required, and low if a test (e.g., finger prick blood glucose test, or temperature or heart rate) is required to confirm the physiological state or to calibrate a sensor (e.g., calibrate a glucose sensor). High urgency to act can favor delivery of short-term guidance, whereas low urgency can favor waiting until a future period of availability, e.g., to avoid guidance fatigue or excessive interruptions by the user.

[0419] The length of the period of the valid behavioral period may also be received as an input. In one example, it may be determined that carbohydrate intake is required within a short period (e.g., a 5 minute period or a 10 minute period). In another example, it may be determined that insulin injection is required within a medium period (e.g., a 20 minute period). In some examples, the period may be a fuzzy input, e.g., the exact length of the period may not be precise. In some examples, the general size of the behavioral window may be understood as reflecting the variability of the behavioral window of the therapeutic or sensor input behavior.

[0420] A level of concern may also be received as an input. A patient's or caregiver's level of concern may vary by patient / caregiver and by the particular situation. The level of concern may be determined, for example, using patient-provided information, learned from data, or received from a model (e.g., a behavioral model). A high level of concern by a particular user or about a particular situation (such as a combination of physiological conditions) may favor a shorter-term decision and delivery of guidance, while a low level of concern may favor a delayed decision and delivery of guidance. Engagement may also be received as an input. As described above, the level of engagement may be determined from the user's responsiveness to alerts or guidance, including, for example, the frequency or consistency of checking sensor data (e.g., blood glucose level), or the method of engagement (e.g., displaying notifications only vs. full data, or watch vs. smartphone vs. computer). In some examples, a high level of engagement (suggestions of concern, availability, or alertness) by a particular user may favor a shorter-term decision and delivery of guidance, while a low level of engagement may favor a delayed decision and delivery of guidance. In other words, to some extent, availability or level of concern may be inferred from the involvement. For example, a low level of involvement may result in less frequent guidance, e.g., to avoid overwhelm the user. In other examples, a low level of concern by a particular user or regarding a particular situation may favor shorter-term guidance decision and delivery, e.g., because it may be determined that the user may not be aware of potential problems due to lack of involvement, whereas a high level of concern may favor deferred guidance decision and delivery, e.g., because the user is already aware of potential problems and is highly involved in monitoring or resolving the problems.

[0421] Two or more inputs may be used together to determine the time to determine guidance, the time to deliver guidance, the form of guidance, or a combination thereof. The time to determine guidance and the time to deliver guidance may be related, for example, guidance may be determined shortly before the time to deliver guidance to ensure that the determined guidance reflects the latest real-time data. In one example, the time for determining guidance may be delayed, for example, if the length of the effective behavioral period or the time until the next availability period is relatively long, to allow for the collection of additional data to improve the accuracy of the guidance or the state for which the guidance is determined. In some examples, guidance may be determined earlier if a relatively short window of availability is opening or approaching, even though additional data would normally be desired to obtain an accurate interpretation of the physiological state to enable delivery of guidance (and the time for which the guidance acts) before the window closes. In other examples, guidance may be delayed if the time until the next window of availability is relatively short. In some examples, the decision module applies weights to factors to determine whether or when to determine guidance. In some examples, the decision module determines a predicted future state or interacts with other modules or models (e.g., physiological models) to determine a predicted future state, balancing various inputs against physiological risk. In some examples, the decision module receives inputs for a future number of times or determines a predicted future state and determines an acceptable or optimal time or range of times for determining or delivering guidance. For example, the module may determine that guidance is not needed at the current time (e.g., 4:00 PM), but that guidance should be delivered in the future (e.g., 6:00-6:30 PM). In some examples, the module may reevaluate the decision as new information becomes available, such as when the urgency of the action changes in response to a change in physiological state, or as the level of engagement changes, or as the schedule or pattern of availability changes.

[0422] Figure 5A 5A is a flow chart illustrating an example method 500 for delivering guidance, such as physiological glucose concentration management guidance, which may provide guidance to facilitate delivery of a therapy, such as insulin delivery, carbohydrate intake, or physical exercise to manage glucose levels in a diabetic patient.

[0423] In step 502, real-time data associated with the patient is measured, determined, or received. The real-time data can be, for example, measurements from a glucose sensor, for example, real-time data received from a continuous glucose monitoring system that intermittently measures glucose levels and provides glucose level information via a network connection. In one example, the user is determined to have just eaten a particular meal (e.g., 60 g of carbohydrates), for example, by meal detection, user input, or other pattern detection. In another example, the user is determined to be about to perform a weekly run, as determined by pattern recognition of calendar entries. In other examples, the real-time data can also be time, deviations from expected behavioral patterns, changes in state (e.g., changes in physiological state determined using a model), an indication that a mealtime is imminent, time of day, a characteristic or signature signal measured by an accelerometer, a location determined by a GPS circuit, or a request for decision support received via a user interface. In various examples, the first real-time data can be measured, received, or determined by a smartphone, determined by a wearable device such as a wristwatch, or determined by a wearable device in combination with a smartphone. In some examples, the first real-time data can be measured, received, or determined by an external device, such as a computer.

[0424] At 504, a state of the patient is determined. The state can be determined using the model and the real-time data, for example, by applying the real-time data to the model.

[0425] The model may include, for example, a state indicative of the patient's convenience or availability to participate in an intervention. For example, information (e.g., availability) from a calendar associated with the patient or associated with a caregiver may be applied to the model. In some examples, sensor information (e.g., accelerometer information indicative of activity level) or pattern information (e.g., indicative of wake / sleep cycles or periods of exercise or passing periods, e.g., driving) may be applied to the model. A state indicative of the availability or convenience of performing an intervention, such as administering insulin, consuming carbohydrates, or participating in physical activity, may be determined by applying real-time data to the model. In some examples, the model may include a physiological model of the patient, and the determination of the patient's state may be based on applying at least the first real-time data to the physiological model of the patient. In some examples, the state is insulin sensitivity. In one example, exercise is detected, and insulin sensitivity is determined based on a known pattern of the user's glycemic response to exercise.

[0426] The model may additionally or alternatively include a behavioral model. The behavioral model may be based on, for example, one or more machine learning characteristics of the patient. The one or more machine learning characteristics may be based on behavioral or contextual patterns. In some examples, the behavioral model may be based on a set of one or more steps determined to be likely to be performed by the patient, or one or more goals determined to be likely to be achieved by the patient, or both.

[0427] In some examples, the behavioral model can include a pattern. In an exemplary configuration, the patient's physiological model is based on physiological patterns and the behavioral model is based on behavioral patterns. In some examples, the first real-time data can indicate a deviation from an expected behavioral pattern. For example, the first real-time data can indicate a mistimed meal, a missed, early, or late insulin dose, a change in physical activity (e.g., inactivity or atypical exercise), or an early or late awakening. In some examples, the behavioral model can indicate a tendency to overcorrect at meals associated with a mealtime, the first real-time data can indicate that a mealtime is imminent, and the guidance message can correspond to a decrease in undercorrection at the mealtime (e.g., a smaller insulin dose or a different combination of basal and bolus doses).

[0428] In some examples, the behavioral patterns can include long-term behavioral patterns based on long-term behavioral patterns and short-term behavioral patterns related to current behavior. The behavioral model may be based on both the long-term behavioral patterns and the short-term behavioral patterns. In some examples, the short-term behavioral patterns can be based on one or more selected from the group consisting of engagement with the mobile device, accelerometer data, frequency of checking glucose levels, calendar data, and combinations thereof.

[0429] In some examples, the determination of the state can also be based on a measurement model. For example, the measurement model can be based on a continuous glucose concentration monitoring system associated with the patient. The measurement model can include, for example, accuracy or other conditions related to the glucose measurement. In some examples, the method 500 can also include measuring glucose concentration data after providing the guidance message and using the measured subsequent data to improve one or more models. For example, the glucose concentration data measured subsequent to the provision can be fed back into the measurement model or the behavioral model or the patient's physiological model, or a combination thereof.

[0430] At 506, a personalized guidance message can be determined based at least in part on the determined state. The personalized guidance can be, for example, a treatment recommendation, such as instructions to administer a particular amount of insulin (e.g., 1 unit) or instructions to consume a food containing a particular amount of carbohydrates (e.g., 5 grams of carbohydrates). In some examples, the guidance message can be based at least in part on a predicted transition to an undesirable physiological state, such as a high glucose level or a low glucose level. Determining the guidance message can be further based on timing to determine a time associated with the guidance message or the determined state. For example, the personalized guidance message can be based on timing information obtained from a calendar, or a pattern or model of upcoming events. The guidance message determined at step 504 can provide glucose administration information or carbohydrate consumption information, or preparation for an upcoming event or notification information to the user, such as "consider administering insulin before the next meeting in 2 hours" or "consume carbohydrates before commuting to avoid possible blood glucose drops during the commute." In some examples, the guidance message can be based at least in part on a determination that the predicted transition from the current state to the predicted state is a low probability transition. For example, state transition probabilities can be known or learned from data, and real-time and other data can indicate that conditions for low probability transitions exist. This determination can form the basis of guidance to the patient and can be particularly useful in situations, for example, where the decision guidance engine can provide warnings about risks of which the patient may not be aware.

[0431] In some examples, the system detects a missed exercise session, or a missed series of exercise sessions, or a trend toward shorter or fewer exercise sessions. A patient's physical exercise tends to increase metabolic drive, which can increase glucose consumption. Missed or reduced exercise sessions can result in a decrease in metabolic drive and a reduced need for calories, or an increased need for insulin to compensate for the low metabolic drive.

[0432] The decision guidance engine can also recognize other patterns such as a confluence of factors, e.g., higher than normal activity and lower than normal food consumption, or stress inducers or lack thereof, travel, sleep disturbance, illness / health, or atypical meal times, and determine that a low probability (given normal state) state transition (e.g., from a normal high or low blood glucose value) is likely to occur. Such a determination can lead to guidance decisions such as "You are likely to experience an atypical low blood glucose value tonight," "You are likely to experience an atypical high blood glucose value this morning," "Your insulin needs today are likely to be higher than normal." The guidance can provide details regarding the guidance reasoning (e.g., "...because you missed several workouts") or simply inform the user about the physiological results.

[0433] At 508, the guidance message can be provided to a user, such as a patient or a caregiver, via a user interface, such as a screen or speaker on a mobile device, a speaker or display on a vehicle, etc. In some examples, the manner or time of delivery of the guidance message can be determined in part by time (e.g., clock time or time of day), for example, to account for the patient's work, sleep, meal, or commute schedule. In one example, providing the guidance message can include displaying a recommended treatment when calculated to be useful to the user. In one example, the guidance message can be provided before a scheduled event, such as a meeting. For example, if it is known that the user will be attending a three-hour meeting, treatment recommendations can be presented before the meeting, rather than waiting for more accurate recommendations to be made or determined. In other examples, providing the guidance message can include providing a message when calculated to be useful to the user. For example, when a user is about to go out for a regular run, a guidance message with a treatment or monitoring recommendation can be provided before the run begins, as opposed to when the user is prone to low blood glucose levels.

[0434] Figure 5B 5B is a flow chart diagram of an exemplary method 501 for determining and providing a calculated guidance message that, when calculated to be useful to a patient, is personalized and useful to the patient in managing the care of his or her diabetes. The example described with reference to FIG. 5A can also be applied to the method of FIG. 5B.

[0435] At 501, the method may include measuring, determining, or receiving first real-time data associated with the patient. The first real-time data may be, for example, a glucose concentration value received via a user interface (e.g., via a smartphone app), a time of day, meal information, a request for advice, activity information (e.g., from a fitness tracker or watch), or insulin delivery information, which may be received via a user interface or from a smart device such as a pen or pump.

[0436] At 503, the method may include determining a state of the patient using the model. For example, the determination may be based on a physiological model, a behavioral model, and a measurement model of the patient. The state may be determined by applying the real-time data to the physiological model and the behavioral model of the patient. The physiological model of the patient may be a state model including, for example, one or more of a glucose concentration state, an insulin on-board state, an insulin sensitivity state, an energy absorption state, or an energy motion state. The particular state may be determined by available input features (e.g., time of day, glucose level, previous activity, etc.).

[0437] At 505, the method may include determining a guidance message. The guidance message may be personalized for the patient based at least on the determined condition.

[0438] At 507, the method can include providing the determined personalized guidance message via a user interface such that the delivery occurs when calculated to be helpful to the patient in managing their diabetes care. Providing the determined personalized guidance message can include providing the personalized guidance message on a user interface.

[0439] The method may also include learning the model from a set of input data. The set of input data may include clock time, time of day, glucose concentration level, insulin on board, patient activity, patient health, day of the week, day of the month, day of the year, location, food consumed, or beverage consumed, and information received via a user interface. Other input data are possible, including, for example, the information described with respect to Figures 2B and 14-16.

[0440] Training the model can occur before or after receiving the real-time data. For example, the method can further include determining a deviation from an expected state after delivering the personalized guidance message and adapting the model based on additional input information.

[0441] Figure 6 6 is a flow chart illustrating an example method 600 for determining and providing a patient with a personalized and useful calculated guidance message in managing the treatment of diabetes. At step 602, the method 600 can include receiving data regarding the patient, the data including a real-time glucose concentration level. The real-time glucose concentration level can be received, for example, from a glucose sensor such as a continuous glucose monitoring system.

[0442] At 604, the data can be applied to a state model to determine a state of the patient. The state of the patient can be, for example, a physiological state, such as any of the physiological states described above. For example, the state can include an insulin state, such as an insulin on-board state, an insulin sensitivity state, an insulin duration state, or a combination thereof. The state model can also include behavioral or contextual states or measurement states. The state model can be, for example, a probabilistic state model. The state model can include state transition probabilities that are learned from retrospective data. In some examples, the model includes multiple sources and is informed using retrospective data or data captured in real time. The model can also include probabilities, such as state transition probabilities, or combinations of state transitions. In some examples, a state or number of states can be determined based on the CGM data and other input data to determine the state of the patient. In other words, the system can process the model backwards to determine the combination of parameters that is most likely to provide a CGM value of the current X. This combination of parameters (e.g., states) can be considered the "state of the patient."

[0443] At 606, a treatment recommendation based on the determined condition can be provided. The treatment recommendation can include, for example, guidance regarding insulin delivery, carbohydrate consumption, protein, fat, or other nutritional or other foods or beverages. The treatment recommendation may be delivered to the patient or caregiver, for example, via a visual user interface (e.g., a screen), a speaker, or electronic communication delivered via other communication mechanisms. The method can further include refining the condition model using data received after delivery of the treatment recommendation. For example, physiological data or condition changes can be input into the model, allowing the model to learn from the actual data and adjust the model based on the input conditions and actual output. The system can also consider physiological results of previous guidance to improve the determination of a particular condition or improve the guidance determination.

[0444] Figure 7 FIG. 7 is a flow chart diagram of a method 700 for determining and delivering guidance messages that are calculated to be personalized and helpful to a patient in managing their diabetes care.

[0445] The method may include, at 702, learning a personalized behavioral model of the patient. The learning may be based on, for example, an existing data set, real-time captured data, or a combination thereof. Learning the model may include learning both the patient's physiological function and the patient's behavior, both of which may be characterized as states. Learning the personalized behavioral model of the patient may include machine learning one or more characteristics of the patient, such as physiological patterns, contextual patterns, or behavioral patterns, or a combination of these patterns.

[0446] The method may also include receiving real-time data, at 704. The real-time data may include any of the examples described herein, such as CGM sensor data, location, network connectivity, or physiological sensor data.

[0447] The method may also include, at 706, determining a personalized guidance message to be provided to the patient. The determination of the personalized guidance message may be based, at least in part, on a time of the determination of the personalized guidance message and a personalized behavioral model of the patient. The method may also include, at 708, determining a delivery time for providing the personalized guidance message using the learned personalized behavioral model, the delivery time being calculated to be useful to the patient in managing the user's diabetes care. The method may also include delivering the personalized guidance message at the delivery time.

[0448] Figure 8 FIG. 8 is a flow chart diagram of an example method 800 of providing decision support functionality to a user. The method may include, at 802, loading a model into a memory of a computing environment. The method may also include, at 804, receiving data indicative of a glucose concentration value of the user. The method may also include, at 806, causing a calculated insight to be displayed on a user interface of the computing environment. The insight may be calculated, for example, using at least the model and the data indicative of the glucose concentration value. In some examples, a user request may trigger the display of the calculated insight. The user request may be associated, for example, with a data entry of a planned activity. The calculated insight may indicate a user action calculated by one or more of the models to bring about a desired outcome associated with the glucose concentration value while maintaining the glucose concentration level (or rate of change thereof) within a target range or above or below a particular level. The planned activity may be, for example, a meal, and the calculated insight may be a calculated or predicted effect of the meal on the glucose concentration value after the meal, or a strategy for managing the glucose concentration level (e.g., insulin delivery or activity or both). In some examples, the calculated insight may include an interactive recommendation and at least one factor used in determining the interactive recommendation.

[0449] In some examples, displaying an insight can be triggered by the occurrence of an event that matches a predetermined condition, such as blood glucose levels or trends, or arrival at a destination as determined by a GPS system, or an event inferred from a pattern or determined using calendar information.

[0450] In some examples, causing the guidance to be displayed may be initiated by the occurrence of an event that matches a calculated condition. The calculated condition may be calculated at least in part based on the model, or data indicative of glucose concentration values, or a combination thereof. For example, if a treatment adjustment exposes the user to more risk than existed prior to the treatment adjustment, the warnings and / or alerts may be adjusted to have additional sensitivity for a period of time following the treatment adjustment. In other examples, messaging frequency of the decision support application may be increased upon detecting when there is a period following a potential treatment decision that triggers more frequent instantiations of the CGM app than prior to the potential treatment decision.

[0451] Figure 9 FIG. 9 is a flow chart diagram of a method 900 for delivering physiological glucose concentration management guidance. In step 902, the method can include receiving data indicative of a glucose concentration level. In step 904, the method can include determining a state by applying the data to a model. In step 906, the method can include determining a guidance message based on the state and a temporal pattern. The temporal pattern can include, for example, a learned temporal pattern or a user-defined schedule (e.g., a patient or caregiver's calendar). The pattern can include a pattern of one or more states correlated with time, or a typical blood glucose concentration level, range, or pattern correlated with time or an event.

[0452] Figure 10 10 is a flow chart diagram of a method 1000 of delivering physiological glucose concentration management guidance. The method 1000 can include receiving data indicative of a glucose concentration, at step 1002. At step 1004, the method can include determining a patient's condition by applying the data to a model.

[0453] In step 1006, the method may include determining whether the patient's condition is atypical. Determining whether the patient's condition is atypical may include determining whether the patient's condition is atypical for a given set of conditions, determining whether a low likelihood state transition has occurred, and determining whether a low likelihood state transition is predicted to occur. In one example, determining the patient's condition includes determining a physiological state and a behavioral state, and determining whether the physiological state is atypical with respect to the determined behavioral state. In a further example, determining whether the patient's condition is atypical may include identifying a blood glucose concentration level that deviates from a controlled blood glucose concentration range when or in a situation where the blood glucose concentration is normally within the controlled range, identifying a blood glucose concentration trend that leads to a high or low blood glucose concentration state when or in a situation where the blood glucose concentration is normally within the controlled range, or predicting a shift to a low blood glucose concentration state when or in a situation where the blood glucose concentration is normally controlled.

[0454] In step 1008, the method may include determining a guidance message based on the atypicality of the patient condition, and in step 1010, the method may include delivering the guidance message via a user interface.

[0455] Figure 11 FIG. 11 is a flow chart diagram of a method 1100 of delivering physiological glucose concentration management guidance. The method can include receiving data indicative of glucose concentration, determining a patient's state by applying the data to a model, determining from the model that a low probability state transition has occurred or is likely to occur, and delivering a guidance message via a user interface based on the determination that a low probability state transition has occurred or is likely to occur. For example, a pattern can be recognized such that under general conditions, a transition to a particular state is of low probability, but under certain conditions, as indicated by real-time data or user input, the pattern is recognized such that the transition may actually occur. For example, the method can include alerting a user to a high probability of an atypical state when glucose levels are normally controlled at the time. For example, a user can be alerted of an expected low glucose level after exercise. Exercise can lead to low glucose levels (e.g., due to increased insulin sensitivity or restoration of glycogen stores) several hours after exercise is completed. The user can be alerted of the likelihood or probability of such a "late and low." If a low is calculated to occur during sleep or at an inopportune time, an alert can be delivered or prioritized. In some examples, the alert may be delivered at a time calculated to be useful to the user, such as before the patient is expected to fall asleep, to avoid waking the patient or caregiver.

[0456] Figure 12 12 is a flow chart illustrating a method 1200 of delivering physiological glucose concentration management guidance. The method may include receiving 1202 data indicative of a glucose concentration, receiving 1204 one or more behavioral, environmental, or contextual inputs, identifying 1206 a likelihood of a transition to an undesirable patient state by applying the data and the one or more behavioral, environmental, or contextual inputs to a model, determining 1208 a guidance message based on the likely transition to the undesirable patient state, and delivering 1210 a guidance message, the guidance message being determined and delivered at a time such that a patient can intervene to avoid the transition to the undesirable patient state.

[0457] Figure 13 13 is a flow chart diagram of a method 1300 of delivering physiological glucose concentration management. The method can include receiving 1302 data indicative of a glucose concentration, determining 1304 a physiological state using the data, determining 1306 a behavioral state, determining 1308 a guidance message based on the physiological state and the behavioral state, and delivering 1310 the guidance message using a user interface.

[0458] Exemplary Inputs and Outputs - Figures 14-16 Flowchart 650 of FIG. 14 illustrates a method for quantifying non-crispy input. In particular, upon receiving a non-crispy input (step 219), one way to quantify it is to perform a step of natural language processing on the input to determine a "crispy" equivalent (step 221). For example, if a user qualitatively indicates that they consumed a glass of orange juice, natural language processing determines the number of carbohydrates in a glass of orange juice and converts the input from non-crispy to crisp. In this regard, historical pattern data can also be used. Similar such natural language processing can be used to determine the crisp nutritional content of an input such as "I ate a Quarter Pounder at McDonald's." Social networks and social media can also be used to give context to the non-crispy input or to tighten the value otherwise associated with the non-crispy input (step 223). Big data can also be used (step 225) to give context and crisp value to the non-crispy input. For example, population data can be used to determine what a particular user means by the display of a particular phrase or parameter, for example by analysis of cohort data, and the same can be used with any of the other techniques to sharpen a version of a quantifiable baseline input that can be used to influence decision support (step 227).

[0459] Specific and other aspects of the input are described in the "Input" section below.

[0460] However, before a general discussion of the inputs, with reference to FIG. 15, a particular type of relationship is illustrated, the particular relationship being illustrated by the relationship 231 between food sensitivity 233d and meal bolus 235a. Other relationships between inputs 233a-233e (only a sampling of such inputs is shown) and various results or particular outputs 235a-235e (again, only a sampling of such outputs is shown) can also be determined using systems and methods according to the present principles. A processing step 237 is shown to show how a correlation parameter, e.g., food sensitivity 233d, is used in conjunction with real-time inputs (not shown) in processing step 237 to result in a treatment recommendation for meal bolus 235a. Particular examples of these inputs and outputs are described in the "Examples" section below.

[0461] The identification of correlated parameters and lifestyle / situational parameters and the subsequent processing steps can be performed in various ways. For example, the steps can include factors from various places, such as social networks, user input data, sensor data, data from user devices, populations or big data. The processing and identification can include, for example, Bayesian analysis, etc., to identify strong connectors, which are parameters or variables that have a strong relationship with each other. If multiple parameters are used, the same can include multiple parameters related to the same event, for example, both the intensity and duration of the exercise. The processing and identification can include multiple steps, for example, a first step of processing the "internal data" of the patient, and a subsequent step of performing processing in the cloud with the "big" data, for example, using prepackaged subroutines and case-based reasoning. For example, case-based reasoning can be used to determine what happened to the user in other similar situations, or what happened to other similar users in other similar situations. As smart devices become more computationally powerful, much of the machine learning can occur on such devices. However, much of the current processing can be done in the cloud, and such processing can result in a large amount of machine learning. In other words, the system learns how one element or "influencer" X affects the patient, for example, how anabolic exercise affects insulin sensitivity. In this example, if a pump action was initiated by a bolus, but performed by the user without considering the effects of exercise, a system and method according to the present principles can detect this sequence of events and provide the user with recommendations such as "expect a drop" or "you need to eat something now."

[0462] As mentioned above, the final step of the method is to modify the input or output interface based on the identified correlation parameters or correlation states and real-time inputs. The real-time inputs can include lifestyle or behavioral or situational parameters, e.g., time of day, an event about to take place as determined by a clock or calendar application or user input, glucose values, etc. In other words, the machine / human interface is modified by a decision support application / function, e.g., on a smart device, smartphone, smartwatch, and / or as part of the input or output user interface of any of these devices, based on the results of the above steps. For example, the output user interface, i.e., the type, format, and content of the output, can then depend on the lifestyle / situational context, as well as the parameterized model and / or user-defined functions. It is noted that certain user-defined functions, e.g., lifestyle goals, need not be used in all implementations, but can be advantageously used to derive specific treatment recommendations.

[0463] In modifying the human interface of a machine, just as the input is categorized or "fuzzified," the output can also be provided in categories or "fuzzification," especially when the output is provided simply in a display user interface. For example, if a therapy recommendation suggests that the user have a large glass of orange juice or eat a medium apple, the user may find such a recommendation more helpful than a recommendation to eat a specific amount of carbohydrates. Of course, when the output includes output to a pump or pen, such "fuzzification" is unnecessary and as much precision as possible is generally desired.

[0464] Figure 15 - Output Exemplary outputs are as shown in Figure 15, such as recommendations for type, amount, and timing of meal bolus 235a, recommendations for type, amount, and timing of correction bolus 235b, recommendations for type, amount, and timing of meal 235c, changes in user interface 235d, such as providing an alert or warning at a time determined to be effective for the user, or pre-event or situational decision 235e, which is a decision made, for example, before sleeping, eating, exercising, driving, activity, etc. Other exemplary outputs include permanent or temporary changes to basal rate settings, rescue carbohydrate recommendations, etc. Specific outputs, and how the same are changed depending on the decision support application / function, are described in the "Output" section below.

[0465] With respect to providing decision support applications / functionality in a manner that supports user-defined functionality, various core methods have been described above, however, it should be understood that the core methods need not be mutually exclusive. For example, various combinations of the core methods may be employed in a given implementation. Additionally, multiple methods may be run in parallel to determine optimal therapy and select the safest option. That is, various algorithms, as described above, may be used to calculate optimal diabetes therapy decisions using defined conditions, sensor data, user input, and other available information. Multiple methods may be run in parallel to calculate optimal therapy decisions and then provide the most conservative or safest solution to the user. For example, during sensor noise, either the filtered or raw sensor values ​​may be used to calculate a current glucose estimate, followed by a recommended insulin bolus. A dose may be calculated in parallel based on both sensor values, and a more conservative dose may be recommended. Another example is using an estimate of glucose rate of change based on trends calculated in a CGM algorithm, or as a two-point difference between the most recent pair of glucose values, and the rate of change that provides a more conservative dose is used.

[0466] Some exemplary inputs and notations for such inputs are shown in the table. It will be understood that other inputs can be used and that the notations given for the inputs are not necessarily limiting. For example, an input can be shown as having a particular context, but in some cases the context can be considered to overlap with a particular category. As another example of variation, a particular input may be identified as something entered by a user, but in some cases may be determined by a sensor or the like. For example, meal data can be determined by user input, but also by GPS, from pattern data, or from an app such as a camera. As mentioned above, the decision support application / function incorporates machine learning to increase the accuracy and appropriateness of treatment prompts over time. For example, meal data entered by a user, such as "small meal," "medium meal," etc., can be "learned" by the system so that the decision support application / function has a good understanding over time of what the user considers a "small meal," etc. Temporal patterns can be analyzed by the system and method to determine aspects of, for example, meals and exercise, but the user can also identify and quantify events they wish to track, including those corresponding to meals and exercise.

[0467] In an alternative implementation, the algorithm may define only one "average" meal, but with some degree of automatic adjustment, define what is large or small for the user. In this implementation, the "average" meal may be defined for a population or for an individual user. This implementation may be convenient to implement because only one meal size needs to be defined and does not need to be changed for each meal. Rather, a multiplier is applied by the patient, HCP, or automatically to evaluate whether a meal is "average," "light," or "heavy / large." The algorithm may then automatically increase or decrease the suggested insulin amount according to the evaluation. For example, an exemplary "multiplier" may be that a large meal is 1.5 times the effect of an "average" meal, or that a small meal is 0.5 times the effect of an "average" meal. Such an implementation may be particularly convenient for the user to implement, especially if the user is not familiar with carbohydrate counting. It is understood that such ideas may be extended and exercised in other applications.

[0468] When multiple types of data are used as input for a given algorithm, the multiple types may be relevant and may be, for example, the type, timing, and intensity of variables such as illness, exercise, diet, sleep, etc., and may be, for example, the duration and intensity of exercise.

[0469] In the table, the inputs are divided into two categories: real-time data and non-real-time data. Referring also to FIG. 17, these input categories 246 are divided into subcategories as follows: user data 254, which can be data from sensors (248 and 252), data entered by the user or from other apps, derived data, and other data, such as appropriate APIs. Some subcategories are displayed for both real-time and non-real-time data. In either case, the inputs 246 are then provided to a user device 256, which can be a dedicated receiver or a smartphone, and more specifically to a decision support application 260 located therein. The derived data 262 can be stored on the user device 256, and the display 258 can include a user interface to prompt the user as well as to receive the user input data. The derived data 262 can be derived by a processor in the user device 256, and the derivation of the data can occur within or outside the decision support application / function.

[0470] Figure 16 - Input Referring again to the types of data shown in FIG. 16, sub-sub-categories describe a particular type of data or are categories in themselves. For example, a sub-sub-category of real-time data is “physiological sensors” which can be further divided into different types, such as CGM, SMBG sensors, body temperature sensors, skin conductance sensors, hormone sensors, heart rate sensors, etc. In addition to physiological sensors, other sensor data includes non-physiological sensors such as barometric pressure, accelerometers, GPS, sensor measurement aspects of the CGM system itself, temperature sensors, etc. Such inputs may be provided from wearable devices / sensors, such as those available from an Apple Watch®, Fitbit®, or other wearables. Other devices providing inputs may include other mobile devices, including smartphones.

[0471] Sensors such as an accelerometer or GPS can be conveniently used to provide data regarding exercise or activity performed by the user. In some cases, the GPS or other sensors can also be used to determine other types of activity data, for example to inform the user if they are driving, and output to the user can be displayed, for example, on the smartwatch or on the smartphone.

[0472] In the particular case of an accelerometer, it can be advantageously used to detect sleep patterns or quality of sleep related to glucose control. Such can generally provide data related to location, but importantly, not only the detection of activity, but also duration and intensity. One potential type of accelerometer that can be advantageously used is a 3-axis accelerometer.

[0473] In some cases, the decision support application / function may allow for input of data regarding the onset of the menstrual cycle (or other markers). In this way, the user can track the behavior of blood glucose levels at various times of the month relative to the cycle over several months. Of course, such algorithms and data may also be used on their own to assist in pregnancy efforts, or if using rhythm methods for birth control.

[0474] Hormone sensors can provide other sources of input data, and in one example can be a source of data related to the menstrual cycle. Other hormone sensors can include those that sense cortisone and / or epinephrine. Hormone sensors and the like can also be used to provide measurements of "energy in" versus "energy out," particularly with respect to the patient's parameterized system model.

[0475] Other subcategories of input of real-time data include user-inputted data including goals, problems to be solved, desire for treatment, input data regarding stress, emotions, or mood, pain level data, sleep level data, data from follower devices, pump data, diet data, exercise data, blood glucose data from an external glucose meter, etc. User-inputted data can include user estimates of glucose values, thus enabling decision support in a manner that helps the user better correlate perceived glucose values ​​with actual glucose values. For example, decision support applications / features can be enabled to better assist the user in determining and identifying how different levels of hyperglycemia feel. User-inputted data can also include demographic data of the user, such as age, gender, etc. Such data can be conveniently obtained, for example, by swiping the user's driver's license.

[0476] When the user input data includes exercise, systems and methods according to the present principles may allow the user to save a particular workout or event to analyze and potentially discover patterns of post-workout glycemic fluctuations to make appropriate automatic or manual therapy changes via a decision support application / function. For example, the user may save workouts such as "Cardio1", "Cardio2", "GetSwoll1", "GetSwoll2", etc. Other stages of exercise may include those related to intensity, e.g., light, moderate, vigorous, duration, e.g., 5 minutes, 10 minutes, 15 minutes, 20 minutes, 25 minutes, 30 minutes, 1 hour, etc.

[0477] The goal data may include an indication of priorities for glucose control, e.g., hypoglycemia avoidance vs. hyperglycemia avoidance. Different control types may be provided as pre-programmed profiles that the user can choose from when selecting a goal. For example, a user may select goals such as low minimized control, very minimized control, frequent vs. infrequent correction boluses, etc. to suit different treatment styles and goals.

[0478] Similarly, user feedback may also constitute an important input to the decision support. That is, the decision support application / function may change based on user feedback, for example periodically querying the user about what they would like to change about their recent glycemic control and providing options such as "I would like to have fewer nocturnal hypoglycemia episodes" or "I would like to not have to give correction boluses as frequently." The feedback may be solicited in a convenient manner to minimize user annoyance. For example, the feedback may be provided by a slider bar or other user interface element convenient for user selection. A slider bar may also be provided for other user input, for example to indicate how much interaction is desired.

[0479] As mentioned above, the decision support application / function can be advantageously used as part of a bolus calculator. Thus, user input can also include user input to such a bolus calculator. For example, the decision support application / function can be provided with a user interface that offers the user predefined dose adjustments, e.g., + / -0%, + / -10%, + / -20%, etc. The proposed dose adjustments can themselves be dependent on CGM trends, e.g., in the case of a negative or declining glucose trend, a negative dose adjustment can be provided. The selected adjustment is applied to the calculated bolus dose with or without other trend adjustments. Alternatively, the adjustments can be fuzzy. In yet other implementations, the user can choose to customize the adjustments within bounds. Over time, with data, the decision support application / function can determine the optimal adjustment based on this user input data (and other inputs), and with provider approval (or without provider approval / confirmation), adjustment options can be presented to the user to be re-determined.

[0480] In a related implementation, the rate of change data can be used to increase / decrease the calculated bolus value by a fixed amount, rather than a percentage. In this way, the patient adds or subtracts enough insulin from the meal bolus to cover that amount of glucose change, using their insulin sensitivity / correction factor. In this implementation, initially, the bolus calculation can be left unchanged, and the decision support application / function can learn how much insulin needs to be added or subtracted based on the rate of change as part of a case-based learning process. For example, rather than updating insulin sensitivity, if glucose is rising or falling, the system may learn how far the glucose is from the target and consider that to be the amount of glucose that should be accounted for. In this case, a new insulin sensitivity is not learned, but instead the best insulin sensitivity estimate is used based on other descriptors of the case, such as lifestyle factors, specific to insulin sensitivity for breakfast with no exercise. Because it may be desirable to learn both the amount to adjust the insulin bolus based on the rate of change and the change in insulin sensitivity over time, exercise, etc., systems and methods according to the present principles advantageously separate the two problems and can only perform insulin sensitivity updates when the rate of change is relatively stable. Once it learns how much a user needs to adjust their insulin based on the rate of change, for example, when the user takes a meal bolus and the trend arrow is at 90 degrees up, such data can be pushed to the HCP where the user's post-prandial glucose always shows a pattern that is too high around 30 mg / dL, and the HCP can be asked to approve adding or subtracting an amount of insulin. Machine learning can also be used to determine whether it is better to change the insulin bolus based on a percentage or a rate of change using a fixed amount, which can vary from patient to patient. Additional details regarding the use of rate of change data are provided in the examples below.

[0481] Returning to the discussion of the various inputs, the inputs can include data about the user's followers or other related users. This entered data can include data about social groupings for achieving individual or group goals, and can further use natural language processing to derive objective and quantifiable desires and goals of the group or its members. The inputs can also include inputs from followers, for example in response to a query such as "What do you think is going on with my daughter?"

[0482] Other sources of real-time data entered by the user include meal data. The user can enter the meal data in a fuzzy or categorical manner, or as crisp input. Machine learning can be used to learn how the user categorizes meals in an objective sense. For example, if the user describes a meal as "small" in terms of what is entered into the decision support application / function, the system can learn what the user considers a "small" meal in a more quantitative or objective manner. The same applies to meals entered and called as other sizes. The same applies to data entered by the user regarding the composition of the meal. In other words, the system can learn what the user means when they enter a statement of meal composition into the decision support application / function. For example, if the user describes a meal as "high carb," the system can learn from data regarding glucose response and insulin provided (if available) in combination with the meal data, what the user considers to be "high carb."

[0483] Other subcategories of input of real-time data include data from other applications or "apps", e.g., data from an appropriate API in general. Such apps may reside in the computing environment providing the decision support application / function or may communicate with it wired or wirelessly. Such apps include calendar apps, GPS apps, CGM apps, apps that hold historical data or other information, SMBG apps, temperature monitor apps, Healthkit®, data from followers such as text messaging apps, bolus calculation apps, clock apps that provide the time, apps that indicate elapsed time so that user prompts can be provided at the optimal time, apps that provide access to cloud or "big" data, camera apps, pump applications, pen applications, bolus calculation apps, etc. As a specific example, a text message or email app can point to an event, e.g., a dinner party. Through an appropriate API, the text message or email app can serve as an input source of calendar data. In a specific example, there can be an option to "add event to CGM", or the CGM (or equivalent decision support application / function) can automatically pull event data each time a calendar event is added. Such a feature would allow users to create calendar events and CGM events simultaneously, thus providing an easy way to collect event data and see how events affect glucose trends.

[0484] For example, bolus calculator decision support generally requires the input of meal data. In one implementation, a camera application may prompt the user to take a picture of a meal on a plate (see FIG. 18A). The user may take the picture using the phone's camera, and a bracket may be provided as part of the on-screen user interface to guide the user on how to take the picture. The app may then measure the size of the meal in relation to the size of the plate and indicate the meal as, for example, small, medium, or large. The app may then present a dosage recommendation based on the size of the meal. In a further enhanced implementation, the app may use photo recognition technology to determine, estimate, or guess what is on the plate and provide an estimate regarding the composition of the resulting meal. Variations are appreciated. For example, in an alternative implementation, the user prompt may instruct the user to swipe different circle (or other shape) sizes over a picture of the meal on a plate (see FIG. 18B). The app may then ask the user to find the circle size that best fits the size of the meal on the plate.

[0485] Other real-time data that can be provided from the app includes pump or associated data including recent boluses, basal rates, etc. As another example, prompts may be provided based on estimated insulin onboard, in conjunction with CGM input and other contextual information. Insulin onboard is a term that describes the amount of insulin that has been administered to the patient but has not been used by the body to transport glucose to tissues. After a meal bolus intake, the estimated insulin onboard is still half of the original dose, but if the measured glucose has already dropped to 80, a warning can be provided because continued insulin activity is expected, further lowering glucose to hypoglycemic levels.

[0486] More specifically, patients who receive too much insulin may be at risk for hypoglycemia and death. Currently, there is no real-time measurement method to measure the amount of insulin that is in a patient's body. Insulin stacking occurs when a patient who uses insulin receives multiple boluses of insulin in a short period of time. The insulin from the previous administration may not have exerted its full effect, and thus the patient may give themselves too much insulin in the subsequent administration, putting the patient at significant risk of hypoglycemia. A continuous direct insulin sensor can be used to measure the amount of insulin that is in the patient's body. This detector can be used as an alarm or fail-safe to shut off the pump or artificial pancreas. Because each patient generally has a different insulin sensitivity (although this sensitivity can be learned using the decision support application / functionality described here), alarm settings generally require multiple thresholds.

[0487] A second aspect of this implementation involves monitoring the patient's insulin amount using a direct insulin sensor. The amount of insulin can be used to give feedback to the patient recommending a safe dose of insulin. The insulin information can also be sent directly to a calculator or pump and used in insulin dosing calculations to more accurately estimate the appropriate amount of insulin to administer. This can be used in place of the current insulin on-board estimation used in bolus calculators.

[0488] A third aspect of this implementation describes the use of a direct insulin sensor to measure a patient's insulin sensitivity. Insulin sensitivity can vary from patient to patient and even over time for the same patient. Thus, systems and methods according to the present principles can use a direct insulin detector to measure the amount of insulin in a patient's body. By combining glucose and insulin concentration information in a patient into an algorithm, insulin sensitivity can be calculated. The information contained in the insulin sensitivity can then be used to determine whether an insulin sensitizer, insulin secretagogue, or insulin should be used to manage diabetes, for example, to increase or decrease the amount of insulin given to the patient to best control their glucose levels.

[0489] Returning to the input chart of FIG. 16, another example of real-time data that can also be used in non-real-time is GPS data from apps and other sensors that can be used for users on the go, for example to determine potential followers and friends for a university user.

[0490] A calendar app can be used to provide data about a user. As an example of determining data from multiple different sources, exercise data can be determined from calendar data if exercise is within a scheduled notation or if a pattern of exercise suggests that the user exercises at the same time each day or week.

[0491] As another example of input, safety rules can be used to provide decision support with varying levels of aggressiveness. For example, if the user does not provide detailed dietary information, a decision support application / function that prompts the user to raise their glucose level into a target range can aim for the upper end of the target range rather than the middle of the goal. Similarly, if the user provides dietary data that indicates a very large amount of carbohydrates, the decision support application / function can again aim for the upper end of the target range since it is known that carbohydrate count errors have a more detrimental impact as the overall carbohydrate amount increases.

[0492] As another example of inputs, device diagnostics may serve as inputs including device signal quality and reliability as well as risk stratification decisions based thereon. For example, meal or correction bolus or other decision support prompts may be at least partially informed by confidence intervals, which may in turn be at least partially informed by device signal quality and / or detected impairments.

[0493] Cloud or big data can also be used. As an example of the use of cloud or big data, an HCP may wish to determine an initial value for insulin resistance or insulin sensitivity. The HCP may input population demographic data such as weight, age, and gender. The app can then search the database to find users who are most similar to the target user and use the average settings as the initial candidate. Cloud or big data can be further used for initial risk stratification, similarly based on aggregate numbers.

[0494] As noted above, the CGM app can provide input to decision support applications / functions. For example, in some implementations it may be preferable to use fuzzy logic to handle glucose levels outside of the range of, for example, 40-400. Still other data that can serve as input and be available from the CGM app can include a target glucose level or range.

[0495] Still other types of inputs include derived data. Derived data, which in some cases may also constitute real-time data, includes rates of change or acceleration of analytes, various types of sensitivities such as insulin, sleep, diet, and / or exercise, tiers within risk stratification (described in more detail below), glucose variability, user stress / emotion / mood data, user preferences for device interaction, sensor accuracy / reliability / signal quality, pattern data, and the like. Such sensitivities often constitute lifestyle factors as defined above. Detection of said hormone levels can further aid in the detection and quantification of insulin sensitivity, as hormone levels are known to be relevant factors.

[0496] Insulin sensitivity can be based on sleep, energy intake vs. energy output, food intake, etc. Insulin sensitivity can change rapidly, for example, due to circadian rhythms. Insulin sensitivity is known to be event-driven, stress-driven, and also driven by factors such as illness, activity, etc. If the user employs a CGM monitor, events that affect insulin sensitivity can be detected, and insulin sensitivity measurements can also be determined from knowledge of carbohydrate intake to glucose and basal / bolus amounts of insulin. Typical and atypical ranges of insulin sensitivity can also be determined. Insulin sensitivity can be measured, for example, by measuring the basal rate at the same time each day and seeing how glucose values ​​change with respect to various events including meals, exercise, stress, etc., and then performing the same test with various changes in the basal rate. Insulin sensitivity can also be detected by testing the levels of various hormones including cortisol and epinephrine.

[0497] Derived data corresponding to meal sensitivities may be further refined by determining, for example, sugar sensitivity, dinner sensitivity, etc. It will be appreciated that other such perturbation or interaction sensitivities may also be derived.

[0498] The "insulin to carbohydrate" ratio may also constitute derived data, and the same is typically determined and optimized using retrospective analysis. The same may be used to provide decision support education to the user by graphically illustrating the impact of various levels of insulin to carbohydrate. In particular, with knowledge of insulin delivery, the decision support application / functionality, or an associated or connected module, may display to the user the effect of use of various insulin to carbohydrate ratios on glucose levels, for example, by modifying retrospective glucose trend lines. Within the decision support application / functionality, optimal insulin to carbohydrate ratio settings may be automatically determined, and further, how insulin to carbohydrate settings vary with time of day, activity level, etc.

[0499] In some cases, derived data requires analysis of a period of time to be analyzed or a pattern to be determined. For example, a determination of insulin sensitivity or insulin resistance can require analysis of data taken over a duration of time. In a particular implementation, insulin resistance can vary throughout the menstrual cycle of a female diabetic patient. A decision support application / function can use the resulting cycle of insulin resistance, including, for example, the incorporation of insulin consumption and glucose values, to determine a predicted insulin resistance warning to provide to the user. For example, a patient can receive a reminder at the beginning of the day that historically their blood glucose levels tend to rise or fall in their cycle. Such prompts can help the patient become more conscientious about how they can expect their blood glucose levels to behave.

[0500] For the initial or seed value of insulin sensitivity, population data can be used from a database of patients, especially patients with similar weight, age, sex, length of diabetes, etc. Such can be used for default values ​​and can be auto-adjusted as additional information about the user is known over time.

[0501] Dietary data may also be in the form of derived data, as in obtained from food patterns, food libraries, and the like. Other methods of deriving dietary data may use retrospective analysis to estimate the carbohydrate content of a given meal using other data. Such other data may include, for example, insulin delivered, glucose levels, exercise, health, meal times, and the like. By collecting such data, the decision support application / function may determine the user's typical meal and typical glucose response to that meal while mitigating the effects of other factors on glucose. Such functionality has several advantages, including improved accuracy of bolus calculators, the ability to optimize alerts if the system notices an abnormal glucose response, assistance in understanding the user's eating patterns and the effects of various meals on glucose, and more accurate calculation of insulin to carbohydrate ratios.

[0502] The derived data may further include user inferred data, such as, for example, whether the user tends to make errors in carbohydrate counting and by how much, for example, to overestimate or underestimate.

[0503] The derived data can also include data determined for recognized patterns, where patterns are recognized through analysis of historical data over time. Exemplary recognized patterns include nightly hypoglycemia, post-meal highs, post-exercise lows, etc.

[0504] One way to determine such patterns, or to detect the occurrence of glucose events that are not in a pattern, is to "bin" specific events defined by certain characteristics: that is, portions of the glucose trace that meet predefined criteria indicative of a particular diabetic challenge, e.g., rebound hypoglycemia, are detected, and patterns can then be looked for in these events that have been "binned" accordingly.

[0505] Figure 19 and onwards In more detail, and with reference to the flowchart of FIG. 19, signatures or fingerprints of glucose sensor data can be identified or differentiated within an individual patient based on some predefined criteria (step 262). Such criteria can include time-based criteria and / or specific incidents detected within certain constraints. In the present system, in accordance with the present principles, bins may be differentiated by different criteria. A supervised learning algorithm can be used that can learn more bins for individual specific patterns. For example, bins can be based on patterns of data previously identified and used to characterize the data, such as insulin data, rate of change (or acceleration / deceleration thereof) of glucose data, events occurring before a small meal, individual responsiveness to glucose information, etc.

[0506] The next step is that the incidents can be characterized (step 264), for example, based on decay curves, waveform signatures, etc. Exemplary incidents can include meal bolus indicators, for example, based on insulin data, which can be categorized into small, medium, and large meal bins. Such can be correlated with insulin data. Different meal types can also be characterized and then sub-binned into different meal compositions. These can be correlated with rate of change / acceleration / deceleration. Incidents can also be characterized based on correlation with pre-meal events, such that correspond to patterns in the data above. Incidents can further be based on behavioral patterns, for example, how often a user checks their glucose data or responds to an alert, such that can be correlated with the responsiveness data above. It will be appreciated that other bins can also be used.

[0507] The characterized incidents can then be placed into bins (step 266). The bins can then be tailored to the physiology of a particular patient by synchronization on an incident-by-incident basis. The bins can then be normalized, i.e., a normal distribution of incidents within the bins can be defined (step 268).

[0508] The normalized bin information can then be actively used as input to a decision support application / function, for example, in determining or defining a condition as per step A (step 268). As an example, the normalized bin information can be input to a bolus calculator. The normalized bin information can also be used to respond to other requests actively determined or requested by the user, such as when the user requests a bolus calculation before a meal, or when the system requests a bolus calculation before a meal based on time or other factors. The binning technique can be used to determine when the patient should align with the data based on behavioral input, which can allow for more aggressive recommendations, where bolus recommendations are generally more conservative, as opposed to when the user is not focused on glucose information, such as overnight.

[0509] Returning to FIG. 16, for non-real-time data, inputs can include user-entered data such as previous SMBG data, user knowledge of the technology, goal data, problems to be solved, desire for specific treatments, target glucose levels, population demographic data such as age and gender, cardiac health, cholesterol levels, type of mathematical calculations to employ (usually by default or entered by the HCP), data regarding illnesses or pregnancy or menstruation, data regarding medications taken, smoking history, etc. Non-real-time data can also include derived data including historical patterns, gastric emptying times, etc. Other non-real-time data can include data regarding the follower, e.g., tone of communication, language, etc. These can be used in modifying the output to enhance the user's effectiveness.

[0510] With regard to gastric emptying times, it has been noted that 25% of the diabetic population (types 1 and 2) experience some form of delayed gastric emptying. 7-12% of the same group suffer from increased delayed gastric emptying. The population with delayed gastric emptying is increasing at a very large rate within the diabetic population and is now a concern for medical professionals within the general population.

[0511] Current bolus wizards do not take into account gastric emptying, and therefore present certain risks. For example, if gastric emptying is not incorporated into the closed loop pancreatic system, the individual runs the risk of glucose fluctuations with repeated corrections and reduced insulin delivery. This results in chaotic insulin delivery that resembles a successive approximation waveform over time. If the same is not used in the bolus calculator for the insulin pump, this puts the person at risk as a result, as hypoglycemic events may occur that roughly correlate with the size of the administered meal. They may also suffer hyperglycemic events that also roughly correlate with the size of the meal, as the effect is activated when insulin responsiveness is reduced and diminished in the system.

[0512] Over time, such fluctuations can manifest into further damage that can reduce stomach function over time. Additionally, the person is at increased risk for peripheral neuropathy.

[0513] Delayed gastric emptying pushes the process of moving processed and prepared nutrients and food into the small intestine where the actual absorption of nutrients occurs and can be caused by factors such as neuropathy of the vagus nerve, nerve damage within the stomach, muscle damage within the stomach, etc. Gastric emptying studies are used by GI physicians to quantify the degree of delay that may affect the prognosis of gastroparesis.

[0514] A common instruction given to insulin-dependent diabetics is to administer (bolus) 0 to 30 minutes before a meal. The rationale for this instruction is to time the effect of insulin to correspond to the time that the consumed food enters the absorption phase. This timing is accurate when gastric emptying is not an issue (75% of the type 1 and type 2 population). However, in the balance of the population, the time of insulin delivery is imprecise. Fast-acting insulin reaches its maximum effect approximately 90 to 120 minutes after bolus administration. This is a delay from the administration of the bolus, propagation through the body, and attachment to the A and B receptors on the cell surface. At that time, the cells are able to process the sugar and do so. However, for individuals with delayed gastric emptying, delivery of the processed food to the system has not yet occurred. For these individuals, approximately 90 to 120 minutes after the meal (if the bolus is administered 30 minutes before the meal), they will suffer a hypoglycemic event. This event is generally countered by liquids such as orange juice, which enter the gut and system faster than solid foods.

[0515] The insulin response is dropping at the end of the peak in the elevated case of gastric emptying delay as food is being processed and entering the system. This results in a hyperglycemic event for which a correction bolus needs to be administered. Therefore, gastric emptying time can be used as an input to provide a time delay for the delivery of a post-meal bolus. This delay can be applied to a bolus calculator or closed-loop artificial pancreas system. Gastric emptying time can also be used as an input to provide a time delay for a modified basal rate after a meal. This delay can be applied to an insulin pump or closed-loop artificial pancreas system.

[0516] One method for determining an individual's gastric emptying delay is as follows: Once the CGM user has entered a bolus and meal, the next four hours of data are analyzed within the CGM. If there are reproducible events occurring for the individual that follow a trend, a gastric emptying delay can be inferred. The inferred delay can then be applied to the bolus and / or corrected basal rate as described above.

[0517] Referring to the example shown in FIG. 20, period (a) indicates the entry of the bolus and food. They are also offset from each other. Period (b) indicates the period when food processing should occur, but in this exemplary patient, food processing is delayed. Period (c) indicates when the food is normally processed because it aligns with the bolus. Time (d) indicates when the actual food processing occurs in the gastric delay. The slope of the BG fall indicates the rate and general delay of delayed gastric emptying. This delay is also represented in the BG value signal by determining the difference between the onset of (c) and (d) and their duration. To separate this signal within the general noise in the blood glucose signal, insulin sensitivity is calculated from the individual's blood glucose data.

[0518] Referring again to FIG. 16, non-real-time data may further include stored data that is stored in and retrieved from memory or other storage. Stored data may include historical data of both the determined pattern and data used to determine the pattern or other glucose event. Stored data may include previous user events. For example, if an HCP has previously commented on a pattern, the HCP comments may reappear in the user interface when the pattern repeats.

[0519] The inputs can be "fuzzy," e.g., categorized into a particular category, e.g., small / medium / large meals, or "less than normal" / normal / "more than normal," and the category itself can be used as an input, or the inputs can be sharp. Thus, the table shows exemplary categorized or fuzzy inputs, as well as exemplary sharp inputs. The table also shows an interpretation of the type of context of the input, e.g., whether the same concern exists for lifestyle aspects, situational aspects, clinical aspects, or device aspects. In some cases, an input may occupy multiple categories.

[0520] The way the inputs are used and aggregated can vary. In one implementation, a function can be determined or a user-system model can be created and the inputs are used directly in the function or model. In another example, in a hierarchical approach,...

Claims

1. 1. A system comprising: a glucose concentration sensor configured to detect a host glucose concentration; a communication circuit configured to receive the host glucose concentration from the glucose concentration sensor; 1. A processor comprising: receiving a host glucose concentration measurement from the communication circuit; predicting an occurrence of a future event of the host entering a second host state from a first host state, the occurrence of the future event of the host entering the second host state from the first host state being from a first disease state describing a first host disease stage to a second disease state indicative of a second host disease stage, the first host state being associated with a first glucose concentration profile and the second host state being associated with a second glucose concentration profile, the first and second glucose concentration profiles corresponding to changes in the host's glucose levels and / or glucose rate of change over time in relation to a behavioral or physiological state of the host, respectively, the first host state being a pre-sleep or pre-exercise state and the second host state being a sleep or exercise state; determining a guidance message during the pre-sleep or pre-exercise state based at least in part on the prediction of an occurrence of a future event of the host entering the sleep or exercise state from the pre-sleep or pre-exercise state, respectively, wherein the second glucose concentration profile is associated with the sleep or exercise state, behavior and physiological data, the physiological data including a measurement of the host glucose concentration; determining a second guidance message based at least in part on the second host disease stage; delivering the guidance message through a user interface during the pre-sleep or pre-exercise state; A processor configured to: Including, the system.

2. 2. The system of claim 1, wherein the processor is further configured to determine that an occurrence of the future event is atypical, and wherein the determination of the guidance message is based at least in part on the atypicality of the occurrence of the future event.

3. 2. The system of claim 1, wherein predicting an occurrence of a future event of the host entering the second host state from the first host state includes identifying a likelihood of a transition to the second host state, the second host state including an undesirable host state, and wherein the guidance message is determined and delivered at a time such that the host can intervene to avoid the occurrence of the future event of the host entering the second host state, which time is during the pre-sleep or pre-exercise state.

4. The system of claim 1 , wherein the system comprises a mobile device, the mobile device comprising the processor.

5. The system of claim 4 , wherein the mobile device includes the communication circuitry and the glucose concentration sensor includes a glucose concentration sensor communication circuitry configured to communicate with the communication circuitry.

6. 6. The system of claim 5, wherein the communication circuitry includes a first wireless transceiver, the glucose concentration sensor communication circuitry includes a second wireless transceiver, and the communication circuitry and the glucose concentration sensor communication circuitry communicate using a wireless communication protocol.

7. The system of claim 1 , further comprising an insulin delivery system, and wherein the physiological data comprises insulin delivery information received from the insulin delivery system.

8. 8. The system of claim 1 , wherein prediction of an occurrence of a future event of a host entering a second host state from a first host state is performed using a machine learning model, the machine learning model being trained using a training dataset including behavioral and physiological data associated with the host, the behavioral and physiological data including at least one of: (i) heart rate data received from a heart rate sensor; (ii) respiration data received from a respiration sensor; (iii) the host glucose concentration from the glucose concentration sensor; (iv) host motion data from a motion sensor; (v) posture data from a posture sensor; or (vi) acoustic data from an acoustic sensor.

9. receiving, by a processor, a host glucose concentration measurement from a communication circuit in communication with the glucose concentration sensor; predicting, by a processor, an occurrence of a future event of the host entering a second host state from a first host state, the occurrence of the future event of the host entering the second host state from the first host state being from a first disease state describing a first host disease stage to a second disease state indicative of a second host disease stage, the first host state being associated with a first glucose concentration profile and the second host state being associated with a second glucose concentration profile, each of the first and second glucose concentration profiles corresponding to changes in the host's glucose levels and / or glucose rate of change over time in relation to a behavioral or physiological state of the host, the first host state being a pre-sleep or pre-exercise state and the second host state being a sleep or exercise state; determining, by the processor, during the pre-sleep or pre-exercise state, a guidance message based at least in part on the prediction of an occurrence of a future event of the host entering the sleep or exercise state from the pre-sleep or pre-exercise state, respectively, wherein the second glucose concentration profile is associated with the sleep or exercise state, behavioral and physiological data, the physiological data including a measurement of the host glucose concentration; determining a second guidance message based at least in part on the second host disease stage; delivering, by the processor, the guidance message through a user interface during the pre-sleep or pre-exercise state; A method comprising:

10. 10. The method of claim 9, further comprising determining, by the processor, that an occurrence of the future event is atypical, and wherein the determination of the guidance message is based at least in part on the atypicality of the occurrence of the future event.

11. 10. The method of claim 9, wherein predicting an occurrence of a future event of the host entering the second host state from the first host state includes identifying a likelihood of a transition to the second host state, the second host state comprising an undesirable host state, and the guidance message is determined and delivered at a time such that the host can intervene to avoid the occurrence of the future event of the host entering the second host state, which time is the pre-sleep or pre-exercise state.

12. 12. The method of claim 9, wherein predicting an occurrence of a future event of a host entering a second host state from a first host state is performed using a machine learning model executed by the processor, the machine learning model being trained using a training dataset including behavioral and physiological data associated with the host, the behavioral and physiological data including at least one of: (i) heart rate data received from a heart rate sensor; (ii) respiration data received from a respiration sensor; (iii) the host glucose concentration from the glucose concentration sensor; (iv) host motion data from a motion sensor; (v) posture data from a posture sensor; or (vi) acoustic data from an acoustic sensor.

13. A non-transitory computer-readable medium comprising instructions that, when executed by a processor, cause the processor to perform a method, the method comprising: receiving a host glucose concentration measurement from a communication circuit in communication with the glucose concentration sensor; predicting an occurrence of a future event of the host entering a second host state from a first host state, the occurrence of the future event of the host entering the second host state from the first host state being from a first disease state describing a first host disease stage to a second disease state indicative of a second host disease stage, the first host state being associated with a first glucose concentration profile and the second host state being associated with a second glucose concentration profile, each of the first and second glucose concentration profiles corresponding to changes in the host's glucose levels and / or glucose rate of change over time in relation to a behavioral or physiological state of the host, the first host state being a pre-sleep or pre-exercise state and the second host state being a sleep or exercise state; determining a guidance message during the pre-sleep or pre-exercise state based at least in part on the prediction of a future occurrence of the host entering the sleep or exercise state from the pre-sleep or pre-exercise state, respectively, wherein the second glucose concentration profile is associated with the sleep or exercise state, behavioral and physiological data, the physiological data including a measurement of the host glucose concentration; determining a second guidance message based at least in part on the second host disease stage; delivering the guidance message through a user interface during the pre-sleep or pre-exercise state; A non-transitory computer readable medium comprising:

14. 14. The non-transitory computer-readable medium of claim 13, wherein the method further comprises determining that an occurrence of the future event is atypical, and wherein the determination of the guidance message is based at least in part on the atypicality of the occurrence of the future event.

15. 14. The non-transitory computer-readable medium of claim 13, wherein predicting an occurrence of a future event of the host entering the second host state from the first host state includes identifying a likelihood of a transition to the second host state, the second host state comprising an undesirable host state, and the guidance message is determined and delivered at a time such that the host can intervene to avoid the occurrence of the future event of the host entering the second host state, which time is the pre-sleep or pre-exercise state.

16. 16. The non-transitory computer-readable medium of claim 13, wherein predicting an occurrence of a future event of a host entering a second host state from a first host state is performed using a machine learning model, the machine learning model being trained using a training dataset including behavioral and physiological data associated with the host, the behavioral and physiological data including at least one of: (i) heart rate data received from a heart rate sensor, (ii) respiration data received from a respiration sensor, (iii) the host glucose concentration from the glucose concentration sensor, (iv) host motion data from a motion sensor, (v) posture data from a posture sensor, or (vi) acoustic data from an acoustic sensor.

Images