Intermittent surveillance

Abstract

To provide systems and methods for patient monitoring.SOLUTION: An example method includes receiving an estimated glucose concentration level of a patient from a continuous glucose monitoring (CGM) system for a first time period. The method may also include receiving non-glucose information relating to the patient for the first time period, and determining the relationship between the estimated glucose concentration level and the non-glucose information. The method may also include receiving non-glucose information relating to the patient for a second time period, and determining diabetic information about the patient for the second time period on the basis of the determined relationship and the non-glucose information. The method may include electronically delivering a notification about the diabetic information.SELECTED DRAWING: Figure 1

Description

TECHNICAL FIELD

[0001] INCORPORATION BY REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 62 / 782,291 filed on December 19, 2018. The foregoing application is hereby incorporated by reference in its entirety into the present specification and is expressly made a part of the present specification.

[0002] The present development relates generally to medical devices such as analyte sensors, and more specifically, without limitation, to systems, devices, and methods for intermittent use of continuous glucose monitoring systems or other monitoring systems. BACKGROUND ART

[0003] Diabetes is a metabolic condition related to the body's production or use of insulin. Insulin is a hormone that enables the body to use glucose for energy or store glucose as fat.

[0004] When a person eats a meal containing carbohydrates, the food is processed by the digestive system which generates glucose in the person's blood. Blood glucose can be used for energy or stored as fat. The body normally maintains blood glucose levels within a range that provides sufficient energy to support bodily functions and avoids problems that may arise when glucose levels are too high or too low. The regulation of blood glucose levels depends on the production and use of insulin, which regulates the movement of blood glucose into cells.

[0005] Blood glucose levels can rise above the normal range if the body does not produce enough insulin or is unable to effectively use the insulin that is present. A condition where blood glucose levels are higher than normal is called "hyperglycemia." Chronic hyperglycemia can lead to several health problems, including cardiovascular disease, cataracts and other eye problems, nerve damage (neuropathy), and kidney damage. Hyperglycemia can also lead to acute problems such as diabetic ketoacidosis. Diabetic ketoacidosis is a condition in which the body becomes excessively acidic due to the presence of blood glucose and ketones produced when the body is unable to use glucose. A condition where blood glucose levels are lower than normal is called "hypoglycemia." Severe hypoglycemia can cause acute seizures, which can lead to seizures or death.

[0006] Diabetes is sometimes categorized as "type 1" or "type 2." Type 1 diabetes patients can usually use insulin when it is present, but their bodies cannot produce enough insulin due to problems with the insulin-producing beta cells in the pancreas. Type 2 diabetes patients may produce some insulin, but their sensitivity to insulin is reduced, leading to "insulin resistance." As a result, even when insulin is present in the body, it is not used effectively to regulate blood glucose levels.

[0007] Blood glucose levels can be monitored using analyte sensors such as continuous glucose monitors. Continuous glucose monitors can provide the wearer (patient) with information such as estimated blood glucose levels or trends in estimated blood glucose levels.

[0008] 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]

[0009] This document specifically discusses systems, devices, and methods for battery management of analyte sensors, such as glucose sensors.

[0010] Examples of the subject matter (e.g., a method, device, or system) (e.g., “Example 1”) may include the following:

[0011] Example 1 is a method for monitoring diabetic patients. The method may include receiving first data of a first type of patient over a first period. The method may also include receiving second data of a second type of patient over at least a second period. The first and second periods may overlap at least partially with respect to overlapping periods. The method may include determining a correlation between the first and second data over the overlapping periods, receiving second type data at a subsequent time, and determining diabetic information about the patient at least partially based on the second type data at the subsequent time and the determined correlation.

[0012] In Example 2, the subject matter of Example 1 optionally includes an example in which the first data includes high-fidelity continuous glucose monitoring data.

[0013] In Example 3, one or more of the themes from Examples 1-2 may optionally include examples in which the second data includes single-point glucose monitoring, blind CGM, data from a wearable monitor, flash glucose monitoring, or optical monitoring techniques.

[0014] In Example 4, the subject of Example 3 optionally includes an example in which the second data includes single-point glucose monitoring. The method may further include calculating a time window for performing single-point glucose measurement based on the first data.

[0015] In Example 5, one or more of the subjects from Examples 1 to 4 are optionally selected to include examples in which diabetes information is selected from the group consisting of estimated values ​​of a first type of data at subsequent time, patient status, or patient insights.

[0016] In Example 6, the subject matter of Example 5 may optionally include examples where the patient's condition or patient insights relate to lifestyle changes associated with diet, exercise, glucose level monitoring, or medication.

[0017] In Example 7, the subject matter of Example 6 may optionally include examples where the patient's condition or patient insights relate to mealtime management, exercise management, or sleep management.

[0018] In Example 8, one or more of the themes from Examples 1 to 7 may optionally include an example in which the first data is high-fidelity data and the second data is low-fidelity data.

[0019] In Example 9, one or more subjects from Examples 1 to 8 optionally include receiving a sensor signal from a sensor and processing the sensor signal to generate at least a portion of a second data.

[0020] In Example 10, the subject matter of Example 9 is optionally extended to include examples where detection includes activity monitoring by a wearable fitness tracker.

[0021] In Example 11, the subject matter of Example 10 optionally includes examples in which the wearable fitness tracker includes a wearable heart rate monitor, a wearable activity monitor, a smartphone, smart glasses, or a smartwatch.

[0022] In Example 12, one or more of the themes from Examples 1 to 11 may optionally include an example in which determining correlation involves determining a relationship between first and second data obtained at corresponding times and / or days of the week within overlapping periods.

[0023] In Example 13, one or more of the themes from Examples 1 to 12 may optionally include an example in which the second data includes user input data.

[0024] In Example 14, the subject matter of Example 13 optionally includes an example in which user input data includes drug data, diet data, exercise data, sleep data, or any combination thereof.

[0025] In Example 15, one or more subjects from Examples 1 to 14 optionally include intermittently monitoring a first type of data and determining diabetes information using a second type of data and correlations during periods when the first type of data is unavailable.

[0026] In Example 16, the subject of Example 15 optionally includes an example in which the intermittent monitoring of a first type of data includes intermittent continuous glucose monitoring, and the second type of monitoring data includes monitoring activity data by a wearable accelerometer, and optionally includes an example in which the wearable accelerometer is configured to monitor data at least when continuous glucose monitoring is not being performed.

[0027] In Example 17, the subject matter of any one or more of Examples 1 to 16 optionally includes examples in which the first-type first data includes an estimated glucose concentration level, and the second-type data includes heart rate, oxygen concentration, skin tension, skin moisture content, activity, activity pattern, blood ketones, urine ketones, respiration, or acoustic information.

[0028] In Example 18, the subject matter of any one or more of Examples 1 to 17 optionally includes monitoring the first data and the second data over a third period, and updating a correlation based on the first data and the second data from the third period.

[0029] In Example 19, the subject matter of any one or more of Examples 1 to 18 optionally includes administering a therapy based at least in part on the determined diabetes information.

[0030] In Example 20, the subject matter of Example 19 optionally includes examples in which the therapy comprises pharmaceutical intervention.

[0031] In Example 21, the subject matter of any one or more of Examples 19 to 20 optionally includes displaying diabetes information related to the patient on a user interface of a patient device.

[0032] In Example 22, the subject matter of Example 21 optionally includes displaying recommended dietary changes or lifestyle changes on the user interface.

[0033] Example 23 is a method that may include receiving an estimated glucose concentration level of a patient from a continuous glucose monitoring (CGM) system during a first period, and receiving non-CGM information relevant to the patient during the first period. The method may also include determining a relationship between the estimated glucose concentration level and the non-CGM information. The method may also include receiving non-CGM information relevant to the patient during a second period when the estimated glucose concentration level is not available from the CGM, and determining diabetes information about the patient during the second period based on the determined relationship and the non-CGM information. The method may further include electronically delivering a notification regarding the diabetes information.

[0034] In Example 24, the subject matter of Example 23 optionally includes an example where non-CGM information includes activity information.

[0035] In Example 25, one or more of the themes from Examples 23 to 24 may optionally include examples in which non-CGM information includes physiological information about the patient.

[0036] In Example 26, the subject of Example 25 optionally includes examples in which physiological information includes one or more of the following: heart rate, respiration, oxygen concentration, skin tension, skin water content, activity, activity pattern, blood ketones, urinary ketones, respiration, or acoustic information.

[0037] In Example 27, one or more of the themes from Examples 23 to 26 may optionally include examples in which non-CGM information includes location information.

[0038] In Example 28, one or more of the themes from Examples 23 to 27 may optionally include an example in which receiving non-CGM information includes receiving user input data.

[0039] In Example 29, one or more of the themes from Examples 23 to 28 may optionally include examples in which determining a patient's diabetes information includes determining the patient's condition.

[0040] In Example 30, one or more of the themes from Examples 23 to 29 may optionally include an example in which determining the patient's condition involves applying non-CGM information to the model.

[0041] In Example 31, one or more of the themes from Examples 23 to 30 may optionally include an example in which determining diabetes information involves determining an estimated glucose concentration level.

[0042] In Example 32, one or more of the themes from Examples 23 to 31 may optionally include examples in which determining diabetes information includes determining quantitative evaluation.

[0043] In Example 33, one or more of the themes from Examples 23 to 32 may optionally include examples in which determining diabetes information involves determining a quantitative metric.

[0044] In Example 34, the subject matter of Example 33 optionally includes an example where the quantitative metric is an estimate of the amount or percentage of time during a specified period that the glucose concentration level was within a range.

[0045] Example 35 is a system comprising an intermittent primary subsystem configured to intermittently collect primary physiological information from a host, and a secondary subsystem configured to collect a second type of secondary data from the host. The system may also include a user interface configured to display guidance based on the secondary data and primary physiological information.

[0046] In Example 36, the subject of Example 35 includes a guidance system configured to optionally receive secondary data and primary physiological information, and to determine guidance based at least partially on the secondary data and primary physiological information.

[0047] In Example 37, the subject matter of Example 36 optionally includes an example in which the guidance system determines the relationship between secondary data and primary physiological information, and determines guidance based at least partially on the secondary data and the relationship between the secondary data and primary physiological information during periods when intermittent primary physiological information is unavailable.

[0048] In Example 38, the subject matter of Example 37 optionally includes an example in which the primary subsystem includes a continuous glucose monitor (CGM), and the guidance system determines diabetes management information based at least partially on secondary data and the relationship between the secondary data and primary physiological information.

[0049] In Example 39, the subject matter of Example 38 is optionally extended to include an example in which diabetes management information includes estimated glucose concentration levels.

[0050] In Example 40, one or more of the themes from Examples 38 to 39 may be optionally included in the example where diabetes management information includes quantitative evaluation.

[0051] In Example 41, one or more of the themes from Examples 38 to 40 may optionally include examples in which diabetes management information includes metrics.

[0052] In Example 42, the subject matter of Example 41 optionally includes an example in which the diabetes management information includes a range-time metric that shows an estimate of the amount or percentage of time during a specified period that the glucose concentration level was within a range.

[0053] In Example 43, one or more of the themes from Examples 41 to 42 may optionally include examples in which diabetes management information includes statistical feedback.

[0054] In Example 44, one or more of the themes from Examples 35 to 43 may optionally include an example in which a secondary subsystem includes a sensor and a memory circuit, and the secondary subsystem determines secondary data from data received from the sensor and stores the received sensor data or secondary data in the memory circuit.

[0055] In Example 45, one or more themes from Examples 35 to 44 may optionally include an example in which the primary subsystem includes a continuous glucose monitor (CGM), a memory circuit, the primary subsystem receives a CGM sensor signal indicating the host glucose concentration, determines an estimated glucose concentration level based at least partially on the CGM sensor signal, stores a plurality of estimated glucose concentration levels in the memory circuit, and the primary physiological information includes or is based on a plurality of estimated glucose concentration levels.

[0056] Example 46 is a patient management device comprising a sensor, a user interface, a communication circuit, and a processor. The processor can execute instructions to perform operations. Operations may include transmitting information to a second device based on input from a sensor using the communication circuit, and receiving estimates of the physiological state based at least partially on input from the sensor using the communication circuit. Operations may also include delivering information related to the estimates of the physiological state using the user interface.

[0057] In Example 47, the subject matter of Example 46 optionally includes an example where the sensor is an activity sensor.

[0058] In Example 48, one or more of the themes from Examples 46 to 47 are optionally included in the example where the estimate of the physiological state is a glucose concentration level.

[0059] In Example 49, one or more of the themes from Examples 46 to 48 may optionally include examples where the information regarding the estimate of a physiological state is in the range of time, glucose concentration level, or glucose concentration range.

[0060] In Example 50, one or more of the themes from Examples 46 to 49 are optionally included in examples where estimates of physiological state are based on correlations between previously collected glucose concentration information and previously collected activity information.

[0061] In Example 51, one or more of the themes from Examples 46 to 50 optionally include an example in which the device is wearable.

[0062] In Example 52, the subject of Example 51 optionally includes an example where the device is a clock.

[0063] In Example 53, one or more subjects from Examples 46 to 52 optionally further include an example in which the operation comprises: generating a sensor message containing an estimate of a physiological state by a first application executed by a processor; transmitting the sensor message by the first application to a second application executed by a processor; and transmitting a device message by the second application to a second device for display using a user interface.

[0064] In Example 54, the subject matter of Example 53 optionally includes an example in which generating a sensor message encrypts an estimate of a physiological state.

[0065] In Example 55, one or more themes from Examples 53 to 54 may optionally include an example in which generating a sensor message involves generating an error detection code based at least partially on a physiological state.

[0066] Example 56 is a method for monitoring a patient. The method may include monitoring a first type of patient data over a first period using low-fidelity monitoring techniques and evaluating patient engagement or patient behavior based on the monitored first type of patient data. The method may also include monitoring a second type of patient data over a second period using high-fidelity monitoring techniques with a monitoring device. In some examples, at least one hardware or software function of the monitoring device is based on the evaluated patient engagement or patient behavior during monitoring.

[0067] In Example 57, the subject matter of Example 56 optionally includes an example in which at least one hardware or software function corresponds to the operation of the user interface.

[0068] In Example 58, one or more of the themes from Examples 56-57 may optionally include an example where the high-fidelity monitoring technique is continuous glucose monitoring.

[0069] In Example 59, one or more of the themes from Examples 56 to 58 may optionally include examples in which the low-fidelity technique includes single-point glucose monitoring, blind CGM, or optical monitoring techniques.

[0070] In Example 60, one or more of the themes from Examples 56 to 59 may optionally include an example in which the low-fidelity monitoring technique includes activity monitoring using a wearable fitness tracker.

[0071] In Example 61, the subject of Example 60 optionally includes examples where the wearable fitness tracker is a wearable heart rate monitor, activity monitor, smartphone, smart glasses, or smartwatch.

[0072] In Example 62, one or more of the themes from Examples 56 to 61 optionally include an example in which the low-fidelity monitoring technique receives user input data.

[0073] In Example 63, the subject matter of Example 62 optionally includes examples in which the received user input data includes drug data, diet data, exercise data, sleep data, or any combination thereof.

[0074] In Example 64, one or more of the themes from Examples 56 to 63 optionally include determining a patient's goal, and at least one hardware or software function of the monitoring device is related to the goal.

[0075] In Example 65, the subject matter of Example 64 optionally includes examples where the goal includes a dietary goal, an exercise goal, a glucose level monitoring goal, or a medication goal.

[0076] In Example 66, the subject matter of Example 65 optionally includes an example in which at least one hardware or software function of the monitoring device relates to mealtime glucose management.

[0077] In Example 67, one or more of the themes from Examples 65 to 66 may optionally include an example in which at least one hardware or software function of the monitoring device relates to sleep management.

[0078] In Example 68, one or more of the themes from Examples 64-67 optionally include an example in which the patient's goals are determined before the first period of monitoring.

[0079] In Example 69, one or more of the themes from Examples 64 to 68 are optionally included in an example in which the patient's goal is determined by a first type of data monitored over a first period using a low-fidelity monitoring technique.

[0080] In Example 70, one or more subjects from Examples 56-69 optionally include monitoring physiological type patient data over a first period, and the basis of at least one hardware or software function of the monitoring device is further based on physiological type patient data.

[0081] In Example 71, one or more of the themes from Examples 56 to 70 optionally include an example in which at least one hardware or software function relates to the frequency or content of an automated coaching routine.

[0082] In Example 72, one or more themes from Examples 56 to 71 are optionally selected to include detecting changes in patient parameters, the changes being measured between a first period and a second period, and using the detected changes to further influence at least one hardware or software function of a monitoring device.

[0083] In Example 73, one or more subjects from Examples 56 to 72 optionally include providing a coaching function to a patient over a first period, the coaching function including automated messages transmitted from a server to a monitoring device based on patient profile data or a first type of patient data or a combination thereof.

[0084] In Example 74, one or more of the themes from Examples 56 to 73 optionally include determining the quantity or frequency of subsequent data after a second period, wherein the quantity or frequency of subsequent data is determined using low-fidelity or high-fidelity monitoring techniques, and the quantity or frequency is calculated to increase or maximize the patient parameter.

[0085] In Example 75, the subject of Example 74 is optionally included in the example where the patient parameter is within the time range.

[0086] In Example 76, the subject matter of Example 75 optionally includes an example in which the quantity or frequency of subsequent data is determined using a low-fidelity monitoring technique.

[0087] In Example 77, the subject matter of Example 76 optionally includes an example in which the quantity or frequency of subsequent data is represented by several sensors.

[0088] In Example 78, one or more subjects from Examples 74-77 are optionally selected as examples where the patient parameter is A1c.

[0089] In Example 79, the subject matter of Example 78 optionally includes an example in which the quantity or frequency of subsequent data is determined using fidelity monitoring techniques.

[0090] In Example 80, one or more of the themes from Examples 74 to 79 optionally include displaying an increased or maximized indicator of a patient parameter on a monitoring device.

[0091] In Example 81, one or more subjects from Examples 74 to 80 may optionally include determining a patient's final goal after a second period, the patient's final goal depending at least in part on a first type of patient data or a second type of patient data, and displaying recommended treatments calculated to cause a transition in the patient's state toward the patient's final goal.

[0092] Example 82 is a system comprising a first system configured to collect a first set of first type sensor data related to a patient, and a second system configured to collect a second set of second type sensor data related to a patient. The system may further include a decision system configured to determine user parameters for the second system based on the first set of sensor data.

[0093] In Example 83, the subject matter of Example 82 optionally includes an example in which the first system includes an activity sensor.

[0094] In Example 84, one or more of the themes from Examples 82 to 83 are optionally included in the example in which the first system includes a blood glucose meter.

[0095] In Example 85, one or more of the themes from Examples 82 to 84 may optionally include an example in which the second system includes a continuous glucose monitor.

[0096] In Example 86, one or more of the themes from Examples 82 to 85 may optionally include an example in which the user parameters include a schedule for using the second system.

[0097] In Example 87, one or more of the themes from Examples 82 to 86 optionally include an example where the user parameter is the time to start using the second system.

[0098] In Example 88, one or more of the themes from Examples 82 to 87 may optionally include an example in which the decision system applies a first set of sensor data to a model.

[0099] In Example 89, one or more subjects from Examples 82-88 optionally include a third system configured to collect a third set of patient-related sensor data, and the decision system determines user parameters based at least partially on the first set of sensor data and the third set of data.

[0100] Example 90 is a patient management device. The patient management device may include sensors, a user interface, a communication circuit, and a processor. The processor may execute instructions, receive information about the subject using the communication circuit, and use the user interface to deliver information related to the management of the physiological state based on the received information about the subject and data from the sensors.

[0101] In Example 91, the subject matter of Example 90 optionally includes an example where the sensor is an activity sensor.

[0102] In Example 92, one or more of the themes from Examples 90 to 91 optionally include an example in which the device is wearable.

[0103] In Example 93, the subject of Example 92 optionally includes an example where the device is a clock.

[0104] In Example 94, one or more of the subjects from Examples 90 to 93 optionally include an example in which the processor further executes instructions and uses information about the subject to determine the configuration of the user interface.

[0105] In Example 95, the subject matter of Example 94 optionally includes an example in which the device displays a specified set of metrics based on previously collected low-fidelity data.

[0106] In Example 96, one or more of the themes from Examples 94 to 95 optionally include an example in which a device delivers information at a specified time based on previously collected low-fidelity data.

[0107] In Example 97, one or more of the themes from Examples 94 to 96 may optionally include an example in which the device notifies a patient management facilitator about the availability of estimates of the patient's physiological state and presents guidance from the patient management facilitator using a user interface.

[0108] In Example 98, one or more of the themes from Examples 90 to 97 are optionally included in the example where the estimate of the physiological state is a glucose concentration level.

[0109] Example 99 is a method for selecting patients who are likely to benefit from intermittent high-fidelity monitoring. The method may include running a first screening algorithm on a pool of participants to determine a group of patients who have diabetes or risk factors for diabetes. The method may also include providing participants in the determined group with a first kit, which is structured and configured to enable participants to perform low-fidelity monitoring of their health for a first period using a first monitoring technique, and obtaining first results. The method may also include running a second screening algorithm on the determined group to determine a cohort for participation in intermittent high-fidelity monitoring, which the second screening algorithm uses at least partially the obtained first results, and subsequently providing participants in the determined cohort with a second kit, which is structured and configured to enable participants in the determined cohort to perform high-fidelity monitoring of their health for a second period using a second monitoring technique, and obtaining second results. The method may also include providing a third kit to one or more participants in the determined cohort, the one or more participants being determined at least in part according to the second results obtained.

[0110] In Example 100, the subject of Example 99 optionally includes an example where high-fidelity monitoring is continuous glucose monitoring.

[0111] In Example 101, one or more subjects from Examples 99-100 are optionally included in an example that involves determining the estimated likelihood that a patient would benefit from high-fidelity monitoring by performing a second screening.

[0112] In Example 102, one or more subjects from Examples 99 to 101 are optionally included in examples in which a second kit is structured and configured based on the first results obtained.

[0113] In Example 103, one or more subjects from Examples 99 to 102 are optionally included in examples in which a third kit is structured and configured based on the second results obtained.

[0114] In Example 104, one or more subjects from Examples 99-103 optionally include performing communication between a server and a device in the first kit during at least a first period, the communication providing a guidance message to the patient.

[0115] In Example 105, one or more subjects from Examples 99 to 104 may optionally include examples in which low-fidelity monitoring includes single-point glucose monitoring, heart rate monitoring, activity monitoring, blind continuous glucose monitoring, or any combination thereof.

[0116] In Example 106, one or more of the themes from Examples 99 to 105 optionally include displaying an output to a patient, the displayed output relating to diet, exercise, glucose level monitoring, or medication.

[0117] In Example 107, one or more of the themes from Examples 99 to 106 optionally include displaying an output to the patient, the displayed output indicating an optimized period during which the patient should engage in high-fidelity monitoring.

[0118] In Example 108, one or more subjects from Examples 99 to 107 optionally include an example in which the algorithm employs one or more factors selected from the group consisting of electronic health records, type II diabetes diagnostic codes, family history, weight, BMI, history of metabolic diseases, blood test results, A1c, fasting glucose levels, oral glucose tolerance, prescribed diabetes medications, or any combination thereof.

[0119] In Example 109, one or more of the themes from Examples 99 to 108 are optionally included in the example in which the second screening algorithm is at least partially based on a factor of compliance with the use of low-fidelity monitoring during the first period.

[0120] Example 110 is a method for managing parameters related to a patient's health, the method comprising a stage of intermittent high-fidelity monitoring. The method may first include monitoring the patient and obtaining a first result during a first period using a first monitoring technique. The method may also include monitoring the patient and obtaining a second result during a second period using a second monitoring technique. The method may also include determining actions the patient may take, the actions being based on the obtained first and second results, and the actions being calculated to increase the likelihood of satisfying the management conditions. In some examples, high-fidelity monitoring is included in either the first or second monitoring technique.

[0121] In Example 111, the subject matter of Example 110 optionally includes an example in which high-fidelity monitoring includes continuous glucose monitoring.

[0122] In Example 112, one or more of the themes from Examples 110 to 111 optionally include displaying an output to the patient, the displayed output indicating patient performance in relation to dietary goals, exercise goals, glucose level monitoring goals, or medication goals.

[0123] In Example 113, one or more subjects from Examples 110 to 112 are optionally selected from the group consisting of time within range and blood glucose variability, in which patient health-related parameters are selected.

[0124] In Example 114, one or more of the themes from Examples 110 to 113 may optionally include examples in which satisfaction of a control condition reduces a patient health-related parameter by a greater than predetermined amount with a confidence level higher than a predetermined confidence level.

[0125] In Example 115, one or more of the themes from Examples 110-114 optionally include patient selection. In some examples, patient selection is performed by determining patients from a pool of patients who are likely to benefit from intermittent high-fidelity monitoring, and the probability is greater than a calculated value.

[0126] In Example 116, one or more of the themes from Examples 110 to 115 optionally include an example in which the first period is a subset of the second period.

[0127] In Example 117, one or more of the themes from Examples 110 to 116 are optionally included in the example where the first period overlaps with the second period.

[0128] In Example 118, one or more subjects from Examples 110 to 117 optionally include performing communication between a server and a device associated with a patient during a first period, a second period, or both, the communication providing the patient with coaching capabilities.

[0129] In Example 119, one or more of the themes from Examples 110 to 118 optionally include displaying an output to the patient, the displayed output indicating an optimized period during which the patient should engage in high-fidelity monitoring.

[0130] In Example 120, one or more of the themes from Examples 110 to 119 may optionally include an example in which the first monitoring technique is a low-fidelity monitoring technique and the second monitoring technique is high-fidelity monitoring.

[0131] In Example 121, the subject of Example 120 optionally includes examples in which low-fidelity monitoring techniques include single-point glucose monitoring or blind CGM.

[0132] In Example 122, one or more of the themes from Examples 120 to 121 may optionally include an example in which the low-fidelity monitoring technique includes activity monitoring using a wearable fitness tracker.

[0133] In Example 123, the subject of Example 122 optionally includes examples where the wearable fitness tracker is a wearable heart rate monitor, activity monitor, smartphone, smart glasses, or smartwatch.

[0134] In Example 124, one or more subjects from Examples 120 to 123 optionally include correlating acquired first and second results, the correlation including determining the relationship between the acquired first and second results at the corresponding time and / or day of the week, and determining the estimated value of the high-fidelity monitoring technique at a given time, based at least in part on the correlation value and the results acquired by the low-fidelity monitoring technique.

[0135] In Example 125, the subject of Example 124 optionally includes determining an estimated value based at least partially on population data.

[0136] In Example 126, one or more of the themes from Examples 120 to 125 may optionally include an example in which the low-fidelity monitoring technique receives user input data.

[0137] In Example 127, the subject matter of Example 126 optionally includes examples in which the received user input data includes drug data, diet data, exercise data, sleep data, or any combination thereof.

[0138] In Example 128, one or more subjects from Examples 120 to 127 optionally include correlating acquired first and second results, the correlation including determining the relationship between the acquired first and second results at the corresponding time or day of the week, and determining an estimated value of the correlation value at a given time and an estimated value of the high-fidelity monitoring technique at a given time, based at least in part on the results acquired by the low-fidelity monitoring technique.

[0139] In Example 129, the subject of Example 128 optionally includes determining an estimated value based at least in part on population data.

[0140] Example 130 is a method for measuring parameters related to a patient's health. The method may include detecting, by an analyte sensor system, that the analyte sensor system has been applied to a host. The method may also include storing analyte data describing the host by the analyte sensor system, determining by the analyte sensor system that the use of the sensor in the analyte sensor system has ended, and uploading the stored analyte data to an upload computing device by the analyte sensor system.

