Recommendation for cost-effective treatment

Abstract

Various examples are directed to systems and methods for measuring parameters related to a patient's health. An analyte sensor system can detect that the analyte sensor system has been applied to a host and can store analyte data that describes the host. The analyte sensor system can determine that use of the sensor in the analyte sensor system has ended and can upload the stored analyte data to an upload computing device.

Description

Technical Field

[0001] This development generally relates to medical devices such as analyte sensors, and more specifically, but not limited to, systems, devices, and methods for intermittently using continuous glucose monitoring systems or other monitoring systems.

Background Art

[0002] Diabetes is a metabolic disease related to the production or use of insulin in the body. Insulin is a hormone that enables the body to use glucose as energy or store glucose as fat.

[0003] When a person eats a carbohydrate-containing meal, the food is processed in the digestive system and glucose is produced in the blood. Blood glucose can be used as energy or stored as fat. The body usually maintains the blood glucose level within a range sufficient to support body functions and avoids problems that can occur if the glucose level is too high or too low. Adjustment of the blood glucose level depends on the production and use of insulin, which regulates the movement of blood glucose into cells.

[0004] When the body does not produce enough insulin or cannot effectively use the insulin present, the blood glucose level may rise above the normal range. A condition where the blood glucose level is higher than the normal value is called "hyperglycemia". Chronic hyperglycemia can cause several health problems such as cardiovascular disease, cataracts and other eye diseases, neuropathy, and kidney damage. Hyperglycemia can also cause acute problems such as diabetic ketoacidosis (a condition where the body becomes overly acidic due to the presence of blood glucose and ketone bodies produced when the body cannot use glucose). A condition where the blood glucose level is lower than the normal value is called "hypoglycemia". Severe hypoglycemia can lead to an acute crisis resulting in seizures or death.

[0005] Diabetes is sometimes referred to as "type 1" and "type 2". Patients with type 1 diabetes typically can use insulin when it is present, but due to problems with the insulin-producing β cells in the pancreas, they cannot produce sufficient amounts of insulin in the body. Patients with type 2 diabetes can produce some insulin, but due to reduced sensitivity to insulin, the patients are "insulin resistant". As a result, even when insulin is present in the body, the insulin is not fully utilized in the patient's body and does not effectively regulate blood glucose levels.

[0006] Blood glucose concentration values can be monitored with an analyte sensor such as a continuous glucose monitor. A continuous glucose monitor can provide information such as estimated blood glucose values and trends in estimated blood glucose values to the wearer (patient).

[0007] This "Background Art" is provided to introduce a brief background for the following "Summary of the Invention" and "Modes for Carrying Out the Invention". This "Background Art" is not intended to assist in determining the scope of the claimed subject matter, nor is it to be regarded as limiting the claimed subject matter to implementations that solve any or all of the drawbacks or problems presented above.

Summary of the Invention

[0008] This specification describes, among other things, systems, devices, and methods for battery management in analyte sensors such as glucose sensors.

[0009] An example of a subject (e.g., a method, a device, or a system), such as "Example 1", may include the following.

[0010] Example 1 is a method for monitoring a diabetic patient. The method may include receiving first data of a first type of the patient over a first period. The method may also include receiving second data of a second type of the patient over at least a second period. The first period and the second period may at least partially overlap over an overlapping period. The method may include determining a correlation between the first data and the second data over the overlapping period, receiving data of the second type at a subsequent time, and determining diabetic information regarding the patient based at least in part on the data of the second type and the determined correlation at the subsequent time.

[0011] 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.

[0012] In Example 3, the subject matter of any one or more of Examples 1-2 optionally includes an example in which the second data includes single-point glucose monitoring, blinded CGM, data from a wearable monitor, flash glucose monitoring, or optical monitoring techniques.

[0013] In Example 4, the subject matter 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 a single-point glucose measurement based on the first data.

[0014] In Example 5, the subject matter of any one or more of Examples 1-4 optionally includes an example in which the diabetic information is selected from the group consisting of an estimated value of data of the first type at a subsequent time, the patient's condition, or the patient's insight.

[0015] In Example 6, the subject matter of Example 5 optionally includes an example in which the patient's condition or the patient's insight is related to an improvement in lifestyle related to diet, exercise, glucose value monitoring, or medication.

[0016] In Example 7, the subject matter of Example 6 optionally includes examples where the patient's condition or the patient's awareness optionally includes examples related to meal time management, exercise management, or sleep management.

[0017] In Example 8, the subject matter of any one or more of Examples 1 to 7 optionally includes an example where the first data is high-fidelity data and the second data is low-fidelity data.

[0018] In Example 9, the subject matter of any one or more of Examples 1 to 8 optionally includes receiving a sensor signal from a sensor and processing the sensor signal to generate at least a part of the second data.

[0019] In Example 10, the subject matter of Example 9 optionally includes an example where the sensing includes activity monitoring by a wearable fitness tracker.

[0020] In Example 11, the subject matter of Example 10 optionally includes an example where the wearable fitness tracker includes a wearable heart rate monitor, a wearable activity monitor, a smartphone, smart glasses, or a smartwatch.

[0021] In Example 12, the subject matter of any one or more of Examples 1 to 11 optionally includes an example where determining the correlation includes determining the relationship between the acquired first data and the second data at corresponding times and / or days of the week within an overlapping period.

[0022] In Example 13, the subject matter of any one or more of Examples 1 to 12 optionally includes an example where the second data includes user input data.

[0023] In Example 14, the subject matter of Example 13 optionally includes an example where the user input data includes drug data, meal data, exercise data, sleep data, or any combination thereof.

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

[0025] In Example 16, the theme of Example 15 optionally includes an example where intermittently monitoring the first type of data includes intermittent continuous glucose monitoring, and monitoring the second type of data includes monitoring activity data using a wearable accelerometer. Optionally, when continuous glucose monitoring is not performed, it includes an example where the wearable accelerometer is configured to at least monitor data.

[0026] In Example 17, one or more of the themes of Examples 1 to 16 optionally include an example where the first data of the first type includes estimated glucose concentration values, and the second type of data includes heart rate, oxygen concentration, skin color, skin moisture content, activity, activity pattern, blood ketone, urine ketone, respiration, or acoustic information.

[0027] In Example 18, one or more of the themes of Examples 1 to 17 optionally include monitoring the first data and the second data over a third period and updating the correlation based on the first data and the second data from the third period.

[0028] In Example 19, one or more of the themes of Examples 1 to 18 optionally include administering treatment based at least in part on the determined diabetes information.

[0029] In Example 20, the theme of Example 19 optionally includes an example where the treatment includes pharmaceutical intervention.

[0030] In Example 21, one or more of the themes of Examples 19 to 20 optionally include displaying diabetes information regarding the patient on a user interface of the patient device.

[0031] In Example 22, the subject matter of Example 21 optionally includes displaying, on a user interface, an improved recommended diet or an improved lifestyle.

[0032] Example 23 can be a method that includes receiving, over a first period, estimated glucose concentration values of a patient from a continuous glucose monitoring (CGM) system and receiving non-CGM information about the patient over the first period. The method can also include determining a relationship between the estimated glucose concentration values and the non-CGM information. The method can also include receiving non-CGM information about the patient over a second period during which estimated glucose concentration values from the CGM are not available and determining diabetic information about the patient over the second period based on the determined relationship and the non-CGM information. The method can further include electronically delivering a notification regarding the diabetic information.

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

[0034] In Example 25, the subject matter of any one or more of Examples 23-24 optionally includes an example in which the non-CGM information includes physiological information about the patient.

[0035] In Example 26, the subject matter of Example 25 optionally includes an example in which the physiological information includes one or more of heart rate, respiration, oxygen concentration, skin color, skin moisture, activity, activity pattern, blood ketones, urine ketones, respiration, or acoustic information.

[0036] In Example 27, the subject matter of any one or more of Examples 23-26 optionally includes an example in which the non-CGM information includes location information.

[0037] In Example 28, the subject matter of any one or more of Examples 23-27 optionally includes an example in which receiving the non-CGM information includes receiving user input data.

[0038] In Example 29, any one or more of the themes of Examples 23 to 28 optionally include an example in which determining diabetes information about a patient includes determining the patient's condition.

[0039] In Example 30, any one or more of the themes of Examples 23 to 29 optionally include an example in which determining a patient condition includes applying non-CGM information to a model.

[0040] In Example 31, any one or more of the themes of Examples 23 to 30 optionally include an example in which determining diabetes information includes determining an estimated glucose concentration value.

[0041] In Example 32, any one or more of the themes of Examples 23 to 31 optionally include an example in which determining diabetes information includes determining a qualitative assessment.

[0042] In Example 33, any one or more of the themes of Examples 23 to 32 optionally include an example in which determining diabetes information includes determining a quantitative metric.

[0043] In Example 34, the theme of Example 33 optionally includes an example in which the quantitative metric is an estimated amount or percentage of time during a specified period that glucose concentration values were within a range.

[0044] 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 the primary physiological information.

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

[0046] 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 during a period when intermittent primary physiological information is not available, the guidance system determines guidance based at least in part on the secondary data and the relationship between the secondary data and the primary physiological information.

[0047] 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 in part on the secondary data and the relationship between the secondary data and the primary physiological information.

[0048] In Example 39, the subject matter of Example 38 optionally includes an example in which the diabetes management information includes an estimated glucose concentration value.

[0049] In Example 40, the subject matter of any one or more of Examples 38 - 39 optionally includes an example in which the diabetes management information includes a qualitative assessment.

[0050] In Example 41, the subject matter of any one or more of Examples 38 - 40 optionally includes an example in which the diabetes management information includes a metric.

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

[0052] In Example 43, the subject matter of any one or more of Examples 41 - 42 optionally includes an example in which the diabetes management information includes statistical feedback.

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

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

[0055] Example 46 is a patient management device, the device comprising a sensor, a user interface, a communication circuit, and a processor. The processor can execute instructions for performing operations. The operations can include transmitting, using the communication circuit, information based on an input from the sensor to a second device, and receiving, using the communication circuit, an estimated value of a physiological state based at least in part on an input from the sensor. The operations can also include delivering, using the user interface, information regarding the estimated value of the physiological state.

[0056] In Example 47, the theme of Example 46 optionally includes an example in which the sensor is an activity sensor.

[0057] In Example 48, any one or more of the themes of Examples 46 to 47 optionally include an example in which the estimated value of the physiological state is a glucose concentration value.

[0058] In Example 49, any one or more of the themes of Examples 46 to 48 optionally include an example in which the information regarding the estimated value of the physiological state is an in-range time, a glucose concentration value, or a glucose concentration range.

[0059] In Example 50, any one or more of the themes of Examples 46 to 49 optionally include an example in which the estimated value of the physiological state is based on the correlation between the previously collected glucose concentration information and the previously collected activity information.

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

[0061] In Example 52, the theme of Example 51 optionally includes an example in which the device is a wristwatch.

[0062] In Example 53, any one or more of the themes of Examples 46 to 52 further optionally include an example in which the operation includes generating a sensor message including an estimated value of the physiological state by a first application executed by a processor, transmitting the sensor message by the first application to a second application executed by the processor, and transmitting a device message by the second application to a second device for display using a user interface.

[0063] In Example 54, the theme of Example 53 optionally includes an example in which generating the sensor message includes encrypting the estimated value of the physiological state.

[0064] In Example 55, any one or more of the themes of Examples 53 to 54 optionally include an example in which generating the sensor message includes generating an error detection code based at least in part on the physiological state.

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

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

[0067] In Example 58, the subject matter of any one or more of Examples 56-57 optionally includes an example in which the high-fidelity monitoring technique is continuous glucose monitoring.

[0068] In Example 59, the subject matter of any one or more of Examples 56-58 optionally includes an example in which the low-fidelity technique includes single-point glucose monitoring or blind CGM or optical monitoring techniques.

[0069] In Example 60, the subject matter of any one or more of Examples 56-59 optionally includes an example in which the low-fidelity monitoring technique includes activity monitoring by a wearable fitness tracker.

[0070] In Example 61, the subject matter of Example 60 optionally includes an example in which the wearable fitness tracker is a wearable heart rate monitor, activity monitor, smartphone, smart glasses, or smartwatch.

[0071] In Example 62, the subject matter of any one or more of Examples 56-61 optionally includes an example in which the low-fidelity monitoring technique includes receiving user input data.

[0072] In Example 63, the subject matter of Example 62 optionally includes an example in which the received user input data includes medication data, dietary data, exercise data, sleep data, or any combination thereof.

[0073] In Example 64, the subject matter of any one or more of Examples 56 to 63 optionally includes determining a goal for a patient, and at least one hardware function or software function of the monitoring device is related to the goal.

[0074] In Example 65, the subject matter of Example 64 optionally includes an example in which the goal includes a dietary goal, an exercise goal, a glucose value monitoring goal, or a medication-taking goal.

[0075] In Example 66, the subject matter of Example 65 optionally includes an example in which at least one hardware function or software function of the monitoring device is related to dietary time glucose management.

[0076] In Example 67, the subject matter of any one or more of Examples 65 to 66 optionally includes an example in which at least one hardware function or software function of the monitoring device is related to sleep management.

[0077] In Example 68, the subject matter of any one or more of Examples 64 to 67 optionally includes an example in which determining a goal for a patient is determined prior to monitoring over a first period of time.

[0078] In Example 69, the subject matter of any one or more of Examples 64 to 68 optionally includes an example in which determining a goal for a patient is determined by first type of data monitored over a first period using a low-fidelity monitoring technique.

[0079] In Example 70, any one or more of the themes of Examples 56 to 69 optionally includes monitoring physiological-type patient data over a first period, and the criteria for at least one hardware function or software function of the monitoring device are further based on the physiological-type patient data.

[0080] In Example 71, any one or more of the themes of Examples 56 to 70 optionally includes an example where at least one hardware function or software function is related to the frequency or content of an automatic coaching routine.

[0081] In Example 72, any one or more of the themes of Examples 56 to 71 optionally includes detecting a change in patient parameters, i.e., a change measured between a first period and a second period, and using the detected change to further affect at least one hardware function or software function of the monitoring device.

[0082] In Example 73, any one or more of the themes of Examples 56 to 72 optionally includes providing a coaching function to the patient over a first period, the coaching function including an automatic message transmitted from a server to the monitoring device based on patient profile data or first-type patient data or a combination thereof.

[0083] In Example 74, any one or more of the themes of Examples 56 to 73 optionally includes determining the amount or frequency of subsequent data after a second period, the amount or frequency of subsequent data being determined using a low-fidelity monitoring technique or a high-fidelity monitoring technique, and the amount or frequency being calculated to increase or maximize patient parameters.

[0084] In Example 75, the theme of Example 74 optionally includes an example where the patient parameter is within-range time.

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

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

[0087] In Example 78, the subject matter of any one or more of Examples 74 to 77 optionally includes an example in which the patient parameter is A1c.

[0088] In Example 79, the subject matter of Example 78 optionally includes an example in which the amount or frequency of subsequent data is determined using a low-fidelity monitoring technique.

[0089] In Example 80, the subject matter of any one or more of Examples 74 to 79 optionally includes displaying an increased or maximized display of a patient parameter on a monitoring device.

[0090] In Example 81, the subject matter of any one or more of Examples 74 to 80 optionally includes determining a final goal of a patient after a second period, where the final goal of the patient depends at least in part on a first type of patient data or a second type of patient data, and displaying a treatment recommendation calculated to cause a transition of the patient state towards the final goal of the patient.

[0091] Example 82 is a system comprising a first system configured to collect a first set of sensor data of a first type regarding a patient, and a second system configured to collect a second set of sensor data of a second type of data regarding the patient. The system may further comprise a determination system configured to determine user parameters of the second system based on the first set of sensor data.

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

[0093] In Example 84, one or more of the themes of Examples 82-83 optionally include an example in which the first system includes a blood glucose meter.

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

[0095] In Example 86, one or more of the themes of Examples 82-85 optionally include an example in which the user parameter includes a usage schedule of the second system.

[0096] In Example 87, one or more of the themes of Examples 82-86 optionally include an example in which the user parameter is the start time of use (us) of the second system.

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

[0098] In Example 89, one or more of the themes of Examples 82-88 optionally include a third system configured to collect a third sensor data set regarding a patient, and the decision system determines user parameters based at least in part on the first sensor data set and the third data set.

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

[0100] In Example 91, the theme of Example 90 optionally includes an example in which the sensor is an activity sensor.

[0101] In Example 92, one or more of the themes of Examples 90 - 91 optionally include an example where the device is a wearable device.

[0102] In Example 93, the theme of Example 92 optionally includes an example where the device is a wristwatch.

[0103] In Example 94, one or more of the themes of Examples 90 - 93 optionally include an example where the processor further executes instructions to determine the configuration of the user interface using information about the subject.

[0104] In Example 95, the theme of Example 94 optionally includes an example where the device displays a specified set of metrics based on previously collected low - fidelity data.

[0105] In Example 96, one or more of the themes of Examples 94 - 95 optionally include an example where the device distributes information at a specified time based on previously collected low - fidelity data.

[0106] In Example 97, one or more of the themes of Examples 94 - 96 optionally include an example where the device notifies a patient management facilitator regarding the availability of an estimated value of a physiological state and presents guidance from the patient management facilitator using the user interface.

[0107] In Example 98, one or more of the themes of Examples 90 - 97 optionally include an example where the estimated value of the physiological state is a glucose concentration value.

[0108] Example 99 is a method for selecting patients who are likely to benefit from intermittent high-fidelity monitoring. The method may include performing a first screening algorithm on a pool of participants to determine a group of patients with diabetes or diabetes risk factors. The method may also include providing a first kit to participants within the determined group, the kit being structured and configured to enable the participants to perform low-fidelity monitoring of their health over a first period using a first monitoring technique, and obtaining a first result. The method includes performing a second screening algorithm on the determined group to determine a cohort for participating in intermittent high-fidelity monitoring, the second screening algorithm at least partially using the obtained first result, and then providing a second kit to participants within the determined cohort, the second kit being structured and configured to enable the participants in the determined cohort to perform high-fidelity monitoring of their health over a second period using a second monitoring technique, and obtaining a second result. The method may also include providing a third kit to one or more participants within the determined cohort, the one or more participants being determined at least partially in accordance with the obtained second result.

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

[0110] In Example 101, the subject matter of any one or more of Examples 99 - 100 optionally includes an example where performing the second screening includes determining an estimate of the likelihood that a patient will benefit from high-fidelity monitoring.

[0111] In Example 102, the subject matter of any one or more of Examples 99 - 101 optionally includes an example where the second kit is structured and configured based on the obtained first result.

[0112] In Example 103, any one or more of the themes of Examples 99 to 102 optionally include an example in which the third kit is structured and configured based on the obtained second result.

[0113] In Example 104, any one or more of the themes of Examples 99 to 103 optionally include performing communication between the server and a device in the first kit during at least a first time, the communication providing a guidance message to a patient.

[0114] In Example 105, any one or more of the themes of Examples 99 to 104 optionally include an example in which low-fidelity monitoring includes single-point glucose monitoring, heart rate monitoring, activity monitoring, blind continuous glucose monitoring, or any combination thereof.

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

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

[0117] In Example 108, any one or more of the themes of Examples 99 to 107 optionally include an example in which an algorithm uses one or more factors selected from the group consisting of an electronic medical record, a type II diabetes diagnosis code, a family history, weight, BMI, a history of metabolic disease, blood test values, A1c, fasting glucose value, oral glucose tolerance, prescribed diabetes medications, or any combination thereof.

[0118] In Example 109, any one or more of the themes of Examples 99 to 108 optionally include an example in which a second screening algorithm is based at least in part on factors contributing to adherence to the use of low-fidelity monitoring during a first period.

[0119] Example 110 is a method for managing parameters related to a patient's health, the method including a phase of intermittent high-fidelity monitoring. The method may first include monitoring a patient over a first period using a first monitoring technique and obtaining a first result. The method may also include monitoring a patient over a second period using a second monitoring technique and obtaining a second result. The method may also include determining an action that the patient can perform, the action being based on the obtained first and second results and being calculated to increase the likelihood of meeting management conditions. In some examples, either the first monitoring technique or the second monitoring technique includes high-fidelity monitoring.

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

[0121] In Example 112, the subject matter of any one or more of Examples 110-111 optionally includes displaying an output to the patient, the displayed output indicating the patient's performance regarding a diet goal, an exercise goal, a glucose value monitoring goal, or a medication goal.

[0122] In Example 113, the subject matter of any one or more of Examples 110-112 optionally includes an example where the parameters related to the patient's health are selected from the group consisting of in-range time and glycemic variability.

[0123] In Example 114, the subject matter of any one or more of Examples 110-113 optionally includes an example where meeting management conditions includes reducing parameters related to the patient's health by a greater amount than a predetermined amount with a confidence level higher than a predetermined confidence level.

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

[0125] In Example 116, one or more of the themes of Examples 110 - 115 optionally include an example where a first period is a subset of a second period.

[0126] In Example 117, one or more of the themes of Examples 110 - 116 optionally include an example where a first period overlaps with a second period.

[0127] In Example 118, one or more of the themes of Examples 110 - 117 optionally include performing communication between a server and a device associated with a patient during either or both of a first period and a second period, where the communication provides a coaching function to the patient.

[0128] In Example 119, one or more of the themes of Examples 110 - 118 optionally include displaying an output to a patient, where the displayed output indicates an optimized period during which the patient should use high - fidelity monitoring.

[0129] In Example 120, one or more of the themes of Examples 110 - 119 optionally include an example where a first monitoring technique is a low - fidelity monitoring technique and a second monitoring technique is a high - fidelity monitoring technique.

[0130] In Example 121, Example 120 optionally includes an example where the low - fidelity monitoring technique includes single - point glucose monitoring or blind CGM.

[0131] In Example 122, one or more of the themes of Examples 120 - 121 optionally include an example where the low - fidelity monitoring technique includes activity monitoring by a wearable fitness tracker.

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

[0133] In Example 124, the subject matter of any one or more of Examples 120 - 123 is correlating a first obtained result with a second obtained result, where correlating includes determining the relationship between the first obtained result and the second obtained result at corresponding times and / or days of the week, and optionally includes determining an estimated value of a high-fidelity monitoring technique at a given time based at least in part on a correlation value at the given time and results obtained by a low-fidelity monitoring technique.

[0134] In Example 125, the subject matter of Example 124 optionally includes determining an estimated value based at least in part on population data.

[0135] In Example 126, the subject matter of any one or more of Examples 120 - 125 optionally includes an example where the low-fidelity monitoring technique receives user input data.

[0136] In Example 127, the subject matter of Example 126 optionally includes an example where the received user input data includes medication data, dietary data, exercise data, sleep data, or any combination thereof.

[0137] In Example 128, the subject matter of any one or more of Examples 120 - 127 is correlating a first obtained result with a second obtained result, where correlating includes determining the relationship between the first obtained result and the second obtained result at a corresponding time or day of the week, and optionally includes determining an estimated value of a high-fidelity monitoring technique at a given time based at least in part on an estimated correlation value at the given time and results obtained by a low-fidelity monitoring technique.

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

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

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

