Decision support systems and methods

Abstract

A system and method are provided to provide users with guidance on managing physiological conditions such as diabetes. [Solution] The decision can be based on the patient's glucose concentration level. The glucose concentration level can be provided to a stored model to determine the state. Guidance can be determined at least partially based on the determined state.

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 diet 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 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 present, blood sugar levels can rise above the normal range. A condition where blood sugar is higher than normal is called "hyperglycemia." Chronic hyperglycemia can cause many health problems, such as cardiovascular disease, eye problems like cataracts, nerve damage (neuropathy), and kidney damage. Hyperglycemia can also cause acute problems such as diabetic ketoacidosis - a condition where the body becomes overly acidic due to the presence of blood glucose and ketones produced when the body cannot use glucose. A condition where blood sugar is lower than normal is called "hypoglycemia." Severe hypoglycemia can cause an acute episode and may lead to seizures and death.

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

[0006] Diabetes is sometimes referred to as "Type 1" or "Type 2." In Type 1 diabetes, individuals can usually use insulin when it is present, but due to problems with the insulin-producing beta cells in the pancreas, the body cannot produce enough insulin. In Type 2 diabetes, individuals can produce insulin, but their sensitivity to insulin is reduced, resulting in "insulin resistance." Consequently, even when insulin is present in the body, it is not used effectively by the patient's body to regulate blood glucose levels.

[0007] This background technology is provided to introduce a concise context for the following outline of the invention and for embodiments for carrying out the invention. This background technology is not intended to assist in determining the scope of the subject matter described in the claims, nor is it intended to limit the subject matter described in the claims to any implementation that solves any or all of the above disadvantages or problems. [Overview of the project] [Means for solving the problem]

[0008] This document specifically describes the systems and methods for determining the timing of the delivery or decision-making process for patient or caregiver decision support guidance.

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

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

[0011] In Example 3, the subject matter of Example 1 or Example 2 can be configured such that the model includes a state that demonstrates 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 structured such that the guidance message is at least partially based on the expected transition to an undesirable physiological state.

[0013] In Example 5, the subject of any one or any combination of Examples 1-4 can be structured such that the guidance message is at least partially based on the decision that the expected transition from the current state to the expected 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 patient physiological model and determining the patient's state is based at least on applying first real-time data to the patient physiological model.

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

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

[0017] In Example 9, any one or any combination of the themes from Examples 1-8 can be configured such that the behavioral model is based on a set of one or more steps that are 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 behavioral model is based on a set of one or more objectives that have been determined to be likely achievable by the patient.

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

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

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

[0022] In Example 14, any one or any combination of themes from Examples 1-13 may be configured such that the behavioral model tends to overcorrect for meals related to mealtime, the first real-time data indicates that mealtime is imminent, and the guidance message responds to undercorrecting for mealtime.

[0023] In Example 15, the subject matter of any one or any combination of Examples 1-14 can be configured such that the model includes 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 using the measured subsequent data to improve one or more models. <000009​​​​​In Example 22, any one or any combination of themes from Examples 1-21 can be configured such that the model includes patterns selected from a group consisting of physiological patterns, contextual patterns, behavioral patterns, or combinations thereof.

[0031] In Example 23, any one or any combination of the themes from Examples 1-22 can be configured such that the physiological patterns are based on a physiological model.

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

[0033] In Example 25, any one or any combination of the themes from Examples 1-24 can be configured such that determining a guidance message includes determining multiple guidance messages based on the state and first real-time data, and selecting one of the multiple guidance messages further determined based on the state and first real-time data.

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

[0035] In Example 27, any one or any combination of the themes from Examples 1-26 may further include determining the patient's expected diabetic response based on their condition and first real-time data, and the guidance messages may be personalized to the patient based further on the expected diabetic response, and the patient may be provided with actionable messages calculated to move the expected diabetic response toward a desired diabetic response.

[0036] In Example 28, Subject Example 27 can be configured such that the desired diabetic response is related to the state and first real-time data, and the desired diabetic response is selected from the group consisting of an improved diabetic response, a potentially improved diabetic response, an ideal response, or an optimized response.

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

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

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

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

[0041] In Example 33, the subject of Example 32 can be configured such that the given conditions are 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, any one or any combination of the themes from Examples 1–33 can be configured such that the guidance message further includes one or more reasons related to the functional relationship, thereby informing the patient of the reason why the guidance message is being provided.

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

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

[0045] In Example 37, the subject of any one or any combination of Examples 1-36 can be structured so that the guidance message includes an affirmation of the patient's current behavior.

[0046] In Example 38, any one or any combination of the subjects from 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, any one or any combination of the subjects from 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, any one or any combination of the subjects from 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, any one or any combination of the subjects from 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 of Example 41 can be configured such that the external device is an accelerometer.

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

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

[0053] In Example 45, any one or any combination of the subjects from Examples 1-44 can be configured such that changes in state are detected by a clock, accelerometer, or GPS circuit.

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

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

[0056] In Example 48, any one or any combination of the subjects from Examples 1-47 may further include measuring, determining, or receiving second real-time data, which is used in determining the patient's condition.

[0057] In Example 49, the subject of any one or any combination of Examples 1-48 may be configured to trigger when a determined personalized guidance message is calculated to be useful in 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 at least in part based on the determined state.

[0059] In Example 51, the subject of Example 50 is further configured such that the processor also determines the guidance message, at least in part, based on a temporal pattern, if necessary.

[0060] In Example 52, any one or more of the subjects from Examples 50-51 include, as necessary, a model that includes a physiological model and a model that determines a state that determines a physiological state.

[0061] In Example 53, the subject of Example 52 is further configured, if necessary, to determine an action state and to determine a guidance message based at least in part on the action state.

[0062] In Example 54, any one or more subjects from Examples 50–53 are configured, if necessary, to further provide treatment recommendations based at least partially on the determined condition.

[0063] In Example 55, any one or more of the subjects from Examples 50-54 are included, if necessary, in that the system includes a mobile device, and the mobile device includes a memory circuit and a processor.

[0064] In Example 56, the subject of Example 55 is further expanded to include, if necessary, a mobile device including a communication circuit and a glucose concentration sensor including a glucose concentration sensor communication circuit configured to communicate with the communication circuit.

[0065] In Example 57, the subject of Example 56 is extended as necessary, including the mobile device communication circuit including a first wireless transceiver, the glucose concentration sensor communication circuit including a second wireless 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 subjects in Examples 55–57 include, if necessary, a user interface configured for the mobile device to provide guidance messages.

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

[0068] In Example 60, any one or more subjects from Examples 55–59 include an insulin delivery system, if necessary.

[0069] In Example 61, the subject of Example 60 is extended to include, if necessary, an insulin delivery system that includes an insulin pump.

[0070] In Example 62, any one or more subjects from Examples 60–61 include, as necessary, an insulin delivery system comprising an insulin pen.

[0071] In Example 63, any one or more subjects from Examples 50–62 include a user interface configured to provide guidance messages to the patient, as needed.

[0072] Example 64 is a method for delivering physiological glucose concentration management guidance, comprising receiving data indicating glucose concentration levels, determining a state by applying the data to a model, and determining a guidance message based at least partially on the state and temporal patterns.

[0073] In Example 65, the subject of Example 64 is extended to include, where necessary, the temporal patterns, which include the patient's learned patterns of behavior.

[0074] In Example 66, any one or more themes from Examples 64-65 include, as necessary, a time pattern that includes a calendar.

[0075] In Example 67, the subject of Example 66 includes, where necessary, determining guidance messages based at least in part on incoming events in the calendar.

[0076] In Example 68, the subject of Example 67 includes, where necessary, determining the guidance message based at least in part on the expected change in insulin sensitivity calculated at least in part on the occurrence of events in the calendar.

[0077] In Example 69, any one or more subjects from Examples 64–68 include, as necessary, a model that includes a physiological model, determining a state that includes determining a physiological state, and determining a guidance message that includes determining from temporal and physiological patterns that indicate a high probability of a transition to an undesirable physiological state occurring.

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

[0079] In Example 71, any one or more of the themes from Examples 64–70 include, if necessary, determining the delivery time for delivering guidance messages using a temporal pattern.

[0080] In Example 72, the subject of Example 71 includes, if necessary, determining the delivery time, which involves selecting a delivery time when the host is likely to be available based at least partially on a temporal pattern.

[0081] In Example 73, any one or more subjects from Examples 71–72 include, as necessary, determining the delivery time, which involves identifying the period of time when the patient will be unavailable and selecting a time to deliver the guidance message before the period of patient unavailability.

[0082] In Example 74, any one or more subjects from Examples 64–73 include, as necessary, determining a guidance message which includes identifying a period of patient unavailability based at least in part on a temporal pattern, and the guidance message which is calculated to promote glucose concentration stability during the unavailability period.

[0083] In Example 75, any one or more subjects from Examples 64–74 include, as necessary, determining an engagement status, determining messaging frequency based at least in part on the engagement status, and determining the time for delivering guidance messages based at least in part on the messaging frequency.

[0084] In Example 76, the subject of Example 75 includes, if necessary, 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.

[0085] In Example 77, any one or more subjects from Examples 64–76 include, as necessary, a disease state in which the condition describes a host stage.

[0086] In Example 78, the subject of Example 77 includes, if 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 the model, and determining a second guidance message at least partially based on the second disease state.

[0087] In Example 79, any one or more of the subjects in Examples 64–78 include, as necessary, determining a state which is a physiological state.

[0088] In Example 80, the subject of Example 79 includes, if necessary, determining the physiological state, which includes determining the insulin state, the energy absorption state, and the energy expenditure state.

[0089] In Example 81, any one or more subjects from Examples 64-80 include, as necessary, receiving behavioral inputs and determining a state, which includes applying both data and behavioral inputs to a model.

[0090] In Example 82, the subject of Example 81 includes, if necessary, receiving behavioral inputs, which includes receiving patient activity information.

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

[0092] In Example 84, the subject of Example 83 includes determining the timing for delivering guidance that enables timely interventions affecting glucose concentration, if necessary.

[0093] In Example 85, any one or more of the subjects in Examples 83–84 include determining the level of interest in the guidance, at least partially based on behavioral and physiological states, as necessary.

[0094] In Example 86, the subject matter of Example 85 includes determining the level of concern in treatment guidance, where necessary, based at least in part on user requests from previous guidance.

[0095] In Example 87, any one or more of the themes from Examples 83–86 include, as necessary, determining a behavioral state, which involves 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 from Examples 83–87 include, if necessary, determining the behavioral state, which involves checking the user calendar for scheduled events.

[0097] In Example 89, any one or more of the subjects in Examples 83–88 include, as necessary, determining a physiological state by applying data to a physiological state model.

[0098] In Example 90, the subject matter of Example 89 includes, if necessary, the physiological state model including glucose concentration levels.

[0099] In Example 91, the subject of Example 90 is further expanded to include, if necessary, one or more of the following physiological state models: insulin state, energy absorption state, and energy expenditure state.

[0100] In Example 92, any one or more of the subjects from Examples 83–91 include, as necessary, determining the measurement conditions, which include the precision or accuracy of the data indicating glucose concentration.

[0101] In Example 93, any one or more subjects from Examples 83–92 include, as necessary, determining a guidance message to determine that a low-probability physiological state transition is likely to occur, and the guidance message provides advance notice of the low-probability physiological state transition.

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

[0103] In Example 95, any one or more subjects from Examples 93–94 include, as necessary, determining a guidance message that is likely to occur when a low-probability physiological state transition is inconvenient, and that the guidance message provides advance warning of the expected low-probability physiological state transition so that intervention to avoid the low-probability physiological state transition can be made.

[0104] In Example 96, the subject of Example 95 includes, if necessary, determining that low-probability physiological state transitions are likely to occur when inconvenient, by applying behavioral inputs to a behavioral state model.

[0105] In Example 97, any one or more subjects from Examples 83–96 are included, if necessary, in receiving additional physiological parameters, and the physiological state is determined using both the data and the additional physiological parameters.

[0106] In Example 98, the subject of Example 97 is expanded to include additional physiological parameters, such as body temperature, heart rate, or respiratory rate, as needed.

[0107] In Example 99, any one or more subjects from Examples 83–98 optionally receive training data during the training period that describes at least one of a physiological or behavioral state, and at least one of the physiological or behavioral states is determined after the training period using the training data.

[0108] Example 100 is a method for determining and providing personalized, useful, computed guidance messages to a patient for the management of diabetes, comprising receiving patient-related data, including real-time glucose concentration levels; determining the patient's state by applying the data to a state model; and providing treatment recommendations based at least partially on the determined state.

[0109] In Example 101, the subject of Example 100 includes, as necessary, patient status including insulin onboard status, insulin sensitivity status, and food consumption status.

[0110] In Example 102, any one or more themes from Examples 100-101 include, as necessary, that the state model is a stochastic state model.

[0111] In Example 103, the subject of Example 102 is extended to include, if necessary, state transition probabilities learned from retrospective data.

[0112] In Example 104, any one or more subjects from Examples 100–103 include, if necessary, refining the state model using data received after the delivery of treatment recommendations.

[0113] Example 105 is a method for providing a user with decision support functionality, 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 the 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] Example 106 includes the fact that the subject of Example 105 is displayed as needed, initiated by a user request.

[0115] In Example 107, the subject matter of Example 106 is, if necessary, associated with user requests for data inputs of planned activities, and the computed insights represent user behavior calculated by one or more models, leading to desired outcomes associated with glucose concentration values.

[0116] In Example 108, the subject of Example 107 is, if necessary, included, that the desired result is a glucose concentration value within a predetermined target range.

[0117] In Example 109, any one or more of the themes from Examples 107-108 optionally include the desired result being a glucose concentration value having a rate of change within a predetermined target range.

[0118] In Example 110, any one or more subjects from Examples 107–109 include, as necessary, that the planned activity is a meal and the calculated insight is the calculated or predicted effect of the meal on glucose concentration values.

[0119] In Example 111, any one or more subjects from Examples 107–110 include, where applicable, that the calculated insights displayed include at least one factor used for interactive recommendations and decisions regarding interactive recommendations.

[0120] In Example 112, any one or more subjects from Examples 105-111 include, if necessary, the display of calculated insights being initiated by the occurrence of an event that matches a predetermined condition.

[0121] In Example 113, any one or more subjects from Examples 105–112 may, if necessary, display a calculated insight, which is triggered by the occurrence of an event that matches a calculated condition, and the calculated condition is calculated at least in part on a model, or data showing glucose concentration values, or a combination thereof.

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

[0123] In Example 115, any one or more of the themes from Examples 113–114 may include, as needed, detecting if there is a period following the potential treatment decision that triggers more frequent CGM app instantiation than before the potential treatment decision, and increasing the frequency of decision support messaging.

[0124] In Example 116, any one or more of the themes from Examples 113–115 include, as necessary, that the messaging is directed to the user or the user's followers.

[0125] In Example 117, any one or more of the themes from Examples 105–116 are, if necessary, used to detect the occurrence of trends associated with the recognized patterns using the received data.

[0126] In Example 118, any one or more of the themes from Examples 105–117 include receiving data from an external data source, as necessary.

[0127] In Example 119, the subject matter of Example 118 is expanded to include, if necessary, an external data source being an insulin pen or pump, and the calculated insights including information about insulin onboarding.

[0128] In Example 120, the subject of Example 119 is, if necessary, an external data source which is an insulin pen or pump, and the calculated insight is 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 subjects from Examples 119–120 include, as necessary, that the external data source is an accelerometer and the calculated insights include information about the effect of exercise on glucose concentration values.

[0130] In Example 122, any one or more subjects from Examples 119–121 include, as necessary, an external data source being a camera or GPS receiver, and the calculated insights including information on the effect of meal size and composition on glucose concentration values.

[0131] In Example 123, any one or more subjects from Examples 119–122 include, as necessary, an external data source being a user interface, the user interface being configured to receive data about the user's goals, and the calculated insights including a percentage of time within the goal range and a display of the goal range.

[0132] In Example 124, any one or more subjects from Examples 105–123 are, if necessary, loaded into the memory of the computing environment a measurement model of a continuous glucose concentration monitoring system associated with the user, and the calculated insights are further based on the measurement model.

[0133] In Example 125, the subject matter of Example 124 is, if necessary, calculated using an algorithm that is at least partially based on glucose concentration variability or the likelihood and / or severity of glucose concentration variability.

[0134] In Example 126, any one or more of the themes from Examples 105–125 are, if necessary, based on calculations that are performed periodically.

[0135] In Example 127, the subject of Example 126 is extended to include determining the cycle based on a series of meal times that occur substantially simultaneously, if necessary.

[0136] In Example 128, any one or more subjects from Examples 126–127 are, if necessary, determined to have a cycle based on a series of similar blood glucose responses.

[0137] In Example 129, the subject matter of Example 128 includes, where necessary, that a similar blood glucose response is a spike.

[0138] In Example 130, any one or more subjects from Examples 126–129 include having their cycles determined based on a series of similar medication strategies, as necessary.

[0139] In Example 131, any one or more subjects from Examples 126–130 include, as necessary, a cycle being determined based on a series of unreliable results in which glucose concentration levels drift over a specified percentage or amount away from the target zone following a potential treatment decision.

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

[0141] In Example 133, any one or more themes from Examples 105–132 include, as necessary, a representation of the calculated insights that includes a representation of a probability cone based on collective data.

[0142] In Example 134, the subject of Example 133 includes, if necessary, the extraction of group data from individuals who share one or more demographic characteristics with the user.

[0143] In Example 135, any one or more subjects from Examples 105–134 include, as necessary, a display of the calculated insights that includes a display of two distinct trend indicators, one determined using data measured on weekdays and the other using data measured on weekends.

[0144] In Example 136, any one or more of the themes from Examples 105–135 include, if necessary, the calculation of insights by a computing environment.

[0145] In Example 137, any one or more subjects from Examples 105–136 include, if necessary, the calculation of insights by a connected server.

[0146] In Example 138, any one or more subjects from Examples 105–137 include, as necessary, models that include physiological and behavioral models.

[0147] In Example 139, the subject of Example 138 is configured, if necessary, to determine the level of concern, the level of concern being selected from a group consisting of concerns about physiological conditions, consequences of treatment decisions, and / or potential future conditions.

[0148] In Example 140, the subject of Example 139 is determined by detecting, as necessary, the frequency with which diabetes-related applications are checked or by detecting the frequency with which SMBG values ​​are entered.

[0149] In Example 141, any one or more subjects from Examples 139–140 are configured, as necessary, to have a behavioral model that determines the level of an involved factor, the level of the involved factor being selected from a group consisting of reaction time, level of therapeutic activity, and / or type of support.

[0150] In Example 142, any one or more subjects from Examples 139–141 are, as may be, a computing environment which is a mobile device, and the method further comprises loading the learned physiological model into the memory of the computing environment which is loaded into the mobile device which is loaded into the mobile device which is further comprising learning the physiological model by a second computer system which is loaded into the memory of the computing environment.

[0151] In Example 143, the subject of Example 142 is further expanded to include, if necessary, training a behavioral model by a second computer system, loading the model into the memory of the computing environment, and loading the trained behavioral model into a mobile device.

[0152] In Example 144, any one or more of the themes from Examples 142–143 include, if necessary, a mobile device determining computed insights without requiring access to a second computer system.

[0153] Example 145 is a system comprising: a glucose concentration sensor configured to detect host glucose concentration; a communication circuit configured to receive 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 host state changes associated with the host glucose concentration data, determine a guidance message based at least partially on the host state changes, and deliver the guidance message via a user interface.

[0154] In Example 146, the subject of Example 145 is further configured, if necessary, to determine that the host state change is atypical, and that determining the guidance message is at least partially based on the atypical nature of the state change.

[0155] In Example 147, any one or more themes from Examples 145–146 include, as necessary, determining a host state change by determining from a model that a low-probability state transition has occurred or is likely to occur, and determining a guidance message by at least partially relying 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 from Examples 145–147 includes, as necessary, determining a host state change, identifying likely transitions to undesirable host states, and determining and delivering guidance messages at once so that the host can intervene to avoid transitions to undesirable host states.

[0157] In Example 149, any one or more subjects from Examples 145–148 include, as necessary, a system including a mobile device, the mobile device including a memory circuit and a processor.

[0158] In Example 150, the subject of Example 149 is further expanded to include, optionally, a mobile device including a communication circuit and a 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 subjects from Examples 149–150 include, as necessary, a mobile device communication circuit including a first wireless transceiver, a glucose concentration sensor communication circuit including a second wireless 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 subjects from Examples 145–151 include an insulin delivery system, if necessary.

[0161] Example 153 includes the fact that any one or more subjects from Examples 145–152 are, as may be, a second disease state indicating a second host disease state from a first disease state describing a first host disease state, and the processor is further configured to determine a second guidance message based at least partially on the second disease state.

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

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

[0164] In Example 156, any one or more of the themes from Examples 154–155 include, as necessary, determining whether the patient's condition is atypical, or determining whether a low-likelihood state transition has occurred.

[0165] In Example 157, any one or more themes from Examples 154–156 include, as necessary, determining whether a guidance message is expected to occur or whether a low-likelihood state transition is predicted to occur.

[0166] In Example 158, any one or more subjects from Examples 154–157 include, as necessary, determining the patient's condition, determining the physiological and behavioral conditions, and determining whether the physiological condition is atypical with respect to the determined behavioral condition.

[0167] In Example 159, any one or more subjects from Examples 154–158 include, as necessary, determining whether a patient's condition is atypical by identifying blood glucose levels that deviate from the controlled blood glucose range by time or circumstances, when blood glucose levels are normally within a controlled range.

[0168] In Example 160, any one or more subjects from Examples 154–159 include, as necessary, determining whether the patient's condition is atypical by identifying blood glucose concentration trends that lead to hyperglycemic or hypoglycemic states over time or under certain circumstances, when blood glucose concentrations are normally within a controlled range.

[0169] In Example 161, any one or more subjects from Examples 154–160 include, as necessary, determining whether the patient's condition is atypical, and predicting a shift to a low blood glucose state, either all at once or in circumstances, when blood glucose levels are normally well controlled.

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

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

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

[0173] Example 165 includes, if necessary, determining that any one or more themes from Examples 162–164 is likely to occur when a low-probability state transition is inconvenient.

[0174] In Example 166, the subject of Example 165 is determined, if necessary, to be more likely to occur when low-probability state transitions are inconvenient, and this includes referencing the user calendar of scheduled events.