[0141] In Example 131, the subject of Example 130 optionally includes, in response to determining that sensor use in the analyte sensor system has ended, broadcasting system identification data by the analyte sensor system; receiving a communication request containing system identification data from the upload computing device and the analyte sensor system; and establishing a communication session with the upload computing device in response to the communication request by the analyte sensor system, wherein uploading transmits the stored analyte data to the upload computing device.

[0142] In Example 132, one or more subjects from Examples 130 to 131 may optionally include, after determining that sensor use in the analyte sensor system has ended, the analyte sensor system receiving an upload request from an upload computing device, the analyte sensor system broadcasting system identification data, and receiving authentication data from the upload computing device. The method may also include the analyte sensor system establishing a communication session with the upload computing device, and uploading means transmitting the stored analyte data to the upload computing device.

[0143] Example 133 is a method comprising: receiving the patient's estimated glucose concentration level from a continuous glucose monitoring (CGM) system in a first period; receiving patient-related non-glucose information in a first period; determining the relationship between the estimated glucose concentration level and the non-glucose information; receiving patient-related non-glucose information in a second period; determining diabetes information about the patient in a second period based on the determined relationship and the non-glucose information; and electronically distributing a notification regarding diabetes information.

[0144] In Example 134, the subject of Example 133 optionally includes receiving multiple estimated glucose concentration levels from a CGM system from a first period, and receiving non-glucose information in the first period includes receiving at least one single-point glucose measurement taken during the first period.

[0145] In Example 135, one or more of the themes from Examples 133-134 optionally include the fact that the estimated glucose concentration level is not available from the CGM during the second period.

[0146] In Example 136, one or more subjects from Examples 133 to 135 optionally include receiving second non-glucose information related to the patient during a first period, the second non-glucose information being different from the non-glucose information, and the relationship being between the estimated glucose concentration level, the non-glucose information and the second non-glucose information.

[0147] In Example 137, one or more of the themes from Examples 133 to 136 optionally include non-glucose information that includes physiological information about the patient.

[0148] In Example 138, the subject of Example 137 optionally includes physiological information comprising at least one of the following: heart rate, respiration, oxygen concentration, skin tension, skin water content, activity, activity pattern, blood ketones, urinary ketones, respiration, or acoustic information.

[0149] In Example 139, one or more themes from Examples 133 to 138 optionally include non-glucose information including location information.

[0150] In Example 140, one or more of the themes from Examples 133 to 139 optionally include determining diabetes information, which involves determining an estimated glucose concentration level.

[0151] In Example 141, one or more of the themes from Examples 133 to 140 optionally include determining diabetes information by determining an estimate of the amount or percentage of time during a specified period when glucose concentration levels were within a specified range.

[0152] Example 142 is a system comprising: a primary subsystem configured to intermittently collect primary physiological information from a host; a secondary subsystem configured to collect a second type of secondary data from the host; a guidance system configured to determine guidance based at least in part on the primary physiological information and the secondary data; and a user interface configured to display the guidance.

[0153] In Example 143, the subject matter of Example 142 is optionally configured to also determine the relationship between secondary data and primary physiological information, and to determine guidance during periods when primary physiological information is not collected, wherein the determination of guidance is at least partially based on the secondary data and the relationship between the secondary data and primary physiological information.

[0154] In Example 144, one or more subjects from Examples 142 to 143 optionally include a primary subsystem comprising a continuous glucose monitor (CGM), and a guidance system configured to determine the patient's condition at least partially based on secondary data and the relationship between the secondary data and primary physiological information.

[0155] In Example 145, the subject of Example 144 optionally includes the patient's condition being an estimated glucose concentration level.

[0156] In Example 146, one or more of the themes from Examples 144 to 145 optionally include a range-of-care time metric that indicates an estimate of the amount or percentage of time during a specified period that the patient's condition was within a range of glucose concentration levels.

[0157] In Example 147, one or more subjects from Examples 142 to 146 optionally include a secondary subsystem comprising a sensor and a memory circuit, wherein the secondary subsystem is configured to determine secondary data from sensor data received from the sensor and to store the sensor data or secondary data in the memory circuit.

[0158] In Example 148, one or more subjects from Examples 142 to 147 are optionally configured such that the primary subsystem includes a continuous glucose monitor (CGM) and a memory circuit, and the primary subsystem receives a CGM sensor signal indicating the host glucose concentration, determines an estimated glucose concentration level based at least in part on the CGM sensor signal, and stores a plurality of estimated glucose concentration levels in the memory circuit, and the primary physiological information includes or is based on a plurality of estimated glucose concentration levels.

[0159] Embodiment 149 is a machine-readable storage medium that stores instructions, and when the instructions are executed by at least one processor, causes at least one processor to perform operations including: in a first period, receiving an estimated glucose concentration level of a patient from a continuous glucose monitoring (CGM) system; in a first period, receiving non-glucose information related to the patient; determining the relationship between the estimated glucose concentration level and the non-glucose information; in a second period, receiving non-glucose information related to the patient; in a second period, determining diabetes information about the patient based on the determined relationship and the non-glucose information; and electronically delivering a notification regarding diabetes information.

[0160] In Example 150, the subject of Example 149 optionally further includes the operation of receiving multiple estimated glucose concentration levels from a CGM system from a first period, receiving non-glucose information in the first period, and receiving at least one single-point glucose measurement taken during the first period.

[0161] In Example 151, one or more of the themes from Examples 149 to 150 optionally include an operation that further includes determining guidance based at least partially on diabetes information and displaying the guidance on a user interface.

[0162] In Example 152, one or more subjects from Examples 149 to 151 optionally include receiving second non-glucose information related to the patient during a first period, wherein the second non-glucose information differs from the non-glucose information in that the relationship is between the estimated glucose concentration level, the non-glucose information, and the second non-glucose information.

[0163] Example 153 is a patient management system comprising an analyte sensor and a processor, wherein the processor executes instructions to receive sensor data indicating the user's analyte concentration from the analyte sensor and by a first application executed on the processor; transmit a sensor message containing an index of the analyte concentration to a second application executed on the processor and by the first application; and deliver a device message to a wearable activity monitoring device and by the second application, the device message being at least partially based on the analyte concentration.

[0164] In Example 154, the subject of Example 153 optionally further includes a wearable activity monitoring device, the wearable activity monitoring device includes a motion sensor, and the wearable activity monitoring device is programmed to generate a user interface that includes data based at least in part on device messages and data based at least in part on the output of the motion sensor.

[0165] In Example 155, one or more subjects from Examples 153 to 154 optionally further include an operation that generates physiological state data describing an estimate of the user's physiological state, wherein the generation is at least partially based on the user's analyte concentration.

[0166] In Example 156, the subject of Example 155 optionally includes the fact that physiological state data is generated by the first application and the sensor message includes physiological state data.

[0167] In Example 157, one or more themes from Examples 155 to 156 optionally include the fact that physiological state data is generated by a second application and a device message includes physiological state data.

[0168] In Example 158, one or more of the themes from Examples 155 to 157 optionally include physiological state data that include a range of time, glucose concentration level, or glucose concentration range.

[0169] In Example 159, one or more themes from Examples 155 to 158 optionally include the generation of physiological state data based on a correlation between previously collected glucose concentration information and previously collected activity information.

[0170] In Example 160, one or more themes from Examples 153 to 159 optionally include the device message including display data for display in the user interface of a wearable activity monitoring device.

[0171] In Example 161, one or more themes from Examples 153 to 160 optionally include generating a sensor message which includes encrypting an indicator of analyte concentration.

[0172] In Example 162, one or more themes from Examples 153 to 161 optionally include generating a sensor message that generates an error detection code based at least partially on the analyte concentration.

[0173] Example 163 is a patient management method comprising: receiving sensor data indicating the user's analyte concentration from an analyte sensor via a first application running on a patient management system; transmitting a sensor message containing an index of the analyte concentration via the first application to a second application running on the patient management system; and delivering a device message via the second application to a wearable activity monitoring device, wherein the device message is at least partially based on the analyte concentration.

[0174] In Example 164, the subject matter of Example 163 optionally includes a wearable activity monitoring device including a motion sensor, and further includes the wearable activity monitoring device generating a user interface including data at least partially based on device messages and data at least partially based on the output of the motion sensor.

[0175] In Example 165, one or more of the themes from Examples 163 to 164 optionally include generating physiological state data that describes an estimate of the user's physiological state, and the generation is at least partially based on the user's analyte concentration.

[0176] In Example 166, the subject of Example 165 optionally includes the fact that physiological state data is generated by the first application and the sensor message includes physiological state data.

[0177] In Example 167, one or more themes from Examples 165 to 166 optionally include the fact that physiological state data is generated by a second application and a device message includes physiological state data.

[0178] In Example 168, one or more of the themes from Examples 165 to 167 optionally include physiological state data that include a range of time, glucose concentration level, or glucose concentration range.

[0179] In Example 169, one or more themes from Examples 165 to 168 optionally include the generation of physiological state data based on a correlation between previously collected glucose concentration information and previously collected activity information.

[0180] In Example 170, one or more of the themes from Examples 163 to 169 optionally include the device message including display data for display in the user interface of a wearable activity monitoring device.

[0181] In Example 171, one or more of the themes from Examples 163 to 170 optionally include generating a sensor message that generates an error detection code based at least in part on the analyte concentration.

[0182] Embodiment 172 is a machine-readable storage medium storing instructions, the instructions causing at least one processor to perform an operation including receiving sensor data indicating a user's analyte concentration from an analyte sensor by a first application running in a patient management system and from an analyte sensor, transmitting a sensor message containing an index of the analyte concentration by the first application and to a second application running in a patient management system, and delivering a device message by the second application and to a wearable activity monitoring device, wherein the device message is at least partially based on the analyte concentration.

[0183] Example 173 is a method for monitoring a patient, comprising: monitoring a first type of patient data over a first period using a low-fidelity monitoring technique; evaluating patient behavior based on the monitored first type of patient data; and monitoring a second type of patient data over a second period using a continuous glucose monitoring device, wherein the parameters of the continuous glucose monitoring device are based on the evaluated patient behavior during monitoring.

[0184] In Example 174, the subject of Example 173 optionally includes the fact that the parameters of the continuous glucose monitoring device correspond to the operation of the user interface.

[0185] In Example 175, one or more of the themes from Examples 173 to 174 optionally include a low-fidelity monitoring technique comprising at least one of single-point glucose monitoring, blind continuous glucose monitoring, or optical monitoring techniques.

[0186] In Example 176, one or more of the themes from Examples 173 to 175 optionally include the low-fidelity monitoring technique including activity monitoring by a wearable fitness tracker.

[0187] In Example 177, the subject of Example 176 optionally includes a wearable fitness tracker comprising at least one of the following: a wearable heart rate monitor, an activity monitor, a smartphone, smart glasses, or a smartwatch.

[0188] In Example 178, one or more of the themes from Examples 173 to 177 optionally include the low-fidelity monitoring technique receiving user input data which includes at least one of the following: medication data, diet data, exercise data, or sleep data.

[0189] In Example 179, one or more of the themes from Examples 173 to 178 optionally include determining a patient's goal, and the parameters of a continuous glucose monitoring device are related to the goal.

[0190] In Example 180, the subject of Example 179 optionally includes that the goal includes a dietary goal, an exercise goal, a glucose level monitoring goal, or a medication goal.

[0191] In Example 181, one or more subjects from Examples 179-180 optionally include determining patient goals based at least in part on first type data monitored over a first period using low-fidelity monitoring techniques.

[0192] In Example 182, one or more of the themes from Examples 173 to 181 optionally include determining parameters for a continuous glucose monitoring device by determining at least one parameter for an automated coaching routine.

[0193] In Example 183, one or more subjects from Examples 173 to 182 optionally include detecting changes in patient parameters between a first period and a second period, and using the detected changes in patient parameters to determine the parameters of a continuous glucose monitoring device.

[0194] In Example 184, one or more subjects from Examples 173 to 183 optionally include providing a coaching function to a patient over a first period, the coaching function including automated messages transmitted from a server to a continuous glucose monitoring device, and the coaching function being based on patient profile data or a first type of patient data or a combination thereof.

[0195] Example 185 is a system comprising: a low-fidelity system configured to collect a first set of a first type of sensor data related to a patient over a first period; a continuous glucose monitoring device configured to collect a second set of a second type of sensor data related to the patient; and a decision system configured to determine the parameters of the continuous glucose monitoring device based on the first set of sensor data.

[0196] In Example 186, the subject of Example 185 optionally includes the inclusion of a low-fidelity system with an activity sensor.

[0197] In Example 187, one or more of the themes from Examples 185 to 186 optionally include a low-fidelity system that includes a blood glucose meter.

[0198] In Example 188, one or more of the themes from Examples 185 to 187 optionally include the continuous glucose monitoring device including a continuous glucose monitor.

[0199] In Example 189, one or more of the themes from Examples 185 to 188 optionally include a parameter that includes a schedule for the use of a continuous glucose monitoring device.

[0200] In Example 190, one or more of the themes from Examples 185 to 189 optionally include the parameter being the time to start using a continuous glucose monitoring device.

[0201] In Example 191, one or more subjects from Examples 185-190 optionally include a third system configured to collect a third set of patient-related sensor data, and the decision system determines parameters based at least partially on the first set of sensor data and the third set of sensor data.

[0202] Embodiment 192 is a machine-readable storage medium storing instructions, wherein, when executed by at least one processor, the instructions cause at least one processor to perform an operation including monitoring a first type of patient data over a first period using low-fidelity monitoring techniques, evaluating patient behavior based on the monitored first type of patient data, and monitoring a second type of patient data over a second period using a continuous glucose monitoring device, the parameters of the continuous glucose monitoring device being based on the evaluated patient behavior during monitoring.

[0203] Example 193 is a method for measuring parameters related to a patient's health, the method comprising: detecting by an analyte sensor system that an analyte sensor system has been applied to a host; storing analyte data describing the host by the analyte sensor system; determining by the analyte sensor system that the use of the sensor in the analyte sensor system has ended; and uploading the stored analyte data by the analyte sensor system to an upload computing device.

[0204] In Example 194, the subject of Example 193 optionally includes, after determining that the use of the sensor in the analyte sensor system has ended, broadcasting system identification data by the analyte sensor system, receiving a communication request containing system identification data from the upload computing device and the analyte sensor system, and establishing a communication session with the upload computing device in response to the communication request, wherein the upload is performed using the communication session.

[0205] In Example 195, one or more of the themes from Examples 193 to 194 optionally include, after determining that the use of the sensor in the analyte sensor system has ended, the analyte sensor system receiving an upload request from an upload computing device and receiving authentication data from the upload computing device.

[0206] In Example 196, one or more subjects from Examples 193 to 195 may optionally include, after determining that the use of the sensor in the analyte sensor system has ended, the analyte sensor system receiving an upload request from an upload computing device, the analyte sensor system broadcasting system identification data, the analyte sensor system receiving authentication data from the upload computing device, and the analyte sensor system establishing a communication session with the upload computing device, wherein uploading involves transmitting the stored analyte data to the upload computing device.

[0207] In Example 197, one or more of the themes from Examples 193 to 196 optionally include detecting that an analyte sensor system has been applied to a host by determining that the analyte sensor system has provided a sensor reading that exceeds a threshold.

[0208] In Example 198, one or more of the themes from Examples 193 to 197 optionally include detecting that an analyte sensor system has been applied to a host by determining that the analyte sensor system has provided a sensor reading exceeding a threshold value for a threshold time.

[0209] In Example 199, one or more themes from Examples 193 to 198 optionally include determining that the use of the sensor in the analyte sensor system has ended by determining that a time exceeding a threshold time has elapsed since the analyte sensor system was applied to the host.

[0210] In Example 200, one or more of the themes from Examples 193 to 199 optionally include uploading stored analyte sensor data to a server system using an upload computing device.

[0211] Example 201 is a system for measuring parameters related to a patient's health, the system comprising an analyte sensor system configured to perform operations including detecting that an analyte sensor system has been applied to a host; storing analyte data describing the host by the analyte sensor system; determining that the use of the sensor in the analyte sensor system has ended; and uploading the stored analyte data to an upload computing device by the analyte sensor system.

[0212] In Example 202, the subject of Example 201 optionally includes, after determining that sensor use in the analyte sensor system has ended, the analyte sensor system broadcasts system identification data; the analyte sensor system receives a communication request containing system identification data from the upload computing device; and the analyte sensor system establishes a communication session with the upload computing device in response to the communication request, wherein the upload is performed using the communication session.

[0213] In Example 203, one or more of the themes from Examples 201 to 202 optionally include, after determining that the use of the sensor in the analyte sensor system has ended, an operation further comprising the analyte sensor system receiving an upload request from an upload computing device and receiving authentication data from the upload computing device.

[0214] In Example 204, one or more of the themes from Examples 201 to 203 optionally include, after determining that sensor use in the analyte sensor system has ended, an operation further comprising: the analyte sensor system receiving an upload request from an upload computing device; the analyte sensor system broadcasting system identification data; the analyte sensor system receiving authentication data from the upload computing device; and the analyte sensor system establishing a communication session with the upload computing device, wherein uploading transmits the stored analyte data to the upload computing device.

[0215] In Example 205, one or more themes from Examples 201 to 204 optionally include detecting that an analyte sensor system has been applied to a host by determining that the analyte sensor system has provided a sensor reading that exceeds a threshold.

[0216] In Example 206, one or more themes from Examples 201 to 205 optionally include detecting that an analyte sensor system has been applied to a host by determining that the analyte sensor system has provided a sensor reading exceeding a threshold value for a threshold time.

[0217] In Example 207, one or more themes from Examples 201 to 206 optionally include determining that the use of the sensor in the analyte sensor system has ended by determining that a time exceeding a threshold time has elapsed since the analyte sensor system was applied to the host.

[0218] In Example 208, one or more subjects from Examples 201 to 207 optionally include an upload computing device, which is configured to perform an operation that includes uploading stored analyte sensor data to a server system.

[0219] Embodiment 209 is a machine-readable storage medium that stores instructions, the instructions causing at least one processor to perform an operation that, when executed by at least one processor, includes detecting that an analyte sensor system has been applied to a host, storing analyte data describing the host, determining that sensor use in the analyte sensor system has ended, and uploading the stored analyte data to an upload computing device.

[0220] In Example 210, the subject of Example 209 optionally includes further operations including, after determining that sensor use in the analyte sensor system has ended, broadcasting system identification data, receiving a communication request containing system identification data from an upload computing device, and establishing a communication session with the upload computing device in response to the communication request, wherein the upload is performed using the communication session.

[0221] In Example 211, one or more of the themes from Examples 209 to 210 optionally further include the following operations: after determining that the use of the sensor in the analyte sensor system has ended, receiving an upload request from an upload computing device and receiving authentication data from the upload computing device.

[0222] In Example 212, one or more subjects from Examples 209 to 211 optionally include, after determining that sensor use in the analyte sensor system has ended, an operation further comprising receiving an upload request from an upload computing device, broadcasting system identification data, receiving authentication data, and establishing a communication session with the upload computing device, wherein uploading means transmitting the stored analyte data to the upload computing device.

[0223] This abstract is intended to provide an overview of the subject matter of this patent application. It is not intended to provide an exclusive or exhaustive description of the disclosure. The detailed description is included to provide further information relating to this patent application. Other aspects of the disclosure will be apparent to those skilled in the art by reading and understanding the following detailed description and by looking at the drawings forming part thereof, each of which should not be construed as restrictive.

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

[0225] [Figure 1] This is a diagram illustrating an exemplary medical device system. [Figure 2] Figure 1 is a schematic diagram of various exemplary electronic components that may be part of a medical device system. [Figure 3] This table shows exemplary patient conditions, physiological states, and exemplary treatments. [Figure 4] This is a flowchart illustrating an exemplary method for transitioning from low-fidelity data acquisition techniques to high-fidelity data acquisition techniques. [Figure 5] This is a flowchart illustrating methods for collecting high-fidelity data and low-fidelity data. [Figure 6] This is a flowchart illustrating a method for collecting low-fidelity data and intermittently collecting high-fidelity data. [Figure 7] This is a flowchart illustrating a method for managing a patient's condition. [Figure 8A] This is a flowchart illustrating an exemplary process for patient management. [Figure 8B] This is a flowchart illustrating an exemplary process for patient management. [Figure 8C] This is a flowchart illustrating an exemplary process for patient management. [Figure 9] This is a flowchart illustrating the process of monitoring a patient using primary and secondary monitoring techniques. [Figure 10] This is a flowchart of an exemplary method 1001 for identifying and notifying patients about diabetes information. [Figure 11]This is a flowchart illustrating an exemplary method for determining a monitoring scheme based on collected sensor information. [Figure 12A] This is a diagram illustrating an example user interface. [Figure 12B] Figure 12A is a magnified view of a portion of the user interface shown. [Figure 12C] This is a diagram of an exemplary user interface including the target A1C indicator. [Figure 13] This is a flowchart illustrating how to identify or select patients who may benefit from an enhanced disease management program. [Figure 14] This is a flowchart illustrating an exemplary method for managing parameters related to a patient's health. [Figure 15] This is an illustrative flowchart of the login process. [Figure 16] This is a diagram illustrating an example user interface. [Figure 17] This is a diagram illustrating an example chat interface. [Figure 18] This is a diagram of an exemplary chat interface. [Figure 19] This is a diagram of an exemplary chat interface. [Figure 20] This is a diagram illustrating an example chat interface. [Figure 21] This is an example of a trend graph. [Figure 22A] This is a diagram illustrating an exemplary system that can implement methods, devices, and subsystems. [Figure 22B] Figure 22A is an example diagram of a system with a configuration similar to that of the system shown. [Figure 22C] This flowchart shows an example of a process that can be performed in the system shown in Figure 22B and display CGM data on the activity sensor. [Figure 23] This is a more detailed diagram of the exemplary system shown in Figure 22A. [Figure 24]This document illustrates exemplary systems that may be used in connection with implementing embodiments of the present disclosure. [Figure 25] Figure 4 illustrates an example of an automated or semi-automated coaching system that can be used in the embodiment shown. [Figure 26A] Figure 5 is a flowchart illustrating an exemplary process for involving a patient in an automated or semi-automated coaching system. [Figure 26B] Figure 5 is a flowchart illustrating an exemplary process for involving a patient in an automated or semi-automated coaching system. [Figure 27] This is an illustrative flowchart of the process for starting the motor module. [Figure 28] This is an exemplary flowchart of the process for implementing a follow-up module. [Figure 29] This is an illustrative flowchart of the process for implementing a confidence rater / booster module. [Figure 30] This is an exemplary flowchart of the process for implementing the meal module. [Figure 31] This is an illustrative flowchart of the process for implementing a meal tracking module. [Figure 32] This is an exemplary process flowchart for implementing a module designed to encourage the use of the embodiment shown in Figure 11. [Figure 33] This is an illustrative flowchart of the process for implementing a sleep module. [Figure 34] This is a diagram of an exemplary system that may include an analyte sensor system configured to upload analyte data captured after collection. [Figure 35] Figure 34 is a flowchart illustrating an example of a process performed by the analyte sensor system to collect and upload analyte data. [Figure 36]This flowchart shows an example of a process performed by sensor electronics that allows for the uploading of collected analyte data. [Figure 37] This flowchart shows another example of a process performed by sensor electronics that allows collected analyte data to be uploaded. [Modes for carrying out the invention]

[0226] The inventors have recognized, among other things, that patients can be advantageously monitored or managed using a combination of technologies with different patterns of information gathering. Typically, to enhance patient management, higher fidelity data and more data are desired to inform patient management decisions. A counterintuitive approach is to use less data or lower fidelity data in combination with information learned from high-fidelity data (such as correlations between data types) to guide patient management. For example, relationships between different types of collected data can be used to inform patient management during periods when one or more types of data are unavailable. In some examples, analyte information automatically collected by sensors from a host on a schedule ("continuous analyte monitoring"), such as glucose information automatically collected by a glucose sensor ("continuous glucose monitoring" or "CGM"), may correlate with other types of information (e.g., activity captured by a wearable activity sensor), which may allow for the estimation of estimated glucose concentration levels (or levels of another analyte) based on the correlation. In some cases, two or more types of data (e.g., CGM data and activity data) may be collected from a patient, and a system or algorithm may be developed or adapted to infer the first type of data (e.g., glucose concentration level) from a second type of data (e.g., activity or heart rate), or from the second type of data and auxiliary inputs (e.g., drug administration or food consumption), using data acquired during the period in which both CGM and activity data are collected. In other words, a non-CGM sensor system may be "calibrated" to an estimated glucose value using concurrently acquired CGM and non-CGM data. In some cases, continuous glucose monitoring may be performed intermittently, and glucose concentration levels may be collected according to a schedule (e.g., every 5 minutes) during the collection period, but CGM data collection may only occur during specific periods, such as when the patient is wearing an activated CGM sensor, which may occur, for example, one week or ten days each month, or every three months.

[0227] In some cases, the need or desire to implement a second type of data collection (e.g., intermittent CGM data collection) or collection parameters (e.g., periodicity for intermittent collection) may be determined based on the first type of data (e.g., blood glucose meter data or activity data). In some cases, the relationship or manner of intermittent collection can be used to determine the collection parameters for different monitoring techniques. For example, CGM data can be used to determine the timing or schedule of one or more blood glucose meter tests. In another example, blood glucose meter test results or activity data can be used to determine a CGM monitoring scheme (e.g., a schedule for intermittent CGM data collection or several sensors used in CGM monitoring). In some cases, oral medication therapy or injectable insulin therapy (e.g., basal insulin) may be determined (or evaluated or re-determined) based in part on CGM information, such as intermittent CGM monitoring. While CGM information is referenced as an example throughout this specification, the examples described are also applicable to other types of analytes (e.g., references to continuous glucose monitoring are generally applicable to continuous analyte monitoring).

[0228] overview Patient management can be more effective when notified by timely information about the patient. For example, physiological, environmental, or behavioral information can be used to determine patient guidance (e.g., dietary or exercise guidance) or therapy (e.g., oral medication regimen), or to decide on changes or improvements to the patient management scheme. Patients with controlled blood glucose levels, such as type 2 diabetes, may particularly benefit from patient management schemes that use timely information. While some monitoring systems or devices, such as continuous glucose monitors, can provide strong signals about a patient's glucose control status (e.g., high, normal, or low glucose levels), continuous use of such systems may be undesirable due to cost (e.g., cost of CGM sensors and monitoring) or patient burden (e.g., the need to wear and manage a CGM on the body). Other systems and devices (e.g., wearable activity monitors, smartwatches, smartphones) may be less burdensome and less expensive, but tend to provide information that may have less direct correlation with blood glucose levels. For example, while activity tends to help control blood glucose levels, actual blood glucose levels cannot be easily predicted from activity information alone, and the effect of activity on blood glucose can vary considerably depending on the patient or patient type (e.g., between subgroups within a population).

[0229] To balance cost with the need for accurate information regarding glucose management, different types of patient data may be collected over one or more overlapping periods, which may allow for the determination of patient management information based on relationships between different types of data. Such relationships can be used to guide patient management when one of the data types is unavailable. For example, continuous glucose monitoring and activity monitoring may be used during overlapping periods, and relationships between glucose concentration level information and activity information may be learned from CGM and activity data. In some examples, users may be instructed to wear an activity sensor (e.g., a watch) continuously (e.g., for at least a portion of each day), or users may be instructed to wear a continuous glucose sensor for a defined period (e.g., a two-week trial period) or continuously (e.g., during two-week sessions every three months). Data may be collected and analyzed by a system (e.g., using mobile devices and servers) to determine relationships between glucose levels and activity. In various cases, activity may correlate with glucose concentration levels or ranges, or with an effect on glucose concentration (e.g., a specific amount of activity may cause a determined effect on glucose, which may vary based on glucose levels due to lower insulin sensitivity (i.e., insulin resistance) at higher glucose levels), or with glucose level trends (e.g., the rate of change in glucose levels associated with the amount, intensity, or type of activity), and any of these may be used to infer estimated glucose concentration levels (e.g., 120 mg / dL), ranges (e.g., 120–160 mg / dL), status (e.g., outside or within the target range), or other glucose level management estimates. One or more of these glucose estimates, or information based on these estimates (e.g., time within the range per day), may be delivered to the patient, which may occur in real time, on demand, or repetitively (e.g., hourly, daily, weekly, three times a day, or before or after meals), depending on the case.