[0141] In Example 132, after determining that the use of the sensor in the analyte sensor system has ended, the analyte sensor system optionally includes receiving an upload request from an upload computing device, broadcasting system identification data by the analyte sensor system, and receiving authentication data from the upload computing device. The method may also include establishing a communication session with the upload computing device by the analyte sensor system, and uploading includes transmitting the stored analyte data to the upload computing device.

[0142] Example 133 includes receiving estimated glucose concentration values of a patient from a continuous glucose monitoring (CGM) system for a first period, receiving non-glucose information about the patient for the first period, determining a relationship between the estimated glucose concentration values and the non-glucose information, receiving non-glucose information about the patient for a second period, determining diabetic information about the patient for the second period based on the determined relationship and the non-glucose information, and electronically distributing a notification regarding the diabetic information.

[0143] In Example 134, the subject matter of Example 133 optionally includes receiving a plurality of estimated glucose concentration values from the CGM system from the first period, and receiving non-glucose information for the first period includes receiving at least one single-point glucose measurement value obtained during the first period.

[0144] In Example 135, the subject matter of any one or more of Examples 133-134 optionally includes that the estimated glucose concentration values from the CGM are not available during the second period.

[0145] In Example 136, one or more of the subjects of Examples 133 - 135 optionally include receiving second non - glucose information related to a patient for a first period, where the second non - glucose information is different from the non - glucose information and the relationship is between an estimated glucose concentration value, the non - glucose information, and the second non - glucose information.

[0146] In Example 137, one or more of the subjects of Examples 133 - 136 optionally include that the non - glucose information includes physiological information related to the patient.

[0147] In Example 138, the subject of Example 137 optionally includes that the physiological information includes at least one of heart rate, respiration, oxygen concentration, skin color, skin moisture, activity, activity pattern, blood ketone, urine ketone, respiration, or acoustic information.

[0148] In Example 139, one or more of the subjects of Examples 133 - 138 optionally include that the non - glucose information includes location information.

[0149] In Example 140, one or more of the subjects of Examples 133 - 139 optionally include that determining diabetes information optionally includes determining an estimated glucose concentration value.

[0150] In Example 141, one or more of the subjects of Examples 133 - 140 optionally include that determining diabetes information includes determining an estimated value of the amount or percentage of time during a specified period that glucose concentration values were within a range.

[0151] 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.

[0152] In Example 143, the subject matter of Example 142 is such that the guidance system is also configured to determine the relationship between secondary data and primary physiological information and to determine guidance during periods when the primary physiological information is not being collected, and determining the guidance optionally includes being at least partially based on the secondary data and the relationship between the secondary data and the primary physiological information.

[0153] In Example 144, the subject matter of any one or more of Examples 142 - 143 optionally includes that the primary subsystem includes a continuous glucose monitor (CGM), and the guidance system is further configured to determine the patient state at least partially based on the secondary data and the relationship between the secondary data and the primary physiological information.

[0154] In Example 145, the subject matter of Example 144 optionally includes that the patient state includes an estimated glucose concentration value.

[0155] In Example 146, the subject matter of any one or more of Examples 144 - 145 optionally includes that the patient state includes an in - range time metric indicating an estimated amount or percentage of time during a specified period that the glucose concentration value was within a range.

[0156] In Example 147, the subject matter of any one or more of Examples 142 - 146 optionally includes that the secondary subsystem includes a sensor and a memory circuit, and the secondary subsystem is further configured to determine secondary data from the sensor data received from the sensor and store the sensor data or the secondary data in the memory circuit.

[0157] In Example 148, for any one or more of the themes of Examples 142-147, the primary subsystem includes a continuous glucose monitor (CGM) and a memory circuit, the primary subsystem is configured to receive a CGM sensor signal indicating glucose concentration within a host, determine an estimated glucose concentration value based at least in part on the CGM sensor signal, and store a plurality of estimated glucose concentration values in the memory circuit, and the primary physiological information optionally includes a plurality of estimated glucose concentration values or is based on a plurality of estimated glucose concentration values.

[0158] Example 149 is a computer-readable medium including instructions that, when executed by at least one processor, cause the at least one processor to perform operations including receiving an estimated glucose concentration value of a patient from a continuous glucose monitoring (CGM) system over a first period, receiving non-glucose information regarding the patient for the first period, determining a relationship between the estimated glucose concentration value and the non-glucose information, receiving non-glucose information regarding the patient for a second period, determining diabetic condition information regarding the patient for the second period based on the determined relationship and the non-glucose information, and electronically delivering a notification regarding the diabetic condition information.

[0159] In Example 150, for the theme of Example 149, the operations further include receiving a plurality of estimated glucose concentration values from the CGM system from the first period, and optionally, receiving at least one single-point glucose measurement value obtained during the first period for receiving non-glucose information for the first period.

[0160] In Example 151, for any one or more of the themes of Examples 149-150, the operations optionally further include determining guidance based at least in part on the diabetic condition information and displaying the guidance on a user interface.

[0161] In Example 152, any one or more of the themes of Examples 149-151 optionally includes receiving second non-glucose information related to a patient for a first period, the second non-glucose information being different from the non-glucose information, and the relationship being between an estimated glucose concentration value, the non-glucose information, and the second non-glucose information.

[0162] Example 153 is a patient management system comprising an analyte sensor and a processor that executes instructions to perform operations, the operations including receiving, by a first application executed on the processor, sensor data from the analyte sensor indicative of a user's analyte concentration; transmitting, by the first application, a sensor message including a display of the analyte concentration to a second application executed on the processor; and delivering, by the second application, a device message to a wearable activity monitoring device, the device message being at least partially based on the analyte concentration.

[0163] In Example 154, the theme of Example 153 optionally includes a wearable activity monitoring device, the wearable activity monitoring device comprising a motion sensor, and the wearable activity monitoring device being programmed to generate a user interface including data at least partially based on the device message and data at least partially based on an output of the motion sensor.

[0164] In Example 155, any one or more of the themes of Examples 153-154 further includes generating physiological state data that describes an estimated value of a user's physiological state, the generating optionally including being at least partially based on the user's analyte concentration.

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

[0166] In Example 157, any one or more of the subjects of Examples 155 - 156 optionally include that physiological state data is generated by a second application and the device message includes the physiological state data.

[0167] In Example 158, any one or more of the subjects of Examples 155 - 157 optionally include that the physiological state data includes an in - range time, a glucose concentration value, or a glucose concentration range.

[0168] In Example 159, any one or more of the subjects of Examples 155 - 158 optionally include that generating the physiological state data is based on a correlation between previously collected glucose concentration information and previously collected activity information.

[0169] In Example 160, any one or more of the subjects of Examples 153 - 159 optionally include that the device message includes display data for display on a user interface of a wearable activity monitoring device.

[0170] In Example 161, any one or more of the subjects of Examples 153 - 160 optionally include that generating the sensor message includes encrypting the display of the analyte concentration.

[0171] In Example 162, any one or more of the subjects of Examples 153 - 161 optionally include that generating the sensor message includes generating an error detection code based at least in part on the analyte concentration.

[0172] Example 163 is a patient management method that includes receiving, by a first application executed in a patient management system, sensor data indicating a user's analyte concentration from an analyte sensor; transmitting, by the first application, a sensor message including a display of the analyte concentration to a second application executed in the patient management system; and delivering, by the second application, a device message to a wearable activity monitoring device, the device message being at least partially based on the analyte concentration.

[0173] In Example 164, the subject matter of Example 163 optionally further includes generating, by the wearable activity monitoring device, a user interface that includes data at least partially based on the device message and data at least partially based on an output of a motion sensor, where the wearable activity monitoring device includes the motion sensor.

[0174] In Example 165, the subject matter of any one or more of Examples 163 - 164 includes generating physiological state data that describes an estimated value of a user's physiological state, optionally including that the generating is at least partially based on the user's analyte concentration.

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

[0176] In Example 167, any one or more of the subject matter of Examples 165 - 166 optionally includes that the physiological state data is generated by the second application and the device message includes the physiological state data.

[0177] In Example 168, the subject matter of any one or more of Examples 165 - 167 optionally includes that the physiological state data includes in - range time, glucose concentration value, or glucose concentration range.

[0178] In Example 169, any one or more of the themes of Examples 165 - 168 optionally include that generating physiological state data is based on a correlation between previously collected glucose concentration information and previously collected activity information.

[0179] In Example 170, any one or more of the themes of Examples 163 - 169 optionally include that the device message includes display data for display on a user interface of a wearable activity monitoring device.

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

[0181] Example 172 is a machine - readable medium including instructions that, when executed by at least one processor, cause the at least one processor to perform operations including receiving, by a first application executed in a patient management system, sensor data indicating a user's analyte concentration from an analyte sensor; transmitting, by the first application, a sensor message including a display of the analyte concentration to a second application executed in the patient management system; and delivering, by the second application, a device message to a wearable activity monitoring device, the device message being based at least in part on the analyte concentration.

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

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

[0184] In Example 175, the subject matter of any one or more of Examples 173 to 174 optionally includes that the low-fidelity monitoring technique includes at least one of single-point glucose monitoring, blind continuous glucose monitoring, or optical monitoring techniques.

[0185] In Example 176, the subject matter of any one or more of Examples 173 to 175 optionally includes that the low-fidelity monitoring technique includes activity monitoring by a wearable fitness tracker.

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

[0187] In Example 178, the subject matter of any one or more of Examples 173 to 177 optionally includes that the low-fidelity monitoring technique includes receiving user input data including at least one of drug data, meal data, exercise data, or sleep data.

[0188] In Example 179, any one or more of the themes of Examples 173 to 178 optionally includes determining a goal for the patient, and the parameters of the continuous glucose monitoring device are related to the goal.

[0189] In Example 180, the theme of Example 179 optionally includes that the goal optionally includes a dietary goal, an exercise goal, a glucose value monitoring goal, or a medication goal.

[0190] In Example 181, any one or more of the themes of Examples 179 to 180 optionally includes that determining a goal for the patient is at least partially based on first type of data monitored over a first period using a low-fidelity monitoring technique.

[0191] In Example 182, any one or more of the themes of Examples 173 to 181 optionally includes at least partially determining the parameters of the continuous glucose monitoring device by determining at least one parameter for an automatic coaching routine.

[0192] In Example 183, any one or more of the themes of Examples 173 to 182 optionally includes detecting a change in patient parameters between a first period and a second period and using the detected change in patient parameters to determine the parameters of the continuous glucose monitoring device.

[0193] In Example 184, any one or more of the themes of Examples 173 to 183 optionally includes providing a coaching function to the patient over a first period, the coaching function including an automatic message transmitted from a server to the continuous glucose monitoring device, and the coaching function being based on patient profile data or first type of patient data, or a combination thereof.

[0194] Example 185 is a system comprising a low-fidelity system configured to collect a first type of first sensor dataset regarding a patient over a first period, a continuous glucose monitoring device configured to collect a second type of second sensor dataset regarding the patient, and a determination system configured to determine parameters of the continuous glucose monitoring device based on the first sensor dataset.

[0195] In Example 186, the subject matter of Example 185 optionally includes that the low-fidelity system includes an activity sensor.

[0196] In Example 187, the subject matter of any one or more of Examples 185-186 optionally includes that the low-fidelity system includes a blood glucose meter.

[0197] In Example 188, the subject matter of any one or more of Examples 185-187 optionally includes that the low-fidelity system includes a continuous glucose monitor.

[0198] In Example 189, the subject matter of any one or more of Examples 185-188 optionally includes that the parameters include a usage schedule of the continuous glucose monitoring device.

[0199] In Example 190, the subject matter of any one or more of Examples 185-189 optionally includes that the parameters are the start time of using the continuous glucose monitoring device.

[0200] In Example 191, the subject matter of any one or more of Examples 185-190 optionally includes a third system configured to collect a third sensor dataset regarding the patient, and the determination system determines the parameters based at least in part on the first sensor dataset and the third sensor dataset.

[0201] Example 192 is a machine-readable medium including instructions that, when executed by at least one processor, cause the at least one processor to perform operations, the operations including monitoring first type of patient data using a low-fidelity monitoring technique over a first period, evaluating patient behavior based on the monitored first type of patient data, and monitoring second type of patient data using a continuous glucose monitoring device over a second period, wherein parameters of the continuous glucose monitoring device are based on the evaluated patient behavior being monitored.

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

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

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

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

[0206] In Example 197, any one or more of the themes of Examples 193 to 196 optionally include detecting that the analyte sensor system has been applied to a host, including determining that the analyte sensor system has provided sensor measurement values exceeding a threshold.

[0207] In Example 198, any one or more of the themes of Examples 193 to 197 optionally include detecting that the analyte sensor system has been applied to a host, including determining that the analyte sensor system has provided sensor measurement values exceeding a threshold for a time longer than a threshold time.

[0208] In Example 199, any one or more of the subjects of Examples 193 to 198 optionally includes that determining that the use of the sensor in the analyte sensor system has ended includes determining that a time longer than a threshold time has elapsed since the analyte sensor system was applied to the host.

[0209] In Example 200, any one or more of the subjects of Examples 193 to 199 optionally includes uploading the stored analyte sensor data to a server system by an upload computing device.

[0210] 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 the 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 to an upload computing device by the analyte sensor system.

[0211] In Example 202, the subject of Example 201 optionally further includes operations including broadcasting system identification data by the analyte sensor system after determining that the use of the sensor in the analyte sensor system has ended, receiving a communication request including the system identification data from the upload computing device by 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, and the uploading is performed using the communication session.

[0212] In Example 203, any one or more of the themes of Examples 201-202 optionally include an operation further including receiving an upload request from an upload computing device by the analyte sensor system and receiving authentication data from the upload computing device after it is determined that the use of the sensor in the analyte sensor system has ended.

[0213] In Example 204, any one or more of the themes of Examples 201-203 optionally include an operation further including receiving an upload request from an upload computing device by the analyte sensor system, broadcasting system identification data by the analyte sensor system, receiving authentication data from the upload computing device, and establishing a communication session with the upload computing device by the analyte sensor system, where uploading includes transmitting stored analyte data to the upload computing device.

[0214] In Example 205, any one or more of the themes of Examples 201-204 optionally include detecting that the analyte sensor system has been applied to a host, including determining that the analyte sensor system has provided sensor measurement values exceeding a threshold.

[0215] In Example 206, any one or more of the themes of Examples 201-205 optionally include detecting that the analyte sensor system has been applied to a host, including determining that the analyte sensor system has provided sensor measurement values exceeding a threshold for a time longer than a threshold time.

[0216] In Example 207, any one or more of the themes of Examples 201 - 206 optionally includes that determining that the use of the sensor in the analyte sensor system has ended includes determining that a time longer than a threshold time has elapsed since the analyte sensor system was applied to the host.

[0217] In Example 208, any one or more of the themes of Examples 201 - 207 optionally includes an upload computing device, which is configured to perform operations including uploading stored analyte sensor data to a server system.

[0218] Example 209 is a machine - readable medium including instructions that, when executed by at least one processor, cause the at least one processor to perform operations including detecting that the analyte sensor system has been applied to the host, storing analyte data describing the host, 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.

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

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

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

[0222] This summary is intended to illustrate the general nature 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 about the patent application. Other aspects of the disclosure will be apparent to those skilled in the art upon reading and understanding the detailed description, and upon viewing the drawings that form a part thereof, and these drawings should not be construed in a limiting sense.

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

Brief Description of the Drawings

[0224]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8A

Figure 8B

Figure 8C

Figure 9

Figure 10

Figure 11

Figure 12A

Figure 12B

Figure 12C

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22A

Figure 22B

Figure 22C

Figure 23

Figure 24

Figure 25

Figure 26A

Figure 26B

Figure 27

Figure 28

Figure 29

Figure 30

Figure 31

Figure 32

Figure 33

Figure 34

Figure 35

Figure 36

Figure 37

Figure 38

Figure 39

Figure 40

Figure 41

Best Mode for Carrying Out the Invention

[0225] The inventors have recognized that, in particular, patients can be beneficially monitored or managed using a combination of techniques having different information collection patterns. Typically, to improve patient management, higher fidelity and larger amounts of data are desirable 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 (e.g., correlations between data types), to guide patient management. For example, the relationship 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 embodiments, analyte information that is automatically collected from a host by a sensor based on a schedule, such as glucose information automatically collected by a glucose sensor (“continuous glucose monitoring,” or “CGM”), can be correlated with other types of information (e.g., activity captured by a wearable activity sensor), enabling the estimation of an estimated glucose concentration value (or value of another analyte) based on the correlation. In some examples, two or more types of data (e.g., CGM data and activity data) can be collected from a patient, and the data obtained during the collection period of both CGM data and activity data can be used to develop or adjust a system or algorithm to infer a first type of data (e.g., glucose concentration value) from a second type of data (e.g., activity or heart rate), or from a second type of data and auxiliary inputs (e.g., administration of a drug or ingestion of a meal). In other words, a non-CGM sensor system can be “calibrated” to an estimated glucose value using simultaneously acquired CGM data and non-CGM data. In some examples, continuous glucose monitoring can be performed intermittently, and during the collection period, glucose concentration values can be collected according to a schedule (e.g., every 5 minutes), but the collection of CGM data can be performed only during a specific period, such as when the patient is wearing an activated CGM sensor, which can be, for example, once a month or once every three months for one week or ten days.

[0226] In some examples, the need or desire to perform the collection of a second type of data (e.g., the collection of intermittent CGM data) or collection parameters (e.g., the periodicity of intermittent collection) can be determined based on a first type of data (e.g., blood glucose meter data or activity data). In some examples, the relationship or manner of intermittent collection can be used to determine the collection parameters of different monitoring techniques. For example, CGM data can be used to determine the test times or test schedules of one or more blood glucose meters. In another example, the test results of a blood glucose meter or activity data can be used to determine the CGM monitoring mode (e.g., the schedule of intermittent CGM data collection, or the number of sensors used in CGM monitoring). In some examples, oral drug therapy or infusion insulin therapy (e.g., basal insulin) can be determined (or evaluated or redetermined) based, at least in part, on CGM information such as intermittent CGM monitoring. CGM information is referred to herein as an example, but the described examples are also applicable to other types of analytes (e.g., references to continuous glucose monitoring can generally be applied to continuous analyte monitoring).

[0227] Summary Patient management can be more effective when informed by timely information about the patient. For example, physiological information, environmental information, or behavioral information can be used to determine guidance for the patient (e.g., dietary or exercise guidance) or treatment (e.g., an oral medication regime), or to determine changes or improvements to the patient management approach. Patients with blood glucose management conditions such as type 2 diabetes can particularly benefit from patient management approaches that use timely information. Some monitoring systems or devices, such as continuous glucose monitors, can provide strong signals regarding the patient's glucose management condition (e.g., high glucose concentration values, normal values, or low values), but continuous use of such systems may be undesirable due to cost (e.g., the cost of CGM sensors and monitoring) or the burden on the patient (e.g., the need to wear and manage a CGM on the body). Other systems and devices (e.g., wearable activity monitors, smartwatches, smartphones) can be less burdensome or less expensive, but tend to provide information that may have less of a direct relationship to blood glucose values. For example, activity can tend to be helpful in managing blood glucose values, but the actual blood glucose concentration value cannot be easily inferred from activity information alone, and the impact of activity on blood glucose can vary widely between patients or between patient types (e.g., between subgroups within a population).

[0228] To balance the need for accurate information about costs and glucose management, different types of patient data can be collected over one or more overlapping periods, enabling the determination of patient management information based on the relationships between different types of data. Such relationships can be used to guide patient management when one of the types of data is unavailable. For example, a continuous glucose monitor and an activity monitor can be used during an overlapping period, and the relationship between glucose concentration values and activity information can be learned from CGM data and activity data. In some examples, the user can be instructed to continuously wear an activity sensor (e.g., a wristwatch) (e.g., for a period of at least daily), and the user can be instructed to wear a continuous glucose sensor over a specified period (e.g., a two-week test period) or continuously (e.g., for a two-week period every three months). The data can be collected by the system (e.g., using a mobile device and a server) and analyzed to determine the relationship between glucose values and activity. In various embodiments, the activity can correlate with a glucose concentration or range, or with an impact on glucose concentration (e.g., a certain amount of activity can vary based on glucose values due to lower insulin sensitivity (i.e., insulin resistance) at higher glucose values, causing a strong impact on glucose), or with a glucose value trend (e.g., the rate of change of glucose values related to the amount, intensity, or type of activity), any of which can be used to infer an estimated glucose concentration value (e.g., 120 mg / dL), a range (e.g., 120 - 160 mg / dL), a status (e.g., outside or within a target range), or other estimated values for glucose value management. One or more of these glucose estimates, or information based on the estimates (e.g., time within a range in a day), can be delivered to the patient, and in various embodiments, can be done in real-time, on demand, or iteratively (e.g., every hour, daily, weekly, three times a day, or before or after meals).

[0229] 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 time (e.g., to enable matching of CGM data with corresponding activity data), location, day of the week, patient input data (e.g., meals or activities), or other information. Correlation with time, location, day of the week, patient input data, or other information can also be used to determine relationships between data types.

[0230] In some embodiments, the 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 management estimates (e.g., estimated glucose values, ranges, or states). In some embodiments, the system can construct population cohorts segmented by glucose profile behavior, and users who match a particular cohort can receive statistical feedback. Based on this type of population information, glucose estimates can be used to determine population-based guidance, and this guidance can be delivered to the patient (e.g., presented on a smart device). For example, a patient may receive guidance such as "70% of people like you are estimated to be out of range around this time. Have you considered taking a walk?"

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

[0232] Certain types of patient management information (e.g., CGM data and activity data) may be the subject of a particular example for illustrative purposes, but the techniques, methods, and systems described herein can be applied to different types of analytes to be monitored (other than glucose), or different types of physiological information (e.g., heart rate, respiration, electrodermal response or other skin qualities, blood ketones, urine ketones, oxygen concentration), or several types of peripheral information (e.g., location, environment, temperature), and other different types of information. It should be understood that the relationships between two or more types of information can be used to determine health (e.g., diabetes) information about a patient when one or more types of information are not available.

[0233] Exemplary System FIG. 1 is a diagram of an exemplary system 100 that may include various sensor systems of a device. System 100 may include an analyte sensor system 102 that can be coupled to a host 101. The host 101 can be a human patient. The patient can be subject to a temporary or permanent diabetic condition or other health condition for which data-driven patient management or analyte monitoring may be useful.

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

[0235] The analyte sensor system 102 may also include sensor electronics 106. In some embodiments, the analyte sensor 104 and the sensor electronics 106 may be provided as an integrated package. In other embodiments, the analyte sensor 104 and the 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 that may include the analyte sensor 104, components 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 that may include some or all of the sensor electronics 106 shown in FIG. 2. The sensor electronics package may be reusable.

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

