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] This development generally relates to medical devices, such as analyte sensors, including systems and methods for providing treatment decision-making support using medical devices.

Background Art

[0002] Diabetes is a metabolic state related to the production or use of insulin by the body. Insulin is a hormone that enables the body to use glucose as energy or store glucose 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. Blood sugar can be used as energy or stored as fat. The body normally maintains blood sugar levels within a range that provides sufficient energy to support body functions and avoids problems that can occur when blood 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 glucose into cells.

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

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

[0006] The condition of diabetes is sometimes referred to as "type 1" and "type 2". Type 1 diabetic patients can usually use insulin when it is available, but due to problems with the insulin-producing beta cells in the pancreas, the body cannot produce sufficient amounts of insulin. Type 2 diabetic patients can produce insulin, but due to reduced sensitivity to insulin, the patients are "insulin resistant". As a result, even when insulin is present in the body, it is not fully utilized by the patient's body to effectively regulate blood sugar levels.

[0007] This background art is provided to introduce a concise context for the following summary of the invention and the mode for carrying out the invention. This background art is also intended to assist in determining the scope of the subject matter recited in the claims, nor is it to be construed as limiting the implementation of the subject matter recited in the claims to implementations that solve any or all of the above disadvantages or problems.

Summary of the Invention

Means for Solving the Problems

[0008] In this document, in particular, a system and method for delivering decision-making support guidance for a patient or caregiver or for determining a decision time will be described.

[0009] An example of a subject (e.g., a method or a system), such as "Example 1", can include measuring, determining, or receiving first real-time data related to a patient, determining at least in part the state in which the patient is using the model and the first real-time data, determining a guidance message based at least in part on the determined state, and providing a personalized guidance message determined via a user interface at a time calculated to enable intervention before transitioning to an undesirable physiological state.

[0010] In Example 2, the subject of Example 1 can be further configured such that determining the guidance message is based at least in part on the timing of determining the guidance message or the time related to the determined state.

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

[0012] In Example 4, the subject 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 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 the predicted transition from the current state to the predicted state is a low-probability transition.

[0014] In Example 6, the subject 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 in part on applying the first real-time data to the patient's physiological model.

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

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

[0017] In Example 9, the subject of any one or any combination of Examples 1-8 can be configured such that the action 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 of any one or any combination of Examples 1-9 can be configured such that the action model is based on a set of one or more goals determined to be likely to be achievable by the patient.

[0019] In Example 11, the subject of any one or any combination of Examples 1-10 can be configured such that the model includes an action model that is a pattern.

[0020] In Example 12, the subject 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 physiological patterns and an action model based on action patterns.

[0021] In Example 13, the subject 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 action pattern.

[0022] In Example 14, the subject of any one or any combination of Examples 1-13 can be configured such that the action model tends to overcorrect in meals related to meal times, the first real-time data indicates that meal times are approaching, and the guidance message is configured to respond to undercorrection of meal times.