[0230] To facilitate the determination of relationships between data types, different types of data (e.g., CGM data and activity data) can be correlated with one or more of the following: time (e.g., to enable matching of CGM data with corresponding activity data), location, day, patient input data (e.g., meals or activities), or other information. Correlation with time, location, day, patient input data, or other information can also be used to determine relationships between data types.

[0231] In some cases, collected sensor data can be used in combination with population-based data such as gender, age, location, ethnicity, occupation, A1C, BMI, weight, or other demographic information to determine glucose control estimates (e.g., estimated glucose levels, range, or status). In some cases, the system can build population cohorts segmented by glucose profile behavior, and users matching a particular cohort may receive statistical feedback. Based on this type of population information, glucose estimates can be used to determine population-based guidance, which can be delivered to patients (e.g., presented on a smart device). For example, a patient might receive guidance such as, "70% of people like you are estimated to be out of range at this time. Have you thought about going for a walk?"

[0232] In some examples, a model can be developed (e.g., learned from collected data), and relationships can be reflected in the model. For example, a state such as glucose status can be determined by applying one or more inputs (e.g., activities) to the model.

[0233] While certain types of patient management information (e.g., CGM and activity data) may be the subject of specific examples for illustrative purposes, it should be understood that the techniques and methods and systems described herein may be applied to other different types of information, such as different types of monitored analytes (other than glucose), or different types of physiological information (e.g., heart rate, respiration, electrocutaneous response, or other skin quality, blood ketones, urinary ketones, oxygen saturation), or types of ambient information (e.g., location, environment, temperature), and that relationships between two or more types of information may be used to determine health information (e.g., diabetes) about a patient when one or more types of information are unavailable.

[0234] Exemplary System Figure 1 shows an exemplary system 100 which may include various sensor systems for the device. System 100 may include an analyte sensor system 102 which may be coupled to a host 101. The host 101 may be a human patient. The patient may be subject to, for example, a temporary or permanent diabetic condition, or other health conditions for which data-driven patient management or analyte monitoring may be useful.

[0235] The analyte sensor system 102 may include an analyte sensor 104, which may be, for example, a glucose sensor. The glucose sensor may be any device capable of measuring glucose concentration. For example, the analyte sensor 104 may be fully implantable, the analyte sensor may be wearable on the body (e.g., on the body but not under the skin), or the analyte sensor may be a transdermal device (e.g., having a sensor located under or in the skin of a host). It should be understood that the devices and methods described herein may be applied to any device capable of detecting glucose concentration and providing an output signal representing glucose concentration (e.g., in the form of analyte data).

[0236] The analyte sensor system 102 may also include sensor electronics 106. In some examples, the analyte sensor 104 and sensor electronics 106 may be provided as an integrated package. In other examples, the analyte sensor 104 and sensor electronics 106 may be provided as separate components or modules. For example, the analyte sensor system 102 may include a disposable (e.g., single-use) base which may include the analyte sensor 104, a component for attaching the sensor to a host (e.g., an adhesive pad), or a mounting structure configured to receive another component. The system may also include a sensor electronics package which may include some or all of the sensor electronics 106 shown in Figure 2. The sensor electronics package may be reusable.

[0237] The analyte sensor may provide a data stream indicating the concentration of the analyte in the host using any known method, including invasive, minimally invasive, or non-invasive detection techniques (e.g., optically excited fluorescence, microneedles, transdermal glucose monitoring). The data stream may be a raw data signal and may be converted into a calibrated and / or filtered data stream used to provide a user, such as a patient or caregiver (e.g., parent, relative, guardian, teacher, physician, nurse, or any other individual interested in the host's health), with a useful value of the analyte (e.g., estimated blood glucose concentration level).

[0238] The analyte sensor 104 may be, for example, a continuous glucose sensor and may include, for example, subcutaneous, transdermal (e.g., transcutaneous), or intravascular devices. In some embodiments, such sensors or devices may analyze sensor data repeatedly (e.g., periodically or intermittently). The glucose sensor may use any method of glucose measurement, including enzymatic, chemical, physical, electrochemical, spectrophotometric, polarimetric, calorimetry, ionophoretic, radiometric, immunochemical, etc. In various examples, the analyte sensor system 102 may be or include continuous glucose monitoring sensors available from DexCom® (e.g., DexCom G5® sensors, or DexCom G6® sensors, or any variation thereof), Abbott® (e.g., Libre® sensors), or Medtronic® (e.g., Enlite® sensors).

[0239] In some examples, the analyte sensor 104 may be a portable glucose sensor, such as the one described in U.S. Patent No. 6,001,067 and U.S. Patent Publication No. US2005 / 0027463(A1). In some examples, the analyte sensor 10 may be a transcutaneous glucose sensor, such as the one described in U.S. Patent Publication No. US2006 / 0020187(A1). In some examples, the analyte sensor 10 may be configured to be implanted in the host's blood vessels or outside the body, as described in U.S. Patent Publication US2007 / 0027385(A1), concurrently pending U.S. Patent Publication US2008 / 0119703(A1) filed October 4, 2006, U.S. Patent Publication US2008 / 0108942(A1) filed March 26, 2007, and U.S. Patent Application US2007 / 0197890(A1) filed February 14, 2007. In some examples, the continuous glucose sensor may include a transcutaneous sensor, as described, for example, in U.S. Patent No. 6,565,509 by Say et al. In some examples, the analyte sensor 10 may be a continuous glucose sensor including a subcutaneous sensor, such as described in U.S. Patent No. 6,579,690 by Bonnecaze et al., or U.S. Patent No. 6,484,046 by Say et al. In some examples, the continuous glucose sensor may include a refillable subcutaneous sensor, such as described in U.S. Patent No. 6,512,939 by Colvin et al. The continuous glucose sensor may include an intravascular sensor, such as described in U.S. Patent No. 6,477,395 by Schulman et al. The continuous glucose sensor may include an intravascular sensor, such as described in U.S. Patent No. 6,424,847 by Mastrototaro et al.

[0240] System 100 may also include a second medical device 108, which may be, or include, a wearable monitor or drug delivery device. For example, the second medical device 108 may be, or include, a drug delivery device such as an insulin pump, insulin pen, or similar device. In some examples, the medical device 108 may be, or include, a sensor, a heart rate sensor, a respiratory sensor, a motion sensor (e.g., an accelerometer), a posture sensor (e.g., a 3-axis accelerometer), an acoustic sensor (e.g., one that captures ambient or internal sounds), or another analyte sensor. In some examples, the medical device 108 may be, for example, wearable on a watch, glasses, contact lenses, a patch, a wristband, ankle band, or other wearable item, or may be incorporated into a handheld device (e.g., a smartphone). In some examples, the medical device 108 may include a multisensor patch capable of detecting one or more of the following: analyte levels (e.g., glucose, lactate, insulin or other substances), 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).

[0241] The analyte sensor system 102 may communicate with the second medical device 108 via a wired connection or via a wireless communication signal 110. For example, the analyte sensor system may be configured to communicate using radio frequencies (e.g., Bluetooth®, Bluetooth Low Energy (LE), Medical Implant Communication System (MICS), Wi-Fi, NFC, RFID, Zigbee, Z-Wave or other communication protocols), optical (e.g., infrared), acoustic (e.g., ultrasound), or cellular protocols (e.g., CDMA (Code Division Multiple Access) or GSM (Global System for Mobile Communications)), or wired connections (e.g., serial, parallel, etc.).

[0242] System 100 may also include a wearable sensor 130 which may include a sensor circuit (e.g., a sensor circuit configured to detect glucose concentration or other analyte concentration) and a communication circuit, which may be, for example, a near-field communication (NFC) circuit. In some examples, information from the wearable sensor 130 may be retrieved from the wearable sensor 130 using a user device 132, such as a smartphone, which is configured to communicate with the wearable sensor 130 via NFC when the user device 132 is placed near the wearable sensor 130. (For example, swiping the user device 132 over the sensor retrieves sensor data from the wearable sensor using NFC). The use of NFC communication may reduce power consumption by the wearable sensor, which may reduce the size of the wearable sensor's power source (e.g., battery or capacitor) or extend the usable life of the power source. In some examples, the wearable sensor 130 may be wearable on the upper arm, as shown. In some examples, the wearable sensor 134 may be additionally or alternatively located on the upper torso of the patient (e.g., above the heart or lungs), which may facilitate the detection of, for example, heart rate, respiration, or posture. The wearable sensor 136 may also be located on the lower body (e.g., the legs).

[0243] In some examples, an array or network of sensors can be associated with a patient. For example, one or more analyte sensor systems 102, a medical device 108, a wearable device 120, and additional sensors 130 may communicate with each other via wired or wireless (e.g., Bluetooth, Bluetooth LE, MICS, NFC, or any of the other options considered above) communication. The additional sensors 130 may be any of the examples considered above with respect to the medical device 108. The analyte sensor systems 102, medical device 108, and additional sensors 130 on host 101 are provided for illustrative and discussion purposes only and are not necessarily drawn to scale.

[0244] System 100 may also include one or more peripheral devices such as a handheld smart device (e.g., a smartphone) 112, a tablet 114, a smart pen 116 (e.g., an insulin delivery pen with processing and communication capabilities), a computer 118, a wearable device such as a wearable device 120, or a peripheral medical device 122, any of which may communicate with the analyte sensor system 102 via wireless communication signals, and may also communicate with a server system (e.g., a remote data center) 125 or a remote terminal 128 via a network 124 to facilitate communication with remote users (not shown), such as technical support staff members or clinicians.

[0245] The wearable device 120 may include activity sensors, heart rate monitors (e.g., light-based or electrode-based sensors), respiration sensors (e.g., acoustic or electrode-based), location sensors (e.g., GPS), or other sensors.

[0246] System 100 may also include a wireless access point (WAP) 138 which can be used to communicatively connect one or more of the analyte sensor system 102, the network 124, one or more server systems 126, 125, 127, the medical device 108, or the peripheral devices described above. For example, the WAP 138 may provide Wi-Fi and / or cellular connectivity within System 100. Other communication protocols (e.g., near-field communication (NFC) or Bluetooth) may also be used between devices in System 100.

[0247] In some examples, the first server system 125 may be used to collect analyte data from the analyte sensor system 102 and / or several other devices, perform analysis on the collected data, generate or apply universal or personalized models of glucose levels, and communicate such analytes, models, or information based thereon back to one or more devices in the system 100. The system may include one or more additional servers 126, 127. For example, the first server system 125 may process (e.g., receive, store, or transmit) CGM data, and the second server system 126 may store general patient information or medical data (e.g., insurance information). The first server system 125 or the second server system 126 may include a decision support system that can, for example, determine guidance to a patient, determine estimated glucose levels (e.g., based on surrogate data), or determine other information (e.g., correlation with other types of information) using any of the various techniques described herein. Guidance, glucose concentration levels, or other information may be transmitted via network 124 and delivered to patient or caregiver devices such as a handheld device 112 or tablet 114. In some examples, CGM information may be delivered to a patient device (such as a handheld device 112) and shared with a caregiver or family member's device. Information regarding remote monitoring of analyte measurements is provided in U.S. Patent Application No. 15 / 632,181, published as U.S. Publication No. 20170293732(A1), and is incorporated by reference.

[0248] System 100 may also include a third server system 127 capable of receiving or storing a second type of patient information or information from another source, such as sensor data from a wearable sensor. In various examples, two or more servers 125, 126, 127 can be combined, or all three servers can be combined, or operations can be distributed differently among the servers, or subtasks can be delegated to additional servers or other resources. In some examples, a smart device such as a wearable device 120 or a handheld device 112 may run a single application that collects, processes, or transmits two types of data (e.g., high-fidelity data and low-fidelity data, or CGM data and activity data) (e.g., to a server or other smart device). In other examples, a smart device may run two separate applications, each collecting, processing, or transmitting a certain type of data. In some examples, a smart device may run separate applications for data collection, with one application receiving data from the other (e.g., a CGM application receiving activity information collected by an activity application). Information regarding inter-application communication is contained in U.S. Patent Application No. 15 / 474,886, U.S. Publication No. 20170286194(A1), and is incorporated by reference.

[0249] In some examples, one smart device can collect information from another smart device; for example, a handheld device 112 can collect activity information from a wearable device 120. In some examples, correlations between data types (described further below) can be determined by a smart device, a server (e.g., server 125), or both, or a combination thereof.

[0250] Figure 2 is a schematic diagram of various exemplary electronic components that may be part of a medical device system 200. In one example, the system may include sensor electronics 106 and a base 290. While a specific example of component separation between the base and the sensor electronics is shown, it is understood that some examples may include additional components in the base 290 or in the sensor electronics 106, and that some of the components shown in the sensor electronics 106 may be provided to the base alternatively or additionally (e.g., redundantly). In one example, the base 290 may include an analyte sensor 104 and a battery 292. In some examples, the base may be replaceable, and the sensor electronics 106 may include debouncing circuits (e.g., gates with hysteresis or delays) to avoid repeated execution of power-on or power-off processes when the battery is repeatedly connected and disconnected, or to avoid handling of noise signals associated with battery removal or replacement.

[0251] The sensor electronics 106 may include electronic components configured to process sensor information, such as sensor data, and to generate converted sensor data and displayable sensor information. The sensor electronics 106 may include electronic circuits associated with measuring, processing, storing, or communicating continuous analyte sensor data, for example, including predictive algorithms associated with processing and calibration of sensor data. The sensor electronics 106 may include hardware, firmware, and / or software that enables the measurement of analyte levels via a glucose sensor. The electronic components may be fixed to a printed circuit board (PCB) or the like and may take various forms. For example, the electronic components may take the form of integrated circuits (ICs), such as application-specific integrated circuits (ASICs), microcontrollers, and / or processors.

[0252] As shown in Figure 2, the sensor electronics 106 may include a potentiostat 202 coupled to the analyte sensor 104 and configured to iteratively acquire analyte sensor readings using the analyte sensor, for example, by continuously or iteratively applying a voltage bias across the sensor electrodes and measuring a current indicating the analyte concentration. The sensor electronics may also include a processor 204 which may retrieve instructions 206 from memory 208, execute the instructions to determine the controlled application of a bias potential to the analyte sensor 104 via the potentiostat, interpret signals from the sensor, or compensate for environmental factors. The processor may also store information in or retrieve information from data storage memory 210. In various examples, data storage memory 210 may be integrated with memory 208 or may be a separate memory circuit such as a non-volatile memory circuit (e.g., flash RAM). Examples of systems and methods for processing sensor analyte data are described in more detail herein and in U.S. Patents 7,310,544 and 6,931,327.

[0253] The sensor electronics 106 may also include a sensor 212 that can be coupled to the processor. The sensor 212 may be, for example, a temperature sensor or an accelerometer. The sensor electronics 106 may also include a power source such as a capacitor or battery 214, which may be integrated into the sensor electronics, be removable, or be part of a separate electronics package. The battery 214 (or other power storage component, e.g., a capacitor) may be optionally rechargeable via a wired or wireless (e.g., inductive or ultrasonic) recharge system 216. The recharge system may recover energy or receive energy from an external or internal source. In various examples, the recharge circuit may include a circuit that recovers energy from a triboelectric charging circuit, a piezoelectric charging circuit, an RF charging circuit, a photoelectric charging circuit, an ultrasonic charging circuit, a thermal charging circuit, a heat recovery circuit, or a communication circuit. In some examples, the recharge circuit may recharge the rechargeable battery using power supplied from a replaceable battery (e.g., a battery supplied with the base component).

[0254] The sensor electronics 106 may also include a wireless communication circuit 218, which may include, for example, a wireless transceiver operably coupled to an antenna. The wireless communication circuit 218 may be operably coupled to a processor and may be configured to wirelessly communicate with one or more peripheral devices or other medical devices, such as an insulin pump or smart insulin pen.

[0255] The peripheral device 250 could be, for example, a wearable device such as the wearable device 120 (e.g., an activity monitor). In other examples, the peripheral device 250 could be a handheld device 112 (e.g., a smartphone or other devices such as a proprietary handheld device available from Dexcom), a tablet 114, a smart pen 116, or a dedicated computer 118 as shown in Figure 1.

[0256] The peripheral device 250 may include a user interface 252, a memory circuit 254, a processor 256, a wireless communication circuit 258, a sensor 260, a power supply 262 (e.g., a battery or capacitor), or any combination thereof. The peripheral device may not necessarily include all the components shown in Figure 2. The user interface 252 of the peripheral device 250 may include, for example, a touch screen interface, a microphone (e.g., for receiving voice commands), or a speaker, a vibration circuit, or any combination thereof, and the user interface 252 may receive information from the user (e.g., glucose values) or deliver information to the user such as glucose values, glucose trends (e.g., arrows, graphs, or charts), or glucose warnings. The processor 256 may be configured to present information to the user or receive input from the user via the user interface 252. The processor 256 may also be configured to store and retrieve information in the memory circuit 254, such as communication information (e.g., pairing information or data center access information), user information, sensor data or trends, or other information. The wireless communication circuit 258 may include a transceiver and antenna configured to communicate via a wireless protocol such as Bluetooth, MICS, or any of the other options considered above. The sensor 260 may include, for example, an accelerometer (e.g., of an activity monitor such as a clock), a temperature sensor, a location sensor, a biometric sensor, or a blood glucose sensor, blood pressure sensor, heart rate sensor, respiratory sensor, or other physiological sensor. The device may include multiple sensors of different types.

[0257] The peripheral device 250 may be configured to receive and display sensor information that can be transmitted by the sensor electronics 106 (for example, in a customized data package transmitted to a display device based on individual preferences). Sensor information (e.g., blood glucose concentration level) or warnings or notifications (e.g., "high glucose level," "low glucose level," or "decrease warning") may be communicated via the user interface 252 (e.g., via a visual display, sound, or vibration). In some examples, the peripheral device 250 may be configured to display or otherwise communicate sensor information when communicated from the sensor electronics module (for example, in a data package sent to a respective display device). For example, the peripheral device 250 may transmit processed data (e.g., an estimated analyte concentration level that can be determined by processing raw sensor data), so that the receiving device does not need to further process the data to determine the available information (such as the estimated analyte concentration level). In other examples, the peripheral device 250 may process or interpret the received information (for example, to declare a warning based on glucose values ​​or glucose trends). In various examples, the peripheral device 250 may receive information directly from the sensor electronics 106 or via a network (for example, via a cellular or Wi-Fi network that receives information from the sensor electronics or from a device communicably coupled to the sensor electronics 106).

[0258] Referring again to Figure 2, the medical device 270 may include a user interface 272, a memory circuit 274, a processor 276, a wireless communication circuit 278, a sensor 280, a treatment circuit 282, or any combination thereof. In some examples, the medical device 270 may not include all the components illustrated in Figure 2. For example, the medical device may not include the user interface 272, nor the treatment circuit 282, nor the sensor 280.

[0259] The user interface 272 may include, for example, a touch screen interface, a microphone or speaker, a vibration circuit, or any combination thereof, and the user interface 272 may receive information from the user (e.g., glucose values, alert preferences, calibration coding) or transmit information to the user such as glucose values, glucose trends (e.g., arrows, graphs or charts), glucose alerts, etc. The processor 276 may be configured to present information to the user or receive input from the user via the user interface 272. The processor 276 may also be configured to store and retrieve information in the memory circuit 274, such as communication information (e.g., pairing information or data center access information), user information, sensor data or trends, or other information. The wireless communication circuit 278 may include transceivers and antennas configured to communicate via wireless protocols such as Bluetooth, Medical Implant Communication System (MICS), Wi-Fi, Zigbee, or cellular protocols (e.g., CDMA (Code Division Multiple Access) or GSM (Global System for Mobile Communications)). The sensor 280 may include, for example, an accelerometer, temperature sensor, location sensor, biometric sensor, or blood glucose sensor, blood pressure sensor, heart rate sensor, respiratory sensor, or other physiological sensor. Although only one is shown in the example in Figure 2, medical device 2 70 may include two or more sensors (or memory or other components). In various examples, the medical device 270 may be a smart handheld glucose sensor (e.g., a blood glucose meter), a drug pump (e.g., an insulin pump), or any other physiological sensor device (e.g., a wearable device 120), a therapeutic device, or a combination thereof. In various examples, the medical device 270 may be the medical device 108, peripheral device 122, wearable device 120, wearable sensor 130, wearable sensor 134, or wearable sensor 136 shown in Figure 1.In an example where the medical device 270 is an insulin pump, the pump and the analyte sensor system may communicate bidirectionally (e.g., the pump may request changes to the analyte transmission protocol, e.g., request data points or data on a more frequent schedule), or the pump and the analyte sensor system may communicate using unidirectional communication (e.g., the pump may receive analyte concentration level information from the analyte sensor system). In unidirectional communication, glucose values ​​may be incorporated into notification messages that can be encrypted with a pre-shared key. In bidirectional communication, the pump may request values ​​that the analyte system shares or acquires and shares in response to requests from the pump, and any or all of these communications may be encrypted using one or more pre-shared keys. The insulin pump may, for one or more of a variety of reasons, use unidirectional communication to receive and track analyte (e.g., glucose) values ​​transmitted from the analyte sensor system 102. For example, the insulin pump may pause or start insulin administration based on glucose values ​​below or above a threshold.

[0260] In some examples, the system 100 shown in Figure 1 may include two or more peripheral devices, each receiving information directly or indirectly from the analyte sensor system 102. Since different display devices may provide different user interfaces, the contents of the data package (e.g., the amount, format, and / or type of data to be displayed, alarms, etc.) may be customized for each specific device (e.g., programmed differently by the manufacturer and / or end-user). For example, in the embodiment of Figure 1, multiple different peripheral devices may communicate wirelessly with the sensor electronics module (e.g., skin surface-mounted sensor electronics 106, etc., physically connected to the continuous analyte sensor 104) during a sensor session to enable multiple different types and / or levels of display and / or functionality associated with the displayable sensor information, or to conserve battery power for the sensor system 102; one or more designated devices may communicate with the analyte sensor system and relay (i.e., share) information directly to other devices or via a server system (e.g., a networked data center) 125.

[0261] Figure 3 shows Table 301 illustrating exemplary patient conditions 305, physiological conditions 310, and exemplary treatments 315. The table is arranged to reflect a typical progression from a normal state to prediabetes and eventually to a diabetic state (e.g., type 2 diabetes), which, depending on the circumstances, can occur over days, weeks, months, or years. The arrangement of patient conditions, physiological conditions, and treatments in the table is provided for illustrative purposes only and may not be the same for every patient. In some patients, insulin resistance or insufficient insulin production by pancreatic β-cells may contribute to the progression of the patient to prediabetes and eventually to type 2 diabetes. Type 2 diabetes and high blood glucose levels are associated with myocardial infarction, stroke, vascular problems, and mortality.

[0262] In healthy patients, there may be no problematic physiological conditions that need to be managed, and as a result, treatment may not be necessary. Patients may develop insulin resistance due to one or more of various factors, including age, diet, lifestyle, pregnancy, genetic factors, or other factors.

[0263] When a patient develops insulin resistance, they may begin to experience higher-than-normal levels of insulin, known as "hyperinsulinemia." To manage hyperinsulinemia and insulin resistance, patients may initiate a patient management regimen, which may include dietary and exercise changes such as consuming fewer calories or fewer carbohydrates (especially monosaccharides and other carbohydrates that can be quickly processed into glucose by the body), and an increase in activity or physical exertion.

[0264] As a patient's condition worsens, they may experience elevated blood glucose levels, known as "hyperglycemia." For example, a patient may initially exhibit postprandial hyperglycemia, where glucose levels spike to higher-than-normal levels after a meal, and then tend to decrease over time after the meal. Glucose levels that are higher than normal but not high enough to trigger a diagnosis of type 2 diabetes are sometimes called "impaired glucose tolerance." Patients may continue dietary and exercise modifications to manage postprandial hyperglycemia or impaired glucose tolerance, and they may also be prescribed oral medications. Oral medications may, for example, stimulate insulin production by pancreatic beta cells (e.g., sulfonylurea or meglitinide), reduce glucose production by the liver (e.g., biguanides), improve the action of circulating insulin (e.g., thiazolidinediones), reabsorb glucose in the kidneys (e.g., SGLT2 inhibitors), block the breakdown of starch in the intestines (e.g., alpha-glucosidase inhibitors), or prevent the breakdown of glucose-lowering compounds (e.g., DPP-4 inhibitors). Other oral medications and combinations of complementary or compatible drugs are also possible treatment options.

[0265] Impaired glucose tolerance may progress to impaired fasting glucose, and patients may exhibit abnormally high glucose concentration levels not only immediately after meals but also during fasting ("fasting hyperglycemia"). For example, a fasting blood glucose level exceeding 100 mg / dL may be considered prediabetes. Patients may continue diet therapy, exercise therapy, and oral medications. Patients may also be prescribed insulin to attempt to lower glucose levels.

[0266] Information about a patient can also be used to assist in the management of the patient's condition. For example, sensor data such as activity data or physiological data (e.g., heart rate or respiration) can be used to develop guidance related to the management of the patient's health. The information about the patient may be of a specific physiological type (e.g., glucose information, heart rate information, respiration information, pulse information, etc.).

[0267] Despite efforts to control glucose or insulin levels, the condition of some patients may continue to deteriorate and eventually progress to type 2 diabetes. For example, if the fasting (overnight) glucose level is 126 mg / dL or higher, the patient may be considered to have type 2 diabetes. Some patients tend to have continuously rising glucose levels, which increases the risk of complications such as cardiovascular disease, vascular problems, and stroke, and may progress further into diabetes.

[0268] To assist in managing glucose levels, prediabetes, or type 2 diabetes, patients may benefit from monitoring using a physiological sensor such as a continuous glucose monitor. In some examples, information from other sources, such as data or data patterns from an activity sensor or a blood glucose meter, can be used to determine whether to initiate the use of a physiological sensor such as a continuous glucose monitor.

[0269] In some cases, a continuous glucose monitor (or other physiological sensor) can be used for a trial period (e.g., 3 days, 7 days, 10 days, 14 days, 30 days, or 3 months). In some cases, information regarding glucose level management can be learned from the trial period. The information learned from the trial period can then be optionally combined with other information such as activity, location, heart rate, user input information, or other glucose information (e.g., single-point glucose data such as blood glucose meter data, glucose data from NFC-enabled sensors, optical glucose data, or glucose information collected by other technologies) to better manage the patient's condition. For example, the relationship between the patient's activity or behavior (estimated from activity, location, heart rate, or user input information, or other information) and the patient's glucose concentration level can be learned during the trial period, and this relationship can be used later to determine guidance for the patient.

[0270] In some situations, continuous glucose monitoring may be used intermittently. For example, glucose concentration levels may be collected from a patient using continuous glucose monitoring on a specified schedule, e.g., a specified number of days, weeks, or a series of days (e.g., 10 days) per quarter, month, or year. Intermittently collected CGM information may be used to proactively manage glucose levels (e.g., in real time) or to update or improve learned relationships between glucose levels estimated from CGM and other information such as activity.