[0237] The analyte sensor 104 can be, for example, a continuous glucose sensor and can include, for example, a subcutaneous device, a transdermal (e.g., transcutaneous) device, or an intravascular device. In some embodiments, such sensors or devices can analyze sensor data repeatedly (e.g., periodically or intermittently). The glucose sensor can use any glucose measurement method, such as an enzymatic method, a chemical method, a physical method, an electrochemical method, a spectrophotometric method, a polarimetric method, a calorimetric method, an iontophoresis method, a radiometric method, an immunochemical method, etc. In various examples, the analyte sensor system 102 can be, or can include, a continuous glucose monitor sensor available from DexCom (e.g., DexCom G5™ sensor or DexCom G6™ sensor or any variation thereof), Abbott (e.g., Libre™ sensor), or Medtronic™ (e.g., Enlight™ sensor).

[0238] In some examples, the analyte sensor 104 can be an implantable glucose sensor as described in U.S. Patent No. 6,001,067 and U.S. Patent Application Publication No. 2005-0027463(A1). In some examples, the analyte sensor 10 can be a transcutaneous glucose sensor as described in U.S. Patent Application Publication No. 2006-0020187(A1). In some examples, the analyte sensor 10 can be configured to be implanted within or outside the host's blood vessels, for example, as described in U.S. Patent Application Publication Nos. 2007-0027385(A1), co-pending U.S. Patent Application Publication No. 2008-0119703(A1) filed on Oct. 4, 2006, U.S. Patent Application Publication No. 2008-0108942(A1) filed on Mar. 26, 2007, and U.S. Patent Application Publication No. 2007-0197890(A1) filed on Feb. 14, 2007. In some examples, the continuous glucose sensor can include a transcutaneous sensor as described in, for example, U.S. Patent No. 6,565,509 (Say et al.). In some examples, the analyte sensor 10 can be a continuous glucose sensor including a subcutaneous sensor as described in, for example, U.S. Patent No. 6,579,690 (Bonnecaze et al.) or U.S. Patent No. 6,484,046 (Say et al.). In some examples, the continuous glucose sensor can include a refillable subcutaneous sensor as described in, for example, U.S. Patent No. 6,512,939 (Colvin et al.). The continuous glucose sensor can include an intravascular sensor as described in, for example, U.S. Patent No. 6,477,395 (Schulman et al.). The continuous glucose sensor can include an intravascular sensor as described in, for example, U.S. Patent No. 6,424,847 (Mastrototaro et al.).

[0239] System 100 may also include a second medical device 108, which may be, or include, for example, a wearable monitor or a drug delivery device. For example, the second medical device 108 may be, or include, a drug delivery device such as an insulin pump or an insulin pen, or a 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., for capturing body sounds such as ambient sounds or breathing), or another analyte sensor. In some examples, the medical device 108 may be attachable to, for example, a wristwatch, glasses, contact lenses, a patch, a wristband, an 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 multi-sensor patch that can detect one or more of, for example, analyte values (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), electrodermal response, tissue fluid values (e.g., using impedance or pressure).

[0240] 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 a radio frequency (e.g., Bluetooth®, Bluetooth Low Energy (LE), Medical Implant Communication System (MICS), Wi-Fi®, NFC, RFID, Zigbee, Z-Wave, or other communication protocol), optical (e.g., infrared), acoustic (e.g., ultrasonic), or cellular protocol (e.g., Code Division Multiple Access (CDMA) or Global System for Mobiles (GSM)), or a wired connection (e.g., serial, parallel, etc.).

[0241] System 100 may also include a wearable sensor 130 that may include a sensor circuit (e.g., a sensor circuit configured to detect glucose concentration or other analyte concentration) and a communication circuit (e.g., which may be a near field communication (NFC) circuit). In some examples, information from the wearable sensor 130 can be retrieved from the wearable sensor 130 using a user device 132, such as a smartphone, configured to communicate with the wearable sensor 130 via NFC when the user device 132 is placed near the wearable sensor 130 (e.g., by swiping the user device 132 above the sensor to retrieve sensor data from the wearable sensor using NFC). By using NFC communication, power consumption by the wearable sensor can be reduced, thereby reducing the size of a power source (e.g., a battery or capacitor) within the wearable sensor or extending the usable time of the power source. In some examples, the wearable sensor 130 can be wearable on the upper arm, as shown. In some examples, the wearable sensor 134 can additionally or alternatively be on the patient's upper torso (e.g., above the heart or lungs), which can facilitate detection of, for example, heart rate, respiration, or posture. Also, the wearable sensor 136 can be on the lower body (e.g., the leg).

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

[0243] 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 120 such as a wearable device, or a peripheral medical device 122 (which may be a patented device such as a user device available from DexCom). Any of these can communicate with the analyte sensor system 102 via a wireless communication signal and can 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 a remote user (not shown), such as a technical support staff member or a clinician.

[0244] The wearable device 120 may include an activity sensor, a heart rate monitor (e.g., an optical-based sensor or an electrode-based sensor), a respiratory sensor (e.g., an acoustic-based sensor or an electrode-based sensor), a position sensor (e.g., GPS), or other sensors.

[0245] System 100 may also include a wireless access point (WAP) 138 that can be used to communicatively couple 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 any of the peripheral devices described above. For example, the WAP 138 may provide Wi-Fi and / or cellular connectivity within the system 100. Other communication protocols (e.g., near field communication (NFC) or Bluetooth, etc.) can also be used between the devices of the system 100.

[0246] In some examples, the first server system 125 can be used to collect analyte data from the analyte sensor system 102 and / or one or more other devices, perform an analysis on the collected data, generate or apply a general or individual model to glucose values, and communicate such analysis, model, or information based thereon back to one or more devices within the system 100. The system can include one or more additional servers 126, 127. For example, the first server system 125 can process CGM data (e.g., receive, store, or transmit it), and the second server system 126 can accommodate general patient information or medical data (e.g., insurance information). The first server system 125 or the second server system 126 can include a decision support system, which can determine guidance for a patient and determine an estimated blood glucose value (e.g., based on alternative data) or determine other information (e.g., correlation with other types of information) using, for example, any of the various techniques described herein. The guidance, glucose concentration value, or other information can be transmitted via the network 124 and delivered to a patient device or caregiver device such as the handheld device 112 or the tablet 114. In some examples, the CGM information can be delivered to a patient device (such as the 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, which is published as U.S. Patent Application Publication No. 20170293732(A1) and is incorporated by reference.

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

[0248] In some examples, one smart device may collect information from another smart device. For example, the handheld device 112 may collect activity information from the wearable device 120. In some examples, the correlation between types of data (described further below) may be determined by a smart device, or by a server (e.g., server 125), or by both or a combination thereof.

[0249] FIG. 2 is a schematic diagram of various exemplary electronic components that can be part of a medical device system 200. In one example, the system can include a sensor electronics 106 and a base 290. Although specific examples of the component division between the base and the sensor electronics are shown, in some examples, the base 290 or the sensor electronics 106 can include additional components, and some of the components shown in the sensor electronics 106 can alternatively or additionally (e.g., redundantly) be provided in the base. In one example, the base 290 can include an analyte sensor 104 and a battery 292. In some examples, the base can be replaceable, and the sensor electronics 106 can include a debounce circuit (e.g., a gate with hysteresis or delay) to avoid repeatedly performing power-up or power-down processes when the battery attachment and detachment are repeated, or to avoid processing noise signals associated with battery removal or replacement.

[0250] The sensor electronics 106 can include electronic components configured to process sensor information such as sensor data and generate the converted sensor data and displayable sensor information. The sensor electronics 106 can include, for example, electronic circuits related to the measurement, processing, storage, or communication of continuous analyte sensor data, including prediction algorithms associated with the processing and calibration of sensor data. The sensor electronics 106 can include hardware, firmware, and / or software that enables the measurement of analyte values via a glucose sensor. The electronic components can be attached to, for example, a printed circuit board (PCB) and can take various forms. For example, the electronic components can take the form of integrated circuits (ICs) such as application-specific integrated circuits (ASICs), microcontrollers, and / or processors.

[0251] As shown in FIG. 2, the sensor electronics 106 may include a potentiostat 202, which is coupled to the analyte sensor 104 and may be configured to repeatedly obtain analyte sensor measurements using the analyte sensor by, for example, continuously or repeatedly applying a voltage bias across the entire sensor electrode and measuring the current indicative of the analyte concentration. The sensor electronics may also include a processor 204, which may retrieve instructions 206 from the memory 208, execute the instructions, and determine the controlled application of the bias potential to the analyte sensor 104 via the potentiostat, interpret signals from the sensor, or compensate for environmental factors. Also, the processor may store information in the data storage memory 210 or retrieve information from the data storage device 210. In various examples, the data storage memory 210 may be integrated with the 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 analyte data of sensors are described in more detail herein and in U.S. Patent Nos. 7,310,544 and 6,931,327.

[0252] The sensor electronics 106 may also include a sensor 212 that may 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 a battery 214, which may be integrated with the sensor electronics, removable, or part of a separate electronic device package. The battery 214 (or other power storage component, e.g., a capacitor) may optionally be rechargeable via a wired or wireless (e.g., inductive or ultrasonic) recharge system 216. The recharge system may collect energy or receive energy from an external source or an on-board source. In various examples, the recharge circuit may include a circuit that collects energy from a triboelectric charging circuit, a piezoelectric charging circuit, an RF charging circuit, an optical charging circuit, an ultrasonic charging circuit, a thermal charging circuit, a thermoelectric harvesting circuit, or a communication circuit. In some examples, the recharge circuit may recharge a rechargeable battery using power supplied from a replaceable battery (e.g., a battery supplied with a base component).

[0253] In addition, the sensor electronic device 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 the processor and may be configured to wirelessly communicate with one or more peripheral devices such as an insulin pump or a smart insulin pen and other medical devices.

[0254] The peripheral device 250 may be a wearable device (e.g., an activity monitor) such as the wearable device 120. In other examples, the peripheral device 250 may be the handheld device 112 shown in FIG. 1 (e.g., a smartphone or other device such as a handheld device of a patented product available from Dexcom), the tablet 114, the smart pen 116, or the dedicated computer 118.

[0255] 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 source 262 (e.g., a battery or a capacitor), or any combination thereof. The peripheral device does not necessarily include all of the components shown in FIG. 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, which may receive information (e.g., glucose values) from the user or distribute information such as glucose values, glucose trends (e.g., arrows, graphs, or charts), or glucose alerts to the user. 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 obtain information such as communication information (e.g., pairing information or access information to a data center), user information, sensor data, or trends in the memory circuit 254. The wireless circuit communication circuit 258 may include a transceiver and an antenna configured to communicate via a wireless protocol such as Bluetooth, MICS, or any of the other options described herein. The sensor 260 may include, for example, an accelerometer (e.g., within an activity monitor such as a wristwatch), a temperature sensor, a position sensor, a biosensor, or a blood glucose sensor, a blood pressure sensor, a heart rate sensor, a respiratory sensor, or another physiological sensor. The device may include a plurality of different types of sensors.

[0256] The peripheral device 250 can be configured to receive and display sensor information that can be transmitted by the sensor electronics 106 (e.g., in a customized data package transmitted to a display device based on respective basic settings). Sensor information (e.g., a blood glucose concentration value) or an alert or notification (e.g., "high glucose value", "low glucose value", or "decrease rate alert") can be communicated via the user interface 252 (e.g., via visual display, sound, or vibration). In some examples, the peripheral device 250 can be configured to display or otherwise communicate sensor information communicated from the sensor electronics module (e.g., in a data package transmitted to respective display devices). For example, the peripheral device 250 can transmit processed data (e.g., an estimated analyte concentration value that can be determined by processing raw sensor data), such that a device receiving the data may not need to further process the data to obtain usable information (such as an estimated analyte concentration value). In other examples, the peripheral device 250 can process or interpret the received information (e.g., to issue an alert based on a glucose value or glucose trend). In various examples, the peripheral device 250 can receive information directly from the sensor electronics 106 or over a network (e.g., via a cellular or Wi-Fi network that receives information from the sensor electronics or from a device communicatively coupled to the sensor electronics 106).

[0257] Referring again to FIG. 2, the medical device 270 can 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 of the components shown in FIG. 2. For example, the medical device may not include the user interface 272, or may not include the treatment circuit 282, or may not include the sensor 280.

[0258] The user interface 272 may include, for example, a touch screen interface, a microphone, or a speaker, a vibration circuit, or any combination thereof, which may receive information from the user (e.g., glucose value, alert setting, calibration coding), or may deliver information such as glucose value, glucose trend (e.g., arrow, graph, or chart), or glucose alert to the user. The processor 276 may be configured to present information to the user or receive input from the user via the user interface 272. Also, the processor 276 may be configured to store and retrieve information such as communication information (e.g., pairing information and access information to the data center), user information, sensor data, or trends in the memory circuit 274. The wireless circuit communication circuit 278 may include a transceiver and an antenna configured to communicate via a wireless protocol such as Bluetooth, Medical Implant Communication System (MICS), Wi-Fi, Zigbee, or a cellular protocol (e.g., Code Division Multiple Access (CDMA) or Global System for Mobiles (GSM)). The sensor 280 may include, for example, an accelerometer, a temperature sensor, a position sensor, a biosensor, or a blood glucose sensor, a blood pressure sensor, a heart rate sensor, a respiration sensor, or another physiological sensor. Although only one sensor is shown in the example of FIG. 2, the medical device 270 may include two or more sensors (or memories 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 other physiological sensor device (e.g., the wearable device 120), a treatment device, or a combination thereof. In various examples, the medical device 270 may be the medical device 108, the peripheral device 122, the wearable device 120, the wearable sensor 130, the wearable sensor 134, or the wearable sensor 136 shown in FIG. 1.In an example where the medical device 270 is an insulin pump, can the pump and the analyte sensor system communicate bidirectionally (e.g., the pump can request a change to the analyte transmission protocol, e.g., request data points or request data on a more frequent schedule), or can the pump and the analyte sensor system communicate using unidirectional communication (e.g., the pump can receive information on analyte concentration values from the analyte sensor system). In unidirectional communication, glucose values may be incorporated into an advertisement message and encrypted with a pre-shared key. In bidirectional communication, the pump can request values that the analyte system can share in response to requests from the pump or obtain and share, and any or all of these communications may be encrypted using one or more pre-shared keys. The insulin pump can receive and track values of an analyte (e.g., glucose) transmitted from the analyte sensor system 102 using unidirectional communication to the pump for one or more of a variety of reasons. For example, the insulin pump can interrupt or initiate insulin administration based on glucose values that are below or above a threshold.

[0259] In some examples, the system 100 shown in FIG. 1 may include two or more peripheral devices, each receiving information directly or indirectly from the analyte sensor system 102. Because the user interface can vary depending on the display device, the content of the data package (e.g., the amount, format, and / or type of data displayed, alarms, etc.) can be customized for each particular device (e.g., programmed differently for different manufacturers and / or end users). For example, in the embodiment of FIG. 1, multiple different peripheral devices can communicate directly wirelessly with a sensor electronics module (e.g., the on-skin sensor electronics 106 physically connected to the continuous analyte sensor 104) during a sensor session to enable displays and / or functions of multiple different types and / or values related to sensor information that can be displayed, or can conserve battery power of the sensor system 102, and one or more designated devices can communicate with the analyte sensor system and relay (i.e., share) information directly or via a server system (e.g., a data center connected to a network) 125 to other devices.

[0260] FIG. 3 is a table 301 showing exemplary patient states 305, physiological conditions 310, and exemplary treatments 315. This table is configured to reflect a typical progression of a patient from a normal state to prediabetes and ultimately to a diabetic state (e.g., type 2 diabetes), and the progression can occur over days, weeks, months, or years, depending on the situation. The placement of the states, conditions, and treatments in the table is provided for illustrative purposes and may not be the same for each patient. In some patients, insulin resistance or insufficient insulin production by pancreatic beta cells can contribute to the patient's progression to prediabetes and ultimately to type 2 diabetes. Type 2 diabetes and high blood glucose levels are associated with risks of myocardial infarction, stroke, vascular problems, and death.

[0261] A patient in a normal state may not have a physiological state with a problem to be managed, and as a result, may not require treatment. A patient can become insulin resistant due to one or more of various factors such as age, diet, lifestyle, pregnancy, genetic factors, or other factors.

[0262] When a patient becomes insulin resistant, the patient may begin to experience values higher than the normal blood levels of insulin, known as "hyperinsulinemia". To manage hyperinsulinemia and insulin resistance, a patient can initiate a patient management regimen that may include improvements in diet and exercise, such as the intake of fewer calories or fewer carbohydrates (especially simple sugars and other carbohydrates that can be rapidly processed into glucose by the body), and an increase in activity or exercise volume.

[0263] As the patient's condition worsens, the patient may produce blood glucose concentration values higher than normal, which is known as "hyperglycemia". For example, a patient may initially exhibit postprandial hyperglycemia, where the glucose value spikes to a higher value than normal after a meal and then tends to decline over time after the meal. Glucose values that are higher than normal but not high enough to result in a diagnosis of type 2 diabetes may be referred to as "impaired glucose tolerance". A patient continues to improve diet and exercise to address postprandial hyperglycemia or impaired glucose tolerance, and the patient may also be prescribed oral medications. Oral medications can, for example, stimulate the production of insulin by pancreatic β-cells (e.g., sulfonylureas or meglitinides), reduce glucose production by the liver (e.g., biguanides), improve the action of blood insulin (e.g., thiazolidinediones), reabsorb glucose in the kidneys (e.g., SGLT2 inhibitors), block the breakdown of starch in the intestine (e.g., α-glucosidase inhibitors), or prevent the breakdown of glucose-lowering compounds (e.g., DPP-4 inhibitors). Other oral medications and combinations of complementary or compatible agents are also possible treatments.

[0264] Impaired glucose tolerance may progress to impaired fasting glucose, and patients may have abnormally high glucose concentration values 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 with diet and exercise therapy as well as oral medications. Patients may also be prescribed insulin to attempt to lower glucose levels.

[0265] Information about the 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 generate guidance for the patient regarding the patient's health management. Information about the patient can be of a specific physiological type (e.g., glucose information, heart rate information, respiration information, pulse information, etc.).

[0266] Despite efforts to manage glucose levels or insulin levels, the condition of some patients may continue to deteriorate and may ultimately progress to type 2 diabetes. For example, if the fasting (nighttime) glucose level is 126 mg / dL or higher, the patient may be considered to have type 2 diabetes. Some patients may continue to have increasing glucose levels and may further progress to diabetes, tending to increase the risk of complications such as cardiovascular disease, vascular problems, or stroke.

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

[0268] In some examples, a continuous glucose monitor (or other physiological sensor) may be used over a test period (e.g., 3 days, 7 days, 10 days, 14 days, 30 days, or 3 months). In some examples, information regarding management of glucose values may be learned from the test period. Information learned from the test period may optionally be 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 an NFC-enabled sensor, optical glucose data, or glucose information collected using another technique), and then applied to better manage the patient's condition. For example, the relationship between a patient's activity or behavior (estimated from activity, location, heart rate, or user input information, or other information) with respect to the patient's glucose concentration value may be learned during the test period, and this relationship may be used later to determine guidance for the patient.

[0269] In some cases, a continuous glucose monitor may be used intermittently. For example, glucose concentration values may be collected from a patient using a continuous glucose monitor for a specified number of days, weeks, or a series of days (e.g., 10 days) specified per a designated schedule, such as quarterly, monthly, or annually. The intermittently collected CGM information may be used to actively manage (e.g., in real time) the glucose values, or to update or refine a learned relationship between the estimated glucose values from the CGM and other information such as activity.

[0270] FIG. 4 is a flowchart diagram of a method 401 for progressing from a low-fidelity data collection technique to a high-fidelity data collection technique. At 405, low-fidelity data is collected. The low-fidelity data can provide information related to the management of a health condition, such as the health of a diabetic patient (e.g., management of glucose concentration values). In some examples, the low-fidelity data can provide information indirectly related to the health of a diabetic patient. The low-fidelity data can be, for example, activity data (e.g., from a smartwatch or other wearable sensor) that indicates the amount of exercise or movement by the patient. The activity data can be accurate with respect to the activity value, but, for example, the low-fidelity data can be considered low-fidelity in that it is either indirectly related to glucose management or has a relatively weak correlation with glucose values compared to high-fidelity data and thus does not provide high precision about the patient's condition from the perspective of glucose management or diabetes state management. The low-fidelity data can additionally or alternatively include location, user input, or other physiological data (e.g., heart rate or respiration). In some examples, the low-fidelity data can be glucose concentration data, such as single-point glucose data (e.g., blood glucose meter data), glucose data from an NFC-enabled sensor, optical glucose data, or glucose information collected using another technique. The low-fidelity data can also include test results, such as fasting glucose values or hemoglobin A1C. The low-fidelity data can be used to perform a health assessment of a diabetic patient or to provide guidance to the patient to improve or manage the patient's diabetic health condition.

[0271] Additional information can also be collected during the collection of low-fidelity data. For example, the system can collect information regarding the use of activity trackers, food trackers, or self-monitoring of blood glucose. Patient engagement can also be collected, such as values of engagement or success in a coaching or goal-setting program. Preference information can also be collected, such as preferred ways to view and review health data (e.g., types and timings of app views, chats, and coaching calls, or learning styles (e.g., pattern recognition vs. real-time tracking and interaction), or preferred graphical styles (e.g., analyzing user interface screen views for examples of specific types of details to be examined, or preference for qualitative views vs. quantitative views), or communication styles (short messaging vs. video or measurements), or preferred health metrics (e.g., steps, exercise streak, daily carbohydrates, current app configuration)). One or more goals can also be determined (e.g., diet choices, exercise, basal or drug titration, or hypoglycemia avoidance). Patient risk metrics can also be determined, for example, based on demographics, medical records, average or fasting glucose values, or postprandial glucose variability characteristics. In some examples, a patient can be assigned a goal or risk metric based at least in part on a cohort of previous subjects with similar starting situations, goals, or characteristics.

[0272] In 410, high-fidelity data can be collected. During the collection of high-fidelity data, the collection of low-fidelity data can be interrupted, or both low-fidelity data and high-fidelity data can be collected. High-fidelity data can provide information highly relevant to the management of a patient's health state. For example, high-fidelity data can be data from a continuous glucose monitor. High-fidelity data can be more costly, burdensome, or invasive to collect than low-fidelity data, and thus it may be necessary to determine the justification for collecting high-fidelity data.

[0273] In one example, a determination is made that the collection of high-fidelity data is necessary or otherwise justified, based at least in part on low-fidelity data. For example, the low-fidelity information can be used to determine or identify subjects who are likely to gain a health benefit by transitioning to intermittent or continuous high-fidelity data collection. Such a determination can be based on, for example, risk metrics as described above, or another assessment of diabetes or cardiovascular risk, or the identification of glucose concentration patterns from which a benefit can be obtained (e.g., postprandial increases in glucose concentration, and high-fidelity data on peaks, and duration or glucose variability can be used to understand the glycemic load and glycemic response of a meal), or the identification of subjects with significant between-meal or daily variability (e.g., high-fidelity (e.g., CGM and activity) can correlate glucose patterns with activity or sleep patterns). The determination to engage in high-fidelity monitoring can also be based on the identification of subjects who will be involved in a next drug regimen change, or subjects who show progress in a coaching program, or recommendations from a coach or other healthcare provider.

[0274] In some examples, machine learning techniques are used to determine whether the collection of high-fidelity data is necessary or justified, based at least in part on low-fidelity data. For example, any suitable machine learning techniques can be used, such as supervised learning models, unsupervised learning models, and / or reinforcement learning models.

[0275] According to supervised learning techniques, a model is trained using a labeled training dataset. In this example, the labeled training data may include a low-fidelity dataset and a label indicating whether each low-fidelity dataset justifies the collection of high-fidelity data. The trained supervised learning model can receive low-fidelity data and generate an output indicating whether the received low-fidelity data indicates that the collection of high-fidelity data is necessary or justified. Exemplary supervised learning models that can be used include classification algorithms such as logistic regression algorithms, naive Bayes classifiers, support vector machines, decision tree algorithms, boosted tree algorithms, random forest algorithms, some neural networks, and nearest neighbor algorithms.

[0276] According to unsupervised learning techniques, a model is generated using low-fidelity training data that cannot be labeled. The model identifies instances of low-fidelity data that are similar to each other. This model can then be used to identify low-fidelity data that is similar to previous instances of low-fidelity data for which the collection of high-fidelity data was required or justified. Examples of unsupervised learning algorithms that can be used include clustering algorithms, anomaly detection algorithms, latent variable models, and some neural networks.

[0277] According to reinforcement learning techniques, a reinforcement learning model can be provided with low-fidelity data and make a decision as to whether the low-fidelity data justifies the collection of high-fidelity data. In a reinforcement learning model, feedback indicating whether the decision is correct can be provided and used to improve its performance. Exemplary reinforcement learning models that can be used include Q-learning algorithms, Sarsa algorithms, Markov decision process algorithms, and the like.

[0278] The decision to initiate collection of high-fidelity data may be based at least in part on information collected from activity sensors worn by a patient. For example, the decision to initiate collection of high-fidelity data may be based on fulfillment of activity conditions. For example, the activity conditions may include evidence that the patient exhibits activity above a threshold, or evidence that the patient periodically participates frequently enough in a certain type of exercise (e.g., walking, running, or activity above a specified criterion). In other examples, the decision to initiate high-fidelity data collection may be based on blood glucose meter data (e.g., fulfillment of blood glucose conditions such as a decision that an average blood glucose value has exceeded a threshold, or that a specified number of glucose measurements have exceeded a threshold) or location (e.g., frequent visits to a fitness facility or an unhealthy restaurant). The decision may also be based on a combination of two or more types of low-fidelity data. For example, activity data and blood glucose meter data may be used in combination, or activity and location may be used in combination, or blood glucose meter data and location may be used in combination. In one example, a determination that a blood glucose value (e.g., as determined by a blood glucose meter) responds to secondary factors such as activity (e.g., activity that lowers the blood glucose value) or location (e.g., whether the blood glucose value decreases or is better managed after visiting a park or gym, or increases or is less well managed after visiting a fast food restaurant).

[0279] The characteristics of high-fidelity data collection 410 can be at least partially based on low-fidelity data collection. For example, the system can estimate a period or schedule (e.g., an intermittent cycle) for high-fidelity monitoring and, according to the schedule, can initiate the shipment of necessary supplies (e.g., CGM sensors) or determine the shipment quantity (e.g., the number of CGM sensors to ship). In some examples, a high-fidelity system (e.g., a CGM system) can be preconfigured at least partially based on low-fidelity data to match the needs of the subject. For example, one or more preferred metrics for current health goals can be selected or ranked, or the system can automatically reset a coaching system (e.g., a chatbot or other coaching application running on a smart device such as a wristwatch) using preferred or specified information such as improved glucose metrics. In some examples, the system can integrate an improved glucose metric (e.g., a meal metric) into one or more specified (e.g., most viewed) application screens or devices (e.g., a display on a wristwatch). The system can notify a patient management facilitator such as a human coach or chatbot of patient management-related information such as when high-fidelity data is available or specified metrics for highlighting for the subject. The system can also determine guidance or other patient management factors based on behavioral learning about the subject, such as the timing and type of messaging, including delivery of information regarding post-meal repeats (e.g., the degree or nature of glucose value management or loss of management), exercise benefits, improvement due to medication changes, or adherence, or conducting an information collection period. The system can also determine goals (e.g., in-range time goals) based on low-fidelity data. Any of the above or below guidance examples can be used in method 401.

[0280] FIG. 5 is a flowchart diagram of a method 501 for collecting high-fidelity data and collecting low-fidelity data. At 505, high-fidelity data can be collected. The high-fidelity data can be used for the health assessment of diabetes, or for the improvement of diabetes health (e.g., to obtain better management of glucose concentration values or patterns), or for both. The high-fidelity data can be CGM data, or any of the other examples of high-fidelity data above or below.

[0281] At 510, low-fidelity data can be collected for the health assessment of diabetes or the improvement of diabetes health (or both). The low-fidelity data can be CGM data, or any of the other examples of low-fidelity data above or below. In some examples, the collection of low-fidelity data can be at least partially based on the collection of high-fidelity data. In some examples, the insights from the collection of high-fidelity data can be used to notify the app functionality, graphics, and phone app. For example, the time to obtain low-fidelity data (e.g., checking glucose values using a meter) can be determined to capture high or low glucose concentration values.

[0282] In some examples, at 515, guidance can be delivered to the patient to improve diabetes health. For example, the subject (e.g., the patient) can be educated or reminded about the importance of exercise or diet choices, or the patient can be congratulated or otherwise recognized for achieving exercise goals or glucose management conditions (e.g., maintaining glucose values within a specified range). The patient guidance can be partially based on the high-fidelity data. For example, the patient can be notified that the glucose value tends to go up and down, or at a particular amount, at a particular time of day (e.g., the glucose value may tend to rise in the morning), or before and after the time of a particular event (e.g., the glucose value may peak at a particular amount of time after a meal).

[0283] In some examples, the high-fidelity data collection stage may personalize metrics, guidance, or other information related to managing a patient's physiological state, such as blood glucose health. For example, insights based on high-fidelity monitoring can be used to inform app functionality, graphics, or notifications in a smart device application. In some examples, health concepts (e.g., possible guidance or actions a subject should take) can be ranked or quantified against potential health impacts, and a list of patient management options can be formed for a subject, for example, by determining one or more estimates of quantifiable benefits to physiological outcomes (e.g., glucose concentration range, target, time in range, or achievement of A1C). For example, one or more patterns (e.g., diet choices, exercise or activity, or sleep) that result in a benefit (e.g., better glucose management) can be determined based at least in part on high-fidelity data. In some examples, correlations can be determined between glucose concentration values and one or more lifestyle factors (e.g., activity (e.g., step count), meal timing, or food selection).

[0284] Guidance can be based at least in part on correlations determined from high-fidelity data, such as correlations between blood glucose health and another measurable characteristic or pattern. For example, guidance can be based on correlations between exercise and activity level and intensity and glucose improvement (e.g., how many minutes or steps are indicated to reduce glucose by 20 mg / dL), or between food and meal choices and glucose improvement (e.g., which foods caused a large glucose spike).

[0285] In some examples, 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 data and high-fidelity data).