[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 an action pattern that includes a long-term action pattern based on long-term and short-term action patterns related to the current action.

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

[0025] In Example 17, the subject matter of Example 16 can be configured such that the short-term action pattern is based on one or more selected from the group consisting of engagement with a mobile device, accelerometer data, frequency of checking glucose concentration, 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 partially based 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 related to the patient.

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

[0029] In Example 21, the subject matter of any one or any combination of Examples 1-19 can be configured such that the glucose concentration data measured after provision is fed back to a measurement model or an action model or a physiological model of the patient, 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 context 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 a physiological pattern, a context pattern, or a behavioral pattern.

[0033] In Example 25, the subject matter of any one or any combination of Examples 1-24 can be configured such that determining a guidance message includes determining a plurality of guidance messages based on a state and first real-time data, and selecting one of the plurality of further determined guidance messages based on the state 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 a comparison of the plurality of guidance messages with 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 patient's expected diabetes response based on a state and first real-time data, and the guidance message is personalized for the patient based on the expected diabetes response, and an executable message calculated to move the expected diabetes response towards a desired diabetes response is provided to the patient.

[0036] In Example 28, the subject matter of Example 27 can be configured such that the desired diabetes response is related to the state and the first real-time data, and the desired diabetes response is selected from the group consisting of an improved diabetes response, a potential improved diabetes 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 based on the functional relationship between the expected diabetes response and the desired diabetes response for which the guidance message is predicted.

[0038] In Example 30, the subject matter of Example 29 can be configured such that the functional relationship is the difference between the glucose concentration level related to the expected diabetes response and the glucose concentration level related to the desired diabetes response.

[0039] In Example 31, the subject matter of Example 30 can be configured such that the glucose concentration level related to the desired diabetes 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 based on whether the functional relationship matches a predetermined condition for which the expected diabetes response is related to the desired diabetes 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 related to the 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, thereby enabling the patient to be notified of the reason for providing the guidance message.

[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 executable prompt.

[0044] In Example 36, the subject matter of Example 34 can be configured such that the guidance message includes an executable prompt that is calculated to move the patient's glucose concentration level towards a target level or target 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 the patient's current behavior.

[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 time, characteristics or signature signals 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 user requests for decision-making support prompts.

[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 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, which is used when determining the state of the patient.

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

[0058] Example 50 is a system comprising a glucose concentration sensor configured to detect a patient's glucose concentration level, a communication 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, execute stored instructions, apply the patient's glucose concentration level to the stored model to determine a state, and determine a guidance message based at least in part on the determined state.

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

[0060] In Example 52, any one or more of the subject matters of Examples 50 - 51 includes that, optionally, 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 includes that, optionally, the processor is 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, any one or more of the subject matters of Examples 50 - 53 includes that, optionally, the processor is further configured to provide a treatment recommendation based at least in part on the determined state.

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

[0064] In Example 56, the subject matter of Example 55 includes that, optionally, 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.

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

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

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

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

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

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

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

[0072] Example 64 is a method of delivering physiological glucose concentration management guidance, comprising receiving data indicating 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 a temporal pattern.

[0073] In Example 65, the subject matter of Example 64 includes, optionally, that the temporal pattern includes a learning pattern of the patient's behavior.

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

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

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

[0077] In Example 69, the subject matter of any one or more of Examples 64-68 includes, optionally, that the model includes a physiological model, determining a state includes determining a physiological state, and determining a guidance message includes determining from a temporal pattern and a 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, optionally, that determining a guidance message includes determining an intervention to avoid a transition to an undesirable physiological state and determining a delivery time of the guidance message to enable an intervention to prevent the transition, at least partially based on the temporal pattern.

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

[0080] In Example 72, the subject matter of Example 71 includes, optionally, determining a delivery time, including selecting a delivery time when it is likely that the host is available at least partially based on a temporal pattern.

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

[0082] In Example 74, the subject matter of any one or more of Examples 64 - 73 includes, optionally, determining a guidance message, including identifying a period when the patient is unavailable at least partially based on a temporal pattern, and including that the guidance message is calculated to promote the stability of glucose concentration during the unavailable period.

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

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

[0085] In Example 77, the subject matter of any one or more of Examples 64 - 76 includes, optionally, including that the state is a disease state that describes the host's disease stage.

[0086] In Example 78, the subject matter of Example 77 includes, as necessary, receiving second data indicating a second glucose concentration level, determining a second disease state that at least partially describes 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 includes, as necessary, determining a state, where determining the state includes determining a physiological state.

[0088] In Example 80, the subject matter of Example 79 includes, as necessary, determining a physiological state, where determining the physiological state includes determining an insulin state, an energy absorption state, and an energy consumption state.

[0089] In Example 81, the subject matter of any one or more of Examples 64 - 80 includes, as necessary, receiving an action input, and determining a state, where determining the state includes applying both data and the action input to a model.

[0090] In Example 82, the subject matter of Example 81 includes, as necessary, receiving an action input, where receiving the action input includes receiving patient activity information.

[0091] Example 83 is a method for delivering physiological glucose concentration management guidance, comprising receiving data indicating a glucose concentration, using the data to determine a physiological state, determining an action state, determining a guidance message based at least in part on the physiological state and the action state, and delivering the guidance message using a user interface.

[0092] In Example 84, the subject matter of Example 83 includes, as necessary, determining a time to deliver guidance that enables timely intervention to affect the glucose concentration.

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

[0094] In Example 86, the theme of Example 85 includes that determining a level of interest in the treatment guidance, at least in part, based on the user requirements of the previous guidance as needed.

[0095] In Example 87, any one or more of the themes of Examples 83 - 86 includes that determining the behavioral state, as needed, includes receiving a behavioral input and applying the behavioral input to a behavioral state model.

[0096] In Example 88, any one or more of the themes of Examples 83 - 87 includes that determining the behavioral state, as needed, includes checking the user calendar for scheduled events.

[0097] In Example 89, any one or more of the themes of Examples 83 - 88 includes that determining the physiological state, as needed, includes applying data to a physiological state model.

[0098] In Example 90, the theme of Example 89 includes that the physiological state model includes a glucose concentration level, as needed.

[0099] In Example 91, the theme of Example 90 includes that the physiological state model further includes one or more of an insulin state, an energy absorption state, and an energy consumption state, as needed.

[0100] In Example 92, any one or more of the themes of Examples 83 - 91 includes determining a measurement state, as needed, where the measurement state includes the accuracy or precision of data indicating glucose concentration.

[0101] In Example 93, any one or more of the themes of Examples 83 - 92 may, as necessary, include determining that a guidance message is to be determined in that a low - probability physiological state transition is likely to occur, and the guidance message provides prior notice of the low - probability physiological state transition.

[0102] In Example 94, the theme of Example 93 may, as necessary, include that a low - probability physiological state transition includes a transition to a low glucose concentration level or a high glucose concentration level.

[0103] In Example 95, any one or more of the themes of Examples 93 - 94 may, as necessary, include determining that a guidance message is to be determined in that a low - probability physiological state transition is likely to occur when it is inconvenient, and the guidance message provides prior warning of the low - probability physiological state transition expected to enable an intervention to avoid the low - probability physiological state transition.

[0104] In Example 96, the theme of Example 95 may, as necessary, include that determining that a low - probability physiological state transition is likely to occur when it is inconvenient may include applying behavioral inputs to a behavioral state model.

[0105] In Example 97, any one or more of the themes of Examples 83 - 96 may, as necessary, include receiving additional physiological parameters, and the physiological state is determined using both the data and the additional physiological parameters.

[0106] In Example 98, the theme of Example 97 may, as necessary, include that the additional physiological parameters include body temperature, heart rate, or respiratory rate.

[0107] In Example 99, any one or more of the themes of Examples 83 - 98 may, as necessary, include receiving learning data that describes at least one of a physiological state or a behavioral state during a learning period, and at least one of the physiological state or the behavioral state is determined after the learning period using the learning data.

[0108] Example 100 is a method for determining and providing a personalized and useful calculated guidance message for a patient for the treatment management of diabetes, comprising receiving data related to the patient, including data on real-time glucose concentration levels, determining the patient's 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 includes, optionally, that the patient state includes an insulin on-board state, an insulin sensitivity state, and a food consumption state.

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

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

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

[0113] Example 105 is a method for providing a decision support function to a user, comprising loading a model into the memory of a computing environment, receiving data indicating the user's glucose concentration value, and displaying the calculated insights on a user interface of the computing environment, wherein the insights are calculated using at least the model and the data indicating the glucose concentration value.

[0114] In Example 106, the subject matter of Example 105 includes, optionally, that the displaying is initiated by a user request.

[0115] In Example 107, the subject matter of Example 106, as needed, includes that user requirements are associated with data input for planned activities, the calculated insights indicate the user's actions calculated by one or more models, and a desired result is brought about that is associated with the glucose concentration value.

[0116] In Example 108, the subject matter of Example 107, as needed, includes that the desired result is 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, as needed, includes that 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, as needed, includes that the planned activity is a meal and the calculated insight is the calculated or predicted effect of the meal on the glucose concentration value.

[0119] In Example 111, the subject matter of any one or more of Examples 107 - 110, as needed, includes that the displayed calculated insight includes at least one factor used for interactive recommendations and the determination of interactive recommendations.

[0120] In Example 112, the subject matter of any one or more of Examples 105 - 111, as needed, includes that displaying the calculated insight is initiated by the occurrence of an event that matches a predetermined condition.

[0121] In Example 113, the subject matter of any one or more of Examples 105 - 112, as needed, includes that displaying the calculated insight is initiated by the occurrence of an event that matches a calculated condition, and the calculated condition is calculated based at least in part on a model, or data indicating a glucose concentration value, or a combination thereof.

[0122] In Example 114, the subject matter of Example 113 includes, as necessary, adjusting warnings and / or alerts to have additional sensitivity for a certain period after a treatment adjustment if the treatment adjustment exposes the user to more risks than existed prior to the treatment adjustment.

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

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

[0125] In Example 117, the subject matter of any one or more of Examples 105 - 116 includes, as necessary, using the received data to detect the occurrence of trends associated with the recognized patterns.

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

[0127] In Example 119, the subject matter of Example 118 includes, as necessary, that the external data source is an insulin pen or pump and that the calculated insights include information regarding insulin on board.

[0128] In Example 120, the subject matter of Example 119 includes, as necessary, that the external data source is an insulin pen or pump and that the calculated insights are represented by two values, one indicating use when the user's exercise is planned and the other indicating use when the user's exercise is not planned.

[0129] In Example 121, any one or more of the themes of Examples 119 - 120 may, as necessary, include that the external data source is an accelerometer and the calculated insight includes information regarding the effect of movement on glucose concentration values.

[0130] In Example 122, any one or more of the themes of Examples 119 - 121 may, as necessary, include that the external data source is a camera or a GPS receiver and the calculated insight includes information regarding the effect of meal size and composition on glucose concentration values.

[0131] In Example 123, any one or more of the themes of Examples 119 - 122 may, as necessary, include that the external data source is a user interface, the user interface is configured to receive data regarding the user's goals, and the calculated insight includes the percentage of time within the target range and the display of the target range.

[0132] In Example 124, any one or more of the themes of Examples 105 - 123 may, as necessary, include loading a measurement model of a continuous glucose concentration monitoring system associated with the user into the memory of a computing environment, and the calculated insight is further based on the measurement model.

[0133] In Example 125, the theme of Example 124 may, as necessary, include that the calculated insight is calculated using an algorithm that is at least partially based on glucose concentration variability or the likelihood and / or severity of glucose concentration fluctuations.

[0134] In Example 126, any one or more of the themes of Examples 105 - 125 may, as necessary, include that the display is based on calculations that are executed periodically.

[0135] In Example 127, the theme of Example 126 may, as necessary, include that the period is determined based on a series of meal times that occur substantially simultaneously.

[0136] In Example 128, any one or more of the themes of Examples 126 - 127 includes that the period is determined based on a series of similar blood glucose responses as needed.

[0137] In Example 129, the theme of Example 128 includes that the similar blood glucose response is a spike as needed.

[0138] In Example 130, any one or more of the themes of Examples 126 - 129 includes that the period is determined based on a series of similar dosing strategies as needed.

[0139] In Example 131, any one or more of the themes of Examples 126 - 130 includes that the period is determined based on a series of unreliable results in which the glucose concentration level drifts over a specified percentage or amount away from the target zone following a potential treatment decision as needed.

[0140] In Example 132, any one or more of the themes of Examples 105 - 131 includes that the display of the calculated insights includes the display of a probability cone based on the user's previous data as needed.

[0141] In Example 133, any one or more of the themes of Examples 105 - 132 includes that the display of the calculated insights includes the display of a probability cone based on population data as needed.

[0142] In Example 134, the theme of Example 133 includes that the population data is extracted from people having one or more demographic characteristics in common with the user as needed.

[0143] In Example 135, any one or more of the themes of Examples 105 - 134 includes that the display of the calculated insights includes the display of two separate trend indicators, one determined using data measured on weekdays and the other determined using data measured on weekends, as needed.

[0144] In Example 136, any one or more of the themes of Examples 105-135 optionally include that insights are calculated by a computing environment.

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

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

[0147] In Example 139, the theme of Example 138 optionally includes that the behavioral model is configured to determine a level of a concern factor, and the level of the concern factor is selected from the group consisting of a concern regarding a physiological state, a result of a treatment decision, and / or a potential future state.

[0148] In Example 140, the theme of Example 139 optionally includes that a concern regarding a physiological state is determined by detecting a frequency of checking an application related to diabetes or by detecting a frequency at which SMBG values are input.

[0149] In Example 141, any one or more of the themes of Examples 139-140 optionally include that the behavioral model is configured to determine a level of an involvement factor, and the level of the involvement factor is selected from the group consisting of a reaction time, a level of a treatment activity, and / or a type of support.

[0150] In Example 142, any one or more of the themes of Examples 139-141 optionally include that the computing environment is a mobile device, and the method further comprises learning a physiological model by a second computer system, and 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 includes, optionally, learning an action model by a second computer system, and loading the model into the memory of a computing environment includes loading the learned action model into a mobile device.

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

[0153] Example 145 is 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, a memory circuit including a stored model, and a processor configured to receive host glucose concentration data detected by the glucose concentration sensor, determine a host state change associated with the host glucose concentration data, determine a guidance message at least in part based on the host state change, and deliver the guidance message via a user interface.

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

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

[0156] In Example 148, any one or more of the themes of Examples 145-147 includes, as necessary, determining a host state change, identifying a likely transition to an undesirable host state, and determining and delivering a guidance message at once so that the host can intervene to avoid a transition to an undesirable host state.

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

[0158] In Example 150, the theme of Example 149 includes, as necessary, the mobile device including a communication circuit, and the glucose concentration sensor including a glucose concentration sensor communication circuit configured to communicate with the communication circuit.

[0159] In Example 151, any one or more of the themes of Examples 149-150 includes, as necessary, the mobile device communication circuit including a first radio transceiver, the glucose concentration sensor communication circuit including a second radio transceiver, and the mobile device communication circuit and the glucose concentration sensor communication circuit communicating using a wireless communication protocol.

[0160] In Example 152, any one or more of the themes of Examples 145-151 includes, as necessary, an insulin delivery system.

[0161] In Example 153, any one or more of the themes of Examples 145-152 includes, as necessary, the state change being from a first disease state describing a first host disease stage to a second disease state indicating a second host disease stage, and the processor being further configured to determine a second guidance message at least in part based on the second disease stage.

[0162] Example 154 is a method for delivering physiological glucose concentration management guidance, comprising receiving data indicating 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 includes, optionally, determining whether the patient state is atypical, which includes determining whether the patient state is atypical for a given set of conditions.

[0164] In Example 156, the subject matter of any one or more of Examples 154 - 155 includes, optionally, determining whether the patient state is atypical, which 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 includes, optionally, determining the guidance message, which includes determining whether a low - likelihood state transition is predicted to occur.

[0166] In Example 158, the subject matter of any one or more of Examples 154 - 157 includes, optionally, determining the patient state, which includes 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 includes, optionally, determining whether the patient state is atypical, which includes identifying a blood glucose concentration level that deviates from the range of blood glucose concentrations that are normally managed over time or in a situation when the blood glucose concentration is within the normally managed range.

[0168] In Example 160, any one or more of the themes of Examples 154-159 may, as necessary, include determining whether the patient's condition is atypical, which, when the blood glucose concentration is normally within the controlled range, includes identifying a blood glucose concentration trend that leads to elevated or low blood glucose concentration states depending on time or situation.

[0169] In Example 161, any one or more of the themes of Examples 154-160 may, as necessary, include determining whether the patient's condition is atypical, which, when the blood glucose concentration is normally well controlled, includes predicting a shift to a low blood glucose concentration state either once or depending on the situation.

[0170] Example 162 is a method for delivering physiological glucose concentration guidance that includes receiving data indicating glucose concentration, determining the patient's condition 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.

[0171] In Example 163, the theme of Example 162 may, as necessary, include the method determining that a low-probability state transition is likely to occur, and the guidance message providing a prior notice of the low-probability state transition.

[0172] In Example 164, any one or more of the themes of Examples 162-163 may, as necessary, include the low-probability physiological state transition including a transition to a low glucose concentration level or a high glucose concentration level.

[0173] In Example 165, any one or more of the themes of Examples 162-164 may, as necessary, include determining the guidance message including determining that a low-probability state transition is likely to occur when it is inconvenient.

[0174] In Example 166, the subject matter of Example 165, as necessary, includes a reference to the user's calendar of scheduled events to determine that a low-probability state transition is likely to occur when it is inconvenient.

[0175] In Example 167, any one or more of the subject matters of Examples 165-166, as necessary, includes a reference to the behavioral state model to determine that a low-probability state transition is likely to occur when it is inconvenient.

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

[0177] In Example 169, the subject matter of Example 168, as necessary, includes a reference to the calendar of scheduled events to determine a period during which a patient is likely to take action to prevent a low-probability state transition.

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

[0179] In Example 171, any one or more of the subject matters of Examples 168-170, as necessary, includes using a model to determine a period during which a patient or caregiver is likely to be available, including using the pattern of the user's activities or the user's location information.

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

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

[0182] In Example 174, the subject matter of any one or more of Examples 172-173 includes, optionally, receiving a behavioral, environmental, or context input, including 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 includes, optionally, receiving a behavioral, environmental, or context input, including receiving an input from a user via a user interface.

[0184] In Example 176, the subject matter of any one or more of Examples 172-175 includes, optionally, receiving a behavioral, environmental, or context input, including receiving information from a user about completion, start, or anticipation of exercise.

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

[0186] In Example 178, any one or more of the themes of Examples 172 - 177 may, as necessary, include receiving one or more actions, environments, or context inputs, including receiving location information.

[0187] In Example 179, any one or more of the themes of Examples 172 - 178 may, as necessary, include receiving one or more actions, environments, or context inputs, including receiving ambient temperature or ambient pressure.

[0188] In Example 180, any one or more of the themes of Examples 172 - 179 may, as necessary, include receiving body temperature, heart rate, or respiratory rate.

[0189] In Example 181, the theme of Example 180 may, as necessary, include learning a model based on one or more patterns of the received information.

[0190] In Example 182, the theme of Example 181 may, as necessary, include learning a model, including learning a pattern of insulin sensitivity as a function of time.

[0191] In Example 183, the theme of Example 182 may, as necessary, include learning a model, including learning a pattern of insulin sensitivity as a function of the time elapsed after a period of physical activity.

[0192] In Example 184, any one or more of the themes of Examples 172 - 183 may, as necessary, include determining a user query and providing the user query to the user, where the action, environment, or context input is received in response to the user query.

[0193] In Example 185, any one or more of the themes of Examples 172 - 184 may, as necessary, include receiving data indicating glucose concentration, including 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 communication 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 at least partially based 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 that the time is calculated to enable intervention, if necessary, before the host transitions to an undesirable physiological state.

[0196] In example 188, the subject matter of any one or more of examples 186 - 187 includes that determining the guidance message is at least partially based on a personalized behavior model of the host, and the time is calculated such that it is useful for the host in the treatment management of diabetes.

[0197] In example 189, the subject matter of any one or more of examples 186 - 188 includes that determining the state is at least partially based on a physiological model of the patient and a behavior model of the patient, if necessary.

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

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

[0200] In Example 192, the subject matter of any one or more of Examples 190 - 191 further includes, optionally, that the model includes a state indicating the convenience or availability of the patient participating in the intervention, as appropriate.

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

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

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

[0204] In Example 196, the subject matter of Example 195 further includes, optionally, that the model further includes a behavior model, as appropriate.

[0205] In Example 197, the subject matter of Example 196 further includes, optionally, that the behavior model is based on the machine - learning characteristics of the patient, and that the machine - learning characteristics are based on behaviors or context patterns, as appropriate.

[0206] In Example 198, the subject matter of any one or more of Examples 196 - 197 further includes, optionally, that the behavior model is based on a set of one or more steps determined to be highly likely to be performed by the patient, as appropriate.

[0207] In Example 199, any one or more of the subjects of Examples 196-198 optionally includes that the behavioral model is based on one or more sets of goals determined to be highly likely to be achievable by the patient.

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

[0209] In Example 201, any one or more of the subjects of Examples 196-200 optionally includes that the patient's physiological model is based on a physiological pattern and the behavioral model is based on a behavioral pattern.

[0210] In Example 202, the subject of Example 201 optionally includes that the first real-time data indicates a deviation from the predicted behavioral pattern.

[0211] In Example 203, the subject of Example 202 optionally includes that the behavioral model tends to overcorrect a meal associated with a meal time, the first real-time data indicates that a meal time is approaching, and the guidance message corresponds to a reduction in overcorrection during the meal.

[0212] In Example 204, the subject of Example 203 optionally includes that the behavioral pattern includes a long-term behavioral pattern based on a long-term pattern of behavior and a short-term behavioral pattern related to current behavior.

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

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

[0215] In Example 207, one or more of the subjects of Examples 190-206, as necessary, includes determining a state further based on a measurement model.

[0216] In Example 208, the subject of Example 207, as necessary, includes the measurement model being based on a continuous glucose monitoring system related to a patient.

[0217] In Example 209, the subject of Example 208, as necessary, includes measuring glucose concentration data after determining a guidance message and improving one or more models using the measured subsequent data.

[0218] In Example 210, the subject of Example 209, as necessary, includes the glucose concentration data measured subsequent to the determination being fed back to a measurement model or an action model or a physiological model of the patient, or a combination thereof.

[0219] In Example 211, one or more of the subjects of Examples 190-210, as necessary, includes the model including a pattern selected from the group consisting of a physiological pattern, a context pattern, an action pattern, or a combination thereof.

[0220] In Example 212, the subject of Example 211, as necessary, includes the physiological pattern being based on a physiological model.

[0221] In Example 213, one or more of the subjects of Examples 190-212, as necessary, includes the model being based on a combination of patterns selected from the group consisting of a physiological pattern, a context pattern, or an action pattern.

[0222] In Example 214, any one or more of the subjects of Examples 190-213 may further include, as necessary, determining a guidance message, 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 based on the state and the first real-time data.

[0223] In Example 215, the subject of Example 214 may further include, as necessary, that the selection is further based on a ranking scheme, a prioritization scheme, or a comparison of a plurality of guidance messages with one or more associated thresholds.

[0224] In Example 216, any one or more of the subjects of Examples 190-215 may include, as necessary, determining the patient's expected diabetes response based on the state and the first real-time data, where the guidance message is further personalized for the patient based on the expected diabetes response, and the patient is provided with an executable message calculated to move the expected diabetes response towards the desired diabetes response.

[0225] In Example 217, the subject of Example 216 may include, as necessary, that the desired diabetes response is related to the state and the first real-time data, and the desired diabetes response is selected from the group consisting of an improved diabetes response, a potentially improved diabetes response, an ideal response, or an optimized response.

[0226] In Example 218, the subject of Example 217 may include, as necessary, that the guidance message is based on a functional relationship between the expected diabetes response and the desired diabetes response.

[0227] In Example 219, the subject of Example 218 may include, as necessary, that the functional relationship is the difference between the glucose concentration level associated with the expected diabetes response and the glucose concentration level associated with the desired diabetes response.

[0228] In Example 220, the subject matter of Example 219 includes, optionally, that the glucose concentration level related to the desired diabetes response is the target glucose concentration level or target glucose concentration range.

[0229] In Example 221, the subject matter of Example 220 includes, optionally, that the functional relationship is based on whether the expected diabetes response meets a predetermined condition related to the desired diabetes response.

[0230] In Example 222, the subject matter of Example 221 includes, optionally, that the predetermined condition is the target glucose concentration level, target glucose concentration range, glucose concentration signal signature, or rate of change related to the glucose concentration level.

[0231] In Example 223, the subject matter of any one or more of Examples 217 - 222 includes, optionally, that the guidance message further includes one or more reasons related to the functional relationship, whereby the patient can be notified of the reason for providing the guidance message.

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

[0233] In Example 225, the subject matter of Example 224 includes, optionally, that the guidance message includes an executable prompt calculated to move the patient's glucose concentration level towards the target level or target range.

[0234] In Example 226, the subject matter of any one or more of Examples 190 - 225 includes, optionally, that the guidance message includes an affirmation of the patient's current actions.

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

[0236] In Example 228, one or more of the subjects of Examples 190-227 optionally include that the first real-time data is measured, received, or determined by a wearable device.

[0237] In Example 229, one or more of the subjects of Examples 190-228 optionally include that the first real-time data is measured, received, or determined by a wearable device in combination with a smartphone.

[0238] In Example 230, one or more of the subjects of Examples 190-229 optionally include that the first real-time data is measured, received, or determined by an external device.

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

[0240] In Example 232, one or more of the subjects of Examples 190-231 optionally include that the first real-time data is the time, a characteristic or signature signal measured by an accelerometer, or a location determined by a GPS circuit.

[0241] In Example 233, one or more of the subjects of Examples 190-232 optionally include that the first real-time data is a change in state.

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

[0243] In Example 235, one or more of the subjects of Examples 190-234 optionally include that the first real-time data is a user request for a decision support prompt.

[0244] In Example 236, one or more of the subjects of Examples 190-235 optionally include that the first real-time data is received from a continuous glucose monitoring system.

[0245] In Example 237, any one or more of the subjects of Examples 190 - 236 includes, as necessary, measuring, determining, or receiving second real-time data, where the second real-time data is used in determining the patient's condition.

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

[0247] In Example 239, any one or more of the subjects of Examples 190 - 238 includes, as necessary, the condition being a disease state that describes the patient's disease stage.

[0248] In Example 240, the subject of Example 239 includes, as necessary, measuring, determining, or receiving second real-time data indicating a second glucose concentration level, determining a second disease state that at least partially describes the second patient's 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.

[0249] In Example 241, any one or more of the subjects of Examples 190 - 240 includes, as necessary, the condition being an engagement state, and further determining a messaging frequency based at least in part on the engagement state, and determining a time for providing a personalized guidance message based at least in part on the messaging frequency.

[0250] In Example 242, any one or more of the subjects of Examples 190 - 241 includes, as necessary, receiving learning data during a learning period and determining the patient's condition based at least in part on the learning data.

[0251] Example 243 is to learn a personalized behavior model of a patient, receive real-time data, and determine a personalized guidance message provided to the patient, where the determination of the personalized guidance message is based at least in part on the time of determination of the personalized guidance message and the personalized behavior model of the patient, and determine a delivery time for providing the personalized guidance message using the learned personalized behavior model, and the delivery time is calculated to be useful to the patient in the treatment management of the patient's diabetes, and it is a method for determining and delivering a calculated guidance message that is personalized and useful to the patient in the treatment management of diabetes.

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

[0253] In Example 245, the subject matter of Example 244 includes, optionally, that the first characteristic is a pattern selected from the group consisting of a physiological pattern, a context pattern, or a behavior 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 the delivery time.

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

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

[0257] In Example 249, the subject matter of Example 248 includes that receiving the first real-time data, if necessary, is a time.

[0258] In Example 250, the subject matter of any one or more of Examples 248 - 249 includes that the patient's physiological model, if necessary, 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 includes learning the model from a set of input data, if necessary.

[0260] In Example 252, the subject matter of Example 251 includes, optionally, that a set of input data includes one or more of clock time, time, glucose concentration level, insulin on board, patient activity, patient health, day of the week, date, 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 includes, optionally, determining a deviation from an expected state after delivering a personalized guidance message and adapting a model based on additional input information.

[0262] In Example 254, the subject matter of Example 253 includes, optionally, that a 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, optionally, that providing a 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 disclosure will be apparent to those of ordinary skill in the art from viewing the drawings, which form a part of it and are not to be construed in a limiting sense, and from reading the following detailed description.

[0265] In the drawings, which are not necessarily drawn to scale, like reference numerals may describe like components in different figures. Like reference numerals with different suffixes may represent different instances of like components. The drawings generally illustrate, by way of example and not limitation, various embodiments described in this document.

Brief Description of the Drawings

[0266]

Figure 1

Figure 2A

Figure 2B

Figure 3A

Figure 3B

Figure 3C

Figure 3D

Figure 4

Figure 5A

Figure 5B

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16a

Figure 16b

Figure 16c

Figure 16d

Figure 16e

Figure 16f

Figure 17

Figure 18A

Figure 18B

Figure 19

Figure 20

Figure 21

Figure 22A

Figure 22B

Figure 23

Figure 24

Figure 25A

Figure 25B

Figure 26

Figure 27A

Figure 27B

Figure 28

Figure 29

Figure 30

Figure 31A

Figure 31B

Figure 32A

Figure 32B

Figure 33

Figure 34

Figure 35

Figure 36

Figure 37

Figure 38

Figure 39

Best Mode for Carrying Out the Invention

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

[0268] Overview A system that provides guidance and determines when to deliver the guidance calculated to be useful to a user (e.g., a patient, caregiver, or clinician) can assist the user in sleeping better by knowing, for example, how to obtain uninterrupted sleep so that glucose levels can be managed, or how to avoid highs and lows during sleep with peace of mind, or how to improve sleep by acting based on pre-sleep guidance, or when there are potential problems that need to be addressed. The system can alternatively or additionally assist the user in eating better by, for example, providing guidance from a decision support system so that the patient can stay within range, regardless of what the patient eats, after eating, or can stay within range after eating, or have the confidence to know that the treatment is safe and effective and feel at ease. The system can alternatively or additionally assist the user in having a better life (e.g., improving quality of life) by, for example, knowing when the user needs to pay attention to diabetes problems (e.g., glucose levels), or when the user needs to adapt to unexpected events during the day while maintaining glucose levels in a managed state, or by recognizing potential or possible excursions in advance and knowing when to respond or react to the excursions without overcorrection or overeating (e.g., excessive carbohydrate intake).

[0269] In some examples, the delivered guidance can help patients, caregivers, or healthcare providers improve their lifestyle or clinical / patient outcomes by addressing various issues such as nighttime blood glucose control (e.g., reducing the incidence of hypoglycemic events or hyperglycemic excursions), in-meal and post-meal blood glucose control (e.g., using history information and trends to improve blood glucose control), hyperglycemic correction (e.g., increasing the time in the 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 a treatment optimization tool that learns the patient's physiology and behavior and calculates guidance that helps the patient identify optimal or desirable treatment parameters such as basal insulin requirements, insulin-to-carbohydrate ratios, correction factors, or changes in insulin sensitivity due to exercise. The decision support tool can assist the patient in reacting to problems in real time, for example, by predicting hypoglycemic or hyperglycemic events or trends, addressing the occurrence or potential hypoglycemic or hyperglycemic events or trends, and providing treatment recommendations for monitoring how blood glucose, physiology, or behavior responds in real time. This type of calculated guidance and support can reduce the cognitive burden on the patient, caregiver, or medical professional.

[0270] Physiological sensors, such as continuous glucose monitoring, can provide useful data that can be used by patients, caregivers, or medical professionals to manage glucose levels. However, significant processing of the data may be required to develop effective strategies for glucose management. Recognition of the vast amounts of data and the correlations between data types, trends, events, and outcomes can potentially far exceed human processing capabilities. This is particularly influential when decisions regarding treatment or responses to physiological states are being made in real time. Integration of real-time or recent data with historical data and patterns can provide useful guidance in making real-time decisions regarding treatment. Technical tools can process this information to provide decision-making support guidance that is calculated to be useful for a particular patient in a particular state or situation at a particular time. Technical tools can also reduce the cognitive burden on human decision-makers by performing repeated calculations throughout the day and determining when to delay or deliver guidance.

[0271] The decision-making support system can be particularly useful in developing pre-sleep guidance to increase the likelihood that glucose levels are controlled during sleep. For example, the system can use an algorithm or model to determine whether hyperglycemic or hypoglycemic events are possible or likely, and create guidance, which can be, for example, pre-sleep behavioral items such as insulin delivery, food intake (e.g., fast carbohydrates, slow carbohydrates, or carbohydrates combined with protein), or set an alarm to check the status or check the guidance at a specific time. The system can also provide context-dependent warnings using an algorithm or model. For example, the system can recognize from human input or sensor input or behavioral patterns that the user is asleep or trying to sleep, and take into account sleep activity when calculating the time to deliver a warning or alert. In some examples, the system can delay the delivery of a warning or guidance (e.g., until a risk condition is met or an intervention time window opens) so as not to unnecessarily wake the patient or caregiver. In some examples, the system can calculate the time to deliver guidance (and warnings that may wake the patient or time provider) to increase the likelihood that more disruptive interventions are not available. For example, the system can determine whether an inquiry is desirable (e.g., checking for low pressure, or checking a fever or blood glucose or other physiological sensor) or a basal or bolus adjustment is needed to avoid hyperglycemic events with timely insulin delivery via injection or pump, or to avoid hypoglycemic events by reducing insulin delivery via the pump and later waking the patient to deliver carbohydrates via food or beverage.

[0272] A decision support system configured to calculate guidance and the timing of guidance can also, for example, provide guidance regarding potential outcomes, notifications of when a decision may be required, or guidance regarding the potential impact of therapeutic interventions or behavioral decisions (e.g., exercise, rest, or eating), to facilitate the transition to a new treatment or a new environment, or the progression of a disease over time (e.g., changes in pancreatic function or the fading of the "honeymoon" period of partial pancreatic function, changes in the treatment routine of type II diabetes patients, etc.).

[0273] The decision support system can determine guidance using various information sources, such as patterns related to eating behavior and other information (e.g., the number of meals per day, the distribution of meal sizes for meals and snacks overall, the size of the treatment for hypoglycemic excursions, or the number of repeated treatments for hypoglycemic events), insulin dosage information (e.g., bolus and basal dosage patterns, pump settings or injection patterns, the number of boluses per day, the amount of trend adjustment, pre-meal bolus patterns, behavioral boluses before and after correction, the number of correction boluses per day, behavioral patterns (the presence and accuracy of carbohydrate counting, the incidence of activity or non-response in response to hyperglycemia, or the need for correction boluses, the state of correction, thresholds or needs (e.g., glucose levels, combinations of trends and levels, foods or other factors), recognition of insulin on board, the timing of insulin, the pre-meal "pre-bolus" pattern and its duration, errors in insulin delivery or therapeutic interventions, exercise timing, exercise duration, and exercise intensity, physiological responses to activity), physiological factors (patterns of response to insulin, carbohydrates, and other foods, the tendency to "rebound" to hyperglycemia after low glucose, the effect of illness or medication on insulin sensitivity or glucose levels), responsiveness to guidance (the time to acknowledge warnings or alerts, actions taken in response to warnings or alerts (e.g., meals, sleep, or exercise), and blood glucose results (e.g., the percentage of time below one or more glucose concentration thresholds (e.g., less than 70 mg / dL, less than 50 mg / dL), the percentage of time above one or more glucose concentration thresholds (e.g., above 180 mg / DL, above 250 mg / DL), and the number of events below or above one or more thresholds), stage of illness 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), etc. Additional exemplary inputs are described below.

[0274] The decision support system can communicate or interact with other systems, such as glucose delivery devices (e.g., pumps or smart pens) and other analysis systems.

[0275] The exemplary embodiments disclosed herein relate to the use of a glucose sensor that measures the concentration of glucose or the concentration of another analyte or the concentration of a substance indicative of the presence thereof. In some embodiments, the glucose sensor is a continuous device, such as a subcutaneous, transdermal, percutaneous, 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, spectrophotometry, spectroscopy (e.g., light absorption spectroscopy, Raman spectroscopy, etc.), polarimetry, calorimetry, ionophoresis, radioassay, and the like.

[0276] The glucose sensor can use any known detection method, including invasive, minimally invasive, and non-invasive sensing techniques, to provide a data stream indicative of the concentration of the analyte within the host. The data stream is typically a raw data signal that is used to provide a useful value of the analyte to users such as patients and healthcare providers (HCPs, e.g., physicians, doctors, nurses, caregivers) who can use the sensor.

[0277] Many of the explanations and examples are directed to a glucose sensor that can measure the concentration of glucose in a host, but the systems and methods of the embodiments can be applied to any measurable analyte. Some of the exemplary embodiments described below utilize an implantable glucose sensor. However, it should be understood that the devices and methods described herein can be applied to any device that can detect the concentration of an analyte and provide an output signal representative of the concentration of the analyte.

[0278] In some embodiments, the analyte sensor is an implantable glucose sensor as described with reference to U.S. Patent No. 6,001,067 and U.S. Patent Application Publication No. 2011-0027127. In some embodiments, the analyte sensor is a transcutaneous glucose sensor as 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 as 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 blood vessel or extracorporeally as described in U.S. Patent Application Publication No. 2007-0027385. These patents and publications are hereby incorporated by reference in their entirety.

[0279] A system and method for decision-making assistance using lifestyle factors are described in U.S. Patent Application No. 15 / 417,008, entitled "System and Method for Decision-Making Assistance Using Lifestyle Factors," which claims the benefit of U.S. Provisional Patent Application No. 62 / 289,825, filed on February 1, 2016, both of which are hereby incorporated by reference in their entirety.

[0280] Overview of an Exemplary System Delivering guidance either once or in a situation that promotes timely action of such guidance can promote effective diabetes management and reduce the burden of blood glucose management. This may be due, at least in part, to the relevance of the guidance or the availability and interest for the patient or caregiver to receive and act on it. In various examples, sources of real-time data, models or other pattern information, patient input, and other sensors as well as user-specific information can be used to determine the time for determining and delivering the guidance.

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

[0282] In some examples, exemplary real-time decision support systems and methods can provide guidance to a patient in real time, i.e., at a time when the patient can intervene in glucose management to avoid undesirable glucose levels or trends, and at a time calculated to be useful to the patient. The timing of such real-time guidance delivery can be determined using information from, for example, a calendar, physiological sensors, or context sensors such as GPS or wireless connections, so that the guidance can be delivered at a time calculated to be possible or convenient for real-time intervention by 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 (referred to as "CGM" and further described below). A continuous glucose monitor can provide information about the patient's glucose level (referred to as "CGM data") at regular intervals such as once a minute or once every five minutes, or on demand. The information can be pushed by the CGM, held on an external device such as a smartphone or sensor, or retrieved by another handheld device that is swiped.

[0284] An exemplary real-time decision support system can also include a processing system that receives CGM data and information such as insulin delivery, calorie consumption, activity, health or illness status, condition, environment, patient behavior, or other sensed or user-entered information related to health. The CGM data and other data can be combined and processed to create guidance for delivery to the patient. The guidance can be based on timing factors such as the timing of insulin delivery, calories consumed, types of calories consumed, absorption or digestion times of food or beverage types or amounts or combinations, exercise timing and post-exercise oxygen or calorie consumption, and the availability or convenience to the patient of interventions such as changes in insulin delivery or delivery, or changes in exercise or diet.

[0285] Model In some examples, a model can be constructed to process 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 the analysis of 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 behavior model or a context model. In some examples, the decision support can be driven by, for example, 1) a physiological model and separate behavior and context models, or 2) at least three models: a physiological, behavior / context model, and a measurement model (further described below). Other variations with multiple models and sub-models are possible.

[0286] Physiological model In some examples, a patient's physiological state can be determined by applying one or more inputs to a physiological model. One or more physiological states can be used to determine guidance for the patient, the timing of the guidance, or both. For example, one or more inputs (see, e.g., FIGS. 2B, and 14-16 and their descriptions, which are described in detail below) can be applied to the model or models to determine the patient's physiological state. The physiological state can include, for example, a glucose concentration level (e.g., the glucose concentration in blood glucose or other body fluids such as interstitial fluid), a decrease or increase in the glucose concentration level (i.e., a glucose trend), or the rate of decrease or increase in the glucose concentration level (e.g., a gradient or a high-level derivative). The determined physiological state can also be an activity level (e.g., motion detected from an accelerometer, a heart rate sensor, or a respiratory sensor), a metabolic drive (e.g., a glucose consumption rate), and insulin resistance (e.g., in response to stress hormone secretion, illness, or high blood glucose levels), insulin sensitivity (described in detail below), insulin on board, insulin action time, insulin duration of action, the ratio of carbohydrate to insulin, or can include them. Other physiological states are possible. Behavioral model or context model

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

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

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

[0290] Determination of guidance and timing The decision-making support engine can determine guidance for a user (such as a patient or caregiver like a parent or clinician) and the timing of guidance decision or delivery, at least partially based on the state of one or more models, and provide the guidance to the user via a user interface such as a mobile device. The decision-making support engine can provide "real-time" guidance based on recent information (such as recent CGM data) that can be used for the user to affect the trend of blood glucose levels (e.g., avoid trends or levels of high or low glucose concentrations).

[0291] Use of machine learning for determining states and guidance In some examples, machine learning methods can be used empirically to identify possible states. In other words, the region of possible states can be estimated from a set of data. For example, the "post-activity state" can be identified as a state of increased insulin sensitivity up to a specific period (e.g., 8 hours) after exercise. Then, in real time, the system can use real-time exercise data (such as activity data, heart rate, or respiration) to confirm that the user is in such a state and provide guidance for the user to take less insulin than normal 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 applicable when in that state. In other examples, machine learning techniques can be used to determine that a patient always ignores warnings at a specific time period (e.g., from 3 pm to 5 pm), and thus the system can turn off unimportant warnings during those time periods and trigger a risk report as guidance just before the period (such as just before 3 pm), or deliver a pre-warning to the user to prepare the user for the period when warnings tend to be ignored.

[0292] Exemplary system Figure 1 shows an exemplary system 100 for determining guidance and the timing of guidance using sensor inputs and a model. The system can process physiological inputs, such as inputs related to the management of glucose concentration levels, to determine a time that is calculated to be useful for a patient or other user for guidance determination or delivery.

[0293] System 100 can include a decision support engine 104 that processes information about a patient (e.g., received real-time sensor data) and combines the sensor information with patterns, such as temporal, physiological, or behavioral patterns, or combinations thereof, to generate an 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 as guidance to patient 102 via 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] Exemplary Inputs Exemplary Implementations of the Decision Support Engine One or more sensors 106 can be associated with the patient to provide information about the patient to the decision support engine 104. The sensors 106 can include, for example, analyte sensors such as glucose sensors as described above. The sensors 106 can be transcutaneous sensors, body fluid sensors such as contact lens sensors or skin sensors, or implantable sensors configured to measure the quality of interstitial fluid or blood. For example, the sensors 106 can be subcutaneous, transcutaneous, transdermal, non-invasive intraocular and / or intravascular glucose sensors as described above. In some examples, the sensors are Dexcom TM 、Abbot TM (e.g., Libre TM sensors), or Medtronic TM(For example, Enlite TMIt can be a wearable or implantable sensor connected to patient 102, such as a continuous glucose monitoring sensor available from a sensor). Other types of sensors can also be associated with the patient, such as a heart rate sensor, a respiration sensor, other types of analyte sensors, a motion sensor (e.g., an accelerometer), a posture sensor (e.g., a three-axis accelerometer), or an acoustic sensor (e.g., for capturing ambient or internal sounds). Sensor 106 can be wearable, for example, on a watch, glasses, contact lenses, a patch wristband, an ankle band, or other wearable items, or can be incorporated into a handheld device (e.g., a smartphone), or can be incorporated into other sensors such as a continuous glucose monitoring sensor. In some examples, sensor 106 can include a multi-sensor patch that can detect, for example, glucose level, heart rate, respiration (e.g., using impedance), activity (e.g., using an accelerometer), posture (e.g., using an accelerometer), electrodermal response, tissue fluid level (e.g., using impedance or pressure). In some examples, an array or network of sensors can be associated with the patient. One or more sensors 106 can communicate with a local device 108 that 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 historical data or knowledge of the joint distribution of signals (e.g., how sensor signals are related to each other or move together) to A) determine or substitute missing sensor data points (e.g., using a model or algorithm or calculation as further described below), or B) predict future blood glucose concentration levels, or C) detect performance problems of a CGM sensor based on sensor failures or joint signals recorded in real-time and historical information, or D) estimate the amount of carbohydrates, fats, proteins, or other substances ingested based on sensor information, or any combination thereof.