[0175] In Example 167, any one or more themes from Examples 165–166 are determined to be more likely to occur when low-probability state transitions are inconvenient, including a reference to a behavioral state model.

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

[0177] In Example 169, the subject of Example 168 involves, if necessary, determining the period during which the patient is likely to take action to prevent a low-probability state transition, by referring to a calendar of scheduled events.

[0178] Example 170 includes, wherever necessary, using a model to determine the period during which a patient or caregiver is likely to take action to prevent a low-probability state transition.

[0179] In Example 171, any one or more subjects from Examples 168–170 include, where necessary, using a model to determine the likely duration for which a patient or caregiver is likely to be available, using patterns of user activity or user location information.

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

[0181] In Example 173, the subject of Example 172 includes receiving behavioral, environmental, or contextual inputs, as needed, including receiving accelerometer data.

[0182] In Example 174, any one or more subjects from Examples 172–173 include receiving behavior, environment, or context input as needed, which includes receiving information from a calendar about a scheduled event.

[0183] In Example 175, any one or more subjects from Examples 172–174 include receiving behavioral, environmental, or contextual input, as necessary, or receiving input from a user via a user interface.

[0184] In Example 176, any one or more subjects from Examples 172–175 include receiving behavior, environment, or contextual input, as necessary, or receiving information from the user about the completion, initiation, or expectation of an action.

[0185] In Example 177, any one or more subjects from Examples 172–176 include detecting that a user is driving by receiving behavioral, environmental, or contextual input, as necessary.

[0186] In Example 178, any one or more subjects from Examples 172–177 include receiving one or more behavioral, environmental, or contextual inputs, or receiving location information, as applicable.

[0187] In Example 179, any one or more subjects from Examples 172–178 include, as necessary, receiving one or more behavioral, environmental, or contextual inputs, including receiving ambient temperature or ambient pressure.

[0188] In Example 180, any one or more subjects from Examples 172–179 include receiving body temperature, heart rate, or respiratory rate, as required.

[0189] In Example 181, the subject matter of Example 180 is expanded to include training a model based on one or more patterns in the received information, as needed.

[0190] In Example 182, the subject of Example 181 is extended to include, if necessary, training the model to learn patterns of insulin sensitivity as a function of time.

[0191] In Example 183, the subject of Example 182 is extended to include, if necessary, training the model to learn a pattern of insulin sensitivity as a function of time elapsed after a period of physical activity.

[0192] In Example 184, any one or more subjects from Examples 172–183 include, as necessary, determining a user query and providing the user query to the user, with behavior, environment, or context inputs received in response to the user query.

[0193] In Example 185, any one or more subjects from Examples 172–184 include receiving data indicating glucose concentration, as required, from a continuous glucose concentration monitoring system.

[0194] Example 186 is a system comprising: a glucose concentration sensor configured to detect host glucose concentration; a communication circuit configured to receive host glucose concentration from the glucose concentration sensor; a memory circuit containing stored models; and a processor configured to access data associated with a host, use the data to determine the host state, determine a guidance message based at least partially 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 is expanded to include the calculation of timing to allow for intervention before the host transitions to an undesirable physiological state, if necessary.

[0196] In Example 188, any one or more of the themes in Examples 186–187 include, where necessary, determining guidance messages based at least in part on a personalized behavioral model of the host, and calculating the timing to be useful to the host in the treatment and management of diabetes.

[0197] In Example 189, any one or more subjects from Examples 186–188 include, where necessary, determining the state based at least in part on a physiological model of the patient and a behavioral model of the patient.

[0198] Example 190 is a method for 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 at least partially using the model and the first real-time data; and 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 allow intervention before a transition to an undesirable physiological state.

[0199] In Example 191, the subject of Example 190 includes, where necessary, determining the guidance message is further based on the timing of determining the guidance message or the time related to the determined state.

[0200] In Example 192, any one or more subjects from Examples 190–191 include, where necessary, a condition in which the model demonstrates the convenience or availability of the patient participating in the intervention.

[0201] In Example 193, any one or more of the themes from Examples 190–192 include, where applicable, guidance messages that are at least partially based on the predicted transition to an undesirable physiological state.

[0202] In Example 194, the subject of Example 193 includes, where necessary, that the guidance message is at least partially based on the determination that the expected transition from the current state to the expected state is a low-probability transition.

[0203] In Example 195, any one or more subjects from Examples 190–194 include, as necessary, a model that includes a patient physiological model, and determining the patient's condition is based on applying at least first real-time data to the patient physiological model.

[0204] In Example 196, the subject matter of Example 195 is expanded to include, if necessary, a behavioral model.

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

[0206] In Example 198, any one or more subjects from Examples 196–197 include, where necessary, a behavioral model based on a set of one or more steps that are determined to be likely to be performed by the patient.

[0207] In Example 199, any one or more subjects from Examples 196–198 include, where necessary, a behavioral model based on a set of one or more objectives that have been determined to be likely achievable by the patient.

[0208] In Example 200, any one or more of the themes from Examples 196–199 include, where necessary, that the behavioral model is a pattern.

[0209] In Example 201, any one or more subjects from Examples 196–200 include, as necessary, a patient's physiological model being based on physiological patterns and a behavioral model being based on behavioral patterns.

[0210] In Example 202, the subject of Example 201 is extended, as needed, to include the first real-time data showing a deviation from the expected behavioral pattern.

[0211] In Example 203, the subject of Example 202 is extended to include, where necessary, a behavioral model showing a tendency to overcorrect for meals associated with mealtime, first real-time data indicating that mealtime is imminent, and a guidance message corresponding to a reduction in mealtime overcorrection.

[0212] In Example 204, the subject of Example 203 includes, where necessary, 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 the current behavior.

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

[0214] In Example 206, the subject of Example 205 is, where necessary, based on one or more selected from the group consisting of engagement with a mobile device, accelerometer data, frequency of glucose concentration checks, calendar data, and combinations thereof.

[0215] In Example 207, any one or more subjects from Examples 190–206 include, if necessary, determining the state based on a measurement model.

[0216] In Example 208, the subject matter of Example 207 is extended, including, where necessary, that the measurement model is based on a patient-related continuous glucose concentration monitoring system.

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

[0218] In Example 210, the subject matter of Example 209 includes, if necessary, that glucose concentration data measured following the decision is fed back into a measurement model, a behavioral model, a patient physiological model, or a combination thereof.

[0219] In Example 211, any one or more subjects from Examples 190–210 include, as necessary, a model that includes patterns selected from a group consisting of physiological patterns, contextual patterns, behavioral patterns, or combinations thereof.

[0220] In Example 212, the subject matter of Example 211 includes, where necessary, that the physiological patterns are based on a physiological model.

[0221] In Example 213, any one or more of the themes in Examples 190–212 include, as necessary, a model based on a combination of patterns selected from a group consisting of physiological patterns, contextual patterns, or behavioral patterns.

[0222] In Example 214, any one or more subjects from Examples 190–213 may, as necessary, further comprise determining a guidance message, determining multiple guidance messages based on a state and first real-time data, and further selecting one of the determined multiple guidance messages based on the state and first real-time data.

[0223] In Example 215, the subject matter of Example 214 includes, where necessary, that the selection is based on a ranking scheme, a prioritization scheme, or a comparison of multiple guidance messages with one or more relevant thresholds.

[0224] In Example 216, any one or more subjects from Examples 190–215 include, if necessary, determining the patient's expected diabetic response based on their condition and first real-time data, and guidance messages are further personalized to the patient based on the expected diabetic response, and the patient is provided with actionable messages calculated to move the expected diabetic response toward a desired diabetic response.

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

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

[0227] In Example 219, the subject of Example 218 is, if necessary, the functional relationship being the difference between the glucose concentration level associated with the expected diabetic response and the glucose concentration level associated with the desired diabetic response.

[0228] In Example 220, the subject of Example 219 is, if necessary, a glucose concentration level associated with the desired diabetic response, which is either a target glucose concentration level or a target glucose concentration range.

[0229] In Example 221, the subject matter of Example 220 includes, where necessary, that the functional relationship is based on whether the expected diabetic response matches predetermined conditions related to the desired diabetic response.

[0230] In Example 222, the subject of Example 221 is, if necessary, a given condition which is a target glucose concentration level, a target glucose concentration range, a glucose concentration signal signature, or a rate of change related to the glucose concentration level.

[0231] In Example 223, any one or more subjects from Examples 217–222 may include, if applicable, that the guidance message may further include one or more reasons related to the functional relationship, thereby informing the patient of the reason why the guidance message is being provided.

[0232] In Example 224, any one or more of the themes from Examples 190–223 include, if necessary, that the guidance message includes actionable prompts.

[0233] In Example 225, the subject of Example 224 is further expanded to include, if necessary, actionable prompts that are calculated to move the patient's glucose concentration level toward a target level or range.

[0234] In Example 226, any one or more subjects from Examples 190–225 include, where applicable, a guidance message that includes an affirmation of the patient's current behavior.

[0235] In Example 227, any one or more subjects from Examples 190–226 include, as necessary, the first real-time data being measured, received, or determined by a smartphone.

[0236] In Example 228, any one or more subjects from Examples 190–227 include, as necessary, the first real-time data being measured, received, or determined by a wearable device.

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

[0238] In Example 230, any one or more subjects from Examples 190–229 include, as necessary, the first real-time data being measured, received, or determined by an external device.

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

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

[0241] In Example 233, any one or more of the themes from Examples 190–232 include, as necessary, that the first real-time data is a change in state.

[0242] In Example 234, the subject of Example 233 is extended to include the detection of state changes by a clock, accelerometer, or GPS circuit, as necessary.

[0243] In Example 235, any one or more of the themes from Examples 190–234 include, as necessary, that the first real-time data is a user request for a decision support prompt.

[0244] In Example 236, any one or more of the themes from Examples 190–235 are, if necessary, included receiving first real-time data from a continuous glucose concentration monitoring system.

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

[0246] Example 238 includes the occurrence of any one or more themes from Examples 190–237 when it is calculated that providing a determined, personalized guidance message would be useful in managing the patient's glucose concentration levels, as needed.

[0247] In Example 239, any one or more subjects from Examples 190–238 include, as necessary, a disease state in which the condition describes the stage of the patient's illness.

[0248] In Example 240, the subject of Example 239 includes, if 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 stage of disease of a second patient by applying the second data to a model; and determining a second guidance message at least partially based on the second disease state.

[0249] In Example 241, any one or more subjects from Examples 190–240 optionally include having a state that is an engagement state, further comprising determining messaging frequency based at least in part on the engagement state, and determining the time for providing personalized guidance messages based at least in part on the messaging frequency.

[0250] In Example 242, any one or more subjects from Examples 190–241 include, if necessary, receiving learning data during the learning period and determining the patient's condition based at least in part on the learning data.

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

[0252] In Example 244, the subject of Example 243 includes, if necessary, learning a personalized behavioral model of the patient, which involves machine learning the patient's first characteristics.

[0253] In Example 245, the subject of Example 244 includes, as necessary, that the first characteristic is a pattern selected from a group consisting of physiological patterns, contextual patterns, behavioral patterns, or combinations thereof.

[0254] In Example 246, the subject of Example 245 includes, if necessary, delivering personalized guidance messages at the time of delivery.

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

[0256] In Example 248, the subject of Example 247 is extended to include receiving the first real-time data, if necessary, which is a glucose concentration value.

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

[0258] In Example 250, any one or more subjects from Examples 248–249 include, as necessary, a state model in which the patient's physiological model includes a glucose concentration state, an insulin onboard state, and one or more of the following states: an insulin sensitivity state, an energy absorption state, or an energy expenditure state.

[0259] In Example 251, any one or more of the themes from Examples 248–250 include training a model from a set of input data, as needed.

[0260] In Example 252, the subject of Example 251 includes, as necessary, a set of input data which includes one or more of the following: clock time, time of day, glucose concentration level, insulin onboard, patient activity, patient health, day of the week, date, day of the week, location, food consumed, or beverage consumed.

[0261] In Example 253, any one or more subjects from Examples 251–252 include, as necessary, determining deviations from the expected state after delivering personalized guidance messages and adapting the model based on additional input information.

[0262] In Example 254, the subject of Example 253 includes, if necessary, a set of input data that includes information received via the user interface.

[0263] Example 255 includes providing personalized guidance messages in a user interface, where any one or more of the subjects in Examples 247-254 may, if necessary, be determined to provide personalized guidance messages.

[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 this disclosure. The detailed description is included to provide further information relating to this patent application. Other aspects of this disclosure will be apparent to those skilled in the art by reading and understanding the detailed description below and by looking at the drawings that form part thereof, each of which should not be interpreted restrictively.

[0265] In drawings that are not necessarily drawn to a consistent scale, similar symbols may describe similar components in different drawings. Similar symbols with different letter suffixes may represent different instances of similar components. Drawings generally illustrate various embodiments described in this document as examples, not limitations. [Brief explanation of the drawing]

[0266] [Figure 1] This illustrates an exemplary system for delivering guidance to patients. [Figure 2A] This is a diagram of the model shown in Figure 1. [Figure 2B] This figure provides a more detailed diagram of exemplary model inputs and exemplary states that can be determined by applying inputs to the model. [Figure 3A] This is a diagram illustrating an example timeline related to a patient. [Figure 3B] This is a diagram illustrating an example schedule for caregivers and child patients. [Figure 3C] This is a diagram showing the patient's wakefulness / sleep state. [Figure 3D] This diagram determines the availability (or convenience) for a patient to participate in an intervention, based on other conditions. [Figure 4] This is a diagram of various input categories coupled with various output categories via a decision step or module. [Figure 5A] This flowchart shows an example of a method for determining user guidance. [Figure 5B] This flowchart shows an example of a method for determining user guidance. [Figure 6] This flowchart shows an example of a method for determining user guidance. [Figure 7] This flowchart shows an example of a method for determining user guidance. [Figure 8] This flowchart shows an example of a method for determining user guidance. [Figure 9] This flowchart shows an example of a method for determining user guidance. [Figure 10] This flowchart shows an example of a method for determining user guidance. [Figure 11] This flowchart shows an example of a method for determining user guidance. [Figure 12]This flowchart shows an example of a method for determining user guidance. [Figure 13] This flowchart shows an example of a method for determining user guidance. [Figure 14] This flowchart shows how to convert unclear input into quantifiable criteria. [Figure 15] This demonstrates the use of one type of correlation parameter within a system model, such as food sensitivity, in decision-making support for dietary bolus decisions. [Figure 16a] This shows the various inputs that can be used in decision support applications / functions. [Figure 16b] This shows the various inputs that can be used in decision support applications / functions. [Figure 16c] This shows the various inputs that can be used in decision support applications / functions. [Figure 16d] This shows the various inputs that can be used in decision support applications / functions. [Figure 16e] This shows the various inputs that can be used in decision support applications / functions. [Figure 16f] This shows the various inputs that can be used in decision support applications / functions. [Figure 17] This shows various physical sources for the input data. [Figure 18A] This describes a different method for acquiring dietary data than conventional methods. [Figure 18B] This describes a different method for acquiring dietary data than conventional methods. [Figure 19] For example, this is a flowchart for obtaining signal signature information that can be used as input for decision support, for state definition and determination. [Figure 20] For example, a chart showing gastric emptying duration can serve as input for decision-making support, for defining and determining a state. [Figure 21]A chart showing a mode, for example, the operating mode of a CGM, and the mode can also be used as an input to decision-making support, for example, for the definition and determination of states. [Figure 22A] It shows a user input for adjusting the threshold level. [Figure 22B] It shows a user input for adjusting the threshold level. [Figure 23] It is a diagram of an exemplary system in which the methods described in this specification can be implemented. [Figure 24] It is a block diagram of an exemplary machine in which any one or more of the technologies (e.g., methodologies) described in this specification can be executed. [Figure 25A] It is a diagram of an exemplary user interface in which a user can select carbohydrate content and fat content on a graph. [Figure 25B] It is a diagram of an exemplary user interface in which a user can select carbohydrate content and fat content on a graph. [Figure 26] It shows an exemplary user interface in which an alarm can be configured. [Figure 27A] It is a diagram of a user interface showing predicted data for the selected carbohydrate intake. [Figure 27B] It is a diagram of a user interface showing predicted data for the selected carbohydrate intake. [Figure 28] It is a diagram of exemplary guidance distributed on the user interface of a mobile device. [Figure 29] It is a diagram of exemplary guidance distributed on the user interface of a mobile device. [Figure 30] It is a diagram of exemplary guidance distributed on the user interface of a mobile device. [Figure 31A] It is a diagram of an exemplary glucose postprandial trend without timely decision-making support guidance. [Figure 31B] It is a diagram of an exemplary glucose postprandial trend with timely decision-making support guidance. [Figure 32A] It is a diagram of an exemplary post - meal insulin tendency distribution pattern without decision - making support guidance. [Figure 32B] It is a diagram of an exemplary post - meal insulin tendency distribution pattern with decision - making support guidance. [Figure 33] It is a diagram of an exemplary glucose tendency including an intervention for dealing with hypoglycemic events. [Figure 34] It shows an exemplary user interface of the device. [Figure 35] It shows an exemplary user interface of the device. [Figure 36] It shows an exemplary user interface of the device. [Figure 37] It shows an exemplary user interface of the device. [Figure 38] It is another diagram of the model shown in FIG. 1. [Figure 39] It is a flowchart showing an example of a process flow that can be executed by a decision - making support system to change according to the change in the host's disease stage.

Mode for Carrying Out the Invention

[0267] Managing diabetes can present complex challenges for patients, clinicians, and caregivers, as the convergence of many factors can influence a patient's blood glucose levels and blood glucose trends. The inventors recognized, among other things, that intensive insulin users can benefit from real-time guidance determined or delivered when 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 a time that is calculated to be within a time window when the patient or caregiver is likely to be available to receive and act upon the guidance, or otherwise when the guidance would be useful. In some examples, the system can learn user preferences or behavioral characteristics or patterns and use those preferences, characteristics, or patterns to determine the timing of the guidance. By delivering 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 the timing of delivering guidance calculated to be useful to the user (e.g., patient, caregiver, or clinician) can help users sleep better by knowing how to improve their sleep by taking action based on pre-sleep guidance, such as getting uninterrupted sleep to manage glucose levels, or avoiding highs and lows during sleep, or by knowing when there are potential problems that need to be addressed. The system can also help users eat better by providing guidance from, for example, a decision support system, to give the patient confidence that whatever they eat will stay within the normal range after meals, or can stay within the normal range after meals, or that they are safe and effective, regardless of what they did leading up to the meal. The system can, alternatively or additionally, help users live better lives (e.g., improve their quality of life) by, for example, when users need to pay attention to diabetic issues (e.g., glucose levels), or when they need to adapt to unexpected events during the day while maintaining controlled glucose levels, or by recognizing potential or possible excursions in advance and knowing when they can react or respond to the excursion without overcompensating or overeating (e.g., excessive carbohydrate intake).

[0269] In some examples, the delivered guidance can help patients, caregivers, or healthcare providers improve lifestyle or clinical / patient outcomes by addressing a variety of challenges, such as nocturnal glycemic control (e.g., reducing the incidence of hypoglycemic events or hyperglycemic excursions), in-meal and post-meal glycemic control (e.g., improving glycemic control using historical information and trends), hyperglycemia correction (e.g., increasing target zone time while avoiding hypoglycemic events from overcorrection), hypoglycemia treatment (e.g., managing hypoglycemia while avoiding "rebound" hyperglycemia), exercise, and other health factors. The system can learn the patient's physiological function and behavior and provide treatment optimization tools that calculate guidance to help 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. Decision support tools can help patients respond to problems in real time by, for example, predicting hypoglycemic or hyperglycemic events or trends, addressing occurring or potential hypoglycemic or hyperglycemic events or trends, and providing treatment recommendations for monitoring how blood glucose, physiology, or behavior respond in real time. This type of calculated guidance and support can reduce the cognitive burden on patients, caregivers, or healthcare professionals.

[0270] Physiological sensors, such as continuous glucose monitoring, can provide useful data that patients, caregivers, or healthcare professionals can use to manage glucose levels. However, developing effective strategies for glucose management may require significant processing of this data. The sheer volume of data, and the recognition of correlations between data types, trends, events, and outcomes, can far exceed human processing capabilities. This is particularly impactful when decisions regarding treatment or responses to physiological conditions are made in real time. Integrating real-time or recent data with historical data and patterns can provide useful guidance in making real-time decisions about treatment. Technological tools can process this information to provide calculated decision-supporting guidance tailored to specific patients in specific conditions or situations at specific times. These tools can also reduce the cognitive burden on human decision-makers by performing iterative calculations throughout the day to determine when to delay or deliver guidance.

[0271] Decision support systems can be particularly helpful in developing pre-sleep guidance to increase the likelihood of glucose levels being controlled during sleep. For example, a system can use algorithms or models to determine whether hyperglycemic or hypoglycemic events are possible or likely and create guidance that could include pre-sleep behavioral items such as insulin delivery, food intake (e.g., fast carbohydrates, slow carbohydrates, or carbohydrates combined with protein), or setting alarms to check the status or guidance at specific times. Systems can also use algorithms or models to provide context-dependent alerts. For example, a system can recognize from human input or sensor input or behavioral patterns that a user is sleeping or about to sleep and take sleep activity into account when calculating when to deliver an alert or warning. In some examples, a system can delay the delivery of an alert or guidance (e.g., until risk conditions are met or an intervention time window opens) to avoid unnecessarily waking the patient or caregiver. In some examples, a system can calculate when to deliver guidance (and alerts that may wake the patient or time provider) to increase the likelihood that a more disruptive intervention is unavailable. For example, the system may determine that a consultation is desirable (e.g., checking for low pressure, or checking for fever, blood glucose, or other physiological sensors) or that adjustment of the basal or bolus dose is necessary to avoid a hyperglycemic event, for example, by timely delivery of insulin via injection or pump, or to avoid a hypoglycemic event by reducing insulin delivery via pump and subsequently waking the patient to deliver carbohydrates via food or beverage.

[0272] Decision support systems configured to calculate guidance and the timing of that guidance can also be helpful in transitioning to new treatments or environments, or in navigating disease progression over time (e.g., changes in pancreatic function or the "honeymoon" period of partial pancreatic function fading, changes in treatment routines for patients with type 2 diabetes), by providing guidance on potential outcomes, notifications when decisions may be needed, or guidance on the potential impact of therapeutic interventions or behavioral decisions (e.g., exercise, rest, or diet).

[0273] The decision support system incorporates patterns and other information related to eating behavior (e.g., number of meals per day, distribution of meal size across meals and snacks, size of treatment for hypoglycemic excursions, or number of recurrent treatments for hypoglycemic events), insulin dosage information (e.g., bolus and basal dosage patterns, pump settings or injection patterns, number of bolus per day, amount of trend adjustment, pre-meal bolus patterns, pre- and post-adjustment behavioral bolus, number of corrected bolus per day), behavioral patterns (presence and accuracy of carbohydrate counting, incidence of activity or no response to hyperglycemia, or need for corrected bolus, correction status, threshold or need (e.g., glucose levels, combination of trend and level, food or other factors)), insulin onboarding recognition, insulin timing, pre-meal "pre-bolus" patterns and their duration, errors in insulin delivery or therapeutic intervention, exercise timing, exercise duration, and exercise intensity, and physiology to activity. Guidance can be determined using a variety of information sources, including: physiological responses (patterns of response to insulin, carbohydrates, and other foods; tendency to “rebound” to hyperglycemia after low glucose; effects of disease or medication on insulin sensitivity or glucose levels); responsiveness to guidance (time to check for warnings or alarms; actions taken in response to warnings or alarms (e.g., eating, sleeping, or exercising)); and glycemic outcomes (e.g., percentage of time spent below one or more glucose concentration thresholds (e.g., <70 mg / dL, <50 mg / dL); percentage of time spent above one or more glucose concentration thresholds (e.g., <180 mg / dL, <250 mg / dL); and the number of events where one or more glucose levels are below or above a threshold); disease stage and / or type of treatment (e.g., type I honeymoon period, type II prediabetes stage, type II oral medication stage, type II basal insulin stage). Additional exemplary inputs are described below.

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

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

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

[0277] While many of the descriptions and examples relate to glucose sensors capable of measuring glucose concentration in a host, the systems and methods of the embodiments can be applied to any measurable analyte. Several exemplary embodiments described below utilize an implantable glucose sensor. However, it should be understood that the apparatus and methods described herein can be applied to any apparatus capable of detecting the concentration of an analyte and providing an output signal representing the concentration of the analyte.

[0278] In some embodiments, the analyte sensor is an implantable glucose sensor as described in 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 in U.S. Patent Application Publication No. 2006-0020187. In still other embodiments, the analyte sensor is a dual electrode analyte sensor as described in 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, titled "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, and both are hereby incorporated by reference in their entirety.

[0280] Overview of an Exemplary System Delivering guidance once, or in situations that promote timely action of such guidance, can facilitate 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 timings that are useful to the user, such as a patient or caregiver, by considering data from various data sources, including physiological sensors, historical information, and other information about the patient or caregiver. The timing can be calculated, for example, based on timing factors or patterns, or based on the occurrence of situations that can be recognized from previously observed patterns. These situations can be, for example, physiological, behavioral / contextual, or both. In some examples, guidance decisions or timings can be calculated to be useful to the user by referring to known patterns and associated glucose control trends, and considering the recurrence of similar situations to those known.

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

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

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

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

[0286] Physiological models In some cases, 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 patient guidance, the timing of guidance, or both. For example, one or more inputs (described in detail below, see, e.g., Figure 2B, and Figures 14-16 and their descriptions) can be applied to a model or multiple models to determine a patient's physiological state. Physiological states can include, for example, glucose concentration levels (e.g., blood glucose levels or glucose concentration in other body fluids such as interstitial fluid), decreases or increases in glucose concentration levels (i.e., glucose trend), or the rate of decrease or increase in glucose concentration levels (e.g., gradient or high-level derivative). Determined physiological states can also be, or include, activity levels (e.g., exercise detected from an accelerometer, heart rate sensor, or respiratory sensor), metabolic drives (e.g., glucose consumption rate), and insulin resistance (e.g., in response to stress hormone secretion, disease, or hyperglycemia levels), insulin sensitivity (described in detail below), insulin onboarding, insulin action time, insulin duration, and carbohydrate-to-insulin ratio. Other physiological conditions are also possible. Behavioral model or contextual model

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

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

[0289] Measurement model The measurement model can at least partially evaluate or verify 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 finger-prick sensor) or from a smart meter (e.g., configured with a communication function for transmitting or sending values), measured blood glucose administration information (e.g., dosage information received from an insulin "smart" pen configured to track and communicate administration information), insulin dosage 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 input to other models.

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

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

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