[0286] By using high-fidelity data as described, the performance of devices that measure and / or utilize low-fidelity data can be increased. For example, using only low-fidelity data, generalized guidance can be provided to a user by comparing, for example, activity values or other low-fidelity data to generalized guidelines or criteria. As described herein, by using high-fidelity data in conjunction with low-fidelity data, a device can provide user guidance that is tailored to individual users, and thus is more likely to provide significant results such as achieving a glucose concentration range, target, time in range, or A1C.

[0287] Figure 6 is a flowchart diagram of a method 601 for collecting low-fidelity data and intermittently collected high-fidelity data. At 605, low-fidelity data is collected. The low-fidelity data can be activity, blood glucose meter data, or any of the examples of low fidelity identified above or below.

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

[0289] This method can return to the collection 605 of low-fidelity data during subsequent low-fidelity data collection periods, during which guidance for the patient can be determined based on the low-fidelity data and the determined relationship between the high-fidelity data and the low-fidelity data. In some examples, the low-fidelity data can be used in place of the high-fidelity data when determining patient guidance. This process can repeat 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., change in glucose concentration value, weight, activity, or new diagnosis). In some examples, the high-fidelity data is collected periodically (e.g., quarterly, annually, etc.). When a new high-fidelity data set is collected, the relationship or correlation between the low-fidelity data and the high-fidelity data can be updated and the patient guidance can be modified.

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

[0291] At 710, the condition or history of a patient is evaluated for diabetes or diabetes risk factors. For example, the patient's weight, body mass index, family history, genetic markers, prescription history (e.g., prescription medications), medical history (e.g., diagnosis of type 2 diabetes or another metabolic disorder that can be determined from an electronic medical record or other data), test results (e.g., A1C, fasting glucose level, oral glucose tolerance), other metabolic disorders, or other factors are evaluated to identify the likelihood of risk factors that may indicate vulnerability to diabetes, prediabetes, or the onset of diabetes. Exclusion criteria such as a diagnosis of type 1 diabetes or a type 2 diagnosis with intensive insulin treatment may also be applied. In some examples, the screening may produce a simple "yes / no" output. In some examples, a subset of 10% of the patients in the pool (e.g., 10,000 out of 100,000) may be identified as candidates for enrollment in an improved diabetes management program. In other examples, a more granular output may be provided, such as classification as type 1 diabetes, type 2 diabetes, gestational diabetes, or classification of type 2 diabetes in terms of 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 of 0 (normal glucose tolerance) to 9 (persistent mismanaged hypoglycemia or hyperglycemia)).

[0292] At 715, a registration selection is performed to determine whether a patient is registered in a diabetes management program. The registration selection can be made, for example, in response to fulfillment of registration conditions that may be based on additional screening inputs, additional confirmation of current or previous medications, progression of diabetes, effectiveness of previous treatments, predicted progression of the disease, adherence to or participation in previous health promotion programs (such as exercise or medication compliance), or any of the factors described above (weight, BMI, family history, etc.). In some examples, a score or other prediction can be determined based on the future diabetes risk or cost if the patient continues in the current diabetes management program. Additionally or alternatively, a score or other prediction can be determined based on the calculated potential benefit or prediction of success of an improved diabetes program. In some examples, a weighted score can be determined based on a combination of potential health risks or costs (or both) and potential benefits (such as cost savings or impact on patient health). Based on the score or other information described above, the registration selection can determine a patient selection for registration in an improved diabetes patient management program at 725 or for continuation of the current diabetes management program at 720. The identification at 705, the evaluation at 710, and the registration selection at 715 can be performed by one or more decision systems, such as execution of an algorithm on a computer system or mobile device, such as one or more of the devices shown in FIGS. 1 and 2. If the patient is not selected for the improved diabetes management program at 720, the method returns to patient selection from the patient pool.

[0293] At 725, a patient can be enrolled in an improved diabetes management program. In one example, the diabetes management system can enroll a patient in an improved diabetes management program, for example, in response to satisfaction of enrollment conditions. At 730, a data-driven patient management process can be executed. For example, data such as activity (e.g., using a wearable device), blood glucose meter data, user input data (e.g., food or beverage selections), location, or physiological data (e.g., heart rate or respiration) can be used to determine guidance for a patient regarding management of the patient's physiological state. Activity data measured by a wearable device can include, for example, data captured using an accelerometer of another motion sensor associated with the wearable device. The guidance can, for example, educate or reorient the patient regarding exercise or food choices, or can congratulate or otherwise evaluate the patient regarding outcomes (e.g., completion of exercise, or exercise on a continuous number of specific days, or a specified number of days in a period (e.g., three times a week or ten times a month)), or can congratulate or otherwise recognize beneficial food choices (e.g., selection of a healthy diet or restriction of calorie intake). In some examples, the improved diabetes management can include collection and correlation of low-fidelity data and high-fidelity data as described above with reference to FIGS. 4, 5, or 6 and as described below with reference to FIGS. 8B and 8C.

[0294] At 735, a decision regarding data-driven patient management is made. For example, the decision can be based on the fulfillment of diabetes management conditions. The diabetes management conditions can be, for example, the amount (e.g., percentage) of time that blood glucose (e.g., measured by a blood glucose meter) is within a target range (e.g., 70 - 160 mg / dL), the value of glycated hemoglobin or hemoglobin A1C in the blood (e.g., A1C test results), other diagnostic tests, changes in BMI, weight, or body composition (e.g., body fat percentage), cardiovascular health, or one or more of other factors or diagnostic tests. The decision can be made, for example, by a computer system configured to determine from the collected data whether the diabetes management conditions are fulfilled. In some examples, the computer system can apply the data input to a model, and the model can be based on a specific patient or a population. The model output can include a fulfillment status (e.g., fulfilled or unfulfilled) or a prediction about a future health state (e.g., the health state of a patient that may improve, the health state of a patient that may be stable, or the health state of a patient that may deteriorate).

[0295] If the diabetes management conditions are fulfilled, the method can return to the data-driven patient management at 730, and the system can continue the previous patient management approach or implement improvements (e.g., more frequent data collection or more proactive guidance) based on the decision at 735 or the information used in making the decision.

[0296] If the diabetes management conditions are not met at 735, the process may proceed to a more intensive patient management approach at 740. For example, the process may initiate the collection or receipt of continuous glucose monitoring information. For example, information from a continuous glucose monitor regarding a patient may be used to determine patient guidance. CGM data may be combined with other data sources to determine guidance. In some examples, a CGM-driven patient management approach 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 an ongoing cycle of intermittent CGM use, such as performing CGM data collection over a specified number of times per specified period (e.g., once a week or 10 days or 2 weeks per month, quarter, or year). Intermittent use of CGM may reduce the cost of managing the patient. For example, intermittent use of CGM may be less expensive than non-intermittent (e.g., continuous) use of CGM. This is because intermittent CGM data collection requires fewer sensors and only intermittent monitoring services via a CGM server. Intermittent use of CGM may also provide additional insights regarding the management of the patient's glucose concentration values, reducing the cost of managing the patient compared to not using CGM by delaying or halting the progression to type 2 diabetes, thereby reducing the overall cost of healthcare and improving the patient's outcome (e.g., improving health).

[0297] In some examples, after a period of CGM-driven patient management, the process may return to data-driven patient management at 730, at which point collection of CGM data may cease 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 (e.g., determine guidance for the patient) during data-driven patient management 730 when CGM data is not available. For example, the relationship (e.g., correlation) between CGM information and non-CGM information can be used to infer an estimated glucose concentration value or range from non-CGM data.

[0298] In various examples, all steps of the process may be performed by a patient management system that can collect, store, and analyze data regarding the patient. In some examples, data-driven patient management 730 may include collection of low-fidelity data, and the second stage of patient management 740 may include collection of high-fidelity data. Although CGM data is provided as an example, other sources of high-fidelity data may also be used, and it will be understood that the exemplary methods may also be adapted for management of other diseases in addition to, or instead of, managing diabetes or pre-diabetic conditions.

[0299] FIG. 8A is a flowchart diagram of a process 801 for managing a first patient. At 805, patient 1 is selected. At 810, a registration decision is made by applying a registration algorithm by a computer system that may use, for example, the health data described above (e.g., height, weight, body mass index, blood glucose level). At 815, a decision is made to maintain the current patient management program, which may include, for example, the delivery of guidance in regular examinations and regular health check-ups, but does not include continuous data collection between health check-ups. A regular health check-up may be an in-hospital visit or an electronic health check-up based on information about the patient collected known or periodically (e.g., every six months or every year). In some examples, each step in the management of patient 1 may be performed by a patient management system that may receive or collect information about the patient and make one or more decisions based on the patient data (e.g., apply an algorithm or apply data to a model).

[0300] FIG. 8B is a flowchart diagram of an exemplary process 803 for the management of a second patient. At 830, patient 2 is selected for evaluation. At 835, a registration decision is made by applying a registration algorithm by a computer system that may use, for example, the health data described above (e.g., height, weight, body mass index, blood glucose value). At 840, patient 2 is registered in a first-stage coaching modality and guidance may be provided to the patient, for example, based on low-fidelity data, via, for example, a handheld device or a wristwatch. For example, the chatbot functionality described herein may be used to provide guidance to the patient. At 845, low-fidelity data is collected and coaching or other guidance is determined based at least in part on the low-fidelity data. At 850, a treatment selection is made. The treatment selection 850 may be based at least in part on the low-fidelity data. The treatment may include, for example, the initiation of treatment such as insulin delivery (e.g., via a smart insulin pen) or the start of an oral medication. In some embodiments, the treatment selection may include delivering a specific bolus of a drug (e.g., considering a current insulin injection) or providing guidance for engaging in an activity (e.g., taking a walk or running to lower a glucose value). At 855, low-fidelity monitoring and coaching for patient 2 is continued.

[0301] FIG. 8C is a flowchart diagram of an exemplary process 805 for the management of a third patient. At 860, patient 3 is selected for evaluation. At 865, a registration decision is made, for example, by applying a registration algorithm by a computer system that may use the health data described above (e.g., height, weight, body mass index, blood glucose level). At 870, patient 3 is registered in a first-stage coaching regime, and guidance may be provided to the patient, for example, via a handheld device or a wristwatch. At 875, low-fidelity data is collected for patient 3, and based at least in part on the low-fidelity data, coaching or other guidance for patient 3 is determined. The coaching and / or other guidance may be provided to patient 3 via the handheld device 112, for example, using a chatbot, video, animation, or other user interface mode. At 880, a treatment selection is made. The treatment selection 880 may be based at least in part on the low-fidelity data. The treatment selection may be the initiation of treatment, such as an insulin injection program or an oral medication. The treatment selection may, in some cases, be a decision to involve the patient in a second-stage coaching regime that may be based at least in part on the high-fidelity data collected about the patient (e.g., CGM data). For example, the factors or process steps described above with reference to FIG. 4 may be applied to the low-fidelity monitoring 875 or the treatment selection 880.

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

[0303] Figure 9 is a flowchart diagram of a process for monitoring a patient using primary and secondary monitoring techniques. The primary technique can include receiving or collecting a first type of data ("primary data," i.e., "first data"), and the secondary technique can include receiving or collecting a second type of data ("secondary data," i.e., "second data"). For example, primary monitoring can include collecting or receiving high-fidelity information about the patient, and secondary monitoring can include collecting or receiving low-fidelity information about the patient. In an example where the patient is a diabetic patient, the primary technique can include, for example, continuous glucose monitoring. The secondary technique can include, for example, receiving or collecting 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 using another technique).

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

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

[0306] In some examples, the secondary monitoring may include monitoring an activity using a wearable fitness tracker. Examples of the wearable fitness tracker may include, for example, a wearable heart rate monitor, a wearable activity monitor, a smartphone, smart glasses, or a smartwatch.

[0307] In some examples, the second data may include user input data. For example, the user input data may include medication data, dietary data, exercise data, sleep data, or any combination thereof.

[0308] In some examples, the first data may include an estimated glucose concentration value, and the second type of data may include one or more detected physiological signals such as heart rate, oxygen concentration, skin color, skin moisture, activity, activity pattern, blood ketone concentration, urine ketone concentration, and respiration.

[0309] At 906, the correlation between the first data and the second data is determined. The correlation can be a positive correlation or a negative correlation. The correlation can be determined, for example, by determining a pattern or relationship between a plurality of data points in the first data and a plurality of data points in the second data corresponding to the first data (e.g., 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 second data after a change or event in the first data). In various examples, the correlation can be calculated using data retrieved from a storage device within a processor and a memory circuit. In some examples, the correlation can be determined using a processor by retrieving stored data from memory and using machine learning techniques based on at least a portion of the stored data. In some examples, determining the correlation can include determining the relationship between the first data and the second data obtained at corresponding times and / or days of the week during an overlapping period. For example, the processor can determine from the stored data that the glucose concentration value tends to be high (e.g., exceeding 150 mg / dL in the morning time period (e.g., 7 to 10 am or 3 hours after waking up)), but on days when the patient takes a morning walk, the glucose concentration does not tend to be high, or tends not to be very high (e.g., the glucose concentration is less than 126 mg / dL).

[0310] In some examples, the correlation is based on multiple types of secondary data. For example, the model can be trained to determine the relationship between activity, heart rate, and estimated glucose concentration values (e.g., as determined using a CGM system).

[0311] In some examples, the method may include, at 908, determining a treatment or monitoring regime using correlation and primary data. For example, the secondary data may include single point glucose monitoring (e.g., blood glucose meter measurements), and the method may include calculating a time window (e.g., an optimal or recommended window) for performing a single point glucose measurement based at least in part on the primary data. In some embodiments, obtaining one or more timely single point glucose measurements may enable an accurate determination of one or more estimated glucose concentration values (e.g., a particular value or range) between measurements based on, for example, interpolation techniques, determined correlations, additional types of secondary data (e.g., heart rate or activity), or any combination thereof. In some embodiments, 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 the user (e.g., a patient) to obtain a measurement (e.g., check blood glucose using a blood glucose meter) or attach a sensor (e.g., wear on a wearable activity monitor). The prompt may be delivered via a smart device such as a wristwatch or a handheld device.

[0312] At 910, the process may include an additional period of secondary monitoring. The secondary monitoring step 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.

[0313] At 912, the process may include determining diabetes information using the determined correlation (from step 906) and secondary data (from step 908). In various examples, the diabetes information may include an estimated value of a first type of data at a subsequent time, the patient's condition, or the patient's insight. The patient's condition or the patient's insight may be related to, for example, diet, exercise, glucose value monitoring, or improvement of lifestyle related to taking medicine. In some examples, the patient's condition or the patient's insight may be related to meal time management, exercise management, or sleep management.

[0314] In one example, when the primary data is an estimated glucose concentration value (e.g., from a CGM), the estimated glucose concentration value may be determined from the secondary data based on the determined (e.g., learned) relationship between the secondary data and the estimated glucose concentration value. In one example, the secondary data is, is included in, or includes physiological information (e.g., activity data, heart rate data), and the estimated glucose concentration value or range (average of real-time or specified period) is determined using the determined relationship and the physiological information.

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

[0316] At 914, the method may include delivering guidance or treatment. For example, the method may include displaying diabetes information regarding the patient on a user interface of a patient device such as a handheld device, a wristwatch, or on a display of wearable glasses. Displaying diabetes information may include, for example, displaying on the user interface an improvement in the recommended diet or lifestyle improvement.

[0317] In some examples, the method may include, at 914, administering treatment based at least in part on the determined diabetes information. Treatment may include, for example, pharmaceutical intervention such as an oral medication or a drug delivered through a pump.

[0318] In some examples, the method may include, at 916, primary monitoring during a third period.

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