[0295] The decision support engine 104 can receive the sensed information 120. The sensed information 120 can include physiological function data such as, for example, 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 connection information (e.g., Wi-Fi).

[0296] The input 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 communicate wirelessly to a system to relay insulin delivery information, e.g., to the decision support engine, via a smart device that can track insulin delivery. The insulin data can also be received from a user, such as a patient or caregiver, via a user interface on a smartphone or other computer device.

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

[0298] Exemplary implementation of the decision-making support engine The decision-making support engine can include one or more models 110. The one or more models 110 can include, for example, a state model. In one example, the "virtual patient" model can include known information about a patient based on a template model formed from known factors, or derived from population data, or learned from information about the patient, or a combination thereof. The model can reflect, for example, physiological information and behavioral information. Physiological information can include factors such as, for example, glucose or insulin sensitivity, response to physical activity or 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 schedule, interest in guidance, and the like. In a state model, factors such as these can be represented as a state, 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, for example, physiological patterns, context patterns, or behavioral patterns, or combinations of these patterns. The physiological pattern can be based on, for example, a physiological model.

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

[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., cloud servers) via 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 sensor 106. The cloud server can also collect other information such as user calendar information, e.g., information received from the calendar of a patient or a patient caregiver. 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 can receive support 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 a 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 can have a higher processing capacity. The hybrid configuration can maintain or improve the performance of the local device 108 by avoiding overloading the local device with overly complex processing tasks. The hybrid configuration can also improve the performance of the system because some tasks can be quickly executed without network access by the local device 108, but more complex tasks are also possible by leveraging the greater processing capacity of the remote resource 109.

[0301] In practice, 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 send data to the remote resource 109 periodically (e.g., in real time, or according to a schedule, or when a connection is available, or any combination thereof), and the remote resource can evaluate the data for a particular user periodically, such as once an hour or once a day. The remote resource 109 can examine, for example, the received data, or a data set enhanced by or including 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 an update (e.g., pushed by the remote resource 109 or requested by the local device 108) to the local device to address problems, insights, or model updates learned from the new data or the extended data set.

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

[0303] In one example, the system determines that a problem is likely to occur when the user is likely to be sleeping (e.g., 2:00 am), and calculates a time to deliver guidance when the user is likely to be available (e.g., 9:00 pm) to promote healthy or uninterrupted sleep. The system can avoid low levels at night by recommending actions such as eating a pre-sleep snack to avoid waking the user at night. In one example, the system receives a glucose value and, based on the patient's learning model, determines that the patient is likely to have a hypoglycemic event when the user (caregiver or patient) is likely to be sleeping, and can determine guidance and a time to provide the guidance that does not interfere with the sleep of the patient or caregiver.

[0304] In other examples, the system can determine a pattern of nocturnal blood glucose concentration levels or trends and delivery guidance for changing an action or treatment. For example, the system can recommend a basal rate increase if the system detects a pattern of glucose levels that rise at night such that the glucose concentration level or trend meets a condition (e.g., above a specified value (e.g., 130 mg / DL) or a specified amount of change (e.g., an increase of 30 mg / dL or 40 mg / dL during sleep or a specified period related to sleep (e.g., from 12:00 am to 5:00 am)). In other examples, the system can recommend a basal rate decrease when the system detects a pattern of glucose concentration levels that decrease by a specified amount or rate or otherwise meets a condition.

[0305] In other examples, the system can support meal-time decisions by providing guidance calculated to help maintain blood glucose control while providing the user flexibility in making decisions about what to eat and when. In one example, the system can determine that glucose levels tend to rise before meal time and determine when to deliver guidance regarding a pre-meal correction bolus to avoid the need to delay the meal when meal time arrives. For example, the system can determine that the user needs to “pre-bolus” a specified amount of time before the meal (e.g., deliver insulin 20 minutes before starting the meal), and the system can determine when to deliver guidance for delivering the bolus so that the meal can be started at the planned time or a time 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 food intake) can be determined by the system, and the timing of the guidance can be calculated to give the user the time corresponding to the calculated pre-bolus window. For example, the system can determine that a 30-minute pre-bolus is needed for the patient to affect high glucose levels before eating the next meal. In one example, the system can deliver guidance 30 minutes before the scheduled meal to prompt the user to deliver the pre-bolus. In other examples, the system can provide the user additional time to respond to the pre-bolus; for example, the system can determine that pre-bolus guidance is delivered 60 minutes before the meal to enable a 30-minute notice of the need to deliver the pre-bolus 30 minutes before the meal.

[0306] In other examples of meal times, 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 determine that guidance for delivering an additional dose of insulin should be provided. 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 provided during a meal to deliver additional insulin. In other examples, the system can calculate the time to deliver guidance to avoid interrupting a meal. This can be achieved, for example, by referring to a user calendar, by using a physiological sensor (e.g., an activity sensor) based on patterns of behavior (e.g., average meal times), 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 the patient or caregiver by calculating the time to deliver guidance to provide sufficient advance notice of potential problems (e.g., high glucose variability or low glucose levels) so that the user can adapt their behavior or respond to problems 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 enables the user to take corrective action (e.g., provide a corrective bolus or exercise) to counter the likely excursion. In some examples, the system can make the time to deliver guidance calculable and / or predictable so that the user can concentrate on other activities and anticipate the delivery of guidance. For example, the system can deliver guidance every two hours during the day. In some examples, the system can determine a repeating schedule until the delivery of guidance. In some examples, the system can deliver guidance regarding the need for the user's attention to glucose management. For example, the system can calculate the probability of the need for user intervention (e.g., determine the risk of a blood glucose concentration level outside a specified range) and notify the user when the condition is met (e.g., the probability exceeds a threshold). In some examples, the system can periodically notify the user that no intervention is necessary (e.g., "Looking good: blood glucose is 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 dietary information such as the content of a meal and the expected or actual (current or past) meal time, and can advise the user to check for further guidance within a specified time, such as "Check for further guidance in 30 minutes". In other examples, the system can deliver pre-sleep guidance, such as "Eat a light snack and check again 10 minutes after eating", and can request the user to check after the pre-sleep activity is completed.

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

[0310] In some examples, the guidance timing can be provided in relation to current user activity, based on real-time data and patterns learned from past activity. For example, to determine the time useful for delivering guidance, the system can integrate real-time physiological data (such as CGM data) with known physiological and behavioral patterns (e.g., models) to determine both the nature of the guidance and the guidance timing. The system can, for example, learn the glucose response after a particular meal. If the real-time data suggests that the user is about to eat the same or a similar meal (e.g., determined from GPS information or Wi-Fi connection to a restaurant), the insights can be delivered based on patterns learned from past activity. In other examples, the real-time data can suggest that the user is about to sleep or that a meeting is 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 provided sooner or earlier than otherwise to avoid interrupting future activities (e.g., sleep or meeting).

[0311] In some examples, the timing of guidance determination can balance the need for data to determine a state, the need for timely action, and the need to avoid unnecessary or excessive interruption to the patient. Generally, over time, more data becomes available to obtain a curve fit to a pattern or apply to a model, which can lead to more accurate conclusions regarding a state, probability, or appropriate guidance. For example, four hours after a meal, much of the data regarding the body's reaction to the meal is known. However, one hour later, the full reaction is still unknown, but generally, the system can identify how much the user ate or whether the delivered insulin is appropriate for the consumed meal. Two and a half hours later, these determinations can be made more accurately. In some cases, the user can administer a correction bolus, or, for example, since the user did not consume as much as thought, the user is instructed to eat more and may now be at risk of trending towards 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 available after a 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 a physiological model). The timing can also be based on user settings that can be learned from data (e.g., settings regarding the frequency or timing of warnings, e.g., warn frequently / less frequently, or warn early / late, or warn according to a predetermined or learned schedule), which can be learned from data (e.g., as a state) or entered as user input.

[0312] Returning to the above example of after a meal, it can be determined where between the time the user eats and the time the warning is triggered to trigger the warning. This determination can take into account the fact that if the warning is delayed, for example, if the system waits to determine guidance or the delivery of guidance, the guidance, or the underlying conditions on which guidance may be determined, are likely to become more accurate over time. However, if the system's waiting time is too long, while the system is waiting for data to accumulate, the time frame for the optimal or desirable opportunity to deliver guidance and administer treatment may have passed, for example, undesirable glucose trends or insulin sensitivity levels may occur. When the glucose level rises above the normal range, the patient's body tends to become insulin resistant, which may make it more difficult to use insulin to return the glucose level to the normal range, and thus more doses of insulin may be required. More doses of insulin may increase the risk that the patient will tend towards low glucose levels when insulin resistance (and high glucose levels) are finally overcome. On the other hand, if the glucose level tends to be too low, it may lead to too late administration of glucose, or an overreaction by the patient (e.g., administration of too much fast-acting carbohydrates) or the patient's body (e.g., glycogen release 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 required. In severe cases, the patient may lose cognitive ability and consciousness at very low glucose levels, which may reduce the patient's ability to execute or participate in subsequent guidance.

[0313] When determining the timing of guidance, user convenience may also be considered. For example, if it is known that the user will participate in a meeting within 2 hours, even if the determined state or guidance is less accurate than what is normally acceptable (e.g., the optimal balance between data accumulation and risk avoidance has not been achieved), the system can provide a warning before the meeting to avoid disturbing the user during the meeting or to ensure that the guidance is delivered when an intervention can be performed. In some examples, if the user is in a situation where they do not need to respond to the warning, the system can provide an option to receive the warning earlier, even if the warning or guidance is somewhat less accurate, through, for example, a one-time user input that can correlate or interact with the calendar, or an adjustment of user-controlled settings. For example, if the system knows or can access the user's calendar, the system can provide such prompts and options itself ("Do you want an early warning before the weekly Tuesday afternoon meeting?"). In other examples, the system can receive a request from the user (in the form of insights requested by the user, for example, as further described below).

[0314] In some examples, a state model can be used to balance factors of urgency and inconvenience. For example, the state can include a risk level or the probability of transitioning to an undesirable state (e.g., the risk or probability of tending towards a blood glucose level less than 40 mg / Dl or exceeding 180 mg / DL), and the system can control the determination or delivery of guidance to maintain the risk level or probability within the specified parameters while avoiding inconvenient notification times if possible.

[0315] The system may also take into account the user's sleep schedule. For example, if it is known that the user goes to bed within 4 hours of having a meal, but the blood glucose response to the meal is not yet known, the system can provide guidance on what to do before going to bed in order to improve those situations or avoid the risk of trending towards an undesirable state or glucose level. For example, the system can deliver pre-sleep guidance to manage a correction bolus, make basic adjustments, avoid a persistent high glucose level or a tendency towards a high glucose level, or avoid waking the user for a nocturnal intervention. In other examples, the system can deliver guidance to eat a snack before going to bed in order to reduce the risk of a low glucose level.

[0316] Exemplary output - guidance formats The guidance output from the decision support engine 104 can include, for example, text (e.g., "monitor for unexpected low glucose levels"), sound (e.g., a tone or conversation), or graphics or animations such as a predicted or actual insulin graph, or a probability cone showing the range of possible outcomes from an assumed or completed action such as exercise, food consumption, insulin delivery, or a combination thereof. The probability cone can show the range of potential outcomes over time, and the range of outcomes expands over time. That is, a wider range of options becomes possible (or can meet statistical criteria). The guidance can include warnings, recommendations, or other useful information.