[0271] Figure 4 is a flowchart of method 401 for transitioning from low-fidelity data acquisition techniques to high-fidelity data acquisition techniques. In 405, low-fidelity data is collected. Low-fidelity data may provide information relevant to the management of health conditions such as diabetes health (e.g., control of glucose concentration levels). In some examples, low-fidelity data may provide information indirectly relevant to diabetes health. Low-fidelity data may be, for example, activity data (e.g., from a smartwatch or other wearable sensor), which may indicate the amount of exercise or movement by the patient. Activity data may be accurate with respect to activity levels, but may be considered low-fidelity in the sense that it does not provide a high degree of accuracy about the patient's condition in terms of glucose management or diabetes condition management, for example, because low-fidelity data is indirectly relevant to glucose control or has a relatively weak correlation with glucose levels compared to high-fidelity data. Low-fidelity data may additionally or alternatively include location, user input, or other physiological data (e.g., heart rate or respiration). In some cases, low-fidelity data may be glucose concentration data such as single-point glucose data (e.g., blood glucose meter data), glucose data from NFC-enabled sensors, optical glucose data, or glucose information collected by other technologies. Low-fidelity data may also include test results such as fasting glucose levels or hemoglobin A1C. Low-fidelity data can be used to perform diabetes health assessments or to provide patients with guidance on improving or controlling their diabetic health status.