[0320] At 920, the method may include performing secondary monitoring 920 during a fourth period. The method can return to step 912 and can use the updated correlation (from step 918) and the secondary monitoring data from step 920 to determine diabetes information. The process may deliver guidance or treatment at 914, perform primary monitoring at 916, update the correlation at 918, perform secondary monitoring 920 again, return to step 912 again, and can result in intermittent primary monitoring as the process cycles through the method steps.

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

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

[0323] At 1004, non-CGM information related to the patient may be received over the first period. The method may optionally include detecting the non-CGM information using a sensor. 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 regarding the patient. The physiological information may include, for example, one or more of heart rate, respiration, oxygen concentration, skin color, skin moisture, activity, activity pattern, blood ketones, urine ketones, respiration, or acoustic information.

[0324] At 1006, a relationship between the estimated glucose concentration values and the non-CGM information is determined. For example, a correlation between the non-CGM information and the estimated glucose concentration values may be calculated. In some examples, a model may be learned from the collected CGM data and non-CGM data, whereby the estimated glucose concentration values can be determined from the non-CGM data by applying the non-CGM data to the model.

[0325] At 1008, non-CGM information related to the patient can be received for the second period. The second period can be a period when the estimated glucose concentration value from the CGM is not available. At 1010, based on the determined relationship and non-CGM information, diabetes information for the patient in the second period can be determined. Determining diabetes information for the patient can include determining the patient state. Determining the patient state can include applying non-CGM information to a model. In some examples, determining diabetes information can include determining an estimated glucose concentration value. For example, the algorithm can infer an estimated glucose concentration value from activity information calibrated to the glucose concentration value at the individual level (e.g., based on information about the patient), or at the population level, or both (e.g., using a predictive learning model).

[0326] In some examples, determining diabetes information can include determining a qualitative assessment such as green, yellow, red, i.e., "good control", "moderate control", "poor control", etc.

[0327] In some examples, determining diabetes information can include determining a quantitative metric. The quantitative metric can be, for example, an estimated amount or percentage of time during a specified period that the glucose concentration value was within a range. In some examples, the quantitative metric may not be available in real time. For example, the quantitative metric can include the time within a specified period (e.g., one day, or several hours), which can be reported at the end of the day, or intermittently, e.g., hourly, daily, weekly, etc.

[0328] In 1012, the system can electronically notify the patient about diabetes information. For example, the system can present a notification (e.g., a word or symbol) on the display of a handheld device, smartwatch, glasses, or other wearable electronic item, or the system can present an audio notification (e.g., a verbal message or sound) or a tactile notification (e.g., vibration) through the speaker of such a device. In an example where an audio notification is used, the audio notification can be provided by an implemented chatbot as described herein. In some examples, the notification is related to diabetes severity information. Consider an example where non-CGM information indicates a hypoglycemic state. The system may present a stronger notification to indicate urgency. For example, the system can present a high-frequency or long-duration sound, a verbal message conveyed with increased intonation or volume, and / or a long-duration and / or high-amplitude tactile notification. Consider another example where non-CGM information indicates a normal or favorable blood glucose value. The system can present a less intense notification, such as a lower-frequency or shorter-duration sound, a verbal message conveyed with decreased intonation or volume, and / or a shorter-duration and / or lower-amplitude tactile notification.

[0329] The system can improve patient management, for example, by managing the costs incurred by continuous glucose monitoring or by enabling the glucose estimate to give the user (e.g., the patient) an incentive to take measures to manage the glucose value. For example, by using low-frequency data and high-frequency data in the manner described by the example related to exemplary method 1001, the benefits of high-fidelity data collection can be provided at reduced costs. For example, the performance of the system during low-fidelity data collection may be comparable to the performance during high-fidelity data collection, so it may not be necessary to frequently perform the more expensive high-fidelity data collection. Also, for example, the patient's blood glucose management can be improved at the cost of full-time high-fidelity data collection.

[0330] FIG. 11 is a flowchart diagram of an exemplary method for determining a monitoring modality based on collected sensor information, which can indicate, for example, qualities related to a patient's engagement or behavior. For example, a determination to use CGM sensing, CGM sensing parameters (e.g., schedule or amount of CGM sensing), user interface parameters (e.g., type or content of guidance), or goals (e.g., glucose target range or A1C target) can be determined based on activity data or other collected information.

[0331] Method 1101 can include, at 1102, monitoring a first sensor input to obtain a first type of first data. For example, method 1101 can include monitoring a first type of patient data using a low-fidelity monitoring technique over a first period. In various examples, the low-fidelity technique can include receiving user input data such as medication data, dietary data, exercise or activity data, sleep data, or any combination thereof.

[0332] Monitoring the first sensor input can 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 wristwatch with an optical sensor), or "blind CGM" (e.g., continuous glucose monitoring where estimated glucose values are not presented to the patient, e.g., for later analysis, the glucose values are transmitted to a server or stored in the memory of a local CGM or device for the patient). In some examples, monitoring the first sensor input can include activity monitoring by a wearable fitness tracker such as a wearable heart rate monitor, activity monitor, smartphone, smart glasses, or smartwatch.

[0333] Method 1101 may further include, at 1104, evaluating a patient's engagement or behavior based on monitored first type of patient data. For example, a remote system (e.g., a server executing an algorithm) or a local system (e.g., a handheld device) may evaluate a user's suitability or preference regarding the complexity or number of features available in a user interface. A skilled or highly engaged user may prefer an interface with more complex or complete functionality over a less skilled or less engaged user. Such a determination may be made based on, for example, the frequency of interaction with a device (e.g., a handheld device or a watch), the timeliness of the interaction, the relevance of the interaction (e.g., responsiveness to an alert), compliance with guidance (e.g., participating in an exercise in response to guidance requesting exercise participation), or interaction with another application (e.g., based on interaction with a fitness tracker application).

[0334] The method may include, at 1106, determining a monitoring mode based on an evaluation of a patient's engagement or behavior. For example, the method may include determining a hardware function or a software function of the device. The hardware function or the software function may correspond to, for example, the operation of a user interface. In some examples, the determined function may include a simple, i.e., a simplified function interface that can be applied in response to identifying a patient with low engagement or a patient who can benefit from a less complex interaction as part of the evaluation. The determined function may also include a relatively complex or full-featured interface that can be applied in response to identifying a highly engaged user or a user (e.g., an experienced user) who may prefer a more complex interface (e.g., an interface that includes more features or provides more configuration options such as programmable alerts or more frequent guidance). In some examples, the user interface may additionally or alternatively adapt at least in part based on the user's age or date of birth (e.g., year). For example, the user interface may use a larger font or user interface elements (e.g., buttons), or a different presentation style (e.g., a higher contrast or a specified color scheme) for an older user. In some examples, the user interface may provide a visual task to determine whether the user has difficulty distinguishing or selecting user interface elements, or may prompt the user to enter information about their vision, and the user interface may adapt based on the response to the task or prompt.

[0335] In some examples, the determined hardware function or software function may relate to the frequency of the automatic coaching routine (e.g., how often the device communicates with the user) or the content (e.g., the subject of the communication to the user). For example, if the contact with the user is too frequent, the user may become fatigued and disengage. On the other hand, if the contact with the user is not frequent enough, the user may not receive sufficient guidance to achieve the desired results. Method 1101 may include correlating the patient's behavior with different contact frequencies.

[0336] In some examples, determining the monitoring approach may include determining patient goals. The method may include determining the hardware function or software function of a monitoring device (e.g., a handheld device or a body-worn device) related to or facilitating the goals. In various examples, the goals may include dietary goals, exercise goals, glucose monitoring goals, or medication goals. In some examples, at least one hardware function or software function of the monitoring device may relate to meal-time glucose management (e.g., strategies for managing glucose values before, during, or after a meal or any combination thereof, such as exercising before or after a meal, or delivering insulin before a meal (the "pre-bolus" strategy)). In some embodiments, at least one hardware function or software function of the monitoring device may relate to sleep management (e.g., strategies for managing glucose values during sleep or avoiding or minimizing interruptions in sleep to address glucose value issues).

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

[0338] Method 1101 may further include, at 1108, determining an amount or frequency of monitoring. In some examples, the amount 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, e.g., based on data collected by a low-fidelity monitoring technique. The amount or frequency of data may include the amount of data points, or 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 (a consistent or irregular period). The amount or frequency of subsequent data may also be based at least in part on a specified goal or outcome. For example, the amount or frequency of data may be calculated to increase or maximize a patient parameter, such as the amount or percentage of time within a specified range of glucose concentration values or the patient's A1c value.

[0339] Method 1101 may include, at 1110, monitoring a second sensor input according to the determined monitoring scheme. For example, the method may include using a monitoring device to monitor a second type of patient data using a high-fidelity monitoring technique over a second period of time. High-fidelity monitoring may include, for example, continuous glucose monitoring.

[0340] Method 1101 may further include, at 1112, providing guidance to a patient, for example, via system 100 shown in FIG. 1. For example, the system may provide an automated message transmitted from a server to a monitoring device based on patient profile data or first sensor input. In some examples, the guidance may be provided using a fitness tracker application, a meal tracking application, or a dedicated CGM or guidance application. For example, the application may deliver (e.g., display) CGM data, information based on the CGM data (e.g., time in range), guidance for the subject (e.g., "Consider a workout session"), and predicted, estimated, or measured exercise benefits for glucose management. In some embodiments, the application may educate the user about food choices and resulting postprandial glucose management (e.g., variability), or about the relationship between exercise and the glucose-lowering effect of exercise, or may quantify that relationship. For example, the application may indicate that the user's selected activity is estimated to bring the user's glucose value to a desired value or range (e.g., "Recent activity will bring glucose values into the desired range"). In another embodiment, the application may indicate that the proposed activity is likely to bring the user's glucose value to a desired value or range (e.g., "One hour of running is estimated to lower glucose by 15 mg / dl"). In some examples, the guidance may be provided by a chatbot function provided as described herein.

[0341] Method 1101 may further include, at 1114, detecting a change in patient parameters (e.g., improvement in glucose concentration management at a specified time or in a specified condition, or improvement in A1C). The change may be measured between a first period during which a first sensor input is collected and a second period during which a second sensor input is collected. The detected change may be used to further affect at least one hardware or software function of the monitoring device. In some examples, machine learning techniques can be used to associate characteristics of the monitoring or guidance modality with changes in patient parameters. For example, a positive change may correlate with a particular aspect of the monitoring modality or guidance, and the hardware or software function of the monitoring device may be modified to emphasize the aspect that correlates with the positive change. Such iterative changes can improve the performance of the monitoring system in leading the patient to a positive clinical outcome or achievement of a management goal (e.g., toward better managed glucose values or lower A1c test results). In some examples, an increased or maximized display of patient parameters may be presented on the monitoring device.

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

[0343] In some examples, the method may include determining a final goal for the patient. The patient's final goal may be based at least in part on a first type of patient data, a second type of patient data, or both. The method may further include presenting a treatment recommendation (e.g., presented as guidance) calculated to cause a transition in the patient's state toward the patient's final goal.

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

[0345] The user interface 1202 may include a chart 1204 that can show glucose concentration values 1236 (e.g., measured in mg / dL) plotted against a timeline 1234. The user interface 1202 may also show the upper limit 1230 and lower limit 1232 of the target range. In various examples, the target range can be set by the user (e.g., a patient), or determined by a device or system (e.g., the handheld device 112 or 120 shown in FIG. 1), or provided by a coach (e.g., a human coach or a computer-controlled "chatbot" coach). In the illustrated example, the upper limit is set at 180 mg / dL and the lower limit is set at 80 mg / dL. In some embodiments, the range can be set (e.g., by the system or by default) between 70 and 160 mg / dL, and this range can be expanded (e.g., to between 70 and 180 mg / dL) or reduced as appropriate for a particular patient, which can be determined, for example, from patterns in CGM or low-fidelity data, or from input from the user. An enlarged view of the chart is shown in FIG. 12B. In various examples, the glucose concentration values can be estimated blood glucose concentration values (e.g., GCM data, or values calculated based on other data), or the plotted glucose values can include blood glucose values from an instrument. The exemplary chart 1204 shows a 24-hour period (from 12:00 AM to 12:00 AM the next day), but in various other examples, the chart can show a shorter period (e.g., 1 hour, 3 hours, 6 hours, or 12 hours) or a longer period (e.g., 2 days, 3 days, 1 week, 2 weeks, 1 month, or 3 months). For longer periods, the plotted values can correspond to the average for a day or a week, or the graph can show the range or distribution of values or averages (e.g., bars indicating high and low, and points or lines indicating the median or average). Although glucose concentration values are shown, other types of analyte values, or other types of sensor data, can be shown instead of, or in addition to, the glucose concentration values (e.g., on the same chart or a different chart).

[0346] The user interface 1202 may include a plurality of event indicators that can indicate physiological events, dietary events, activity events, and medication events. For example, the user interface 1202 indicates a glucose event 1206 around 4:30 am, at which time the glucose concentration value reaches a low point of 51 mg / dL and has a steep downward trend indicated by two downward arrows. In some examples, particularly those where the user is known to be a heavy user of insulin, the event 1206 may prompt the user to consume carbohydrates to avoid potential low blood glucose problems in response to an alert on a smart device (e.g., the wearable device 120 or the user device 132). The user interface indicates a second glucose event indicator 1214 around 1:30 pm, at which time the glucose concentration value is moderate (129 mg / dL) and the trend is stable (indicated by a horizontal arrow). The glucose event 1214 may correspond to, for example, a user-specified post-lunch report or may occur at a time calculated by the system (e.g., midday or post-lunch report). An exemplary user interface 1202 indicates a third glucose indicator 1222 around 7:30 pm, at which time the glucose concentration is high (203 mg / dL) and has a rapid upward trend as indicated by two upward arrows in this example. In some examples, the glucose indicator may be shaded, colored, or otherwise visually distinguishable to indicate whether the glucose concentration value meets the glucose management conditions, e.g., whether the glucose concentration value is within a specified range.

[0347] The user interface 1202 may include a plurality of meal indicators, such as a breakfast indicator 1208, a lunch indicator 1212, and a dinner indicator 1220. The meal indicators 1208, 1212, 1220 may correspond to the user's meals. The user's meals can be identified from user inputs such as smartphone inputs indicating that a meal has been consumed, and may optionally include information about the meal, such as the meal content (e.g., carbohydrates, proteins, and fats, or food types such as "1 slice of pizza and 1 cup of milk"). The user's meals may also, in some examples, be identified from other types of inputs, such as, for example, geolocation data, movement data, etc. For example, the geolocation data may indicate that the user is at the user's kitchen, a restaurant, or another place where food is cooked and / or served. Also, for example, the movement data may indicate the user's movement that coincides with a meal. Such movement may include, for example, the user repeatedly moving the user's hand to the user's mouth.

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

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

[0350] The user interface may also include guidance comments. For example, the user interface may include a guidance bubble 1210 stating "There was a spike at 1:00 PM in the past three days" and a second guidance bubble 1226 stating "The medicine is best taken before bedtime". In some examples, the guidance bubble is provided in the morning, and the data event indicator is displayed according to the passage of time on the same day. When the guidance bubbles 1210, 1226 are provided with a view to the future, the guidance may prompt the user to, for example, change the content of the breakfast meal or go for a walk during the day to address the recurrent glucose spike at 1:00 PM. In some examples, a chatbot function can be activated by selecting the guidance bubbles 1210, 1226, etc. to provide guidance to the user.

[0351] In some examples, the user interface may include gamification (e.g., prizes or badges) to encourage user engagement. For example, the user interface 1202 may present a badge 1218 that may show a person walking in a still or moving image, and may also present a comment such as "The post-meal walking skill is not locked!" to confirm the user's activity behavior. In some examples, the decision to award the post-meal walking skill may be made by a system (e.g., a remote system connected via the network 124 or a processor within the user device 132). The user interface may also include a medication badge (Rx) 1228 where a message such as "The medication optimization skill is not locked" may be presented. In some examples, the system may decide to award the medication badge 1228 based on fulfillment of delivery conditions such as delivery of the medication within a specified period before sleep (which may be detected by an activity sensor, a posture sensor, a physiological sensor, or any combination thereof). In some examples, machine learning techniques can be used to associate gamification with patient outcomes such as desired values for blood glucose management. In this way, the system can configure gamification to improve patient outcomes, thereby enhancing the effectiveness of the system.

[0352] In some examples, the user interface can provide a plot of glucose values along with a display of the average glucose value to achieve a particular A1C value. FIG. 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 indicates the average blood glucose corresponding to the user's desired A1C. In the example of FIG. 12C, the A1C indicator 1254 is located at a blood glucose value of 154 mg / dl corresponding to an A1C of 7.0. In some examples, target A1C indicators such as 1254 can be used in other user interfaces such as the user interface 1202 described herein. Also, similar to the user interface 1202, the user interface 1202 can be presented on a user device such as the user device 132, or alternatively or additionally, on a handheld smart device (e.g., smartphone) 112, a tablet 114, a computer 118, a wearable device 120, a peripheral medical device 122, or a remote terminal 128.

[0353] FIG. 13 is a flowchart diagram of a method for identifying or selecting patients who may benefit from an improved disease management program such as intermittent CGM or other high-fidelity monitoring for the management of type 2 diabetes, or optionally low-fidelity monitoring (e.g., activity monitoring) that correlates with high-fidelity (e.g., CGM) information. In some examples, the method may include determining whether a patient improvement condition is likely to be met by the improved monitoring. For example, the method may include determining an estimated likelihood that a patient will benefit from the improved monitoring approach. The estimated likelihood may be a calculated value or percentage, such as 75%, 90%, or 95%, and may optionally be configurable by a user (e.g., a patient or a health system administrator). The method may include measurable improvements as indicators that a patient will (or has) benefited from the improved monitoring, such as a reduction in A1c, achievement of an A1c goal (e.g., an A1c of less than 7.0), or a reduction in glucose variability, or any combination thereof.

[0354] At 1302, a system, such as system 125, 126, or 127, may screen for a first characteristic. For example, the system may execute a first screening algorithm (e.g., on a processor) against stored data in a participant (e.g., patient) pool to determine a group of individuals with diabetes or with diabetes risk factors. The method may use factors such as electronic health records, type II diabetes diagnosis codes, family history, weight, BMI, history of metabolic diseases, blood test values, A1c, fasting glucose values, oral glucose tolerance, prescribed diabetes medications, or any combination thereof.

[0355] At 1304, a first monitoring approach may be applied to obtain additional data regarding the determined population. For example, method 1301 may include providing a first kit to participants in the determined group. The kit is structured and configured to enable participants in the determined group to perform low-fidelity monitoring of their health over a first period using a first monitoring technique and obtain a first result. The information may be received from a device within the kit by system 127 or by another system or device.

[0356] 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.

[0357] At 1306, a system (e.g., system 127 or user device 132) may screen for a second characteristic. For example, the system may execute a second screening algorithm on the determined group to determine a cohort that participates in intermittent high-fidelity monitoring. The second screening algorithm may be at least partially based on results obtained using the first monitoring approach. In some examples, intermittent high-fidelity monitoring may include continuous glucose monitoring. In some examples, the screening may be at least partially based on factors that persist in the use of the first approach (e.g., a low-fidelity monitoring technique), such as whether a user adheres to a monitoring plan. For example, a factor in determining the use of high-fidelity monitoring may be the degree to which a patient adheres to instructions or procedures for low-fidelity monitoring, such as wearing an activity monitor or performing blood glucose measurements according to a specified schedule.

[0358] In 1308, a second monitoring method may be applied. For example, method 1301 may include providing a second kit to the determined cohort participants. The second kit is structured and configured to enable the determined cohort participants to perform high-fidelity monitoring of their health over a second period using a second monitoring technique and obtain a second result. In some examples, the second kit may include a continuous glucose monitor. The second kit may be structured and configured based on the obtained first result. For example, in an example where the second monitoring method is continuous glucose monitoring, the amount or type (or both) of glucose sensors provided in the second kit may be determined based on the obtained first result. In some examples, the determination may be made to include a plurality of first type sensors that use a first communication technology (e.g., NFC that requires a swipe by a smart device to extract glucose data), or a plurality of second type sensors designed for use with a long-range transmitter (e.g., Bluetooth) that can provide glucose information to a wireless device (e.g., a smartphone) without human interaction, or a combination of the first type sensors and the second type sensors.

[0359] At 1310, the method may include providing guidance. For example, the method may include presenting guidance on a 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 and a device in the first kit. The communication may be provided, for example, during the first monitoring. The communication can provide guidance (e.g., coaching information regarding steps to take to lower glucose values such as exercise, or feedback regarding glucose management such as estimated average glucose concentration or variability or both over a specified period) to a patient or caregiver. The guidance may include diabetes management guidance including, for example, improvements in lifestyle related to diet or exercise, glucose value monitoring, or medication, or any combination thereof. In some examples, the guidance may include a display of a period or schedule for using high-fidelity monitoring, such as once a week, or for 10 days, or for one week out of every month.

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

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

[0362] Method 1300 may be implemented in a dedicated system that may include hardware components, software components, or both, such as system 2200 shown in FIGS. 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 delivery of one or more detection kits to a designated patient or patient cohort.

[0363] FIG. 14 is a flowchart diagram of an exemplary method for managing parameters related to a patient's health using intermittent high-fidelity monitoring. At 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, where the likelihood is greater than a calculated value. The patient pool may represent, for example, a group of patients in a clinical practice, or in a designated insurance pool or program, or in a geographical location, or in a workplace, or any combination thereof.

[0364] At 1404, the patient may be monitored over a first period (e.g., a duration) using a first monitoring technique that may generate a first result (or set of results). The first technique may include, for example, high-fidelity monitoring (e.g., using CGM) or low-fidelity monitoring (e.g., using a blood glucose meter).

[0365] At 1406, the patient may be monitored over a second period using a second monitoring technique that may generate a second result (or set of results). In various examples, the first period may be a subset of the second period or may overlap with the second period.

[0366] In some examples, the first technique may include high-fidelity monitoring, and the second technique may include low-fidelity monitoring that is at least partially determined 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 where the patient does not receive some or all of the estimated glucose concentration values). In some examples, the first technique may include activity monitoring using a wearable fitness tracker such as a heart rate monitor, activity monitor, smartphone, smart glass, or smartwatch, or any combination thereof. In some examples, the second monitoring, i.e., the low-fidelity technique, may include receiving user input data such as medication data, dietary data, exercise data, sleep data, or any combination thereof.

[0367] In other examples, the second technique may include low-fidelity monitoring, and the first technique may include high-fidelity monitoring that is at least partially determined by the results of the low-fidelity monitoring.

[0368] At 1408, actions that the patient may perform may be determined based on the first result and the second result. The actions may be calculated to increase the likelihood of meeting the management conditions. For example, the actions may be calculated to increase a parameter related to the patient's health by a greater amount than a predetermined amount with a higher confidence level than a predetermined confidence level. For example, the actions may be calculated to increase the in-range time, such as the amount (e.g., percentage or fraction or number of hours) that the estimated glucose concentration value is within a specified range. In another example, the actions may be calculated to change the glucose variability by a specified amount (e.g., increase or decrease).