[0293] The system 100 may include a decision support engine 104 that processes patient information (e.g., received real-time sensor data) and combines the sensor information with patterns, e.g., 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 to the patient 102 as guidance via the user interface 108, used to determine the guidance, or used to determine the timing of the guidance. The guidance may include, for example, diabetes treatment guidance.

[0294] Example input Exemplary implementation of a decision support engine To provide patient information to the decision support engine 104, one or more sensors 106 can be associated with the patient. Sensor 106 may include, for example, an analyte sensor such as a glucose sensor as described above. Sensor 106 may be a body fluid sensor such as a transcutaneous sensor, a contact lens sensor or a skin sensor, or an implantable sensor configured to measure the quality of interstitial fluid or blood. For example, sensor 106 may be a subcutaneous, transcutaneous, non-invasive intraocular and / or intravascular glucose sensor as described above. In some examples, the sensor is a Dexcom TM Abbot TM (For example, Libre TM Sensor), or Medtronic TM(For example, Enlite TMSensor 106 can be a wearable or implantable sensor connected to patient 102, such as a continuous glucose monitoring sensor available from the sensor. Other types of sensors can also be associated with the patient, such as heart rate sensors, respiratory sensors, other types of analyte sensors, motion sensors (e.g., accelerometers), posture sensors (e.g., 3-axis accelerometers), or acoustic sensors (e.g., for capturing ambient or internal sounds). Sensor 106 can be worn on, for example, a watch, glasses, contact lenses, a patch wristband, ankle band, or other wearable item, or it can be incorporated into a handheld device (e.g., a smartphone), or it can be incorporated into other sensors such as a continuous glucose monitoring sensor. In some examples, sensor 106 may include a multi-sensor patch that can detect, for example, glucose levels, heart rate, respiration (e.g., using impedance), activity (e.g., using an accelerometer), posture (e.g., using an accelerometer), electrocutaneous reactions, and tissue fluid levels (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, which can be a mobile device such as a smartphone, via wired or wireless (e.g., Bluetooth®, Zigbee, Z-Wave, NFC) communication. The system can learn the combined signal 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 signal junction distribution (e.g., how sensor signals relate to or move together) to: A) determine or substitute missing sensor data points (e.g., using models, algorithms, or calculations, as further described below); B) predict future blood glucose levels; C) detect sensor failures or performance issues with the CGM sensor based on junction signals recorded in real-time and historical information; or D) estimate the number of carbohydrates, fats, proteins, or other substances, or any combination thereof, ingested based on sensor information.

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

[0296] The input to the decision support engine 104 may also include insulin data 122. Insulin data can be obtained, for example, from an insulin delivery device such as a pump, or received from a smart pen configured to track insulin delivery and communicate insulin delivery information to a smart device via wireless communication, such as the decision support engine. 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 support engine 104 can also receive other information 124, such as meal information, sleep information, or calendar information, which may include detected information (e.g., sleep detected using an accelerometer or physiological sensor), learned information (e.g., temporal patterns), or information provided by the user via a user interface (e.g., meal and schedule information). Additional inputs that can be received by the decision support engine 104 are described with reference to Figures 2A, 2B, and 14-16. Additional details of exemplary system components are described with reference to Figures 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 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 the pump).

[0298] Exemplary implementation of a decision support engine The decision support engine may include one or more models 110. These one or more models 110 may include, for example, state models. For example, a “virtual patient” model may include known information about a patient, such as that formed from known factors, based on a template model derived from population data, learned from information about the patient, or a combination thereof. The models may reflect, for example, physiological and behavioral information. Physiological information may include factors such as 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 may include factors such as food and beverage intake, exercise, insulin administration, schedules described by calendar appointments, and interest in guidance. In state models, these factors can be represented as states, which can be discrete (e.g., high, medium, low) or continuous (e.g., determined by a function). These one or more models 110 may include patterns, such as physiological patterns, contextual patterns, or behavioral patterns, or combinations thereof. Physiological patterns can be based, for example, on physiological models.

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

[0300] In various examples, the decision support engine 104 can reside in a remote resource 109, a local device 108, or a combination thereof (e.g., a "hybrid configuration"). The decision support engine 104 can reside in or be connected to one or more remote resources 109 (e.g., cloud servers) via a network such as a cellular network, 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 patient's or patient caregiver's calendar. In some examples, the decision support engine 104 can reside in a device near the patient, e.g., a local device 118. In some examples, the decision support engine 104 can reside in a local device but can receive assistance or periodic updates from a remote system. In a hybrid configuration example, 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 has higher processing power. The hybrid configuration can maintain or improve the performance of the local device 108 by avoiding overloading the local device with excessively complex processing tasks. The hybrid configuration can also improve system performance because some tasks can be performed quickly without network access by the local device 108, but even more complex tasks are possible by leveraging the greater processing power of the remote resource 109.

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

[0302] Example of a decision on the timing of guidance by a decision support engine. A decision support engine can process various inputs, for example, by applying the inputs to one or more models and determining the timing of guidance that is calculated to be useful to the user. In various examples, the timing of guidance can be calculated to enable the user to improve their sleep experience, eating experience, or quality of life. For example, the system can identify potentially problematic patterns and determine when to deliver guidance, in which case the guidance delivery time is calculated to avoid sleep interruption, or to maintain blood glucose control while giving the user flexibility in meal choices and timing, or to provide sufficient advance notice of potential problems (e.g., high glucose fluctuations or low glucose levels) so that the user can adapt their behavior or respond to the problem in a timely manner.

[0303] For example, the system can promote healthy or uninterrupted sleep by determining that problems are more likely to occur when the user is likely to be asleep (e.g., 2 a.m.) and calculating the time to deliver guidance when the user is likely to be available (e.g., 9 p.m.). The system can avoid nighttime lows by recommending actions such as eating a pre-sleep snack to avoid the need to wake the user at night. For example, the system can receive glucose values ​​and, based on a patient learning model, determine that the patient is more likely to have a hypoglycemic event when the user (caregiver or patient) is likely to be asleep, and determine the time to provide guidance and ensure that the guidance is not disturbed to the patient's or caregiver's sleep.

[0304] In other cases, the system may determine delivery guidance for modifying behavior or treatment based on patterns of nocturnal blood glucose levels or trends. For example, the system may recommend increasing the base dose if it detects a pattern of rising glucose levels at night that meets a condition (e.g., above a specified value (e.g., 130 mg / dL) or a change of a specified amount (e.g., an increase of more than 30 mg / dL or 40 mg / dL during sleep or a specified period related to sleep (e.g., from 12 a.m. to 5 a.m.))). In other cases, the system may recommend decreasing the base dose when it detects a pattern of glucose levels that decreases by a specified amount or rate, or otherwise meets a condition.

[0305] In other examples, the system can support mealtime decisions by providing users with flexibility in deciding what and when to eat, while also offering guidance calculated to help maintain blood glucose control. In one example, the system might determine that glucose levels tend to be higher before mealtime and decide when to deliver guidance about a pre-meal corrective bolus to avoid the need to delay eating when mealtime arrives. For example, the system might determine that a user needs a specified amount of "pre-bolus" before a meal (e.g., delivering insulin 20 minutes before starting a meal), and the system might decide when to deliver guidance to deliver the bolus so that the meal begins at a planned time or a time that matches a learned pattern. In some examples, the length of the pre-bolus window (the time from administering the insulin bolus to starting the meal) can be determined by the system, and the timing of the guidance can be calculated to give the user a time corresponding to the calculated pre-bolus window. For example, the system might determine that a patient needs a 30-minute pre-bolus to affect high glucose levels before their next meal. In one example, the system might deliver guidance 30 minutes before the scheduled meal to prompt the user to deliver the pre-bolus. In other examples, the system may provide users with additional time to respond to pre-bolas. For instance, the system might decide that pre-bolas guidance is delivered 60 minutes before a meal to allow for 30 minutes prior notification of the need to deliver a pre-bolas 30 minutes before the meal.