[0272] Additional information may be collected during low-fidelity data collection. For example, the system may collect information on the use of activity trackers, food trackers, and self-monitoring of blood glucose. Patient involvement may also be collected, such as the level or success of involvement in coaching or goal-setting programs. Preference information can also be collected, such as preferred methods for viewing and reviewing health data (e.g., type and timing of app views, chats, and coaching calls; learning style (e.g., reviewing patterns or real-time tracking and interaction); preferred graphical style (e.g., analyzing user interface screen views for examples of specific types of details investigated, or preference for qualitative or quantitative display); communication style (short messages, video, or readouts); or preferred health metrics (e.g., steps, exercise streaks, daily carbohydrates, current app settings). One or more goals can also be determined (e.g., dietary choices, exercise, basal or drug titrations, or hypoavoidance). Patient risk metrics can also be determined based on, for example, demographics, medical records, mean or fasting glucose levels, or postprandial glucose variability characteristics. In some cases, patients may be assigned goals or risk metrics based at least in part on a cohort of previous subjects with similar starting circumstances, goals, or characteristics.

[0273] In 410, high-fidelity data may be collected. During high-fidelity data collection, low-fidelity data collection may be paused, or both low-fidelity and high-fidelity data may be collected. High-fidelity data may provide information highly relevant to managing the patient's health status. For example, high-fidelity data may be data from a continuous glucose monitor. Because high-fidelity data may be more expensive, burdensome, or invasive to collect than low-fidelity data, it may be necessary to determine the reasons for collecting high-fidelity data.

[0274] One example is determining whether high-fidelity data collection is necessary or justified, based at least in part on low-fidelity data. For instance, low-fidelity information can be used to determine or identify subjects who are likely to benefit from transitioning to intermittent or continuous high-fidelity data collection. Such determinations may be based, for example, on risk metrics such as those mentioned above, or other assessments of diabetes or cardiovascular risk, or on identifying glucose concentration patterns that may benefit from high-resolution information (e.g., high-resolution data of not only the postprandial rise in glucose concentration but also its peak and duration, or glucose variability, can be used to understand the glucose load of a meal), or on identifying subjects with significant variability from meal to meal or day to day (e.g., high-fidelity (e.g., CGM and activity) can correlate glucose patterns with activity or sleep patterns). Determination to perform high-fidelity monitoring may also be based on identifying subjects scheduled for medication changes, subjects in the middle of a coaching program, or recommendations from a coach or other healthcare provider.

[0275] In some cases, machine learning techniques are used to determine, or at least partially, whether high-fidelity data collection is necessary or justified based on low-fidelity data. Any suitable machine learning technique can be used, such as supervised learning models, unsupervised learning models, and / or reinforcement learning models.

[0276] According to supervised learning techniques, a model is trained using a set of labeled training data. In this example, the labeled training data could include a set of low-fidelity data and a label indicating whether each set of low-fidelity data justifies high-fidelity data collection. The trained supervised learning model can receive low-fidelity data and produce an output indicating whether the received low-fidelity data indicates that high-fidelity data collection is necessary or justified. Exemplary supervised learning models that can be used include classification algorithms such as the logistic regression algorithm, naive Bayes classifier, support vector machine, decision tree algorithm, boosting tree algorithm, random forest algorithm, several neural networks, and nearest neighbor algorithm.

[0277] According to unsupervised learning techniques, models are generated using potentially unlabeled, low-fidelity training data. The models identify instances of low-fidelity data that are similar to each other. The models can then be used to identify low-fidelity data that is similar to previous instances of low-fidelity data that required or justified high-fidelity data collection. Examples of unsupervised learning algorithms that can be used include clustering algorithms, anomaly detection algorithms, latent variable models, and several neural networks.

[0278] According to reinforcement learning techniques, a reinforcement learning model can be provided with low-fidelity data and can determine whether the low-fidelity data justifies the collection of high-fidelity data. The reinforcement learning model can also be provided with feedback indicating whether the determination is correct, and this feedback can be used to improve performance. Exemplary reinforcement learning models that can be used include the Q-learning algorithm, the Sarsa algorithm, and the Markov decision process algorithm.

[0279] The decision to initiate high-fidelity data collection can be based at least in part on information collected from activity sensors attached to the patient. For example, the decision to initiate high-fidelity data collection can be based on the fulfillment of activity conditions. For example, activity status may include evidence that the patient exhibits activity exceeding a threshold, or evidence that the patient regularly participates in a certain type of exercise (e.g., walking, running, or activity exceeding a specified baseline) sufficiently frequently. In other examples, the decision to initiate high-fidelity data collection can be based on blood glucose meter data (e.g., fulfillment of blood glucose conditions, such as a determination that the mean blood glucose level exceeds a threshold, or a specified number of glucose readings exceeding a threshold), or location (e.g., frequent visits to exercise facilities or unhealthy restaurants). The decision may also be based on a combination of two or more types of low-fidelity data. For example, activity and blood glucose meter data may be used in combination, activity and location may be used in combination, or blood glucose meter data and location may be used in combination. One example is a determination of secondary factors such as blood glucose levels (e.g., determined by a blood glucose meter) and activity (e.g., activity lowers blood glucose levels) or location (e.g., blood glucose levels decrease or become more controlled after visiting a park or gym, or increase or become less controlled after visiting a fast-food restaurant).

[0280] The characteristics of high-fidelity data collection 410 can be based at least partially on low-fidelity data collection. For example, the system may estimate a period or schedule (e.g., intermittent periods) for high-fidelity monitoring and initiate shipments of necessary supplies (e.g., CGM sensors) or determine the quantity of shipments (e.g., the number of CGM sensors to ship) according to the schedule. In some examples, a high-fidelity system (e.g., a CGM system) may be pre-configured at least partially on low-fidelity data to suit the needs of a subject. For example, one or more preferred metrics may be selected or ranked for a current health goal or multiple health goals, or the system may automatically reconfigure a coaching system (a chatbot or other coaching application running on a smart device such as a watch) with preferred or specified information, such as enhanced glucose metrics. In some examples, the system may integrate enhanced glucose metrics (e.g., dietary metrics) into one or more specified (e.g., most viewed) application screens or devices (e.g., watch displays). The system may notify a patient management facilitator, such as a human coach or a chatbot, of patient management-related information, such as when high-fidelity data is available, or of specified metrics to highlight the subject. The system may also determine guidance or other patient management factors based on behavioral learning about the subject, such as the timing and type of messages, including the delivery of information on postprandial summaries (e.g., the degree or nature of control of blood glucose levels, or loss of control), the benefits of exercise, improvements from medication changes, or compliance, or to conduct information gathering periods. The system may also determine goals (e.g., goals within a given time) based on low-fidelity data. Either of the above or below examples of guidance may be adopted in Method 401.

[0281] Figure 5 is a flowchart of a method 501 for collecting high-fidelity data and low-fidelity data. In 505, high-fidelity data may be collected. High-fidelity data can be used for diabetes health assessment or improvement of diabetes health (e.g., to obtain better control of glucose concentration levels or patterns), or both. High-fidelity data may be CGM data, or any other example of high-fidelity data described above or below.

[0282] In 510, low-fidelity data may be collected for diabetes health assessment or improvement of diabetes health (or both). Low-fidelity data may be activity data or any of the other examples of low-fidelity data described above or below. In some cases, low-fidelity data collection may be based at least partially on high-fidelity data collection. In some cases, insights from high-fidelity data collection may be used to inform app features, graphic apps, and phone apps. For example, the time to acquire low-fidelity data (e.g., checking glucose levels using an instrument) may be determined to capture, for example, high or low glucose concentration values.

[0283] In some cases, guidance may be delivered to patients in 515 to improve their diabetes health. For example, the target audience (e.g., patients) may be educated or made aware of the importance of exercise or dietary choices, or patients may be congratulated or otherwise recognized for achieving exercise goals or glucose control status (e.g., maintaining blood glucose levels within a specified range). Patient guidance may be partially based on high-fidelity data. For example, patients may be informed that their glucose levels tend to rise or fall at certain times, or by certain amounts (e.g., glucose levels may tend to rise in the morning), or that their glucose levels tend to rise or fall before or after certain events, or by certain amounts (e.g., glucose levels may peak some time after a meal).

[0284] In some cases, the high-fidelity data collection phase can personalize metrics, guidance, or other information related to managing a patient's physiological state, such as glycemic health. For example, insights based on high-fidelity monitoring can be used to inform app features, graphic applications, or smart device applications. In some cases, a health concept (e.g., potential guidance or actions taken by the subject) may be ranked or quantified for its potential health impact, and a list of patient management options may be formed into a personalized list for the subject by determining one or more estimates of quantifiable benefits to physiological outcomes (e.g., glucose concentration range, target, time within range, or A1C achievement). For example, one or more patterns (e.g., dietary choices, exercise or activity, or sleep) that result in benefits (e.g., better glucose control) may be determined based at least partially on high-fidelity data. In some cases, correlations may be determined between glucose concentration levels and one or more lifestyle factors (e.g., activity (e.g., steps), meal timing, or food choices).

[0285] Guidance can be based on correlations determined at least partially from high-fidelity data, such as correlations between glycemic health and other measurable characteristics or patterns. For example, guidance can be based on correlations between the amount and intensity of exercise and activity and glucose improvement (e.g., the number of minutes or steps shown to reduce glucose by 20 mg / dL), or between food and dietary choices and glucose improvement (e.g., which foods caused large glucose spikes).

[0286] In some cases, glucose metrics, glucose variability (e.g., deviation from a desired range), or glucose profiles (e.g., glucose concentration patterns) can be determined from low-fidelity data and previously collected high-fidelity data (e.g., using correlations between low-fidelity and high-fidelity data).

[0287] As described, using high-fidelity data can improve the performance of devices that measure and / or utilize low-fidelity data. For example, using only low-fidelity data, generalized guidance can be provided to the user by comparing, for instance, activity levels or other low-fidelity data to generalized guidelines or standards. By using high-fidelity data in combination with low-fidelity data, as described herein, devices can provide personalized user guidance and are therefore more likely to provide meaningful results such as glucose concentration range, target, time within range, or A1C achievement.

[0288] Figure 6 is a flowchart of method 601 for collecting low-fidelity data and intermittently collecting high-fidelity data. In 605, low-fidelity data is collected. Low-fidelity data may be activity, blood glucose meter data, or any of the low-fidelity examples identified above or below.

[0289] At 610, high-fidelity data is collected. While the high-fidelity data is being collected, the collection of low-fidelity data may continue, or the collection of low-fidelity data may be interrupted. Preferably, the low-fidelity collection is continued for at least a portion of the high-fidelity data collection period, such that both the high-fidelity data and the low-fidelity data are collected during overlapping periods. A relationship (e.g., a correlation) between the low-fidelity data and the high-fidelity data may be determined from the data collected during the overlapping periods. For example, the relationship between the low-fidelity data and the high-fidelity data can be found using machine learning techniques, such as, for example, the techniques described herein.

[0290] The method can then return to low-fidelity data collection 605 during a subsequent low-fidelity data collection period, during which time guidance for the patient can be determined based on the low-fidelity data and the determined relationship between the low-fidelity data and the high-fidelity data. In some examples, the low-fidelity data may be used as a proxy for the high-fidelity data in determining patient guidance. The process may cycle between the low-fidelity collection period at 605 and the high-fidelity collection period at 610, such that high-fidelity data is collected intermittently. The intermittent high-fidelity data can be used to refine or update (e.g., recalibrate) the determined relationship between the high-fidelity data and the low-fidelity data. In some examples, the process can return to high-fidelity collection at 610 in response to a detected or reported health change (e.g., a change in glucose concentration level, body weight, activity, or a new diagnosis). In some examples, high-fidelity data is collected periodically (e.g., once per quarter, once per year, etc.). Collecting a new set of high-fidelity data allows the relationship or correlation between the low-fidelity data and the high-fidelity data to be updated, and the patient's guidance to be revised.

[0291] Figure 7 is a flowchart of method 701 for managing patient status. In 705, patients are identified for screening from a patient pool. A patient pool may include, for example, a group of patients in a clinical practice, or a designated insurance pool or program, or a geographical location, or workplace, or any combination thereof. For example, a pool of 100, 10,000, or 100,000 patients may be identified.

[0292] In 710, the patient's condition or health history is assessed for diabetes or diabetes risk factors. For example, the patient's weight, body mass index, family history, genetic markers, prescription history (e.g., prescribed medications), medical history (e.g., diagnosis of type 2 diabetes or other metabolic disorders, which may be determined from, for example, electronic health record codes or other data), laboratory results (e.g., A1C, fasting glucose levels, oral glucose tolerance), other metabolic disorders, or other factors may be assessed to identify potential risk factors that may indicate diabetes, prediabetes, or vulnerability to developing diabetes. Exclusion criteria may also be applied, such as a diagnosis of type 1 or type 2 diabetes by intensive insulin therapy. In some cases, the screening may produce a simple yes / no output. In some cases, a subset of 10% of patients in the pool (e.g., 10,000 out of 100,000) may be identified as candidates for enrollment in an enhanced diabetes management program. Other examples may provide more detailed outputs, such as classification as type 1 diabetes, type 2 diabetes, or gestational diabetes, or classification of type 2 diabetes based on disease progression or glycemic control (e.g., prediabetes, early type 2, or full type 2), or quantification of disease progression (e.g., on a scale from 0 (normal glucose tolerance) to 9 (persistent uncontrolled hypoglycemia or hyperglycemia)).

[0293] In step 715, enrollment selection is performed to determine whether the patient is to be enrolled in the diabetes management program. Enrollment selection may occur in response to the fulfillment of enrollment criteria, which may be based on, for example, additional screening input, consideration of additional current or previous medications, progression of diabetes, effectiveness of previous treatments, predicted disease progression, adherence to or participation in previous health promotion programs (e.g., exercise or medication compliance), or any of the factors mentioned above (e.g., weight, BMI, family history). In some cases, scores or other predictions may be determined based on the future diabetes risk or cost if the patient continues in the current diabetes management program. Additionally or alternatively, scores or other predictions may be determined based on calculated potential benefits or predicted success of the enhanced diabetes program. In some cases, weighted scores may be determined based on a combination of potential health risks or costs (or both) and strong benefits (e.g., cost savings or impact on patient health). Based on the scores or other information mentioned above, enrollment selection may determine the patient's assignment to enroll in the enhanced diabetes patient management program in step 725, or to continue in the current diabetes management program in step 720. Identification in 705, evaluation in 710, and enrollment selection in 715 may be performed by one or more decision systems, such as the execution of algorithms on a computer system or mobile device, such as one or more devices shown in Figures 1 and 2. If a patient is not selected for the enhanced diabetes management program in 720, the method returns to patient selection from the patient pool.

[0294] In 725, the patient may be enrolled in an enhanced diabetes management program. For example, a diabetes management system may enroll the patient in an enhanced diabetes management program in response to the fulfillment of enrollment criteria. In 730, a data-driven patient management process may be implemented. For example, data such as activity (e.g., using a wearable device), blood glucose meter data, user input data (e.g., food or drink selection), location, or physiological data (e.g., heart rate or respiration) may be used to determine guidance for the patient regarding the management of their physiological condition. Activity data measured by a wearable device may include, for example, data captured using an accelerometer of another motion sensor associated with the wearable device. Guidance can, for example, educate or raise awareness in patients about exercise or dietary choices; celebrate or otherwise recognize achievements (e.g., completing exercise, or exercising for a specified number of consecutive days or days within a period (e.g., three times a week or ten times a month)); or celebrate or otherwise acknowledge positive dietary choices (e.g., healthy dietary choices or calorie restriction). In some examples, enhanced diabetes management may include the collection and correlation of low-fidelity and high-fidelity data, as described above with reference to Figures 4, 5, or 6, and below with reference to Figures 8B and 8C.

[0295] In 735, decisions are made regarding data-driven patient management. For example, decisions may be based on the fulfillment of diabetes management conditions. Diabetes management conditions may be based on, for example, the amount (e.g., percentage) of time when blood glucose (e.g., determined by a blood glucose meter) is within the target range (e.g., 70-160 mg / dL), the level of glycated hemoglobin or hemoglobin A1c in the blood (e.g., A1C test result), other diagnostic tests, changes in BMI, weight, or body composition (e.g., body fat percentage), cardiovascular health, or one or more other factors or diagnostic tests. Decisions may be made, for example, by a computer system configured to determine from collected data whether diabetes management conditions are met. In some examples, the computer system may apply data inputs to a model that can be based on a specific patient or population. Model outputs may include fulfillment status (e.g., met or not met) or predictions about future health status (e.g., whether the patient's health may improve, stabilize, or deteriorate).

[0296] If the diabetes management conditions are met, the method may revert to data-driven patient management in 730, and the system may continue the previous patient management scheme or implement improvements (e.g., more frequent data collection or more proactive guidance), which may be based on the information used when making the determination in 735.

[0297] In 735, if diabetes management conditions are not met, the process may proceed to a more robust patient management scheme in 740. For example, the process may begin to collect or receive continuous glucose monitoring information. For example, information from a patient's continuous glucose monitor may be used to determine patient guidance. CGM data may be used in combination with other data sources to determine guidance. In some examples, a CGM-driven patient management scheme may use intermittent CGM data. For example, CGM data may be collected during a first period, and the data collected during the first period may be used (optionally in combination with other non-CGM data) to determine guidance for the patient during a second period when CGM data is not available. In some examples, CGM-driven patient management may include a continuous cycle of intermittent CGM use, such as performing CGM data collection a specified number of times at specified intervals (e.g., monthly, quarterly, or yearly, for one week, ten days, or two weeks). The use of intermittent CGM may reduce the cost of managing the patient. For example, because fewer sensors are needed for intermittent CGM data collection and only intermittent monitoring services via a CGM server are required, the use of intermittent CGM may be less expensive than the use of intermittent (e.g., continuous) CGM. The use of intermittent CGM may also reduce the cost of managing patients by providing additional insights into managing patients' glucose concentration levels and slowing or stopping progression to type 2 diabetes compared to not using CGM, which can reduce overall healthcare costs or improve patient outcomes (e.g., improved health).

[0298] In some cases, after a period of CGM-driven patient management, the process can revert to data-driven patient management in 730, at which point the collection of CGM data may be stopped, and the patient may be managed based on non-CGM information. Information collected during CGM-driven patient management 740 may be used to manage the patient during data-driven patient management 730 when CGM data is unavailable (e.g., to determine guidance for the patient). For example, relationships (e.g., correlations) between CGM and non-CGM information may be used to infer glucose concentration levels or ranges estimated from non-CGM data.

[0299] In various examples, all steps of the process can be performed by a patient management system capable of collecting, storing, and analyzing data about the patient. In some examples, data-driven patient management 730 may include the collection of low-fidelity data, and the second stage of patient management 740 may include the collection of high-fidelity data. It is understood that while CGM data is provided as an example, other sources of high-fidelity data may also be used, and that the exemplary methods may also be adapted to the management of other diseases in addition to, or instead of, the management of diabetes or prediabetic conditions.

[0300] Figure 8A is a flowchart of the process 801 for managing the first patient. In 805, patient 1 is selected. In 810, the enrollment decision is made, for example, by applying a enrollment algorithm by a computer system, which may use health data such as height, weight, body mass index, and blood glucose levels. In 815, a decision is made to maintain the current patient management program, which may include, for example, the delivery of guidance for periodic examinations and periodic health checkups, but not continuous data collection between health checkups. Periodic health checkups may be visits to a clinic or electronic health checkups based on known or periodically (e.g., every six months or annually) collected information about the patient. In some examples, each step in the management of patient 1 may be carried out by a patient management system that receives or collects information about the patient and can make one or more decisions based on the patient data (e.g., by applying an algorithm to a model or by applying data to a model).

[0301] Figure 8B is a flowchart of an exemplary process 803 for the management of a second patient. In 830, patient 2 is selected for evaluation. In 835, enrollment is made, for example, by applying an enrollment algorithm by a computer system, which may use health data such as height, weight, body mass index, and blood glucose levels. In 840, patient 2 is enrolled in a Stage 1 coaching scheme, where guidance may be provided to the patient, for example, via a handheld device or watch, based on low-fidelity data. For example, a chatbot function, as described herein, can be used to provide guidance to the patient. In 845, low-fidelity data is collected, and coaching or other guidance is determined, at least in part, based on the low-fidelity data. In 850, treatment selection is made. Treatment selection 850 may be based at least in part on the low-fidelity data. Treatment may include, for example, initiating treatment such as insulin delivery (e.g., via a smart insulin pen) or initiating oral medication. In some cases, treatment options may include guidance on administering a prescribed bolus dose (e.g., considering an immediate insulin injection) or guidance on engaging in activities (e.g., walking or running to lower glucose levels). In 855, low-fidelity monitoring and coaching are continued for patient 2.

[0302] Figure 8C is a flowchart of an exemplary process 805 for the management of a third patient. In 860, patient 3 is selected for evaluation. In 865, enrollment is made, for example, by applying an enrollment algorithm by a computer system, which may use health data such as height, weight, body mass index, and blood glucose levels. In 870, patient 3 is enrolled in a Stage 1 coaching scheme, for example, via a handheld device or watch, to which guidance may be provided. In 875, low-fidelity data is collected for patient 3, and coaching or other guidance for patient 3 is determined based at least in part on the low-fidelity data. Coaching and / or other guidance may be provided to patient 3 via a handheld device 112, for example, using a chatbot, video, animation, or other user interface mode. In 880, treatment selection is made. Treatment selection 880 may be based at least in part on the low-fidelity data. Treatment selection may be the initiation of treatment, such as an insulin injection program or oral medication. Treatment selection may, in some cases, be a decision to involve the patient in a Stage 2 coaching scheme, which may be based at least in part on high-fidelity data collected about the patient (e.g., CGM data). For example, the factors or process steps described above with reference to Figure 4 may be applied to low-fidelity monitoring 875 or treatment selection 880.

[0303] In 885, the patient may be enrolled in a Stage 2 coaching program. In 890, high-fidelity monitoring may be performed. For example, continuous glucose monitoring (CGM) data may be received or collected. In some examples, high-fidelity data may be analyzed to determine whether the data meets criteria (e.g., statistical metrics) for identifying correlations, patterns, or one or more correlations. In some examples, machine learning techniques may be used, as described herein. In 895, low-fidelity monitoring may be performed, and coaching or other guidance may be delivered to the patient (e.g., via an interface on a user device such as a smartphone or watch). In some examples, the guidance in 895 may be based at least in part on high-fidelity data (e.g., CGM data) collected during the high-fidelity data collection period, or on the relationship between high-fidelity and low-fidelity data.

[0304] Figure 9 is a flowchart of the process for monitoring a patient using primary and secondary monitoring techniques. Primary techniques may include receiving or collecting a first type of data ("primary data" or "first data"), and secondary techniques may include receiving or collecting a second type of data ("secondary data" or "second data"). For example, primary monitoring may include collecting or receiving high-fidelity information about the patient, and secondary monitoring may include collecting or receiving low-fidelity information about the patient. In an example where the patient is diabetic, primary techniques may include, for example, continuous glucose monitoring. Secondary techniques may include receiving or collecting, for example, activity information, location information, user input information, or glucose concentration information (e.g., single-point glucose data such as blood glucose meter data, glucose data from an NFC-enabled sensor, optical glucose data, or glucose information collected by another technique).

[0305] In 902, primary monitoring is performed to collect first data of a first type during the primary monitoring period. In some examples, monitoring may include receiving first data from a sensor system, such as a continuous glucose monitoring system. In some examples, monitoring may include receiving sensor signals from a sensor circuit and processing the sensor signals to generate at least a portion of the first data.

[0306] In 904, secondary monitoring is performed to collect a second type of second data during the secondary monitoring period. The secondary monitoring period may overlap with all or part of the primary monitoring period in overlapping periods. In some examples, monitoring may include receiving second data from a second sensor system. In some examples, secondary monitoring may include receiving sensor signals from the sensor and processing the sensor signals to generate at least part of the second data.

[0307] In some cases, secondary monitoring may include monitoring activity using wearable fitness trackers. Wearable fitness trackers may include, for example, wearable heart rate monitors, wearable activity monitors, smartphones, smart glasses, or smartwatches.

[0308] In some examples, the second set of data may include user input data. For instance, user input data may include medication data, diet data, exercise data, sleep data, or any combination thereof.

[0309] In some examples, the first type of data may include estimated glucose concentration levels, while the second type of data may include one or more detected physiological signals such as heart rate, oxygen saturation, skin tension, skin moisture content, activity, activity pattern, blood ketone concentration levels, urinary ketone concentration levels, and respiration.

[0310] In 906, a correlation between the first data and the second data is determined. The correlation may be positive or negative. The correlation may be determined, for example, by determining a pattern or relationship between multiple data points of the first data and multiple data points of the second data that correspond to the first data (for example, corresponding to the same time point, or time-shifted to recognize a change in the first data after a change or event in the second data, or time-shifted to recognize a change in the first data after a change or event in the second data). In various examples, the correlation may be calculated using data retrieved from a memory device, for example, a processor and memory circuits. In some examples, the correlation may be determined using a processor by retrieving stored data from memory, and using machine learning techniques based on at least some of the stored data. In some examples, determining the correlation may involve determining the relationship between the first data and the second data acquired at corresponding times and / or days of the week within overlapping periods. For example, the processor might determine from stored data that glucose concentration levels tend to be high (e.g., exceeding 150 mg / dL during the morning hours (e.g., 7 a.m. to 10 a.m. or 3 hours after waking up)), but that on days when the patient takes an early morning walk, glucose concentration does not tend to be high, or does not tend to be high (e.g., glucose concentration below 126 mg / dL).

[0311] In some cases, the correlation is based on multiple types of secondary data. For example, a model may be trained to determine the relationship between activity, heart rate, and estimated glucose concentration levels (determined, for example, using a CGM system).

[0312] In some examples, the method may include determining a treatment or monitoring scheme using correlations and primary data in 908. For example, secondary data may include single-point glucose monitoring (e.g., readings from a blood glucose meter), and the method may include calculating a time window (e.g., an optimal window or a recommended window) for making single-point glucose measurements, based at least in part on the primary data. In some examples, by obtaining one or more single-point glucose measurements at appropriate timings, it may be possible to accurately determine one or more estimated glucose concentration levels (e.g., a specific level or range) between measurements, based, for example, interpolation, determined correlations, additional types of secondary data (e.g., heart rate or activity), or any combination thereof. In some examples, the method may include determining a time window for obtaining or using non-glucose information, such as activity information, heart rate information, or user input. The method may further include prompting a user (e.g., a patient) to obtain a measurement (e.g., check blood glucose using a blood glucose meter) or to attach a sensor (e.g., place it on a wearable activity monitor). The prompt may be delivered via a smart device such as a watch or handheld device.

[0313] In step 910, the process may include an additional period of secondary monitoring. Secondary monitoring 910 may be performed during a period when primary monitoring is not being performed. Secondary monitoring may include obtaining a single-point glucose measurement (or other sensor information or user input) at the time determined in step 908.

[0314] In step 912, the process may include determining diabetes information using the determined correlations (from step 906) and secondary data (from step 908). In various examples, diabetes information may include estimated values ​​of the first type of data over time, patient status, or patient insights. Patient status or patient insights may relate to lifestyle changes, such as diet, exercise, glucose level monitoring, or medication. In some examples, patient status or patient insights may relate to mealtime management, exercise management, or sleep management.

[0315] In one example, if the primary data is an estimated glucose concentration level (e.g., from a CGM), the estimated glucose concentration level can be determined from the secondary data based on a determined (e.g., learned) relationship between the secondary data and the estimated glucose concentration level. In another example, the secondary data may be physiological information (e.g., activity data, heart rate data), or both, or include both, and the estimated glucose concentration level or range (real-time or average over a specified period) is determined using the determined relationship and physiological information.

[0316] In some examples, the method may involve intermittently monitoring a first type of data (e.g., CGM data) and using a second type of data (e.g., activity or single-point blood glucose, or both) and correlations to determine diabetes information during one or more periods when the first type of data is unavailable. For example, the first type of monitoring data 902 may include continuous glucose monitoring, and the second type of monitoring data 904 may include monitoring activity data using a wearable accelerometer. The wearable accelerometer can be configured to monitor data when continuous glucose monitoring is not being performed.

[0317] In Article 914, the method may include delivering guidance or treatment. For example, the method may include displaying diabetes information about a patient on the user interface of a patient device such as a handheld device or watch, or on a display on wearable glasses. Displaying diabetes information may include, for example, displaying recommended dietary or lifestyle changes on the user interface.

[0318] In some cases, the method may include, in 914, providing treatment based at least in part on the determined diabetes information. Treatment may include, for example, drug interventions such as oral medications or drugs administered via a pump.

[0319] In some examples, the method may include primary monitoring during the third period in 916.

[0320] In 918, the correlation may be updated at least in part on primary data collected during the primary monitoring in the third period in 916. In some examples, the secondary monitoring step 910 may be extended to at least part of the primary monitoring 916 during the third period, and the correlation may be updated based on the secondary monitoring 910 and the primary monitoring 916.

[0321] In step 920, the method may include secondary monitoring during a fourth period. The method may return to step 912, and diabetes information may be determined using updated correlations (from step 918) and secondary monitoring data from step 920. The process may deliver guidance or treatment in step 914, perform primary monitoring in step 916, update correlations in step 918, perform secondary monitoring again in step 920, and return to step 912 again, resulting in intermittent primary monitoring as the process cycles through the method steps.

[0322] In various examples, any of the steps of method 901 may be omitted or combined with other steps. For example, step 912 may be omitted, combined with step 910, or step 910 may occur after step 912.

[0323] Figure 10 is a flowchart of an exemplary method 1001 for determining and notifying a patient about diabetes information. Method 1001 may be performed on a system such as system 100 shown in Figure 1. In 1002, the estimated glucose concentration level may be received from a continuous glucose monitoring (CGM) system during a first period. The method may optionally include detecting the estimated glucose concentration level using a CGM sensor. The first period may be, for example, several days (e.g., 7, 10, or 14 days) or several weeks (e.g., 4 or 10 weeks). For example, a patient may be enrolled in a CGM study to collect information on the patient's response to various stimuli such as oral medications, exercise, and activity.

[0324] In 1004, non-CGM information related to the patient may be received during the first period. The method may optionally include detecting non-CGM information using sensors. In some examples, the non-CGM information may include activity information, location information, or user input data. In some examples, the non-CGM information may include physiological information about the patient. Physiological information may include, for example, one or more of the following: heart rate, respiration, oxygen saturation, skin tension, skin water content, activity, activity pattern, blood ketones, urinary ketones, respiration, or acoustic information.

[0325] In step 1006, the relationship between the estimated glucose concentration level and non-CGM information is determined. For example, the correlation between non-CGM information and the estimated glucose concentration level can be calculated. In some cases, the model may be trained from collected CGM and non-CGM data, and as a result, the estimated glucose concentration level may be determined from the non-CGM data by applying the non-CGM data to the model.

[0326] In 1008, non-CGM information relevant to the patient may be received during a second period. The second period may be a period during which estimated glucose concentration levels are not available from the CGM. In 1010, diabetes information for the patient during the second period may be determined based on the determined relationships and non-CGM information. Determining diabetes information for a patient may include determining the patient's condition. Determining the patient's condition may include applying non-CGM information to a model. In some examples, determining diabetes information may include determining estimated glucose concentration levels. For example, an algorithm may infer estimated glucose concentration levels from activity information calibrated to glucose concentration levels at the individual level (e.g., based on patient information) or the population level, or both (e.g., using a predictive learning model).

[0327] In some cases, determining diabetes information may involve determining a qualitative classification such as green, yellow, red, or “good control,” “moderate control,” or “poor control.”

[0328] In some cases, determining diabetes information may involve determining quantitative metrics. These quantitative metrics could be estimates of, for example, the amount or percentage of time during a given period when glucose concentration levels were within a specified range. In some cases, quantitative metrics may not be available in real time. For example, quantitative metrics might include time within a specified range (e.g., a day or a few hours), which may be reported at the end of the day or intermittently, such as hourly, daily, or weekly.

[0329] In 1012, the system may electronically notify the patient of diabetes information. For example, the system may present a notification (e.g., a word or symbol) on the display of a handheld device, smartwatch, eyeglasses, or other wearable electronic product, or the system may present an audio notification (e.g., a verbal message or sound) or a tactile notification (e.g., vibration) on the speaker of such a device. In examples where audio notifications are used, the audio notifications may be provided by an implemented chatbot, as described herein. In some examples, the notification relates to the severity of the diabetes information. Consider an example where non-CGM information indicates a hypoglycemic state. The system may present a more serious notification to indicate urgency. For example, the system may present a high-frequency or high-duration sound, a verbal message presented with increased rhythm or volume, and / or a high-duration and / or high-amplitude tactile notification. Consider another example where non-CGM information indicates normal or favorable blood glucose levels. The system may present less critical notifications, such as sounds of lower frequency or duration, verbal messages presented with reduced rhythm or volume, and / or tactile notifications of shorter duration and / or amplitude.

[0330] The system can improve patient management, for example, by managing the costs incurred by continuous glucose monitoring, or by enabling glucose estimation to motivate users (e.g., patients) to take measures to manage their glucose levels. For example, utilizing low-frequency and high-frequency data in the manner described with respect to exemplary method 1001 can provide the benefits of high-fidelity data acquisition at reduced cost. For example, the system's performance during low-fidelity data acquisition may be comparable to that during high-fidelity data acquisition, thus eliminating the need to frequently perform high-cost high-fidelity data acquisition. Furthermore, patient blood glucose control can be improved, for example, at the cost of full-time high-fidelity data acquisition.

[0331] Figure 11 is a flowchart illustrating an exemplary method for determining a monitoring scheme based on collected sensor information, which may, for example, represent characteristics related to patient involvement or behavior. For example, CGM detection, CGM detection parameters (e.g., schedule or amount of CGM detection), user interface parameters (e.g., type or content of guidance), or goals (e.g., glucose target range or A1C target) may be determined based on activity data or other collected information.

[0332] Method 1101 may include, in 1102, monitoring a first sensor input to acquire a first type of first data. For example, Method 1101 may include monitoring a first type of patient data over a first period of time using a low-fidelity monitoring technique. In various examples, the low-fidelity technique may include receiving user input data such as medication data, diet data, exercise or activity data, sleep data, or any combination thereof.

[0333] Monitoring of the first sensor input may include, for example, activity monitoring, single-point blood glucose monitoring (e.g., monitoring using blood glucose meter information), optical glucose monitoring (e.g., using a watch with an optical sensor), or "blind CGM" (e.g., continuous glucose monitoring where the estimated glucose level is not presented to the patient, e.g., the glucose level is transmitted to a server for later analysis or stored in the memory of a local CGM or device in the patient). Monitoring of the first sensor input may include activity monitoring by wearable fitness trackers such as wearable heart rate monitors, activity monitors, smartphones, smart glasses, or smartwatches.

[0334] Method 1101 may further include, in 1104, evaluating patient engagement or behavior based on monitored first type patient data. For example, a remote system (e.g., a server-running algorithm) or a local system (e.g., a handheld device) may evaluate a user's suitability or preference in terms of the complexity or number of features available in a user interface. Skilled or highly engaged users may prefer a more complex or fully-featured interface than less skilled or less engaged users. Such determinations may be based, for example, on the frequency of interaction with a device (e.g., a handheld device or watch), the timeliness of the interaction, the relevance of the interaction (e.g., responsiveness to warnings), adherence to guidance (e.g., participating in exercise in response to guidance to do so), or interaction with another application (e.g., based on interaction with a fitness tracker application).

[0335] The method, in 1106, may include determining a monitoring scheme based on an assessment of patient involvement or behavior. For example, the method may include determining the functionality of the device's hardware or software. The hardware or software functionality may, for example, correspond to the operation of a user interface. In some examples, the determined functionality may include a simple or lightly functional interface, which may be applied in response to identifying, as part of the assessment, patients with less involvement or those who may benefit from less complex interactions. The determined functionality may also include a relatively complex or fully functional interface, which may be applied in response to identifying highly involved users or users (e.g., skilled users) who may prefer a more complex interface (e.g., one that includes more functionality or provides more configuration options such as programmable warnings or more frequent guidance). In some examples, the user interface may be additionally or alternatively adapted based at least in part on the user's age or date of birth (e.g., year). For example, the user interface may use larger fonts or user interface elements (e.g., buttons), or a different presentation scheme for older users (e.g., more contrast or a specified color scheme). In some examples, a user interface may provide a visual challenge to determine if the user has difficulty identifying or selecting user interface elements, or may prompt the user for information regarding their vision, and the user interface may adapt based on the user's response to the challenge or prompt.

[0336] In some cases, the determined hardware or software functionality may be related to the frequency (e.g., how often the device communicates with the user) or content (e.g., the subject of the communication with the user) of the automated coaching routine. For example, if the user is contacted too frequently, they may become fatigued and drop out. On the other hand, if the user is not contacted frequently enough, they may not receive sufficient guidance to achieve the desired outcome. Method 1101 may involve correlating patient behavior with different contact frequencies.

[0337] In some examples, determining a monitoring scheme may involve determining patient goals. The method may involve determining the hardware or software functions of a monitoring device (e.g., a handheld device or a wearable device) that are relevant to or facilitate the goals. In various examples, goals may include dietary goals, exercise goals, glucose level monitoring goals, or medication goals. In some examples, at least one hardware or software function of the monitoring device may relate to mealtime glucose management (e.g., strategies for managing glucose levels before, during, or after meals, or by exercising before meals, or by administering insulin before meals, e.g., before, during, or after meals, or any combination thereof ("pre-bolus" strategies). In some examples, at least one hardware or software function of the monitoring device may relate to sleep management (e.g., strategies for controlling glucose levels during sleep, or strategies for avoiding or minimizing sleep interruptions to address glucose level problems).

[0338] In some cases, patient goals may be determined, at least in part, based on a first sensor input (e.g., data monitored using low-fidelity monitoring techniques).

[0339] Method 1101 may further include determining the quantity or frequency of monitoring in 1108. In some examples, the quantity or frequency of subsequent data (e.g., a second sensor input or high-fidelity data) may be determined based at least in part on the first sensor input, for example, based on data collected by a low-fidelity monitoring technique. The quantity or frequency of data may include the quantity of data points, the number of high-fidelity sensors used (e.g., the number of CGM sensors used continuously or intermittently to collect CGM data), or the periodicity between data collection events (consistent or irregular periods). The quantity or frequency of subsequent data may also be based at least in part on a specified goal or outcome. For example, the quantity or frequency of data may be calculated to increase or maximize a patient parameter, such as the quantity or percentage of time at a specified range of glucose concentration levels or the patient's A1c levels.

[0340] Method 1101 may include monitoring a second sensor input in accordance with a determined monitoring scheme in 1110. For example, the method may include monitoring a second type of patient data over a second period using high-fidelity monitoring techniques with monitoring devices. High-fidelity monitoring may include, for example, continuous glucose monitoring.

[0341] Method 1101 may further include providing guidance to the patient, for example, via a system 100 shown in Figure 1, in 1112. For example, the system may provide automated messages transmitted from a server to a monitoring device based on patient profile data or a first sensor input. In some examples, guidance may be provided using a fitness tracker application, a meal tracking application, or a dedicated CGM or guidance application. For example, an application may deliver CGM data, information based on the CGM data (e.g., range time), guidance for the subject (e.g., "Consider an exercise session"), and predicted, estimated, or measured exercise benefits for glucose control. In some examples, an application may educate the user about food choices and the resulting postprandial glucose control (e.g., fluctuation), or educate or quantify the relationship between exercise and the glucose-lowering effect of exercise. For example, an application may indicate that a user's selected activity is estimated to bring the user's glucose level to a desired value or range (e.g., "Recent activity should bring glucose levels to a desired range"). In another example, the application might indicate that a suggested activity is likely to bring the user's glucose level to a desired value or range (e.g., "It is estimated that a one-hour run will lower the glucose level by 15 mg / dl"). In some examples, guidance can be provided by a chatbot function, as described herein.

[0342] Method 1101 may further include detecting changes in patient parameters (e.g., improved glucose concentration control or A1C improvement at a particular time or under specified conditions) in 1114. Changes may be measured between a first period in which first sensor inputs are collected and a second period in which second sensor inputs are collected. Detected changes may be used to further influence at least one hardware or software function of the monitoring device. In some examples, machine learning techniques may be used to relate characteristics of the monitoring or guidance scheme to changes in patient parameters. For example, positive changes may correlate with certain aspects of the monitoring scheme or guidance, and the hardware or software function of the monitoring device may be modified to highlight the aspects correlated with positive changes. Such iterative modifications may improve the performance of the monitoring system in guiding the patient toward positive clinical outcomes or the achievement of management goals (e.g., toward better controlled glucose levels or lower A1c test results). In some examples, indicators of increase or maximization of patient parameters may be displayed on the monitoring device.

[0343] The method can be repeated to provide continuous guidance to the patient. For example, after step 1114, the method can return to steps 1102, 1106, or 1110. In some examples, one or more steps of the method can be omitted each time the method is repeated, or at that time.

[0344] In some examples, the method may include determining the patient's ultimate goal. The patient's ultimate goal may be based at least partially on a first type of patient data, a second type of patient data, or both. The method may further include displaying treatment recommendations (e.g., displayed as guidance) calculated to move the patient's condition toward the patient's ultimate goal.

[0345] Figure 12A is a diagram of an exemplary user interface 1202, which may be presented on a user device such as user device 132, or additionally or alternatively, on a handheld smart device (e.g., a smartphone) 112, a tablet 114, a computer 118, a wearable device 120, a peripheral medical device 122, or a remote terminal 128.

[0346] The user interface 1202 may include a chart 1204 which may show glucose concentration levels 1236 (e.g., measured in mg / dL) plotted against a time axis 1234. The user interface 1202 may also show upper and lower limits 1230 and 1232 of the target range. In various examples, the target range may be set by the user (e.g., the patient), determined by a device or system (e.g., a handheld device 112 or 120 shown in Figure 1), or provided by a coach (e.g., a human coach or a computerized "chatbot" coach). In the illustrated example, the upper limit is set to 180 mg / dL and the lower limit is set to 80 mg / dL. In some examples, the range may be set to 70–160 mg / dL (e.g., by the system or by default), and the range may be expanded (e.g., to 70–180 mg / dL) or narrowed to suit a particular patient, which may be determined, for example, from the CGM pattern, low-fidelity data, or user input. An enlarged view of the chart is shown in Figure 12B. In various examples, the glucose concentration level may be an estimated blood glucose concentration level (e.g., a level calculated based on GCM data or other data), or the plotted glucose level may include blood glucose levels from an instrument. Exemplary chart 1204 shows a 24-hour period (e.g., from 12:00 a.m. to 12:00 a.m. the following day), but in various other examples, the chart may show shorter periods (e.g., 1 hour, 3 hours, 6 hours, or 12 hours) or longer periods (e.g., 2 days, 3 days, 1 week, 2 weeks, 1 month, or 3 months). For longer periods, the plotted values ​​may correspond to daily or weekly averages, or the graph may show a range or distribution of values ​​or averages (e.g., bars indicating highs and lows, and a dot or line indicating the median or mean). Glucose concentration levels are shown, but other types of analyte levels, or other types of sensor data, may be shown instead of or in addition to glucose concentration levels (e.g., on the same chart or on different charts).

[0347] User interface 1202 may include multiple event indicators that can indicate physiological events, dietary events, activity events, and medication events. For example, user interface 1202 may show a glucose event 1206 around 4:30 AM, at which point the glucose concentration level has reached a low point of 51 mg / dL, and a sharp downward trend is indicated by two downward arrows. In some examples, especially if the user is known to be a heavy insulin user, event 1206 may prompt the user to consume carbohydrates to avoid a potential low blood glucose problem, in response to a warning on a smart device (e.g., wearable device 120 or user device 132). The user interface may show a second glucose event indicator 1214 around 1:30 PM, at which point the glucose concentration level is moderate (129 mg / dL), and the trend was stable (indicated by a horizontal arrow). A glucose event 1214 may correspond, for example, to a user-specified post-lunch report, or may occur at a time calculated by the system (e.g., noon or post-lunch report). An exemplary user interface 1202 shows a third glucose indicator 1222 at approximately 7:30 p.m., at which point the glucose concentration level was high (203 mg / dL) and rapidly increasing, as indicated by the two upward arrows in this example. In some examples, the glucose indicator may be visually identified by shading, color, or other means to indicate whether the glucose concentration level meets glucose control conditions, for example, whether the glucose concentration level is within a specified range.

[0348] The user interface 1202 may include multiple meal indicators, for example, a breakfast indicator 1208, a lunch indicator 1212, and a dinner indicator 1220. The meal indicators 1208, 1212, and 1220 may correspond to the user's meals. The user's meals may be identified from user input, such as a smartphone input indicating that a meal has been consumed, and may optionally include information about the meal, such as the contents of the meal (e.g., carbohydrates, protein, fat, or food type, such as "one slice of pizza and a glass of milk"). In some examples, the user's meals may also be identified from other types of input, such as geolocation data and motion data. For example, geolocation data may indicate that the user is in their kitchen, a restaurant, or another location where food is prepared and / or served. Motion data may also indicate the user's motions that correspond to eating. Such motions may include, for example, the user repeatedly moving their hand to their mouth.

[0349] The user interface 1202 may also include activity events such as walking events 1216. In some examples, walking events 1216 may be determined by the system at least partially based on activity data from activity sensors (e.g., from a wearable device 120) or on physiological sensors (e.g., a heart rate sensor) or a combination thereof. In some examples, walking events 1216 may be at least partially based on user input (e.g., input via a user device 132 indicating that walking has occurred).

[0350] The user interface may include a medication event 1224, which may be based on user input (e.g., input received via user device 132) or on detected or controlled events from a device (e.g., from an event sensor on an insulin injection device or from medication information received from a pump).

[0351] The user interface may also include guidance comments. For example, the user interface may include a guidance bubble 1210 stating, "There have been spikes at 1 PM for the past three days," and a second guidance bubble 1226 stating, "It is best to take medication before bedtime." In some examples, the guidance bubbles are provided in the morning, and the data event indicators appear throughout the day as time progresses. If guidance bubbles 1210 and 1226 are provided in advance, the guidance can prompt the user to take action, such as modifying their breakfast diet or taking a midday walk to address the recurring glucose spikes at 1 PM. In some examples, selecting guidance bubbles 1210, 1226, etc., can activate a chatbot function to provide guidance to the user.

[0352] In some examples, the user interface may include game features (e.g., rewards or badges) to encourage user engagement. For example, user interface 1202 may present a badge 1218 that can show a still or animated walking person, and may also acknowledge the patient's activity behavior by presenting a comment such as "Postprandial walking skill unlocked!". In some examples, the decision to award the postprandial walking skill may be made by the system (e.g., a remote system connected via network 124 or a processor in user device 132). The user interface may also include a medication badge (Rx) 1228 that may display a message such as "Medication optimization skill unlocked". In some examples, the system may decide to award the medication badge 1228 based on the fulfillment of administration conditions (which may be detected by activity sensors, posture sensors, physiological sensors, or any combination thereof), such as administering medication within a specified period before sleep. In some examples, machine learning techniques may be used to associate game features with patient outcomes, such as a desired level of glucose control. In this way, the system may position game features to improve patient outcomes and thereby enhance the effectiveness of the system.

[0353] In some examples, the user interface may provide a plot of glucose levels along with an indicator of the average glucose level to achieve a specific A1C value. Figure 12C is a diagram of an exemplary user interface 1250 that includes a target A1C indicator 1254. The user interface 1250 includes a plot 1252 of blood glucose over time. The target A1C indicator 1254 shows the average blood glucose corresponding to the A1C desired by the user. In the example in Figure 12C, the A1C indicator 1254 is located at a blood glucose level of 154 mg / dl, corresponding to an A1C of 7.0. In some examples, a target A1C indicator such as example 1254 may be used in other user interfaces, such as user interface 1202 described herein. Furthermore, similar to user interface 1202, user interface 1202 may be presented on a user device such as user device 132, or additionally or alternatively, on a handheld smart device (e.g., smartphone) 112, tablet 114, computer 118, wearable device 120, peripheral medical device 122, or remote terminal 128.

[0354] Figure 13 is a flowchart illustrating a method for identifying or selecting patients who may benefit from an enhanced disease management program, such as intermittent continuous glucose monitoring (CGM) or other high-fidelity monitoring for the management of type 2 diabetes, or low-fidelity monitoring (e.g., activity monitoring) with optional correlation to high-fidelity (CGM) information. In some examples, the method may include determining whether patient improvement conditions are likely to be met by enhanced monitoring. For example, the method may include determining the estimated likelihood that a patient will benefit from an enhanced monitoring scheme. The estimated likelihood may be a calculated value or percentage, such as 75%, 90%, or 95%, which may be optionally set by the user (e.g., the patient or healthcare system administrator). The method may include measurable improvements as indicators showing that a patient will benefit (or has benefited) from enhanced monitoring, such as a decrease in A1c, achievement of an A1c target (e.g., A1c < 7.0), or a decrease in glucose variability, or any combination thereof.

[0355] In 1302, systems such as systems 125, 126, or 127 can be screened for a first characteristic. For example, a system may run a first screening algorithm (e.g., on a processor) on stored data of a pool of participants (e.g., patients) to determine a group of individuals who have diabetes or risk factors for diabetes. The method may employ factors such as electronic medical records, type 2 diabetes diagnostic codes, family history, weight, BMI, history of metabolic diseases, blood test results, A1c, fasting glucose levels, oral glucose tolerance, prescribed diabetes medications, or any combination thereof.

[0356] In 1304, a first monitoring scheme may be applied to obtain additional data for a determined group of individuals. For example, method 1301 may include providing a first kit to participants in a determined group. The kit may be structured and configured so that participants in a determined group can perform low-fidelity monitoring of their health for a first period using the first monitoring technique and obtain first results. Information may be received from a device in the kit by system 127 or by another system or device.

[0357] In various examples, low-fidelity monitoring may include single-point glucose monitoring, heart rate monitoring, activity monitoring, blind continuous glucose monitoring, or any combination thereof.

[0358] In 1306, the system (e.g., system 127, or user device 132) can be screened for a second characteristic. For example, the system can run a second screening algorithm on a determined group to determine a cohort for participation in intermittent high-fidelity monitoring. The second screening algorithm can be based at least in part on results obtained using the first monitoring scheme. In some examples, intermittent high-fidelity monitoring may include continuous glucose monitoring. In some examples, screening can be based at least in part on factors of compliance with the use of the first scheme (e.g., low-fidelity monitoring techniques) (e.g., whether the user complied with the monitoring plan). For example, factors determining whether to utilize high-fidelity monitoring may be the extent to which the patient complied with the instructions or procedures of low-fidelity monitoring, such as wearing an activity monitor or taking blood glucose measurements according to a specified schedule.

[0359] In 1308, a second monitoring scheme may be applied. For example, method 1301 may include providing a second kit to participants in a determined cohort. The second kit may be structured and configured to enable participants in the determined cohort to perform high-fidelity monitoring of their health over a second period using a second monitoring technique and to obtain second results. In some examples, the second kit may include a continuous glucose monitor. The second kit may be structured and configured based on the first results obtained. For example, in an example where the second monitoring scheme is continuous glucose monitoring, the number or type (or both) of glucose sensors provided in the second kit may be determined based on the first results obtained. In some examples, the decision may include several first-type sensors using a first communication technology (e.g., NFC which must be swiped by a smart device to extract glucose data), or several second-type sensors designed to be used with long-range transmitters (e.g., Bluetooth) which can provide glucose information to wireless devices (e.g., smartphones) without human intervention, or a mixture of first-type and second-type sensors.

[0360] In paragraph 1310, the method may include providing guidance. For example, the method may include presenting guidance on the display of a user device, such as a handheld device (e.g., a smartphone). In some examples, the guidance may be provided using a chatbot function, as described herein. In some examples, the method may include performing communication between a server in a first kit and a device. Communication may be provided, for example, during a first monitoring. Communication may provide the patient or caregiver with guidance, such as coaching information on steps to take to lower glucose levels, such as exercise, or feedback on glucose control, such as estimated average glucose concentration or variability, or both, over a specified period of time. Guidance may include, for example, diabetes management guidance, including lifestyle changes related to diet or exercise, glucose level monitoring, or medication, or any combination thereof. In some examples, guidance may include indicators of a period or time schedule for adopting high-fidelity monitoring, such as one week, or ten days, or one week per month.

[0361] The method may further include, at the discretion of selection, providing a third kit to one or more participants of a determined cohort, the one or more participants being determined at least in part according to the second results obtained. The third kit may be structured and configured based on the second results obtained. For example, the third kit may include a number of continuous glucose monitoring sensors, the number and / or type of sensors (or both) being determined at least in part based on the second results obtained.

[0362] While the progression from low fidelity to high fidelity is described above, the method may alternatively include a progression from high fidelity to low fidelity. For example, the first monitoring scheme may include high-fidelity monitoring (e.g., using CGM), the screening of the second characteristic in 1306 may be based at least in part on information from high-fidelity monitoring, and the second monitoring may include low-fidelity monitoring such as activity monitoring.

[0363] Method 1300 can be implemented in a specialized system that may include hardware components, software components, or both, such as System 2200 shown in Figures 22A, 22B, 22C, and 23. For example, patient data may be retrieved from an electronic storage device and analyzed using a process to determine, for example, patients who may benefit from high-fidelity monitoring, and electronic instructions may be sent to a provisioning system to initiate the delivery of one or more detection kits to a specified patient or cohort of patients.

[0364] Figure 14 is a flowchart illustrating an exemplary method for managing patient health-related parameters using intermittent high-fidelity monitoring. In 1402, a patient is selected. Selecting a patient may include, for example, determining a patient from a pool of patients who are likely to benefit from intermittent high-fidelity monitoring, and this likelihood is greater than a calculated value. The patient pool may represent, for example, a group of patients in a clinical practice, or a designated insurance pool or program, or a geographical location, or workplace, or any combination thereof.

[0365] In 1404, a patient may be monitored over a first period (e.g., a set of periods) using a first monitoring technique, which may produce a first result (or set of results). The first technique may include, for example, high-fidelity monitoring (e.g., using a continuous glucose monitor) or low-fidelity monitoring (e.g., using a blood glucose meter).

[0366] In 1406, the patient may be monitored over a second period using a second monitoring technique, which may produce a second outcome (or set of outcomes). In various examples, the first period may be a subset of the second period or may overlap with the second period.

[0367] In some examples, the first technique may include high-fidelity monitoring, and the second technique may include low-fidelity monitoring, which can be determined at least partially by the results of the high-fidelity monitoring. In some examples, the first technique may be single-point glucose monitoring or blind continuous glucose monitoring (e.g., continuous glucose monitoring in which the patient does not receive some or all of the estimated glucose concentration levels). In some examples, the first technique may include activity monitoring using wearable fitness trackers such as heart rate monitors, activity monitors, smartphones, smart glasses, or smartwatches, or any combination thereof. In some examples, the second monitoring, a low-fidelity technique, may include receiving user input data such as medication data, diet data, exercise data, sleep data, or any combination thereof.

[0368] In other examples, the second technique may include low-fidelity monitoring, and the first technique may include high-fidelity monitoring, which can be determined at least partially by the results of high-fidelity monitoring.

[0369] In 1408, the actions a patient may take may be determined based on the first and second outcomes. The actions may be calculated to increase the likelihood of satisfying the control conditions. For example, an action may be calculated to increase a parameter related to the patient's health by a larger amount than a given amount, with a confidence level greater than a given confidence level. For example, an action may be calculated to increase the time the estimated glucose concentration level is within a specified range, such as by a certain amount (e.g., a percentage, fraction, or number of hours). In another example, an action may be calculated to change (e.g., increase or decrease) blood glucose variability by a specified amount.

[0370] In 1410, guidance may be provided. For example, guidance may be displayed on a screen. In various examples, the guidance may relate to diet, exercise, glucose level monitoring, or medication. In some examples, the guidance may indicate satisfactory patient performance in meeting conditions (e.g., goals) related to diet, exercise, glucose level monitoring, or medication, or other health-related matters. Delivering guidance may involve performing communication between a server and a device associated with the patient. In some examples, delivering guidance may involve delivering chatbot functionality to the device associated with the patient. Communication may occur during the first period, the second period, or both, or after the second period. In some examples, communication may provide the patient with coaching functionality.

[0371] In some examples, providing guidance may include indicating (or otherwise communicating via a device or system) the optimized period during which patients should adopt high-fidelity monitoring.

[0372] In some examples, the method may include correlating the obtained first and second results by determining the relationship between the obtained first and second results in, for example, time, day of the week, location, or other correlating factors. The method may further include calculating an estimated value for a high-fidelity monitoring technique at a given time based on the correlation value for a given time obtained by a low-fidelity monitoring technique. In some examples, the guidance delivered in 1410 may be based on an estimated value for a high-fidelity monitoring technique. In various examples, calculating an estimated value for a high-fidelity monitoring technique, or determining the correlation, may be at least in part based on population data corresponding to the patient, or physiological or other data about the patient collected using sensors, user input about the patient, or any combination thereof.

[0373] Figure 15 shows an example of a method 1501 that sets up a patient's user account on a server so that the patient can automatically log in using an app on a mobile device by entering only minimal information.

[0374] In step 1502, before providing the kit to the patient, a patient account is set up on behalf of the patient in a database maintained on the server. Among the items provisioned in the patient account, such as the patient name and date of birth (DOB), the patient account is also provisioned with a unique identifier for the mobile device included in the kit that is to be provided to the patient. For example, the identifier may be the mobile device's International Mobile Equipment Identity (IMEI). If the mobile device used is provided by the user and is not part of the kit, a different mobile device identifier may be assigned and used as the unique identifier.

[0375] In step 1504, the patient is provided with a kit including a mobile device. In step 1506, the user launches the app, which establishes communication with the server and automatically transmits a unique identifier for the mobile device. The app also transmits patient information that has been pre-provisioned in the patient record, and this information is used to associate the patient with the mobile device. This information may include one or more of the following, for example, the patient's email address, DOB, and phone number.

[0376] In step 1508, the server attempts to match the mobile device's unique identifier and patient information against the patient records stored in its database. If the match is successful, in step 1510, the server sends the necessary credentials to the app to log in, or otherwise accesses the matching patient record in the database. The app then logs in in step 1512 using the credentials to access the patient record.

[0377] The automated login procedure described above applies to new patients who need to create a user record. The procedure can also be used for existing patients. For example, if, in step 1504, a new kit is provided to an existing patient, and a new transmitter is provided instead, in step 1502, instead of creating a new patient account, the identifier of the new transmitter is entered into the patient's existing record. Thus, the process shown in Figure 15 allows both new and existing patients to automatically log in and access their patient account records with minimal effort.

[0378] It should be noted that the server functionality used in the automated login procedures discussed above may or may not be controlled by the same entity, and may be distributed across multiple servers. For example, in one particular case, one or more servers may be controlled and operated by the device manufacturer, and one or more additional servers may be controlled and operated by the database provider.

[0379] Figure 16 shows an exemplary user interface 1600, which may be presented on the display of a smart device, such as a handheld device 112, or on the display of a wearable device 120. User interface 1600 may include a trend graph 1602 that can display high-fidelity data (e.g., CGM data) plotted for a portion of the current day. The user interface screen shown in Figure 16 can be accessed by selecting a button on the user interface (labeled "glucose"). User interface 1600 may include a legend 1604 that provides descriptive information about the plot. A time selector user interface element 1610 may allow the user to control the period over which the data is displayed (e.g., today, yesterday, two days ago, or a full week). User interface 1600 may also provide a range time chart 1606, which may show a percentage (as shown) or duration (e.g., minutes or hours) within a range of several periods (e.g., the number of days in a week, as shown, or a portion of a day, such as morning, afternoon, evening, or night). Interface 1600 may include an input element 1608 that allows the user to select a percentage-based display, as shown in Figure 16, or a time-based display 1902, as shown in Figure 19. A time selector user interface element 1612 may receive user input for a range time chart and may allow the user to select, for example, a specific week to display data, or a period of different sizes (e.g., a portion of a day, or a range of several weeks or several months). In some examples, both trend graphs may be displayed simultaneously, or a scrollable portion 1614 (indicated by a dashed line) may be visible on the display screen, and the user interface may receive user input (e.g., via a touchscreen) and scroll or zoom to display the range time graph in addition to, or as an alternative to, the trend graph.

[0380] In an example of intermittent monitoring, a trend graph may be displayed during periods when high-fidelity collected data (e.g., CGM data) is available (e.g., several days), while a range-time chart may be provided during periods when low-fidelity collected data is available (with or without high-fidelity data) (e.g., several weeks).

[0381] Figure 17 shows an exemplary chat user interface 1700, which may be presented, for example, on the display of a handheld device 112 or on the display of a wearable device 120. The chat user interface 1700 may be accessed by selecting a chat user interface element 1702, which may initiate a chat session in a chat window 1704 with a human coach or a chatbot coach. The chat user interface 1700 may also include a context field 1706. The context field 1706 may include guidance messages that may be provided, for example, in response to high-fidelity or low-fidelity collected data. The chat interface may present information from the coach 1708 and comments or questions 1710 from the user. Input from the user may be received via a virtual keyboard (not shown) or using a microphone and speech recognition software. For example, if the user asks, "Why should I eat vegetables?", the coach (e.g., a chatbot) may respond, "Vegetables tend to help keep glucose within ranges because they contain fewer monocarbohydrates than foods like bread or sweets." In some examples, the chat session may be conducted using a microphone and speaker in addition to, or instead of, the on-screen chat shown in Figure 17.

[0382] Figure 18 shows a chat interface 1800 with a chart in context field 1802. The chart may be, for example, a range time chart such as the percentage-based chart shown in the context field of Figure 18, or a time-based chart in the context field shown in user interface 1900 shown in Figure 19, or the chart may be a trend, as shown in Figures 16 and 21. In another example, user interface 2000 may contain text messages in context field 2002. The user and coach may interact in chat fields 1804, 1904, and 2004, for example, to ask questions about the chart or to answer questions. On space-constrained devices, user input may be advantageously received via a microphone and speech recognition software to avoid conflicts of screen space requirements with chat field 1804, keyboard (not shown), and context field 1802. For example, the auditor's chat function (e.g., using a microphone and speaker) may be initiated by selecting the chat button 1620 in the interface shown in Figure 16. In some cases, a chat session may be triggered by detected data, patient information, or other chat trigger conditions. For example, a chat session may be triggered in response to a trend that satisfies a trend or range condition, which may, for example, allow the patient or user to take corrective action (e.g., participate in an activity such as exercise, change dietary choices, or take medication). For example, a chat session may be triggered by an estimated glucose concentration level that is likely to rise or fall rapidly, or become significantly larger outside the range, or is outside the range during a time or situation in which glucose is normally within the range, or is outside the range for a specified period of time (e.g., 12 hours, outside the range), or is outside the range by a specified percentage over a specified period of time (e.g., a specified number of days or weeks, greater than 60%).

[0383] In some examples, the user interfaces 1600, 1700, 1800, 1900, and 2000 shown in Figures 16-20 may be adapted based on information about the user. For example, the user interface may be adapted based on the user's preferences or characteristics regarding the sophistication or use of the interface. In some examples, the user interface may provide fewer choices, a larger display, or simpler information to accommodate users who show a tendency or preference for less sophisticated interactions. In some examples, the user interface may be adapted based on the user's age or time of birth (e.g., years). For example, users who meet certain age criteria (e.g., over 60, 65, or 70) may be shown a user interface with a specified appearance scheme (e.g., color scheme or high contrast) or larger buttons or larger fonts.

[0384] Figure 21 is a diagram of an exemplary user interface 2000. User interface 2000 may be in landscape mode view (for example, wider than it is long, which may be useful when a handheld smart device is held horizontally). User interface 2000 may be horizontally scrollable to display data for a period of time to the left (i.e., before) or right (i.e., after) the currently displayed data. For example, if the user touches the screen and swipes to the right, the data may "slide" to the right to show data for times before 9 p.m., and in response to a user swipe to the left, the data may slide to the left to show data for times after 4 p.m., for example. User interface 2100 may also include a user interface element 2102 (e.g., a "View Now" button), and in response to a user selection of user interface element 2102, the user interface may refresh or slide left or right as needed to display data for the current time. A sliding user interface can be useful for coaching, for example, a user may receive instructions from a coach to display data for a specific time or event (e.g., dinner), and then receive instructions to select user interface element 2102 to return to the current data.

[0385] Figure 22A is a diagram of an exemplary system in which various examples described herein may be used or applied. System 2200 may include a continuous glucose monitoring sensor 2202 and an activity sensor 2204 (e.g., a watch), which may be worn by a participant (e.g., a patient) 2201 to generate glucose concentration and activity information about the patient. The CGM sensor 2202 may provide activity information to a user computing device 2206 (e.g., a smartphone or a watch), and the activity sensor 2204 may provide activity information to the user computing device 2206, which may be a wearable device such as a handheld device (as shown) or a watch. Although the user computing device 2206 and the activity sensor 2204 are shown as separate devices, in some examples the activity sensor 2204 may be part of the user computing device 2206 (e.g., a smart device may be a wearable device such as a watch that includes an activity sensor).

[0386] One or more applications may run on the user computing device 2206 to provide patients with glucose concentration information, activity information, or guidance. For example, a first application 2208 running on the smart device may provide information about glucose concentration levels and optionally also provide guidance on managing glucose concentration levels, and a second application 2210 running on the smart device may provide information about activities and optionally also provide activity-related guidance (e.g., "Consider taking a brisk walk this afternoon"), or guidance related to managing glucose concentration levels (e.g., "You may need to take steps to lower your glucose levels today"), or guidance related to both (e.g., "To help lower your glucose levels today, consider taking a brisk walk this afternoon"). Although two separate applications are illustrated, in some examples the smart device may run a single application that combines the above functions (i.e., a single application may provide information about glucose concentration and activity therapy, as well as guidance related thereto).

[0387] The system may include one or more web service systems, which may include one or more servers configured to communicate over a network with, for example, a user computing device 2206, a CGM sensor 2202, an activity sensor 2204, or other devices, or with respect to them. For example, a first web service system 2212 may collect information related to continuous glucose management, a second web service system 2214 may collect activity information and optionally collect CGM information from the first web service system 2212. A third web service system 2216 may act as a coaching server to facilitate interaction with a human or computerized coach via coaching guidance through the user computing device 2206 or telephone follow-up communication. In some examples, the coaching server 2216 may be, or include, coaching servers 2412 or 2512, shown in Figures 24 and 25 and described below. Although the web service systems 2212, 2214 and the coaching server 2216 are presented as three separate systems, they could alternatively be part of a single system (e.g., a subsystem), or a single system could perform the tasks of two or more systems.

[0388] Figure 22B is a diagram of an exemplary system 2200A, which is the configuration of system 2200 in Figure 22A. In this example, a first data application 2208 is configured to establish a first communication link with a continuous glucose monitoring sensor 2202. In some examples, the first communication link is managed by a user computing device 2206, for example, by the operating system of the user computing device 2206. The first communication link may be a wireless communication link, such as Bluetooth, Bluetooth LE, or other preferred wireless communication link. The continuous glucose monitoring sensor 2202 can transmit CGM data, including glucose data describing the estimated glucose value of participant 2201, for example, to the first data application via the first communication link. In some examples, the CGM data provided by the continuous glucose monitoring sensor 2202 also includes metadata describing participant 2201 and / or diagnostic data describing the performance of the continuous glucose monitoring sensor 2202.

[0389] The second data application 2210 can be configured to establish a second communication link with the activity sensor 2204. The second communication link may be, for example, a wireless communication link similar to the first communication link. The activity sensor 2204 can provide the second data application with activity data describing the participant's activities via the second communication link. For example, the accelerometer or other suitable sensor of the activity sensor 2204 may capture data indicating the participant's motion or other activities and provide the corresponding data to the second data application 2210 via the second communication link. In some examples, the second data application 2210 may provide UI data to the activity sensor 2204 via the second communication link. For example, the activity sensor 2204 may include output devices such as a lamp, display screen, or speaker to transmit the UI data to the participant 2201. The UI data may describe, for example, the activities of the participant 2201 captured by the activity sensor 2204.

[0390] In some examples, the first data application 2208 is configured to communicate CGM data to the second data application 2210. The second data application 2210 can then provide the CGM data to the activity sensor 2204 as UI data provided to the participant via the output device of the activity sensor 2204. In this way, the activity sensor 2204 can provide the participant with indicators of glucose data, such as the participant's current estimated glucose value, and / or indicators of metadata, such as the direction in which the participant's glucose value is trending, and the participant's past glucose values.

[0391] However, communicating CGM data between the first data application 2208 and the second data application 2210 could introduce data security issues. For example, CGM data could be at risk of being maliciously intercepted by another application (not shown) running on the user computing device 2206.

[0392] To prevent CGM data from being intercepted, the first data application 2208 and the second data application 2210 can be configured to communicate over a secure communication protocol. An example of a secure communication protocol is described herein with respect to Figure 22C.

[0393] The exemplary system 2200A also illustrates links between data applications 2208 and 2210, their respective web service systems 2212 and 2214, and the coaching server 2216. For example, the first data application 2208 may provide CGM data to the web service system 2212. The web service system 2212 may provide CGM data to the coaching server 2216. The second data application 2210 may provide activity data describing the activities of participant 2201 to the web service system 2214. The web service system 2214 may provide activity data to the coaching server 2216. The coaching server 2216 may provide guidance to participant 2201. The guidance may be in any form described herein, including, for example, via a chatbot as illustrated in Figure 17, as shown in Figures 12A, 12B, and 12C. In various examples, the guidance is provided via the first data application 2208. For example, the first data application 2208 can provide a user interface for providing guidance, such as the user interfaces shown in Figures 12A, 12B, 12C, and 17.

[0394] Figure 22C is a flowchart showing an example of a process 2270 that runs on system 2200A in Figure 22A and can display CGM data on the activity sensor 2204. Process 2270 includes three columns 2271, 2273, and 2275. Column 2271 contains actions performed by the first data application 2208. Column 2273 contains actions performed by the second data application 2210. Column 2275 contains actions performed by the activity sensor 2204.

[0395] In step 2272, the first data application 2208 receives CGM data from the continuous glucose monitor sensor 2202. The CGM data may include glucose data such as estimated glucose values ​​and / or metadata, as described herein. In step 2274, the first data application 2208 generates a CGM message 2277. Generating the CGM message 2277 may include generating a data structure containing the CGM data. The first data application 2208 may encrypt the data structure using an encryption key. Any suitable encryption technique may be used.

[0396] In some examples, the first data application 2208 also adds an error detection code to the CGM data. The error detection code is data that can be used to verify the CGM data. The first data application 2208 generates an error detection code based on the CGM data contained in the CGM message 2277. The error detection code is a data value smaller than the CGM data that can be used by the second data application 2210, as described herein, to verify that the CGM data has been transmitted correctly. Some error detection code techniques allow the second data application 2210 to correct transmission errors in the CGM data. Any suitable error detection technique can be used. In some examples, cyclic redundancy check (CRC) technique is used. The error detection code may or may not be encrypted.

[0397] In step 2274, the first data application 2208 sends the CGM message 2277 to the second data application 2210. For example, the first data application 2208 may provide the CGM message 2277 to the operating system of the user computing device 2206. The operating system can then deliver the CGM message 2277 to the second data application 2210. In an example where the CGM data is encrypted, the CGM data may be unreadable by the operating system and / or by other applications that may intercept the CGM message 2277 between the first data application 2208 and the second data application 2210.

[0398] In step 2278, the second data application 2210 receives and processes the CGM message 2277. Processing the CGM message 2277 may include decrypting the CGM data contained in the CGM message 2277. Decryption can be performed using an encryption key. For example, the second data application 2210 may have access to the same encryption key used by the first data application 2208 to encrypt the CGM data. In another example, the first data application 2208 encrypts the CGM data using the second data application 2210's public (e.g., non-private) encryption key. The second data application 2210 can decrypt the CGM data using its private (e.g., secret) encryption key, which is not shared. Processing the CGM message 2277 may also include using an error detection code to verify the accuracy of the CGM data in the CGM message 2277 and / or correct any errors detected.

[0399] In step 2280, the second data application 2210 generates a device CGM message 2279. The device CGM message 2279 contains some or all of the CGM data for display by the activity sensor 2204. In some examples, generating the device CGM message 2279 also includes encrypting the CGM data and / or adding error correction codes. The second data application 2210 transmits the device CGM message 2279 to the activity sensor 2204, for example, using the wireless transmitter of the user computing device 2206. For example, the second data application 2210 can transmit the device CGM message 2279 directly to the operating system of the user computing device 2206. The operating system can instruct the wireless transmitter of the user computing device 2206 to transmit the device CGM message 2279 to the activity sensor 2204.

[0400] In step 2282, the activity sensor 2204 receives a device CGM message 2279. In some examples, the activity sensor 2204 performs decoding and / or error detection or correction on the CGM data contained in the device CGM message 2279. In step 2284, the activity sensor 2204 provides some or all of the CGM data at the output device of the activity sensor 2204, as described herein. For example, the activity sensor 2204 can incorporate some or all of the CGM data into a user interface provided to participant 2201.

[0401] Figure 23 is a more detailed diagram of the exemplary system shown in Figure 22A. In some examples, a first application 2208 may provide synchronized data (e.g., CGM data) 2218, which can be delivered to a sensor data subsystem 2220 (e.g., via a wireless or wired network) and transmitted to the data service portion 2222 of a first web service system 2212. The first web service system 2221 may also include a registration subsystem 2224 and a provisioning subsystem 2226, which may provide information to an eligibility subsystem 2228, which may determine the eligibility of an object (e.g., participant 2201) to receive a CGM sensor system and interact with a CGM execution subsystem 2230 (which may be operated by a third party, e.g., a medical supply service) to deliver the CGM sensor to the participant 2201. The data service portion 2222 of the first system 2212 may also receive other types of sensor data (e.g., low-fidelity data or blind CGM data) from the second sensor data subsystem 2232, which may provide information that can be used to determine the registration, provisioning, or configuration of a CGM sensor system.

[0402] The user computing device 2206 may provide activity data 2234 to an external system such as a second system 2214 (for example, via a second application 2210) or to a web application programming interface (API) 2258 that facilitates communication with a second subsystem 2214. The second system 2214 may receive participant information, CGM information, or other information from the first system 2212.

[0403] The second system 2214 may include an activity detection system 2236, which may receive and process activity data 2234 to identify problem conditions (e.g., insufficient activity), communicate with an intervention engine 2238, and the intervention engine 2238 may initiate a conversation server 2240 that can provide information to the coaching dashboard 2242. Coach 2241 may interact with the coaching dashboard 2242 to develop guidance for delivery to participant 2201, for example, via the guidance portion 2244 of a second app 2210 on user computing device 2206, or via the guidance portion 2246 of a first app 2208. In some examples, the functionality of coach 2241 is implemented using a coaching server such as coaching server 2216 and / or chatbot functionality, as described herein. For example, the process illustrated in Figures 26A-33 (described below) may be implemented on user computing device 2206.

[0404] The coaching server 2216 may receive identification of qualified coaches from a coach pool 2248 (e.g., managed by an insurance company or other entity). The coaching server may assign coaches to specific participants, maintain call records, generate weekly coaching reports, facilitate communication with user computing devices 2206, or facilitate follow-up via a call center 2250. The coaching server 2216 may also generate adverse event reports 2252, if any, for adjustment, process improvement, or other purposes.

[0405] The second system 2214 (or coaching server) may generate a push notification 2254 for delivery to the participant via a smart device (e.g., a second app 2210) or an activity sensor (e.g., a watch) 2204. The push notification 2254 may, for example, indicate that a new coach message is available. The second system 2214 may also generate a second push notification 2256, which may communicate CGM information, such as a message or guidance regarding glucose concentration level information, or information regarding the provision, delivery, application (e.g., to the participant's body), replacement, scheduling (e.g., when or for how long to wear) or use of a CGM sensor.

[0406] The second system 2214 may also include an authentication system 2262 which may, for example, provide authentication to the first app 2208, the second app 2210, or both, or provide information to the activity sensor authentication system 2260 for the use of API 2258 (for example, to "activate" the activity sensor on the sensor). The second system 2214 may also include a glucose level application program interface (API) 2266 which may receive glucose information (e.g., CGM information or sensor information or estimates thereof) from the first system 2212 and communicate the received information (e.g., 105 mg / dL) to the activity sensor 2204 for display to the participant.

[0407] The system may also include a group system 2264, which may include group information such as participant identification, which may be used in the web API 2258 or for sensor implementation to facilitate the distribution of activity sensors 2204 to participants 2201.

[0408] Any of the systems shown in Figures 22A and 23 can be implemented as a hardware system, software module, or application, or a combination thereof. The interaction of various systems and subsystems can improve the delivery of guidance and / or sensors to participants, improve patient management, and promote positive clinical outcomes.

[0409] Figure 24 illustrates an example of a continuous glucose monitoring (CGM) system 2400 in which a coaching staff member operates a coaching server 2412 to support and provide coaching services to patients using the CGM system 2400. Some references to the coaching server 2412 may refer to the personnel operating the coaching server 2412. The CGM system 2400 may include a continuous glucose monitor (CGM) 2402 for transmitting glucose monitoring data to a transceiver 2404. The transceiver 2404 may be a dedicated display device or a smartphone or other display device configured to transmit / receive data and communications within the CGM system 2400. The transceiver 2404 may transmit some or all of the patient's analytic data to a cloud computing architecture 2410 for future reference, further processing, record keeping, or other purposes related to managing or improving the patient's health.

[0410] The cloud computing architecture 2410 may include one or more health data servers configured to receive patient analytic data. The transceiver 2404 and / or the cloud computing architecture 2410 are capable of receiving patient analytic data and generating self-referencing data structures that can display or analyze more meaningful patient analytic data. For example, CGM 2402 readings can be used to generate a self-referencing data structure for displaying patient analytic data in a meaningful and easy-to-understand graphical display used by the patient and / or the coaching staff operating the coaching server 2412. The display self-referencing data structure may include a table encoded with flagged analytic sensor data, so that by using the self-referencing data structure, various analytic trend displays can be generated on demand and individually without querying multiple databases to collect the data necessary to generate the desired graphical display.

[0411] In some aspects of the systems, devices, and methods of this disclosure, health-related and non-health-related data are aggregated, structured, and / or transformed to intelligently generate outputs that include constructing, displaying, and controlling devices of the system and other systems, including new analytical data. Such health-related information may include glucose and related data (e.g., insulin, diet, activity, etc.), and non-health-related data may include location data, user demographic data, etc. Such implementations of the technology are recognized to improve the operation of the system by, for example, reducing the complexity of data processing and data transmission between devices, reducing the amount of data and processing algorithms to be stored and manipulated, and thereby accelerating the performance of the system as described herein. Furthermore, such implementations of the technology are envisioned to improve the user's ability to manage diabetes or other disorders through continuous analytic monitoring.

[0412] Some of the advantages of the described method and system include: Self-referencing data structures eliminate the need for the processor to retrieve and call necessary information from various parts of the system to generate a graphic display. Otherwise, for example, without a self-referencing data structure, the processor would need to retrieve, query, and / or call various parts of the system each time the user requests a different graphic or requests a change in the displayed graphic. Thus, self-referencing data structures improve the operation of the system by reducing the complexity of data processing and data transmission between different parts of the system. For example, using a self-referencing data structure, the system does not need to store or process additional algorithms, such as pattern recognition algorithms, to generate output such as a display for conveying pattern information to the user. Furthermore, self-referencing data structures can reduce the amount and frequency of data transmitted for the purpose of generating a graphic display. Accordingly, the associated processing or graphing algorithms that are stored and manipulated are also reduced, improving the performance of the system.

[0413] The transceiver 2404 can run the analyte sensor application 2405. The analyte sensor application 2405 can not only facilitate the connection between the coaching staff 2412 using the CGM system 2400 and the patient, but can also provide other services related to the CGM system 2400, such as providing alarms, displays, monitoring, memory, and other functions. Once appropriate legal and privacy permissions are obtained, the coaching staff 2412 can access patient data on the transceiver 2404 or the cloud computing architecture 2410 to better support the patient in managing their diabetes. The analyte sensor application 2405 may include a coaching module 2414, which can handle tasks associated with providing automated or semi-automated coaching to the patient.

[0414] Figure 25 illustrates an exemplary coaching system 2500, which can be used to implement automated and semi-automated coaching services for users of the CGM system 2400. The coaching system 2500 may include a coaching module 2502. The coaching module 2502 may include subroutines, programs, and algorithms that provide coaching support to the patient in one or more areas affecting the patient's health. For example, the coaching module 2502 may include an initializer module 2504 designed to introduce the patient to available sub-coaching modules and to involve the patient in one or more of those modules; an exercise module 2506 designed to encourage and guide the patient in engaging in mobility and physical activity; a diet module 2508 designed to help the patient better understand the relationship between food choices and blood glucose levels; and a sleep module 2510 designed to encourage and guide the patient in getting quality sleep while monitoring and managing glucose levels to avoid diabetic complications. The sub-coaching modules described are intended as examples and are not intended to be limiting. Those skilled in the art can envision other submodules of the coaching module 2502 that can provide support, education, monitoring, and coaching for different skills or activities beneficial to the management and improvement of diabetes. The coaching module 2502 can communicate with the coaching server 2512 to provide coaching services to patients of the CGM system 2400. The coaching server 2512 may be operated in part or in whole by trained human personnel who mentor diabetic patients.

[0415] Coaching Module 2502 and its submodules provide coaching by proposing activities, creating commitments to perform activities (e.g., by scheduling the time and / or place to perform the activity), setting goals (e.g., by requiring the patient to commit to performing the activity a desired number of repetitions, or by refraining from the activity for several days), monitoring outcomes (e.g., by examining one or more relevant glucose trend graphs), deriving alternative approaches to activities in case of suboptimal outcomes (e.g., taking walks closer to meal times if PPW glucose levels do not improve despite walks), and repetition. Coaching Module 2502 provides alarms, scheduling, reminders, and follow-up services to continuously encourage and monitor patient progress, interest, and engagement. Coaching Module 2502 can provide congratulations in case of good outcomes, encouragement and / or motivational messages when outcomes are mediocre, and alert the coach when outcomes are alarming or below average.

[0416] Initializer module When a patient is newly set up with the CGM system 2400, there is also an opportunity to set up the patient with automated coaching and provide preliminary general or specific education on diabetes and techniques and approaches to living with diabetes. Figure 26A illustrates an exemplary process 2600A performed by the initializer module 2504. Process 2600A can be initiated from step 2602A through patient behavior (e.g., by inputting a desire to run or enroll in a coaching program via the touchscreen or other input device connected to the analyte sensor application 2405). Process 2600A can be initiated automatically when the analyte sensor application 2405 detects a new patient. In step 2604A, the process determines whether the new patient has set up a new CGM device. If the answer is no, process 2600B in Figure 26B is performed. If the answer is yes, process 2600A proceeds to step 2606A by displaying a message containing general educational information about blood glucose levels, their meaning, their behavior, and the objectives of the coaching program. Coaching Module 2502 and its submodules can eliminate potential confusion, generate greater interest in the coaching program, and create a friendly and relaxed attitude and relationship between the patient and the coaching program by using colloquial and / or simple conversational language. For example, the information displayed in Step 2606A may include the following: "Your blood glucose levels do not stay constant, they fluctuate. Sometimes they rise, sometimes they rise much higher, and sometimes they fall."

[0417] The process then moves to step 2608A by generating a graphical representation of the patient's analyte data (e.g., a glucose trend graph relating to the patient's glucose levels over the past few hours). In addition to the graphical representation of the patient's analyte data, the process may also display educational graphics that indicate what could be considered “surges” or fluctuations in the analyte data. Educational graphics may include animations, text, or other visual indicators to inform the patient and display the patient’s glucose trend graph, or, if unavailable, a general glucose trend graph for the sample. If available, the initializer module 2504 may query and retrieve a self-referencing dataset related to the patient’s recent past, generate an analyte trend graph from the self-referencing dataset, and display that graph to the patient. The self-referencing dataset can be retrieved from the transceiver 2404 or from storage on the cloud computing architecture 2410.

[0418] In step 2610A, the process may encourage the patient to examine their analyte trend graph and determine if they can observe any spikes or fluctuations in their analyte data. If the answer is no, the process proceeds to step 2612A by congratulating the patient and displaying a message or graphics encouraging them to continue monitoring their blood glucose levels and taking healthy actions. The process then proceeds to process 2600B in Figure 26B. If in step 2610A the patient indicates that they can observe any spikes or undesirable fluctuations in their analyte data, process 2600A proceeds to step 2614A by asking the patient if they can recall any events or circumstances that occurred before the spikes or undesirable fluctuations occurred. Thus, the patient is encouraged to reflect on their choices, circumstances, or environment and to deepen their awareness of what might be affecting their health. If the patient recalls that event E occurred before the spikes, the process proceeds to step 2616A, where a message is displayed highlighting the relationship between event E and the patient's blood glucose levels and encouraging the patient to pay attention to this relationship the next time event E occurs. Next, the process moves to process 2600B in Figure 26B. If the patient cannot recall what happened before the spike observed in the analyte data, process 2600A moves to step 2618A. A message is displayed encouraging the patient to utilize the tools and submodules provided by coaching module 2502 to learn how various activities, situations, and life events affect blood glucose levels. Next, the process moves to process 2600B in Figure 26B.

[0419] Consider an example where a patient experiences a high glucose event in the early morning. The coaching module can access data (for example, in the cloud computing architecture 2410, indicating that the patient was prescribed medication to be taken in the early morning). Process 2600A can proceed to step 2610A as described above, where the early morning spike is detected. In step 2614A, the coaching module 2502 can ask the patient whether they are still taking the medication prescribed for the specified time in the morning. If the patient is taking the medication, the coaching module 2502 can be configured to display an encouraging message (for example, in step 2618A) or to further ask the patient about other events that may have caused the spike. If the patient is not taking the medication, the coaching module 2502 can be configured to display a message in step 2616A encouraging the patient to resume taking the medication.

[0420] Figure 26B illustrates an exemplary process 2600B performed by the initializer module 504. The process begins in step 2602B and proceeds to step 2604B by displaying educational information regarding a safe range of blood glucose levels. The patient may be provided with information on multiple safe blood glucose levels depending on the circumstances the patient may encounter. For example, the displayed educational information may state, "A safe blood glucose range varies depending on the individual's circumstances, but roughly speaking, blood glucose should be between 70 and 180 after a meal, and below 130 a few hours after a meal. Before bedtime, it should be between 100 and 140." The displayed educational information on safe ranges may also warn the patient to use a custom range if prescribed by the patient's physician. The displayed educational information may further include an introduction to tools available in the coaching module 2502 to help the patient maintain blood glucose levels within a safe range.

[0421] Patients are further encouraged to check their blood glucose levels frequently, and more frequently after activities that affect blood glucose levels. For example, patients are instructed to check their glucose readings before and after meals, during physical activity, during stress, or before going to bed. Another recommended time to check glucose levels is when calibrating the CGM2402. As patients become more accustomed to checking their blood glucose levels more frequently, they are more likely to observe and learn the effects of various choices and activities on their blood glucose levels, and have more opportunities to do so. The process moves to step 2606B by asking the patient to guess what their current blood glucose level is. Coaching module 2502 and its submodules can encourage further patient engagement using fun and engaging questions. Patients can input their estimated current blood glucose level via interesting and engaging graphic displays, such as sliders, scroll bars, text and arrows, or other images designed to work with touchscreen or voice recognition technology. The process then moves to step 2608B, by presenting the patient with a recent glucose trend graph that can include an indicator of the actual current glucose level. The patient is encouraged to examine the trend graph to observe their current blood glucose level and recent blood glucose level.

[0422] Next, the process moves to step 2610B, where the patient is encouraged to examine a glucose graph to see if any spikes or fluctuations in glucose data can be observed. Then, the process moves to step 2612B by asking the patient which activities affect their blood glucose levels. The patient may be presented with multiple options, such as "diet, exercise, sleep, or all of the above." In this example, the correct response is "all of the above," as all of the answers provided are true. If the patient responds with an answer other than "all of the above," the process moves to step 2614B, where an encouraging message is displayed indicating that all selections affect blood glucose levels and that the coaching module can guide the patient step-by-step through each activity. The process then moves to step 2618B. If the patient responds by indicating that all of the listed activities affect blood glucose, the process moves to step 2616B by displaying congratulatory and encouraging messages to the patient to select the correct answer. The displayed message may indicate that the coaching module can guide the patient by learning and understanding each factor listed and its effect on the patient's blood glucose levels. The process then moves to step 2618B, where the patient is asked which activity or skill they would like to learn about first. If the patient makes no selection or indicates a lack of interest or motivation, the process moves to step 2620B, where a coaching warning ticket is generated and transmitted to the coach via the coaching server 2512. The process then terminates in step 2626B. If the patient shows interest by selecting one of the presented activities or skills, the process moves to step 2622B by displaying a message congratulating the patient on their enthusiasm. The process then moves to the submodule selected by the patient. For example, if exercise, diet, or sleep is selected, the exercise module 2506, diet module 2508, or sleep module 2510 are respectively called and executed by the coaching module 2502.The process then moves to step 2624B, in which the coaching server 2512 is updated to reflect the activity module selected by the patient. In some embodiments, the coach operating the coaching server 2512 can manually assign sub-coaching modules and update the coaching server 2512 accordingly. The process then terminates in step 2626B.

[0423] Generally, the coaching module 2502 can be configured to generate coaching alert tickets and notify the coach when a patient's responses and interactions with the patient indicate a lack of interest, motivation, or commitment. Living with diabetes can be challenging. Responses indicating a lack of interest and commitment may be an indicator of depression or a sign that the patient may need psychological or emotional support to cope with the challenges of living with diabetes. As part of generating coaching alert tickets, the coaching module 2502 or its submodules can gather relevant contextual information to help the coach respond to the patient efficiently and quickly. For example, in response to an activity in which the patient shows a lack of enthusiasm, the coaching module 2502 may pose questions to the patient and elicit answers relevant to providing coaching and counseling regarding that activity.

[0424] The coaching module allows for further annotation, labeling, and categorization of patient context information, enabling coaches to deliver counseling and coaching services more efficiently and effectively. For example, if a patient initiates and anticipates healthy activities but fails to achieve their anticipated goals, the context information used to create a coaching alert ticket may include a label stating "Committed but unable to achieve." Conversely, if a patient refuses to schedule activities and their response indicates a lack of confidence in the proposed activities, the context information may include a label stating "Patient does not believe in the proposed activities." Coaches operating the coaching server 2512 can consult context information labels for efficient and timely review of the patient's medical history and current problems. In some embodiments, coaches operating the coaching server 2512 may specialize in specific areas where they provide coaching and support to patients. For example, some coaches may specialize in providing counseling and coaching to patients who lack discipline in monitoring their diet and may have special training in this area. Using context information labels, coaching alert tickets can be forwarded to coaches who specialize in addressing the underlying issues.

[0425] The overall theme of communicating the interaction between the coaching module 2502 and the patient is to facilitate engagement with the CGM system 2400 and the coaching module 2502, for example, by using the provided tools and observing the analysis and recommendations of tools related to the patient's blood glucose levels. Such engagement can enhance the patient's understanding of the disease and improve their intuitive response to their condition.

[0426] Exercise module The coaching module 2502 may include an exercise module 2506 for encouraging and guiding patients to engage in physical activity and observing the benefits and correlations between physical activity and improved glucose levels. Figure 27 illustrates a process 2700 in which a patient can be involved using an automated or semi-automated coaching system submodule focused on exercise and physical activity. Beneficial mobility and physical activity for diabetic patients is as easy as taking a walk after a meal. Since Post Prandial Walk (PPW) can be an area of ​​focus for coaching, processes 2700 in Figure 27, 2800 in Figure 28, and 2900 in Figure 29 are described in relation to PPW. Those skilled in the art can envision other types of physical activity or mobility that can be carried out using processes 2700, 2800, and 2900 without departing from the spirit of the described art.

[0427] Process 2700 begins at step 2702. The exercise module 2506 can educate the patient about the beneficial effects of physical movement on blood glucose levels and recommend exercise as a way to maintain blood glucose levels within a safe range. The process moves to step 2704, where the patient is asked about their previous experience with recommended physical activities such as PPW. If the patient indicates that they have never tried PPW, the process moves to step 2706, where the patient is asked if they would like to choose a diet to practice PPW in the future. If the patient indicates a lack of interest, the process moves to step 2708, where additional contextual information is obtained from the patient or from the patient's records in the cloud computing architecture 2410 and / or transceiver 2404. In step 2710, a coaching alert ticket is generated and transmitted to the coaching server 2512 to notify the coach. The process ends at step 2712. The same process can be repeated, and whenever the patient's response indicates a lack of interest or motivation to manage or improve their health, a coaching alert ticket will be generated and transmitted.

[0428] If the patient expresses interest in trying PPW, the process moves to step 2714, where the patient is asked to select a meal plan for practicing PPW and a time when the exercise module 2506 can provide feedback to the patient on the results. Follow-up reminders are scheduled based on the patient's response. When it is time for follow-up, the process moves to step 2716, where the patient is asked whether they were able to practice PPW as planned and what the results were. If the patient's response indicates a failure or unexpected outcome after practicing PPW, the process may proceed to steps 2708 and 2710 to gather information and create and transmit a coaching warning ticket. The process ends in step 2712. If the PPW results were successful, the process moves to step 2720, where the patient is asked if they would like to repeat the success achieved by scheduling more PPW sessions.

[0429] The success or failure of a PPW session can be determined by presenting the patient with a question and providing multiple-choice answers such as "What happened to my blood glucose?", "It rose more slowly," "It didn't rise as high as expected," "It didn't change," "It rose a little," or "It rose a lot." A group of possible patient responses can be classified as successes, and if those responses are detected, process 2700 can route based on the successful outcome. Similarly, some responses may be classified as failures, and if those responses are detected, process 2700 can route accordingly. In some embodiments, the success or failure of a PPW or other proposed activity can be determined by querying the patient's records in the cloud computing architecture 2410, the transceiver 2404, or both, to automatically determine whether the patient's glucose levels were in a safe range after the scheduled PPW session. Alternatively, to encourage the patient to learn to interpret their glucose trend graph or other available glucose data, the patient may be asked to determine the success or failure of a PPW session by manually examining their glucose data. Analyte data stored in the CGM system 2400 can be used as a secondary check, and if a discrepancy is detected, the patient may be prompted to re-evaluate their responses or stored data. Similarly, whether the patient was able to perform the PPW can be determined by presenting the patient with text or graphic questions, or, if the transceiver 2404 is optionally incorporated, by querying the transceiver 2404 for, for example, Global Positioning System (GPS) data.

[0430] If the patient does not show interest in scheduling more PPW sessions, the process may proceed to steps 2708 and 2710 to gather information and generate and transmit a coaching warning ticket. The process then terminates in step 2712. If the patient shows interest in repeating the success achieved by scheduling more PPW sessions, the process moves to step 2722 to schedule future PPW sessions based on the patient's preferred times and meals. The process then moves to step 2724, where the scheduled PPW sessions are used to carry out follow-up process 2800, as described in relation to Figure 28. The process then terminates in step 2726.

[0431] As explained, in step 2704 of process 2700, the patient is asked if they have tried PPW before. If the patient responds yes, the process moves to step 2718, asking the patient what the outcome of their previous PPW experience was. If the patient indicates failure or an unexpected outcome, the process may move to step 2728, asking the patient if there is anything they can do differently to make PPW more successful. The patient may respond by interacting with a menu or other visual interface, such as by free text, from a dropdown menu, or by selecting a radio button from a menu of autofilled responses (e.g., “Walk longer,” “Walk faster,” “Walk in time with meals”). The process may move to step 2730, asking the patient if they would like to try one or more of the alternative approaches the patient just indicated. If the patient responds with no interest, the process may proceed to steps 2708 and 2710 to gather information and generate and transmit a coaching alert ticket. The process then terminates in step 2712. If the patient responds positively, the process moves to step 2732, where future PPW sessions can be scheduled based on the patient's preferred times and meals. The scheduled PPW sessions are used to carry out follow-up process 2800, as described in relation to Figure 28. Process 2700 then concludes in step 2734.

[0432] Figure 28 illustrates process 2800 for introducing PPW or other recommended activities beneficial for diabetes management and performing follow-up on the patient's scheduled progress. Process 2800 begins with step 2802. After the pre-scheduled time for the PPW session has arrived, or after a predetermined time after the scheduled time, the process moves to step 2804, inquiring whether the patient is able to perform the PPW as scheduled. If the patient responds negatively, the process may proceed with steps 2806 and 2808 to gather contextual information and create and transmit a coaching alert ticket. The process then concludes in step 2810.

[0433] If the patient indicates that they can practice PPW as scheduled, the process moves to step 2812, where the patient is asked whether their blood glucose levels were within a safe or desirable range after the PPW session. If the answer is no, the process performs steps 2806 and 2808 to collect information and create and transmit a coaching warning ticket. The process then terminates in step 2810. If the answer is yes, the process moves to step 2814, where the patient is asked how many days they predict they will be able to practice PPW. If the patient's response is less than a minimum threshold (e.g., 0 or 1 day), the process may perform steps 2806 and 2808 to collect information and create and transmit a coaching warning ticket. The process then terminates in step 2810. If the answer is greater than or equal to the minimum threshold (e.g., 2 days), the process may move to step 2816, where the predicted number of days of PPW activity is stored and transmitted to the confidence assessor / booster process 2900, as described in relation to Figure 29. The process then terminates in step 2810.

[0434] As previously shown, consider an example where the patient has an acceptable A1C level and is stored in the cloud computing architecture 2410. In this example, the patient also indicated in advance, in step 2806 of a previous run of process 2800, that an injury was preventing the patient from performing the desired exercise. This data is also stored in the cloud computing architecture and can be used in subsequent runs of process 2800. For example, in step 2804, the patient may be asked whether the patient's injury has healed, in addition to whether the patient was able to perform the PPW.

[0435] Figure 29 illustrates an exemplary process 2900 that can be performed by exercise module 2506 to further follow up, assess, or enhance a patient's confidence in practicing PPW or other suggested activities beneficial for diabetes. The process begins in step 2902. Exercise module 2506 can track the number of days the patient practices PPW. The process moves to step 2904, where it determines whether the number of days the patient has practiced PPW is equal to or greater than the number of days the patient predicted they would practice PPW. If the answer is yes, the process moves to step 2906, where the patient is asked, on a given scale (e.g., a scale from 0 to 10), how confident they are that they will be able to practice PPW over the next 7 days. If the patient's confidence level exceeds a given minimum confidence number (e.g., 7), the process moves to step 2908, where it displays a message celebrating the patient's determination and commitment. The process can then return to step 2902 and repeat process 2900 after one week or another predetermined period. If the patient's confidence level in their ability to practice PPW is lower than a predetermined confidence number (e.g., less than 7), the process moves to step 2910, where the patient may be asked if there is anything they can do to raise their confidence level that they are capable of achieving a scheduled number of PPW practices. If the answer is no, the process proceeds to steps 2918 and 2920 to gather information and create and transmit a coaching alert ticket. The process ends at step 2922. If the answer is yes, the process moves to step 2912, where the patient is asked to enter a plan for successfully performing a scheduled number of PPWs. The process may then move to step 2914, where the patient is asked if they believe they can stick to the plan. If the answer is yes, the process moves to step 2916, where the patient's PPWs are tracked daily or taken after a predetermined time (e.g., one week), and then the process moves to step 2902, and process 2900 is repeated.If the answer is no, the process can proceed by performing steps 2918 and 2920 to collect information and create and transmit a coaching alert ticket. The process then terminates in step 2922.

[0436] If, in step 2904, it is determined that the number of days the patient has performed PPW is less than the scheduled number, the process proceeds to step 2924. If the number of days the patient has performed PPW is less than or equal to a predetermined minimum (e.g., 2 days or less), the process performs steps 2918 and 2920 to collect information and create and transmit a coaching warning ticket. The process then terminates in step 2922. If the number of days the patient has performed PPW exceeds a predetermined minimum (e.g., more than 2 days), the process proceeds to step 2926 to ask the patient whether they believe they can achieve the scheduled number of PPW days. If the answer is yes, the process proceeds to step 2916, where the patient's PPW is tracked daily or taken after a predetermined time (e.g., 1 week), and the process then proceeds to step 2902, and process 2900 is repeated. If the answer is no, the process performs steps 2918 and 2920 to collect information and create and transmit a coaching warning ticket. The process then terminates in step 2922.

[0437] The coaching module 2502 may include a diet module 2508 to encourage and guide patients to understand and learn about the impact of their dietary choices on blood glucose levels and diabetes. Figure 30 illustrates a process 3000 that can involve a patient using an automated or semi-automated coaching system submodule focused on diet. Process 3000 begins at step 3002. In step 3004, the patient is asked if they would like to learn how different foods and dietary choices affect their blood glucose levels. If the answer is no, the process performs steps 3006 and 3008 to collect information and create and transmit a coaching alert ticket. The process then ends at step 3010. If the answer is yes, a message is displayed to the patient encouraging their interest and engagement. The message may further raise the patient's awareness of the relationship and correlation between diet and blood glucose levels. The message can encourage patients to continue reviewing their blood glucose readings and to learn how different dietary choices affect their glucose readings.

[0438] The process moves to step 3012, where the patient is asked to select a mealtime M and begin learning about the effect of meals on blood glucose levels. The mealtime M selected by the patient can be remembered, and a reminder can be scheduled for the patient to follow up. The process moves to step 3014, where the patient is asked if they know what they will eat for the selected meal. If the answer is no, the process moves to step 3016, where an encouraging message is displayed, informing the patient that they can track what they ate and observe its effect on blood glucose levels using the tools provided by the CGM2400 system. Immediately after the scheduled mealtime M or after a predetermined time, the process moves to step 3018, where the patient is asked how consuming the meal affected their blood glucose levels. The patient can type a text or select an answer from several possible scenarios, such as "It went up and stayed there," "It went up but then quickly went down," "It didn't change much," or "It went down." The patient's response can be stored in variable S. The process then moves to step 3020, where the patient is asked what they ate at their scheduled meal M. The patient can describe the meal they had by typing free text or selecting from a menu of available options, and the patient's answer can be stored in variable F.

[0439] The process then moves to step 3022, where a message is displayed, via a text block or other graphic or visual representation, linking the patient's diet M and the patient's blood glucose level S. The message can be a sentence populated with the values ​​stored in the variables M, F, and S. For example, the message could be: "Meal <m>in <f>eat, and blood glucose level<S". If F=chocolate cake, M=breakfast, and S=risen and stayed there, the displayed message reads "I ate chocolate cake for the breakfast meal, and my blood glucose level rose and stayed there". Various messaging formats and scenarios can be used to enhance understanding and learning about the effects of food and meals on a patient's blood glucose levels.

[0440] The process then moves to step 3024 to ask whether the patient is surprised by the result. If the answer is no, the process can move to step 3026, where the patient is congratulated for tracking the post-meal glucose level and encouraged to keep checking the post-meal glucose level. The process then moves to step 3028, where the patient is encouraged to track more meals and their effects on glucose levels using a meal tracking tool. The meal tracking tool is described in connection with process 3100 of Figure 31. The process then ends at step 3030. If the patient is surprised by the result of the glucose reading and the patient's answer at step 3024 is yes, the patient may require additional or individualized coaching regarding food and meal types and their effects on diabetes. The process can perform steps 3006 and 3008 to collect information and create and transmit a coaching alert ticket. The process then ends at step 3010.

[0441] In step 3014, if the patient knows what they will consume for the scheduled mealtime M, the process moves to step 3032 to store the patient's planned meal in variable F. The process moves to step 3034, where the patient is asked how consuming food F at meal M affected the patient's blood glucose level. The patient's response can be stored in variable S. The process moves to step 3036 to display a message constructed from variables M, F, and S. For example, the message can be "Meal <m>in <f>Eat, blood sugar level <s>It can be constructed from the sentence, where F = grilled fish, whole wheat toast, garden salad, M = lunch, and S = decreased. The displayed message may say, "I ate grilled fish, whole wheat toast, and garden salad for lunch, and my blood sugar decreased." Next, the process moves to step 3024, where the patient is encouraged to use the meal tracking tool in Figure 31 to gain a better understanding of the correlation between meals and blood glucose.

[0442] Figure 31 illustrates an exemplary process 3100 that can be performed by the meal module 2508 to implement a meal tracking tool to encourage and instruct patients to understand the relationship between meals and blood glucose levels. Process 3100 begins in step 3102 via input from a user who is interested in starting to operate the tool, or by a complementary process or tool such as process 3000. Process 3100 moves to step 3104, which asks the patient to schedule a meal M for tracking. The patient's selection is stored, and a reminder is scheduled for a predetermined period T after the scheduled meal M. T may be, for example, 1 to 2 hours. The process moves to step 3106, which waits for a predetermined time T after meal M. The process moves to step 3108, which asks the patient what they ate in the scheduled meal M, and stores the patient's response in variable F. The process then moves to step 3110, where the patient's glucose data is taken for the period before and after meal M plus a predetermined time T. Glucose data for a relevant period can be obtained from the patient, who then examines a glucose trend graph obtained from the relevant time or from another part of the CGM system 2400, such as the transceiver 2404 or the cloud computing architecture 2410. Once the glucose data is presented to the patient, the process moves to step 3112, where the patient is asked if they have observed any spikes or undesirable fluctuations in the glucose data. In other embodiments, the meal module can automatically examine and scan the glucose data for fluctuations by comparing stored glucose values ​​to high or low thresholds. If there are no spikes or undesirable fluctuations in the glucose data, the process moves to step 3114, where the patient is shown a message encouraging them to continue checking their blood glucose levels and learn how to eat safely. For example, the message might read, "OK, every time you check your glucose after a meal, you will learn more about how to eat safely and enjoy your food."

[0443] If the patient observes a spike or fluctuation in blood glucose levels and the patient's response in step 3112 is yes, the process moves to step 3118, where the patient is asked if they could eat a different food that might have a better effect on their blood glucose levels. If the patient shows a lack of interest or knowledge about what they can do differently, the process may proceed to steps 3120 and 3122 to gather information and create and transmit a coaching alert ticket. The process then terminates in step 3124. If the patient responds by showing an ability to make better dietary choices, the process moves to step 3126, where the patient is asked further questions to help determine the patient's determination and interest. For example, in step 3126, the patient may be asked to input into the system what they can do differently next time (e.g., what their future dietary choices will be). The process moves to step 3128, where it is determined whether the patient's planned choices are similar to or different from the patient's previous choices that led to undesirable fluctuations in blood glucose levels. If the patient's planned choices are the same as or similar to the patient's previous choices, the process can proceed to steps 3120 and 3122 to collect information and create and transmit a coaching alert ticket. The process then terminates at step 3124. If the patient's choices differ from the patient's previous choices, which indicated a plan aimed at maintaining safe blood glucose levels, the process can proceed to step 3104 to schedule a follow-up diet tracking session, and process 3100 is repeated.

[0444] Figure 32 illustrates an exemplary process 3200 that can be implemented in the meal module 2508 to encourage and instruct patients to increase their efforts to monitor postprandial blood glucose by using the meal tracking tool described in relation to Figure 31. Process 3200 can be run automatically at predetermined time intervals (e.g., weekly) or manually by the patient, starting from step 3202. The meal tracking tool implemented via process 3100 can be configured to track and remember the number of times the tool has been used and / or the number of meals tracked by the patient, in variable MT (tracked meals). By default, the system can specify a desired number of meals to be tracked in variable D, or it can query the patient, the patient's guardian, or a healthcare professional and / or coaching factor for the number of meals the patient is expected to track and remember in variable D. In step 3204, the patient's tracked meals MT is compared to the desired or expected number of meals D to be tracked. If the tracked meal MT is greater than or equal to the expected tracked meal D, the process moves to step 3206 to display a congratulatory message, and the process ends in step 3208. If, in step 3210, the tracked meal MT is less than the expected number D but greater than half of the expected number D, the process moves to step 3212, where the meal module 2508 can be configured to send reminders, suggestions, and encouragements to the patient to track meals and check glucose data. The process then ends in step 3214. If the tracked meal MT is less than half of the desired number D, the patient may require more personalized coaching to increase their effort in tracking meals and checking glucose data. The process can then perform steps 3216 and 3218 to collect information and create and transmit coaching alert tickets. The process then ends in step 3220.

[0445] Sleep Module Figure 33 illustrates an exemplary process 3300 that can be implemented by the sleep module 2510 to monitor nocturnal glucose behavior and encourage and guide patients to better understand the beneficial effects of adequate sleep on blood glucose levels. Process 3300 begins in step 3302. In step 3304, the process displays general and / or patient-specific data regarding the relationship between sleep and blood glucose. For example, such a display might say, "Sleeping well makes you safer / healthier. Keeping glucose within a range (e.g., 100-140 mg / dL) during sleep helps you sleep better and improve how you manage diabetes." The process then moves to step 3306. A glucose trend graph is generated from a self-referencing data structure stored in the CGM system 2400 and presented to the patient. The patient is asked to examine the glucose trend graph for the past seven nights to determine how many nights the patient's glucose levels were within a safe range during the first few hours of sleep. In some embodiments, the sleep module 2510 may automatically determine whether the patient's glucose levels were safe during the relevant period. In some cases, machine learning techniques such as those described herein can be used to generate a model of the relationship between a patient's sleep and blood glucose.

[0446] In situations where automated coaching is provided, encouraging patients to examine glucose trend graphs and learn how to read and correctly interpret glucose data and graphs may be preferable to simply determining unsafe glucose fluctuations. Other safety and monitoring tools and modules within the CGM2400 can perform these tasks more effectively. Therefore, in situations where automated coaching is provided, the CGM system's ability to automatically analyze patient glucose data and reconfirm patient analysis and judgment can be secondarily utilized. The analysis and interpretation of patient glucose data can be compared with the automated analysis of the CGM system 2400, and if a discrepancy is detected, the patient, coach, or other relevant parties can be notified.

[0447] If, in step 3308, the patient's glucose levels are within a safe range for a certain number of nights, the process moves to step 3310, where a message is displayed congratulating the patient on the approach and encouraging them to continue monitoring their nighttime or sleep-time glucose levels and trends. The process concludes in step 3312.

[0448] In step 3314, it is determined whether the patient's nightly glucose levels have been safe for at least five or six nights. If the answer is no, the process moves to step 3316 to determine whether the patient's nightly glucose levels have been safe for at least three or four nights. If the answer is no, the patient may require more personalized or immediate coaching assistance to better manage their blood glucose levels during sleep. The process then performs steps 3318 and 3320 to collect information and create and transmit a coaching alert ticket. The process then terminates in step 3322.

[0449] In step 3314, if it is determined that the patient's nighttime glucose levels have been within a safe range for at least five or six nights, the process proceeds to step 3324, where the patient is asked if there was anything different they did during the nights their blood glucose levels remained within a safe range. If the patient cannot recall or does not know, the process proceeds to step 3326, where a message is displayed encouraging the patient to track their nighttime glucose levels for the next seven days (or any other period that may be desirable based on the patient's age, medical history, or other factors). The process proceeds to step 3328, where the patient is asked how many nights they believe their glucose levels will remain within a safe range. The patient's response is stored in the variable NP (predicted nights). In step 3330, if the predicted nights are five or more, the process proceeds to step 3332. A message is displayed celebrating the patient's engagement and commitment to their health.

[0450] After a one-week delay, the process moves to step 3334, where the patient is asked to check their blood glucose levels for the past seven nights. If the patient's nighttime glucose levels remain within a safe range above the predicted nighttime NP, the process moves to step 3336, where a congratulatory message is displayed and the patient is encouraged to continue tracking their nighttime glucose levels, and the process ends at step 3338. If the number of nights in which the patient's nightly glucose levels remain within a safe range is less than the predicted nighttime NP, the process moves to step 3340, where an encouraging message is displayed acknowledging any challenges the patient may have faced and encouraging the patient to discuss those challenges with their coach. The process then performs steps 3318 and 3320 to collect information and create and transmit a coaching alert ticket. The process then ends at step 3322.

[0451] In step 3330, if the patient predicts that their glucose levels will remain within a safe range for less than five nights, the process proceeds to step 3342, displaying a message encouraging the patient to discuss with their coach any challenges that may affect their ability to maintain safe nightly glucose levels. The process then performs steps 3318 and 3320 to gather information and create and transmit a coaching alert ticket. The process terminates in step 3322.

[0452] If, in step 3316, the patient's nightly glucose levels have been within a safe range for at least three to four nights, the process proceeds to step 3344. The patient is then more closely monitored by the sleep module 2510. For example, in step 3344, the patient may be asked each morning, or at some point before sleeptime, whether they predict their nightly glucose levels will be within a safe range for that night. The process is repeated over a week or other desired period, and the predicted nightly NPs are counted and remembered. The process then proceeds to step 3334.

[0453] In step 3324, if the patient knows what has changed to enable them to maintain safe nightly glucose levels, the process moves to step 3346, where the patient is asked what caused the difference between safe nights and other nights. The patient's response is recorded. In step 3348, a message is displayed congratulating the patient on their positive and proactive attitude. The process moves to step 3350, where the patient is asked if they are ready to achieve the same level of success to have safe nightly glucose levels again next week. If the patient responds yes, the process moves to step 3328. If the patient responds no, the patient may lack confidence in their ability to maintain safe nightly glucose levels. The patient may need more personalized coaching to increase their level of confidence. The process performs steps 3318 and 3320 to gather information and create and transmit a coaching alert ticket. The process ends in step 3322.

[0454] Information collected to provide automated or semi-automated coaching (e.g., information collected in processes 2600A, 2600B, 2700, 2800, 2900, 3000, 3100, 3200, and 3300) can be obtained from the patient as described above, or obtained or inferred from other data available in the CGM system 2400. For example, a patient's behavior during a pre-scheduled activity can be inferred from Global Positioning System (GPS) data from the transceiver 2404, or from patient glucose data stored in the transceiver 2404 or the cloud computing architecture 2410. The patient may be asked to confirm whether the automated determination of an event is correct. For example, the coaching module 2502 can automatically detect blood glucose levels within a range for a period following a PPW session. The coaching module 2502 can present the patient with a glucose trend graph for the relevant period and ask the patient to confirm that their glucose level was within a range during that period. If appropriate permission is obtained, the coaching module 2502 can determine if the patient went for a walk during the period in which PPW activity is scheduled by referring to GPS data stored in the transceiver 2404. The coaching module can then confirm this determination with the patient.

[0455] In some cases, analyte sensor systems can be configured to perform high-fidelity data acquisition, where the captured data is retrieved after collection. This can be useful for patients who do not have access to wireless networks and / or who do not regularly carry smart devices or other user computing devices. Post-collection data retrieval also minimizes or eliminates the need for users to set up smart devices to communicate with the analyte sensor system. This allows clinicians to provide patients with access to analyte sensors with less training cost.

[0456] Figure 34 shows an exemplary system 3400 which may include an analytic sensor system 3402 configured to upload analytic data captured after collection. The analytic sensor system 3402 may be coupled to host 3401, similar to host 101 in Figure 1. The analytic sensor system 3402 may be similar to analytic sensor 102 in Figure 1. For example, the analytic sensor system 3402 may include an analytic sensor 3404, such as a glucose sensor. Sensor electronics 3406 may be similar to sensor electronics 106 in Figure 1. Sensor electronics 3406 may include data storage hardware for storing analytic data captured by analytic sensor 3404. Sensor electronics 3406 may also be programmed to upload captured analytic data after collection, for example, as described herein with respect to Figures 35-37.

[0457] The exemplary system 3400 includes an optional smart device 3412 that can be used to communicate with the analyte sensor system 3402 via one or more wireless communication signals 3410, similar to the handheld device 112. The smart device 3412 can provide the host 3401, for example, with an index of the analyte data detected by the analyte sensor system 3402 when the data is collected. In some examples, the analyte sensor system 3402 operates in blind mode, and the smart device 3412 may be omitted.

[0458] The exemplary system 3400 also includes an upload device 3450. The upload device 3450 can be, or include, any preferred computing device configured to communicate with the analyte sensor system 3402 (e.g., its sensor electronics 3406) via wireless communication signals 3410. In some examples, the upload device 3450 is away from the host 3401 while the analyte data is being collected by the analyte sensor system 3402. In some examples, the analyte sensor system 3402 (or its sensor electronics 3406 only) is removed from the host 3401 after data collection and physically transported to the location of the upload device 3450. For example, the upload device 3450 may be located in a pharmacist's, clinician's office, or other preferred location. The upload device 3450 can be coupled to the sensor electronics 3406 to retrieve the collected analyte data. In some examples, the upload device 3450 provides the downloaded analyte data to one or more server systems 3425, 3426, 3427 via the network 3424. Server systems 3425, 3426, and 3427 may be similar to server systems 125, 126, and 127 described herein.

[0459] Figure 35 is a flowchart illustrating an example of a process 3500 that can be performed by the analyte sensor system 3402 (e.g., its sensor electronics 3406) to collect and upload analyte data. In step 3502, the sensor electronics 3402 detects that the analyte sensor system 3402 has been applied to the host 3401. Detection may occur, for example, when the analyte sensor 3404 begins to provide analyte data. In some examples, the sensor electronics 3402 detects that the analyte sensor system 3402 has been applied to the host 3401 when the analyte sensor 3404 provides sensor readings exceeding a threshold over two different time periods. Consider an example where the analyte sensor 3404 is a glucose sensor configured to capture an estimated glucose value of a patient every 30 seconds. The sensor electronics 3406 may detect the application of the analyte sensor system 3402 when the analyte sensor 3404 detects an estimated glucose value exceeding a threshold (e.g., 60 mg / dL) over two different 30-second time periods. In some examples, the sensor electronics 3406 detect the application of the analyte sensor system 3402 when the analyte sensor 3404 detects an estimated glucose value exceeding a threshold (e.g., 60 mg / dL) over two consecutive 30-second periods.

[0460] In some examples, the sensor electronics 3406 receives, for example, the serial number of another sensor identifier of the analyte sensor 3404 in order to properly calibrate the analyte data received from the analyte sensor 3404. The sensor electronics 3406 can receive the sensor identifier in any preferred manner. In some examples, the sensor electronics 3406 establishes a wireless communication link with the analyte sensor 3404. The analyte sensor 3404 provides the sensor identifier via the wireless link. Any preferred type of wired or wireless communication link can be used, for example, a Bluetooth LE connection or a Near Field Communication (NFC) connection. Also in some examples, the analyte sensor 3404 includes a radio frequency identifier (RFID) circuit. The sensor electronics 3404 can illuminate the RFID circuit with electromagnetic radiation, which may cause the RFID circuit to broadcast the sensor identifier. In an optional step 3504, the sensor electronics 3406 can establish a wireless communication session with a smart device 3412, for example, as described herein. Step 3504 may be omitted in examples where blind analyte measurements are performed.

[0461] In step 3506, the sensor electronics 3406 periodically receives analytic data from the analytic sensor 3404 and stores the received analytic data in data storage hardware that communicates with the sensor electronics 3406, for example. The analytic data may include analytic values ​​and / or metadata describing the host 3401, and / or diagnostic data describing the performance of the analytic sensor 3404. The sensor electronics can receive and store the analytic data at any preferred interval, such as every 30 seconds, every 5 minutes, or any other preferred interval. In some examples, the sensor electronics 3406 is programmed to prompt the analytic sensor 3404 to provide analytic data. For example, such a prompt may occur once per interval. In examples where the sensor electronics 3406 has a communication session with the smart device 3412, the sensor electronics 3406 can also transmit some or all of the collected analytic data to the smart device 3412 (e.g., the host 3401) for display.

[0462] In step 3508, the sensor electronics 3406 determines whether the use of the analyte sensor 3404 has ended. Use may end, for example, when the sensor usage period expires. For example, the analyte sensor 3404 can be configured to be used for a defined usage period (e.g., one week, ten days). If the sensor has been used for the entire usage period, the sensor use may end. In another example, the sensor use may end if the analyte sensor 3404 is removed from the host 3401 or otherwise fails. For example, the sensor electronics 3406 may determine that the analyte system 3404 has failed if it cannot receive analyte data within a defined range for measurements exceeding a threshold number.

[0463] If the use of the analyte sensor 3404 is not yet complete, the sensor electronics 3406 may continue to periodically receive and store analyte data in step 3506. If use is complete, the sensor electronics 3406 may enter an upload routine in step 3510. An exemplary upload routine is described herein with reference to Figures 36 and 37.

[0464] Figure 36 is a flowchart illustrating an example of a process 3600 that can be performed by the sensor electronics 3406 to upload the collected analyte data. Process 3600 is an example method by which the sensor electronics 3406 can upload the collected analyte data in step 3510 of process 3500.

[0465] When the sensor is no longer in use, in some examples the analyte sensor device 3402 (or in some examples only the sensor electronics 3406) is mailed to the location where the upload device 3450 resides, or otherwise physically transported. In the example of Figure 36, the sensor electronics 3406 begins broadcasting system identification data in step 3602. The system identification data can identify the sensor electronics 3406, the analyte sensor 3404, or both. The system identification data can be broadcast using any suitable wired or wireless communication technology, including, for example, Bluetooth, Bluetooth LE, MICS, NFC, etc.

[0466] When the sensor electronics 3406 is within range of the upload device 3450, the upload device 3450 can receive the transmitted system identification data and use the system identification data to establish a communication link (e.g., a wireless communication link) with the sensor electronics. In operation 3604, the sensor electronics determines, for example, whether it has received a request to establish a communication link with the upload device 3450. If no such request is received, the sensor electronics 3406 can continue broadcasting the system identification data in step 3602.

[0467] If a communication request is received in operation 3604, the sensor electronics 3406 establishes a communication link with the upload device 3450, for example in step 3608. In some examples, establishing a communication link includes authenticating the upload device 3450. For example, a communication request from the upload device 3450 may include authentication data for authenticating the upload device 3450. The communication link can follow any preferred wired or wireless technology, including, for example, Bluetooth, Bluetooth LE, MICS, NFC, etc. Once the communication link is established, the sensor electronics 3406 may begin uploading the collected analyte data to the upload device 3450 in operation 3610. The upload device 3450 may then upload the uploaded analyte data to one or more servers 3425, 3426, 3427 for further consideration. For example, the analyte data collected in this manner may constitute high-fidelity data that can be used in conjunction with low-fidelity data, for example, as described herein.

[0468] Figure 37 is a flowchart illustrating another example of a process 3700 that can be performed by the sensor electronics 3406 to upload the collected analyte data. Process 3700 is another exemplary method by which the sensor electronics 3406 can upload the collected analyte data in step 3510 of process 3500. As described herein, once the sensor use is complete, the analyte sensor device 3402 (or, in some examples, the sensor electronics 3406 alone) is mailed to the location where the upload device resides, or otherwise physically transported.

[0469] In the example in Figure 37, when the sensor usage is finished, the sensor electronics 3406 determines in operation 3702 whether an upload request has been received (for example, from the upload device 3450). The upload request can be transmitted using a suitable wired or wireless communication protocol. In some examples, wireless protocols such as NFC are used, but other protocols such as Bluetooth, Bluetooth LE, and MICS can also be used. If no upload request is received, the sensor electronics 3406 continues to wait for an upload request in operation 3702.

[0470] If an upload request is received in operation 3702, the sensor electronics 3406 broadcasts system identification data in step 3704. In step 3704, the sensor electronics uses the system identification data to establish a communication session with the upload device 3450. For example, the upload device 3450 receives the system identification data and can use it to retrieve authentication data from the sensor electronics 3406. The upload device 3450 can then use the authentication data to establish a communication session. Once the communication session is established, the sensor electronics 3406 uploads the stored analyte data to the upload device 3450 in step 3708. The upload device 3450 can then upload the uploaded analyte data to one or more servers 3425, 3426, 3427 for further consideration. For example, analyte data collected in this manner may constitute high-fidelity data that can be used in conjunction with low-fidelity data, as described herein, for example.

[0471] While methods and systems are often described herein in relation to estimated blood glucose concentration levels, such as those determined by a continuous glucose monitor (CGM) that estimates blood glucose concentration levels from subcutaneous fluid measurements, methods and systems may also be applied to other types of concentration levels, such as actual blood glucose concentration levels, or to the levels of other analytes in blood, other body fluids, or substances. Methods and systems may also be applied to other physiological conditions or circumstances that are desirable to manage for health or other reasons.

[0472] Each of these non-limiting embodiments can be independent of itself or can be combined in various permutations or in combination with one or more of the other embodiments.

[0473] The above detailed description includes references to accompanying drawings that form part of the detailed description. The drawings illustrate specific embodiments in which the present invention can be carried out. These embodiments are also referred to herein as “Examples.” Such embodiments may include elements in addition to those shown or described. However, the inventors also intend embodiments in which only the shown or described elements are provided. Furthermore, the inventors also intend embodiments in which any combination or permutation of the shown or described elements (or one or more embodiments thereof) is used, either relating to a specific embodiment (or one or more aspects thereof) or to other embodiments (or one or more aspects thereof) shown or described herein.

[0474] In the event of any inconsistent usage between this document and any of the documents incorporated by reference, the usage in this document shall prevail.

[0475] In this document, the terms “a” or “an” are used to mean one or more, as is common in patent documents, regardless of other instances or uses of “at least one” or “one or more.” In this document, the term “or” is used to mean non-exclusive “or,” such that “A or B” includes “A but not B,” “B but not A,” and “A and B.” In this document, the terms “including” and “in which” are used as plain English equivalents of the terms “comprising” and “wherein.” Furthermore, in the following claims, the terms “including” and “equipped with” are unrestrictive; that is, any system, device, article, composition, formulation, or process that includes elements in addition to those listed after such terms in the claims is still considered to be within the scope of that claim. Furthermore, in the following claims, terms such as “first,” “second,” and “third” are used merely as labels and are not intended to impose numerical requirements on those objects.

[0476] Geometric terms such as "parallel," "perpendicular," "circular," or "quadrilateral" do not require absolute mathematical precision unless otherwise indicated in the context. Instead, such geometric terms allow for variations due to manufacturing or equivalent function. For example, if an element is described as "circular" or "generally circular," elements that are not exactly circular (e.g., somewhat rectangular or multi-sided polygons) are also included in this description.

[0477] Examples of the methods described herein can be implemented at least partially in machines or computers. Some examples may include computer-readable or machine-readable storage media encoded with instructions that can be operated to configure an electronic device to perform the methods described in the above examples. Implementations of such methods may include, for example, code such as microcode, assembly language code, or higher-level language code. Such code may include computer-readable instructions for performing various methods. The code may form part of a computer program product. Furthermore, in one example, the code may be tangibly stored in one or more volatile, non-temporary, or non-volatile tangible computer-readable storage media during execution or at other times. Embodiments of these tangible computer-readable storage media may include, but are not limited to, hard disks, removable magnetic disks, removable optical disks (e.g., compact disks and digital video disks), magnetic cassettes, memory cards or sticks, random access memory (RAM), read-only memory (ROM), and the like.

[0478] The above description is intended to be illustrative and not limiting. For example, the above embodiments (or one or more embodiments thereof) may be used in combination with one another. A person skilled in the art may, for example, use other embodiments by considering the above description. The abstract is provided in accordance with 37 C. FR § 1.72(b) so that the reader may quickly confirm the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Also, in the above detailed description, various features may be grouped together in order to simplify the disclosure. This should not be interpreted as meaning that any disclosed features not claimed are essential to the claims. Rather, the subject matter of the invention may not be encompassed by all features of a particular disclosed embodiment. Consequently, the following claims are incorporated into the detailed description as examples or embodiments, and each claim stands independently as a separate embodiment, and such embodiments are intended to be combined with one another in various combinations or substitutions. The scope of the invention should be determined by referring to the appended claims, along with the entire scope of the equivalent to which such claims are granted. [Explanation of Symbols]

[0479] 100 Systems 101 Host 102 Analytical Sensor System 104 Analytical Sensor 106 Sensor Electronics 108. Second Medical Device 110 Wireless communication signal 112 Handheld Devices 114 Tablets 116 Smart Pen 118 Computers 120 Wearable Devices 122 Peripheral Medical Devices 124 Network 125,126,127 Server Systems 128 Remote terminals 130, 134, 136 Wearable Sensors 132 User Devices 138 Wireless Access Point (WAP) 200 Medical Device Systems 202 Potentiostat 204 Processors 206 Command 208 memory 210 Data Storage 212 sensors 214 batteries 216 Recharging System 218 Wireless Communication 250 peripheral devices 252 User Interface 254 memory 356 processors 258 Wireless 260 sensors 262 Power supply 270 medical devices 272 User Interface 274 memory 276 processors 278 Wireless 280 sensors 282 Treatment 284 Power supply 290 base 2200, 2200A System 2201 participants 2202 Continuous Glucose Monitoring (CGM) Sensor 2204 Activity Sensor 2206 User Computing Devices 2208 First Application 2210 Second Application 2212 First Web Service System 2214 Second Web Service System 2216 Coaching Server 2218 Synchronized data (CGM data) 2220 Sensor Data Subsystem 2222 Data Services Section 2224 Registered subsystem 2226 Provisioning subsystem 2228 Eligibility Subsystem 2230 CGM execution subsystem 2232 Second Sensor Data Subsystem 2234 Synchronized data (activity data) 2236 Activity Detection System 2238 Intervention Engine 2240 Conversation Server 2241 Coach 2242 Coaching Dashboard 2244,2246 Guidance section 2248 Coach Pool 2250 Call Center 2252 Reports of adverse events 2254 Push Notifications 2256 Second push notification 2258 Web Application Programming Interface (API) 2260 Activity Sensor Authentication System 2262 Authentication System 2264 Group System 2266 Glucose Level API 2402 CGM 2404 Transmitter / Receiver 2405 Analytical Sensor App 2410 Cloud Computing Architecture 2412 Coaching Server 2414 Coaching Module 2502 Coaching Module 2504 Initializer Module 2506 Exercise Module 2508 Meal Module 2510 Sleep Module 2512 Coaching Server 3400 System 3401 Host 3402 Analytical Sensor System 3404 Analytical Sensor 3406 Sensor Electronics 3410 Wireless communication signal 3412 Smart devices 3424 Network 3425, 3426, 3427 Server Systems 3450 Upload Devices< / s> < / f> < / m> < / f> < / m>

Claims

1. A method for operating a patient monitoring system, Monitoring the patient's glucose concentration, continuously measured by a continuous glucose monitoring (CGM) system attached to the patient, during a first period, wherein the monitoring includes receiving a plurality of first glucose information from the CGM system, the plurality of first glucose information representing the patient's glucose concentration at a plurality of time points during the first period. During the first period, the receiving of a plurality of first non-glucose information from an activity monitor attached to the patient, wherein the plurality of first non-glucose information indicates the patient's physical activity corresponding to the plurality of time points during the first period. The relationship between the plurality of first glucose information and the plurality of first non-glucose information is determined by relating the physical activity of the patient to the corresponding effect on the patient's glucose concentration as a change in glucose concentration, In the second period, it is determined that glucose information is not available from the CGM system, During the second period in which glucose information is unavailable from the CGM system, the system receives second non-glucose information from the activity monitor attached to the patient, wherein the second non-glucose information indicates the patient's physical activity corresponding to the second period. Based on the determined relationship between the plurality of first glucose information and the plurality of first non-glucose information and the patient's second non-glucose information, the second glucose information of the patient for the second period is estimated in real time. A method comprising electronically distributing a notification relating to the second glucose information during the second period.

2. Receiving additional non-glucose information of the patient for the first period, wherein the additional non-glucose information is different from the plurality of first non-glucose information. The method according to claim 1, further comprising determining the relationship between the plurality of first glucose information, the plurality of first non-glucose information, and the additional non-glucose information, wherein the determination of second glucose information is at least partially based on the determined relationship.

3. The method according to claim 1, wherein the plurality of first non-glucose information indicating the patient's physical activity and the second non-glucose information indicating the patient's physical activity each include physiological information relating to the patient.

4. The method according to claim 3, wherein the physiological information includes at least one of heart rate, respiration, oxygen concentration, skin tension, skin water content, activity, activity pattern, blood ketones, urinary ketones, respiration, or acoustic information.

5. The method according to claim 1, wherein each of the plurality of first non-glucose information and the second non-glucose information further includes location information.

6. The method according to claim 1, wherein estimating second glucose information includes determining the estimated glucose concentration level.

7. The method according to claim 1, wherein estimating second glucose information includes determining an estimate of the amount or percentage of time during a specified period that the glucose concentration level was within a specified range.

8. The plurality of first non-glucose information of the patient includes first activity data received from the activity monitor attached to the patient during the first period, The method according to claim 1, wherein determining the relationship includes associating the first activity data with the plurality of first glucose information of the patient.

9. The method according to claim 8, wherein the activity monitor includes a clock.

10. The method according to claim 1, further comprising adjusting a glucose estimation algorithm based on the determined relationship between the plurality of first glucose information and the plurality of first non-glucose information, wherein estimating second glucose information includes using the adjusted glucose estimation algorithm.

11. Monitoring the patient's glucose concentration during a third period, comprising receiving a plurality of third glucose information from the CGM system, wherein the plurality of third glucose information indicates the patient's glucose concentration at a plurality of time points during the third period. During the third period, the receiving of a plurality of third non-glucose information from the activity monitor, wherein the plurality of third non-glucose information indicates the patient's physical activity corresponding to the plurality of time points during the third period. The method according to claim 10, further comprising adjusting the glucose estimation algorithm based on the determined relationship between the plurality of third glucose information and the plurality of third non-glucose information.

12. The method according to claim 10, further comprising periodically adjusting the glucose estimation algorithm based on additional glucose information received from the CGM system and additional non-glucose information received from the activity monitor during one or more subsequent periods.

13. The method according to claim 1, wherein the plurality of first non-glucose information and the second non-glucose information each include activity data.

14. The plurality of first non-glucose information and the second non-glucose information each include the same type of information, Steps, Indicators of activity types, An indicator of activity intensity, and An indicator of the amount of time spent on an activity. The method according to claim 1, comprising at least one of the following.

15. The method according to claim 1, wherein the first period includes one of the periods of 3 days, 7 days, 10 days, 14 days, 30 days, 1 month, and 3 months.

16. The method according to claim 1, wherein each of the plurality of first glucose information and the second glucose information includes at least one glucose concentration level.

17. A non-temporary computer-readable storage medium storing instructions, wherein when the instructions are executed by at least one processor, the at least one processor is provided with Monitoring the patient's glucose concentration, continuously measured by a continuous glucose monitoring (CGM) system configured to be worn by the patient, during a first period, wherein the monitoring includes receiving a plurality of first glucose information from the CGM system, the plurality of first glucose information representing the patient's glucose concentration at a plurality of time points during the first period. During the first period, the receiving of a plurality of first non-glucose information from an activity monitor configured to be worn by the patient, wherein the plurality of first non-glucose information indicates the patient's physical activity corresponding to the plurality of time points during the first period. The relationship between the plurality of first glucose information and the plurality of first non-glucose information is determined by relating the physical activity of the patient to the corresponding effect on the patient's glucose concentration as a change in glucose concentration, In the second period, it is determined that glucose information is not available from the CGM system, During the second period in which glucose information is unavailable from the CGM system, the system receives second non-glucose information of the patient from the activity monitor, wherein the second non-glucose information indicates the patient's physical activity corresponding to the second period. Based on the determined relationship between the plurality of first glucose information and the plurality of first non-glucose information and the patient's second non-glucose information, the second glucose information of the patient for the second period is estimated in real time. A non-temporary computer-readable storage medium that performs an operation including electronically distributing a notification relating to the second glucose information during the second period.

18. The operation described above is: Determining guidance based at least partially on the second glucose information, The non-temporary computer-readable storage medium according to claim 17, further comprising displaying the guidance on a user interface.

19. The operation described above is: Receiving additional non-glucose information of the patient for the first period, wherein the additional non-glucose information is different from the plurality of first non-glucose information, A non-temporary computer-readable storage medium according to claim 17, further comprising determining the relationship between the plurality of first glucose information, the plurality of first non-glucose information, and the additional non-glucose information, wherein the determination of second glucose information is at least partially based on the determined relationship.

20. The non-temporary computer-readable storage medium according to claim 17, wherein the activity monitor includes a clock.

Images