[0369] At 1410, guidance can be delivered. For example, the guidance can be presented on a display. In various examples, the guidance can be related to diet, exercise, glucose monitoring, or taking medications. In some embodiments, the guidance can show the patient's performance in meeting conditions (e.g., goals) related to diet, exercise, glucose monitoring, taking medications, or other health-related matters. Delivering the guidance can include communicating between a server and a device associated with the patient. In some examples, delivering the guidance can include delivering a chatbot function to a device associated with the patient. The communication can be performed during a first period or a second period, or both, or after the second period. In some examples, the communication can provide a coaching function to the patient.

[0370] In some embodiments, delivering the guidance can include displaying (or otherwise communicating via a device or system) the optimal period during which the patient should use high-fidelity monitoring.

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

[0372] FIG. 15 shows an example of a method 1501 by which a patient's user account can be set up on a server, where the patient can automatically log in using an app on their mobile device while entering only a minimal amount of information.

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

[0374] In step 1504, provide the patient with a kit that includes the mobile device. In step 1506, the user launches the app, establishes communication with the server, and automatically transmits the unique identifier of the mobile device. The app also transmits the patient information pre-set in the patient record that is used to associate the patient with the mobile device. This information can include, for example, one or more of the patient's email address, DOB, phone number, etc.

[0375] In step 1508, the server attempts to match the unique identifier of the mobile device and the patient information with the patient record stored in the server's database. If the match is successful, in step 1510, the server either logs in to the matching patient record in the database or transmits the authentication information necessary to otherwise access it to the app. Then, in step 1512, the app uses the authentication information to log in and access the patient record.

[0376] The above-described automatic login procedure has been described for new patients who require the creation of user records. This procedure can also be used for existing patients. For example, in step 1504, instead of providing a kit to a new patient, if a new transmitter is provided to an existing patient, in step 1502, instead of creating an account for a new patient, the identifier of the new transmitter is entered into the existing record of the patient. Thus, in this way, the process shown in FIG. 15 enables both new and existing patients to automatically log in with minimal effort and access their patient account records.

[0377] It should be noted that the functions of the servers used in the above-described automatic login procedure may, in some cases, be distributed among a plurality of servers that may or may not be controlled by the same entity. For example, in one particular example, one or more of the servers may be controlled and operated by a device manufacturer, and one or more additional servers may be controlled and operated by a database provider.

[0378] FIG. 16 is a diagram of an exemplary user interface 1600 that can be presented on a display of a smart device, such as a handheld device 112, or on a display of a wearable device 120. The user interface 1600 can include a trend graph 1602 that can show high-fidelity data (e.g., CGM data) plotted against some time today. The user interface screen shown in FIG. 16 can be accessed by selecting a button (labeled "Glucose") on the user interface. The user interface 1600 can include a legend 1604 that provides explanatory information about the plot. A time selector user interface element 1610 can enable a user to manage the display period of the data (e.g., today, yesterday, two days ago, or the entire week). The user interface 1600 can also provide a within-range time chart 1606 that can show, for example, the proportion (as shown) or amount (e.g., fraction or number of hours) of time within range for some periods (e.g., several days of the week, or parts of a day such as morning, afternoon, evening, night as shown). The interface 1600 can include an input element 1608 that enables a user to select a percentage-based display as shown in FIG. 16, or a time-based display 1902 as shown in FIG. 19. A time selector user interface element 1612 can receive user input for the within-range time chart and can enable a user to select, for example, a particular week for which data is shown, or a period of a different size (e.g., a part of a day, or a within-range time for several weeks or months). In some examples, both trend graphs can be shown simultaneously, or a scrollable portion 1614 (shown by the dashed line) can be visible on the display screen, and the user interface can receive user input (e.g., via a touch screen) to scroll or zoom to show a within-range time graph in addition to, or as an alternative to, the trend graph.

[0379] In an example of intermittent monitoring, the trend graph may be presented for a period (e.g., several days) during which high-fidelity collected data (e.g., CGM data) is available, and the in-range time chart may be provided for a period (e.g., several weeks) during which low-fidelity collected data is available (regardless of the availability of high-fidelity data).

[0380] FIG. 17 is a diagram of an exemplary chat user interface 1700 that may be presented on a display of a handheld device 112, or on a display of a wearable device 120. The chat user interface 1700 can be accessed by selecting a chat user interface element 1702, thereby enabling the start of a chat session with a human coach or a chatbot coach within a chat window 1704. The chat user interface 1700 may also include a context field 1706. The context field 1706 may include, for example, a guidance message that may be provided in response to high-fidelity or low-fidelity collected data. The chat interface may present information 1708 from the coach 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, the user may ask "Why do I need to eat vegetables?" and the coach (e.g., a chatbot) may respond with "Vegetables tend to have fewer simple carbohydrates than foods like bread or pastries, so they can help keep glucose within range." In some embodiments, the chat session may be conducted using a microphone and speaker, in addition to or as an alternative to the on-screen chat shown in FIG. 17.

[0381] FIG. 18 shows a chat interface 1800 that includes a chart within a context field 1802. The chart can be, for example, a percentage-based chart as shown in the context field of FIG. 18, or a time-based chart within a context field as shown in the user interface 1900 shown in FIG. 19 (such as shown), or the chart can be a trend as shown in FIGS. 16 and 21. In another example, the user interface 2000 can include a text message in a context field 2002. The user and the coach can interact within chat fields 1804, 1904, 2004 to, for example, ask questions about the chart or answer questions. On a device with spatial constraints, input from the user can be advantageously received via a microphone and speech recognition software to avoid competing demands for screen space with the chat field 1804, the keyboard (not shown), and the context field 1802. For example, an audio chat function (such as using a microphone and a speaker) can be initiated by selecting a chat button 1620 within the interface shown in FIG. 16. In some examples, a chat session can be triggered by detected data, information about a patient, or other chat trigger conditions. For example, a chat session can be triggered in response to a trend that meets a trend condition or a range condition, which can thereby enable, for example, a patient or user to take corrective measures (such as participate in activities such as exercise, or change a diet selection, or administer a drug). For example, a chat session can be triggered by an estimated glucose concentration value that is rising or falling rapidly, or deviating significantly from a range, or deviating from a range during a time or situation when glucose is normally within the range, or deviating from a range for a specified period of time (such as deviating from a range for 12 hours), or deviating from a range by more than a specified percentage over a specified period of time (such as more than 60% over a specified day or week).

[0382] In some examples, the user interfaces 1600, 1700, 1800, 1900, 2000 shown in FIGS. 16-20 may adapt based on information about the user. For example, the user interface may adapt based on proficiency or preferences or characteristics regarding the use of the interface by the user. In some examples, the user interface may provide fewer options, larger displays, or simpler information to accommodate users who exhibit a tendency or preference for less sophisticated interactions. In some examples, the user interface may adapt based on the user's age or date of birth (e.g., year). For example, users who meet a specific age condition (e.g., over 60, over 65, or over 70) may be presented with a user interface having a designated appearance scheme (e.g., color scheme or high contrast) or larger buttons or larger fonts.

[0383] FIG. 21 is a diagram of an exemplary user interface 2000. The user interface 2000 can be in a landscape mode view (e.g., where the width is greater than the length and can be useful when the handheld smart device is in landscape orientation). The user interface 2000 can be scrollable horizontally to display data for a period of time to the left (i.e., earlier) or right (i.e., later) of the currently displayed data. For example, the data can “slide” to the right when the user touches the screen and swipes right to show data for a time before 9:00 PM, and the data can slide to the left in response to the user swiping left to show data for a time, for example, after 4:00 PM. The user interface 2100 can also include a user interface element 2102 (e.g., a “show current” button), and in response to a selection of the user interface element 2102 by the user, the user interface can be refreshed as appropriate to show data for the current time or can slide left or right. The slidable user interface can be useful in coaching, for example, the user can receive an instruction from a coach to display data for a particular time or event (e.g., dinner), and then the user can select the user interface element 2102 to receive an instruction to return to the current data.

[0384] FIG. 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 wristwatch), which may be worn by a participant (e.g., a patient) 2201 to generate glucose concentration information and activity information regarding the patient. The CGM sensor 2202 may provide activity information to a user computing device 2206 (e.g., a smartphone or a wristwatch), and the activity sensor 2204 may provide activity information to the user computing device 2206, which may be a wearable device such as, for example, a handheld device (as shown) or a wristwatch. The user computing device 2206 and the activity sensor 2204 are shown as separate devices, but 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 wristwatch that includes an activity sensor).

[0385] One or more applications may be executed on the user computing device 2206 to provide glucose concentration information, activity information, or guidance to a patient. For example, a first application 2208 executed on a smart device may provide information about glucose concentration values and optionally also provide guidance regarding the management of glucose concentration values, and a second application 2210 executed on the smart device may provide information about activities and optionally also provide guidance regarding activities (e.g., "Consider taking a brisk walk this afternoon") or guidance regarding glucose concentration management (e.g., "Steps need to be taken to lower today's glucose value") or both (e.g., "Consider taking a brisk walk this afternoon to help lower today's glucose value"). Although two separate applications are shown, in some examples, the smart device may execute a single application that combines the above-described features (i.e., a single application may provide information regarding both glucose concentration and activity and guidance regarding them).

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

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

[0388] The second data application 2210 can be configured to establish a second communication link with the activity sensor 2204. The second communication link can be, for example, a wireless communication link similar to the first communication link. The activity sensor 2204 can provide activity data that describes the activity of the participant 2201 to the second data application via the second communication link. For example, the accelerometer or other suitable sensor of the activity sensor 2204 can capture data indicating the movement or other activity of the participant 2201 and provide the corresponding data to the second data application 2210 via the second communication link. The second data application 2210, in some examples, provides UI data to the activity sensor 2204 via the second communication link. For example, the activity sensor 2204 can include output devices, such as, for example, a lamp, a display screen, a speaker, etc., to transmit the UI data to the participant 2201. The UI data can describe the activity of the participant 2201, such as that captured by the activity sensor 2204.

[0389] In some examples, the first data application 2208 is configured to communicate CGM data to a second data application 2210. The second data application 2210 can then provide the CGM data to the activity sensor 2204 as UI data to be 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 a display of glucose data, such as the participant's current estimated glucose value, and / or metadata such as the direction in which the participant's glucose value is trending, the participant 2201's past glucose values.

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

[0391] To prevent interception of the CGM data, the first data application 2208 and the second data application 2210 can be configured to communicate via a secure communication protocol. Examples of secure communication protocols are described herein with respect to FIG. 22C.

[0392] Exemplary system 2200A also shows links between data applications 2208, 2210 and their respective web service systems 2212, 2214 and coaching server 2216. For example, the first data application 2208 may provide CGM data to web service system 2212. Web service system 2212 may provide the CGM data to coaching server 2216. The second data application 2210 can provide activity data describing the activities of participant 2201 to web service system 2214. Web service system 2214 can provide the activity data to coaching server 2216. Coaching server 2216 can provide guidance to participant 2201. The guidance can be in any of the forms described herein, such as via a chatbot as shown in FIG. 17, as described in FIGS. 12A, 12B, 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 of FIGS. 12A, 12B, 12C, 17.

[0393] FIG. 22C is a flowchart showing an example of a process 2270 that may be executed in system 2200A of FIG. 22B to display CGM data in activity sensor 2204. Process 2270 includes three columns 2271, 2273, 2275. Column 2271 includes operations executed by the first data application 2208. Column 2273 includes actions executed by the second data application 2210. Column 2275 includes actions executed by activity sensor 2204.

[0394] In step 2272, the first data application 2208 receives CGM data from the continuous glucose monitoring sensor 2202. The CGM data may include glucose data such as an estimated glucose value 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 that includes the CGM data. The first data application 2208 can encrypt the data structure using an encryption key. Any suitable encryption technique can be used.

[0395] 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 the error detection code based on the CGM data included 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 to verify that the CGM data was transmitted accurately, as described herein. Some error detection code techniques allow the second data application 2210 to correct transmission errors within the CGM data. Any suitable error detection technique can be used. In some examples, a cyclic redundancy check (CRC) technique is used. The error detection code may or may not be encrypted.

[0396] 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 can provide the CGM message 2277 to the operating system of the user computing device 2206. The operating system can distribute the CGM message 2277 to the second data application 2210. In an example where the CGM data is encrypted, the CGM data may not be readable by the operating system and / or any other application that may intercept the CGM message 2277 between the first data application 2208 and the second data application 2210.

[0397] 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 included with the CGM message 2277. Decryption can be performed using an encryption key. For example, the second data application 2210 can access the same encryption key used by the first data application 2208 to encrypt the CGM data. In other examples, the first data application 2208 encrypts the CGM data using the public (e.g., non-secret) encryption key of the second data application 2210. The second data application 2210 can decrypt the CGM data using its private (e.g., secret) encryption key that is not shared. Processing the CGM message 2277 may also include using an error detection code to verify the accuracy of the CGM data within the CGM message 2277 and / or correct any detected errors.

[0398] In step 2280, the second data application 2210 generates a device CGM message 2279. The device CGM message 2279 includes 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 an error correction code. 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 directly transmit the device CGM message 2279 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.

[0399] In step 2282, the activity sensor 2204 receives the device CGM message 2279. In some examples, the activity sensor 2204 decodes the CGM data included in the device CGM message 2279 and / or performs error detection or correction. In step 2284, the activity sensor 2204 provides a display of 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 the user interface provided to the participant 2201.

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

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

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

[0403] The coaching server 2216 may receive identifiers of eligible coaches from a coach pool 2248 (e.g., managed by an insurance entity or other entity). The coaching server may assign a coach to a particular participant, maintain call records, generate a weekly coaching report, facilitate communication with a user computing device 2206, or facilitate follow - up via a call center 2250. The coaching server 2216 may also generate a report 2252 of adverse events for regulatory, process improvement, or other purposes if an adverse event exists.