[0306] In other mealtime examples, the system can calculate the timing for delivering guidance during or after a meal. For example, the system might determine that insulin levels are rising faster than normal and that guidance should be given to deliver an additional dose of insulin. In one example, the system can calculate the timing for delivering guidance to optimize glucose control. For example, the system might determine that guidance should be given during the meal to deliver additional insulin. In another example, the system can calculate the timing for delivering guidance to avoid interrupting a meal. This can be achieved, for example, by referring to a user calendar, or by using physiological sensors (e.g., activity sensors) based on behavioral patterns (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 a patient or caregiver by calculating the timing of delivering guidance to provide sufficient advance notice of potential problems (e.g., high glucose fluctuations or low glucose levels) so that users can adapt their behavior or respond to problems in a timely manner. For example, the system may determine that an excursion (e.g., a tendency toward high glucose) is likely to occur and determine the timing of delivering guidance that will enable the user to take corrective measures (e.g., provide a corrective bolus or exercise) to counteract the likely excursion. In some examples, the system can make the timing of guidance delivery calculated and / or predictable so that users can anticipate the delivery of guidance while focusing on other activities. For example, the system may deliver guidance every two hours during the day. In some examples, the system may determine a repeating schedule until the guidance is delivered. In some examples, the system may deliver guidance regarding the user's need for attention to glucose management. For example, the system may calculate the probability of the need for user intervention (e.g., determining the risk of blood glucose levels falling outside a specified range) and notify the user when the conditions are met (e.g., the probability exceeds a threshold). In some cases, the system can periodically notify the user that no intervention is needed (for example, "Looking good: Blood sugar levels are well controlled").

[0308] In some cases, the system can deliver guidance on when to check the system for further guidance. For example, the system can receive meal information such as what was eaten and the expected or actual (current or past) meal times, and advise the user to check the system again for further guidance within a specified time, such as "check for further guidance in 30 minutes." In other cases, the system can deliver pre-sleep guidance, such as "eat a light snack and check again 10 minutes after eating," and require the user to check after completing their pre-sleep activity.

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

[0310] In some examples, the timing of guidance can be provided in relation to the current user activity, based on real-time data and patterns learned from past activities. For example, to determine when it is helpful to deliver 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 and timing of the guidance. The system can learn, for example, the glucose response after a particular meal. If real-time data suggests that the user is about to eat the same or similar meal (determined, for example, from GPS information or Wi-Fi connection to a restaurant), the insight can be delivered based on patterns learned from past activities. In other examples, real-time data may suggest that the user is about to go to sleep or that a meeting is approaching, and such data can be used to determine when to deliver guidance. For example, real-time information may indicate that decision support should be provided immediately or earlier than necessary to avoid interrupting upcoming activities (e.g., sleep or a meeting).

[0311] In some cases, the timing of guidance decisions can balance the need for data to determine the state, the need for timely action, and the need to avoid unnecessary or excessive interruptions to the patient. Generally, as time progresses, more data becomes available to obtain curve fitting to patterns or apply to models, which allows for more accurate conclusions about states, probabilities, or appropriate guidance. For example, four hours after a meal, most of the data about the body's response to the meal is available. However, after one hour, while the full response is still unknown, it is generally possible to identify how much the user ate or whether the delivered insulin was appropriate for the consumed meal. After two and a half hours, these decisions can be made even more precise. In some cases, the user may be given a corrective bolus, or, for example, the patient did not consume as much as thought, and the user may be instructed to eat more, potentially putting them at risk of a tendency toward low glucose levels. This additional information regarding food intake or insulin administration can also be processed by the system. In this example, the timing of delivering guidance can be determined based on the information available after the meal. This may include one or more of the following: food consumption information, insulin information, glucose level information, other physiological information (e.g., activity), and known physiological patterns (e.g., from physiological models). Timing may also be based on user settings that can be learned from the data (e.g., settings regarding the frequency or timing of warnings, e.g., warn frequently / not warn less frequently, or warn early / late, or warn according to a predetermined or learned schedule), which can be learned from the data (e.g., as states) or entered as user input.

[0312] Returning to the post-meal example mentioned above, it is possible to determine when to trigger the warning somewhere between the time the user eats and the time the warning is triggered. This decision can take into account the fact that if the warning is delayed, for example, if the system waits for a decision to deliver guidance or 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 waits for too long, the optimal or desirable time frame for delivering guidance and administering treatment may have passed while the system waits for data to accumulate, which may result in, for example, an undesirable glucose tendency or insulin sensitivity level. When glucose levels rise above the normal range, the patient's body tends to become insulin resistant, which can make it more difficult to bring glucose levels back to the normal range using insulin, and therefore may require higher doses of insulin. Higher doses of insulin may increase the risk of the patient tending towards low glucose levels when insulin resistance (and high glucose levels) is eventually overcome. On the other hand, if glucose levels tend to be too low, glucose administration may be too delayed or lead to an overreaction by the patient (e.g., too much carbohydrate administered too quickly) or the patient's body (e.g., glycogen release by the body), which can subsequently 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 glucagon administration may be necessary. In severe cases, patients may lose cognitive abilities or consciousness due to very low glucose levels, which may impair their ability to follow or participate in subsequent guidance.

[0313] When determining the timing of guidance, user convenience may also be considered. For example, if a user is expected to attend a meeting within two hours, the system may provide a warning before the meeting to avoid disrupting the user during the meeting or to ensure that guidance is delivered when intervention is possible, even if the determined state or guidance is less accurate than normally acceptable (e.g., the optimal balance between data accumulation and risk avoidance is not achieved). In some cases, if the user is in a situation where they do not need to respond to the warning, the system may provide an option to receive the warning earlier, even if the warning or guidance is less accurate, through a one-time user input that can correlate with or interact with the calendar, or by adjusting user-controlled settings. For example, if the system knows or can access the user's calendar, the system may provide such a prompt and option on its own ("Would you like an early warning before the meeting every Tuesday afternoon?"). In other cases, the system may receive requests from the user (e.g., in the form of user-requested insights, as further described below).

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

[0315] The system may also take the user's sleep schedule into account. For example, if it is known that a user goes to bed within four hours of eating, but their blood glucose response to that meal is not yet known, the system can provide guidance on what to do before bed to improve those circumstances or to avoid the risk of a tendency toward an undesirable state or glucose level. For instance, the system could deliver pre-sleep guidance to manage corrective boluses or make basic adjustments to avoid persistently high glucose levels or a tendency toward high glucose levels, or to avoid waking the user for nocturnal interventions. In another example, the system could deliver guidance to eat a snack before bed to mitigate the risk of low glucose levels.

[0316] Example output - guidance format The guidance output from the decision support engine 104 may include, for example, text (e.g., "Monitor unexpectedly low glucose levels"), sound (e.g., tone or conversation), graphics or animations such as predicted or actual insulin graphs, or a probability cone showing the range of possible outcomes from assumed or completed actions, such as exercise, food consumption, insulin delivery, or a combination thereof. The probability cone may show the range of potential outcomes over time, and the range of outcomes expands over time; that is, a wider range of options becomes available (or statistical conditions can be met). The guidance may include warnings, recommendations, or other useful information.

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

[0318] In various examples or guidance scenarios, decision support requests can be delivered via text, email, app notifications, phone calls, or other means of communication. In some cases, the best mode can be selected by the user or system based on context. For example, the system might use voice while the patient is driving and display a message during a meeting. In some cases, guidance and decision support requests can be voice-enabled using automated speech recognition and natural language understanding.

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

[0320] Examples of event-driven insights 126, user requirements insights 128, and periodic insights 130 are described in more 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, insights can be at least partially triggered by physiological events, such as patterns of glycemic events that may include, for instance, 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 specific relevance to events or patterns currently occurring. These personalized guidance messages can be based on learned information about the patient, which can be embodied or reflected by one or more patient models. For example, the system could detect patterns preceding hypoglycemic and hyperglycemic events and alert the user with sufficient time to take action. In another example, treatment adjustments can set context-driven alerts: for instance, if a treatment adjustment such as an increased basal rate is made, which may be determined to increase the risk of nocturnal low glucose levels, the system could make nighttime low glucose warnings more sensitive for a specified period, such as the next two weeks, or deliver personalized guidance messages to the user every night, or more frequently, or under broader conditions than before the adjustment, informing them of the possibility of nocturnal low glucose levels. In other examples, a treatment decision or event (e.g., forgetting to administer insulin before a meal, e.g., missing a “pre-bolus”) may be determined to justify enhanced alertness (e.g., checking CGM data or recognizing a potential need to provide treatment) during a time window following the decision or event, which can be communicated via a guidance message, or during a window under a broader set of conditions (e.g., lower thresholds for providing event-driven guidance). In some examples, event-driven alerts may be set based on cumulative glycemic risk or glycemic exposure, for example, food or calorie or carbohydrate consumption may be tracked, and insulin / glycemic imbalance may be detected, which can be communicated via personalized guidance (e.g., “food or beverage consumption may be exceeding expectations”) or form the basis of a personalized guidance message (e.g., “depending on your eating and drinking patterns, you may need more insulin”). In some examples, personalized guidance messages may offer a range of choices stratified by risk and reward.

[0323] In some cases, the decision support engine can determine bolus recommendations (dietary bolus or correction) and the timing for making those recommendations. The timing of bolus decisions and guidance delivery can be calculated to balance the need for guidance with the interest in avoiding interruptions for the patient / user and the need for sufficient data to accurately determine bolus information. In one example, manual input and learned or planned inputs (e.g., dietary information) may be supplied to the bolus calculator. The bolus calculator can be generic or personalized, for example, to the user's current diabetic status. The bolus calculator can output a recommended dose, and the system can observe glucose levels after the user has administered the recommended dose. Based on historical data, a typical blood glucose response in a particular situation can be identified, which allows for comparison of real-time data with historical data or patterns derived from historical data. For example, if a user consumes 60g of carbohydrates and a specific amount of insulin, the resulting glucose levels and trends that occur over time can be seen from historical data or patterns (e.g., a glucose level of 120mg / dL 30 minutes after a meal, rising slowly (e.g., 2mg / dL every 5 minutes)). In a particular case, the user indicates that they consumed a specific meal or amount of carbohydrates (e.g., 60g of carbohydrates), but the glucose value produces a different level or trend than in previous profiles (e.g., a glucose level of 160mg / dL and steadily rising (e.g., 10mg / dL every 5 minutes)), and the system can query the user to obtain corrected meal information, or determine the actual number of carbohydrates the user consumed based on the glucose signal and current guidance or query (e.g., "Did you eat anything else?" or "Did you not eat chicken?"). The system can also take into account absorption rates (for example, fast carbohydrates such as foods with large amounts of sugar or refined sugar versus slow carbohydrates such as pasta) and the presence of other foods that may affect glucose trends, such as proteins and fats, which can slow down the absorption rate of carbohydrates consumed with proteins and fats.

[0324] In an example using a state model, the patient's state is initially state 1 (e.g., ate 60 carbohydrates), and the system can then determine that the patient is actually in a different state (e.g., ate 90 carbohydrates). In another example, the patient's state may initially be state 1 (ate 60 carbohydrates), and medication is administered accordingly, but the patient's state is later determined to be state X (e.g., 30 grams of carbohydrates), in which case the system can provide decision-supporting guidance, such as a corrective bolus, to avoid under- or over-administering.

[0325] In some cases, the timing for delivering guidance regarding a corrective bolus may be determined using a physiological model, a behavioral model, or both. For example, an acceptable time range for delivering a corrective bolus can be determined using a physiological model, and a convenient time range for delivering guidance or a corrective bolus can be determined using a behavioral model, for example using learning pattern information, or using a calendar showing the meeting or class schedule, so that the guidance can be timed to be delivered during or near the end of a class or meeting.

[0326] User Requirements Insights User needs insights can include receiving input from the user (e.g., via a smartphone app) to support decision-making regarding urgent diabetes decisions, such as "How much insulin should I bolus before this meal?" or "Should I have a snack before cycling?". For example, a personalized guidance response could include interactive recommendations (e.g., "Deliver 4 units of insulin") and, if necessary, a set of factors to be used in the decision (e.g., "Some pasta contains 40g of carbohydrates, post-lunch activity level is usually moderate, and current blood glucose is normal but low"). In some cases, if assumptions need to be changed, the factors can be adjusted by the user (e.g., to reach a different dose).

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

[0328] In some cases, the system can receive user requests for decision-making support regarding future activities (e.g., exercise, driving, eating, or sleeping), and the system can provide suggested treatment adjustments or preparatory steps as guidance. For example, the guidance could include changing basal insulin, calculating bolus insulin, and the recommended amount of snacks (e.g., changing basal insulin by x before starting exercise, or consuming 15 grams of carbohydrates before going to bed). In some cases, the system (e.g., a model) can learn from the results of the guidance and make individual-specific adjustments; for example, the system can learn how much exercise changes glucose. In some cases, patient-specific information, such as basal rates or insulin-to-carbohydrate ratios for specific meals or time periods, can be entered into an electronic medical record (EMR) system by a clinician and retrieved and used by the system to notify or educate the model or to help develop responses to patient requests for guidance.

[0329] In one example, the system can receive user requests for pre-sleep guidance. These requests can be received, for example, via a decision support smartphone app. The system can provide guidance on one or more actions that the user should take or consider before going to sleep, such as eating a snack, taking an insulin dose, setting an alarm clock, or setting a continuous glucose monitor alert. The system can also provide risk explanations or reasons for the guidance. For example, the system can inform the user of the risk of “slow 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 estimates to be too high for a given meal or set of circumstances, or the risk of low or high glucose levels based on trend analysis. In some examples, the system can inform the user of a time or time range in which problems may occur, such as “low glucose levels may occur around midnight.” In some examples, the system can suggest that the user review the guidance later (for example, review the latest guidance in a decision support app on a smartphone), which may occur if the system determines that additional information (e.g., additional CGM trend data) could be particularly helpful in determining the guidance, improving the reliability of the guidance, or determining anticipated events.

[0330] In one example, a user may provide a photo of an upcoming meal or scan a restaurant menu, and the system may provide guidance on the estimated effect on recommendations for blood glucose or insulin administration. For example, a mobile device (e.g., smartphone) application may be configured to scan a menu and convert meal items into estimated blood glucose effects. In one example, the user may be prompted to position the smart device camera over the menu, and the glucose information for the menu items may be presented on the user interface, for example, next to the menu items the user sees on the screen. This can be achieved, for example, using text recognition and a lookup table of glucose values ​​for a specific type of meal or establishment. In some examples, meals considered “healthy” or “unhealthy” may be highlighted, indicated by text or symbols, identified in the user interface, or, for example, using augmented reality (AR) where the menu is subject to enhancement. In some examples, the predicted blood glucose effect or fluctuation (e.g., “72g carbohydrates” or “BG>200”) or the required insulin bolus (e.g., 6 units) may be presented. In some examples, a predictive trend graph or summary metric such as blood glucose load may be presented. In some examples, predicted excursions can be personalized by learning from historical data or by profiling the patient and incorporating such information into a physiological model as needed, so that the effect on glucose is personalized for the patient. 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 input (e.g., entered into a smartphone app), expected results such as a glucose profile can be predicted (e.g., by applying the workout as input to a model) and displayed in a user interface. The results may be provided as a probabilistic cone to give the user information about a potential range of glycemic responses.

[0331] In some examples, guidance may include bolus recommendations that reflect a decision tree, for example, one bolus number that assumes the user will exercise as planned and a second bolus number that assumes the exercise will not be completed. In some examples, guidance may include the amount of insulin onboard, which may be the amount of insulin determined to be the activity in the body, as determined by a predefined algorithm (e.g., based on population-based or theoretical data) or by a model (in which case insulin onboard may be patient-specific). Guidance on insulin onboard may be provided at the user's request or in response to events such as a determination that insulin onboard is likely to cause low glucose levels or that the amount of insulin onboard may be insufficient to control glucose levels (i.e., high glucose levels may occur). In some examples, guidance may reflect predefined or user-defined goals, such as a predefined blood glucose range (e.g., a 70-150 mg / dL range) or a percentage of time when glucose levels are within a defined range (e.g., 80% of the 70-150 mg / dL range). For example, guidance may include suggested changes to motivate the user toward their goals (e.g., afternoon exercise or changes in insulin dosage).

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

[0333] Regular insights Regular insights can also be provided as guidance. For example, guidance can be provided according to a regular schedule, such as weekly updates, or when it is determined that sufficient data is available to provide reliable summaries, such as 10 low-carbohydrate breakfasts versus 10 high-carbohydrate breakfasts, to provide comparative analysis, averages, graphs, probability zones, or other information regarding diabetes management. In one example, meals or foods may be grouped by type that have similar glycemic responses in terms of size and time course ("spike vs. slow"). In another example, meals or foods may be grouped by similar insulin administration strategies, such as which meals require a corrective bolus. In yet another example, the decision support engine can summarize types of decisions that lead to unreliable outcomes in a way that facilitates education ("the idea of ​​low-carbohydrate breakfasts") or medical review (e.g., inquiries to physicians about management strategies). The decision support engine can compile summaries of such information (e.g., problematic meals) in anticipation of a physician's consultation, including successes and concerns.

[0334] In some cases, decision support engines 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 levels, or their interest in or availability of glucose level management, or in the patient's goals or thresholds for notification. In some cases, periodic insights can be presented in a differentiated manner based on the schedule; for example, weekend trends and weekday trends can be presented separately. Guidance can also include suggestions for different treatments or actions for different parts of a person's schedule; for example, different underlying patterns can be suggested based on knowledge of the schedule. In various examples, the schedule is learned by a model notified by the patient's or caregiver's calendar based on user input via a user interface (e.g., answering questions on a smartphone), or a combination thereof.

[0335] The various examples of insights described above can be transformed into different types of insights. For example, an example described as an event-driven insight can be provided as a user requirements insight, and a user requirements 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 the insight as guidance.

[0336] While "real-time" doesn't necessarily mean immediate, it allows interventions to influence short-term outcomes based on recent data or trends, as opposed to retrospective information presented to assess overall behavioral or treatment improvement opportunities. Input and model interaction

[0337] Figure 2A is a diagram of an exemplary configuration of 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 a true glucose level 160 which can be measured by sensor 152. The physiological model 112, behavioral model 114, and 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 guidance for patient 102 as well as the time to determine or deliver the guidance. The guidance may be delivered via guidance module 150.

[0338] The sensor system 152 can measure physiological parameters such as glucose level, activity, heart rate, respiration, or body temperature, or contextual parameters such as ambient temperature, pressure, or location. The sensor system 150 may include multiple sensors integrated into a single device (e.g., a watch) or a group of multi-sensor devices (e.g., a watch and wearable sensors), or the sensors may reside 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 the “sensor system”. The sensor system 152 may include a continuous glucose monitor (provided in more detail below) which can be configured to measure glucose levels that are calculated to indicate a true glucose level 160.

[0339] Data from the sensor system 152 can be provided as input to the physiological model 112 or the behavioral model 114, or both. The physiological model 112 can also receive input from the patient 102, input from the measurement model 154 (described below), input from the behavioral model 112 (such as activity or stress levels), 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 relation to Figure 2B, and numerous inputs are shown and described in Figures 14-16. Physiological models can provide physiological status information as output, such as current or predicted glucose levels or trends, insulin-to-carbohydrate ratio (ICR), insulin sensitivity coefficient (ISF), basal rate, or insulin onboard (IOB), all of which may influence true glucose levels, as well as decisions or recommendations for insulin delivery made by guidance modules, patients, caregivers, or clinicians.

[0340] The physiological model 112 or the behavioral model 114 can also receive information received from the patient, such as calendar information from a computer system like a smartphone, user input regarding specific activities or exercise, or user input regarding food consumed. The behavioral model can also receive guidance information delivered to the patient, as well as sensor data, as input. The behavioral model can also receive 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 may include, for example, exercise, sleep, potential for intervention, interest in receiving guidance, and other information regarding the patient's activities, interests, or behaviors. The behavioral model can also receive contextual information or determine current or predicted contextual information as a state (e.g., during a meeting or while driving home), which can be used to determine the timing of guidance or guidance delivery. A detailed description of the inputs and outputs of the behavioral model is provided below in relation to Figure 2B, and numerous inputs are shown and explained in Figures 14-16. A measurement model 154 may be included in the system as needed. Data from the sensor system 152 can be provided to a measurement model 154, which can process the sensor data to evaluate the accuracy and precision of the data, for example, to determine the likelihood that the measured glucose level matches the true glucose level. The sensor system can use statistical methods, such as the variability or variance of sensor data points, trend information, historical information, and behavioral models, physiological models, and other information provided by the sensor, to assess whether one or more sensor data points are likely to be accurate or inaccurate. For example, if consecutive blood glucose data differ significantly or if a pattern emerges that does not reflect a normal physiological pattern (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 that falls outside the range of estimates.For example, if an ambient temperature of -5°C is detected in July, the model may conclude that the sensor reading is inaccurate, especially if location information is available. In other examples, activity information can be processed, including correlating aspects of a measurement model with aspects of a behavioral model, to determine the correlation with likely actual activity. For example, accelerometer information can be processed to assess whether movement is excessively rhythmic (which may indicate mechanical movement, such as bumpy riding, as opposed to physical movement) or out of range (e.g., a relatively sedentary person who is active for 3 hours). Outputs from the measurement model (e.g., accuracy state information) may be provided to a behavioral model 114 or a physiological model 112 to be integrated with other information to determine a physiological or behavioral state.

[0341] The guidance module 150 can deliver guidance information to the patient 102, for example, via a user interface on a mobile device such as a smartphone. In some examples, the guidance module 150 can determine guidance based on information (e.g., state) provided by a physiological model 112 and a behavioral 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 behavioral model 114, and the guidance module 150 may provide the determined guidance at the determined time. In various examples, the guidance module 150 may reside, for example, on a mobile device 108, or it may reside on a computer system that is remote or local from the patient and can deliver guidance to the patient via a user interface on the mobile device 108 or other device.

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

[0343] Physiological models Food consumption can be provided as input to the physiological model 112. Food consumption information may include information about meals, snacks, and beverages, such as size, content (carbohydrates, fat, protein), order of consumption, and time of consumption. Food consumption can be provided by the user manually entering it, by providing a photograph in an application configured to recognize the type and quantity of food, or by scanning a barcode or menu. In various examples, the size of a meal can be manually entered as calories, quantity ("3 cookies"), menu item ("Royal with cheese"), 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 Figures 25A and 25B, the user interface user 2500 may allow the user to be instructed by touching the amount of fat and carbohydrates (and protein, if necessary) in a graph 2502 (or other graphical user interface element) for each meal. Figure 25A shows selected point 2504 on graph 2502 with high carbohydrate (78 grams) and low fat (1.6 grams) content. Figure 25B shows selected point 2506 on graph 2502 with high carbohydrate (78 grams) and low fat (1.6 grams) content. Figure 25B shows selected point 2506 on graph 2502 with low carbohydrate (3 grams) and relatively high fat (20 grams) content. Examples of meals with similar nutritional content (e.g., carbohydrate-to-fat ratio) can be displayed in the user interface.

[0344] Activity can also be provided as input to a physiological model. Activity information may be provided, for example, by accelerometer sensors on wearable devices such as watches, fitness trackers, or patches.

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

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

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

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

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

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

[0351] In some examples, model inputs can be inferred from, for example, one or more historical user inputs (e.g., a meal diary), geolocation information, insulin administration, CGM function (blood glucose elevation), or time. In some examples, the model can operate in 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 associated with specific meals or types of meals or activities, 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. Metabolic rate can include basal metabolic rate (e.g., energy consumed at rest), as well as active metabolism, e.g., energy consumed by activity, exercise, or physical activity. In some examples, basal metabolic rate and active metabolism can be tracked as separate states. Activity level can also be determined based on, for example, activity sensors or other physiological sensors. Activity level states can include, for example, four states: sleep, rest, activity, and exercise. Insulin sensitivity can be determined using historical data, real-time data, or a combination thereof, and can be based on, for example, food consumption, insulin delivery, and the resulting glucose levels. Insulin onboarding can be determined using insulin delivery information and a known or learned (e.g., from patient data) insulin time-action profile that can take into account both basal metabolic rate (insulin renewal to maintain bodily function) and insulin usage driven by activity and food consumption. Dietary state can include, for example, fasting, pre-meal, during a meal, post-meal response, or stable state. Dietary status may also include onboard nutrition, such as meals, snacks, or beverages consumed, and can be determined from, for example, food consumption information, meal timing information, and digestibility information associated with the type, quantity, and order of foods (e.g., which food / beverage was eaten first). Health and illness may be determined from physiological sensors (e.g., temperature), activity sensors, or a combination thereof, based on, for example, user input (e.g., pregnancy information or known illness information). Exemplary health states may include, for example, health, illness, rest, and fatigue. Glucose levels may be determined from sensor information (e.g., CGM data), in combination with the status of the measurement model as needed. In some examples, if CGM data is unavailable or its reliability is uncertain, the glucose level status may also be determined from the model, given a combination of, for example, food consumption, insulin, and activity, based on historical information about glucose levels in a particular situation.The degree of blood glucose control (not shown) can also be determined as a state, and can be based, for example, on glucose levels, glucose level fluctuations, or insulin administration patterns. Confidence levels can be applied to one or more states (e.g., high, medium, low, or numerical confidence).

[0353] In some cases, transitions between states can be critical decision points for determining guidance, or times to determine or deliver guidance. For example, a user may need guidance specifically during transitions between states. For instance, guidance may be needed while waiting for a glucose response after a meal, or when deciding 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 when to determine or deliver guidance. Examples of these state transitions may include active → rest → exercise → sleep, or healthy → sick → rest → fatigue, or changes in the degree of glycemic control (e.g., changes in glucose levels, changes in insulin sensitivity, changes in insulin dosage), or transitions to pregnancy. In some cases, the physiological model 112 also includes disease stages, such as in patients with type II diabetes. Examples of disease stages in patients with type II diabetes may include the prediabetic stage, the oral therapy stage, and the basal insulin therapy stage. The insights provided by the decision support engine may differ depending on the host at different disease stages, as described herein, for example.

[0354] Modeling of kinetic and potential energy flows For example, the physiological model 112 can characterize the energy flow in the human body, including the effects of diet, exercise, glucose and insulin, as well as other hormones such as cortisol and adrenaline. Energy inputs may include meals 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 counteract hypoglycemia). Energy outputs may include energy expenditure from activities such as exercise, glycogen replacement by muscles or the liver, and glucose uptake driven by insulin. The insulin time-action profile may take into account not only the distinct effects of basal (e.g., resting) metabolism and activity metabolism (e.g., by activity / exercise). Model 112 may be tailored to the subject's physiology using user input, measurements (e.g., CGM patterns and fitness tracker or accelerometer), and inference, e.g., learning patterns and associations from data.

[0355] At a high level, physiological models can track energy inputs and outputs and determine one or more physiological states. This aspect of the physiological model's energy properties can be used to predict future blood glucose states (e.g., high glucose levels, low glucose levels, upward glucose trends, downward glucose trends). Physiological models can also interact with behavioral models and guidance modules (such as decision-making support apps) to determine when users need context-specific guidance (advice, warnings, alerts, etc.), such as transitions from rest to exercise or from health to illness.

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

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

[0358] The behavioral model state may also include risk tolerance (e.g., comfort with a tendency towards hypoglycemia, which may depend on experience with intervention or the possibility of caregiver intervention), interest in guidance, activity status (e.g., whether exercising, which can be inferred from a calendar or activity sensor), sleep status (e.g., sleep, rest, or wakefulness, inferred from activity sensors, a calendar, or other information), and appetite (e.g., inferred from eating patterns).

[0359] Involvement (or level of involvement) can also be determined as a state in a behavioral model. For example, involvement factors can include a user's response to decision support in terms of time, activity, and type of support (user-requested, context-generating, routine). Involvement states can include, for example, types of guidance that tend to prompt action, and actions in which the user participates, which may correlate with time (e.g., cannot walk from 9 to 5) and activity (e.g., no blood glucose test that requires finger pricking during execution). Involvement level states can also reflect the amount of time a user is engaged in receiving or following guidance (e.g., if a short time suggests guidance was ignored). Involvement states can also include types of communication that can be associated with an activity or schedule, such as learning the appropriate mode of interaction with the user depending on the time and place. For example, a user might receive display messages on a clock or phone during a meeting, voice messages in a car, and hierarchical messages based on urgency while sleeping, with urgent messages accompanied by sound and vibration, and less urgent messages displayed silently on a display or clock. In some examples, the involvement level logic and schemes applied above can also be applied to caregivers (such as data followers of smart devices) to notify them of the need for intervention or to inform the patient or other caregivers that they are aware of or in control of the situation.

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

[0361] The concern level can be based on the duration of the user's concern (e.g., time, duration after a meal, duration after exercise, or time derived from a specific day of the week or month, or from a calendar event such as a holiday or school event). The duration can also be applied to caregivers (such as data followers). The concern level related to the duration can be derived from user input or learned from user behavior. The concern level can also reflect the user's goals, for example, the user's concern level regarding alarms and low noises, or one focused on maximizing the duration within a range, or both.

[0362] Behavioral models may also include induction states, such as an insulin induction state (e.g., delivering X units of insulin or increasing or decreasing the basal rate) and a carbohydrate consumption induction state (e.g., eating X grams of carbohydrates).

[0363] In some cases, the generation of guidance messages or other information for patients can be done as part of a behavioral model (for example, as an output state from the model). For clarity and simplicity, guidance generation will be discussed separately below.

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

[0365] A CGM measurement model can add context to glucose values ​​and patterns generated from sensor data. The model can accommodate various data types. For example, confidence limits can be determined for data values ​​or datasets. Confidence limits can be presented to the user or provided as input to other models. The model can provide, for example, precise boundaries to adjust on usage days (e.g., newly implanted and aged sensors, which can be inaccurate), adherence to calibration schedules, the impact of delays at high rates of change (both due to physiological delays in the movement of glucose levels in interstitial fluid), and sensor delays due to sensors only taking measurements regularly, for example, every 5 minutes. The measurement model can also monitor the consistency between blood glucose and CGM measurements as an indicator of the reliability of blood glucose, CGM, or both. Similar principles can be applied to other data sources to evaluate accuracy, consistency, or variability.

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

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

[0368] study In some cases, the system can enter a “learning mode” in which it observes physiological or behavioral data. For example, the system can collect CGM values, blood glucose measurements, insulin dosage, meals, activity, medication, stress levels, sleep patterns, hormonal cycles, location (via GPS, etc.), and other information to build a set of information from which patterns can be estimated. The system can determine, for example, the basal dose, insulin sensitivity, insulin-to-carbohydrate ratio, insulin duration, or bolus for commonly used meals. In one example, the protocol may be followed by collaboration with patient involvement, which may include trackers such as carbohydrate intake and insulin administration. The resulting glucose levels or trends can be determined for the patient, especially if the patient is newly diagnosed or treated. Since some factors, such as insulin sensitivity, change throughout the day, in some cases the protocol can be tracked several times at different times of the day to obtain a correlation between the desired parameter (such as insulin sensitivity) and the time of day. 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 baseline trial, the user is asked to select a day when their BG is within a specified range (e.g., between 80 and 250), plan to skip meals, manage their diet so that the previous meal is not high in fat or very high in carbohydrates, and avoid exercise or other activities that could affect blood glucose levels. The system can receive input from the user to start the baseline trial. The system can then assess blood glucose levels for a certain period (e.g., 3 hours) after the last meal. If blood glucose levels remain stable for a certain period, the system can declare the baseline rate correct. If there is a period during which BG is increasing or decreasing, the baseline rate affecting that period can be changed in small, safe increments until blood glucose stabilizes for the entire period. In some examples, this process can be repeated until a full 24 hours (or longer, e.g., a week) is covered in a successful baseline trial.

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

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

[0372] In some cases, the baseline rate is determined first to enable accurate estimation of ISF and ICR. In some cases, the decision support system can determine an appropriate timeframe for determining the baseline rate, ISF, or ICR, instead of requiring patient involvement or cooperation, or in addition to that.

[0373] The system can integrate various states and learn their interrelationships. For example, it can track exercise intensity and duration, glucose levels, and insulin dosage to learn how exercise affects glucose sensitivity. The determined glucose sensitivity can be provided as guidance or used as input to algorithms to determine other states or guidance. The system can also refer to or build nutrition databases and link them to patients (e.g., tracking how patients respond to specific diets or types of food). 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 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 releasing cortisol in response to stress, which constitutes the body's insulin resistance).