[0317] In some examples, the guidance recommendation screen can show the factors involved 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 (there are 40g of carbohydrates in the pasta, the patient's activity level after lunch is usually moderate, and the current glucose level is normal but decreasing). These factors can be adjusted by the user if the assumptions need to be changed. In some examples, CGM insulin and meal / carbohydrate 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 changes in progress, occurred, or pending that may occur. For example, the system can intentionally skew the blood glucose value low immediately after administering insulin and reduce the likelihood of overcorrection for a limited time.

[0318] In various examples or guidance, the decision support request can use text, email, app notifications, phone calls, or other communication means. 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 allow viewing of messages during a meeting. In some examples, the guidance and decision support requests can be made voice-enabled using automatic speech recognition and natural language understanding.

[0319] Various types of guidance insights are possible. For example, the guidance output can include, for example, event-driven insights 126, user-request insights 128, or periodic insights 130. Event-driven insights 126 can include, for example, time, context, or physiological event-driven insights that are driven by algorithms that identify decision points, such as useful times for delivering actionable guidance. User-request insights 128 can include, for example, guidance for specific treatment decisions at specific times, such as pre-meal insulin delivery, or user requests anticipating events such as meetings, physical activity, or sleep, and the decision support engine 104 can provide guidance in response to the requests. Such guidance can include, for example, the dosage or scheme of recommended basal or bolus insulin, or the amount of exercise, or a plan to monitor or intervene at a specific time or time range. Periodic (non-real-time) insights 130 can summarize patterns, meals, or treatment decisions over several days. For example, periodic insights can include retrospective summaries at the end of periods such as days, weeks, months, or quarters, post-workout summaries, summaries after a certain period of time (e.g., number of hours, or morning or afternoon or night), or variations thereof.

[0320] Examples of event-driven insights 126, user-request 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 determined states or state transitions, physical events, locations, timing patterns (such as calendars), or any combination thereof. For example, the insights can be at least partially triggered by physiological events, such as patterns of blood glucose events that can include, for example, rapidly decreasing glucose levels after a meal or during exercise, or rapidly increasing glucose levels (e.g., after a meal or snack, or a stressful event).

[0322] Insights can take the form of personalized guidance messages that have a particular 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 that precede hypoglycemic and hyperglycemic events and can alert the user with sufficient time to take action. In another example, treatment adjustments can set context-driven alerts: for example, when a treatment adjustment such as an increase in the basal rate is determined to increase the risk of low glucose levels at night, the low glucose warning can be made more sensitive at night for a specified period such as the next two weeks, or a personalized guidance message informing the user of the likelihood of low glucose levels at night can be delivered nightly or more frequently or under a broader set of conditions than before the adjustment. In another example, treatment decisions or treatment events (e.g., forgetting to administer insulin before a meal, e.g., missing a "pre-bolus") can justify an intensification of vigilance (e.g., checking CGM data or recognizing the 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 the 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 glucose risk or glucose exposure, e.g., food or calorie or carbohydrate consumption can be tracked, and an insulin / glucose imbalance can be detected, which can be communicated via personalized guidance ("The amount of food and beverage consumed may be exceeding predictions") or can form the basis of a personalized guidance message ("Depending on the eating pattern, additional insulin may be required"). In some examples, the personalized guidance messages can provide a range of choices stratified by risk and reward.

[0323] In some examples, the decision support engine can determine a bolus recommendation (meal bolus or correction) and determine the time to make the recommendation. The timing of the bolus decision and the delivery of guidance can be calculated to balance the need for guidance and the interest in avoiding interruption to the patient / user and the need for sufficient data to accurately determine the bolus information. In one example, manual input and learned or programmed input (e.g., meal information) may be provided to the bolus calculator. The bolus calculator can be general or personalized, for example, specified to the user's current diabetes state. 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, the typical blood glucose response in a particular situation can be known, which enables comparison of the real-time data with the historical data or patterns derived from the historical data. For example, if the user consumes 60g of carbohydrates and a particular amount of insulin, the resulting glucose level and the tendency that occurs over time can be known from the 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 a particular case, the user indicates that they have consumed a particular meal or amount of carbohydrates (e.g., 60 carbohydrates), but the glucose value produces a different level or tendency from the previous profile (e.g., 160mg / dL glucose level and rising steadily (e.g., 10mg / dL every 5 minutes)), and the system can query the user to obtain corrected meal information or determine the number of carbohydrates the user actually consumed based on the glucose signal and the current guidance or query ("Did you eat something else?" or "Did you not eat the chicken?"), The system can also consider the absorption rate (e.g., fast carbohydrates such as foods high in sugar and refined sugars and slow carbohydrates such as pasta) and the presence of other foods that may affect the glucose tendency, such as proteins and fats that slow the absorption rate of carbohydrates consumed with them.

[0324] In an example of using a state model, the patient's state is initially the first state (e.g., eating 60 carbohydrates), and the system can then determine that the patient is actually in a different state (e.g., eating 90 carbohydrates). In other examples, the patient's state may initially be the first state (eating 60 carbohydrates), and a dose is administered 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 can provide decision-making support guidance such as a correction bolus to avoid low or high.

[0325] In some examples, the time to deliver guidance regarding the correction bolus may be determined using a physiological model, a behavioral model, or both. For example, the acceptable time range for delivery of the correction bolus can be determined using a physiological model, and the convenient time range for delivery guidance or the correction bolus can be determined using a behavioral model that uses, for example, learning pattern information so that the guidance is delivered during or near the end of a class or meeting, or using a calendar indicating the schedule of the meeting or class.

[0326] User Requirement Insights User request insights can include receiving input from a user (e.g., via a smartphone app) for decision support for urgent diabetes decisions such as "How much insulin should be bolused before this meal?" or "Should a snack be taken before riding a bicycle?" In one example, a personalized guidance response can include interactive recommendations (e.g., "Deliver 4 units of insulin") and, optionally, can include a set of factors used in the decision (e.g., "A portion of pasta has 40g of carbohydrates, the activity level after lunch is usually moderate, and the current blood glucose level is normal but decreasing"). In some examples, if assumptions need to be changed, factors can be adjusted by the user (e.g., to reach a different dosage).

[0327] In some examples, previous user requirement insights can be used as input to a model, and the model can learn or adapt to situations where the user is likely to request insights. This information can be integrated into the model and decision support engine so that the system can provide personalized guidance in situations and at times when the user is likely to need guidance, such as by predicting requests and proactively providing guidance to the user. For example, if a user rides a bicycle once a week before (e.g., determined from learned behavior patterns), or while eating at a particular restaurant (e.g., determined from the patient's calendar), or after completing a physical workout (determined from activity sensors, a related smartwatch, or the calendar), and the user frequently requests guidance, the system can determine that personalized guidance is needed at a particular time and deliver guidance related to the current situation or typical pattern. User requirement insights can also be used to train the model based on implicit information in the user's requests. For example, if a user requests decision support before exercise, the system can gather that the user has a tendency to exercise at a particular time, and in particular, if a series of related user requests are obtained over a period of time, it can reveal the timing pattern of the exercise (such as being performed on Monday, Wednesday, and Friday mornings).

[0328] In some examples, the system can receive user requests for decision support for future activities (e.g., exercise, driving, eating, or sleeping), and the system can provide treatment adjustments or preparation steps proposed as guidance. For example, the guidance can include changes to basal insulin, calculation of bolus insulin, and the amount of recommended snacks (e.g., change the basal amount by x amount before starting exercise, or consume 15 grams of carbohydrates before going to bed). In some examples, the system (e.g., a model) can learn from the results of the guidance and make adjustments specific to the individual. For example, the system can learn how much exercise changes glucose. In some examples, patient-specific information such as basal rates and the insulin-to-carbohydrate ratio for specific meals or time periods can be entered by a clinician into an electronic medical record (EMR) system and used by the system to inform or educate the model or to assist in the development of responses to the patient's requests for guidance.

[0329] In one example, the system can receive user requests for pre-sleep guidance. The requests can be received, for example, via a decision support smartphone application. The system can provide guidance regarding one or more actions that the user needs to perform or consider before going to sleep, such as eating a snack, delivering an insulin dose, setting an alarm clock, or setting a continuous glucose monitor warning setting. The system can also provide an explanation of the risk or the reason for the guidance. For example, the system can notify the user of the risk of "late and low" glucose levels due to an exercise session, or the risk of low glucose levels due to a reported insulin dose that the system has estimated to be too high for a given meal or series of circumstances, or the risk of low or high glucose levels based on trend analysis. In some examples, the system can notify the user of a time or time range when a problem, such as "low glucose levels may occur around midnight," may occur. In some examples, the system can propose that the user reconfirm the guidance later (e.g., check the latest guidance in the decision support application on the smartphone), which can occur if, for example, additional information (e.g., additional CGM trend data) is determined by the system to be particularly useful for guidance decisions, improving the reliability of the guidance, or determining expected events.

[0330] In one example, the user can provide a photo of a future meal or scan a restaurant menu, and the system can provide guidance on the estimated effects on blood glucose or insulin administration recommendations. For example, a mobile device (e.g., smartphone) application can be configured to scan the menu and convert meal items into their estimated blood glucose impact. In one example, the user may be prompted to place the smart device camera over the menu, and the glucose information for the menu item may be presented on the user interface, for example, next to the menu item as seen by the user on the screen. This can be achieved, for example, using text recognition and a lookup table of glucose values for specific types of meals or establishments. In some examples, meals considered "healthy" or "unhealthy" can be highlighted, indicated with text or symbols, identified on the user interface, or, for example, using augmented reality (AR) where the menu is the subject of the augmentation. In some examples, the predicted blood glucose impact or variation (e.g., "72g carbohydrates" or "BG>200") or the required insulin bolus (e.g., 6 units) may be presented. In some examples, a predicted trend graph or a summary metric such as glucose load may be presented. In some examples, the predicted excursions can be personalized by learning from historical data such that the impact on glucose is personalized to the patient, profiling the patient, and incorporating such information into a physiological model as needed. In other examples, when a proposed workout (e.g., 30 minutes of moderate running, or 5 sets of deadlifts, or 1 hour of swimming) is provided as an input (e.g., entered into a smartphone app), the expected results such as a glucose profile can be predicted (e.g., by applying the workout as an input to a model) and displayed on the user interface. The results may be provided, for example, as a probability cone to provide the user with information about the potential range of blood glucose responses.

[0331] In some examples, the guidance can include a bolus recommendation that includes two numbers that reflect a decision tree, for example, one bolus number assuming the user will exercise as planned and a second bolus number assuming the exercise is not complete. In some examples, the guidance can include the amount of insulin on board, which can be determined by a pre-defined algorithm (e.g., based on population-based data or theoretical data), or as determined by a model (in which case the insulin on board can be patient-specific), as the amount of insulin determined to be active in the body. The guidance on insulin on board can be provided in response to a user request, or in response to events such as a determination that the insulin on board is likely to cause low glucose levels, or a determination that the amount of insulin on board may be insufficient to control glucose levels (i.e., high glucose levels may occur). In some examples, the guidance can reflect pre-defined or user-defined goals, such as a pre-defined blood glucose range (e.g., 70 - 150 mg / dL range) or a percentage of time within a defined range of glucose levels (e.g., 80% of the 70 - 150 mg / dL range). For example, the guidance can include proposed changes (e.g., afternoon exercise or a change in insulin dosage) to move the user towards the goal.

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

[0333] Regular Insights Regular insights can also be provided as guidance. For example, according to a regular schedule such as weekly updates, or when sufficient data is determined to be available to provide a reliable summary, such as 10 low-carbohydrate breakfasts vs. 10 high-carbohydrate breakfasts, to provide comparative analysis, averages, graphs, probability zones, or other information related to diabetes management. In one example, meals or foods can be grouped by types with similar blood glucose responses with respect to size and time elapsed (“spike vs. slow”). In other examples, meals or foods may be grouped by similar insulin administration strategies, such as which meals require correction boluses. In other examples, the decision support engine can summarize the types of decisions that lead to unreliable results in a way that promotes education (“ideas for low-carbohydrate breakfasts”) or medical review (e.g., inquiries to physicians about management strategies). The decision support engine can summarize such information (e.g., problematic meals) in anticipation of a physician's 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 differ between weekends and weekdays. This schedule difference can be reflected in the patient's glucose level, or the patient's interest or availability in glucose level management, or the patient's goals or thresholds for notification. In some examples, regular insights can be presented in a way that differentiates based on schedule, for example, weekend trends and weekday trends can be presented separately. Guidance can also include separate treatment or action recommendations for different parts of a person's schedule, for example, different basal patterns can be proposed based on knowledge of the schedule. In various examples, the schedule is learned by a model notified by the patient 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 above examples of various insights can be converted into different types of insights. For example, the example described as an event-driven insight can be provided as a user requirement insight, and the user requirement insight can be provided as an event-driven insight by applying an algorithm or model that determines the conditions and timing of the delivery of insights as guidance.

[0336] "Real-time" does not necessarily mean immediate, but in contrast to retrospective information presented to evaluate overall behavior and treatment improvement opportunities, an intervention can affect short-term outcomes based on recent data or trends. Input and Model Interaction

[0337] Figure 2A is a diagram of an exemplary configuration of the model 110 shown in Figure 1. Figure 38 is a diagram showing another example of the configuration shown in Figure 2A. Patient 102 is interested in controlling the true glucose level 160 that can be measured by sensor 152. The physiological model 112, the behavior 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 for patient 102 and the time to determine or deliver the guidance. The guidance can be delivered via the guidance module 150.

[0338] The sensor system 152 can measure physiological parameters such as glucose level, activity, heart rate, respiration, or body temperature, or context parameters such as ambient temperature, pressure, or location. The sensor system 150 can include a single device (e.g., a watch), or a group of multi-sensor devices (e.g., a watch and wearable sensors), or the sensors can be present in individual other devices, which may or may not communicate with each other. For simplicity, the sensors that provide data input are simply referred to as "sensor system". The sensor system 152 can include a continuous glucose monitor (provided in more detail below) configured to measure a glucose level that is calculated to indicate the 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 state or stress state), or information regarding drug delivery 156 (e.g., insulin delivery), which can be received from the patient or via user input 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 Figure 2B, and numerous inputs are shown and described in Figures 14 - 16. The physiological model can provide physiological state information such as the current or predicted glucose level or trend, insulin-to-carbohydrate ratio (ICR), insulin sensitivity factor (ISF), basal rate, or insulin on board (IOB) as output, all of which can affect 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 can also receive information received from a patient, such as calendar information from a computer system such as a smartphone, user input regarding a specific activity or exercise, or user input regarding food consumed. The behavioral model can also receive, as inputs, guidance information delivered to the patient, as well as sensor data. The behavioral model can also receive the output from the physiological model. The behavioral model can process various inputs to determine the current state of the patient or predict the future state of the patient, which can include, for example, exercise, sleep, likelihood of intervention, interest in receiving guidance, and other information regarding the patient's activities, interests or behaviors. The behavioral model can also receive context information or determine current or predicted context information as a state (e.g., during a meeting or while driving home), which can 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 numerous inputs are shown and described in FIGS. 14-16. The measurement model 154 can be included in the system as needed. Data from the sensor system 152 can be provided to a measurement model 154 that can process the sensor data to evaluate the accuracy and precision of the data, for example, to determine the likelihood that a measured glucose level matches the true glucose level. The sensor system can use statistical techniques such as variability or dispersion of sensor data points, trend information, historical information, and information provided by the behavioral model, physiological model, and other sensors to evaluate whether one or more sensor data points are likely to be accurate or inaccurate. For example, if consecutive blood glucose data varies significantly or a pattern that does not reflect a normal physiological pattern becomes apparent (e.g., 90 mg / dl, 112 mg / dl, 96 mg / dl, 121 mg / dl in consecutive 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 outside the range of the estimated values.For example, if the ambient temperature is detected to be -5°C in July, especially when location information is available, the model can conclude that the sensor readings are inaccurate. In other examples, activity information can be processed, including correlating the mode of the measurement model with the mode of the behavior model, to determine the correlation with the likely actual activities. For example, the information from the accelerometer can be processed to evaluate whether the movement is overly rhythmic (as opposed to movement, which can indicate mechanical movement such as a bumpy vehicle) or outside the expected range (e.g., a relatively sedentary person who is active for 3 hours). The output from the measurement model (e.g., accuracy status information) may be provided to the behavior model 114 or the physiological model 112 to integrate with other information to determine the 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 the guidance based on the information (e.g., status) provided by the physiological model 112 and the behavior model 114 and determine the time to provide 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 behavior model 114, and the guidance module 150 may provide the determined guidance at the determined time. In various examples, the guidance module 150 may, for example, reside on the mobile device 108 or be remote from or local to the patient and reside on a computer system that can deliver guidance to the patient via a user interface on the mobile device 108 or another device.

[0342] Exemplary models Figure 2B provides a more detailed view of exemplary model inputs and exemplary states that can be determined by applying inputs to the model. The physiological model 112, the behavioral model 114, and the measurement model 116 of Figure 2B are shown along with exemplary inputs and states for each model. The exemplary inputs are shown on the left side and the determined exemplary states are shown on the right side. The following Figures 14 - 16 provide a more comprehensive description of the inputs, any of which can be applied to one or more of the models. The states can be identified by a physician or expert or learned by the model via machine learning. Each state can have two or more (in some cases multiple) state values, such as discrete numerical values, ranges, 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 model. Although three models are shown, those skilled in the art will understand that the models can be integrated into one or two models or decomposed into a greater number of models or submodels.

[0343] Physiological model Food consumption can be provided as an input to the physiological model 112. Food consumption information can include information about meals, snacks, and beverages, such as size, content (carbohydrates, fats, proteins), order of consumption, and consumption time. The amount of food consumed can be provided by the user manually entering it, providing a photo with an application configured to recognize the type and amount of food, or scanning a barcode or menu. In various examples, the size of a meal can be entered manually as calories, quantity ("3 cookies"), menu item ("cheeseburger"), or food exchange (1 fruit, 1 dairy product). In some examples, meals can also be entered as typical items or combinations for 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 FIGS. 25A and 25B, the user interface user 2500 can enable the user to indicate by touching the amount of fat and carbohydrates (and optionally, also proteins) on the graph 2502 (or other graphical user interface element) for each meal. FIG. 25A shows a selected point 2504 on a graph 2502 with a high carbohydrate (78 grams) and low fat (1.6 grams) content. FIG. 25B shows a selected point 2506 on a graph 2502 with a high carbohydrate (78 grams) and low fat (1.6 grams) content. FIG. 25B shows a selected point 2506 on a graph 2502 with a low carbohydrate (3 grams) and relatively high fat (20 grams) content. Examples of meals with similar nutritional content (e.g., ratio of carbohydrates to fats) can be displayed on 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 statistics such as age, height, weight, body mass index, body composition (e.g., % body fat), torso length, build, or other information can also be provided as input from a wireless scale or a measuring device such as a camera, e.g., Bluetooth®-enabled, that can communicate with the mobile device 108 to provide patient data, via the user interface or via an interface with an electronic source such as an electronic medical record.

[0346] Insulin delivery can be received by the model from the smart pen via a wireless connection, or via user input, or from an insulin pump. Insulin delivery information can include the amount of insulin and the 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, administration of treatment such as use of glucagon to stimulate hepatic glycogen release in response to hypoglycemia, a recommended basal rate or insulin-to-carbohydrate ratio (e.g., received from a clinician), or recorded activity (e.g., intensity, duration, and completion or start time).

[0348] The input can also be received from sensors such as physiological sensors that detect heart rate, respiration, oxygen saturation, or body temperature (e.g., detect illness). An electromagnetic sensor can also detect a low-power RF electromagnetic field emitted from an object or an object or tool in contact with or in proximity to the object, and can provide information regarding the patient's activity or location. Glucose level information can also be provided as an input, for example, via a continuous glucose monitoring (CGM) system that provides CGM data. The input can also be received from a smart pill dispenser that tracks when a customer takes medication, a blood ketone meter, A1C measured or estimated in a laboratory, other measurements of long-term control, or a sensor that measures peripheral neuropathy using the tactile function of a smartphone or a tactile response of a special device.

[0349] The state of a measurement model or behavior model can also be provided as an input.

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

[0351] In some examples, the model input can be inferred from, for example, one or more historical user inputs (e.g., a diet diary), geographical location information, insulin administration, CGM functionality (rising blood glucose levels), or time of day. In some examples, the model can operate in a learning mode and 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 related to a particular meal or type of meal or activity, or insulin action time or duration of insulin action, or combinations thereof.

[0352] Physiological state One or more physiological states can be determined by applying inputs to a physiological model. The metabolic rate can include the basal metabolic rate (e.g., the energy consumed at rest), as well as the active metabolism, e.g., the energy consumed by activity, such as exercise, activity, or movement. In some examples, the basal metabolic rate and the active metabolism can be tracked as separate states. The activity level can also be determined, for example, based on an activity sensor or other physiological sensors. The activity level state can include, for example, four states: sleep, rest, activity, exercise. Insulin sensitivity can be determined using historical data, real-time data, or a combination thereof, for example, based on food consumption, insulin delivery, and the resulting glucose levels. Insulin on board can be determined using insulin delivery information and a known or learned (e.g., from patient data) insulin time-action profile that can account for both the basal metabolic rate (the renewal of insulin to maintain the body's operation) and the insulin usage driven by activity and food consumption. The meal state can include, for example, fasting, pre-meal, during-meal, post-meal response, or steady state. The meal state can also include on-board nutrition, e.g., the consumed meal, snack, or beverage, and can be determined, for example, from the digestion rate information associated with the food consumption information, meal time information, and food type, amount, and order (e.g., which food / beverage was eaten first). Health and illness can be determined, for example, based on user input (e.g., pregnancy information or known illness information), from physiological sensors (e.g., temperature), activity sensors, or a combination thereof. Exemplary health states can include, for example, healthy, ill, resting, and fatigued. The glucose level can be determined from sensor information (e.g., CGM data), optionally in combination with the state of the measurement model. In some examples, when CGM data is unavailable or of uncertain reliability, for example, based on historical information regarding glucose levels in certain situations, such as when a combination of food consumption amount, insulin, and activity is given, the glucose level state can also be determined from the model.The degree of blood glucose control (not shown) can also be determined as a state, for example, based on glucose level, variation in glucose level, or insulin administration pattern. The confidence level can be applied to one or more states (e.g., high, medium, low, or numerical confidence).

[0353] In some examples, the transitions between states can be important decision points for determining guidance, or the times at which to determine or deliver guidance. For example, a user may particularly need guidance during a transition between states. For example, guidance may be needed while waiting for the glucose response after a meal, or when determining what to do before exercise. These state transitions, or predicted state transitions, can be identified by the system (e.g., using a model) and used to determine the times at which to determine or deliver guidance. Examples of these state transitions can include active → resting → exercising → sleeping, or healthy → sick → resting → fatigued, or changes in the degree of blood glucose control (e.g., changes in glucose level, changes in insulin sensitivity, changes in insulin dosage), or transitions to pregnancy. In some examples, the physiological model 112 also includes disease stage states such as those of type II diabetic patients. Examples of disease stage states of type II diabetic patients can include the prediabetes stage, the oral treatment stage, and the basal insulin treatment stage. The insights provided by the decision support engine can vary, for example, by hosts in different disease stages, as described herein.

[0354] Modeling of Exercise and Potential Energy Flow In one example, the physiological model 112 can characterize the flow of energy in the human body, including the effects of diet, exercise, glucose and insulin, and other hormones such as cortisol and adrenaline. Energy inputs can include diet and snacks (characterized by time, size, and type), and glucose production by the liver (e.g., the "dawn effect" where the body releases energy in the early morning, or the release of energy by the liver to counter low blood sugar levels). Energy outputs can include energy consumption by activities such as exercise, glycogen replacement by muscles or the liver, and glucose uptake driven by insulin. The insulin time-action profile can take into account not only the separate effects of basal (e.g., resting) metabolism and activity metabolism (e.g., due to activity / exercise). Model 112 may be tailored to the physiology of the subject using user input, measurements (e.g., CGM patterns and fitness tracker or accelerometer) and inferences, e.g., learning of patterns and associations from data.

[0355] At a high level, the physiological model can track energy inputs, energy outputs, and determine one or more physiological states. This aspect of the energy characteristics of the physiological model can be used to predict future blood glucose states (e.g., high glucose levels, low glucose levels, rising glucose trend, falling glucose trend). The physiological model can also interact with a behavior model and guidance module (such as a decision-making support app) to determine when the user needs context-specific guidance (advice, warnings, alerts, etc.), such as transitions from rest to exercise or from health to illness.

[0356] Behavior model The behavior model can reflect behaviors, preferences, schedules, and other information about the user. Referring again to FIG. 2B, the inputs to the behavior model can include user inputs such as activities, the level of interest in guidance, or inputs via the user interface regarding location. The inputs to the behavior model can also include calendar information such as availability and activity information received from a computer or a calendar application on a smartphone. The inputs can also include activities such as information from activity sensors such as a clock or an accelerometer on a fitness band. The inputs to the behavior model 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 state of the behavior model can include the availability or convenience of an intervention (e.g., available / unavailable or convenient / inconvenient) estimated from a calendar or an estimated schedule, or from the learning pattern of the schedule of a patient or a caregiver. The state of availability or convenience can also include the proximity of a caregiver to a patient, which can be inferred from location information or calendar information.

[0358] The state of the behavior model can also include risk tolerance (e.g., comfort with a tendency to hypoglycemia, which may depend on experience with an intervention or the likelihood of intervention by a caregiver), interest in guidance, activity state (e.g., whether exercising, which can be inferred from a calendar or an activity sensor), sleep state (e.g., sleep or rest or wakefulness inferred from an activity sensor, a calendar, or other information), and appetite (e.g., which can be inferred from a meal pattern).

[0359] Involvement (or level of involvement) can also be determined as a state of the action model. For example, the involvement factors can include the user's response to decision-making support from the perspectives of time, activity, and type of support (requested by the user, context generation, periodic). The involvement state can include, for example, the type of guidance that tends to prompt an action, the actions the user participates in, which may be correlated with time (e.g., cannot walk from 9 to 5) and activity (e.g., no blood glucose test that punctures a finger during execution). The state of the involvement level can also reflect the time the user is engaged in receiving or following guidance (e.g., if a short time suggests ignoring the guidance). The involvement state can also include the type of communication that can be associated with an activity or schedule, such as learning the appropriate mode to interact with the user depending on the time and place. For example, the user can receive clock or phone display messages during a meeting, voice messages in a car, hierarchical messages based on urgency during sleep, where urgent messages are accompanied by sound or vibration and less urgent messages are quietly displayed on the display or clock. In some examples, the involvement level logic and scheme applied above can also be applied to caregivers (such as data followers of smart devices), notify of the need for intervention, or notify that the patient or other caregivers are aware of or managing the situation.

[0360] The level of concern can also be determined by an action model. For example, the system can determine a situation that may cause concern about the current physiological state, the result of a treatment decision, or a potential future state, and determine the level of concern based on the presence or likelihood of such a situation. For example, how the patient views the CGM value or guidance, or the device for displaying information, the method of displaying information (such as on a watch or phone, or full-screen display, or interaction only with a notification screen that can provide less information), can indicate the level of concern (seeking more information or looking for less convenient 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 (the higher the frequency, the higher the concern). Other factors that can be considered when determining the level of concern can include self-monitored blood glucose measurements (e.g., measurements from a finger prick sensor), requests for decision-making support, and the situations surrounding such requests (e.g., restaurant meals and home cooking), when insulin adjustments are made (basal, meal, postprandial), consumption of snacks or immediate-acting carbohydrates to avoid hypoglycemia, the presence or attention of a caregiver (e.g., a data follower) who monitors blood glucose levels or responds to data updates, or the pattern of alarms. In some examples, the level of concern or alarm preference can be learned through 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 the concern level can be based on the period during which the user is concerned (e.g., time, period after a meal, period after exercise, or specific day of the week or month, or time derived from calendar events such as holidays or school events). The period can also apply to caregivers (such as data followers). The concern level regarding the period can be derived, for example, from user input or learned from the user's behavior. The concern level can also reflect the user's goals, for example, the user's concern level regarding alarms and low sounds, or those focused on maximizing the time within a range, or both.

[0362] The behavior model can also include induced states that can include, for example, an insulin-induced state (e.g., delivering X units of insulin or increasing or decreasing the basal rate) and a carbohydrate consumption-induced state (e.g., eating X grams of carbohydrates).

[0363] In some examples, the generation of guidance messages or other information for the patient can be done as part of the behavior model (e.g., as an output state from the model). For the sake of clarity and simplicity of the explanation, the guidance generation will be explained separately below.

[0364] Measurement model The measurement model can provide information regarding sensor measurements such as CGM sensor measurements. The measurement model can provide, for example, an indicator of the accuracy of the data from the sensor.

[0365] The CGM measurement model can add context to the glucose values and patterns generated from sensor data. The model can enable various data types. For example, confidence limits can be determined for data values or data sets. The confidence limits can be presented to the user or provided as input to other models. The model can provide, for example, accurate boundaries adjusted for the date of use (e.g., newly implanted sensors and aging sensors, which may become inaccurate), compliance with the calibration schedule, the impact of delays at high rates of change (both due to the physiological delay in the movement of glucose levels in the interstitial fluid), and sensor delays due to the sensor only measuring periodically, e.g., every 5 minutes. The measurement model can also monitor the consistency between blood glucose measurement values and CGM measurement values as an indicator of the reliability of the blood glucose measurement values, CGM measurement values, or both. Similar principles can be applied to other data sources to evaluate accuracy, consistency, or variability.

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

[0367] Determination of the Timing of Guidance In various examples, guidance, and the timing of the guidance, can be determined based on a state model or other inputs. For example, the guidance can be determined from one or more physiological states 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 a large number of states can be used to determine the guidance and the timing of the guidance. In various examples, the guidance, and the timing of the delivery of the guidance, can be performed by a behavior model or a guidance module that uses state information such as states from a behavior model and a physiological model.

[0368] Learning In some examples, the system can enter a "learning mode" in which the system observes physiological or behavioral data. For example, the system can collect CGM values, blood glucose measurements, insulin dosages, meals, activities, medications, stress levels, sleep patterns, hormonal cycles, location (via GPS, etc.) and other information to build a set of information from which patterns can be inferred. The system can determine, for example, basal doses, insulin sensitivity, insulin-to-carbohydrate ratios, insulin action periods, or boluses for commonly used meals. In one example, in cooperation with the patient, which can include tracking factors such as carbohydrate intake and insulin administration, a protocol can be followed. The resulting glucose levels or trends can be determined for the patient, particularly when the patient is newly diagnosed or treated. Since 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 parameters (such as insulin sensitivity) and time. The carbohydrate-to-glucose ratio can also be determined, for example, by determining how much the patient's glucose level increases per gram of carbohydrate and explaining the underlying basal rate.

[0369] In one example, for a basal test, the user is asked to select a day when the BG is within a specified range (e.g., between 80 - 250), make a plan to skip meals, manage meals so that the previous meal is not high in fat or very high in carbohydrates, and avoid exercise and other things that may affect blood glucose levels. The system can receive input from the user to start the basal test. Next, the system can evaluate the blood glucose concentration level for a certain period (e.g., 3 hours) after the last meal. If the blood glucose level is stable for a certain period, the system can declare that the basal rate is correct. If there is a period during which the BG is increasing or decreasing, the basal rate that affects that period can be changed in small, safe increments until the blood glucose is stable throughout the period. In some examples, this process can be repeated until a full 24 hours (or more, e.g., one week) is covered by a successful basal test.

[0370] When the blood glucose level is within a specific range, for an insulin-to-carbohydrate ratio test, the user is asked to select a time when the blood glucose is within a specified range (e.g., between 80 - 250) for at least a specified amount of time (e.g., 4 hours) from the previous meal, without being affected by exercise, stress, or other influences that may affect blood glucose levels, and eat a specific meal with a known carbohydrate content and a medium glycemic index. In some examples, the system can require the user to eat a specific food or ask the user to take a photo to confirm consuming a food with a nutrition label. Since the carbohydrate content is established with confidence and other causes of glucose fluctuations are minimized, the system can determine the patient's ICR. In some examples, the process can be run multiple times so that the system can adjust to the correct ICR. This can be achieved, for example, by making changes in execution from small, safe executions until the content of the meal is appropriately covered (i.e., until the system identifies an appropriate insulin dose that produces a stable glucose level within the desired range).

[0371] In other examples, to estimate the insulin sensitivity factor (ISF), the user can be asked to select a time (e.g., 4 hours) since the last meal and avoid other actions that affect exercise or glucose levels. Next, the system can request that the user take a correction bolus. Next, the system can 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 examples, the basal rate is first determined to enable accurate estimation of ISF and ICR and ISF. In some examples, instead of or in addition to requiring patient involvement or cooperation, the decision support system can determine an appropriate period for determining the basal rate, ISF, or ICR.

[0373] The system can integrate various states and learn the relationships between the states. For example, the system can track the intensity and duration of exercise, glucose levels, insulin dosage, and learn how exercise affects glucose sensitivity. The determined glucose sensitivity can be provided as guidance, or used to determine other states, or as input to an algorithm for determining guidance. The system can also reference or build a nutrition database and link the database to the patient (e.g., track how the patient responds to specific meals or food types). The system can also track patterns of insulin sensitivity and insulin use, for example, to predict changes in insulin sensitivity or insulin use patterns. The system can also track the recent history of blood glucose 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, which constitutes insulin resistance in the body).

[0374] In one example, the system can learn when a patient makes a treatment decision and how the patient and caregiver (e.g., a data follower of a smartphone) track the result of the decision. Next, the system can predict when the patient is likely to make a similar decision and the information useful for making the decision, and provide such information as guidance. The system can also predict a desired result and provide a confirmation notice (e.g., "Well done! The post-breakfast peak is 140 mg / dL, and it is currently stable and within the range"), or recognize that the desired result has not been achieved ("It is still 220 mg / dL after the 3-unit bolus at 7 am and is rising").

[0375] In some examples, the system can identify a situation or pattern of interest (e.g., general situations such as diet, exercise regimen, or holidays), or receive such identification of a situation or pattern from the user, and create more accurate guidance or guidance timing for the more effectively identified situation. For example, the system can obtain information about the identified situation by requesting user input or by overseeing an "experiment" to enable collection of more data or more accurate data. The additional data can be used to improve the guidance or guidance timing for the identified situation.

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

[0377] In some examples, state transitions are detected using a model and can be used to generate guidance or notifications to a patient. Some physiological state transitions (e.g., illness / health) can occur over a period of days or weeks, while others can occur on a time or minute scale (e.g., glucose level or trend). In some examples, guidance can be delivered when a state transition condition is met. For example, if a patient is determined to be trending towards a low glucose level and transitioning to or likely to exercise soon (e.g., using a pattern or based on the location of a park or gym), the guidance can provide for the consumption of some carbohydrates. In some examples, a combination of state transitions can trigger guidance (e.g., a transition from normal glucose to low glucose and a transition from a seated position to an active state / exercise state).

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

[0379] In some examples, the system can deliver guidance when a specified combination of state conditions is met, or when a specified combination of state transitions occurs, or when it is calculated to be likely to occur. For example, guidance can be delivered when both the glucose state and the exercise state meet specified conditions, such as when there is a high likelihood or presence of a low glucose state and the patient is about to exercise or has finished exercising. 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 can adjust the guidance based on the severity of the situation, the level of concern, and the level of engagement. For example, the decision to withhold or deliver guidance may be determined in part based on the level of concern or engagement state level of the action model at a particular point in time. If the level of concern or level of engagement is relatively low, the delivery of guidance may be postponed until a time when the user has more free time or a more convenient time for the user. In situations where the level of concern or level of engagement state is high, guidance can be delivered even if it is inconvenient. For example, even if the user is participating in a meeting, guidance regarding an emergency situation can be delivered, but guidance regarding relatively routine (e.g., low concern / engagement) issues can be postponed until after the meeting. In this way, the messaging frequency of insights and / or guidance delivered to hosts with an engagement state indicating a low level of engagement can be reduced. This can prevent hosts in a low-engagement state from being overwhelmed by the guidance. As the level of engagement of the host changes, the frequency of guidance can also change. For example, the host can respond to the initial low-frequency guidance by increasing engagement, such as reaching an engagement state indicating a higher level of engagement. If this occurs, the frequency can be increased. For example, the delivery of guidance may not need to be postponed, and / or may be postponed, in a shorter time than when the host is in an engagement state indicating a low level of engagement. When the engagement state of the host changes to indicate a decrease in the level of engagement, the delivery frequency of the guidance can be reduced.

[0381] Examples of guidance In various examples, the guidance is determined at least in part based on time. For example, the determination of the guidance can be based on clock time, or time of day (e.g., zones such as morning, afternoon, evening, night). Insulin sensitivity tends to vary based on several functions that overlap in time. For example, diabetic patients tend to have higher insulin resistance in the morning due to factors such as other hormones secreted by the body in the morning. The determination of the guidance can be based at least in part on time of day to account for the time-varying insulin sensitivity. The determination of the guidance can also vary over time based on the patient's actions, 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 competitions) 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 actions (e.g., the rate of change of insulin to carbohydrates for a particular meal (e.g., lunch) or for exercising within a particular time frame (e.g., "consider increasing insulin sensitivity by walking briskly after breakfast")).

[0383] In some examples, information determined from a physiological model or a behavioral model can be used to propose alternative approaches to common patterns. For example, the system can determine that a user has a tendency to over-correct or under-correct after a particular situation, such as a particular time or a particular meal, and guidance can be provided when the system detects a pattern related to a correction error. 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-correction or under-correction has occurred. In other examples, a predicted tendency can be presented for a proposed action. For example, a user can input a proposed insulin dose or snack or meal via a user interface, and the system can display a predicted tendency. In the example shown in FIG. 27A, a user interface 2702 can be presented to the user that includes a scroll dial 2704 that enables selection of a carbohydrate amount, and the system can present a predicted tendency 2706 showing possible results from a snack that includes the selected amount of carbohydrates. In other examples, as shown in FIG. 27B, a user can input a proposed carbohydrate value, a proposed insulin dose, and the system can present a user interface 2720 that shows three curves, one curve 2708 being a scenario where carbohydrates are ingested but no insulin is administered, one curve 2710 being a scenario where insulin is administered but no carbohydrates are ingested, and an estimated glucose value curve 2712 being a scenario where both glucose and insulin are administered. In some examples, the dial shown in FIG. 27A can be provided on the user interface 2720 shown in FIG. 27B. The predicted insulin tendency is shown as a line, but in other examples, a probability cone may be shown instead of the line.

[0384] In some examples, the system can provide guidance on a nighttime preparation level to prevent the user from having a tendency to have low glucose levels at night, reduce nighttime warnings, reduce nighttime hypoglycemic events, and provide comfort to the user at night. To develop long-range (e.g., 6 - 10 hours) or reliable predictions regarding states or state transitions, the system can obtain more information from the patient or sensors, or perform additional processing to increase the likelihood that the guidance enables a full night of sleep without interruption for eating or delivering insulin. The nighttime preparation function can provide guidance for taking actions before going to sleep, such as consuming 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 data such as the resulting blood glucose profile, can also be provided to the clinical supervision platform after delivery to the patient, enabling adjustments or feedback from the clinician, such as changes in insulin type, dosage, timing, or enabling the formation or optimization of future guidance.

[0386] In some examples, the decision support system can include a diabetes management supervisor configured to provide overall guidance or feedback. The diabetes management supervisor can, for example, quantify diabetes management overall. This can include metrics for measuring the effectiveness of control of estimated blood glucose values measured against criteria such as specified conditions, benchmarks, or measurements of time within a specified blood glucose range (e.g., percentage).

[0387] Treatment parameters The decision support system can also provide guidance regarding treatment parameters. For example, the system can identify when changes to the basal rate, ICR, ISF, or IOB are needed. The system can also request a test, for example, when the type or amount of the necessary change cannot be identified within a specified measure (such as a confidence level). Real-world data can pose the following challenges in determining treatment parameters: Theoretically, if the basal rate is correct and the ISF is known (or assumed to have a known relationship with other treatment parameters), the bolus can be determined with acceptable accuracy. Similarly, if the ICR and ISF are correct and the carbohydrate estimate is (at least on average) accurate, the basal rate can be fine-tuned within an acceptable range. However, actual conditions may be filled with uncertainties, complexities, and overlapping elements, and errors may exist in all parameters, so the ideal scenarios described above are rare or difficult to recognize. To address this systematic complexity, the decision support system can include a model or algorithm that learns or detects inappropriate specific basal rates, ICRs, ISFs, or insulin-on-board periods from the collected data. In some examples, the parameters can be determined retrospectively from data over several days or weeks, and the determined parameters can be evaluated for accuracy when additional data is collected. The decision support system can also use the model or algorithm and the learned parameters or past data in combination with real-time or recent data to generate guidance and calculate the time for delivering 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 low or high repetition for a time (e.g., 4 hours) or more after a meal (i.e., after the effects of food and basal dose reduction). Similarly, an inappropriate ICR can be identified by identifying repetitions of low or high glucose levels for a time (e.g., 2 - 4 hours) after a meal (while food and basal insulin are still active) in an incident where the repeated low / high did not occur longer than a second time (e.g., 4 hours) specified after the same meal (suggesting that the basal rate is correct).

[0389] The decision support system can consider 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 the pre - meal range (e.g., without an on - board correction bolus) but out of range after a meal, the error may possibly be due to an inappropriate ICR. In some examples, the glucose trends of meals with different characteristics can be compared to verify or improve the inaccuracies detected in the ICR. For example, by collecting patterns of glucose levels with a low trend, if it becomes clear that the higher the number of carbohydrates, the faster the glucose level trend or the lower the glucose level, it can be inferred that the ICR is likely too high (i.e., due to a high ICR, excessive insulin is delivered, and the effect of the high ICR is amplified as the amount of carbohydrates increases, resulting in a faster low - glucose trend or a decrease in the glucose level). Similarly, by collecting patterns of glucose levels with a high trend, if it becomes clear that the higher the number of carbohydrates, the faster or higher the glucose level, it can be inferred that the high - glucose trend is likely due to an ICR that is too low (i.e., insufficient insulin is delivered, so the glucose level increases, and the effect is amplified as the number of carbohydrates increases).

[0390] Insulin sensitivity factor In other examples, 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 (further described below) and assist the user in determining whether a problem is caused by treatment parameters or a system fault (e.g., to distinguish a problem with insulin sensitivity from a problem with hardware faults). Guidance regarding insulin sensitivity can be particularly useful when a patient experiences a change in insulin sensitivity. For example, during a "normal" state, a patient's diabetes can be adequately controlled by estimating and using "treatment" parameters such as basal rate, ICR, ISF, and insulin duration of action. However, stress, illness, changes in physical activity, hormonal cycles, etc. can cause changes in insulin sensitivity, alter the effects of insulin in the body, and also affect many or all of the "treatment" parameters (ICR, ISF, etc.), which can have a dramatic impact on the patient's glucose levels. In one example, in noisy data with multiple overlapping effects, the decision support system can identify an inappropriate ISF based on the occurrence of low or high instances at a specified time (e.g., 2 - 4 hours) after a correction bolus in the absence of detected basal errors or detected ICR errors. For example, the system can identify an incorrect ISF from a pattern of low (or high) glucose levels after a correction bolus that does not respond to a meal error. In other examples, if there is a low (or high) glucose level after a meal using a correction bolus and no glucose variation after a meal without using a correction bolus, the system can determine that it is likely due to an incorrect ISF.

[0391] To detect changes in insulin sensitivity, the decision support system can use a model or algorithm that can identify changes in glucose patterns in real time (using retrospective data). In some examples, the decision support system can use a model or algorithm to distinguish different types of changes in glucose patterns (e.g., insulin sensitivity, insulin delivery problems, sensor problems, etc.). Regarding changes in insulin sensitivity, the decision support system can propose appropriate percentage changes for all "treatment" parameters. The system can identify when insulin sensitivity returns to baseline and propose returning the parameters to baseline. The system can distinguish normal and abnormal states, or normal and abnormal insulin infusion states, such as normal ISF and changed ISF caused by stress. In some examples, the system can detect changes using various data sources (glucose measurements from sensors, raw sensor data, fingerstick data, insulin, carbohydrates, parameters of pump occlusion alarms, last change date of infusion sets) and provide guidance based on recognized patterns in the data.

[0392] Fault Detection Furthermore, "faults" in the system, such as insulin delivery problems (e.g., injection site problems) or sensor problems, can cause unexpected changes in glucose patterns. The decision support system can identify faults using a model or algorithm based on patterns in glucose or other data. Identifying the start and end of such fault states can help the patient and their physician take appropriate measures, keep glucose levels within acceptable ranges, and avoid changing other factors (such as ISF) to address blood glucose fluctuations when an unrecognized system fault that causes glucose control problems occurs.

[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] Figure 3B is a diagram of an exemplary schedule for a caregiver (e.g., a parent) (upper figure) and a pediatric patient (lower figure). In one example, the decision support engine can recognize the available periods of the caregiver and the periods when the caregiver is absent or unavailable from calendar information, user input, sensor information (e.g., GPS), or learning 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 availability of the caregiver, for example, providing guidance during an available period early in a basketball game or (if possible) deferring the guidance until an available period at the end of the game.

[0414] Figure 3C is a diagram of the patient's awake / sleep state. The decision support engine can determine the time to deliver guidance when the patient is awake, e.g., before sleep or during a nocturnal wake period, such that it can be determined using, for example, activity or other sensors of a clock, a fitness tracker, or other wearable or patient recognition device.

[0415] Figure 3D is a diagram of determining the availability (or convenience) for a patient to participate in an intervention based on other states. Initially, the patient is asleep and unavailable. When sleep ends, the patient is available until the start of the commute (as determined by connection via schedule information, GPS, or a wireless connection in the vehicle). When the commute ends, the patient is available until the start of a meeting. When the meeting ends, the patient becomes available again. Determination of Guidance Timing

[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 can include, for example, a state indicating the convenience or availability of a patient participating in an intervention. For example, information (such as availability) from a calendar related to the patient or related to a caregiver may be applied to the model. In some examples, sensor information (such as accelerometer information indicating an activity level) or pattern information (such as a wake / sleep cycle or a movement period or a passing period, such as indicating driving) can be applied to the model. A state indicating the availability or convenience of performing an intervention such as insulin administration, carbohydrate consumption, or participation in physical activity can be determined by applying real-time data to the model. In some examples, the model can include a physiological model of the patient, and the determination of the patient's state can be based at least on applying first real-time data to the physiological model of the patient. In some examples, the state is insulin sensitivity. In one example, movement is detected and the insulin sensitivity is determined based on a known pattern of the user's blood glucose response to the movement.

[0426] The model may additionally or alternatively include a behavioral model. The behavioral model can be based on, for example, one or more machine learning characteristics of the patient. The one or more machine learning characteristics can be based on a behavior pattern or a context pattern. In some examples, the behavioral model can 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 behavior model can include patterns. In an exemplary configuration, the patient's physiological model is based on physiological patterns and the behavior model is based on behavior patterns. In some examples, the first real-time data can indicate a deviation from an expected behavior pattern. For example, the first real-time data can indicate a deviation in meal times, a missed insulin administration, an early or late insulin administration, a change in physical activity (e.g., lack of exercise or uncharacteristic movement), or an early or late awakening. In some examples, the behavior model may tend to overcorrect with meals associated with meal times, the first real-time data indicates that a meal time is approaching, and the guidance message can correspond to a decrease in undercorrection at meal time (e.g., a smaller insulin dose or a different combination of basal and bolus doses).

[0428] In some examples, the behavior pattern can include a long-term behavior pattern based on a long-term behavior pattern and a short-term behavior pattern associated with current behavior. The behavior model may be based on both the long-term behavior pattern and the short-term behavior pattern. In some examples, the short-term behavior pattern can be based on one or more selected from the group consisting of engagement with a mobile device, accelerometer data, glucose concentration check frequency, 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 states related to glucose measurement. In some examples, method 500 can also include measuring glucose concentration data after providing a 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 may be fed back to the measurement model or the behavior 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, treatment recommendations such as instructions to administer a particular amount (e.g., 1 unit) of insulin, 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 further be based on the timing of determining the guidance message or the time associated with 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 future events. The guidance message determined at step 504 can provide glucose administration information or carbohydrate consumption information, or information for preparing for the next event or notifying the user, such as "consider administering insulin before the next 2-hour meeting" or "consume carbohydrates before commuting to avoid the possibility of a drop in blood glucose level during commuting". 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, the state transition probability can be known or learned from data, and real-time and other data can indicate the presence of conditions for a low-probability transition. This determination can form the basis for guidance to the patient and can be particularly useful, for example, in situations where a decision guidance engine may be able to provide warnings regarding risks that the patient may not be aware of.

[0431] In some instances, the system detects a state where an exercise session is missing, or a series of exercise sessions are missing, or a tendency towards shorter or fewer exercise sessions. A patient's physical exercise tends to increase metabolic drive and may increase glucose consumption. A lack or decrease in exercise sessions can lead to a decrease in metabolic drive and calorie needs, or an increased need to compensate for low metabolic drive with insulin.

[0432] The decision guidance engine can also recognize converging points of factors, such as higher than normal activity and lower than normal food consumption, or other patterns such as stressors or their absence, travel, sleep disturbances, illness / health, or irregular meal times, and determine that a low-probability (given a normal state) state transition (e.g., from an unusually high or low blood sugar level) may occur. Such determinations can lead to guidance decisions such as "You may experience an irregular low blood sugar tonight," "You may experience an irregular high blood sugar this morning," "Your insulin needs may be higher than normal today." The guidance can provide details regarding the reasoning behind the guidance (e.g., "due to missing several workouts"), or simply notify the user about the physiological result.

[0433] In 508, guidance messages can be provided to users such as patients or caregivers via a user interface such as the screen or speaker of a mobile device, or the speaker or display in a vehicle. In some examples, the method or time of delivery of guidance messages can be determined in part by time (e.g., clock time or time of day), for example, to account for a patient's work, sleep, meal, or commute schedule. In one example, providing a guidance message can include displaying a recommended treatment when calculated to be useful to the user. In one example, a guidance message can be provided before a scheduled event such as a meeting. For example, if it is known that a user will be attending a 3-hour meeting, rather than waiting for more accurate recommendations to be created or determined, treatment recommendations can be presented before the meeting. In other examples, providing a guidance message can include providing the message when calculated to be useful to the user. For example, when a user is about to go on their regular run, a guidance message with treatment or monitoring recommendations can be provided before the run, as opposed to when the user has a tendency to head towards low blood sugar levels.

[0434] Figure 5B Figure 5B is a flowchart diagram of an exemplary method 501 for determining and providing a calculated guidance message that is personalized and useful in the treatment management of diabetes for a patient when calculated to be useful to the patient. The example described with reference to Figure 5A can also be applied to the method of Figure 5B.

[0435] At 501, the method can include measuring, determining, or receiving first real-time data related to a patient. The first real-time data can be, for example, glucose concentration values, times, meal information, requests for advice, activity information (e.g., from a fitness tracker or watch), or insulin delivery information that can be received via a user interface (e.g., via a smartphone app) or from a smart device such as a pen or pump.

[0436] At 503, the method can include using a model to determine a patient's state. For example, the determination can be based on a patient's physiological model, behavioral model, and measurement model. The state can be determined by applying the real-time data to the patient's physiological model and behavioral model. The patient's physiological model can be, for example, a state model that includes one or more of a glucose concentration state, an insulin on board state, an insulin sensitivity state, an energy absorption state, or an energy exercise state. A particular state can be determined by the characteristics of the available inputs (e.g., time, glucose level, previous activity, etc.).

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

[0438] At 507, the method can include providing, via a user interface, the determined personalized guidance message such that the provision occurs when it is calculated to be useful to the patient in the treatment management of their diabetes. Providing the determined personalized guidance message can include providing the personalized guidance message on the user interface.

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

[0440] Learning of the model can be performed before or after receipt of real-time data. For example, the method can further include determining a deviation from an expected state after delivery of a personalized guidance message and adapting the model based on additional input information.

[0441] Figure 6 FIG. 6 is a flowchart showing an exemplary method 600 for determining and providing personalized, useful calculated guidance messages to a patient in the treatment management of diabetes. At step 602, 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 patient's state can be determined by applying data to a state model. The patient's state 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 action time state, or a combination thereof. The state model can also include a state of behavior or context or a measurement state. The state model can be, for example, a probabilistic state model. The state model can include state transition probabilities 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, the state or number of states can be determined based on CGM data and other input data to determine the patient's state. In other words, the system can process the model in reverse to determine the combination of parameters that is most likely to provide the current CGM value of X. This combination of parameters (e.g., state) can be regarded as the "patient's state".

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

[0444] Figure 7 Figure 7 is a flowchart diagram of a method 700 for determining and delivering guidance messages that are personalized and can be useful to a patient in the treatment management of diabetes.

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

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

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

[0448] Figure 8 FIG. 8 is a flowchart diagram of an exemplary method 800 for providing a decision support function to a user. The method can include, at 802, loading a model into a memory of a computing environment. The method can also include, at 804, receiving data indicative of a glucose concentration value of the user. The method can also include, at 806, displaying insights calculated on a user interface of the computing environment. The insights can be calculated using, for example, at least the model and data indicative of the glucose concentration value. In some examples, a user request can trigger the display of the calculated insights. The user request can be associated with, for example, data entry of a planned activity. The calculated insights can indicate user actions calculated by one or more of the models to bring about a desired result 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 can be, for example, a meal, and the calculated insights can be, after the meal, a calculation or predicted effect of the meal on the glucose concentration value, or a strategy (e.g., insulin delivery or activity or both) for managing the glucose concentration level. In some examples, the calculated insights can include interactive recommendations and at least one factor used in determining the interactive recommendations.

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

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

[0451] Figure 9 Figure 9 is a flowchart diagram of a method 900 for delivering physiological glucose concentration management guidance. At step 902, the method can include receiving data indicative of a glucose concentration level. At step 904, the method can include determining a state by applying the data to a model. At 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's 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 Figure 10 is a flowchart diagram of a method 1000 for delivering physiological glucose concentration management guidance. Method 1000 can include, at step 1002, receiving data indicative of a glucose concentration. At step 1004, the method can include determining a patient's state by applying the data to a model.

[0453] In step 1006, the method can include determining whether the patient's state is atypical. Determining whether the patient state is atypical can include determining whether the patient state 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 state includes determining the physiological state and the behavioral state, and determining whether the determined physiological state is atypical with respect to the behavioral state. In a further example, determining whether the patient's state is atypical includes identifying a blood glucose concentration level that deviates from the 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 can include determining a guidance message based on the atypia of the patient state, and in step 1010, can include delivering the guidance message via a user interface.

[0455] Figure 11 FIG. 11 is a flowchart diagram of a method 1100 for delivering physiological glucose concentration management guidance. The method can include receiving data indicative of a glucose concentration, determining a patient's state by applying the data to a model, determining from the model whether 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 as having a low probability of transitioning to a particular state under normal conditions, but under particular conditions, the pattern can be recognized as having a likelihood of the transition actually occurring, as indicated by real-time data or user input. For example, the method can include warning a user that a non-typical state is likely when the glucose level is being normally controlled at that time. For example, the user can be warned about an expected low glucose level after exercise. Exercise can lead to a low glucose level several hours after the exercise is completed (e.g., due to an increase in insulin sensitivity or a restoration of glycogen stores). The user can be warned about such a "late and low" likelihood or probability. If calculated to occur low during sleep or at an inconvenient time, the warning can be delivered or prioritized. In some examples, the warning may be delivered when calculated to be useful to the user, such as before the patient is expected to be in a sleeping state, to avoid waking the patient or caregiver.

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

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

[0458] Exemplary Inputs and Outputs - FIGS. 14 - 16 The flowchart 650 of FIG. 14 shows a method for quantifying ambiguous inputs. In particular, when an ambiguous input is received (step 219), one way to quantify it is to perform natural language processing steps on the input to determine a "clear" equivalent (step 221). For example, if a user qualitatively indicates that they consumed one glass of orange juice, natural language processing determines the number of carbohydrates contained in one glass of orange juice, and the input is converted from ambiguous to clear. In this regard, historical pattern data can also be used. Similar such natural language processing can be used to determine the clear nutritional content of inputs such as "ate a Quarter Pounder at McDonald's". Social networks and social media can also be used to provide context to ambiguous inputs or otherwise tighten the values associated with ambiguous inputs (step 223). Also, big data can be used (step 225) to provide context and clear values to non-clear inputs. 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 clarify a version of the input that can serve as a quantifiable criterion for use in influencing decision-making.

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

[0460] However, prior to a general discussion of the input, referring to FIG. 15, a particular type of relationship is shown, and the particular relationship is shown by 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 the systems and methods according to this principle. Processing step 237 is shown to illustrate how a correlation parameter, such as food sensitivity 233d, is used with real-time inputs (not shown) within processing step 237 to yield a treatment recommendation for meal bolus 235a. Specific examples of these inputs and outputs are described in the "Examples" section below.

[0461] The identification of correlation parameters and lifestyle / situation parameters, and subsequent processing steps, can be performed in various ways. For example, the steps can include factors from various sources such as social networks, user input data, sensor data, data from user devices, population or big data. The processing and identification can include, for example, Bayesian analysis to identify strong connectors that are parameters or variables having a strong relationship with each other. When multiple parameters are used, the same can include multiple parameters related to the same event, for example, both the intensity and duration of 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 using "big" data using, for example, pre-packaged subroutines or 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 powerful in terms of computing capabilities, much of 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 "influence factor" X affects the patient, for example, how exercise affects insulin sensitivity. In this example, although the pump operation was started by a bolus, if the user executes it without considering the effect of exercise, the system and method according to this principle can detect this series of events and provide recommendations to the user such as "expect a decrease" or "need to eat something now".

[0462] As described above, the last step of this method is to change the input or output interface based on the identified correlation parameters or correlation states, and real-time inputs. Real-time inputs can include lifestyle or behavior or situation parameters such as time, events that are about to occur as determined by a clock or calendar application or user input, glucose values, etc. In other words, the machine / human interface is changed by a decision support application / function based on the results of the above steps, for example, on a smart device, smartphone, smartwatch, and / or as part of the input user interface or output user interface of any of these devices. For example, the output user interface, i.e., the type, format, and content of the output, can then depend on the lifestyle / situation context, as well as the parameterized model and / or user-defined functions. Note that specific user-defined functions, such as lifestyle goals, do not have to be used in all implementations but can be advantageously used to derive specific treatment recommendations.

[0463] In changing the machine's human interface, the output can be provided in categories or "fuzzified" in the same way that the input is classified or "fuzzified", and this is particularly true when the output is simply provided in the user interface of the display. For example, if the therapy recommendations suggest that the user has a large glass of orange juice or eats a medium-sized apple, the user may find such recommendations more useful than recommendations to eat a specific amount of carbohydrates. Of course, if the output includes output to a pump or pen, such "fuzzification" is not necessary and generally high accuracy is desired.

[0464] Figure 15 - Output Exemplary outputs are as shown in FIG. 15 and include, for example, recommendations for the type, amount, and timing of a meal bolus 235a, recommendations for the type, amount, and timing of a correction bolus 235b, recommendations for the type, amount, and timing of a meal 235c, changes to a user interface 235d that provides a warning or alert at a time determined to be effective for the user, such as, or pre-event or situation determinations 235e that are decisions made, for example, prior to sleep, meals, exercise, driving, activities, etc. Other exemplary outputs include permanent or temporary changes to a basal rate setting, recommendations for rescue carbohydrates, and the like. How the same is modified depending on a particular output and decision support application / function will be described in the "Output" section below.

[0465] Regarding providing a decision support application / function in a way that supports user-defined functions, various core methods have been described above, but it should be understood that the core methods need not be mutually exclusive. For example, various combinations of core methods may be employed in a given implementation. Further, multiple methods may be executed in parallel to determine an optimal treatment and select the safest option. That is, various algorithms as described above can be used to calculate an optimal diabetes treatment decision using defined states, sensor data, user input, and other available information. Multiple methods can be executed in parallel to calculate an optimal treatment decision, and then the most conservative or safest solution can be provided to the user. For example, during sensor noise, an estimated current glucose value can be calculated using either a filtered value or a raw sensor value, followed by calculating a recommended insulin bolus. Doses can be calculated in parallel based on both sensor values, and a more conservative dose can be recommended. Another example is using an estimated rate of change of glucose as the difference between two points of a pair of most recent glucose values, based on a trend calculated by a CGM algorithm, where a rate of change that provides a more conservative dose is used.

[0466] Several exemplary inputs and notations regarding such inputs are shown in a table. It will be understood that other inputs can also be used and the notations given regarding 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 variations, a particular input may be specified as being input by a user, but in some cases it may be determined by a sensor or the like. For example, diet data can be determined by user input, but can also be determined by GPS, from pattern data, or from an app such as a camera. As described above, the decision-making support application / function incorporates machine learning to improve the accuracy and appropriateness of treatment prompts over time. For example, diet data such as "light meal", "moderate meal", etc. input by the user can be "learned" by the system so that the decision-making support application / function can better understand over time what the user considers to be a "light meal", etc. Temporal patterns can be analyzed by the system and method to determine, for example, diet and exercise patterns, but the user can also identify and quantify events to be tracked, including those corresponding to diet and exercise.

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

[0468] When multiple types of data are used as input to a given algorithm, the multiple types may be related, for example, variables such as illness, exercise, diet, sleep, etc., can be, for example, type, timing, and intensity, 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 further divided into subcategories as follows: data from sensors (248 and 252), data entered by the user, or data from other applications such as appropriate APIs, derived data, and user data 254 which can be other data. Some subcategories are shown for both real-time data and non-real-time data. In any case, the input 246 is then supplied to a user device 256 which can be a dedicated receiver or a smartphone, more specifically, to a decision support application 260 disposed therein. The derived data 262 can be stored in the user device 256, and the display 258 can be provided with a user interface for displaying prompts to the user and for receiving user input data. The derived data 262 may be derived by a processor within the user device 256, and the derivation of the data may occur within or outside of the decision support application / function.

[0470] Figure 16 - Input Referring again to the types of data shown in FIG. 16, the sub-subcategories either describe a particular type of data or are themselves categories. For example, the sub-subcategories of real-time data are "physiological sensors", which can be further divided into different types such as, for example, 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 modes of the CGM system itself, temperature sensors, etc. Such inputs may be provided from wearable devices / sensors such as, for example, those available from an Apple Watch®, Fitbit®, or other wearables. Other devices that can provide the input can include other mobile devices including smartphones.

[0471] Sensors such as accelerometers and GPS can be conveniently used to provide data regarding the movements and activities performed by a user. In some cases, GPS or other sensors can also be used to determine other types of activity data, for example, when the user is driving, the output to the user can notify, for example, whether it can be displayed on either a smartwatch or a smartphone.

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

[0473] In some cases, a decision-making support application / function can be made capable of inputting data regarding the start of the menstrual cycle (or other markers). In this way, the user can track the behavior of blood glucose levels over several months at various times of the month regarding the cycle. Of course, such algorithms and data can also be used by themselves to assist in pregnancy efforts or when using the rhythm method for contraception.

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

[0475] Other subcategories of real-time data input include user input 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, meal data, exercise data, blood glucose data from an external blood glucose meter, and the like. Since the user input data can include the user's estimated value of the glucose level, it can provide decision-making support in a way that more appropriately correlates the glucose level perceived by the user with the actual glucose level. For example, enabling a decision-making support application / function can better assist in determining and identifying how the user feels about various levels of hyperglycemia. The user input data can also include the user's population statistical data 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, the systems and methods according to this principle can enable the user to save a specific workout or event, analyze the pattern of post-workout blood glucose fluctuations for potential discovery, and make appropriate automatic or manual treatment changes by a decision-making support application / function. For example, the user can save workouts such as "Cardio1", "Cardio2", "GetSwoll1", "GetSwoll2", etc. Other aspects of the exercise can include intensity, e.g., light, moderate, intense, and duration, e.g., 5 minutes, 10 minutes, 15 minutes, 20 minutes, 25 minutes, 30 minutes, 1 hour, etc.

[0477] The goal data can include the display of priorities regarding glucose control, for example, hypoglycemia avoidance and hyperglycemia avoidance. Different control types can be provided as pre-programmed profiles that the user can select when choosing goals. For example, the user can select goals such as low minimization control, ultra-minimization control, frequent versus occasional correction bolus, etc., to match different treatment styles and goals.

[0478] Similarly, user feedback can also constitute an important input to decision-making support. That is, the decision-making support application / function can be changed based on user feedback. For example, the user can be periodically queried about what changes they want to make regarding recent blood glucose control, and options such as "want to reduce the number of nocturnal hypoglycemias" or "wish to not need to give corrective boluses frequently" can be provided. Feedback can be requested in a convenient way to minimize user annoyance. For example, feedback can be provided by a slider bar or other user interface elements convenient for user selection. The slider bar can also be provided for other user inputs, for example, to indicate how desirable the interaction is.

[0479] As described above, the decision-making 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-making support application / function can be provided using a user interface that provides the user with a predetermined dose adjustment, such as + / −0%, + / −10%, + / −20%, etc. The dose adjustment presented can itself depend on the CGM trend. For example, in the case of a negative or decreasing glucose trend, a negative dose adjustment can be provided. The selected adjustment is applied to the calculated bolus dose regardless of the presence or absence of other trend adjustments. Alternatively, the adjustment can be made fuzzy. In still other implementations, the user can choose to customize the adjustment within a boundary. Over time, based on the data, the decision-making support application / function can determine an optimal adjustment based on this user input data (and other inputs), and with the approval of the provider (or without provider approval / confirmation), the adjustment options can be presented to the user for re-decision.

[0480] In related implementations, instead of percentages, rate-of-change data can be used to increase / decrease the bolus value calculated at a fixed amount. In this way, the patient can use their insulin sensitivity / correction factor to add or subtract enough insulin from the meal bolus to cover that amount of glucose change. In this implementation, initially, the bolus calculation can be left unchanged, and the decision support application / function can learn the amount of insulin addition or subtraction required based on the rate of change as part of a case-based learning process. For example, instead of updating insulin sensitivity, when glucose is rising or falling, the system can learn how far the glucose is from the target and consider that to be the amount of glucose to be explained. In this case, no new insulin sensitivity is learned, but instead, the best insulin sensitivity estimate is used based on other descriptors of the case, such as lifestyle factors, specific to the insulin sensitivity of a breakfast without exercise. Since it may be desirable to learn both the amount by which to adjust the insulin bolus based on the rate of change and the change in insulin sensitivity with respect to time, exercise, etc., the systems and methods according to this principle advantageously separate the two problems and can perform only insulin sensitivity updates when the rate of change is relatively stable. Learning how much the user needs to adjust their insulin based on the rate of change can, for example, push such data to the HCP that shows a pattern where the user's post-meal glucose is always too high, around about 30 mg / dL, when the user takes a meal bolus and the trend arrow is 90 degrees up, and the HCP can be requested 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 rate of change using percentages or fixed amounts, 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 description of the various inputs, the input can include data about the user's followers or data about other relevant users. This input data can include, for example, data related to social grouping for achieving individual or group goals, and can further use natural language processing to derive the objective and quantifiable desires and goals of the group or its members. The input can further include input from followers as a response to queries such as, for example, "What do you think is happening to your daughter?".

[0482] Other sources of real-time data input by the user include dietary data. The user can input dietary data in a fuzzy or classified manner, or as a distinct input. Machine learning can be used to learn objectively how the user classifies their diet. For example, with respect to what is input into a decision-making support application / function, if the user classifies their diet as "small portion", the system can learn in a more quantitative or objective way what the user considers a "small portion" diet to be. The same applies to other sizes of meals that are input and called. The same also applies to data regarding the composition of the meals input by the user. In other words, the system can learn what the user means when the user inputs a dietary composition statement into a decision-making support application / function. For example, if the user classifies their diet as "high carbohydrate", the system can learn, from data regarding glucose reaction and the provided insulin (if available), in combination with the dietary data, what the user considers to be "high carbohydrate".

[0483] Other subcategories of real-time data input include data from other applications or "apps", such as data from generally suitable APIs. Such apps can reside in a computing environment that provides a decision-making support application / function or communicate with it, either wired or wirelessly. Such apps include calendar apps, GPS apps, CGM apps, apps that hold historical data and other information, SMBG apps, temperature monitor apps, Healthkit (registered trademark), data from followers such as text messaging apps, bolus calculation apps, clock apps that provide time, apps that show elapsed time to enable user prompts to be provided at optimal times, apps that provide access to cloud data or "big" data, camera apps, pump applications, pen applications, bolus calculation applications, etc. As a specific example, a text messaging or email app can refer to an event such as a dinner party. Through a suitable API, a text messaging or email app can function as an input source for calendar data. In a specific example, there can be an option to "add an event to the CGM", or the CGM (or equivalent decision-making support application / function) can automatically pull event data each time a calendar event is added. Such a function provides a way to collect event data and easily check how events affect glucose trends, enabling the user to create calendar events and CGM events simultaneously.

[0484] For example, decision support for a bolus calculator generally requires the input of meal data. In one implementation, a camera application can prompt the user to take a picture of the meal on the plate (see FIG. 18A). The user can take a picture using the phone's camera, and brackets can be provided as part of the user interface on the screen to guide the user on how to take the picture. Next, the app can measure the size of the meal in relation to the size of the plate and can indicate the meal as, for example, small, medium, or large. Next, the app can present a recommended dose based on the size of the meal. In a more enhanced implementation, the app can use photo recognition technology to determine, estimate, or infer what is on the plate and provide an estimate regarding the resulting meal composition. Variations are understood. For example, in an alternative implementation, the user prompt can instruct the user to swipe the sizes of different circles (or other shapes) over the picture of the meal on the plate (see FIG. 18B). Next, the app can 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 by the app includes pump or related data, including recent boluses, basal rates, etc. As another example, the prompt may be provided based on the estimated insulin on board, in conjunction with CGM input and other contextual information. Insulin on board is a term that represents the amount of insulin that has been administered to the patient but has not been used by the body to transport glucose to the tissues. After a meal bolus is taken, if the estimated insulin on board is still half of the original dose but the measured glucose has already dropped to 80, continuous insulin activity is expected and further glucose lowering to hypoglycemic levels may occur, so a warning can be provided.

[0486] More specifically, patients who are administered too much insulin are at risk of hypoglycemia and possible death. Currently, there is no real-time measurement method to measure the amount of insulin in a patient's body. Insulin stacking occurs when a patient using insulin administers multiple boluses of insulin in a short period of time. Insulin from a previous administration may not have exerted its full effect, and thus the patient may give themselves an excessive amount of insulin in subsequent administrations, posing a significant risk of hypoglycemia to the patient. A continuous direct insulin sensor can be used to measure the amount of insulin in a patient's body. This detector can be used as a warning or failsafe to shut off the pump or artificial pancreas. Since each patient generally has a different insulin sensitivity (although this sensitivity can be learned using the decision support applications / functions described herein), multiple thresholds are generally required for warning settings.

[0487] A second aspect of this implementation involves using a direct insulin sensor to monitor a patient's insulin amount. The amount of insulin can be used to provide feedback that recommends a safe dosage of insulin for the patient. Insulin information can also be transmitted directly to a computer 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 current on-board insulin estimation used in bolus calculators.

[0488] This third aspect of the implementation describes the use of a direct insulin sensor for measuring a patient's insulin sensitivity. Insulin sensitivity can vary depending on the patient and even over time in the same patient. Thus, the systems and methods according to this principle can use a direct insulin detector to measure the amount of insulin in a patient's body. By combining information on glucose and insulin concentrations within the patient into an algorithm, insulin sensitivity can be calculated. Next, the information contained in the insulin sensitivity can be used to determine whether to increase or decrease the amount of insulin administered to the patient, for example, or to use insulin sensitizers, insulin secretagogues, or insulin to best control those glucose levels in order to manage diabetes.

[0489] Returning to the input chart of FIG. 16, as another example of real-time data that can be used even non-real-time, GPS data from an app or other sensors can be used by a user while out and about, for example, to determine potential followers or friends for a university user.

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

[0491] As another example of input, safety rules can be used to provide decision support at various levels of aggressiveness. For example, if a user does not provide detailed dietary information, a decision support application / function that prompts the user to raise their glucose level to the target range can aim for the upper limit of the target range rather than the center of the target. Similarly, if a user provides dietary data indicating a very large amount of carbohydrates, the decision support application / function can aim for the upper limit of the target range again because it is known that carbohydrate count errors have a worse impact as the overall amount of carbohydrates increases.

[0492] As another example of input, the diagnosis of a device can not only function as an input including the signal quality and reliability of the device, but also determine risk stratification based on it. For example, a meal or correction bolus or other decision support prompt may be at least partially informed by a confidence interval, which may be at least partially informed by device signal quality and / or detected malfunctions.

[0493] Cloud or big data can also be used. As an example of the use of cloud or big data, an HCP may desire to determine an initial value of insulin resistance or insulin sensitivity. The HCP can input population statistics data such as weight, age, gender, etc. Next, the app can search a database, find the user most similar to the target user, and use the average setting as the first candidate. Cloud or big data can similarly be further used for initial risk stratification based on aggregated counts.

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

[0495] Still other types of input include derived data. In some cases, derived data, which can also constitute real-time data, includes the rate of change or acceleration of an analyte, various types of sensitivities such as insulin, sleep, diet, and / or exercise, hierarchies within risk stratifications (described in more detail below), glucose variability, user stress / affect / mood data, user desires for interaction with the device, sensor accuracy / reliability / signal quality, pattern data, and the like. Such sensitivities often constitute lifestyle factors as defined above. Since hormone levels are known to be relevant factors, detection of the above hormone levels can be further useful for detecting and quantifying insulin sensitivity.

[0496] Insulin sensitivity can be based on sleep, energy intake vs. energy expenditure, food intake, etc. Insulin sensitivity can change rapidly, for example, by the circadian rhythm. Insulin sensitivity is known to be event-driven, stress-driven, and also driven by factors such as illness, activity, etc. When a user employs a CGM monitor, events that affect insulin sensitivity can be detected, and measurement of insulin sensitivity can also be determined from knowledge of carbohydrate intake to glucose and the basal / bolus amount 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, seeing how glucose values change with respect to various events including meals, exercise, stress, etc., and further performing the same test with various changes to 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 diet sensitivity can be further refined, for example, by determining sugar sensitivity, dinner sensitivity, etc. It will be understood that other such perturbations or interaction sensitivities can also be derived.

[0498] The ratio of "insulin to carbohydrate" can also constitute the derived data, and the same is generally determined and optimized using retrospective analysis. Using the same, by graphically showing the various levels of influence from insulin to carbohydrate, decision support education can be provided to the user. In particular, with knowledge of insulin delivery, a decision support application / function, or a related or connected module can, for example, change the retrospective glucose trend line to show the user the effects of using various ratios of insulin to carbohydrate on glucose levels. Within the decision support application / function, the optimal insulin to carbohydrate ratio setting can be automatically determined, and further, how the insulin and carbohydrate settings change depending on time of day, activity level, etc. can be determined.

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

[0500] For an initial or seed value of insulin sensitivity, population data can be used from a patient database, particularly a patient database of patients with similar characteristics such as weight, age, gender, length of diabetes, etc. Such can be used as default values and can be automatically adjusted as additional information about the user becomes known over time.

[0501] Diet data may also be in the form of derived data, similar to that obtained from food patterns, food libraries, etc. In other ways of deriving diet data, retrospective analysis can be used to estimate the carbohydrate content of a given diet using other data. Such other data can include, for example, delivered insulin, glucose levels, exercise, health, meal times, etc. By collecting such data, the decision support application / function can determine the user's typical diet and the typical glucose response to that diet, while reducing the impact of other factors on glucose. Such functions have several advantages, such as improving the accuracy of the bolus calculator, optimizing the warning function when the system notices an abnormal glucose response, assisting in understanding the user's diet pattern and the impact of various diets on glucose, and more accurately calculating the insulin-to-carbohydrate ratio.

[0502] The derived data can further include user estimation data, such as whether and to what extent the user is prone to making errors in carbohydrate counting, for example, tendencies to overestimate or underestimate.

[0503] The derived data can also include data determined for recognized patterns, where the patterns are recognized by analyzing historical data over time. Exemplary recognized patterns include patterns such as nightly hypoglycemia, post-meal highs, post-exercise lows, etc.

[0504] One way to determine such patterns or detect the occurrence of glucose events not in the pattern is to "bin" specific events defined by specific characteristics. That is, a portion of the glucose trace that meets a given criterion indicating a specific diabetes issue, such as rebound hypoglycemia, is detected, and then patterns can be sought in these events "binned" accordingly.

[0505] From Figure 19 onwards More specifically, and referring to the flowchart of FIG. 19, the signature or fingerprint of glucose sensor data can be identified or distinguished within an individual patient based on several predetermined criteria (step 262). Such criteria can include time-based criteria and / or specific incidents detected within specific constraints. In this system, according to this principle, bins may be distinguished by different criteria. A supervised learning algorithm can be used to learn more bins for individual specific patterns. For example, the bins can be based on insulin data, the rate of change of glucose data (or its acceleration / deceleration), such as events that occur before a small meal, the individual's reactivity to glucose information, etc., and patterns of data previously identified and used to characterize the data.

[0506] The next step is that incidents can be characterized, for example, based on a decay curve, waveform signature, etc. (step 264). Exemplary incidents can include, for example, a meal bolus indicator based on insulin data, which can be classified 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 the rate of change / acceleration / deceleration. Incidents can also be characterized based on their correlation with pre-meal events, such as those corresponding to the above patterns of data. Incidents can further be based on behavioral patterns, such as the frequency with which the user checks their glucose data or responds to an alarm, such as those that can be correlated with the above responsiveness data. It will be understood that other bins can also be used.

[0507] Next, the characterized incidents can be binned (step 266). Thereafter, by synchronizing for each incident, the bins can be adjusted to the physiological functions of a specific patient. Next, the bins can be normalized. That is, a normal distribution of the incidents within the bins can be defined (step 268).

[0508] Subsequently, the normalized bin information can be actively used as an input to a decision support application / function, for example, in the determination or definition of the state according to step A (step 268). As an example, the normalized bin information can be used as an 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. Using the binning technique, it is possible to determine when a patient should adapt the data based on behavioral inputs, which can enable more aggressive recommendations as opposed to when the bolus recommendations are generally more conservative and the user is not focused on glucose information, such as at night.

[0509] Returning to FIG. 16, for non-real-time data, the inputs can include user input data such as previous SMBG data, the user's knowledge of the technology, target data, problems to be solved, desires for a specific treatment, target glucose levels, population statistical data such as age and gender, heart health status, cholesterol levels, the type of mathematical calculations to employ (usually default or entered by the HCP), data regarding illness or pregnancy or menstruation, data regarding medications taken, smoking history, etc. Non-real-time data can also include derived data such as historical patterns, gastric emptying times, etc. Other non-real-time data can include data regarding followers, for example, communication tone, language, etc. These can be used when changing the output to enhance the user's effectiveness.

[0510] Regarding gastric emptying time, it has been pointed out that 25% of the diabetic population (type 1 and type 2) experiences some form of delayed gastric emptying. 7 - 12% of the same group suffers from an increase in delayed gastric emptying. The population with delayed gastric emptying is increasing at a very high rate within the diabetic population and is currently a concern for medical professionals within the general population.

[0511] Current bolus wizards have certain risks because they do not take into account gastric emptying. For example, if gastric emptying is not incorporated into a closed - loop pancreatic system, the individual bears the risk of glucose fluctuations where corrections are repeated and insulin delivery decreases. This results in chaotic insulin delivery similar to a successive approximation waveform over time. If the same is not used in a bolus calculator for an insulin pump, hypoglycemic events that roughly correlate with the size of the administered meal can occur, thus putting the person at risk as a result. They also risk hyperglycemic events that are similarly roughly correlated with meal size because their effect becomes effective when insulin responsiveness is reduced and decreasing within the system.

[0512] Over time, such fluctuations can manifest in further damage that may potentially reduce gastric function over time. Additionally, the person has an increased risk of peripheral neuropathy.

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

[0514] Common instructions given to insulin-dependent diabetes patients are to administer (bolus) 0 to 30 minutes before a meal. The reasonable reason for this instruction is to time the effect of insulin to correspond to the time when the consumed food enters the absorption stage. This timing is accurate when gastric emptying is not a problem (75% of the type 1 and type 2 populations). However, in the balance of the population, the delivery time of insulin is inaccurate. Rapid-acting insulin reaches its maximum effect about 90 to 120 minutes after bolus administration. This is due to the delay from bolus administration, propagation in the body, and attachment to the A and B receptors on the cell surface. At that time, the cells can process sugar. However, in the case of individuals with delayed gastric emptying, the delivery of processed food to the system has not yet occurred. In the case of these individuals, about 90 to 120 minutes after the meal (when a bolus was administered 30 minutes before the meal), they experience hypoglycemic events. This event is generally addressed by liquids such as orange juice that enter the intestine and system earlier than solid foods.

[0515] The insulin response decreases at the end of the peak in cases of increased gastric emptying delay when the food is being processed and entering the system. This results in hyperglycemic events that require the administration of a correction bolus. Therefore, the gastric emptying time can be used as an input to provide a time delay for the delivery of the post-meal bolus. This delay can be applied to a bolus calculator or a closed-loop artificial pancreas system. The gastric emptying time can also be used as an input to provide a time delay for the modified basal rate after a meal. This delay can be applied to an insulin pump or a closed-loop artificial pancreas system.

[0516] One way to determine an individual's gastric emptying delay is as follows. When a CGM user enters a bolus and a...

Claims

1. 1. A system comprising: a glucose concentration sensor configured to detect a glucose concentration level of the patient; a communication circuit configured to receive a glucose concentration level of the patient from the glucose concentration sensor; a memory circuit containing the stored model; 1. A processor comprising: receiving a glucose concentration level of the patient; Executing the stored instructions to apply the patient's glucose concentration level to the stored model to determine a state; and a processor configured to determine a guidance message based at least in part on the determined condition.

2. The system of claim 1 , wherein the processor is also configured to determine the guidance message based at least in part on a temporal pattern.

3. The system of claim 1 , wherein the model comprises a physiological model, and determining the state comprises determining a physiological state.

4. The processor further comprises: Determine the behavioral state, The system of claim 3 , configured to determine the guidance message based at least in part on the behavioral state.

5. The system of claim 1 , wherein the processor is further configured to provide a treatment recommendation based at least in part on the determined condition.

6. The system of claim 1 , wherein the system comprises a mobile device, the mobile device comprising the memory circuit and the processor.

7. The system of claim 6 , 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.

8. 8. The system of claim 7, wherein the mobile device communication circuitry includes a first wireless transceiver, the glucose concentration sensor communication circuitry includes a second wireless transceiver, and the mobile device communication circuitry and the glucose concentration sensor communication circuitry communicate using a wireless communication protocol.

9. The system of claim 6 , wherein the mobile device includes a user interface configured to provide a guidance message.

10. 10. The system of claim 9, wherein the mobile device is configured to receive user input via the user interface, and the processor is 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 condition.

11. 10. The system of claim 9, further comprising an insulin delivery system.

12. The system of claim 11 , wherein the insulin delivery system comprises an insulin pump.

13. The system of claim 11 , wherein the insulin delivery system comprises an insulin pen.

14. The system of claim 1 , comprising a user interface configured to provide the guidance message to a patient.

15. 1. A method for 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 temporal patterns.

16. The method of claim 15 , wherein the temporal patterns comprise learned patterns of patient behavior.

17. The method of claim 15 , wherein the temporal pattern comprises a calendar.

18. 20. The method of claim 17, wherein determining a guidance message is based at least in part on an upcoming event in the calendar.

19. 20. The method of claim 18, wherein determining a guidance message is based at least in part on a predicted change in insulin sensitivity calculated based at least in part on the upcoming event in the calendar.

20. 16. The method of claim 15, wherein the model includes a physiological model, determining the state includes determining a physiological state, and determining the guidance message includes determining from the temporal pattern and the physiological model a probability that a transition to an undesirable physiological state will occur.

21. The method of claim 20, wherein determining a guidance message includes determining an intervention to avoid the transition to the undesirable physiological state and determining a time for delivery of the guidance message to enable intervention to prevent the transition based at least in part on the temporal pattern.

22. 16. The method of claim 15, further comprising using the temporal pattern to determine a delivery time for delivery of the guidance message.

23. 23. The method of claim 22, wherein determining a delivery time comprises selecting a delivery time if a host is likely to be available based at least in part on the temporal pattern.

24. 23. The method of claim 22, wherein determining a delivery time comprises identifying an upcoming period of patient unavailability and selecting a time for delivery of the guidance message prior to the period of patient unavailability.

25. 16. The method of claim 15, wherein determining a guidance message includes identifying periods of patient unavailability based at least in part on the temporal pattern, and wherein the guidance message is calculated to promote glucose concentration stability during the periods of patient unavailability.

26. moreover, Determining an engagement status; and determining a messaging frequency based at least in part on the engagement state; and determining a time to deliver the guidance message based at least in part on the messaging frequency.

27. moreover, determining that the 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 to deliver the second guidance based at least in part on the new messaging frequency.

28. The method of claim 15, wherein the condition is a disease state describing a host disease stage.

29. moreover, 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 the model; and determining a second guidance message based at least in part on the second disease condition.

30. The method of claim 15 , wherein determining a condition comprises determining a physiological condition.

31. 31. The method of claim 30, wherein determining a physiological state includes determining an insulin state, an energy absorption state, and an energy expenditure state.

32. The method of claim 15 , further comprising receiving a behavioral input, and wherein determining a state comprises applying both the data and the behavioral input to the model.

33. 33. The method of claim 32, wherein receiving the behavioral input comprises receiving patient activity information.

34. 1. A method for delivering physiological glucose concentration management guidance, comprising: receiving data indicative of a glucose concentration; determining a physiological state using said data; and Determining a behavioral state; and 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.

35. 35. The method of claim 34, further comprising determining a time to deliver guidance to enable timely intervention to affect the glucose concentration.

36. 35. The method of claim 34, further comprising determining a level of interest in guidance based at least in part on the behavioral state and the physiological state.

37. 37. The method of claim 36, wherein determining a level of interest in the treatment guidance is based at least in part on a user request for previous guidance.

38. 35. The method of claim 34, wherein determining a behavioral state comprises receiving a behavioral input and applying the behavioral input to a behavioral state model.

39. 35. The method of claim 34, wherein determining the behavioral state includes checking a user calendar for scheduled events.

40. 35. The method of claim 34, wherein determining the physiological state comprises applying the data to a physiological state model.

41. 41. The method of claim 40, wherein the physiological state model includes a glucose concentration level.

42. 42. The method of claim 41, wherein the physiological state model further comprises one or more of an insulin state, an energy absorption state, and an energy expenditure state.

43. 35. The method of claim 34, further comprising determining a measurement state, the measurement state comprising a precision or accuracy of the data indicative of the glucose concentration.

44. 35. The method of claim 34, wherein determining a guidance message comprises determining that a low probability physiological state transition is likely to occur, the guidance message providing advance notice of the low probability physiological state transition.

45. 45. The method of claim 44, wherein the low probability physiological state transition comprises a transition to a low glucose concentration level or a high glucose concentration level.

46. 45. The method of claim 44, wherein determining a guidance message includes determining that the low probability physiological state transition is likely to occur at an inconvenient time, and wherein 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.

47. 47. The method of claim 46, wherein determining that the low probability physiological state transition is likely to occur at an inconvenient time comprises applying a behavioral input to a behavioral state model.

48. 35. The method of claim 34, further comprising receiving an additional physiological parameter, wherein the physiological condition is determined using both the data and the additional physiological parameter.

49. 49. The method of claim 48, wherein the additional physiological parameters include body temperature, heart rate, or respiration rate.

50. 35. The method of claim 34, further comprising receiving, during a learning period, learning data describing at least one of a physiological state or the behavioral state, wherein at least one of the physiological state or the behavioral state is determined after the learning period using the learning data.

51. 1. A method for determining and providing a patient with a personalized and useful calculated guidance message for diabetes care management, comprising: receiving data relating to the patient, including a real-time glucose concentration level; determining a patient state by applying the data to a state model; and and providing a treatment recommendation based at least in part on the determined condition.

52. 52. The method of claim 51, wherein the patient conditions include an insulin on-board condition, an insulin sensitivity condition, and a food consumption condition.

53. 52. The method of claim 51, wherein the state model is a probabilistic state model.

54. 54. The method of claim 53, wherein the state model comprises state transition probabilities learned from retrospective data.

55. 52. The method of claim 51, further comprising refining the condition model using data received after delivery of the treatment recommendation.

56. 1. A method for providing decision support 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 insights calculated using at least the model and the data indicative of the glucose concentration values ​​on a user interface of the computing environment.

57. 57. The method of claim 56, wherein the causing is initiated by a user request.

58. 58. The method of claim 57, wherein the user request is associated with data input of a planned activity, and the calculated insight is indicative of a user's behavior calculated by one or more of the models to result in a desired outcome associated with the glucose concentration value.

59. 59. The method of claim 58, wherein the desired outcome is a glucose concentration value within a predetermined target range.

60. 60. The method of claim 58, wherein the desired outcome is a glucose concentration value having a rate of change within a predetermined target range.

61. 59. The method of claim 58, wherein the planned activity is a meal and the calculated insight is a calculated or predicted effect of the meal on the glucose concentration value.

62. 60. The method of claim 58, wherein the calculated insights displayed include interactive recommendations and at least one factor used to determine the interactive recommendations.

63. 57. The method of claim 56, wherein causing the display of the calculated insight is triggered by the occurrence of an event matching a predetermined condition.

64. 57. The method of claim 56, wherein causing the calculated insight to be displayed is initiated by the occurrence of an event that matches a calculated condition, the calculated condition being calculated based at least in part on the model, or the data indicative of the glucose concentration value, or a combination thereof.

65. 65. The method of claim 64, wherein if a therapy adjustment exposes the user to more risk than existed prior to the therapy adjustment, warnings and / or alarms are adjusted to have additional sensitivity for a period of time after the therapy adjustment.

66. 65. The method of claim 64, further comprising: detecting when a period of time exists following a potential treatment decision that triggers more frequent instantiation of a CGM app than before the potential treatment decision; and increasing a frequency of decision support messaging.

67. 67. The method of claim 66, wherein the messaging is to the user or a follower of the user.

68. 57. The method of claim 56, further comprising using the received data to detect the occurrence of a trend associated with a recognized pattern.

69. 57. The method of claim 56, further comprising receiving data from an external data source.

70. 70. The method of claim 69, wherein the external data source is an insulin pen or pump and the calculated insights include information regarding insulin onboard.

71. 71. The method of claim 70, wherein the external data source is an insulin pen or pump and the calculated insight is 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.

72. 71. The method of claim 70, wherein the external data source is an accelerometer and the calculated insights include information regarding the effect of exercise on glucose concentration values.

73. 71. The method of claim 70, wherein 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.

74. 71. The method of claim 70, wherein the external data source is a user interface, the user interface configured to receive data regarding a user's goals, and the calculated insights include a percentage of time within a goal range and an indication of the goal range.

75. 57. The method of claim 56, further comprising loading into a memory of a computing environment a measurement model of a continuous glucose concentration monitoring system associated with the user, wherein the calculated insight is further based on the measurement model.

76. 76. The method of claim 75, 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.

77. 57. The method of claim 56, wherein the causing is based on a calculation that is performed periodically.

78. 78. The method of claim 77, wherein the period is determined based on a series of meal times that occur substantially simultaneously.

79. 78. The method of claim 77, wherein the cycle is determined based on a series of similar glycemic responses.

80. 80. The method of claim 79, wherein the similar glycemic response is a spike.

81. 78. The method of claim 77, wherein the cycle is determined based on a series of similar dosing strategies.

82. 78. The method of claim 77, wherein the period is determined 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.

83. 57. The method of claim 56, wherein the display of the calculated insight comprises a display of a probability cone based on prior data of the user.

84. 57. The method of claim 56, wherein the display of the calculated insight comprises a display of a probability cone based on population data.

85. 85. The method of claim 84, wherein the population data is drawn from people who have one or more demographic characteristics in common with the user.

86. 57. The method of claim 56, wherein the display of the calculated insight includes displaying two separate trend indicators, one determined using data measured during weekdays and the other determined using data measured over weekends.

87. 57. The method of claim 56, wherein the insight is calculated by the computing environment.

88. 57. The method of claim 56, wherein the insight is calculated by a connected server.

89. 57. The method of claim 56, wherein the models include a physiological model and a behavioral model.

90. 90. The method of claim 89, wherein the behavioral model is configured to determine a level of concern, the level of concern being selected from the group consisting of concerns regarding a physiological condition, consequences of a treatment decision, and / or a potential future condition.

91. 91. The method of claim 90, wherein concern regarding the physiological condition is determined by detecting the frequency with which a diabetes related application is checked or by detecting the frequency with which SMBG values ​​are entered.

92. 91. The method of claim 90, wherein the behavioral model is configured to determine a level of an engagement factor, the level of engagement factor being selected from the group consisting of reaction time, level of therapeutic activity, and / or type of support.

93. 91. The method of claim 90, wherein the computing environment is a mobile device, the method further comprising learning the physiological model by a second computer system, and wherein loading the model into a memory of the computing environment includes loading the learned physiological model into the mobile device.

94. 94. The method of claim 93, further comprising learning a behavioral model by a second computer system, and wherein loading the model into a memory of a computing environment includes loading the learned behavioral model into the mobile device.

95. 94. The method of claim 93, wherein the mobile device determines the calculated insight without requiring access to the second computer system.

96. 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; a memory circuit containing the stored model; 1. A processor comprising: receiving host glucose concentration data sensed by the glucose concentration sensor; determining a host condition change associated with the host glucose concentration data; determining a guidance message based at least in part on the host status change; and a processor configured to deliver the guidance message via a user interface.

97. 97. The system of claim 96, wherein the processor is further configured to determine that the host state change is atypical, and wherein the determining of the guidance message is based at least in part on the atypicality of the state change.

98. 97. The system of claim 96, wherein determining the host state change comprises determining from a model that a low probability state transition has occurred or is likely to occur, and wherein determining the guidance message is based at least in part on the determination that the low probability state transition has occurred or is likely to occur.

99. 97. The system of claim 96, wherein determining the host state change comprises identifying a likely transition to 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 transition to the undesirable host state.

100. 97. The system of claim 96, wherein the system includes a mobile device, the mobile device including the memory circuit and the processor.

101. 101. The system of claim 100, wherein the mobile device includes the communications circuitry and the glucose concentration sensor includes a glucose concentration sensor communications circuitry configured to communicate with the communications circuitry.

102. 102. The system of claim 101, wherein the mobile device communication circuitry includes a first wireless transceiver, the glucose concentration sensor communication circuitry includes a second wireless transceiver, and the mobile device communication circuitry and the glucose concentration sensor communication circuitry communicate using a wireless communication protocol.

103. 97. The system of claim 96, further comprising an insulin delivery system.

104. 97. The system of claim 96, wherein the status change is from a first disease state describing a first host disease stage to a second disease state indicating 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.

105. 1. A method for delivering physiological glucose concentration management guidance, comprising: receiving data indicative of a glucose concentration; determining a patient status by applying the data to a model; and determining whether the patient condition is atypical; and determining a guidance message based on the atypicality of the patient condition; and delivering the guidance message via a user interface.

106. 106. The method of claim 105, wherein determining whether the patient condition is atypical comprises determining whether the patient condition is atypical for a given set of conditions.

107. 106. The method of claim 105, wherein determining whether the patient condition is atypical comprises determining whether a low likelihood state transition has occurred.

108. 106. The method of claim 105, wherein determining a guidance message comprises determining whether a low likelihood state transition is predicted to occur.

109. 106. The method of claim 105, wherein determining a patient state comprises determining a physiological state and a behavioral state, and determining whether the physiological state is atypical for the determined behavioral state.

110. The method of claim 105, wherein determining whether the patient condition is atypical comprises identifying blood glucose concentration levels that deviate from a controlled blood glucose concentration range over time or in a situation when the blood glucose concentration is normally within the controlled range.

111. 106. The method of claim 105, wherein determining whether the patient condition is atypical comprises identifying blood glucose concentration trends that, depending on the time or circumstance, lead to high or low blood glucose concentration conditions when blood glucose concentrations are normally within a controlled range.

112. The method of claim 105, wherein determining whether the patient condition is atypical comprises predicting a shift to a low blood glucose concentration condition at one time or in some cases when blood glucose concentrations are normally well controlled.

113. 1. A method for delivering physiological glucose concentration management guidance, comprising: receiving data indicative of a glucose concentration; determining a patient status by applying the data to a model; and 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 the low probability state transition has occurred or is likely to occur.

114. 114. The method of claim 113, wherein the method includes determining that a low probability state transition is likely to occur, and wherein the guidance message provides advance notice of the low probability state transition.

115. 114. The method of claim 113, wherein the low probability physiological state transition comprises a transition to a low glucose concentration level or a high glucose concentration level.

116. 114. The method of claim 113, wherein determining a guidance message comprises determining that the low probability state transition is likely to occur at an inconvenient time.

117. 117. The method of claim 116, wherein determining that the low probability state transition is likely to occur at an inconvenient time includes reference to a user calendar of scheduled events.

118. 117. The method of claim 116, wherein determining that the low probability state transition is likely to occur at an inconvenient time includes reference to a behavioral state model.

119. The method of claim 113, wherein delivering the guidance message comprises determining a period of time during which the patient or caregiver is likely to take action to prevent the low probability state transition, and delivering the guidance message during the determined period of time.

120. 120. The method of claim 119, wherein determining a period during which the patient is likely to take action to prevent the low probability state transition comprises consulting a calendar of scheduled events.

121. 120. The method of claim 119, wherein determining a time period during which the patient or caregiver is likely to take action to prevent the low probability state transition comprises using the model.

122. 121. The method of claim 120, wherein using the model comprises using patterns of user activity or user location information to determine periods during which the patient or caregiver is likely to be available.

123. 1. A method for delivering physiological glucose concentration management guidance, comprising: receiving data indicative of a glucose concentration; Receiving one or more behavioral, environmental, or contextual inputs; identifying likelihood of transitions to undesirable patient states by applying the data and the one or more behavioral, environmental, or contextual inputs to a model; determining a guidance message based on the likelihood of the transition to an undesirable patient state; delivering the guidance message, the guidance message being determined and delivered when the patient is able to intervene to avoid the transition to an undesirable patient state.

124. 124. The method of claim 123, wherein receiving behavioral, environmental, or contextual input comprises receiving accelerometer data.

125. 124. The method of claim 123, wherein receiving behavioral, environmental, or contextual input comprises receiving information about a scheduled event from a calendar.

126. 124. The method of claim 123, wherein receiving behavioral, environmental, or contextual input comprises receiving input from a user via a user interface.

127. 124. The method of claim 123, wherein receiving behavioral, environmental, or contextual input comprises receiving information from a user regarding completion, initiation, or anticipation of an exercise.

128. 124. The method of claim 123, wherein receiving the behavioral, environmental, or contextual input includes detecting that the user is driving.

129. 124. The method of claim 123, wherein receiving one or more behavioral, environmental, or contextual inputs includes receiving location information.

130. 124. The method of claim 123, wherein receiving one or more behavioral, environmental, or contextual inputs includes receiving an ambient temperature or an ambient pressure.

131. 124. The method of claim 123, further comprising receiving a body temperature, a heart rate, or a respiratory rate.

132. 124. The method of claim 123, further comprising training the model based on one or more patterns in received information.

133. 133. The method of claim 132, wherein training the model comprises learning a pattern of insulin sensitivity as a function of time.

134. 134. The method of claim 133, wherein training the model comprises learning a pattern of insulin sensitivity as a function of time elapsed after a period of physical exercise.

135. 124. The method of claim 123, further comprising determining a user query and providing the user query to a user, wherein the behavioral, environmental, or contextual input is received in response to the user query.

136. 124. The method of claim 123, wherein receiving data indicative of the glucose concentration includes receiving data from a continuous glucose concentration monitoring system.

137. 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; a memory circuit containing the stored model; 1. A processor comprising: Access data associated with the host, Using said data to determine a state of said host; determining a guidance message based at least in part on the determined condition; Selecting a time for providing the guidance message; and a processor configured to provide the guidance message via a user interface at the selected time.

138. 138. The system of claim 137, wherein the time is calculated to allow for intervention before the host transitions into an undesirable physiological state.

139. The system of claim 137, wherein determining the guidance message is 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 their diabetes care.

140. 138. The system of claim 137, wherein determining the state is based at least in part on a patient physiological model and a patient behavioral model.

141. 1. A method for 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 using at least in part a model and the first real-time data; determining a personalized guidance message, the guidance message being based at least in part on the determined condition; and providing the determined personalized guidance message via a user interface at a time calculated to allow intervention prior to a transition to an undesirable physiological state.

142. 142. The method of claim 141, wherein determining a guidance message is further based on a timing of determining the guidance message or a time associated with the determined condition.

143. 142. The method of claim 141, wherein the model includes states indicative of the patient's convenience or availability to participate in an intervention.

144. 142. The method of claim 141, wherein the guidance message is based at least in part on a predicted transition to the undesirable physiological state.

145. 145. The method of claim 144, wherein the guidance message is based at least in part on a determination that a predicted transition from a current state to a predicted state is a low probability transition.

146. 142. The method of claim 141, wherein the model includes a physiological model of the patient, and determining the state of the patient is based on applying at least the first real-time data to the physiological model of the patient.

147. 147. The method of claim 146, wherein the model further comprises a behavioral model.

148. The method of claim 147, wherein the behavioral model is based on machine learning characteristics of the patient, the machine learning characteristics being based on behavioral or contextual patterns.

149. 148. The method of claim 147, wherein the behavioral model is based on a set of one or more steps determined to be likely to be performed by the patient.

150. 148. The method of claim 147, wherein the behavioral model is based on a set of one or more objectives determined to be likely achievable by the patient.

151. 148. The method of claim 147, wherein the behavioral model is a pattern.

152. 148. The method of claim 147, wherein the patient's physiological model is based on physiological patterns and the behavioral model is based on behavioral patterns.

153. 153. The method of claim 152, wherein the first real-time data indicates a deviation from an expected behavioral pattern.

154. 154. The method of claim 153, wherein the behavioral model indicates a tendency to overcorrect meals associated with mealtimes, the first real-time data indicates that a mealtime is imminent, and the guidance message corresponds to a decrease in overcorrection of the mealtimes.

155. 154. The method of claim 153, wherein the behavioral patterns include long-term behavioral patterns based on long-term patterns of behavior and short-term behavioral patterns related to current behavior.

156. 156. The method of claim 155, wherein the behavioral model is based on the long-term behavioral patterns and further based on the short-term behavioral patterns.

157. 157. The method of claim 156, 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 concentrations, calendar data, and combinations thereof.

158. 148. The method of claim 147, wherein determining the state is further based on a measurement model.

159. 159. The method of claim 158, wherein the measurement model is based on a continuous glucose concentration monitoring system associated with the patient.

160. 160. The method of claim 159, further comprising measuring glucose concentration data after determining a guidance message, and using the measured subsequent data to improve one or more of the models.

161. 161. The method of claim 160, wherein the glucose concentration data measured subsequent to the determination is fed back into a measurement model or the behavioral model or the patient's physiological model, or a combination thereof.

162. 142. The method of claim 141, wherein the model comprises a pattern selected from the group consisting of a physiological pattern, a contextual pattern, a behavioral pattern, or a combination thereof.

163. 163. The method of claim 162, wherein the physiological pattern is based on a physiological model.

164. 142. The method of claim 141, wherein the model is based on a combination of patterns selected from the group consisting of physiological patterns, contextual patterns, or behavioral patterns.

165. 142. The method of claim 141, wherein the determining the guidance message further comprises determining a plurality of guidance messages based on the condition and the first real-time data, and selecting one of the determined plurality of guidance messages further based on the condition and the first real-time data.

166. 166. The method of claim 165, 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.

167. The method of claim 141, further comprising determining a predicted diabetic response of the patient based on the condition and the first real-time data, wherein the 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.

168. The method of claim 167, wherein the 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.

169. 169. The method of claim 168, wherein the guidance message is based on a functional relationship between the predicted diabetic response and a desired diabetic response.

170. 170. The method of claim 169, wherein the functional relationship is the difference between the glucose concentration level associated with the predicted diabetic response and the glucose concentration level associated with the desired diabetic response.

171. The method of claim 170, wherein the glucose concentration level associated with the desired diabetic response is a target glucose concentration level or a target glucose concentration range.

172. 170. The method of claim 169, wherein the functional relationship is based on whether the predicted diabetic response meets predetermined conditions associated with the desired diabetic response.

173. 173. The method of claim 172, wherein the predetermined condition is 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.

174. 170. The method of claim 169, wherein the guidance message further includes one or more reasons related to the functional relationship, whereby the patient can be informed as to why the guidance message is being provided.

175. 142. The method of claim 141, wherein the guidance message includes an actionable prompt.

176. 176. The method of claim 175, wherein the guidance message includes an executable prompt calculated to move the patient's glucose concentration level toward a target level or range.

177. 142. The method of claim 141, wherein the guidance message includes an affirmation of a current action associated with the patient.

178. 142. The method of claim 141, wherein the first real-time data is measured, received, or determined by a smartphone.

179. 142. The method of claim 141, wherein the first real-time data is measured, received, or determined by a wearable device.

180. 142. The method of claim 141, wherein the first real-time data is measured, received, or determined by a wearable device in combination with a smartphone.

181. 142. The method of claim 141, wherein the first real-time data is measured, received, or determined by an external device.

182. 182. The method of claim 181, wherein the external device is an accelerometer.

183. 142. The method of claim 141, wherein 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.

184. 142. The method of claim 141, wherein the first real-time data is a change in state.

185. 185. The method of claim 184, wherein the change in state is detected by a clock, an accelerometer, or a GPS circuit.

186. 142. The method of claim 141, wherein the first real-time data is a user request for a decision support prompt.

187. 142. The method of claim 141, wherein the first real-time data is received from a continuous glucose concentration monitoring system.

188. 142. The method of claim 141, further comprising measuring, determining, or receiving second real-time data, the second real-time data being used in determining the condition of the patient.

189. 142. The method of claim 141, wherein providing the determined personalized guidance message occurs when calculated to be helpful in managing the patient's glucose concentration level.

190. 142. The method of claim 141, wherein the condition is a disease state describing the stage of the patient.

191. moreover, measuring, determining, or receiving second real-time data indicative of a second glucose concentration level; determining a second disease state describing at least in part a second patient stage by applying the second data to the model; and determining a second guidance message based at least in part on the second disease condition.

192. the condition is an engagement condition, and determining a messaging frequency based at least in part on the engagement state; and determining a time to provide the personalized guidance message based at least in part on the messaging frequency.

193. 142. The method of claim 141, further comprising receiving, during a training period, training data and determining the condition of the patient based at least in part on the training data.

194. 1. A method for determining and delivering personalized, useful, calculated guidance messages to a patient in the management of diabetes care, comprising: learning a personalized behavioral model of the patient; Receiving real-time data; and determining a personalized guidance message to be provided to the patient, the determination being based at least in part on a time of the determination of the personalized guidance message and the personalized behavioral model of the patient; 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.

195. 202. The method of claim 194, wherein learning a personalized behavioral model of a patient includes machine learning a first characteristic of the patient.

196. 200. The method of claim 195, wherein 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.

197. 200. The method of claim 194, further comprising delivering the personalized guidance message at the delivery time.

198. 1. A method for determining and providing a personalized and useful calculated guidance message to a patient in the management of diabetes care, comprising: measuring, determining, or receiving first real-time data associated with the patient; determining a state of the patient based on a physiological model, a behavioral model, and a measurement model of the patient using models, the state being determined by the physiological model and the behavioral model of the patient and the real-time data; determining a guidance message, the guidance message being personalized to the patient based at least on the determined condition, whereby the determined condition and use of a plurality of models enable personalization of the guidance message; providing the determined personalized guidance message via a user interface, such that the providing occurs when calculated to be useful to the therapeutic management of the patient's diabetes.

199. 200. The method of claim 198, wherein the first real-time data received is a glucose concentration value.

200. 200. The method of claim 198, wherein receiving the first real-time data is a time of day.

201. 200. The method of claim 198, wherein 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 motion state.

202. 200. The method of claim 198, further comprising learning the model from the set of input data.

203. 203. The method of claim 202, wherein 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.

204. 203. The method of claim 202, further comprising determining a deviation from an expected state after delivering the personalized guidance message, and adapting the model based on additional input information.

205. 203. The method of claim 202, wherein the set of input data includes information received via a user interface.

206. 200. The method of claim 198, wherein providing the determined personalized guidance message includes providing the personalized guidance message in a user interface.

Images