[0404] The second system 2214 (or coaching server) may generate push notifications 2254 for delivery to participants via a smart device (e.g., via the second app 2210) or via an activity sensor (e.g., a wristwatch) 2204. The push notification 2254 may indicate, for example, that a new coaching message is available. The second system 2214 may also generate a second push notification 2256, which may communicate a message about glucose concentration value information, such as CGM information, or guidance, or information about the provision, delivery, application (e.g., on the participant's body), exchange, scheduling (e.g., the time or length of wear), or use of a CGM sensor.

[0405] The second system 2214 may also include a permission system 2262 that may provide permission to, for example, the first app 2208, the second app 2210, or both, or provide information to an activity sensor permission system 2260 for use of an API 2258 (e.g., to "activate" an activity sensor on the system). The second system 2214 may also include a glucose value application programming interface (API) 2266 that 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.

[0406] The system may also include a group system 2264 that may include group information, such as an identifier of a participant that may be used, for example, in a web API 2258 or for sensor execution to facilitate delivery of the activity sensor 2204 to the participant 2201.

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

[0408] FIG. 24 shows an example of a continuous glucose monitoring (CGM) system 2400 in which a coaching server 2412 is operated by a coaching staff to assist in a coaching service and provide the coaching service to a patient using the CGM system 2400. A portion of the reference to the coaching server 2412 may refer to the staff 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 can be a dedicated display device or a smartphone or other display device configured to transmit and receive data and communications within the CGM system 2400. The transceiver 2404 can transmit some or all of the patient's analyte data to a cloud computing architecture 2410 for future reference, further processing, record keeping, or other purposes related to the management or improvement of the patient's health.

[0409] The cloud computing architecture 2410 may include one or more health data servers configured to receive patient analyte data. The transceiver 2404 and / or the cloud computing architecture 2410 can receive patient analyte data and generate a self-referencing data structure from which more meaningful patient analyte data can be displayed or analyzed. For example, the measurements of the CGM 2402 can be used to generate a self-referencing data structure for displaying the patient's analyte data in a meaningful and understandable graphical display for use by the patient and / or a coaching person operating the coaching server 2412. The display self-referencing data structure can include a table encoded with flagged analyte sensor data so that the self-referencing data structure can be used to independently generate various analyte trend displays on demand without querying multiple databases to collect the data necessary to generate the desired graphical display.

[0410] In some aspects according to the systems, devices, and methods of the present disclosure, aggregation, structuring, and / or transformation of health-related data and non-health-related data is performed to intelligently generate outputs such as construction, display of new analysis data, and control of the devices of the system and the devices of other systems. Such health-related information can include glucose and related data (e.g., insulin, diet, activity, etc.), and non-health-related data can include location data, user demographic data, etc. Implementations according to such aspects of the present technology are thought to speed up the operation of the system, for example, by reducing the complexity in data processing and data transmission between devices, reducing the amount of data and processing algorithms to be stored and operated on, thereby speeding up the performance of the systems described herein. Further, implementations according to such aspects of the present technology are envisioned to improve the user's ability to manage their diabetes or other disease through continuous analyte monitoring.

[0411] Some of the advantages of the described method and system may include the following. The self-referential data structure eliminates the need for the processor to search for and call the necessary information from various parts of the system to generate a graphical display. Otherwise, for example, without the self-referential data structure, the processor would need to search, query, and / or call various parts of the system each time the user requests a different graphic or requests a modification of the displayed graphic. Thus, the self-referential data structure improves the operation of the system by reducing the complexity of data processing and data transmission between various parts of the system. For example, using the self-referential data structure, the system does not need to store or process additional algorithms, such as pattern recognition algorithms, to generate outputs such as displays for communicating pattern information to the user. Further, the self-referential data structure can reduce the amount and frequency of data transmitted for the purpose of generating a graphical display. Accordingly, the associated processing or graphing algorithms that are stored and manipulated are also reduced, improving the performance of the system.

[0412] The transceiver 2404 can execute an analyte sensor application 2405. The analyte sensor application 2405 can facilitate the connection between a coach 2412 and a patient using the CGM system 2400 and can provide other services related to the CGM system 2400, such as providing alarms, displays, monitoring, storage, and other functions. With appropriate legal and privacy permissions obtained, the coach 2412 can access the patient's data on the transceiver 2404 or the cloud computing architecture 2410 to better support the patient in their diabetes management. The analyte sensor application 2405 may include a coaching module 2414 that can handle tasks related to providing automated or semi-automated coaching to the patient.

[0413] FIG. 25 illustrates an exemplary coaching system 2500 that can be used to implement automatic and semi-automatic 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, algorithms that provide coaching assistance to a patient in one or more areas that affect 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 handhold the patient in one or more of those modules, an exercise module 2506 designed to encourage and guide the patient when engaging in exercise and physical activity, a diet module 2508 designed to assist the patient in better understanding the relationship between diet choices and blood glucose levels, and a sleep module 2510 designed to monitor and manage blood glucose levels to avoid diabetic complications while prompting and guiding the patient to get good quality sleep. The sub-coaching modules described are intended as examples and are not meant to be limiting. One of ordinary skill in the art can envision other sub-modules of the coaching module 2502 that can provide support, education, monitoring, and coaching for various skills or activities beneficial to the management and improvement of diabetes. The coaching module 2502 can communicate with a coaching server 2512 to provide coaching services to patients of the CGM system 2400. The coaching server 2512 can be operated, in part or in whole, by a human operator who has received training in coaching diabetic patients.

[0414] The coaching module 2502 and its sub-modules provide coaching by suggesting activities to generate engagement in activity execution (e.g., by scheduling the time and / or location for activity execution), setting goals (e.g., by requiring the patient to engage in activity execution over a desired number of repetitions, or by refraining from activity for several days), monitoring results (e.g., by examining one or more relevant glucose trend graphs), eliciting alternative approaches to activities in the case of sub-optimal results (e.g., going for a walk closer to meal times when the PPW glucose value has not improved despite walking), and providing coaching by repetition. The coaching module 2502 provides alarm, scheduling, reminder, and follow-up services to continuously encourage and monitor the patient's progress, interest, and engagement. The coaching module 2502 can provide a blessing message when the results are good, a message to boost motivation and / or morale when the results are not satisfactory, and can alert the coach when the results are concerning or do not meet the criteria.

[0415] Initializer module When newly setting up a patient with the CGM system 2400, there is also an opportunity to use automated coaching to set up the patient and provide opportunities for preliminary general or specific education about diabetes and techniques and approaches for living with diabetes. FIG. 26A shows an exemplary process 2600A executed by the initializer module 2504. Process 2600A can be initiated in step 2602A via the patient's actions (e.g., by entering a desire to run or enroll in a coaching program via a touch screen or other input device connected to the analyte sensor application 2405). Process 2600A can be automatically initiated 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", the process 2600B of FIG. 26B is executed. If the answer is "yes", process 2600A proceeds to step 2606A and displays a message containing general educational information about blood glucose values, their meaning, their behavior, and the purpose of the coaching program. The coaching module 2502 and its sub-modules can use spoken language and / or simple conversational language to remove the potential for confusion, increase interest in the coaching program, and create a friendly and relaxed attitude and relationship between the patient and the coaching program. For example, the information displayed in step 2606A can include "Blood glucose levels are not constant and change. They can go up and improve, or they can go down."

[0416] Next, the process proceeds to step 2608A to generate a graphical display of the patient's analyte data (e.g., a glucose trend graph related to the patient's glucose values over the past few hours). Along with the graphical display of the patient's analyte data, the process can display an educational graphic that demonstrates what may be considered a "spike" in the analyte data or variability. The educational graphic can include animations, text, or other visual displays to convey information to the patient and to display to the patient the patient's glucose trend graph and a general glucose trend graph of the samples (if the patient's glucose trend graph is not available). If the initializer module 2504 is available, this module can query and call a self-reference data set related to the patient's most recent data, generate an analyte trend graph from the self-reference data set, and display the graph to the patient. The self-reference data set can be called from storage on the transceiver 2404 or the cloud computing architecture 2410.

[0417] In step 2610A, the process can prompt the patient to examine their analyte trend graph and determine whether spikes or variability in the analyte data can be observed. If the answer is "no", the process proceeds to step 2612A, where a message or graphic is displayed that blesses the patient and continues to prompt the patient to monitor their blood glucose levels and engage in healthy behaviors. The process then proceeds to process 2600B in FIG. 26B. In step 2610A, if the patient indicates that they observe a spike or undesirable variability in the analyte data, process 2600A proceeds to step 2614A and asks the patient whether they can recall an event or situation prior to the spike or undesirable variability occurring. Thus, the patient is prompted to think about their choices, situations, or environment and recognize what is affecting their health. If the patient recalls that event E occurred prior to the spike, the process proceeds to step 2616A, where a message is displayed that emphasizes the relationship between event E and the patient's blood glucose levels and then prompts the patient to pay attention to this relationship when event E occurs again. The process then proceeds to process 2600B in FIG. 26B. If the patient does not recall what happened prior to the spike they observed in the analyte data, process 2600A proceeds to step 2618A. A message is displayed that prompts the patient to learn about the impact of various activities, situations, and life events on their blood glucose levels using the tools and sub-modules provided by coaching module 2502. The process then proceeds to process 2600B in FIG. 26B.

[0418] Consider an example where a patient is experiencing early morning hyperglycemia events. The coaching module may be prescribed a drug to be taken by the patient in the early morning (e.g., access to data in cloud computing architecture 2410). Process 2600A may proceed to step 2610A where an early morning spike is detected as described above. In step 2614A, coaching module 2502 can query the patient as to whether the patient is still taking the drug prescribed at a specified time in the morning. If the patient is taking the drug, coaching module 2502 can be configured to display an encouraging message (e.g., in step 2618A) or to further query the patient about other events that may cause a spike. If the patient is not taking the drug, coaching module 2502 can be configured to display a message prompting the patient to resume taking the drug in step 2616A.

[0419] Figure 26B shows an exemplary process 2600B executed by initializer module 504. The process starts at step 2602B, proceeds to step 2604B, and displays educational information regarding the safe range of blood glucose levels. The patient may be provided with information regarding multiple safe blood glucose levels depending on the situation the patient may encounter. For example, the educational information displayed may be "The safe blood glucose range varies based on an individual's situation, but generally should be 70 - 180 after meals and drop below 130 a few hours after meals. Before bedtime, it should be 100 - 140." The educational information displayed regarding the safe range can warn the patient to use a custom range if the patient is receiving a prescription from the patient's physician. The educational information displayed may further include an overview of the tools available in coaching module 2502 to support the patient in keeping the blood glucose level within the safe range.

[0420] The patient is further encouraged to frequently check their blood glucose levels, and to check more frequently after activities that affect blood glucose levels. For example, the patient is instructed to check their glucose measurements before and after meals, after physical activity, when stressed, or before bedtime. Another time when checking glucose levels is recommended is when calibrating the CGM 2402. If the patient can become accustomed to checking their blood glucose levels more frequently, the patient will have a better and increased opportunity to observe and learn the effects of various choices and activities on their blood glucose levels. This process can proceed to step 2606B, where the patient can be asked to estimate their current blood glucose level. The coaching module 2502 and its sub-modules can use fun and engaging questions to encourage further patient participation. The patient can enter an estimated value of their current blood glucose level via an interesting and engaging graphical display, such as a slider bar, scroll bar, text and arrows, or other visuals designed to operate using touch screen or voice recognition technology. Next, the process proceeds to step 2608B, where the patient is presented with their most recent glucose trend graph, which may include a display of the actual current glucose value. The patient is prompted to examine the trend graph and observe their current blood glucose level and its most recent values.

[0421] Next, the process proceeds to step 2610B, where the patient is prompted to analyze the glucose graph to examine whether spikes or variability can be observed in the glucose data. Next, the process proceeds to step 2612B, where the patient is questioned about activities that affect the blood glucose level. The patient can be presented with a plurality of options, such as "diet, exercise, sleep, or all of the above". In this example, since all of the presented answers are true, the correct answer is "all of the above". If the patient responds with an answer other than "all of the above", the process proceeds to step 2614B, where an encouraging message is displayed indicating that all of the options can affect the blood glucose level and that the coaching module can guide the patient step by step through each activity. Next, the process proceeds to step 2618B. If the patient responds by indicating that all of the listed activities can affect the blood glucose, the process proceeds to step 2616B, where a congratulatory and encouraging message is displayed, along with a message prompting the patient to select the correct answer. The displayed message can state that the coaching module can guide the patient by learning and understanding each of the listed factors and their impact on the patient's blood glucose level. Next, the process proceeds to step 2618B, where the patient is questioned about the activity or skill that the patient wants to learn first. If the patient does not make a selection or shows a lack of interest or motivation, the process proceeds to step 2620B, where a coaching alert ticket is generated and sent to the coach via the coaching server 2512. Then, the process ends in step 2626B. If the patient selects one of the presented activities or skills and shows interest, the process proceeds to step 2622B, where a message congratulating the patient's enthusiasm is displayed. Then, the process moves to the sub-module selected by the patient. For example, if exercise, diet, or sleep is selected, the corresponding exercise module 2506, diet module 2508, or sleep module 2510 is called and executed by the coaching module 2502, respectively. Next, the process proceeds to step 2624B, where the coaching server 2512 is updated to reflect the activity module selected by the patient.In some embodiments, the coaching personnel operating the coaching server 2512 can manually assign a sub-coaching module and update the coaching server 2512 accordingly. The process then ends at step 2626B.

[0422] Generally, the coaching module 2502 can be configured to generate a coaching alert ticket and notify the coaching personnel when the patient's response and interaction with the patient indicate a lack of interest, motivation, or engagement. Living with diabetes can be difficult. Responses indicating a lack of interest and engagement may indicate symptoms of depression or that the patient may need psychological or mental support to cope with the challenges of living with diabetes. As part of generating the coaching alert ticket, the coaching module 2502 or its sub-module can collect relevant context information to assist the coaching personnel in responding to the patient efficiently and promptly. For example, in response to an activity where the patient shows a lack of enthusiasm, the coaching module 2502 can present questions to the patient and obtain answers related to providing coaching and counseling regarding the activity.

[0423] The coaching module can further annotate, label, and classify the patient's context information, so that the coaching staff can provide counseling and coaching services more efficiently and effectively. For example, if the patient started a healthy activity as predicted but could not achieve the predicted goal, the context information used to build the coaching alert ticket may include a label stating that "the maximum effort was made but it could not be achieved". On the other hand, if the patient refuses to schedule an activity and the patient's response indicates a lack of trust in the proposed activity, the context information may include a label stating that "the patient does not believe in the proposed activity". The coaching staff operating the coaching server 2512 can examine the context information labels to efficiently and timely check the patient's medical history and current problems. In some embodiments, the coaching staff operating the coaching server 2512 can provide coaching and support to the patient specializing in a particular field. For example, some coaching staff may specialize in providing counseling and coaching to patients lacking dietary monitoring discipline and may have received special training. The context information labels can be used to transfer coaching alert tickets to coaching staff specializing in dealing with root problems.

[0424] The overall theme of notifying the interaction between the coaching module 2502 and the patient is, for example, to encourage involvement with the CGM system 2400 and the coaching module 2502 by using the provided tools and observing the analysis and advice of the tools related to the patient's blood glucose value. Such involvement can increase the patient's understanding of the disease and improve the patient's intuitive response to the patient's condition.

[0425] Exercise module The coaching module 2502 may include an exercise module 2506 to encourage and instruct a patient to engage in physical activity and observe the benefits and correlations between the physical activity and improved glucose values. FIG. 27 shows a process 2700 that can handhold a patient using an automated or semi-automated coaching system sub-module focused on exercise and physical activity. Beneficial exercise and physical activity for diabetic patients can be as simple as taking a walk after a meal. Postprandial walk (PPW) can be an area of focus for coaching, and process 2700 of FIG. 27, process 2800 of FIG. 28, and process 2900 of FIG. 29 are described in relation to PPW. One of ordinary skill in the art can envision other types of physical activity or exercise that can be implemented using processes 2700, 2800, and 2900 without departing from the spirit of the described technology.

[0426] Process 2700 begins at step 2702. The exercise module 2506 can educate the patient about the beneficial effects of physical exercise on blood glucose values and recommend exercise as a way to keep blood glucose values within a safe range. The process proceeds to step 2704, where the patient is questioned about previous experience with the recommended physical activity, such as PPW. If the patient indicates that they have not tried PPW, the process proceeds to step 2706, where the patient is asked whether they would like to select a future meal to perform PPW. If the patient shows a lack of interest, the process proceeds to step 2708, where additional context information is obtained from the patient or from the patient's records within the cloud computing architecture 2410 and / or transceiver 2404. At step 2710, a coaching alert ticket is generated and sent to the coaching server 2512 to notify the coaching staff. The process ends at step 2712. The same process can be repeated, and a coaching alert ticket can be generated and sent whenever the patient's response indicates a lack of interest or willingness to manage or improve their health.

[0427] If the patient shows interest in attempting PPW, the process proceeds to step 2714, where the patient is asked to select a diet and time to perform PPW, whereby the exercise module 2506 can contact the patient again regarding the results. The follow-up reminder is scheduled based on the patient's response. When the follow-up time arrives, the process moves to step 2716 and asks the patient whether they were able to perform PPW as scheduled and about the results. If the patient's response indicates non-implementation or unexpected results after PPW implementation, the process can execute steps 2708 and 2710 to collect information, generate, and send a coaching alert ticket. The process ends at step 2712. If the results of the PPW were successful, the process proceeds to step 2720 and asks the patient whether they want to repeat the success achieved by scheduling more PPW sessions.

[0428] The success or failure of a PPW session can be determined by presenting the patient with a question and presenting multiple answer options such as "What happened to the blood glucose level?", "It rose more gradually", "It did not rise as high as expected", "It did not change", "It rose slightly", or "It rose significantly". The possible patient response groups can be classified as successful, and if those responses are detected, process 2700 can be determined based on the successful result. Similarly, some responses can be classified as failed results, and if those responses are detected, process 2700 can be determined accordingly. In some embodiments, the success or failure of PPW or other proposed activities can be determined by querying the patient's records in cloud computing architecture 2410, transceiver 2404, or both to automatically determine whether the patient's glucose value was within the safe range after the scheduled PPW session. Alternatively, the patient may be asked to determine the success or failure of a PPW session by manually examining their glucose data in order to learn to interpret their own glucose trend graph or other available glucose data. The analyte data stored within CGM system 2400 can be used as a secondary check, and the patient can be prompted to reevaluate their response or the stored data if a discrepancy is detected. Similarly, whether the patient was able to perform PPW can be determined by presenting the patient with a textual or graphical question or by querying transceiver 2404 as to whether the transceiver 2404 incorporated that option, for example, for global positioning system GPS data.

[0429] If the patient shows no interest in scheduling more PPW sessions, the process can execute steps 2708 and 2710 to collect information, generate, and send a coaching alert ticket. The process ends at step 2712. If the patient shows interest in repeating the success achieved by scheduling more PPW sessions, the process proceeds to step 2722 and schedules future PPW sessions based on the patient's desired times and meals. Next, the process proceeds to step 2724 and executes a follow-up process 2800 as described in connection with FIG. 28 using the scheduled PPW sessions. Then, process 2700 ends at step 2726.

[0430] As described, in step 2704 of process 2700, the patient is asked whether they have previously attempted PPW. If the patient's answer is "yes", the process proceeds to step 2718, where the patient is asked about the results of their previous PPW experience. If the patient indicates a failure or unexpected result, the process may proceed to step 2728, where the patient may be asked whether there is another way for them to be more successful with PPW. The patient can answer by interacting with a menu or other visual interface, such as by free text or by selecting from a drop-down menu or radio buttons in a pre-prepared response menu (e.g., "Take longer walks", "Walk faster", "Take walks closer to meal times"). The process proceeds to step 2730, where the patient is asked whether they want to try one or more of the alternative approaches they just indicated. If the patient responds that they are not interested, the process can collect information by performing steps 2708 and 2710, generate, and send a coaching alert ticket. The process ends at step 2712. If the patient responds affirmatively, the process proceeds to step 2732, where future PPW sessions can be scheduled based on the patient's desired times and meals. Using the scheduled PPW sessions, a follow-up process 2800 as described in connection with FIG. 28 is performed. The process 2700 then ends at step 2734.

[0431] Figure 28 shows a process 2800 for following up on the progress of patients who have been introduced to and scheduled for PPW or other recommended activities beneficial for diabetes management. The process 2800 begins at step 2802. After the arrival of the time of a previously scheduled PPW session, or after a predetermined time has elapsed from the scheduled time, the process proceeds to step 2804 and asks the patient whether the patient was able to perform PPW as scheduled. If the patient responds negatively, the process can execute steps 2806 and 2808 to collect information, generate, and send a coaching alert ticket. The process ends at step 2810.

[0432] If the patient indicates that they were able to perform PPW as scheduled, the process proceeds to step 2812 and asks the patient whether the patient's blood glucose level was within a safe or desirable range after the PPW session. If the answer is "no", the process executes steps 2806 and 2808 to collect information, generate, and send a coaching alert ticket. The process ends at step 2810. If the answer is "yes", the process proceeds to step 2814 and asks the patient for the number of days the patient predicts they will be able to perform PPW. If the patient's response is less than a minimum threshold (e.g., 0 days or 1 day), the process can execute steps 2806 and 2808 to collect information, generate, and send a coaching alert ticket. The process ends at step 2810. If the response is at least the minimum threshold (e.g., 2 days) or more, the process may proceed to step 2816, save the predicted number of days of PPW activity, and send it to a confidence assessor / booster process 2900 as described in connection with Figure 29. The process ends at step 2810.

[0433] As previously shown and stored in the cloud computing architecture 2410, consider an example where a patient has an acceptable A1C value. In this example, the patient has also previously indicated in step 2806 of the previous execution of process 2800 that due to an injury, the patient cannot perform the desired exercise. This data is also stored in the cloud computing architecture and can be used in subsequent executions of process 2800. For example, in step 2804, in addition to asking whether the patient was able to perform the PPW, the patient can be asked whether their injury has healed.

[0434] Figure 29 shows an exemplary process 2900 that can be executed by exercise module 2506 to further track, evaluate, or increase a patient's confidence in the implementation of PPW or other proposed activities beneficial for diabetes. This process starts at step 2902. Exercise module 2506 can track the number of days a patient has implemented PPW. The process proceeds to step 2904 to determine whether the number of days the patient has implemented PPW is equal to or greater than the predicted number of days of PPW implementation. If the answer is "yes", the process proceeds to step 2906, where the patient is asked, on a predetermined scale (e.g., a scale of 0 to 10), about their confidence that they can implement PPW in the next seven days. If the patient's confidence level is greater than a predetermined minimum confidence score (e.g., 7), the process proceeds to step 2908, where a message is displayed to bless the patient for their determination and participation. Then, the process returns to step 2902 and can repeat process 2900 after one week or another predetermined period. If the patient's confidence level in their ability to implement PPW is less than the predetermined confidence score (e.g., less than 7), the process proceeds to step 2910, where the patient can be asked if there is anything that can be done to increase the patient's confidence level so that they can achieve the scheduled number of PPW implementations. If the answer is "no", the process executes steps 2918 and 2920 to collect information, generate, and send a coaching alert ticket. The process ends at step 2922. If the answer is "yes", the process proceeds to step 2912, where the patient is asked to enter a plan for successfully implementing the scheduled number of PPW. The process proceeds to step 2914, where the patient can be asked if they think they can follow the plan. If the answer is "yes", the process proceeds to step 2916, where the patient's PPW is tracked daily or the PPW is obtained after a predetermined time (e.g., one week), and then the process moves to step 2902 and repeats process 2900. If the answer is "no", the process can execute steps 2918 and 2920 to collect information, generate, and send a coaching alert ticket.This process ends at step 2922.

[0435] In step 2904, if it is determined that the number of days of the patient's PPW implementation is less than the scheduled number of days, the process proceeds to step 2924. If the number of days of the patient's PPW implementation is less than or equal to a predetermined minimum number (e.g., 2 days or less), the process executes steps 2918 and 2920 to collect information, generate, and send a coaching alert ticket. This process ends at step 2922. If the number of days of the patient's PPW implementation is more than the predetermined minimum number (e.g., more than 2 days), the process proceeds to step 2926 and asks the patient whether it is thought that the scheduled number of PPW implementation days can be achieved. If the answer is "Yes", the process proceeds to step 2916, and either tracks the patient's PPW daily or obtains the PPW after a predetermined time (e.g., 1 week), and then the process moves to step 2902 and repeats process 2900. If the answer is "No", the process executes steps 2918 and 2920 to collect information, generate, and send a coaching alert ticket. This process ends at step 2922.

[0436] The coaching module 2502 may include a diet module 2508 that prompts and guides the patient to understand and learn about their blood glucose levels and the effects of dietary choices on diabetes. FIG. 30 shows a process 3000 that can handhold a patient using an automatic or semi-automatic coaching system sub-module focused on diet. The process 3000 starts at step 3002. At step 3004, the patient is asked whether they want to learn about the impact that different foods and dietary choices can have on their blood glucose levels. If the answer is "no", the process performs steps 3006 and 3008 to collect information, generate, and send a coaching alert ticket. The process ends at step 3010. If the answer is "yes", a message to the patient is displayed to encourage the patient's interest and engagement. The message may further remind the patient of the connection and correlation between diet and blood glucose levels. The message may prompt the patient to continue to check their blood glucose measurements in order to learn more about the impact that different dietary choices have on their glucose measurements.

[0437] The process proceeds to step 3012, where it asks the patient to select a meal time M and start learning about the impact of the meal on the blood glucose level. The meal time M selected by the patient is stored, and a reminder can be scheduled to follow up on the patient. The process proceeds to step 3014, where it asks the patient whether they are aware of what they consumed as the selected meal. If the answer is "No", the process proceeds to step 3016, where it displays an encouraging message and notifies the patient that they can use the tools provided in the CGM 2400 system to track their meal content and observe the impact on the blood glucose level. Immediately after the scheduled meal time M or after a predetermined time, the process proceeds to step 3018, where it asks the patient about the impact of meal intake on their blood glucose level. The patient can enter text or select an answer from a series of possible scenarios such as "Rose and stayed the same", "Rose but then immediately dropped", "Didn't change much", or "Dropped". The patient's response can be stored in the variable S. The process proceeds to step 3020, where it asks about what the patient consumed during the scheduled meal M. The patient can enter free text or select from an available option menu to describe the meal they consumed, and the answer can be stored in the variable F.

[0438] The process proceeds to step 3022, where it displays a message that links the patient's meal M and the patient's blood glucose level S through a text step or other graphical or visual display. The message can be a sentence with the values stored in the variables M, F, and S automatically filled in. For example, the message could be "Meal <m>Sometimes <f>After eating, the blood glucose level is <s>It can be constructed from the sentence "」. If F = chocolate cake, M = breakfast, and S = rose and remained as it was, the displayed message can be read as "At breakfast, eating chocolate cake caused the blood glucose level to rise and remain as it was." Various messaging formats and scenarios can be used to improve the patient's understanding and learning about the effects of food and diet on the patient's blood glucose level.

[0439] The process then proceeds to step 3024 and asks the patient whether they were surprised by the result. If the answer is "No", the process can proceed to step 3026, bless the patient for continuing to track their glucose level after meals, and encourage them to continue checking their post-meal glucose levels. The process then proceeds to step 3028 and encourages the patient to use a meal tracking tool to track more meals and the effect of meals on the patient's glucose level. The meal tracking tool is described in connection with process 3100 of FIG. 31. The process ends at step 3030. If the patient is surprised by the result of their glucose measurement and the patient's answer at step 3024 is "Yes", the patient may need additional or individual guidance regarding the type of food and meals and their effects on diabetes. The process can execute steps 3006 and 3008 to collect information, generate, and send a coaching alert ticket. The process ends at step 3010.

[0440] In step 3014, if the patient knows what they will consume at the scheduled meal time M, the process proceeds to step 3032 and stores the patient's planned meal in variable F. Immediately after the scheduled meal time M or after a predetermined time, the process proceeds to step 3034 and asks the patient about the effect of consuming food F in meal M on the patient's blood glucose level. The patient's answer can be stored in variable S. The process proceeds to step 3036 and displays a message constructed from variables M, F, and S. For example, the message is "Meal <m>At times <f>After eating, the blood glucose level is <s>The sentence "」, variable F = grilled fish, whole grain bread toast, and garden salad, M = lunch, and S = decreased, can be constructed. The displayed message can be read as "After eating grilled fish, whole grain bread toast, and garden salad for lunch, blood glucose decreased". Next, the process proceeds to step 3024, and the patient is prompted to use the meal tracking tool in FIG. 31 to deepen the understanding of the correlation between meals and blood glucose.

[0441] Figure 31 illustrates an exemplary process 3100 that may be performed by the diet module 2508 to implement a diet tracking tool that prompts and guides a patient in understanding the relationship between diet and blood glucose levels. Process 3100 begins at step 3102 via an input from a user indicating interest in starting operation of the tool, or by a complementary process or tool such as process 3000. Process 3100 proceeds to step 3104 where the patient is asked to schedule a meal M to be tracked. The patient's selection is stored and a reminder is scheduled for a predetermined period T after the scheduled meal M. T can be, for example, 1 to 2 hours. The process proceeds to step 3106 where it waits for the predetermined time T after meal M. The process proceeds to step 3108 where the patient is questioned about the content consumed in the scheduled meal M and the patient's response is stored in variable F. Next, the process proceeds to step 3110 where the patient's glucose data is obtained for the period before meal M and the period after meal M + the predetermined time T. Glucose data for the relevant period can be obtained from the patient, and the patient can examine a glucose trend graph obtained from the patient for the relevant period or from other parts of the CGM system 2400 such as the transceiver 2404 or the cloud computing architecture 2410. The glucose data is presented to the patient and the process moves to step 3112 where the patient is questioned whether they observed a spike or undesirable variability in the glucose data. In other embodiments, the diet module can automatically examine and scan the glucose data for variability by comparing the stored glucose values to a high or low threshold. If there is no spike or undesirable variability in the glucose data, the process proceeds to step 3114 where a message is displayed prompting the patient to continue checking their blood glucose levels and learn about safe ways to eat. For example, the message can be "OK. Each time you check your glucose after a meal, please continue to learn about safe and enjoyable ways to eat."

[0442] If the patient observes a spike or variability in their blood glucose levels and the patient's response in step 3112 is "yes", the process proceeds to step 3118 and asks the patient whether they can consume another food that may have a better effect on their blood glucose levels. If the patient shows a lack of interest or knowledge about other methods, the process can execute steps 3120 and 3122 to collect information, generate, and send a coaching alert ticket. The process ends in step 3124. If the patient responds by showing the ability to make better dietary choices, the process proceeds to step 3126 and asks the patient further questions to assist in determining the patient's determination and interest. For example, in step 3126, the patient may be asked to enter into the system another method that they can do next time (e.g., future dietary choices of the patient). The process proceeds to step 3128 and determines whether the planned patient's choice is the same as or different from their previous choice that resulted in an undesirable variability in blood glucose levels. If the planned patient's choice is the same as or similar to the previous choice, the process can execute steps 3120 and 3122 to collect information, generate, and send a coaching alert ticket. The process ends in step 3124. If the patient's choice is different from their previous choice and indicates a plan aimed at maintaining a safe blood glucose level, the process can proceed to step 3104 to schedule a follow-up meal tracking session, and process 3100 is repeated.

[0443] Figure 32 shows an exemplary process 3200 that can be implemented in the meal module 2508 to encourage and guide a patient who attempts to monitor postprandial blood glucose by using the meal tracking tool described in relation to Figure 31. The process 3200 can be automatically executed at a predetermined time interval (e.g., weekly) or manually executed by the patient and started at step 3202. The meal tracking tool implemented via the process 3100 can continue to track the number of times the tool is used and / or the number of meals tracked by the patient and is configured to store it in the variable MT (Meals Tracked). By default, the system can specify the desired number of meals to be tracked in the variable D, or ask the patient, the patient's guardian, medical professional, and / or coaching staff about the patient's expected number of meals to be tracked and store the value in the variable D. At step 3204, the number of meals tracked MT by the patient is compared with the desired number of meals to be tracked or the expected number of meals to be tracked D. If the number of meals tracked MT is greater than or equal to the expected number of meals to be tracked D, the process proceeds to step 3206 to display a congratulatory message, and the process ends at step 3208. At step 3210, if the number of meals tracked MT is less than the expected number D but more than half of the expected number D, the process proceeds to step 3212, and the meal module 2508 can be configured to send reminders, offers, and guidance to the patient to track meals and check glucose data. The process ends at step 3214. If the number of meals tracked MT is less than or equal to half of the desired number D, the patient may need more individualized guidance to increase the patient's effort to track meals and check glucose data. The process can execute steps 3216 and 3218 to collect information, generate, and send a coaching alert ticket. The process ends at step 3220.

[0444] Sleep module FIG. 33 shows an exemplary process 3300 that can be implemented by the sleep module 2510 to monitor a patient's nocturnal glucose behavior and encourage and guide the patient to better understand the beneficial effects of proper sleep on the patient's blood glucose levels. Process 3300 begins at step 3302. At step 3304, the process displays general data and / or patient-specific data regarding the relationship between sleep and blood glucose. For example, such a display could be something like "The better you sleep, the safer / healthier you are. Keeping glucose within range (e.g., 100 - 140 mg / dL) during sleep helps for better sleep and improves how you manage diabetes." The process then proceeds 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 and determine the number of nights in which the patient's glucose levels were within the safe range during the first few hours of sleep. In some embodiments, the sleep module 2510 can automatically determine whether the patient's glucose levels were safe during the relevant period. In some examples, machine learning techniques described herein can be used to generate a model of the relationship between the patient's sleep and blood glucose.

[0445] In the context of providing automated coaching, it may be desirable to encourage the patient to examine their glucose trend graph and learn how to read and correctly interpret the glucose data and graph, rather than simply determining risky glucose variability. Other safety and monitoring tools and modules within the CGM 2400 can perform these tasks more appropriately. Thus, in the context of providing automated coaching, the ability of the CGM system to automatically analyze the patient's glucose data is used secondarily and can double-check the patient's analysis and decisions. The patient's analysis and interpretation of their own glucose data can be compared to the CGM system 2400's automated analysis, and if a discrepancy is detected, the patient, the coach, or other relevant parties can be notified.

[0446] In step 3308, if the number of nights of the patient's glucose value is within the safe range, the process proceeds to step 3310, where a message is displayed blessing the patient's efforts and prompting the patient to continue to check the glucose value and trend during the night or during sleep. The process ends at block 3312.

[0447] In step 3314, it is determined whether the patient's nighttime glucose value has been safe for at least 5 or 6 nights. If the answer is "no", the process proceeds to step 3316, where it is determined whether the patient's nighttime glucose value has been safe for at least 3 or 4 nights. If the answer is "no", the patient may need more individualized or immediate coaching support to better manage their blood glucose levels during sleep. The process performs steps 3318 and 3320 to collect information, generate, and send a coaching alert ticket. The process ends at step 3322.

[0448] In step 3314, if it is determined that the patient's nighttime glucose value has been within the safe range for at least 5 or 6 nights, the process proceeds to step 3324, where the patient is asked whether they took any different actions on the nights when their glucose remained within the safe range. If the patient does not remember or is unsure, the process proceeds to step 3326, where a message is displayed prompting the patient to track their nighttime glucose value for the next 7 days (or other period that may be desired 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 think their glucose value will remain within the safe range. The patient's answer is stored in the variable NP (Night Predicted). In step 3330, if the predicted number of nights is 5 or more, the process proceeds to step 3332. A message is displayed blessing the patient's engagement with their health.

[0449] One week later, the process proceeds to step 3334 and asks the patient to check their blood glucose values for the past seven nights. If the patient's nighttime glucose values remain within the safe range for more than the predicted number of nights NP, the process proceeds to step 3336, where a congratulatory message is displayed, the patient is prompted to continue tracking their nighttime glucose values, and the process ends at step 3338. If the number of nights that the patient's nighttime glucose values have remained within the safe range is less than the predicted number of nights NP, the process proceeds to step 3340, where an encouraging message is displayed that identifies the challenges the patient may have faced and prompts the patient to discuss those challenges with their coach. The process collects information by performing steps 3318 and 3320, generates a coaching alert ticket, and sends it. The process ends at step 3322.

[0450] At step 3330, if the patient predicts that their glucose values will remain within the safe range for less than five nights, the process proceeds to step 3342 and displays a message prompting the patient to discuss with their coach the possible challenges that could affect their ability to maintain safe nighttime glucose values. The process then collects information by performing steps 3318 and 3320, generates a coaching alert ticket, and sends it. The process ends at block 3322.

[0451] If the patient's nighttime glucose values have been within the safe range for at least three to four nights at step 3316, the process proceeds to step 3344. The patient is monitored more closely by the sleep module 2510. For example, at step 3344, the patient may be prompted to enter whether they predict that their nighttime glucose values will be within the safe range for that night, either in the morning or at a certain time before bedtime. The process is repeated over a period of one week or other desired period, and the predicted number of nights NP is counted and remembered. The process then proceeds to step 3334.

[0452] In step 3324, if the patient is aware of what has changed to enable maintaining safe nighttime glucose, the process proceeds to step 3346 and asks the patient about the differences between the safe night and other nights. Record the patient's responses. In step 3348, display a message blessing the patient's forward, actively engaged attitude. The process proceeds to step 3350 and asks the patient if they are prepared to achieve the same level of success next week in having a safe nighttime glucose value. If the patient's answer is "yes", the process proceeds to step 3328. If the patient's answer is "no", the patient may not have much confidence in their ability to maintain a safe nighttime glucose value. The patient may need more individualized coaching to increase their confidence level. The process executes steps 3318 and 3320 to collect information, generate, and send a coaching alert ticket. The process ends in block 3322.

[0453] The information collected to provide automated or semi-automated coaching (e.g., the information collected in processes 2600A, 2600B, 2700, 2800, 2900, 3000, 3100, 3200, and 3300) can be obtained from the patient as described above, or from other data available in the CGM system 2400, or can be inferred. For example, a patient's behavior during a pre-scheduled activity can be inferred from the global positioning system (GPS) data of the transceiver 2404, or from the patient's glucose data stored in the transceiver 2404 or the cloud computing architecture 2410. The patient can be asked to confirm whether the automatic determination of an event is correct. For example, the coaching module 2502 can automatically detect in-range blood glucose values for a period after a PPW session. The coaching module 2502 can present a glucose trend graph for the relevant period to the patient and request that the patient confirm that the glucose values were in range during that period. If appropriate permission is obtained, the coaching module 2502 can determine that the patient went for a walk during the period scheduled for the PPW activity by examining the GPS data stored in the transceiver 2404. The coaching module can confirm this determination to the patient.

[0454] In some examples, the analyte sensor system can be configured to perform high-fidelity data collection, and the captured data is incorporated after collection. This can be useful for patients who do not have access to a wireless network and / or do not always carry a smart device or other user computing device. Incorporating the data after collection can also minimize or eliminate the need for the user to set up a smart device to communicate with the analyte sensor system. This can potentially enable a clinician to provide access to the analyte sensor to patients at a lower training cost.

[0455] FIG. 34 is a diagram of an exemplary system 3400 that can include an analyte sensor system 3402 configured to upload analyte data captured after collection. The analyte sensor system 3402 can be coupled to a host 3401 similar to host 101 of FIG. 1. The analyte sensor system 3402 can be similar to the analyte sensor system 102 of FIG. 1. For example, the analyte sensor system 3402 can include an analyte sensor 3404 such as a glucose sensor. The sensor electronics 3406 can be similar to the sensor electronics 106 of FIG. 1. The sensor electronics 3406 can include data storage hardware for storing analyte data captured by the analyte sensor 3404. The sensor electronics 3406 can also be programmed to upload analyte data captured after collection, as described herein with respect to FIGS. 35-37, for example.

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

[0457] Exemplary system 3400 also includes an upload device 3450. The upload device 3450 can be, or can include, any suitable computing device configured to communicate with an analyte sensor system 3402 (e.g., its sensor electronics 3406) via a wireless communication signal 3410. In some examples, the upload device 3450 is remote from the host 3401 while analyte data is being collected by the analyte sensor system 3402. In some examples, the analyte sensor system 3402 (or only its sensor electronics 3406) 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 can be located at a pharmacy, a hospital, or other suitable 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 analyte data downloaded to one or more of the server systems 3425, 3426, 3427 via the network 3424. The server systems 3425, 3426, 3427 can be similar to the server systems 125, 126, 127 described herein.

[0458] FIG. 35 is a flowchart illustrating an example of a process 3500 that may be performed by an analyte sensor system 3402 (e.g., its sensor electronics 3406) to collect and upload analyte data. At step 3502, the sensor electronics 3402 detects that the analyte sensor system 3402 has been applied to the host 3401. The 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 measurements that exceed a threshold over two different 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 that exceeds a threshold (e.g., 60 mg / dL) over two different 30-second periods. In some examples, the sensor electronics 3406 detects the application of the analyte sensor system 3402 when the analyte sensor 3404 detects an estimated glucose value that exceeds a threshold (e.g., 60 mg / dL) over two consecutive 30-second periods.

[0459] In some examples, the sensor electronics 3406 receives the serial number of other sensor identifiers of the analyte sensor 3404 and appropriately calibrates, for example, the analyte data received from the analyte sensor 3404. The sensor electronics 3406 can receive the sensor identifier in any suitable 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 suitable type of wired or wireless communication link can be used, such as, for example, a Bluetooth LE connection, 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 irradiate the RFID circuit with electromagnetic radiation, which can 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 the smart device 3412, for example, as described herein. In examples where blind analyte measurements are made, step 3504 can be omitted.

[0460] In step 3506, the sensor electronics 3406 periodically receives analyte data from the analyte sensor 3404 and stores the received analyte data, for example, in data storage hardware that is in communication with the sensor electronics 3406. The analyte data can include analyte values and / or metadata that describe the host 3401 and / or diagnostic data that describes the performance of the analyte sensor 3404. The sensor electronics can receive and store the analyte data at any suitable interval, such as, for example, every 30 seconds, every 5 minutes, or any other suitable period. In some examples, the sensor electronics 3406 is programmed to prompt the analyte sensor 3404 to provide analyte data. For example, such prompting can be done once per period. In an example 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 analyte data to the smart device 3412 (e.g., to the host 3401) for display.

[0461] In step 3508, the sensor electronics 3406 determines whether the use of the analyte sensor 3404 has ended. The use can end, for example, when the sensor usage period has expired. For example, the analyte sensor 3404 can be configured to be used during a specified usage period (e.g., one week, ten days, etc.). The use of the sensor can end when the sensor has been used over its entire usage period. In other examples, the use of the analyte sensor 3404 can end when the sensor is detached from the host 3401 or otherwise malfunctions. For example, if the sensor electronics 3406 cannot receive analyte data within a range defined by exceeding a threshold number of measurements, it can be determined that the analyte system 3404 has malfunctioned.

[0462] If the use of the analyte sensor 3404 has not ended, the sensor electronics 3406 can continue to periodically receive and store analyte data in step 3506. If the use has ended, the sensor electronics 3406 can enter the upload routine in step 3510. An exemplary upload routine is described herein with respect to FIGS. 36 and 37.

[0463] FIG. 36 is a flowchart showing an example of a process 3600 that can be executed by the sensor electronics 3406 to upload the collected analyte data. Process 3600 is one exemplary method by which the sensor electronics 3406 can upload the collected analyte data in step 3510 of process 3500.

[0464] When the use of the sensor is complete, in some examples, the analyte sensor device 3402 (or in some examples, only the sensor electronics 3406) is mailed or otherwise physically transported to where the upload device 3450 is located. In the example of FIG. 36, the sensor electronics 3406 initiate a broadcast of 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, and the like.

[0465] When the sensor electronics 3406 are within the 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 determine, for example, whether a request to establish a communication link with the upload device 3450 has been received. If such a request is not received, the sensor electronics 3406 can continue to broadcast the system identification data in step 3602.

[0466] When a communication request is received in operation 3604, the sensor electronic device 3406, in step 3608, establishes a communication link with, for example, the upload device 3450. In some examples, establishing the 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 may be by any suitable wired or wireless technology such as, for example, Bluetooth, Bluetooth LE, MICS, NFC, etc. Once the communication link is established, the sensor electronic device 3406 can, in operation 3610, initiate the upload of the collected analyte data to the upload device 3450. The upload device 3450 can then upload the uploaded analyte data to one or more of the servers 3425, 3426, 3427 for further consideration. For example, the analyte data collected in this way may constitute high-fidelity data that can be used, as described herein, in combination with, for example, low-fidelity data.

[0467] FIG. 37 is a flowchart showing another example of a process 3700 that may be performed by the sensor electronic device 3406 to upload the collected analyte data. Process 3700 is another exemplary method by which the sensor electronic device 3406 can upload the collected analyte data in step 3510 of process 3500. As described herein, when the use of the sensor ends, the analyte sensor device 3402 (or in some examples, only the sensor electronic device 3406) is mailed to where the upload device is located or otherwise physically transported.

[0468] In the example of FIG. 37, when the use of the sensor ends, the sensor electronics 3406 determines at 3702 whether it has received an upload request (e.g., from the upload device 3450). The upload request can be transmitted using any suitable wired or wireless communication protocol. In some examples, a wireless protocol such as NFC is used, but other protocols such as Bluetooth, Bluetooth LE, MICS can also be used. If no upload request is received, the sensor electronics 3406 continues to wait for an upload request at operation 3702.

[0469] If an upload request is received at operation 3702, the sensor electronics 3406 broadcasts system identification data at step 3704. At 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 can receive the system identification data and use the system identification data to retrieve the authentication data of the sensor electronics 3406. The upload device 3450 can 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 at step 3708. The upload device 3450 can then upload the uploaded analyte data to one or more of the servers 3425, 3426, 3427 for further consideration. For example, the analyte data collected in this way can constitute high-fidelity data that can be used, for example, in combination with low-fidelity data as described herein.

[0470] Recommendation for cost-effective treatment In one or more implementations, treatment costs are utilized as a factor for determining treatment recommendations for a patient. For example, consider FIG. 38 showing a system 3800 for generating cost-effective treatment recommendations. The system 3800 includes a treatment recommendation module 3802 that generates treatment recommendations for a patient. To generate the treatment recommendations, the treatment recommendation module 3802 obtains treatment selection data 3804. The treatment selection data 3804 is shown as including treatments 3806 available for managing a patient's glucose. As described throughout this specification, the available treatments 3806 can include treatments such as recommended behavior changes, exercise recommendations, diet recommendations, wearing a glucose monitor, oral medications, administration of insulin (e.g., via an automated insulin delivery system or via an insulin pen), and the like.

[0471] The treatment selection data 3804 also includes treatment cost data 3808 corresponding to the costs associated with the available treatments 3806. The costs associated with a treatment can include the cost of the medications (e.g., insulin) used by each of the available treatments 3806 and / or the cost of the devices (e.g., glucose monitor, insulin pen, insulin pump). For example, the treatment cost data 3808 for insulin treatment using an insulin pump can include the cost of purchasing insulin as well as the cost of purchasing the insulin pump. Such costs can correspond to the amount that a patient is required to pay to obtain the medications and / or devices, or the costs that a payer (e.g., an insurance provider) is required to pay. In some cases, the treatment cost data 3808 can include the total cost of the treatment based on an expected treatment timeline. For example, if the treatment corresponds to a patient wearing a glucose monitor for three months, the treatment cost data 3808 can indicate the total cost for the patient or payer for wearing the glucose monitor for three months. Alternatively, if the treatment is ongoing, the treatment cost data 3808 can include the cost of the treatment over a period of time, such as the cost per week, per day, per year, etc.

[0472] In one or more implementations, the treatment cost data 3808 may include cost savings (e.g., suppressed or reduced costs) associated with each treatment. For example, the costs associated with a treatment that includes a patient wearing a glucose monitor may include the cost associated with the glucose monitor itself (e.g., the purchase cost of the glucose monitor and sensors), and, for example, predicted cost savings that would result from the patient wearing the glucose monitor, such as a shorter hospital stay or avoidance of hospitalization, and a reduction or elimination in the use of expensive medical technologies (e.g., both devices and treatments).

[0473] The treatment advice module 3802 also obtains the patient data 3810 of the patient. As described throughout this specification, the patient data 3810 may include the patient's glucose data 3812 obtained from a glucose monitor worn by the patient over a period of time. Such glucose data 3812 may include, for example, the patient's glucose trace collected over a period of time. In one or more implementations, the glucose data 3812 may also include various metrics determined from the glucose data 3812, such as the in-range time, the time spent below the glucose threshold (e.g., below 70 mg / dL), and the time spent above the glucose threshold (e.g., above 180 mg / dL). The patient data 3810 may also include other metrics related to glucose and insulin, such as the patient's insulin sensitivity and the patient's carbohydrate ratio. In some cases, the glucose data 3812 may be obtained from a continuous glucose monitor (or other physiological sensor) worn by the patient over the test period (e.g., 3 days, 7 days, 10 days, 14 days, 30 days, or 3 months) during which the patient's glucose data 3812 is collected. The patient data 3810 may also include other information about the patient obtained from other devices or sensors, 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 an NFC-enabled sensor, optical glucose data, or glucose information collected using another technique). In one or more implementations, the patient data 3810 may include data collected using the low-fidelity data collection techniques or high-fidelity data collection techniques described above.

[0474] In one or more implementations, patient data 3810 also includes a risk metric 3814. Generally, the risk metric 3814 indicates the relative level of risk that a patient will experience a health-harmful event. The risk metric 3814 can be determined using risk stratification. Generally, risk stratification corresponds to classifying patients within a patient population based on health data and other factors. In one or more implementations, risk stratification is used to assign a risk metric 3814 to a patient based on the patient's glucose data 3812. For example, as described above, as a patient's glucose value increases, there is a tendency to increase the risk of health-harmful events such as hypoglycemic events, hyperglycemic events, cardiovascular diseases, vascular problems, or strokes. A patient's risk metric 3814 can also be determined based on other patient data such as the patient's demographic data, medical records, average or fasting glucose value, postprandial glucose variability characteristics, insulin sensitivity, carbohydrate ratio, etc. The risk metric can also be based on patient data 3810 such as the patient's weight, body mass index, family history, genetic markers, prescription history (e.g., prescription drugs), medical history (e.g., diagnosis of type 2 diabetes or another metabolic disease that can be determined from an electronic medical record or other data), test results (e.g., A1C, fasting glucose value, oral glucose tolerance). In one or more implementations, a patient population is divided into several groups based on a risk metric 3814. As an example, patients can be divided into a low-risk group, a medium-risk group, and a high-risk group based on a risk metric 3814.

[0475] In one or more implementations, the risk metric 3814 can also be based on patient engagement, such as the level of engagement or success in a coach...

Claims

1. A computer-implemented method, comprising: receiving patient data of a patient, the patient data including glucose data of the patient collected by a glucose monitor; determining, by a treatment selection model, a suitable treatment that is suitable for managing the patient's glucose based on the patient data; filtering, by the treatment selection model, the suitable treatment to select a cost-effective treatment for the patient based at least in part on treatment cost data, the treatment cost including the cost of the suitable treatment; outputting a treatment recommendation for managing glucose for the patient, including the cost-effective treatment.

2. The computer-implemented method according to claim 1, wherein the patient data of the patient further includes a risk metric indicating a relative level of risk of experiencing a health-harmful event for the patient based on the glucose data of the patient.

3. The computer-implemented method according to claim 2, wherein the treatment selection model selects the cost-effective treatment for the patient based at least in part on the risk metric of the patient.

4. The computer-implemented method according to claim 1, wherein the cost-effective treatment has the lowest cost of the suitable treatments that are suitable for managing the patient's glucose.

5. The computer-implemented method according to claim 1, wherein the treatment cost data further includes cost savings of the suitable treatment.

6. The computer-implemented method according to claim 1, wherein the suitable treatment includes one or more of wearing a glucose monitor, automatic coaching, insulin treatment using an insulin pen, or insulin treatment using an insulin pump.

7. The computer-implemented method according to claim 1, wherein the highly cost-effective treatment includes insulin treatment using insulin pen or insulin pump.

8. The computer-implemented method according to claim 1, wherein the preferred treatment includes insulin treatment using different types of insulin, and each of the different types of insulin has a different cost.

9. The computer-implemented method according to claim 8, wherein the highly cost-effective treatment selected by the treatment selection model includes insulin treatment having the lowest cost.

10. A system, A treatment selection model, Receiving patient data of a patient, the patient data including the glucose data of the patient collected by a glucose monitor, and Receiving treatment selection data including available treatments and treatment cost data, the treatment cost data including the costs of the available treatments, and A treatment selection model for selecting a highly cost-effective treatment for the patient from the available treatments based on the glucose data and the treatment cost data of the patient, and An output module for outputting the highly cost-effective treatment via a user interface. A system comprising.

11. The system according to claim 10, wherein the treatment selection model includes a machine learning model.

12. The system according to claim 10, wherein the treatment selection model selects the highly cost-effective treatment based on the glucose data, the treatment cost data, and a risk metric of the patient, and the risk metric indicates a relative level of risk of experiencing a health-harmful event for the patient.

13. The treatment selection model is Determine a suitable treatment that is suitable for managing the patient's glucose based on the patient data, Selecting a highly cost-effective treatment for the patient by filtering the suitable treatment and selecting the highly cost-effective treatment for the patient at least partially based on the treatment cost data, the system according to claim 10.

14. The highly cost-effective treatment has the lowest cost of the suitable treatment that is suitable for managing the patient's glucose, the system according to claim 13.

15. The suitable treatment includes insulin treatment using different types of insulin, each of the different types of insulin having a different cost, the system according to claim 13.

16. The highly cost-effective treatment includes insulin treatment having the lowest cost, the system according to claim 15.

17. The treatment cost data further includes cost savings of the available treatments, the system according to claim 10.

18. The highly cost-effective treatment includes one or more of wearing a glucose monitor, automatic coaching, insulin treatment using an insulin pen, or insulin treatment using an insulin pump, the system according to claim 10.

19. A computer-implemented method, Receiving patient data of a patient, the patient data including glucose data of the patient collected by a glucose monitor, Generating a risk metric for the patient based on the patient data, the risk metric indicating a relative level of risk that the patient will experience a health-harmful event, Determining, by a treatment selection model, a suitable treatment that is suitable for managing the patient's glucose based on the risk metric, Outputting the suitable treatment via a user interface, and a computer-implemented method including the same. **Claim 20** The computer-implemented method according to claim 19, wherein the risk metric is generated at least in part based on the patient's involvement in an automated coaching program.

Images