[0374] For example, the system can learn when patients make treatment decisions and how patients and caregivers (e.g., smartphone data followers) track the outcome of those decisions. The system can then predict when patients are likely to make similar decisions and what information would help them make those decisions, providing such information as guidance. The system can also predict desirable outcomes and provide confirmation notifications (e.g., "Well done! Post-breakfast peak was 140 mg / dL and is now stable and within range") or recognize that the desired outcome has not been achieved (e.g., "Still 220 mg / dL after a 3-unit bolus at 7am and is rising").

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

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

[0377] In some cases, state transitions can be detected using a model and used to generate guidance or notifications to the patient. Some physiological state transitions (e.g., sick / healthy) may occur over periods of several days or weeks, while others may occur in hours or minutes (e.g., glucose levels or trends). In some cases, guidance can be delivered when state transition conditions are met. For example, if a patient has a tendency toward low glucose levels and is determined to be likely to transition to an exercise state or to exercise soon (e.g., using patterns or based on the location of a park or gym), the guidance may give a recommendation to consume some carbohydrates. In some cases, a combination of state transitions can trigger guidance (e.g., transition from normal glucose to low glucose and transition from sedentary to active / exercising state).

[0378] The probability of a state transition can be used to determine whether or not to provide guidance, and when to provide it. For example, guidance may be determined and provided when a probability of transitioning to an undesirable state is detected. In some examples, guidance may only be determined and provided if one or more additional conditions are met, such as when the availability state or concern level state 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 is calculated to be likely to occur. For example, guidance may be delivered when both glucose and exercise states meet specified conditions, for instance, when a low glucose state is present or likely, and when the patient is about to exercise or has finished exercising. In some examples, the system determines messaging frequency to provide insights or guidance based on state conditions such as the host's engagement status.

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

[0381] Example of guidance In various cases, guidance is determined at least partially on time. For example, guidance decisions can be based on clock time or time zones (e.g., morning, afternoon, evening, night). Insulin sensitivity tends to change based on several overlapping time functions. 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. Guidance decisions can be at least partially on time to account for time-varying insulin sensitivity. Guidance decisions can also change over time based on patient behavior, such as exercise routines, daily eating habits, and meal schedules. Other physiological parameters (e.g., adrenaline-inducing events such as stress, alcohol consumption, heat exposure, and sports competition) can also be time-dependent.

[0382] In various cases, the determined guidance may include guidance on how to respond to specific situations (e.g., detected or predicted hypoglycemic events or hyperglycemic excursions), or more general guidance on treatment or behavior (e.g., the rate of change in insulin relative to carbohydrates for a specific meal (e.g., lunch) or exercise within a specific time frame (e.g., "consider improving insulin sensitivity by taking a brisk walk after breakfast").

[0383] In some examples, information determined from physiological or behavioral models can be used to suggest alternative approaches to common patterns. For example, the system may determine that a user tends to overcompensate or undercompensate in certain situations, such as after a particular time or meal, and guidance can be provided when the system detects patterns associated with the compensation errors. In some cases, the system may simulate what would happen with an alternative therapy approach or compare it to a historical approach. For example, an alternative approach can be provided as guidance after an overcompensation or undercompensation has occurred. In other examples, predictive trends can be presented for a proposed behavior. For example, a user can input a proposed insulin dose or snack or meal via a user interface, and the system can display predictive trends. In the example shown in Figure 27A, the user may be presented with a user interface 2702 that includes a scroll dial 2704 that allows selection of a carbohydrate amount, and the system can present predictive trends 2706 showing possible outcomes from a snack containing the selected amount of carbohydrates. In other examples, as shown in Figure 27B, the user can input a proposed carbohydrate value and a proposed insulin dose, and the system can present a user interface 2720 showing three curves: one curve 2708 for the scenario where carbohydrates are ingested but insulin is not administered; one curve 2710 for the scenario where insulin is administered but carbohydrates are not ingested; and an estimated glucose value curve 2712 for the case where both glucose and insulin are administered. In some examples, the dial shown in Figure 27A can be provided on the user interface 2720 shown in Figure 27B. The predicted insulin trend is shown as a line, but in other examples, a probability cone may be shown instead of a line.

[0384] In some cases, the system can provide guidance on nighttime readiness levels to prevent users from having low glucose levels at night, reduce nighttime alerts, decrease nighttime hypoglycemic events, and provide users with comfort at night. To develop long-range (e.g., 6-10 hours) or reliable predictions regarding states or state transitions, the system can acquire more information from the patient or sensors or perform additional processing to increase the likelihood that the guidance will allow for a full night's sleep without interruption to eat or deliver insulin. Nighttime readiness features can provide guidance on taking action before bed, such as consuming carbohydrates or administering insulin before going to sleep.

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

[0386] In some examples, a decision support system may include a diabetes manager who can be configured to provide overall guidance or feedback. The diabetes manager may, for example, quantify overall diabetes management. This could include metrics of effectiveness in controlling estimated blood glucose levels measured against criteria such as specified conditions, standards, or time (e.g., percentage) within a specified blood glucose range.

[0387] Treatment parameters Decision support systems can also provide guidance on treatment parameters. For example, a system can identify when changes to basal rates, ICR, ISF, or IOB are necessary. The system can also request trials if, for example, the type or amount of necessary change cannot be identified within specified metrics (such as confidence levels). Real-world data can present the following challenges in determining treatment parameters: Theoretically, if the basal rate is correct and the ISF is known (or assumed to have known relationships with other treatment parameters), the bolus can be determined with acceptable precision. Similarly, if the ICR and ISF are correct and carbohydrate estimates are assumed to be accurate (at least on average), the basal rate can be fine-tuned within acceptable limits. However, real-world conditions can be filled with uncertainty, complexity, and overlapping elements, and errors can exist in all parameters, making the above ideal scenarios rare or difficult to recognize. To address this systematic complexity, decision support systems may include models or algorithms that learn or detect inappropriate specific basal rates, ICR, ISF, or insulin onboarding periods from collected data. In some cases, parameters can be determined retrospectively from data over several days or weeks, and the determined parameters can be evaluated for accuracy as additional data is collected. Decision support systems can also use models or algorithms and learned parameters or historical data in combination with real-time or recent data to generate guidance and calculate the time to deliver that guidance.

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

[0389] Decision support systems can consider whether low or high glucose levels occur with different amounts of carbohydrates, correction factors, or initial glucose levels. In one example, if glucose levels are within the pre-meal range (e.g., without an onboard correction bolus) but outside the range after a meal, the error may be due to an inappropriate ICR. In some cases, glucose trends of meals with different characteristics can be compared to verify or improve the inaccuracies detected in the ICR. For example, if collecting patterns of low-trending glucose levels reveals that the higher the amount of carbohydrates, the faster the trend in glucose levels becomes or the lower the glucose levels become, it can be inferred that the ICR is likely too high (i.e., excessive insulin is delivered due to the high ICR, and the effects of the high ICR are amplified as the amount of carbohydrates increases, resulting in a faster low-glucose trend or lower glucose levels). Similarly, if collecting patterns of high-glucose-tendency glucose levels reveals that a higher carbohydrate count is associated with faster or higher glucose levels, it can be inferred that the high-glucose trend is likely due to a low ICR (i.e., insufficient insulin delivery leads to high glucose levels, and this effect is amplified as the carbohydrate count increases).

[0390] Insulin sensitivity factors In other examples, decision support systems can provide guidance regarding insulin sensitivity. For instance, the system can track and report insulin sensitivity or changes or trends in insulin sensitivity. Decision support systems can also provide fault detection (further described below) to help users determine whether a problem is caused by a treatment parameter or a system failure (e.g., to distinguish insulin sensitivity issues from hardware failure issues). 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 well controlled by estimating and using "treatment" parameters such as basal rate, ICR, ISF, and insulin time action. However, stress, illness, changes in exercise activity, hormonal cycles, etc., can cause changes in insulin sensitivity, alter the effects of insulin in the body, and may 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, with noisy data containing multiple overlapping influences, a 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 corrected bolus, even if no underlying error or ICR error is detected. For instance, the system can identify an inappropriate ISF from a pattern of low (or high) glucose levels after a corrected bolus that does not respond to a meal error. In another example, if glucose levels are low (or high) after a meal using a corrected bolus, and no glucose fluctuation is present after a meal without a corrected bolus, the system can determine that this is likely due to an inappropriate ISF.

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

[0392] Fault detection Furthermore, system “failures” such as problems with insulin delivery (e.g., injection site problems) or sensor problems can cause unexpected changes in glucose patterns. Decision support systems can identify failures using models or algorithms based on patterns of glucose or other data. Identifying the onset and termination of such failure conditions can help patients and their physicians take appropriate action to keep glucose levels within acceptable limits and avoid changes in other factors (such as ISF) to address blood glucose fluctuations in the event of unrecognized system failures causing glucose control problems.

[0393] In some cases, decision support systems can identify instances of recurring low, high, or out-of-range values ​​that are not definitively attributable to the ICR, baseline rate, or ISF, and that do not prompt a “test” of the baseline, ICR, or ISF, and can provide additional data with less overlapping influence to more accurately estimate parameterization issues.

[0394] Setting the basal rate of the insulin pump In some cases, decision support systems can assist in setting and fine-tuning the basal rate of an insulin pump. Basal rates can vary significantly throughout the day. For example, a relatively high basal rate may be needed in the early morning, while a lower basal rate may be needed in the afternoon. Some insulin pumps allow for setting different basal rates every 30 minutes, making 48 basal rate parameters possible per day. Initializing these parameters can be very time-consuming, and there can be a lot of uncertainty in the first dose. Without appropriate basal rates, estimating ICR and ISF parameters and learning these parameters retrospectively is extremely difficult. Continuous glucose monitoring (CGM) data can be particularly helpful when fine-tuning basal rate parameters, as consecutive measurements can help identify the exact times when different basal rates are needed. In some cases, systems can use CGM data or blood glucose patterns to determine basal rate adjustments.

[0395] In various applications, decision support systems can combine CGM data with other data to determine or refine bolus rates. For example, a decision support system can evaluate estimated glucose levels received from a CGM sensor during the night or periods when other factors are not affecting glucose levels determined from sensor or behavioral data to determine guidance for adjusting one or more basal rates. Nighttime decisions can be more accurate or easier to make because the issue of basal rate adjustment is not complicated by diet or physical activity. In some applications, decision support systems guide patients through testing protocols that limit the number of variables that may affect glucose levels (e.g., limiting or adjusting exercise, stress, and carbohydrate consumption), enabling accurate determination of basal rates.

[0396] Multiple daily injections In some cases, decision support systems can determine guidance for multiple daily insulin injections. The body's insulin requirements can fluctuate significantly throughout the day. For example, the secretion of hormones that affect hepatic glucose secretion (e.g., glucagon secretion by the pancreas), and the secretion of hormones that increase insulin resistance (decreasing insulin sensitivity), can cause fluctuations in insulin requirements. For instance, a pattern known as the dawn phenomenon tends to raise morning insulin levels. This can be caused, for example, by the secretion of growth hormone or other hormones that raise blood glucose levels, dietary issues, or the body's response to nocturnal hypoglycemia (the Somogyi effect). While these effects can be present in any patient, they can be particularly challenging for patients using multiple daily insulin injections (MDIs) because there are limits to the number of times insulin can be injected per day and a practical lower limit to 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 using multiple daily insulin injections (MDIs) can use long-acting or intermediate-acting insulin injections for more than a day to provide background insulin for 24 hours. The timing and dosage of intermediate- or long-acting insulin vary depending on the type and size of the insulin, as well as the insulin's action (how quickly insulin starts acting), peak, and duration of action. Long-acting insulins (such as insulin glargine or insulin measurement) can provide a relatively stable insulin flow and a consistent absorption pattern. Intermediate-acting insulins can provide peak and intermediate durations of action and can help address patterns in 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 4 to 8 hours after injection (i.e., more insulin is in the bloodstream) and less effective 16 to 24 hours after injection.

[0398] Intermediate-acting insulins such as NPH can help counteract the daytime phenomenon. It is important to time the delivery of NPH to match its peak action to the underlying needs at peak time. Furthermore, when using intermediate-acting insulin, it may be important to avoid low levels at specific times (e.g., when insulin action is at its peak) by eating at specific times or scheduling meals accordingly. Managing glucose levels can be even more complex because some insulins have different absorption rates from day to day or may produce unpredictable peaks.

[0399] Combining various forms of long-acting or intermediate-acting insulin can simulate the body's basal insulin secretion pattern (for example, when diabetes is absent). For instance, combining NPH with glargine or detemir once daily at night at a low dose to better match the body's basic requirements may be useful. However, the insulin coverage provided by intermediate-acting or long-acting insulin, or combinations thereof, often does not adequately match the body's basal insulin needs, so fine-tuning and careful timing of insulin delivery and meals may be crucial. Responding to daily fluctuations may also be important.

[0400] Decision support systems can provide guidance in determining insulin administration and timing to address recognized patterns (e.g., the dawn phenomenon). The system can also provide guidance in addressing daily variations. For example, retrospective data might detect one or more patterns suggesting that multiple daily injection regimens are not adequately meeting a person's basal insulin needs. This information may be provided to the patient, to the clinician recommending a change in dosage or regimen, or to prescribe a different type or brand of insulin. In some cases, decision support systems can act as a communication tool between patients and clinicians, enabling clinicians to better understand insulin and glucose patterns (for example, the system could provide guidance that a patient feels lower on weekend mornings when breakfast tends to be later).

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

[0402] In some cases, decision support systems can identify specific phenomena of interest, such as the dawn phenomenon or the Somogyi phenomenon. In some cases, the decision support system can suggest adjustments or referrals to a physician. For example, the Somogyi phenomenon can be addressed by lowering the basal insulin dose, and the dawn phenomenon can be addressed by using NPH insulin that peaks in the morning or by using rapid-acting insulin in the morning.

[0403] In some cases, decision support systems can identify when basic needs are not adequately met by any combination of MDI therapy. In some cases, decision support systems can provide indicators of the success of basic therapy. For example, a decision support system can assess whether stable blood glucose levels are achieved during sleep (e.g., a change of less than 30 mg / dl, assuming no complex factors are present, such as the patient not eating, taking rapid-acting insulin, or exercising shortly before sleep).

[0404] The decision support system can also determine when a single basal injection is insufficient (based on glucose levels and injection timing) and provide guidance to consider additional injections (e.g., injecting basal insulin twice daily to achieve a "two-wave" pattern of insulin action) or introducing other types of insulin (e.g., adding intermediate-acting insulin) (e.g., consulting a clinician). The decision support system may include a basal testing function (e.g., an application that can operate on a smart device) that can identify when a basal testing is necessary or recommended. A basal testing may include, for example, periods of relative inactivity and fasting or highly predictable or controlled diets to clarify the basal needs. In some examples, the system may also provide guidance on how behaviors can match the basal requirements, such as combinations of basal injections, or injections combined with meals, or exercise.

[0405] Predicting future blood sugar levels In some cases, decision support systems can predict blood glucose levels in advance for a specified period (e.g., 30 minutes, several hours, or 6 hours). Blood glucose predictions can be based, for example, on dietary information (e.g., amount consumed, time of consumption, carbohydrate and fat or protein content, absorption rate (fast, moderate, slow carbohydrates), reliability of food estimates), bolus information (time, insulin action, and bolus type (normal or dual wave), basal rate, exercise, CGM data, blood glucose levels (e.g., fingerstick data), alcohol consumption, stressors (e.g., behavioral or calendar-based), or time of day.

[0406] The decision support system can predict blood glucose levels in real time and provide advance notification before potential hypoglycemic or hyperglycemic events 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 for administering a corrective bolus before a hyperglycemic event occurs or before the patient becomes insulin-resistant due to high glucose levels.

[0407] Decision support systems can also retrospectively or hypothetically determine predicted glucose levels to evaluate treatment or model parameters (to ensure model parameters are stable). In some examples, the system can evaluate model parameters by comparing predicted values ​​to actual values.

[0408] In some cases, if the system has high confidence in the model (e.g., if the model parameters have been validated or evaluated for accuracy), it can use the model to test scenarios and predictive outcomes to assess whether the patient or clinician should consider adjusting therapeutic parameters such as the insulin-to-carbohydrate ratio or insulin sensitivity coefficient. For example, the system can run various “tests” against the model, which are burdensome or time-consuming tasks for the patient to actually perform (because they require strict control over food, activity, or insulin delivery), and the results of the tests can be used to determine guidance or the timing of guidance, or to select one or more tests that the patient should actually perform (e.g., delivering guidance such as “Insulin-to-carbohydrate ratio may be incorrect: Test with your next meal” or “Basal rate may be incorrect: Perform a fasting basal test as soon as possible”). In one example, if no food is consumed, the system can determine what happens (according to the model). If the predicted blood glucose level rises, a higher basal rate may be required, and if the predicted blood glucose level falls, a lower basal rate may be required. In other examples, assuming the basal rate is correct, the system can determine what happens when a meal is consumed: 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. Otherwise, the ICR may require adjustment (e.g., if the underlying basal rate is assumed to be correct, a high glucose level beyond 4 hours after a meal suggests that the ICR is too low). In other examples, assuming the basal rate is correct, the system can determine what happens when a specified amount (e.g., 1 unit) of insulin is given, and the system can use this information to suggest updating the insulin sensitivity factor. In other examples, assuming a normal absorption meal and a correct basal rate, the system can determine when the predicted glucose level will reach a stable value, and use this to determine the duration of insulin onboarding.In some cases, decision support systems can use models to predict recurring low or high glucose levels (for example, using time based on patterns observed over time). In some cases, decision support systems can use models to identify the Somogyi phenomenon or the dawn phenomenon.

[0409] Bolas's decision Decision support systems can develop guidance for insulin bolus delivery. For example, the system may also include a model or curve-based corrected 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, insulin dosage, and duration. In some examples, the decision support system may first collect data for curve estimation through a learning period. The decision support system can use the curve estimation in real time to predict deviations from the meal curve estimation. Predicted deviations from the 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. Deviations caused by exercise or other factors can also be taken into account and corrected. In some examples, a similar approach can be applied to a blood glucose prediction model, where the guidance is based on deviations from the model rather than deviations from the curve. For example, deviations from the output expected by the model may indicate that an input parameter (e.g., meal size) was incorrect and that appropriate correction (e.g., reestimation of meal size or delivery of a corrected bolus) is needed. Any detected deviations may be provided as guidance, or additionally or alternatively, improvement steps (e.g., reestimation of meal size or delivery of a corrective bolus) may be suggested as guidance.

[0410] motion Exercise can have an immediate (e.g., almost immediate) effect on blood glucose levels, and can have an effect for up to 48 hours after exercise is completed. Decision support systems can provide recommendations on what to do before, during, or after exercise. For example, a decision support system can provide guidance on therapeutic parameters to explain the effects of exercise. Decision support systems can also retrospectively learn and improve exercise recommendations. In one example, the system could receive an exercise plan from a user (e.g., a patient) that includes the type of exercise to be performed, the intensity of the exercise, and the duration of the exercise, and the system could create and deliver guidance based on the received exercise plan. In one example, the system could provide guidance that the patient will need a snack of a certain size. If the exercise is planned in advance (e.g., communicated to the decision support system) at least one hour beforehand, the system can suggest a temporary baseline rate to explain the effects of the exercise. The system can also suggest the possibility of a temporary baseline change if the exercise lasts (or is performed) for more than one hour. Because exercise can either increase blood glucose (e.g., due to adrenaline secretion triggering 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 cases, the effects of exercise can be monitored using a continuous glucose monitor (CGM) or other sensors, and changes in treatment strategies can be learned on a case-by-case basis to improve guidance and outcomes over time (e.g., intense morning running versus leisurely afternoon cycling).

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

[0412] Example Timeline Figure 3A is a diagram of an exemplary timeline 300 related to a patient. It is assumed that the patient has performed an activity for a period of time, followed by a meal and insulin delivery. After the meal, the patient is available for a certain period, followed by a meeting, then another available period, followed by another meeting. The decision support engine can take the patient's schedule into account when deciding when and what guidance to deliver. For example, through access to the patient's calendar or by learning the patient's temporal patterns from data, the decision support engine can recognize available periods after a meal and before a meeting and deliver guidance during these available periods accordingly. The guidance can also take into account the upcoming meeting and its length to determine guidance that is calculated to avoid interruptions during the meeting. For example, the decision support engine may suggest a corrective 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 may suggest a pre-meeting snack to maintain glucose levels throughout the meeting. In some cases, the decision support engine may error in favor of allowing glucose levels to drift lower if it knows (e.g., through user-specified settings) that consuming a small snack during a meeting is easier than managing insulin (e.g., if the patient injects insulin using a needle or pen). Conversely, if it knows that administering insulin is easier than consuming a snack (e.g., if the user receives insulin via a pump), the guidance may error in favor of a high glucose tendency.

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

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

[0415] Figure 3D illustrates how a patient's availability (or convenience) to participate in an intervention is determined based on other conditions. Initially, the patient is asleep and unavailable. Once sleep ends, the patient becomes available until their commute begins (as determined by scheduling information, GPS, or connectivity via in-vehicle wireless connection). Once the commute ends, the patient becomes available until the meeting begins. Once the meeting ends, the patient becomes available again. Determining the timing of guidance

[0416] Figure 4 is a schematic diagram of the guidance decision. The guidance decision module 402 receives an input 404 and can determine one or more outputs 404 related to the guidance. The decision module 402 may include a model or pattern to which the input 404 applies. In some examples, the decision module may include or be part of a behavioral model. The input can be determined by a state output from another application or a model such as a physiological or behavioral model.

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

[0418] The urgency of the action can also be received as input. The urgency of the action can depend, for example, on the patient's physiological state, the nature of the guidance, or both. For example, the urgency of the action may be high if the user is rapidly trending towards hypoglycemia, especially in situations where the user may not be aware of the trend. The urgency of the action may be moderate if the user is trending towards hypoglycemia slowly, or towards hyperglycemia 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 needed to avoid hypoglycemia, moderate if insulin injection is needed, and low if testing (e.g., finger-prick blood glucose test, or temperature or heart rate) is needed to check the physiological state or calibrate sensors (e.g., glucose sensor calibration). High urgency in an action can favor the delivery of short-term guidance, while low urgency can favor waiting until a future availability period to avoid user fatigue or excessive interruptions to the guidance.

[0419] The length of the effective action period can also be received as input. In one example, it may be determined that carbohydrate intake is needed within a short period (e.g., a 5-minute or 10-minute period). In another example, it may be determined that insulin injection is needed within a moderate period (e.g., a 20-minute period). In some examples, the period can be a fuzzy input, and for example, the exact length of the period does not need to be precise. In some examples, the general size of the action window can be understood as reflecting the variation in the action window of the treatment or sensor input action.

[0420] The level of concern can also be received as input. The level of concern of a patient or caregiver can vary from patient / caregiver to patient / caregiver and can vary depending on the specific situation. The level of concern can 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 regarding a particular situation (e.g., a combination of physiological states) may favor shorter-term decisions and guidance delivery, while a low level of concern may favor delayed decisions and guidance delivery. Involvement can also be received as input. As mentioned above, the level of involvement can be determined from the user's responsiveness to warnings or guidance, including, for example, the frequency or consistency of checking sensor data (e.g., blood glucose levels), or the method of involvement (e.g., displaying only notifications vs. displaying full data, or a watch vs. a smartphone vs. a computer). In some examples, a high level of involvement by a particular user (concern, availability, or attention suggestion) may favor shorter-term decisions and guidance delivery, while a low level of involvement may favor delayed decisions and guidance delivery. In other words, to some extent, the level of availability or concern can be inferred from the level of involvement. For example, a low level of involvement may result in less frequent guidance, for instance, to avoid overwhelming the user. In other examples, a low level of concern by a particular user or regarding a particular situation may favor the decision and delivery of guidance sooner, for example, because it can be determined that the user may not be aware of a potential problem due to a lack of involvement. Conversely, a high level of concern may favor the decision and delivery of guidance later, for example, because the user is already aware of a potential problem and is highly involved in monitoring or resolving the issue.

[0421] Two or more inputs can be used together to determine the time to determine guidance, the time to deliver guidance, the format of guidance, or a combination thereof. The time to determine guidance and the time to deliver guidance can be related; for example, guidance may be determined slightly before the time to deliver guidance to ensure that the determined guidance reflects the latest real-time data. In one example, the time to determine guidance may be postponed if, for example, the length of the effective action period or the time until the next availability period is relatively long, allowing for the collection of additional data to improve the accuracy of the guidance or the state in which guidance is determined. In some examples, guidance may be determined early if a relatively short availability window is open or approaching, even if additional data is usually desired to obtain an accurate interpretation of the physiological state in order to enable the delivery of guidance (and the time the guidance is in effect) before the window closes. In other examples, guidance may be postponed if the time until the next availability window is relatively short. In some examples, the decision module applies weights to factors to determine whether or not to determine guidance and when to determine it. In some examples, the decision module determines a predicted future state or interacts with other modules or models (e.g., a physiological model) to determine a predicted future state and balance various inputs for physiological risk. In some examples, the decision module receives input a number of times in the future or determines a predicted future state and determines an acceptable or optimal time or time range for determining or delivering guidance. For example, the module may decide that guidance is not needed at the present time (e.g., 4 p.m.) but that the guidance should be delivered in the future (e.g., 6 p.m.-6:30 p.m.). In some examples, the module may re-evaluate its decision when new information becomes available, for example, when the urgency of action changes in response to a change in physiological state, or as a change in the level of involvement, or as a change in the schedule or pattern of availability.

[0422] Figure 5A Figure 5A is a flowchart illustrating an exemplary method 500 for delivering guidance, such as physiological glucose concentration management guidance. This method can provide guidance to facilitate the delivery of therapies, such as insulin delivery, carbohydrate intake, or physical exercise to manage glucose levels in diabetic patients.

[0423] In step 502, real-time data related to the patient is measured, determined, or received. Real-time data can be, for example, measurements from a glucose sensor, or 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., 60g of carbohydrates) by, for example, meal detection, user input, or other pattern detection. In another example, the user is determined to be about to perform a weekly routine, as determined by pattern recognition of calendar entries. In yet another example, 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), indication that meal time is imminent, time of day, characteristic or signature signals measured by an accelerometer, location determined by a GPS circuit, or a decision support request 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] In 504, the patient's condition is determined. The condition can be determined using a model and real-time data, for example, by applying real-time data to the model.

[0425] The model may include states that indicate, for example, the convenience or availability of a patient participating in an intervention. For example, information from a patient- or caregiver-related calendar (e.g., availability) may be applied to the model. In some examples, sensor information (e.g., accelerometer information indicating activity level) or pattern information (e.g., wake / sleep cycle or exercise or transit period, e.g., indicating driving) may be applied to the model. States 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 may include a patient physiological model, and the determination of the patient's state may be based on applying at least the first real-time data to the patient physiological model. In some examples, the state is insulin sensitivity. In one example, exercise is detected, and insulin sensitivity is determined based on a known pattern of the user's blood glucose response to exercise.

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

[0427] In some cases, behavioral models may include patterns. In exemplary configurations, the patient's physiological model is based on physiological patterns, and the behavioral model is based on behavioral patterns. In some cases, the first real-time data may indicate deviations from expected behavioral patterns. For example, the first real-time data may indicate mealtime shifts, missed, early, or delayed insulin administration, changes in physical activity (e.g., lack of exercise or atypical exercise), or early or late arousal. In some cases, the behavioral model may show a tendency to overcorrect for meals associated with mealtime, and the first real-time data may indicate that mealtime is imminent, with guidance messages responding to a decrease in undercorrection at mealtime (e.g., a smaller insulin dose or different combinations of basal and bolus doses).

[0428] In some examples, behavioral patterns can include long-term behavioral patterns based on long-term behavioral patterns and short-term behavioral patterns related to current behavior. Behavioral models may be based on both long-term and short-term behavioral patterns. In some examples, short-term behavioral patterns may be based on one or more selected from a group consisting of engagement with mobile devices, accelerometer data, glucose concentration check frequency, calendar data, and combinations thereof.

[0429] In some examples, the determination of a state can also be based on a measurement model. For example, the measurement model may be based on a continuous glucose concentration monitoring system related to the patient. The measurement model may include, for example, accuracy or other states regarding glucose measurement. In some examples, method 500 may 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, glucose concentration data measured following provision may be fed back into a measurement model, a behavioral model, a patient physiological model, or a combination thereof.

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

[0431] In some cases, the system detects a state of missing exercise sessions, a state of missing a series of exercise sessions, or a tendency toward shorter or fewer exercise sessions. A patient's physical exercise tends to increase metabolic drive and can increase glucose consumption. Missing or reducing exercise sessions can lead to a decrease in metabolic drive and a decrease in calorie needs, or an increase in the need for insulin to compensate for the low metabolic drive.

[0432] The decision-making guidance engine can also recognize convergence points of factors, such as higher-than-usual activity and lower-than-usual food consumption, or other patterns such as stressors or their deficiencies, travel, sleep disorders, illness / health, or atypical meal times, and can determine that there is a low probability of a state transition (e.g., from normally too high or too low blood glucose levels) occurring (given a normal state). Such decisions may lead to guidance decisions such as "You may experience atypical hypoglycemia tonight," "You may experience atypical hyperglycemia this morning," or "You may have a higher-than-usual insulin requirement today." The guidance can provide details about the reasoning behind the guidance (e.g., "...because you failed some workouts") or simply inform the user about physiological outcomes.

[0433] In 508, guidance messages may be provided to a user, such as a patient or caregiver, through a user interface such as a mobile device screen or speaker, or a speaker or display on a vehicle. In some examples, the method or timing of delivery of guidance messages may be partially determined by time (e.g., clock time or time of day), for example, to describe a patient's work, sleep, meal, or commute schedule. In one example, providing a guidance message may include displaying recommended treatments when calculated to be useful to the user. In one example, a guidance message may be provided before an scheduled event, such as a meeting. For example, if a user knows they will be attending a three-hour meeting, treatment recommendations may be presented before the meeting rather than waiting for more precise recommendations to be made or determined. In other examples, providing a guidance message may include providing the message when calculated to be useful to the user. For example, when a user is about to go for a regular run, a guidance message with recommendations for treatment or monitoring may be provided before the run begins, as opposed to when the user is prone to hypoglycemia.

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

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

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

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

[0438] In 507, the method may include providing determined personalized guidance messages via a user interface, such that the provision is calculated to be useful to the patient in the treatment and management of their diabetes. Providing determined personalized guidance messages may include providing personalized guidance messages on a user interface.

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

[0440] Model training can be performed before or after receiving real-time data. For example, the method may further include determining deviations from the expected state after delivering personalized guidance messages and fitting the model based on additional input information.

[0441] Figure 6 Figure 6 is a flowchart illustrating an exemplary method 600 for determining and providing personalized, useful, calculated guidance messages to a patient in the treatment and management of diabetes. In step 602, method 600 may include receiving data about the patient, the data including real-time glucose concentration levels. Real-time glucose concentration levels may be received from a glucose sensor, such as a continuous glucose monitoring system.

[0442] In 604, the patient's state can be determined by applying data to a state model. The patient's state can be a physiological state, such as any of the physiological states described above. For example, a state can include an insulin state, such as an insulin onboard state, an insulin sensitivity state, an insulin duration of action state, or a combination thereof. The state model can also include behavioral or contextual states or measured states. 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, a 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 work backward from the model to determine the combination of parameters that is most likely to provide the current CGM value for X. This combination of parameters (e.g., states) can be considered the "patient's state".

[0443] In 606, treatment recommendations based on a determined state can be provided. Treatment recommendations may include, for example, guidance on insulin delivery, carbohydrate consumption, protein, fat, or other nutrients or other foods or beverages. Treatment recommendations may be delivered to the patient or caregiver via electronic communication, for example, through a visual user interface (e.g., a screen), a speaker, or other communication mechanism. The method may further include refining the state model using data received after the delivery of treatment recommendations. For example, by inputting physiological data or state changes into the model, the model can learn from the actual data and adjust the model based on the input conditions and actual outputs. The system can also take into account the physiological consequences of previous guidance to improve the determination of a particular state or to improve the decision of guidance.

[0444] Figure 7 Figure 7 is a flowchart illustrating a method for determining and delivering personalized and useful guidance messages to patients in the treatment and management of diabetes.

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

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

[0447] The method may also include, in 706, determining a personalized guidance message to be provided to the patient. The determination of the personalized guidance message may be based at least in part on the time of the personalized guidance message determination and the patient's personalized behavior model. The method may also include, in 708, determining the 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 managing the user's diabetes treatment. The method may also include delivering the personalized guidance message at the time of delivery.

[0448] Figure 8 Figure 8 is a flowchart of an exemplary method 800 for providing a user with decision support functionality. The method may include loading a model into the memory of a computing environment in 802. The method may also include receiving data indicating the user's glucose concentration value in 804. The method may also include displaying calculated insights on the user interface of the computing environment in 806. The insights may be calculated, for example, using at least a model and data indicating the glucose concentration value. In some examples, a user request may trigger the display of the calculated insights. The user request may be associated, for example, with data entry for a planned activity. The calculated insights may indicate user actions calculated by one or more models to produce a desired outcome associated with the glucose concentration value while maintaining the glucose concentration level (or its rate of change) within a target range or above or below a specific level. The planned activity may be, for example, a meal, and the calculated insights may be, after the meal, the calculated or predicted effect of the meal on the glucose concentration value, or a strategy for managing the glucose concentration level (e.g., insulin delivery or activity or both). In some examples, the calculated insights may include interactive recommendations and at least one factor used in determining those recommendations.

[0449] In some examples, displaying insights can be initiated by the occurrence of events that match predetermined conditions, such as blood glucose levels or trends, arrival at a destination determined by a GPS system, or events inferred from patterns or determined using calendar information.

[0450] In some examples, displaying guidance may be triggered by the occurrence of an event that matches a calculated condition. The calculated condition can be based at least partially on a model, or data showing glucose concentration values, or a combination thereof. For example, if a treatment adjustment exposes the user to more risk than was present before the adjustment, warnings and / or alerts may be adjusted to have additional sensitivity for a certain period after the treatment adjustment. In other examples, the messaging frequency of a decision support application may be increased when it detects that there is a period following a potential treatment decision that triggers more frequent instantiation of the CGM app than before the potential treatment decision.

[0451] Figure 9 Figure 9 is a flowchart of method 900 for delivering physiological glucose concentration management guidance. Step 902 may include receiving data indicating glucose concentration levels. Step 904 may include determining a state by applying the data to a model. Step 906 may include determining a guidance message based on the state and temporal patterns. Temporal patterns may include, for example, learned temporal patterns or user-defined schedules (e.g., patient or caregiver calendars). Patterns may include patterns of one or more states correlated with time, or typical blood glucose concentration levels, ranges, or patterns correlated with time or events.

[0452] Figure 10 Figure 10 is a flowchart of Method 1000 for delivering physiological glucose concentration management guidance. Method 1000 may include receiving data indicating glucose concentration in step 1002. In step 1004, Method may include determining the patient's condition by applying the data to a model.

[0453] Step 1006 may include determining whether the patient's condition is atypical. Determining whether the patient's condition is atypical may include determining whether the patient's condition is atypical for a given set of conditions, determining whether a low-likelihood state transition has occurred, and determining whether a low-likelihood state transition is expected to occur. In one example, determining the patient's condition includes determining the physiological and behavioral states and determining whether the physiological state is atypical with respect to the determined behavioral states. In a further example, determining whether the patient's condition is atypical may include identifying blood glucose levels that deviate from a controlled blood glucose range when or under circumstances blood glucose levels are normally within a controlled range, identifying blood glucose trends that lead to high or low blood glucose states when or under circumstances blood glucose levels are normally within a controlled range, or predicting a shift to a low blood glucose state when or under circumstances blood glucose levels are normally within a controlled range.

[0454] Step 1008 may include determining a guidance message based on the atypical nature of the patient's condition, and step 1010 may include delivering the guidance message via a user interface.

[0455] Figure 11 Figure 11 is a flowchart of a method 1100 for delivering physiological glucose concentration management guidance. The method may include receiving data indicating glucose concentration, determining the 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 guidance messages 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 may be recognized as indicating a low probability of a transition to a particular state under general conditions, but under specific conditions, the pattern may be recognized as indicating that the transition is actually likely to occur, as indicated by real-time data or user input. For example, the method may include warning the user that an atypical state is likely to occur when glucose levels are normally controlled at that time. For example, the user may be warned about an expected low glucose level after exercise. Exercise may lead to a low glucose level several hours after the exercise is completed (e.g., due to increased insulin sensitivity or recovery of glycogen stores). The user may be warned about the possibility or likelihood of such a “slow and low” state. If it is calculated that the low will occur during sleep or at an inconvenient time, the warning may be delivered or prioritized. In some cases, warnings may be delivered at times that are useful to the user, such as before the patient is expected to fall asleep, in order to avoid waking the patient or caregiver.

[0456] Figure 12 Figure 12 is a flowchart of a method 1200 for delivering physiological glucose concentration management guidance. The method may include, in 1202, receiving data indicating glucose concentration; in 1204, receiving one or more behavioral, environmental, or contextual inputs; in 1206, identifying the likelihood of transition to an undesirable patient state by applying the data and one or more behavioral, environmental, or contextual inputs to a model; in 1208, determining a guidance message based on the likely transition to an undesirable patient state; and in 1210, delivering the guidance message, which is determined and delivered at once to enable the patient to intervene and avoid transition to an undesirable patient state.

[0457] Figure 13 Figure 13 is a flowchart of method 1300 for delivering physiological glucose concentration management. The method may include receiving data indicating glucose concentration in 1302, determining the physiological state using the data in 1304, determining the behavioral state in 1306, determining a guidance message based on the physiological and behavioral states in 1308, and delivering the guidance message using a user interface in 1310.

[0458] Exemplary inputs and outputs - Figures 14-16 The flowchart 650 in Figure 14 illustrates a method for quantifying non-clear inputs. In particular, upon receiving non-clear input (step 219), one way to quantify it is to perform a natural language processing step on the input to determine its "clear" equivalent (step 221). For example, if a user qualitatively indicates that they consumed one glass of orange juice, natural language processing can determine the number of carbohydrates in one glass of orange juice, thus converting the input from non-clear to clear. Historical pattern data can also be used in this regard. Using similar natural language processing, the clear nutritional content of an input such as "I ate a Quarter Pounder at McDonald's" can be determined. Social networks and social media can also be used to give context to non-clear inputs or to tighten values ​​related to non-clear inputs (step 223). Also, big data can be used (step 225) to give context and clear values ​​to non-clear inputs. For example, group data can be used to determine what a particular user means by displaying a particular phrase or parameter, for example, through the analysis of cohort data, and the same can be used in conjunction with any of the other technologies to clarify a quantifiable criterion version of the input that can influence decision support (step 227).

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

[0460] However, before a general discussion of inputs, referring to Figure 15, certain types of relationships are shown, and a particular relationship is indicated by relationship 231 between food sensitivity 233d and dietary bolus 235a. Other relationships between inputs 233a-233e (only sampling of such inputs is shown) and various outcomes or specific outputs 235a-235e (again, only sampling of such outputs is shown) can also be determined using the systems and methods relating to this principle. Processing step 237 is shown to demonstrate how correlation parameters, such as food sensitivity 233d, are used together with real-time inputs (not shown) within processing step 237 to yield therapeutic recommendations for dietary bolus 235a. Specific examples of these inputs and outputs are described in the “Examples” section below.

[0461] Identifying correlation parameters and lifestyle / situational parameters, and the subsequent processing steps, can be carried out 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, and collective or big data. Processing and identification can include, for example, Bayesian analysis to identify strong connectors, which are parameters or variables that have a strong relationship with each other. If multiple parameters are used, the same can include multiple parameters related to the same event, such as both exercise intensity and duration. Processing and identification can include multiple steps, for example, a first step of processing the patient's "internal data" and subsequent steps of performing processing in the cloud using "big" data, for example, using pre-packaged subroutines or case-based inference. For example, case-based inference can be used to determine what happened to the user in other similar situations, or what happened to other similar users in other similar situations. As smart devices become more computationally powerful, much of the machine learning can occur on such devices. However, much of the current processing can be done in the cloud, and such processing can result in massive amounts of machine learning. In other words, the system learns how a single element or "influencing factor" X affects the patient, for example, how anabolic exercise affects insulin sensitivity. In this example, if pump action is initiated by a bolus but without considering the effects of exercise, and the user performs the exercise, a system and method based on this principle can detect this sequence of events and provide the user with recommendations such as "expect a drop" or "you need to eat something now."

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

[0463] In modifying the human interface of a machine, just as inputs can be categorized or "fuzzy," outputs can also be provided in a categorical or "fuzzy" manner, especially when the output is simply provided in a user interface on a display. For example, if a therapy recommendation suggests that the user has a large glass of orange juice or eats a medium-sized apple, the user might find such a recommendation more helpful than a recommendation to eat a specific amount of carbohydrates. Of course, if the output involves output to a pump or pen, such "fuzzy" processing is unnecessary, and the highest possible precision is generally desired.

[0464] Figure 15 - Output Exemplary outputs are shown in Figure 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 corrected bolus 235b, recommendations for the type, amount, and timing of a meal 235c, changes to the user interface 235d that provide warnings or alerts at times determined to be effective for the user, or pre-event or situational decisions 235e, which are decisions made, for example, before sleep, meals, exercise, driving, or activity. Other exemplary outputs include permanent or temporary changes to baseline rate settings, recommendations for rescue carbohydrates, etc. Specific outputs, and how the same may change depending on the decision support application / function, are described in the "Outputs" section below.

[0465] Regarding providing decision support applications / functions in a way that supports user-defined functions, various core methods have been described above, but it should be understood that these core methods do not need to be mutually exclusive. For example, various combinations of core methods may be adopted in a given implementation. Furthermore, multiple methods can be executed in parallel to determine the optimal treatment and select the safest option. That is, various algorithms as described above can be used to compute the optimal diabetes treatment decision using defined conditions, sensor data, user input, and other available information. Multiple methods can be executed in parallel to compute the optimal treatment decision and then provide the user with the most conservative or safest solution. For example, in the case of sensor noise, the current glucose estimate can be calculated using either filtered or raw sensor values, followed by the calculation of 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 estimate of the glucose rate of change based on the trend calculated by the CGM algorithm, or as a two-point difference of the most recent pair of glucose values, with the rate of change used to provide a more conservative dose.

[0466] A table shows some exemplary inputs and their notations. It should be understood that other inputs can be used, and that the given notations for inputs are not necessarily limited. For example, an input may be indicated as having a specific context, but in some cases, the context may be considered to overlap with a specific category. Another example of variation is that a particular input may be identified as something entered by a user, but in some cases, it may be determined by sensors, etc. For example, meal data may be determined by user input, but it can also be determined by GPS, from pattern data, or from an app such as a camera. As mentioned earlier, decision support applications / functions incorporate machine learning to improve the accuracy and appropriateness of treatment prompts over time. For example, meal data such as "small meal" and "moderate meal" entered by the user can be "learned" by the system so that the decision support application / function can better understand what the user considers a "small meal," etc., over time. Temporal patterns can be analyzed by the system and methods to determine, for example, the nature of meals and exercise, but the user can also identify and quantify the events they want to track, including those corresponding to meals and exercise.

[0467] In an alternative implementation, the algorithm can define only one "average" meal, but with some degree of auto-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 for individual users. This implementation can be convenient to implement because it only needs to define one meal size and does not need to be changed for each meal. Rather, a multiplier is applied automatically to assess whether a meal is "average," "light," or "heavy / large" for the patient, HCP, or automatically. The algorithm can then automatically increase or decrease the proposed insulin amount according to the assessment. For example, an exemplary "multiplier" could be that a large meal has 1.5 times the effect of an "average" meal, or a small meal has 0.5 times the effect of an "average" meal. Such an implementation can be particularly convenient for users to implement, especially if the user is unfamiliar with carbohydrate counting. It is conceivable that such an idea could be extended and applied to other applications.

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

[0469] In the table, inputs are divided into two categories: real-time data and non-real-time data. See also Figure 17, these input categories 246 are further divided into subcategories such as: data from sensors (248 and 252), user-entered data, or data from other applications such as appropriate APIs, derived data, and user data 254, which may be other data. Some subcategories appear in both real-time and non-real-time data. In either case, the inputs 246 are then supplied to a user device 256, which may be a dedicated receiver or a smartphone, more specifically to a decision support application 260 located therein. Derived data 262 may be stored in the user device 256, and a display 258 may have a user interface to display prompts to the user and to receive user input data. Derived data 262 may be derived by a processor within the user device 256, and the data derivation may occur within or outside the decision support application / function.

[0470] Figure 16 - Input Referring again to the data types shown in Figure 16, a sub-subcategory either describes a specific type of data or is a category in itself. For example, a sub-subcategory of real-time data is "physiological sensors," which can be further divided into different types such as CGM, SMBG sensors, body temperature sensors, skin conductivity sensors, hormone sensors, and heart rate sensors. In addition to physiological sensors, other sensor data includes non-physiological sensors such as atmospheric pressure, accelerometers, GPS, sensor measurement modes of the CGM system itself, and temperature sensors. Such inputs may be provided from wearable devices / sensors, such as those available from Apple Watch®, Fitbit®, or other wearables. Other devices providing inputs may include other mobile devices, including smartphones.

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

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

[0473] In some cases, decision support applications / functions can allow users to input data about the start of their menstrual cycle (or other markers). In this way, users can track the behavior of their blood glucose levels at different times of the month in relation to their cycle over several months. Of course, such algorithms and data can also be used on their own to assist in attempts to conceive, or if the rhythm method is used for contraception.

[0474] Hormone sensors can provide other sources of input data, for example, a source of data related to the menstrual cycle. Other hormone sensors may include those that detect cortisone and / or epinephrine. Hormone sensors can also be used to provide "energy input" versus "energy output" measurements, particularly in relation to a parameterized system model of a patient.

[0475] Other subcategories of real-time data input include user input data such as goals, problems to solve, and desire for treatment; input data related to stress, emotions, or mood; pain level data; sleep level data; data from follower devices; pump data; diet data; exercise data; and blood glucose data from external blood glucose meters. User input data can include user estimates of glucose values, allowing for decision support in a way that helps better correlate perceived glucose values ​​with actual glucose values. For example, a decision support application / feature can be enabled to better help users determine and identify how they are experiencing various levels of hyperglycemia. User input data can also include user population statistics such as age and gender. Such data can be conveniently obtained, for example, by swiping the user's driver's license.

[0476] If user input data includes exercise, the system and method relating to this principle allow the user to save specific workouts or events, analyze and potentially discover patterns of blood glucose fluctuations after workouts, and enable decision support applications / functions to make appropriate automated or manual changes to treatment. For example, a user can save workouts such as "Cardio1," "Cardio2," "GetSwoll1," and "GetSwoll2." Other aspects of exercise may 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] Target data may include a display of priorities regarding glucose control, such as avoiding hypoglycemia and hyperglycemia. Different control types can be offered as pre-programmed profiles that users can select when choosing targets. For example, users may select targets such as low-minimizing control, ultra-minimizing control, and frequent vs. infrequent corrective bolus to suit different treatment styles and goals.

[0478] Similarly, user feedback can also constitute important input to decision support. That is, decision support applications / functions can be modified based on user feedback, for example, by periodically asking the user what they would like to change about their recent blood glucose control and providing options such as "I would like to reduce the number of nocturnal hypoglycemia episodes" or "I would like to not need to give corrective boluses as frequently." Feedback can be solicited in a convenient way to minimize user inconvenience. For example, feedback can be provided by a slider bar or other user interface elements that are convenient for the user's selection. A slider bar can also be provided for other user inputs, for example, to indicate how much interaction is desired.

[0479] As described above, decision support applications / functions can be advantageously used as part of a bolus calculator. Therefore, user input can also include user input to such a bolus calculator. For example, a decision support application / function can be provided with a user interface that provides the user with predetermined dose adjustments, such as + / -0%, + / -10%, + / -20%, etc. The presented dose adjustments may themselves depend on the CGM trend; for example, in the case of a negative or decreasing glucose trend, a negative dose adjustment may be provided. The selected adjustment is applied to the calculated bolus dose with or without other trend adjustments. Alternatively, the adjustment can be fuzzy. In yet another implementation, the user may choose to customize the adjustment within the bounds. Over time, the data allows the decision support application / function to determine the optimal adjustment based on this user input data (and other inputs), and with provider approval (or without provider approval / confirmation), the adjustment options can be presented to the user for re-determination.

[0480] In related implementations, rate of change data, rather than percentages, can be used to increase / decrease bolus values ​​calculated with a fixed amount. In this way, the patient uses 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, the bolus calculation can initially be left unchanged, and the decision support application / function can learn the amount of insulin to add or subtract based on the rate of change as part of a case-based learning process. For example, instead of updating insulin sensitivity, if glucose is rising or falling, the system might learn how far glucose is from the target and consider that to be the amount of glucose that should explain it. 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 insulin sensitivity for breakfast without exercise. Since it may be desirable to learn both the amount to adjust the insulin bolus based on the rate of change and the change in insulin sensitivity with respect to time, exercise, etc., systems and methods relating to this principle can advantageously separate the two problems and only perform insulin sensitivity updates when the rate of change is relatively stable. Learning how much a user needs to adjust their insulin based on the rate of change allows us to push data to the HCP, for example, if a user takes a meal bolus and the trend arrow is 90 degrees up, and the user's postprandial glucose consistently shows an overly high pattern around 30 mg / dL, the HCP can then be asked to approve adding or subtracting insulin. Machine learning can also be used to determine whether it is better to change the insulin bolus based on the rate of change, using a percentage or a fixed amount, in cases where it can be exactly different for each patient. Additional details on using rate of change data are provided in the example below.

[0481] Returning to the description of various inputs, the input can include data about a user's followers or other related users. This input data can include, for example, data about social grouping to achieve individual or group goals, and further, natural language processing can be used to derive objective and quantifiable needs and goals of the group or its members. The input can also include input from followers as responses to queries such as, for example, "What do you think is happening with your daughter?"

[0482] Other sources of real-time data entered by users include meal data. Users can enter meal data in a fuzzy, categorized, or clear manner. Machine learning can be used to learn how users categorize meals in an objective sense. For example, if a user describes a meal as "small" in relation to what is entered into a decision support application / function, the system can learn in a more quantitative or objective way what the user considers a "small" meal to be. The same applies to meals that are entered and called by other sizes. The same applies to data about the composition of meals entered by users. In other words, the system can learn what the user means when they enter a statement about the composition of a meal into a decision support application / function. For example, if a user describes a meal as "high in carbohydrates," the system can learn what the user considers "high in carbohydrates" by combining meal data with data on glucose response and provided insulin (if available).

[0483] Other subcategories of real-time data input include data from other applications or “apps,” such as data from appropriate APIs. Such apps may reside in or communicate with a computing environment that provides a decision support application / function, 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®, data from followers such as text messaging apps, bolus calculation apps, clock apps that provide the time, apps that show elapsed time to enable user prompts to be provided at the optimal time, apps that provide access to cloud data or “big” data, camera apps, pump applications, pen applications, bolus calculation apps, etc. As a specific example, a text messaging or email app may refer to an event, such as a dinner party. Through an appropriate API, a text messaging or email app can function as an input source for calendar data. In a specific example, there may be an option to “add event to CGM,” or the CGM (or equivalent decision support application / function) may be able to automatically pull event data whenever a calendar event is added. Such functionality allows users to create calendar events and CGM events simultaneously, providing an easy way to collect event data and see how events affect glucose trends.

[0484] For example, decision support for bolus computers generally requires input of meal data. In one implementation, a camera application could prompt the user to take a picture of the meal on a plate (see Figure 18A). The user can take the picture using their phone's camera, and brackets can be provided as part of the on-screen user interface to guide the user on how to take the picture. The app can then measure the size of the meal in relation to the size of the plate and indicate the meal as, for example, small, medium, or large. The app can then suggest a recommended serving size based on the size of the meal. In a more enhanced implementation, the app could use photo recognition technology to determine, estimate, or guess what is on the plate and provide an estimate of the resulting meal composition. Variations are understood. For example, in an alternative implementation, a user prompt could instruct the user to swipe different sizes of circles (or other shapes) on a picture of the meal on a plate (see Figure 18B). The app can then ask the user to find the circle size that best fits the size of the meal on the plate.

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

[0486] More specifically, patients who receive too much insulin are at risk of hypoglycemia and even death. Currently, there is no real-time method to measure the amount of insulin in a patient's body. Insulin stacking occurs when a patient using insulin receives multiple bolus doses of insulin in a short period of time. Insulin from a previous dose may not have exerted its full effect, and therefore, the patient may give themselves too much insulin with a subsequent dose, potentially putting them at a serious risk of hypoglycemia. 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 fail-safe to shut down the pump or artificial pancreas. Since each patient generally has different insulin sensitivities (although this sensitivity can be learned using the decision support application / function described here), multiple thresholds are generally required for warning settings.

[0487] A second aspect of this implementation includes monitoring the patient's insulin levels using a direct insulin sensor. The insulin levels can be used to provide feedback recommending a safe dose of insulin to the patient. The insulin information can also be transmitted directly to a calculator or pump and used in insulin dosing calculations to more accurately estimate the appropriate amount of insulin to administer. This can be used as a replacement for the current onboard insulin estimate used in bolus calculators.

[0488] A third aspect of this implementation describes the use of a direct insulin sensor to measure a patient's insulin sensitivity. Insulin sensitivity can vary from patient to patient, and even in the same patient over time. Therefore, the system and method relating to this principle can measure the amount of insulin in a patient's body using a direct insulin detector. By combining information on glucose and insulin concentrations in the patient with an algorithm, insulin sensitivity can be calculated. Then, using the information contained in insulin sensitivity, it is possible to determine whether insulin sensitizers, insulin secretagogues, or insulin should be used to manage diabetes, for example, by increasing or decreasing the amount of insulin given to the patient to best control their glucose levels.

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

[0490] A calendar app can be used to provide data about a user. For example, if exercise is included in the schedule, or if the exercise pattern suggests that the user exercises at the same time every day or week, exercise data can be determined from calendar data.

[0491] Another example of input is the use of safety rules to provide decision support at varying levels of assertiveness. For instance, if a user does not provide detailed dietary information, a decision support application / feature that prompts the user to raise their glucose levels to a target range may aim for the upper limit of the target range rather than the middle of the target. Similarly, if a user provides dietary data showing a very high amount of carbohydrates, the decision support application / feature may again aim for the upper limit of the target range, as it is known that carbohydrate counting errors have a worse impact as the overall carbohydrate amount increases.

[0492] Other examples of inputs include device diagnostics, which not only serve as inputs including device signal quality and reliability, but can also be used to determine risk stratification. For example, a meal or corrective bolus or other decision support prompt may be indicated at least partially by confidence intervals, which may be indicated at least partially by device signal quality and / or detected faults.

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

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

[0495] Other types of input include derived data. Derived data, which in some cases can also constitute real-time data, includes the rate of change or acceleration of the analyte, various types of sensitivity such as insulin, sleep, diet, and / or exercise, stratification within risk stratification (described in more detail below), glucose fluctuations, user stress / emotion / mood data, user requests for interaction with the device, sensor accuracy / reliability / signal quality, pattern data, etc. Such sensitivity often constitutes lifestyle factors as defined above. Since hormone levels are known to be relevant factors, the detection of hormone levels described above can further aid in the detection and quantification of insulin sensitivity.

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

[0497] Derived data corresponding to dietary sensitivity can be further refined by determining, for example, glucose sensitivity, dinner sensitivity, etc. It will be understood that other such perturbation or interaction sensitivities can also be derived.

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

[0499] In some cases, derived data requires analysis of the period to be analyzed or the patterns to be determined. For example, determining insulin sensitivity or insulin resistance may require analysis of data taken over a period of time. In certain implementations, insulin resistance may change throughout the menstrual cycle of female diabetic patients. Decision support applications / functions can use the cycles resulting from insulin resistance, including, for example, the incorporation of insulin consumption and glucose values, to determine predictive insulin resistance alerts to provide to the user. For example, a patient may receive a reminder at the beginning of the day that their blood glucose levels tend to rise or fall historically during their cycle. Such prompts help patients be more mindful of how they can expect their blood glucose levels to behave.

[0500] For initial or seed values ​​of insulin sensitivity, population data can be used from a patient database, particularly one with similar weight, age, sex, and duration of diabetes. Such data can be used as default values ​​and can be automatically adjusted as additional information about the user becomes available over time.

[0501] Dietary data may also be in the form of derived data, similar to how it may be obtained from food patterns or food libraries. Another method of deriving dietary data is to use retrospective analysis to estimate the carbohydrate content of a given meal using other data. Such other data may include, for example, delivered insulin, glucose levels, exercise, health, and meal timing. By collecting such data, decision support applications / functions can determine a user's typical diet and their typical glucose response to that diet, while mitigating the influence of other factors on glucose. Such functions offer several advantages, including improved accuracy of bolus calculators, the ability to optimize warnings when the system detects an abnormal glucose response, assistance in understanding the user's dietary patterns and the influence of various diets on glucose, and more accurate calculation of insulin-to-carbohydrate ratios.

[0502] The derived data may also include user estimation data, such as whether users are prone to making errors in carbohydrate counting and to what extent they tend to overestimate or underestimate, for example.

[0503] The derived data may also include data determined about recognized patterns, which are identified through analysis of historical data over time. Exemplary recognized patterns include patterns such as nightly hypoglycemia, postprandial highs, and post-exercise lows.

[0504] One way to determine such patterns, or to detect the occurrence of glucose events that do not fit the pattern, is to "binn" specific events defined by certain characteristics. That is, portions of the glucose trace that meet predetermined criteria indicating a specific diabetic challenge, such as rebound hypoglycemia, can be detected, and then patterns can be looked for in these events that have been "binned" accordingly.

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

[0506] The next step is to characterize incidents based on, for example, decay curves, waveform signatures, etc. (Step 264). Exemplary incidents may include, for example, a meal bolus index based on insulin data, which can be classified into small, medium, and large meal bins. Such may correlate with insulin data. Different meal types can also be characterized and then sub-binned into different meal compositions. These may correlate with rate of change / acceleration / deceleration. Incidents can also be characterized based on correlation with pre-meal events, such as those corresponding to the data patterns described above. Incidents can further be based on behavioral patterns, for example, how often a user checks their glucose data or how often they respond to alarms, such as those correlating with the responsiveness data described above. It will be understood that other bins can also be used.

[0507] Next, the characterized incidents can be placed into bins (step 266). Then, by synchronizing each incident, the bins can be adjusted to match the physiological function of a particular patient. Next, the bins can be normalized; that is, a normal distribution of incidents within the bins can be defined (step 268).

[0508] Next, the normalized bin information can be actively used as input to a decision support application / function, for example, in determining or defining the state relating to step A (step 268). As an example, the normalized bin information can be used as 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 binning techniques, it is possible to determine when patients should align with the data based on behavioral input, which can enable more proactive recommendations, as opposed to when the user is not focused on glucose information, such as at night, where bolus recommendations are generally more conservative.

[0509] Returning to Figure 16, non-real-time data can include user input data such as previous SMBG data, user knowledge of the technology, target data, problems to be solved, desires for specific treatments, target glucose levels, population statistics such as age and sex, heart health status, cholesterol levels, type of mathematical calculation to employ (usually by default or entered by the HCP), data on illness, pregnancy, or menstruation, data on medications taken, and smoking history. Non-real-time data can also include derived data, such as historical patterns and gastric emptying time. Other non-real-time data can include data on followers, such as tone of communication and language. These can be used when modifying the output to enhance user effectiveness.

[0510] Regarding gastric emptying time, it has been noted that 25% of the diabetic population (types 1 and 2) experience some form of delayed gastric emptying. 7-12% of the same group experience increased delayed gastric emptying. The population experiencing delayed gastric emptying is increasing at a very large rate within the diabetic population and is now a concern for healthcare professionals in the general population.

[0511] Current bolus wizards do not take gastric emptying into account, thus posing certain risks. For example, if gastric emptying is not incorporated into the closed-loop pancreatic system, individuals risk glucose fluctuations that lead to repeated corrections and reduced insulin delivery. This results in chaotic insulin delivery similar to a successive approximation waveform over time. If the same is not used in bolus calculators for insulin pumps, this can endanger individuals as hypoglycemic events may occur that roughly correlate with the size of the meal administered. They may also suffer hyperglycemic events that are similarly roughly correlated with meal size, as their effect becomes more pronounced when insulin responsiveness is reduced and decreased within the system.

[0512] Over time, such fluctuations can manifest as further damage that may impair stomach function over time. Furthermore, the individual may have an increased risk of peripheral neuropathy.

[0513] Delayed gastric emptying is the process of moving processed and prepared nutrients and food into the small intestine, where actual absorption of nutrients occurs and can be caused by factors such as vagus nerve damage, 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 result in gastric paralysis.

[0514] The general instruction given to patients with insulin-dependent diabetes is to administer insulin (bolus) 0 to 30 minutes before a meal. The rationale for this instruction is to time the effect of insulin to coincide with the time it takes for consumed food to enter the absorption phase. This timing is accurate when gastric emptying is not a problem (75% of the type 1 and type 2 population). However, in a balance of the population, the timing of insulin delivery is inaccurate. Rapid-acting insulin reaches its maximum effect approximately 90 to 120 minutes after bolus administration. This is due to delays from bolus administration, propagation in the body, and attachment to A and B receptors on the cell surface. At that time, the cells can process the glucose and do so. However, in individuals with delayed gastric emptying, the delivery of processed food to the system has not yet occurred. In these individuals, a hypoglycemic event occurs approximately 90 to 120 minutes after a meal (if the bolus was administered 30 minutes before the meal). This event is generally mitigated by liquids such as orange juice, which enter the intestines and system faster than solid food.

[0515] The insulin response decreases at the end of the peak in elevated cases of delayed gastric emptying as food is processed and enters the system. This leads to hyperglycemic events requiring the administration of a corrective bolus. Therefore, gastric emptying time can be used as input to provide a time delay for the delivery of a postprandial bolus. This delay can be applied to a bolus calculator or a closed-loop artificial pancreas system. Gastric emptying time can also be used as input to provide a time delay for a modified basal rate after a meal. This delay can be applied to an insulin pump or a closed-loop artificial pancreas system.

[0516] One method for determining an individual's gastric emptying delay is as follows: When a CGM user inputs a bolus and a meal, data for the next four hours is analyzed within the CGM. If there are reproducible events that occur in the individual following a trend, gastric emptying delay can be estimated. The estimated delay can then be applied to the bolus and / or adjusted baseline rate as described above.

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

[0518] Referring again to Figure 16, non-real-time data can also include stored data, which is stored in memory or other storage and retrieved from there. Stored data can include historical data of both determined patterns and data used to determine patterns or other glucose events. Stored data can include previous user events. For example, if an HCP has previously commented on a pattern, the HCP comment can be redisplayed in the user interface when the pattern is repeated.

[0519] Inputs can be "fuzzy," for example, categorized into specific categories such as small / medium / large meals, or "less than normal" / normal / more than normal," with the category itself being used as input, or the input can be clear. Therefore, the table also shows exemplary categorized or fuzzy inputs, as well as exemplary clear inputs. The table also provides interpretations regarding the type of context of the input, such as whether the same concerns apply to lifestyle, situation, clinical, or device configurations. In some cases, the input may comprise multiple categories.

[0520] The way inputs are used and aggregated can differ. In one implementation, a function may be determined, or a user system model may be created, with inputs used directly in the function or model. In another example, in a hierarchical approach, a decision support application / function may be designed to use information obtained from various sources in a stratified approach. A bare-bones system may use CGM data, and as additional data is received, the same data can be used for decision support. Generally, as the amount of information increases, the reliability of estimations and decisions improves. Similarly, users or usage conditions can be categorized into buckets or risk layers. As information becomes available, the system can move up or down the hierarchy to ensure safety.

[0521] Furthermore, as can be understood from the above, the combination of inputs itself can lead to additional inputs. For example, an alternative empirical approach could involve controlling aggression based on historical levels or predictive success. For instance, aggression in decision support may be reduced if circumstances such as time of day, day of the week, or type of event result in historically variable or poorly predicted glucose levels. For example, a user might eat very consistent lunches on weekdays and inconsistent lunches on weekends, where consistency refers to timing, meal size, and meal content. Inconsistency could make it difficult to predict the outcome of a pre-lunch bolus on weekends. A decision support application / function could detect this poor predictability and adjust its aggression accordingly.

[0522] Referring to Figure 21, the operating modes of a CGM app or decision support application / function can function as inputs that can be classified in various ways. For example, an operating mode can refer to a calibration mode, such as self-calibration of the device or factory calibration. An operating mode can also refer to a transmission mode (transmission of data to a display device), such as scheduled transmission or unscheduled transmission. Note that all of these modes described are illustrative, and other operating modes are possible. An operating mode can also refer to a decision support mode, such as therapeutic, non-therapeutic, supportive, or non-supportive. As can be seen from the figure, even when modes can be considered operationally sequential, a decision support application / function can jump from one mode to an adjacent mode, or from one mode to a non-adjacent mode. An example is scheduled transmission, where mode 1 transmits every 30 seconds, mode 2 transmits every minute, and mode 3 transmits every 5 minutes. Often, such modes are not marked only by characteristic time changes, but also by changes in function, such as from periodic to aperiodic.

[0523] Signals are collected from sensors in smartwatches such as Apple Watch or Microsoft Band and can augment specific input data, such as detecting hypoglycemia. Signals can include heart rate, sympathetic / parasympathetic balance (estimated from heart rate), sweating, and movement. Signals can be used in addition to CGM signals. Algorithms used to process these augmentative signals can be trained with patient-specific data, using CGM to assist in training. These external limitations can be optimized offline or in the cloud. Detection criteria can then be sent to the patient's smartphone and / or smartwatch. For example, if CGM may fail to detect hypoglycemia, augmenting it with a potential hypoglycemia signal alerts the patient, allowing them to avoid the outcome. Alternatively, after the algorithm used to process the augmentative signals is trained, hypoglycemia can be detected using smartwatch signals without CGM. In this use case, algorithm tuning can be used to optimize sensitivity / specificity.

[0524] The detected cognitive abilities can also be used as input. More specifically, it should be noted that cognitive abilities and motor functions can be influenced by a number of diverse inputs and effects. For example, individuals with diabetes may suffer cognitive and / or motor function impairments as a result of hypoglycemia. When a hypoglycemic incident occurs and blood sugar levels drop, individuals may suffer from decreased concentration and / or comprehension. Furthermore, as the body reacts to the lack of sugar, muscles may become tense and begin to act irregularly.

[0525] Capacitive touch functionality in input devices such as smartphones and tablets allows users to view information, make decisions, and interact with the device by pressing on-screen indicators. As users become familiar with applications on such devices, their decision-making abilities improve while interaction delays decrease. Furthermore, they develop familiar sequences of actions to perform common, familiar tasks.

[0526] However, if an individual is experiencing drug interactions, alcohol, or hypoglycemia / hyperglycemia, these familia...

Claims

1. It is a system, 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 containing the stored model, It is a processor, The glucose concentration level of the aforementioned patient is received, The stored command is executed, and the patient's glucose concentration level is applied to the stored model to determine the state. A system comprising a processor configured to determine a guidance message based at least partially on the aforementioned determined state.

2. The system according to 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 according to claim 1, wherein the model includes a physiological model, and determining a state includes determining a physiological state.

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

5. The system according to claim 1, wherein the processor is further configured to provide treatment recommendations based at least in part on the determined state.

6. The system according to claim 1, wherein the system includes a mobile device, and the mobile device includes the memory circuit and the processor.

7. The system according to claim 6, wherein the mobile device includes the communication circuit, and the glucose concentration sensor includes a glucose concentration sensor communication circuit configured to communicate with the communication circuit.

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

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

10. The system according to 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 state.

11. Furthermore, the system according to claim 9, comprising an insulin delivery system.

12. The system according to claim 11, wherein the insulin delivery system includes an insulin pump.

13. The system according to claim 11, wherein the insulin delivery system includes an insulin pen.

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

15. A method for distributing guidance on physiological glucose concentration management, Receiving data indicating glucose concentration levels, The state is determined by applying the aforementioned data to the model, A method comprising determining a guidance message based at least in part on the aforementioned state and temporal pattern.

16. The method according to claim 15, wherein the temporal pattern includes learned patterns of patient behavior.

17. The method according to claim 15, wherein the aforementioned time pattern includes a calendar.

18. The method according to claim 17, wherein determining the guidance message is at least in part based on the incoming events in the calendar.

19. The method according to claim 18, wherein determining the guidance message is at least partially based on an expected change in insulin sensitivity calculated at least partially on the incoming event in the calendar.

20. The method according to claim 15, wherein the model includes a physiological model, determining a state includes determining a physiological state, and determining a guidance message includes determining from the temporal pattern and the physiological model that a transition to an undesirable physiological state is likely to occur.

21. The method according to 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 the delivery of the guidance message to enable the intervention to prevent the transition, at least in part on the temporal pattern.

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

23. The method according to claim 22, wherein determining the delivery time includes selecting a delivery time when it is likely that the host is available based at least partially on the aforementioned time pattern.

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

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

26. moreover, Determining the level of involvement, Determining the messaging frequency based at least partially on the aforementioned involvement status, The method according to claim 15, further comprising determining the time for delivering the guidance message based at least in part on the messaging frequency.

27. moreover, The determination that the aforementioned involvement state has changed to a changed involvement state, Determining a new messaging frequency based at least partially on the aforementioned changed engagement status, To determine the second guidance message, The method according to claim 26, further comprising determining a second time for delivering the second guidance based at least in part on the new messaging frequency.

28. The method according to claim 15, wherein the state is a disease state that describes the host disease stage.

29. moreover, Receiving a second data showing a second glucose concentration level, Applying the second data to the model determines a second disease state that at least partially describes the second host disease stage, The method according to claim 28, comprising determining a second guidance message based at least in part on the second disease state.

30. The method according to claim 15, wherein determining a state includes determining a physiological state.

31. The method according to claim 30, wherein determining the physiological state includes determining the insulin state, the energy absorption state, and the energy expenditure state.

32. The method according to claim 15, further comprising receiving an action input and determining a state, which includes applying both the data and the action input to the model.

33. The method according to claim 32, wherein receiving behavioral input includes receiving patient activity information.

34. A method for distributing guidance on physiological glucose concentration management, Receiving data indicating glucose concentration, Using the aforementioned data to determine the physiological state, Determining the behavioral state, Determining guidance messages based at least partially on the aforementioned physiological state and behavioral state, A method comprising delivering the guidance message using a user interface.

35. The method according to claim 34, further comprising determining the time to deliver guidance that enables timely interventions affecting the glucose concentration.

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

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

38. The method according to claim 34, wherein determining an action state includes receiving an action input and applying the action input to an action state model.

39. The method according to claim 34, wherein determining the action state includes checking the user calendar for scheduled events.

40. The method according to claim 34, wherein determining the physiological state includes applying the data to a physiological state model.

41. The method according to claim 40, wherein the physiological state model includes glucose concentration levels.

42. The method according to claim 41, wherein the physiological state model further includes one or more of the insulin state, the energy absorption state, and the energy consumption state.

43. The method according to claim 34, further comprising determining a measurement state, wherein the measurement state includes the accuracy or precision of the data indicating the glucose concentration.

44. The method according to claim 34, wherein determining a guidance message includes determining that there is a high probability of a low-probability physiological state transition occurring, and the guidance message provides prior notification of the low-probability physiological state transition.

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

46. The method according to claim 44, wherein determining a guidance message includes determining that the low-probability physiological state transition is likely to occur when it is inconvenient, and the guidance message provides advance warning of the expected low-probability physiological state transition so as to enable intervention to avoid the low-probability physiological state transition.

47. The method according to claim 46, wherein determining that the low-probability physiological state transition is likely to occur during an inconvenient time includes applying behavioral inputs to a behavioral state model.

48. The method according to claim 34, further comprising receiving additional physiological parameters, wherein the physiological state is determined using both the data and the additional physiological parameters.

49. The method according to claim 48, wherein the additional physiological parameters include body temperature, heart rate, or respiratory rate.

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

51. A method for determining and providing personalized, useful, and calculated guidance messages to patients for the treatment and management of diabetes, Receiving patient data, including real-time glucose concentration levels, The patient's condition is determined by applying the aforementioned data to a state model, A method comprising providing treatment recommendations based at least partially on the aforementioned determined condition.

52. The method according to claim 51, wherein the patient condition includes an insulin onboard state, an insulin sensitivity state, and a food consumption state.

53. The method according to claim 51, wherein the state model is a probabilistic state model.

54. The method according to claim 53, wherein the state model includes state transition probabilities learned from retrospective data.

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

56. A method for providing users with decision support functions, Loading the model into the memory of the computing environment, Receiving data indicating the glucose concentration value of the aforementioned user, A method comprising displaying insights calculated using at least the model and the data indicating the glucose concentration values ​​on the user interface of the computing environment.

57. The method according to claim 56, wherein the display is initiated by a user request.

58. The method according to claim 57, wherein the user request is associated with data input for a planned activity, and the calculated insights indicate user behavior calculated by one or more models, resulting in a desired outcome associated with the glucose concentration value.

59. The method according to claim 58, wherein the desired result is a glucose concentration value within a predetermined target range.

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

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

62. The method according to claim 58, wherein the calculated insights displayed include at least one factor used for interactive recommendations and for determining the interactive recommendations.

63. The method according to claim 56, wherein displaying the calculated insights is initiated by the occurrence of an event that matches predetermined conditions.

64. The method according to claim 56, wherein displaying the calculated insight is initiated by the occurrence of an event that matches the calculated conditions, and the calculated conditions are calculated at least in part on the model, or the data indicating the glucose concentration value, or a combination thereof.

65. The method according to claim 64, wherein if the treatment adjustment exposes the user to more risks than were present before the treatment adjustment, the warnings and / or alarms are adjusted to have additional sensitivity for a certain period after the treatment adjustment.

66. The method according to claim 64, further comprising detecting if there is a period following the potential treatment decision that triggers more frequent instantiation of the CGM app than before the potential treatment decision, and increasing the frequency of decision support messaging.

67. The method according to claim 66, wherein the messaging is directed to the user or the user's followers.

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

69. The method according to claim 56, further comprising receiving data from an external data source.

70. The method according to claim 69, wherein the external data source is an insulin pen or pump, and the calculated insight includes information regarding insulin onboarding.

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

72. The method according to claim 70, wherein the external data source is an accelerometer and the calculated insight includes information regarding the effect of exercise on glucose concentration values.

73. The method according to 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. The method according to claim 70, wherein the external data source is a user interface, the user interface is configured to receive data relating to the user's goals, and the calculated insights include a percentage of time within the goal range and a display of the goal range.

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

76. The method according to claim 75, wherein 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 variability.

77. The method according to claim 56, wherein the display is based on calculations that are performed periodically.

78. The method according to claim 77, wherein the cycle is determined based on a series of meal times occurring substantially simultaneously.

79. The method according to claim 77, wherein the period is determined based on a series of similar blood glucose responses.

80. The method according to claim 79, wherein the aforementioned similar blood glucose response is a spike.

81. The method according to claim 77, wherein the period is determined based on a series of similar drug administration strategies.

82. The method according to claim 77, wherein the period is determined based on a series of unreliable results in which glucose concentration levels drift over a specified percentage or amount away from the target zone following a potential treatment decision.

83. The method according to claim 56, wherein the display of the calculated insights includes a display of a probability cone based on the user's previous data.

84. The method according to claim 56, wherein the display of the calculated insights includes a display of a probability cone based on collective data.

85. The method according to claim 84, wherein the group data is extracted from persons having one or more demographic characteristics in common with the user.

86. The method according to claim 56, wherein 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.

87. The method according to claim 56, wherein the insight is calculated by the computing environment.

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

89. The method according to claim 56, wherein the model includes a physiological model and a behavioral model.

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

91. The method according to claim 90, wherein the concern regarding the physiological state is determined by detecting the frequency with which diabetes-related applications are checked, or by detecting the frequency with which SMBG values ​​are entered.

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

93. The method according to claim 90, wherein the computing environment is a mobile device, and the method further comprises learning the 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.

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

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

96. It is a system, A glucose concentration sensor configured to detect 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, It is a processor, The host glucose concentration data detected by the glucose concentration sensor is received, Determine the host state changes related to the aforementioned host glucose concentration data, A guidance message is determined based at least partially on the aforementioned host state change. A system comprising a processor configured to deliver the guidance messages via a user interface.

97. The system according to claim 96, wherein the processor is further configured to determine that the host state change is atypical, and the determination of the guidance message is at least partially based on the atypical nature of the state change.

98. The system according to 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 determining the guidance message is at least in part based on the determination that the low-probability state transition has occurred or is likely to occur.

99. The system according to claim 96, wherein determining the host state change includes identifying a likely transition to an undesirable host state, and the guidance message is determined and delivered all at once so that the host can intervene to avoid the transition to the undesirable host state.

100. The system according to claim 96, wherein the system includes a mobile device, and the mobile device includes the memory circuit and the processor.

101. The system according to claim 100, wherein the mobile device includes the communication circuit, and the glucose concentration sensor includes a glucose concentration sensor communication circuit configured to communicate with the communication circuit.

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

103. Furthermore, the system according to claim 96, comprising an insulin delivery system.

104. The system according to claim 96, wherein the state change is a second disease state indicating a second host disease state from a first disease state describing a first host disease state, and the processor is further configured to determine a second guidance message based at least in part on the second disease state.

105. A method for distributing physiological glucose concentration management guidance, Receiving data indicating glucose concentration, The patient's condition is determined by applying the aforementioned data to the model, To determine whether the aforementioned patient condition is atypical, Determining a guidance message based on the atypical nature of the patient's condition, A method comprising delivering the guidance message via a user interface.

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

107. The method according to claim 105, wherein determining whether the patient condition is atypical includes determining whether a low-likelihood state transition has occurred.

108. The method according to claim 105, wherein determining a guidance message includes determining whether a low-likelihood state transition is predicted to occur.

109. The method according to claim 105, wherein determining the patient's condition includes determining the physiological and behavioral states, and determining whether the physiological state is atypical with respect to the determined behavioral state.

110. The method according to claim 105, wherein determining whether the patient condition is atypical includes identifying a blood glucose concentration level that deviates from a controlled blood glucose concentration range over time or under circumstances, when the blood glucose concentration is normally within a controlled range.

111. The method according to claim 105, wherein determining whether the patient condition is atypical includes identifying a blood glucose concentration trend that leads to high or low blood glucose concentration states depending on the time or circumstances, when the blood glucose concentration is normally within a controlled range.

112. The method according to claim 105, wherein determining whether the patient condition is atypical includes predicting a shift to a low blood glucose state, either all at once or depending on the circumstances, when blood glucose levels are normally well controlled.

113. A method for distributing physiological glucose concentration management guidance, Receiving data indicating glucose concentration, The patient's condition is determined by applying the aforementioned data to the model, From the aforementioned model, it is determined that a low-probability state transition has occurred or is highly likely to occur. A method comprising 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. The method according to claim 113, comprising determining that there is a high probability that a low-probability state transition will occur, wherein the guidance message provides prior notification of the low-probability state transition.

115. The method according to claim 113, wherein the low-probability physiological state transition includes a transition to a low glucose concentration level or a high glucose concentration level.

116. The method according to claim 113, wherein determining a guidance message includes determining that the low-probability state transition is likely to occur when it is inconvenient.

117. The method according to claim 116, wherein determining that the low-probability state transition is likely to occur when inconvenient includes referencing a user calendar of scheduled events.

118. The method according to claim 116, wherein determining that the low-probability state transition is likely to occur when it is inconvenient includes referencing a behavioral state model.

119. The method according to claim 113, wherein delivering the guidance message includes determining a period 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.

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

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

122. The method according to claim 120, wherein using the model includes determining a period of time during which the patient or caregiver is likely to be available, using patterns of user activity or user location information.

123. A method for distributing physiological glucose concentration management guidance, Receiving data indicating glucose concentration, Receiving one or more actions, environments, or contextual inputs, The possibility of transitioning to an undesirable patient state is identified by applying the aforementioned data and the one or more behavioral, environmental, or contextual inputs to the model. Determining guidance messages based on the likelihood of the aforementioned transition to an undesirable patient condition, A method comprising delivering the guidance message such that the guidance message is determined and delivered when the patient can intervene to avoid the transition to an undesirable patient condition.

124. The method according to claim 123, wherein receiving behavior, environment, or context input includes receiving accelerometer data.

125. The method according to claim 123, wherein receiving behavior, environment, or context input includes receiving information about a scheduled event from a calendar.

126. The method according to claim 123, wherein receiving behavior, environment, or contextual input includes receiving input from a user via a user interface.

127. The method according to claim 123, wherein receiving behavior, environment, or contextual input includes receiving information from the user about the completion, commencement, or expectation of an action.

128. The method according to claim 123, wherein receiving behavior, environmental, or contextual input includes detecting that a user is driving.

129. The method according to claim 123, wherein receiving one or more actions, environments, or contextual inputs includes receiving location information.

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

131. The method according to claim 123, further comprising receiving body temperature, heart rate, or respiratory rate.

132. The method according to claim 123, further comprising learning the model based on one or more patterns of received information.

133. The method according to claim 132, wherein learning the model includes learning a pattern of insulin sensitivity as a function of time.

134. The method according to claim 133, wherein learning the model includes learning a pattern of insulin sensitivity as a function of time elapsed after a period of physical activity.

135. The method according to claim 123, further comprising determining a user query and providing the user query to the user, wherein the behavior, environment, or context input is received in response to the user query.

136. The method according to claim 123, wherein receiving data indicating glucose concentration includes receiving data from a continuous glucose concentration monitoring system.

137. It is a system, A glucose concentration sensor configured to detect 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, It is a processor, Access the data associated with the host, The state of the host is determined using the aforementioned data. A guidance message is determined based at least partially on the aforementioned determined state. Select the time to provide the aforementioned guidance message, A system comprising: a processor configured to provide the guidance message via a user interface at the selected time;

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

139. The system according to claim 137, wherein determining the guidance message is at least partially based on a personalized behavioral model of the host, and the time is calculated to be useful to the host in the treatment and management of diabetes.

140. The system according to claim 137, wherein determining the aforementioned state is at least partially based on a physiological model of the patient and a behavioral model of the patient.

141. A method for distributing physiological glucose concentration management guidance, Measuring, determining, or receiving first real-time data associated with a patient, The patient's condition is determined using the model and the first real-time data, at least partially. Determining a personalized guidance message, wherein the guidance message is at least partially based on the determined state, A method comprising providing the determined personalized guidance message via a user interface at a time calculated to allow intervention before a transition to an undesirable physiological state.

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

143. The method according to claim 141, wherein the model includes a state that indicates the convenience or availability of the patient participating in the intervention.

144. The method according to claim 141, wherein the guidance message is at least partially based on the predicted transition to the undesirable physiological state.

145. The method according to claim 144, wherein the guidance message is at least partially based on a determination that the expected transition from the current state to the expected state is a low-probability transition.

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

147. The method according to claim 146, wherein the model further includes a behavioral model.

148. The method according to claim 147, wherein the behavioral model is based on the patient's machine learning characteristics, and the machine learning characteristics are based on behavior or contextual patterns.

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

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

151. The method according to claim 147, wherein the behavioral model is a pattern.

152. The method according to claim 147, wherein the physiological model of the patient is based on physiological patterns and the behavioral model is based on behavioral patterns.

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

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

155. The method according to claim 153, wherein the behavior pattern includes a long-term behavior pattern based on a long-term behavior pattern and a short-term behavior pattern related to the current behavior.

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

157. The method according to claim 156, wherein 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 glucose concentration checks, calendar data, and combinations thereof.

158. The method according to claim 147, wherein the determination of the state is further based on a measurement model.

159. The method according to claim 158, wherein the measurement model is based on a continuous glucose concentration monitoring system related to the patient.

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

161. The method according to claim 160, wherein the glucose concentration data measured following the determination is fed back to a measurement model, a behavioral model, a patient physiological model, or a combination thereof.

162. The method according to claim 141, wherein the model includes a pattern selected from the group consisting of physiological patterns, contextual patterns, behavioral patterns, or combinations thereof.

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

164. The method according to 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. The method according to claim 141, wherein determining the guidance message further comprises determining a plurality of guidance messages based on the state and the first real-time data, and further selecting one of the determined plurality of guidance messages based on the state and the first real-time data.

166. The method according to claim 165, wherein 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.

167. The method according to claim 141, further comprising determining the patient's expected diabetic response based on the state and the first real-time data, wherein the guidance message is further personalized to the patient based on the expected diabetic response, and the patient is provided with an actionable message calculated to move the expected diabetic response toward a desired diabetic response.

168. The method according to claim 167, wherein the desired diabetic response is related to the state and the first real-time data, and the desired diabetic response is selected from the group consisting of an improved diabetic response, a potentially improved diabetic response, an ideal response, or an optimized response.

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

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

171. The method according to claim 170, wherein the glucose concentration level related to the desired diabetic response is a target glucose concentration level or a target glucose concentration range.

172. The method according to claim 169, wherein the functional relationship is based on whether the expected diabetic response matches predetermined conditions related to the desired diabetic response.

173. The method according to 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 related to the glucose concentration level.

174. The method according to claim 169, wherein the guidance message further includes one or more reasons relating to the functional relationship, thereby informing the patient of the reason for providing the guidance message.

175. The method according to claim 141, wherein the guidance message includes an actionable prompt.

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

177. The method according to claim 141, wherein the guidance message includes an affirmation of the current behavior related to the patient.

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

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

180. The method according to claim 141, wherein the first real-time data is measured, received, or determined by a wearable device combined with a smartphone.

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

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

183. The method according to claim 141, wherein the first real-time data is time, characteristics or signature signals measured by an accelerometer, or location determined by a GPS circuit.

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

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

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

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

188. The method according to claim 141, further comprising measuring, determining, or receiving second real-time data, wherein the second real-time data is used in determining the patient's condition.

189. The method according to claim 141, wherein it is calculated that providing the determined personalized guidance message is useful for managing the patient's glucose concentration level.

190. The method according to claim 141, wherein the state is a disease state that describes the stage of the patient's illness.

191. moreover, Measure, determine, or receive second real-time data indicating a second glucose concentration level, Applying the second data to the model determines a second disease state that at least partially describes a second patient stage, The method according to claim 190, comprising determining a second guidance message based at least in part on the second disease state.

192. The aforementioned state is an involved state, and further, Determining the messaging frequency based at least partially on the aforementioned involvement status, The method according to claim 141, comprising determining the time to provide the personalized guidance message based at least in part on the messaging frequency.

193. The method according to claim 141, further comprising receiving learning data during the learning period and determining the patient's condition based at least in part on the learning data.

194. A method for determining and delivering personalized, useful, and calculated guidance messages to patients in the treatment and management of diabetes, Learning a personalized behavioral model of the aforementioned patient, Receiving real-time data, Determining a personalized guidance message to be provided to the patient, wherein the determination is at least partially based on the timing of the determination of the personalized guidance message and the patient's personalized behavioral model. A method comprising determining the delivery time for providing the personalized guidance message using the learned personalized behavior model, wherein the delivery time is calculated to be useful to the patient in the treatment management of the patient's diabetes.

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

196. The method according to claim 195, wherein the first characteristic is a pattern selected from the group consisting of physiological patterns, contextual patterns, behavioral patterns, or combinations thereof.

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

198. A method for determining and providing personalized, useful, and calculated guidance messages to patients in the treatment and management of diabetes, Measuring, determining, or receiving first real-time data related to the aforementioned patient, The process involves using a model to determine the patient's state based on a physiological model, a behavioral model, and a measurement model, wherein the state is determined by the patient's physiological model, the behavioral model, and the real-time data. Determining a guidance message, wherein the guidance message is personalized for the patient based on at least the determined state, and the use of the determined state and multiple models enables the personalization of the guidance message. A method comprising providing the determined personalized guidance message via a user interface, such that the provision is calculated to be useful for the treatment management of the patient's diabetes.

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

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

201. The method according to claim 198, wherein the physiological model of the patient is a state model that includes one or more of the following: glucose concentration state, insulin onboard state, insulin sensitivity state, energy absorption state, or energy kinetic state.

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

203. The method according to claim 202, wherein the set of input data includes one or more of the following: clock time, time of day, glucose concentration level, insulin onboard, patient activity, patient health, day of the week, date, day of the week, location, food consumed, or beverage consumed.

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

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

206. The method according to claim 198, wherein providing the determined personalized guidance message includes providing the personalized guidance message to a user interface.

Images