Intermittent Monitoring

Abstract

Various examples are directed to systems and methods for patient monitoring. An exemplary method includes receiving an estimated glucose concentration level of a patient from a continuous glucose monitoring (CGM) system during a first time period. The method may also include receiving non-glucose information related to the patient during the first time period and determining a relationship between the estimated glucose concentration level and the non-glucose information. The method may also include receiving non-glucose information related to the patient during a second time period and determining diabetes information for the patient during the second time period based on the determined relationship and the non-glucose information. The method may include electronically delivering a notification regarding the diabetes information.

Description

[Technical field]

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

[0002] The present development relates generally to medical devices such as analyte sensors, and more particularly, but not by way of limitation, to systems, devices, and methods for the intermittent use of continuous glucose or other monitoring systems. [Background technology]

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

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

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

[0006] Diabetic conditions are sometimes referred to as "Type 1" or "Type 2." Type 1 diabetics are usually able to use insulin when it is present, but because of problems with the insulin-producing beta cells in the pancreas, the body is unable to produce enough insulin. Type 2 diabetics may produce some insulin, but have reduced sensitivity to insulin, making the patient "insulin resistant." As a result, even though insulin is present in the body, the patient's body does not use enough insulin to effectively regulate blood sugar levels.

[0007] Blood glucose concentration levels may be monitored using an analyte sensor, such as a continuous glucose monitor, which may provide the wearer (patient) with information such as an estimated blood glucose level or a trend in the estimated blood glucose level.

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

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

[0010] An example (eg, "Example 1") of the subject matter (eg, a method, device, or system) may include the following.

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

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

[0013] 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, blind CGM, data from a wearable monitor, flash glucose monitoring, or optical monitoring technology.

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

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

[0016] In Example 6, the subject matter of Example 5 optionally includes an example in which the patient condition or patient insight is related to lifestyle changes related to diet, exercise, glucose level monitoring, or medication.

[0017] In Example 7, the subject matter of Example 6 optionally includes an example where the patient condition or patient insight relates to mealtime management, exercise management, or sleep management.

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

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

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

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

[0022] In Example 12, the subject matter of any one or more of Examples 1-11 optionally includes an example where determining the correlation includes determining a relationship between the first data and the second data obtained at corresponding times and / or days of the week within the overlapping time periods.

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

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

[0025] In Example 15, the subject matter of any one or more of Examples 1-14 optionally includes intermittently monitoring the first type of data and determining the diabetes information using the second data and the correlation during periods when the first type of data is not available.

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

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

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

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

[0030] In Example 20, the subject matter of Example 19 optionally includes examples where the treatment comprises pharmaceutical intervention.

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

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

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

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

[0035] In Example 25, the subject matter of any one or more of Examples 23-24 optionally includes examples where the non-CGM information includes physiological information about the patient.

[0036] 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 tension, skin moisture content, activity, activity patterns, blood ketones, urinary ketones, respiration, or acoustic information.

[0037] In Example 27, the subject matter of any one or more of Examples 23-26 optionally includes examples where the non-CGM information includes location information.

[0038] In Example 28, the subject matter of any one or more of Examples 23-27 optionally includes examples where receiving the non-CGM information includes receiving user input data.

[0039] In Example 29, the subject matter of any one or more of Examples 23-28 optionally includes examples where determining diabetes information about the patient includes determining a patient status.

[0040] In Example 30, the subject matter of any one or more of Examples 23-29 optionally includes examples where determining the patient status includes applying non-CGM information to the model.

[0041] In Example 31, the subject matter of any one or more of Examples 23-30 optionally includes examples where determining the diabetes information includes determining an estimated glucose concentration level.

[0042] In Example 32, the subject matter of any one or more of Examples 23-31 optionally includes examples where determining the diabetes information includes determining a quantitative assessment.

[0043] In Example 33, the subject matter of any one or more of Examples 23-32 optionally includes examples where determining the diabetes information includes determining a quantitative metric.

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

[0045] Example 35 is a system that includes an intermittent primary subsystem configured to intermittently collect primary physiological information from the 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.

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

[0047] In Example 37, the subject matter of Example 36 optionally includes an example in which the guidance system determines a relationship between the secondary data and the primary physiological information, and during periods 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.

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

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

[0050] In Example 40, the subject matter of any one or more of Examples 38-39 optionally includes examples where the diabetes management information includes a quantitative assessment.

[0051] In example 41, the subject matter of any one or more of examples 38-40 optionally includes examples where the diabetes management information includes a metric.

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

[0053] In Example 43, the subject matter of any one or more of Examples 41-42 optionally includes examples where the diabetes management information includes statistical feedback.

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

[0055] In Example 45, the subject matter of any one or more of Examples 35 to 44 optionally includes 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 indicative of a glucose concentration of the host, determines an estimated glucose concentration level based at least in part on the CGM sensor signal, and stores a plurality of estimated glucose concentration levels in the memory circuit, and the primary physiological information includes or is based on the plurality of estimated glucose concentration levels.

[0056] Example 46 is a patient management device including a sensor, a user interface, a communication circuit, and a processor. The processor can execute instructions to perform operations. The operations can include transmitting information to a second device based on an input from the sensor using the communication circuit, and receiving an estimate of a physiological condition based at least in part on the input from the sensor using the communication circuit. The operations can also include delivering information related to the estimate of the physiological condition using the user interface.

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

[0058] In Example 48, the subject matter of any one or more of Examples 46-47 optionally includes examples where the estimate of the physiological condition is a glucose concentration level.

[0059] In Example 49, the subject matter of any one or more of Examples 46-48 optionally includes examples where the information regarding the estimate of the physiological state is a time in range, a glucose concentration level, or a glucose concentration range.

[0060] In Example 50, the subject matter of any one or more of Examples 46-49 optionally includes an example in which the estimate of the physiological state is based on a correlation between previously collected glucose concentration information and previously collected activity information.

[0061] In Example 51, the subject matter of any one or more of Examples 46-50 optionally includes examples in which the device is wearable.

[0062] In Example 52, the subject matter of Example 51 optionally includes an example in which the device is a watch.

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

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

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

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

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

[0068] In Example 58, the subject matter of any one or more of Examples 56-57 optionally includes examples where the high fidelity monitoring technology is continuous glucose monitoring.

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

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

[0071] 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, an activity monitor, a smartphone, smart glasses, or a smart watch.

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

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

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

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

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

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

[0078] In Example 68, the subject matter of any one or more of Examples 64-67 optionally includes examples where determining the patient's goal is determined prior to the first time period of monitoring.

[0079] In Example 69, the subject matter of any one or more of Examples 64-68 optionally includes an example in which determining the patient's goals is determined by a first type of data monitored over a first period of time using low-fidelity monitoring techniques.

[0080] In Example 70, the subject matter of any one or more of Examples 56 to 69 optionally includes monitoring patient data of a physiological type over a first period of time, and a basis for at least one hardware or software function of the monitoring device is further based on the patient data of the physiological type.

[0081] In Example 71, the subject matter of any one or more of Examples 56-70 optionally includes an example in which at least one hardware or software feature is related to the frequency or content of the automated coaching routine.

[0082] In Example 72, the subject matter of any one or more of Examples 56-71 optionally includes detecting a change in a patient parameter, the change being measured between a first period and a second period, and using the detected change to further affect at least one hardware or software function of the monitoring device.

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

[0084] In Example 74, the subject matter of any one or more of Examples 56-73 optionally includes determining an amount or frequency of subsequent data after the second period of time, where the amount or frequency of subsequent data is determined using low fidelity or high fidelity monitoring techniques, and the amount or frequency is calculated to increase or maximize the patient parameter.

[0085] In Example 75, the subject matter of Example 74 optionally includes an example in which the patient parameter is time in range.

[0086] 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 low fidelity monitoring techniques.

[0087] 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 several sensors.

[0088] In Example 78, the subject matter of any one or more of Examples 74 to 77, optionally, wherein the patient parameter is A1c.

[0089] 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 fidelity monitoring techniques.

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

[0091] In Example 81, the subject matter of any one or more of Examples 74-80 optionally includes determining a patient end goal after a second period of time, the patient end goal depending at least in part on the first type of patient data or the second type of patient data, and displaying a recommended treatment calculated to cause a transition of a patient status toward the patient end goal.

[0092] Example 82 is a system including a first system configured to collect a first set of sensor data of a first type associated with a patient and a second system configured to collect a second set of sensor data of a second type associated with the patient, the system may further include a determination system configured to determine a user parameter of the second system based on the first set of sensor data.

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

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

[0095] In Example 85, the subject matter of any one or more of Examples 82-84 optionally includes an example where the second system includes a continuous glucose monitor.

[0096] In Example 86, the subject matter of any one or more of Examples 82-85 optionally includes an example in which the user parameters include a schedule for use of the second system.

[0097] In Example 87, the subject matter of any one or more of Examples 82-86 optionally includes an example in which the user parameter is a time for starting use of the second system.

[0098] In Example 88, the subject matter of any one or more of Examples 82-87 optionally includes an example in which the decision system applies the first set of sensor data to the model.

[0099] In Example 89, the subject matter of any one or more of Examples 82 to 88 optionally includes a third system configured to collect a third set of sensor data related to the patient, and the determination system determines a user parameter based at least in part on the first set of sensor data and the third set of data.

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

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

[0102] In Example 92, the subject matter of any one or more of Examples 90-91 optionally includes examples in which the device is wearable.

[0103] In Example 93, the subject matter of Example 92 optionally includes an example in which the device is a watch.

[0104] In Example 94, the subject matter of any one or more of Examples 90 to 93 optionally includes an example in which the processor further executes instructions to use information about the subject to determine a configuration of the user interface.

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

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

[0107] In Example 97, the subject matter of any one or more of Examples 94 to 96 optionally includes an example in which the device notifies a patient management facilitator regarding the availability of an estimate of the physiological condition and provides guidance from the patient management facilitator using a user interface.

[0108] In Example 98, the subject matter of any one or more of Examples 90-97 optionally includes examples where the estimate of the physiological condition is a glucose concentration level.

[0109] Example 99 is a method for selecting patients likely to benefit from intermittent high-fidelity monitoring. The method may include executing 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 the participants of the determined group, the kit being structured and configured to enable the participants to perform low-fidelity monitoring of their health for a first period of time using a first monitoring technology, and obtaining a first result. The method may include executing a second screening algorithm on the determined group to determine a cohort for participation in intermittent high-fidelity monitoring, the second screening algorithm using at least in part the obtained first result, and subsequently providing a second kit to participants in 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 for a second period of time using a second monitoring technology, and obtaining a second result. The method may also include providing a third kit to one or more participants of the determined cohort, the one or more participants being determined, at least in part, according to the obtained second result.

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

[0111] In Example 101, the subject matter of any one or more of Examples 99-100 optionally includes an example in which performing the second screening includes determining an estimated likelihood that the patient would benefit from high fidelity monitoring.

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

[0113] In Example 103, the subject matter of any one or more of Examples 99-102 optionally includes examples in which a third kit is structured and configured based on the second result obtained.

[0114] In Example 104, the subject matter of any one or more of Examples 99 to 103 optionally includes performing communication between a server in the first kit and a device, during at least a first period of time, wherein the communication provides a guidance message to the patient.

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

[0116] In Example 106, the subject matter of any one or more of Examples 99-105 optionally includes displaying output to the patient, the displayed output related to diet, exercise, glucose level monitoring, or medication.

[0117] In Example 107, the subject matter of any one or more of Examples 99 to 106 optionally includes displaying an output to the patient, the displayed output indicating an optimized period during which the patient should employ high-fidelity monitoring.

[0118] In Example 108, the subject matter of any one or more of Examples 99-107 optionally includes examples where the algorithm employs one or more factors selected from the group consisting of electronic health records, type II diabetes diagnosis code, family history, weight, BMI, history of metabolic disease, blood test results, A1c, fasting glucose level, oral glucose tolerance, prescribed diabetes medications, or any combination thereof.

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

[0120] Example 110 is a method of managing a parameter related to a patient's health, the method including a step of intermittent high fidelity monitoring. The method may initially include monitoring the patient for a first period of time using a first monitoring technique and obtaining a first result. The method may also include monitoring the patient for a second period of time using a second monitoring technique and obtaining a second result. The method may also include determining an action that the patient may take, the action being based on the obtained first and second results, the action being calculated to increase the likelihood of satisfaction of a management condition. In some examples, either the first monitoring technique or the second monitoring technique includes high fidelity monitoring.

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

[0122] 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 patient performance in relation to a diet goal, an exercise goal, a glucose level monitoring goal, or a medication goal.

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

[0124] In Example 114, the subject matter of any one or more of Examples 110 to 113 optionally includes an example in which satisfaction of the control condition includes reducing a parameter related to the patient's health by more than a predetermined amount with a confidence level greater than a predetermined confidence level.

[0125] In Example 115, the subject matter of any one or more of Examples 110-114 optionally includes selecting a patient. In some examples, selecting the patient is performed by determining a patient from a pool of patients who are likely to benefit from intermittent high-fidelity monitoring, the likelihood being greater than a calculated value.

[0126] In Example 116, the subject matter of any one or more of Examples 110-115 optionally includes examples where the first period of time is a subset of the second period of time.

[0127] In Example 117, the subject matter of any one or more of Examples 110-116 optionally includes examples where the first time period overlaps with the second time period.

[0128] In Example 118, the subject matter of any one or more of Examples 110 to 117 optionally includes performing communication between the server and a device associated with the patient during the first period or the second period or both, the communication providing a coaching function to the patient.

[0129] In Example 119, the subject matter of any one or more of Examples 110-118 optionally includes displaying an output to the patient, the displayed output indicating an optimized period during which the patient should employ high-fidelity monitoring.

[0130] In Example 120, the subject matter of any one or more of Examples 110 to 119 optionally includes an example in which the first monitoring technique is a low fidelity monitoring technique and the second monitoring technique is high fidelity monitoring.

[0131] In Example 121, the subject matter of Example 120 optionally includes an example in which the low-fidelity monitoring technique includes single-point glucose monitoring or blind CGM.

[0132] In example 122, the subject matter of any one or more of examples 120-121 optionally includes an example in which the low-fidelity monitoring technique includes activity monitoring by a wearable fitness tracker.

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

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

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

[0136] In Example 126, the subject matter of any one or more of Examples 120 to 125 optionally includes an example in which the low fidelity monitoring technique includes receiving user input data.

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

[0138] In Example 128, the subject matter of any one or more of Examples 120 to 127 optionally includes correlating the first and second results obtained, the correlation including determining a relationship between the first and second results obtained at corresponding times or days of the week, and determining an estimated value of the high fidelity monitoring technique at the given time based at least in part on an estimate of the correlation value at the given time and the results obtained by the low fidelity monitoring technique.

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

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

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

[0142] In Example 132, the subject matter of any one or more of Examples 130-131 optionally includes receiving, by the analyte sensor system, an upload request from the uploading computing device after determining that sensor use in the analyte sensor system has ended, broadcasting, by the analyte sensor system, system identification data, and receiving authentication data from the uploading computing device. The method may also include establishing, by the analyte sensor system, a communications session with the uploading computing device, where the uploading transmits the stored analyte data to the uploading computing device.

[0143] Example 133 is a method that includes receiving an estimated glucose concentration level of a patient from a continuous glucose monitoring (CGM) system during a first time period, receiving non-glucose information related to the patient during the first time period, determining a relationship between the estimated glucose concentration level and the non-glucose information, receiving non-glucose information related to the patient during a second time period, determining diabetic information for the patient during the second time period based on the determined relationship and the non-glucose information, and electronically delivering a notification regarding the diabetic information.

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

[0145] In Example 135, the subject matter of any one or more of Examples 133-134, optionally includes, where an estimated glucose concentration level is not available from the CGM during the second period of time.

[0146] In Example 136, the subject matter of any one or more of Examples 133-135 optionally includes receiving second non-glucose information associated with the patient during the first period, where the second non-glucose information is different from the non-glucose information, and where the relationship is between the estimated glucose concentration level, the non-glucose information, and the second non-glucose information.

[0147] In Example 137, the subject matter of any one or more of Examples 133-136 optionally includes, where the non-glucose information includes physiological information about the patient.

[0148] In Example 138, the subject matter of Example 137 optionally includes, where the physiological information includes at least one of heart rate, respiration, oxygen concentration, skin tension, skin moisture content, activity, activity patterns, blood ketones, urinary ketones, respiration, or acoustic information.

[0149] In Example 139, the subject matter of any one or more of Examples 133-138 optionally includes where the non-glucose information includes location information.

[0150] In Example 140, the subject matter of any one or more of Examples 133-139 optionally includes, where determining the diabetes information includes determining an estimated glucose concentration level.

[0151] In Example 141, the subject matter of any one or more of Examples 133-140 optionally includes where determining the diabetes information includes determining an estimate of the amount or percentage of time that the glucose concentration level was within range during a specified period of time.

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

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

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

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

[0156] In Example 146, the subject matter of any one or more of Examples 144-145 optionally includes, where the patient condition includes a time in range metric indicating an estimate of the amount or percentage of time the glucose concentration level was within range during a specified period of time.

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

[0158] In Example 148, the subject matter of any one or more of Examples 142 to 147 optionally includes the primary subsystem including a continuous glucose monitor (CGM) and a memory circuit, wherein the primary subsystem is configured to receive a CGM sensor signal indicative of a glucose concentration of the host, determine an estimated glucose concentration level based at least in part on the CGM sensor signal, and store a plurality of estimated glucose concentration levels in the memory circuit, and wherein the primary physiological information includes or is based on the plurality of estimated glucose concentration levels.

[0159] Example 149 is a machine-readable storage medium having instructions stored thereon that, when executed by at least one processor, cause the at least one processor to perform operations including receiving an estimated glucose concentration level of a patient from a continuous glucose monitoring (CGM) system during a first time period; receiving non-glucose information related to the patient during the first time period; determining a relationship between the estimated glucose concentration level and the non-glucose information; receiving non-glucose information related to the patient during a second time period; determining diabetic information for the patient during the second time period based on the determined relationship and the non-glucose information; and electronically delivering a notification regarding the diabetic information.

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

[0161] In Example 151, the subject matter of any one or more of Examples 149 to 150 optionally includes an operation further including determining guidance based at least in part on the diabetes information and displaying the guidance in a user interface.

[0162] In Example 152, the subject matter of any one or more of Examples 149-151 optionally includes receiving second non-glucose information associated with the patient during the first period, where the second non-glucose information is different from the non-glucose information, and where the relationship is between the estimated glucose concentration level, the non-glucose information, and the second non-glucose information.

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

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

[0165] In Example 155, the subject matter of any one or more of Examples 153 to 154 optionally includes the operation further including generating physiological condition data describing an estimate of the user's physiological condition, the generation being based at least in part on the user's analyte concentration.

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

[0167] In Example 157, the subject matter of any one or more of Examples 155-156 optionally includes, where the physiological condition data is generated by a second application and the device message includes the physiological condition data.

[0168] In Example 158, the subject matter of any one or more of Examples 155-157 optionally includes, where the physiological condition data includes a time in range, a glucose concentration level, or a glucose concentration range.

[0169] In Example 159, the subject matter of any one or more of Examples 155 to 158 optionally includes, where generation of the physiological condition data is based on a correlation between previously collected glucose concentration information and previously collected activity information.

[0170] In Example 160, the subject matter of any one or more of Examples 153 to 159 optionally includes, where the device message includes display data for display on a user interface of the wearable activity monitoring device.

[0171] In Example 161, the subject matter of any one or more of Examples 153-160 optionally includes where generating the sensor message includes encrypting the indication of the analyte concentration.

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

[0173] Example 163 is a patient management method including receiving, by a first application executing on the patient management system and from an analyte sensor, sensor data indicative of a user's analyte concentration; transmitting, by the first application and to a second application executing on the patient management system, a sensor message including an indication of the analyte concentration; and delivering, by the second application and to a wearable activity monitoring device, a device message based at least in part on the analyte concentration.

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

[0175] In Example 165, the subject matter of any one or more of Examples 163-164 optionally includes generating physiological condition data describing an estimate of the user's physiological condition, the generating being based at least in part on the user's analyte concentration.

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

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

[0178] In Example 168, the subject matter of any one or more of Examples 165-167 optionally includes, where the physiological condition data includes a time in range, a glucose concentration level, or a glucose concentration range.

[0179] In Example 169, the subject matter of any one or more of Examples 165 to 168 optionally includes, where generation of the physiological condition data is based on a correlation between previously collected glucose concentration information and previously collected activity information.

[0180] In Example 170, the subject matter of any one or more of Examples 163 to 169 optionally includes, where the device message includes display data for display on a user interface of the wearable activity monitoring device.

[0181] In Example 171, the subject matter of any one or more of Examples 163-170 optionally includes where generating the sensor message includes generating an error detection code based at least in part on the analyte concentration.

[0182] Example 172 is a machine-readable storage medium having instructions stored thereon that, when executed by at least one processor, cause the at least one processor to perform operations including receiving, by a first application executing on the patient management system and from the analyte sensor, sensor data indicative of an analyte concentration of a user; transmitting, by the first application and to a second application executing on the patient management system, a sensor message including an indication of the analyte concentration; and delivering, by the second application and to a wearable activity monitoring device, a device message based at least in part on the analyte concentration.

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

[0184] In Example 174, the subject matter of Example 173 optionally includes a parameter of the continuous glucose monitoring device responsive to an operation of the user interface.

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

[0186] In example 176, the subject matter of any one or more of examples 173 to 175 optionally includes, where the low fidelity monitoring technique includes activity monitoring by a wearable fitness tracker.

[0187] 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 smart watch.

[0188] 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 medication data, dietary data, exercise data, or sleep data.

[0189] In Example 179, the subject matter of any one or more of Examples 173-178 optionally includes determining a goal for the patient, wherein a parameter of the continuous glucose monitoring device is related to the goal.

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

[0191] In Example 181, the subject matter of any one or more of Examples 179-180 optionally includes that determining the patient's goal is based at least in part on a first type of data monitored over a first period of time using low-fidelity monitoring techniques.

[0192] In Example 182, the subject matter of any one or more of Examples 173 to 181 optionally includes determining parameters of a continuous glucose monitoring device, at least in part, by determining at least one parameter for the automated coaching routine.

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

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

[0195] Example 185 is a system including a low fidelity system configured to collect a first set of sensor data of a first type associated with a patient over a first period of time, a continuous glucose monitoring device configured to collect a second set of sensor data of a second type of data associated with the patient, and a determination system configured to determine a parameter of the continuous glucose monitoring device based on the first set of sensor data.

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

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

[0198] In Example 188, the subject matter of any one or more of Examples 185-187 optionally includes where the continuous glucose monitoring device includes a continuous glucose monitor.

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

[0200] In Example 190, the subject matter of any one or more of Examples 185-189 optionally includes, where the parameter is a time to begin using the continuous glucose monitoring device.

[0201] In Example 191, the subject matter of any one or more of Examples 185 to 190 optionally includes a third system configured to collect a third set of sensor data related to the patient, and the determination system determines a parameter based at least in part on the first set of sensor data and the third set of sensor data.

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

[0203] Example 193 is a method for measuring a parameter 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 sensor use in the analyte sensor system has ended; and uploading, by the analyte sensor system, the stored analyte data to an upload computing device.

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

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

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

[0207] In Example 197, the subject matter of any one or more of Examples 193 to 196 optionally includes detecting that the analyte sensor system has been applied to the host includes determining that the analyte sensor system provides a sensor reading that exceeds a threshold value.

[0208] In Example 198, the subject matter of any one or more of Examples 193 to 197 optionally includes detecting that the analyte sensor system has been applied to the host includes determining that the analyte sensor system has provided a sensor reading that exceeds the threshold for more than a threshold time.

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

[0210] In example 200, the subject matter of any one or more of examples 193-199 optionally includes uploading the stored analyte sensor data to a server system by an upload computing device.

[0211] Example 201 is a system for measuring a parameter related to a patient's health, the system including an analyte sensor system configured to perform operations including detecting 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 sensor use in the analyte sensor system has ended, and uploading, by the analyte sensor system, the stored analyte data to an upload computing device.

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

[0213] In Example 203, the subject matter of any one or more of Examples 201-202 optionally includes an operation further including, after determining that sensor use in the analyte sensor system has ended, receiving, by the analyte sensor system, an upload request from the uploading computing device, and receiving authentication data from the uploading computing device.

[0214] In Example 204, the subject matter of any one or more of Examples 201 to 203 optionally includes operations including, after determining that sensor use in the analyte sensor system has ended, receiving an upload request from the uploading computing device by the analyte sensor system, broadcasting system identification data by the analyte sensor system, receiving authentication data from the uploading computing device, and establishing a communications session with the uploading computing device by the analyte sensor system, wherein the uploading transmits the stored analyte data to the uploading computing device.

[0215] In example 205, the subject matter of any one or more of examples 201-204 optionally includes detecting that the analyte sensor system has been applied to the host includes determining that the analyte sensor system provides a sensor reading that exceeds a threshold value.

[0216] In Example 206, the subject matter of any one or more of Examples 201-205 optionally includes detecting that the analyte sensor system has been applied to the host includes determining that the analyte sensor system has provided a sensor reading that exceeds the threshold for more than a threshold time.

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

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

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

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

[0221] In Example 211, the subject matter of any one or more of Examples 209 to 210 optionally includes an operation further including, after determining that sensor use in the analyte sensor system has ended, receiving an upload request from the uploading computing device, and receiving authentication data from the uploading computing device.

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

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

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

[0225] [Figure 1] FIG. 1 is a diagram of an exemplary medical device system. [Diagram 2] 2 is a schematic diagram of various exemplary electronic components that may be part of the medical device system shown in FIG. 1. [Diagram 3] 1 is a table showing exemplary patient conditions, physiological conditions, and exemplary treatments. [Figure 4] FIG. 2 is a flow chart diagram of an exemplary method for migrating from low fidelity to high fidelity data collection techniques. [Diagram 5] FIG. 1 is a flow chart diagram of a method for collecting high fidelity data and collecting low fidelity data. [Figure 6] FIG. 1 is a flow chart diagram of a method for collecting low fidelity data and intermittently collecting high fidelity data. [Figure 7] FIG. 1 is a flow chart diagram of a method for managing a patient condition. [Figure 8A] FIG. 1 is a flow chart diagram of an exemplary process for patient management. [Figure 8B] FIG. 1 is a flow chart diagram of an exemplary process for patient management. [Figure 8C] FIG. 1 is a flow chart diagram of an exemplary process for patient management. [Figure 9] FIG. 1 is a flowchart diagram of a process for monitoring a patient using primary and secondary monitoring techniques. [Figure 10] FIG. 10 is a flow chart diagram of an exemplary method 1001 for assessing and informing a patient about diabetes information. [Figure 11]FIG. 2 is a flow chart diagram of an example method for determining a monitoring scheme based on collected sensor information. [Figure 12A] FIG. 2 is a diagram of an exemplary user interface. [Figure 12B] FIG. 12B is an enlarged view of a portion of the user interface shown in FIG. 12A. [Figure 12C] 13 is a diagram of an exemplary user interface including a target A1C indicator. [Figure 13] FIG. 1 is a flow chart diagram of a method for identifying or selecting patients who may benefit from an enhanced disease management program. [Figure 14] FIG. 1 is a flow chart diagram of an exemplary method for managing parameters related to a patient's health. [Figure 15] FIG. 1 is a flow chart diagram of an exemplary login process. [Figure 16] FIG. 2 is a diagram of an exemplary user interface. [Figure 17] FIG. 2 is an exemplary chat interface. [Figure 18] FIG. 2 is an exemplary chat interface. [Figure 19] FIG. 2 is an exemplary chat interface. [Figure 20] FIG. 2 is an exemplary chat interface. [Figure 21] FIG. 2 is an exemplary trend graph. [Figure 22A] FIG. 1 is a diagram of an example system in which the methods, devices, and subsystems can be implemented. [Figure 22B] FIG. 22B is a diagram of an exemplary system that is a deployment of the system of FIG. 22A. [Figure 22C] 22C is a flow chart illustrating an example of a process that may be performed in the system of FIG. 22B to display CGM data with an activity sensor. [Figure 23] FIG. 22B is a more detailed diagram of the exemplary system shown in FIG. 22A. [Figure 24]1 illustrates an example system that may be used in connection with implementing embodiments of the present disclosure. [Diagram 25] 5 illustrates an example of an automated or semi-automated coaching system that can be used in the embodiment of FIG. 4. [Figure 26A] FIG. 6 is a flow diagram of an exemplary process for engaging a patient in the automated or semi-automated coaching system of FIG. [Figure 26B] FIG. 6 is a flow diagram of an exemplary process for engaging a patient in the automated or semi-automated coaching system of FIG. [Figure 27] FIG. 13 is a flow chart diagram of an exemplary process for initiating an exercise module. [Figure 28] FIG. 11 is a flowchart diagram of an exemplary process for implementing a follow-up module. [Figure 29] FIG. 13 is a flowchart diagram of an example process for implementing a confidence evaluator / booster module. [Diagram 30] FIG. 13 is a flowchart diagram of an exemplary process for implementing a meal module. [Diagram 31] FIG. 13 is a flowchart diagram of an exemplary process for implementing a meal tracking module. [Diagram 32] FIG. 12 is a flow chart diagram of an exemplary process for implementing a module designed to encourage use of the embodiment of FIG. [Diagram 33] FIG. 13 is a flow chart diagram of an exemplary process for implementing a sleep module. [Diagram 34] FIG. 1 is a diagram of an example system that can include an analyte sensor system configured to upload captured analyte data after collection. [Diagram 35] 35 is a flow chart illustrating an example of a process that may be performed by the analyte sensor system of FIG. 34 to collect and upload analyte data. [Diagram 36]1 is a flow chart illustrating an example of a process that may be performed by the sensor electronics to upload collected analyte data. [Figure 37] 10 is a flow chart illustrating another example of a process that may be performed by the sensor electronics to upload collected analyte data. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

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

[0228] overview Patient management can be more effective when informed by timely information about the patient. For example, physiological, environmental, or behavioral information can be used to determine patient guidance (e.g., dietary or exercise guidance) or therapy (e.g., oral medication regime), or to determine changes or improvements to patient management schemes. Patients with blood glucose control conditions, such as type 2 diabetes, may particularly benefit from patient management schemes that use timely information. Some monitoring systems or devices, such as continuous glucose monitors, may provide strong signals about a patient's glucose control status (e.g., high glucose concentration levels, normal levels, or low levels), but continuous use of such systems may be undesirable due to cost (e.g., cost of CGM sensors and monitoring) or 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, smart watches, smartphones) may be less burdensome and less costly, but tend to provide information that may have less direct relationship to blood glucose levels. For example, while activity tends to help control blood glucose levels, actual blood glucose concentration levels cannot be easily inferred from activity information alone, and the effects of activity on blood glucose can vary widely depending on the patient or type of patient (e.g., between subgroups within a population).

[0229] To balance costs and the need for accurate information regarding glucose management, different types of patient data may be collected for one or more overlapping time periods, which may enable the determination of patient management information based on relationships between the different types of data. Such relationships may be used to guide patient management when one of the types of data is not available. For example, a continuous glucose monitor and an activity monitor may be used during the overlapping time periods, and relationships between glucose concentration level information and activity information may be learned from the CGM and activity data. In some examples, a user may be instructed to wear an activity sensor (e.g., a watch) continuously (e.g., for at least a portion of each day), and the user may be instructed to wear the continuous glucose sensor for a defined period of time (e.g., a two-week test period) or continuously (e.g., for two-week sessions every three months). Data may be collected by the system (e.g., using a mobile device and a server) and analyzed to determine relationships between glucose levels and activity. In various examples, activity may be correlated with glucose concentration levels or ranges, or with effects on glucose concentrations (e.g., a particular amount of activity causes a determined effect on glucose, which may vary based on glucose levels due to lower insulin sensitivity (i.e., insulin resistance) at higher glucose levels), or with glucose level trends (e.g., rate of change in glucose level associated with amount, intensity, or type of activity), any of which may be used to infer an estimated glucose concentration level (e.g., 120 mg / dL), range (e.g., 120-160 mg / dL), status (e.g., outside target range, or within range), or other estimates of glucose level management. One or more of these glucose estimates, or information based on the estimate (e.g., time within range for the day), may be delivered to the patient, which in various examples may occur in real time or on demand or recurringly (e.g., hourly, daily, weekly, three times a day, or before or after meals).

[0230] To facilitate determining relationships between types of data, different types of data (e.g., CGM data and activity data) may be correlated with one or more of time (e.g., to enable matching of CGM data with corresponding activity data), location, day, patient-entered data (e.g., meals or activity), or other information. Correlations with time, location, day, patient-entered data, or other information can also be used to determine relationships between types of data.

[0231] In some examples, 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 control estimates (e.g., estimated glucose levels, range, or status). In some examples, the system builds population cohorts divided by glucose profile behavior, and users matching a particular cohort can receive statistical feedback. Based on this type of population information, the glucose estimates can be used to determine population-based guidance that can be delivered to the patient (e.g., presented on a smart device). For example, the patient can receive guidance that reads, "It is estimated that 70% of people like you are out of range at this time of year. Have you thought about going for a walk?"

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

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

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

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

[0236] The analyte sensor system 102 may also include sensor electronics 106. In some examples, the analyte sensor 104 and the sensor electronics 106 may be provided as an integrated package. In other examples, 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, a component (e.g., an adhesive pad) for attaching the sensor to a host, 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.

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

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

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

[0240] The system 100 may also include a second medical device 108, which may be or include, for example, a wearable monitor or drug delivery device. For example, the second medical device 108 may be or include a drug delivery device, such as an insulin pump, insulin pen, or similar device. In some examples, the medical device 108 may be or include a sensor, a heart rate sensor, a respiration sensor, a motion sensor (e.g., an accelerometer), a posture sensor (e.g., a three-axis accelerometer), an acoustic sensor (e.g., capturing ambient or internal sounds), or another analyte sensor. In some examples, the medical device 108 may be wearable, for example, on a watch, 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 may detect, for example, one or more of analyte levels (e.g., glucose, lactate, insulin, or other substances), heart rate, respiration (e.g., using impedance), activity (e.g., using an accelerometer), posture (e.g., using an accelerometer), galvanic skin response, tissue fluid levels (e.g., using impedance or pressure).

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

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

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

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

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

[0246] The system 100 may also include a wireless access point (WAP) 138 that may be used to communicatively couple one or more of the analyte sensor system 102, the network 124, the 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, such as near field communication (NFC) or Bluetooth, may also be used between the devices of the system 100.

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

[0248] The system 100 may also include a third server system 127 that may receive or store a second type of patient information or information from another source, such as sensor data from a wearable sensor. In various examples, two or more servers 125, 126, 127 may be combined, or all three servers may be combined, or operations may be distributed differently among the servers, or subtasks may be delegated to additional servers or other resources. In some examples, a smart device such as the wearable device 120 or the handheld device 112 may run 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 run two separate applications that each collect, process, or transmit a type of data. In some examples, the smart device may run separate applications for collection of data, with one application receiving data from the other application (e.g., a CGM application may receive activity information collected by an activity app). Information regarding inter-application communication is described in U.S. Patent Application No. 15 / 474,886, U.S. Publication No. 20170286194(A1), which is incorporated by reference.

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

[0250] 2 is a schematic diagram of various exemplary electronic components that may be part of a medical device system 200. In one example, the system may include a sensor electronics 106 and a base 290. While a particular example of a division of components between the base and the sensor electronics is shown, it is understood that some examples may include additional components in the base 290 or in the sensor electronics 106, and some of the components shown in the sensor electronics 106 may be alternatively or additionally (e.g., redundantly) provided in the base. In one example, the base 290 may include an analyte sensor 104 and a battery 292. In some examples, the base may be replaceable and the sensor electronics 106 may include debouncing circuitry (e.g., a gate with hysteresis or delay) to avoid repeated execution of power-on or power-down processes when the battery is repeatedly connected and disconnected, or to avoid processing noise signals associated with removing or replacing the battery, for example.

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

[0252] As shown in FIG. 2, the sensor electronics 106 may include a potentiostat 202 that is coupled to the analyte sensor 104 and configured to repeatedly obtain analyte sensor readings using the analyte sensor, for example, by continuously or repeatedly applying a voltage bias across the sensor electrodes and measuring a current indicative of an analyte concentration. The sensor electronics may also include a processor 204 that may retrieve instructions 206 from a memory 208 and execute the instructions to determine controlled application of a bias potential to the analyte sensor 104 via the potentiostat, interpret signals from the sensor, or compensate for environmental factors. The processor may also store information in or retrieve information from a data storage memory 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). Example systems and methods for processing sensor analyte data are described in more detail herein and in US Pat. Nos. 7,310,544 and 6,931,327.

[0253] The sensor electronics 106 may also include a sensor 212, which 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 battery 214, which may be integrated into the sensor electronics, may be removable, or may be part of a separate electronics package. The battery 214 (or other power storage component, e.g., a capacitor) may be optionally rechargeable via a wired or wireless (e.g., inductive or ultrasonic) recharging system 216. The recharging system may recover energy or may receive energy from an external or built-in source. In various examples, the recharging circuit may include 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 heat recovery circuit, or a circuit that recovers energy from a communication circuit. In some examples, the recharging circuit may recharge a rechargeable battery using power provided from a replaceable battery (e.g., a battery supplied with the base component).

[0254] The sensor electronics 106 may also include wireless communication circuitry 218, which may include, for example, a wireless transceiver operably coupled to an antenna. The wireless communication circuitry 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 smart insulin pen, or other medical devices.

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

[0256] The peripheral device 250 may include a user interface 252, a memory circuit 254, a processor 256, a wireless communication circuit 258, a sensor 260, a power source 262 (e.g., a battery or a capacitor), or any combination thereof. A peripheral device may not necessarily include all 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, and the user interface 252 may receive information from a user (e.g., glucose values) or deliver information to a user, such as glucose values, glucose trends (e.g., arrows, graphs, or charts), or glucose alerts. The processor 256 may be configured to present information to a user or receive input from a user via the user interface 252. The processor 256 may also be configured to store and retrieve information in the memory circuit 254, such as communication information (e.g., pairing information or data center access information), user information, sensor data or trends, or other information. The wireless communication circuitry 258 may include a transceiver and antenna configured to communicate via a wireless protocol, such as Bluetooth, MICS, or any of the other options discussed above. The sensors 260 may include, for example, an accelerometer (e.g., in an activity monitor such as a watch), a temperature sensor, a location sensor, a biometric sensor, or a blood glucose sensor, a blood pressure sensor, a heart rate sensor, a respiration sensor, or other physiological sensor. The device may include multiple sensors of different types.

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

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

[0259] The user interface 272 may include, for example, a touch screen interface, a microphone or speaker, a vibration circuit, or any combination thereof, and the user interface 272 may receive information from a user (e.g., glucose values, alert preferences, calibration coding) or transmit information to a user, such as, for example, glucose values, glucose trends (e.g., arrows, graphs, or charts), glucose alerts, etc. The processor 276 may be configured to present information to a user or receive input from a user via the user interface 272. The processor 276 may also be configured to store and retrieve information in the memory circuit 274, such as communication information (e.g., pairing information or data center access information), user information, sensor data or trends, or other information. The wireless communication circuit 278 may include a transceiver and 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., CDMA (Code Division Multiple Access) or GSM (Global System for Mobile Communications)). The sensors 280 may include, for example, an accelerometer, a temperature sensor, a location sensor, a biometric sensor, or a blood glucose sensor, a blood pressure sensor, a heart rate sensor, a respiration sensor, or other physiological sensor. Although only one is shown in the example of FIG. 2, the medical device 2 may include a plurality of sensors. 70 may include two or more sensors (or memory or other components). In various examples, medical device 270 may be a smart handheld glucose sensor (e.g., a blood glucose meter), a drug pump (e.g., an insulin pump), or any other physiological sensor device (e.g., wearable device 120), a therapeutic device, or a combination thereof. In various examples, medical device 270 may be medical device 108, peripheral device 122, wearable device 120, wearable sensor 130, wearable sensor 134, or wearable sensor 136 shown in FIG. 1.In an example where the medical device 270 is an insulin pump, the pump and the analyte sensor system may be in bidirectional communication (e.g., so that the pump may request changes to the analyte transmission protocol, e.g., request data points or data on a more frequent schedule), or the pump and the analyte sensor system may communicate using one-way communication (e.g., the pump may receive analyte concentration level information from the analyte sensor system). In one-way communication, the glucose value may be incorporated into an announcement message that may be encrypted with a pre-shared key. In two-way communication, the pump may request values ​​for the analyte system to share or obtain and share in response to a request from the pump, and any or all of these communications may be encrypted using one or more pre-shared keys. The insulin pump may receive and track analyte (e.g., glucose) values ​​transmitted from the analyte sensor system 102 using one-way communication to the pump for one or more of a variety of reasons. For example, the insulin pump may pause or activate insulin delivery based on glucose values ​​below or above a threshold.

[0260] 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 different display devices may provide different user interfaces, the contents of the data package (e.g., the amount, format, and / or type of data to be displayed, alarms, etc.) may be customized to each particular device (e.g., programmed differently by the manufacturer and / or end user). For example, in the embodiment of FIG. 1, multiple different peripheral devices may wirelessly communicate directly with the sensor electronics module (e.g., the skin-mounted sensor electronics 106, etc., physically connected to the continuous analyte sensor 104) during a sensor session to enable multiple different types and / or levels of display and / or functionality associated with the displayable sensor information or to conserve battery power of the sensor system 102, and one or more designated devices may communicate with the analyte sensor system and relay (i.e., share) the information to other devices directly or via a server system (e.g., a networked data center) 125.

[0261] FIG. 3 shows a table 301 that shows exemplary patient states 305, physiological states 310, and exemplary treatments 315. The table is arranged to reflect a patient's typical progression from a normal state to a pre-diabetic state, and ultimately to a diabetic state (e.g., type 2 diabetes), which may occur over days, weeks, months, or years, depending on the circumstances. The arrangement of patient states, physiological states, 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 may contribute to a patient's progression to pre-diabetes, and ultimately to type 2 diabetes. Type 2 diabetes and high blood glucose levels are associated with myocardial infarction, stroke, vascular problems, and mortality.

[0262] A normal patient may not have a problematic physiological condition to manage and, therefore, may not require treatment. A patient may become insulin resistant due to one or more of a variety of factors, such as age, diet, lifestyle, pregnancy, genetic factors, or other factors.

[0263] When a patient becomes insulin resistant, the patient may begin to experience higher than normal circulating levels of insulin, known as "hyperinsulinemia." To manage hyperinsulinemia and insulin resistance, the patient may begin a patient management regimen, which may include dietary and exercise modifications, such as consuming fewer calories or fewer carbohydrates (especially simple sugars and other carbohydrates that can be rapidly processed by the body into glucose), and increasing activity or exercise.

[0264] As the patient's condition worsens, the patient may develop higher than normal blood glucose concentration levels, known as "hyperglycemia." For example, the patient may initially exhibit postprandial hyperglycemia, where glucose levels spike to higher than normal levels after ingestion of a meal, and then tend to decline as time passes after the meal. Glucose levels that are higher than normal, but not high enough to trigger a diagnosis of type 2 diabetes, may be referred to as "impaired glucose tolerance." The patient continues with diet and exercise modifications to address the postprandial glycemia or impaired glucose tolerance, and the patient may also be prescribed oral medications. Oral medications may, for example, stimulate the production of insulin by pancreatic beta cells (e.g., sulfonylureas or meglitinides), reduce glucose production by the liver (e.g., biguanides), improve the action of circulating insulin (e.g., thiazolidinediones), reabsorb glucose in the kidneys (e.g., SGLT2 inhibitors), block the breakdown of starch in the 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 drugs are also possible treatments.

[0265] Impaired glucose tolerance may progress to impaired fasting glucose, in which the patient may exhibit abnormally high glucose concentration levels not only immediately after a meal, but also when fasting ("fasting hyperglycemia"). For example, fasting blood glucose levels above 100 mg / dL may be considered prediabetes. The patient may continue with diet and exercise regimens, as well as oral medications. The patient may also be prescribed insulin to try to lower glucose levels.

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

[0267] Despite efforts to control glucose or insulin levels, some patients' conditions may continue to worsen and may eventually progress to type 2 diabetes. For example, a patient may be considered to have type 2 diabetes if their fasting (overnight) glucose level is 126 mg / dL or higher. Some patients may progress deeper into diabetes as their glucose levels continue to rise, tending to increase the risk of complications such as cardiovascular disease, vascular problems, and stroke.

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

[0269] In some examples, a continuous glucose monitor (or other physiological sensor) may be used for 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 levels may be learned from the test period. The information learned from the test period may then be applied, optionally in combination with other information, such as activity, location, heart rate, user-inputted 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 with another technique) to better manage the patient's condition. For example, the relationship of a patient's activity or behavior (inferred from activity, location, heart rate, or user-inputted information, or other information) to the patient's glucose concentration level may be learned during the test period, and this relationship may be used later to determine guidance to the patient.

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

[0271] FIG. 4 is a flow chart diagram of a method 401 of transitioning from low-fidelity data collection techniques to high-fidelity data collection techniques. At 405, low-fidelity data is collected. The low-fidelity data may provide information related to managing a health condition, such as diabetic health (e.g., controlling glucose concentration levels). In some examples, the low-fidelity data may provide information indirectly related to diabetic health. The low-fidelity data may be, for example, activity data (e.g., from a smart watch or other wearable sensor), which may indicate an amount of movement or movement by a patient. The activity data may be considered low-fidelity in the sense that it may be accurate with respect to activity levels, but does not provide a high degree of accuracy about the patient's condition, for example, in terms of glucose management or diabetic condition management, for example, because the low-fidelity data is indirectly related to glucose control or has a relatively weak correlation with glucose levels compared to high-fidelity data. The low-fidelity data may 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 with another technique. The low fidelity data may also include test results, such as fasting glucose levels or hemoglobin A1C. The low fidelity data can be used to perform a diabetes health assessment or to provide guidance to the patient to improve or control their diabetes health.

[0272] Additional information may also be collected during low fidelity data collection. For example, the system may collect information regarding the use of activity trackers, food trackers, and self-monitoring of blood glucose. Patient engagement may also be collected, such as level of engagement or success in coaching or goal setting programs. Preference information such as preferred methods for viewing and reviewing health data (e.g., app displays, chats, and types and timing of coaching calls, or style of learning (e.g., reviewing patterns or real-time tracking and interaction), or preferred graphical style (e.g., analyzing user interface screen views for examples of the particular type of details explored, or preference for qualitative or quantitative displays), communication style (short messages versus videos or readouts), or preferred health metrics (e.g., steps, exercise streak, daily carbohydrates, current app settings) may also be collected. One or more goals may also be determined (e.g., meal selections, exercise, basal or drug titrations, or hypoavoidance). A patient's risk metric may also be determined, for example, based on demographics, medical records, average or fasting glucose levels, or postprandial glucose variability characteristics. In some examples, a patient may be assigned a goal or risk metric based at least in part on a cohort of prior subjects with similar starting circumstances, goals, or characteristics.

[0273] At 410, high fidelity data may be collected. During high fidelity data collection, low fidelity data collection may be paused or both low fidelity and high fidelity data may be collected. High fidelity data may provide information highly relevant to the management of a patient's health condition. For example, high fidelity data may be data from a continuous glucose monitor. High fidelity data may be more costly, burdensome, or invasive to collect than low fidelity data, so the reason for the collection of high fidelity data may need to be determined.

[0274] In one example, a determination that high fidelity data collection is necessary or otherwise justified based at least in part on low fidelity data. For example, low fidelity information can be used to determine or identify subjects who are likely to benefit from health benefits by transitioning to intermittent or continuous high fidelity data collection. Such a determination can be based, for example, on risk metrics as described above, or another assessment of diabetes or cardiovascular risk, or on identification of glucose concentration patterns that may benefit from high resolution information (e.g., high resolution data of the postprandial rise in glucose concentration, as well as peaks, and duration or glucose fluctuations, can be used to understand the glucose load and glucose burden of a meal), or on identification of subjects with significant meal-to-meal or day-to-day variations (e.g., high fidelity (e.g., CGM and activity) can correlate glucose patterns with activity or sleep patterns). The determination to perform high fidelity monitoring can also be based on identification of subjects scheduled for medication changes, subjects on an ongoing coaching plan, or recommendations from a coach or other health care provider.

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

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

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

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

[0279] The decision to start collecting high fidelity data can be based at least in part on the collection of information from an activity sensor worn by the patient. For example, the decision to start collecting high fidelity data can be based on the satisfaction of an activity condition. For example, the activity condition can include evidence that the patient exhibits activity above a threshold, or evidence that the patient regularly participates in some type of exercise (e.g., walking, running, or activity above a specified baseline) frequently enough. In other examples, the decision to start high fidelity data collection can be based on blood glucose meter data (e.g., the satisfaction of a blood glucose condition, such as a determination that the average blood glucose level exceeds a threshold, or a specified number of glucose readings above a threshold), or location (e.g., frequent visits to exercise facilities or unhealthy restaurants). The decision may also be based on a combination of two or more types of low fidelity data. For example, activity and blood glucose meter data can be used in combination, or activity and location can be used in combination, or blood glucose meter data and location can be used in combination. In one example, a determination that blood glucose levels (e.g., as determined by a blood glucose meter) correspond to secondary factors such as activity (e.g., activity lowers blood glucose levels) or location (e.g., after a visit to the park or gym, blood glucose levels are lower or more controlled, or after a visit to a fast food restaurant, blood glucose levels are higher or less controlled).

[0280] The characteristics of the high fidelity data collection 410 can be based at least in part on the low fidelity data collection. For example, the system may estimate a period or schedule (e.g., intermittent periods) for high fidelity monitoring and initiate shipment of necessary supplies (e.g., CGM sensors) according to the schedule or determine the quantity of shipment (e.g., number of CGM sensors to ship). In some examples, the high fidelity system (e.g., CGM system) may be pre-configured to fit the needs of the subject based at least in part on the low fidelity data. For example, one or more preferred metrics for a current health goal or multiple health goals may be selected or ranked, or the system may automatically reconfigure a coaching system (a chatbot or other coaching application running on a smart device such as a watch) with preferred or specified information, such as enhanced glucose metrics. In some examples, the system may integrate enhanced glucose metrics (e.g., diet metrics) into one or more specified (e.g., most viewed) application screens or devices (e.g., watch displays). The system may inform 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 a specified metric to highlight the subject. The system may also determine guidance or other patient management factors based on behavioral learning about the subject, such as the timing and type of messages, such as delivery of information about post-meal summaries (e.g., degree or nature of blood glucose level control, or loss of control), benefits of exercise, improvement with medication changes, or adherence, or to conduct an information gathering period. The system may also determine goals (e.g., time-in-range goals) based on low fidelity data. Any of the guidance examples described above or below may be employed in method 401.

[0281] 5 is a flow chart diagram of a method 501 of collecting high fidelity data and collecting low fidelity data. At 505, high fidelity data may be collected. The high fidelity data may be used for diabetic health assessment or diabetic health improvement (e.g., to obtain better control of glucose concentration levels or patterns), or both. The high fidelity data may be CGM data or any of the other examples of high fidelity data described above or below.

[0282] At 510, low fidelity data may be collected for diabetic health assessment or diabetic health improvement (or both). The low fidelity data may be activity data or any of the other examples of low fidelity data described above or below. In some examples, the low fidelity data collection may be based at least in part on the high fidelity data collection. In some examples, insights from the high fidelity data collection may be used to inform app functionality, graphic apps, and phone apps. For example, the time to acquire low fidelity data (e.g., using a meter to check glucose levels) may be determined to capture, for example, high or low glucose concentration values.

[0283] In some examples, guidance may be delivered to the patient at 515 to improve diabetic health. For example, the subject (e.g., the patient) may be educated or reminded about the importance of exercise or dietary choices, or the patient may be congratulated or otherwise recognized for achieving an exercise goal or glucose control status, etc. (e.g., maintaining blood glucose levels within a specified range). Patient guidance may be based in part on high fidelity data. For example, the patient may be informed that at a particular time of day, glucose levels tend to rise or fall, or tend to rise or fall by a particular amount (e.g., glucose levels may tend to rise in the morning), or that around the time of a particular event, glucose levels tend to rise or fall, or tend to rise or fall by a particular amount (e.g., glucose levels may peak some time after a meal).

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

[0285] The guidance can be based at least in part on a correlation determined from high fidelity data, such as a correlation between glycemic health and another measurable characteristic or pattern. For example, the guidance can be based on a correlation between the amount and intensity of exercise and activity and glucose improvement (e.g., the number of minutes or steps shown to reduce glucose by 20 mg / dL), or on a correlation between food and meal choices and glucose improvement (e.g., which foods caused large glucose spikes).

[0286] In some examples, glucose metrics, glucose fluctuations (e.g., deviations from a desired range), or glucose profiles (e.g., glucose concentration patterns) may be determined from the low fidelity data and previously collected high fidelity data (e.g., using correlations between the low fidelity data and the high fidelity data).

[0287] Using high fidelity data as described can improve the performance of devices that measure and / or utilize low fidelity data. For example, low fidelity data alone can be used to provide generalized guidance to a user, for example, by comparing activity levels or other low fidelity data to generalized guidelines or standards. By using high fidelity data in combination with low fidelity data as described herein, a device can provide user guidance tailored to an individual user, and thus be more likely to provide meaningful results, such as achievement of glucose concentration ranges, goals, time in range, or A1C.

[0288] 6 is a flow chart diagram of a method 601 for collecting low fidelity data and intermittently collecting 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 low fidelity examples identified above or below.

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

[0290] The method may return to low fidelity data collection 605 during a subsequent low fidelity data collection period during which time guidance for the patient may be determined based on the low fidelity data and the determined relationship between the low fidelity data and the high fidelity data. In some examples, the low fidelity data may be used as a surrogate for the high fidelity data in determining patient guidance. The process may cycle between low fidelity collection periods at 605 and high fidelity collection periods at 610 such that high fidelity data is intermittently collected. The intermittent high fidelity data may 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 may return to high fidelity collection at 610 in response to a detected or reported health change (e.g., change in glucose concentration level, weight, activity, or new diagnosis). In some examples, high fidelity data is collected periodically (e.g., quarterly, annually, etc.). As new sets of high-fidelity data are collected, the relationships or correlations between the low-fidelity and high-fidelity data can be updated and patient guidance can be revised.

[0291] 7 is a flow chart diagram of a method 701 for managing a patient condition. At 705, patients are identified for screening from a patient pool. A patient pool may include, for example, a group of patients in a clinical practice, or a designated insurance pool or program, or a geographic location, or a workplace, or any combination thereof. For example, a pool of 100, 10,000, or 100,000 patients may be identified.

[0292] At 710, the patient's condition or health history 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., prescribed medications), medical history (e.g., diagnosis of type 2 diabetes or other metabolic disease, which may be determined, for example, from electronic health record codes or other data), test results (e.g., A1C, fasting glucose level, oral glucose tolerance), other metabolic diseases, or other factors may be evaluated to identify possible risk factors that may indicate diabetes, prediabetes, or vulnerability to developing diabetes. Exclusion criteria may also be applied, such as a type 1 diabetes diagnosis or type 2 diagnosis with intensive insulin therapy. In some examples, the screening may produce a simple yes / no output. In some examples, a 10% subset of patients in the pool (e.g., 10,000 out of 100,000) may be identified as candidates for enrollment in an enhanced diabetes management program. In other examples, more detailed outputs 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 uncontrolled hypoglycemia or hyperglycemia)).

[0293] At 715, an enrollment selection is performed to determine whether the patient is enrolled in the diabetes management program. The enrollment selection may occur in response to, for example, additional screening inputs, additional consideration of current or previous medications, diabetes progression, efficacy of previous therapies, predicted disease progression, adherence to or participation in previous health promotion programs (e.g., exercise or medication compliance), or fulfillment of enrollment conditions that may be based on any of the above factors (weight, BMI, family history, etc.). In some examples, a score or other prediction may be determined based on future diabetes risk or cost if the patient continues with the current diabetes management program. Additionally or alternatively, a score or other prediction may be determined based on a calculated potential benefit or prediction of the success of the enhanced diabetes program. In some examples, a weighted score may be determined based on a combination of potential health risks or costs (or both) and a compelling benefit (e.g., cost savings or impact on patient health). Based on the above score or other information, the enrollment selection may determine the patient's assignment to enrollment at 725 in the enhanced diabetes patient management program or to continuation of the current diabetes management program at 720. The identification at 705, the evaluation at 710, and the enrollment selection at 715 may be performed by one or more decision systems, such as an algorithm running on a computer system or mobile device, such as one or more of the devices shown in Figures 1 and 2. If the patient is not selected for the enhanced diabetes management program at 720, the method returns to selecting the patient from the patient pool.

[0294] At 725, the patient may be enrolled in an enhanced diabetes management program. In an example, the diabetes management system may enroll the patient in the enhanced diabetes management program, for example, in response to satisfaction of an enrollment condition. At 730, a data-driven patient management process may be performed. For example, data such as activity (e.g., using a wearable device), blood glucose meter data, user input data (e.g., food or drink selection), location, or physiological data (e.g., heart rate or respiration) may be used to determine guidance to the patient regarding management of a physiological condition. Activity data measured by the wearable device may include, for example, data captured using an accelerometer or other motion sensor associated with the wearable device. The guidance may, for example, educate or remind the patient about exercise or dietary choices, or may congratulate or otherwise recognize the patient for an achievement (e.g., completing an exercise session or exercising a specified number of consecutive days or days in a period of time (e.g., three times a week or ten times a month)), or may congratulate or otherwise recognize a positive dietary choice (e.g., choosing a healthy diet or limiting caloric intake). In some examples, enhanced diabetes management may include the collection and correlation of low-fidelity and high-fidelity data, as described above with reference to Figures 4, 5, or 6, and below with reference to Figures 8B and 8C.

[0295] At 735, a determination is made regarding data-driven patient management. For example, the determination can be based on satisfaction of a diabetes control condition. The diabetes control condition can be based on, for example, one or more of the amount (e.g., percentage) of time that blood glucose (e.g., as determined by a blood glucose meter) is in a target range (e.g., 70-160 mg / dL), blood glycosylated hemoglobin or hemoglobin A1c levels (e.g., A1C test results), other diagnostic tests, changes in BMI, weight, or body composition (e.g., percentage of body fat), cardiovascular health, or other factors or diagnostic tests. The determination can be made, for example, by a computer system configured to determine from the collected data whether a diabetes control condition is satisfied. In some examples, the computer system may apply the data input to a model that can be based on a particular patient or population. The model output can include a satisfaction state (e.g., satisfied or not satisfied) or a prediction regarding a future health state (e.g., that the patient's health is likely to improve, or that the patient's health is likely to stabilize, or that the patient's health is likely to deteriorate).

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

[0297] If the diabetes management condition is not met at 735, the process may proceed to a more intensive patient management scheme at 740. For example, the process may begin collecting or receiving continuous glucose monitoring information. For example, information from the patient's continuous glucose monitor may be used to determine patient guidance. The CGM data may be combined with other data sources to determine guidance. In some examples, the CGM-driven patient management scheme may use intermittent CGM data. For example, CGM data may be collected during a first period of time, and the data collected during the first period may be used (optionally in combination with other non-CGM data) to determine guidance to the patient during a second period of time when CGM data is not available. In some examples, the CGM-driven patient management may include a continuous cycle of intermittent CGM use, such as performing a specified number of CGM data collections per specified period (e.g., one week or ten days or two weeks per month, quarterly, or yearly). Intermittent CGM use may reduce the cost of managing a patient. For example, intermittent CGM use may be less expensive than non-intermittent (e.g., continuous) use of a CGM because intermittent CGM data collection requires fewer sensors and only intermittent monitoring services via a CGM server. Intermittent CGM use may also reduce the cost of managing a patient by providing additional insight into the management of a patient's glucose concentration levels and slowing or halting the progression to type 2 diabetes compared to not using a CGM, which may reduce overall healthcare costs or improve patient outcomes (e.g., improved health).

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

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

[0300] FIG. 8A is a flow chart diagram of a process 801 of managing a first patient. At 805, patient 1 is selected. At 810, an enrollment decision is made, for example, by application of an enrollment algorithm by a computer system, which may use health data (e.g., height, weight, body mass index, blood glucose level) as described above. At 815, a decision is made to maintain the current patient management program, which may include, for example, periodic testing and delivery of guidance at periodic checkups, but not continuous data collection between checkups. Periodic checkups may be office visits or electronic checkups based on known or periodically (e.g., semi-annually or annually) collected information about the patient. In some examples, each of the steps 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 to a model or apply data to a model).

[0301] FIG. 8B is a flow chart diagram of an exemplary process 803 of managing a second patient. At 830, patient 2 is selected for evaluation. At 835, an enrollment decision is made, for example, by application of an enrollment algorithm by a computer system, which may use health data (e.g., height, weight, body mass index, blood glucose level) as described above. At 840, patient 2 is enrolled in a stage 1 coaching scheme, where guidance may be provided to the patient, for example, via a handheld device or watch, based on the low fidelity data. For example, chatbot functionality as 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, initiation of a treatment such as insulin delivery (e.g., via a smart insulin pen), or initiation of oral medication. In some examples, the treatment selection may include guidance to take a prescribed bolus medication (e.g., consider an insulin injection now) or to participate in an activity (e.g., take a walk or run to lower glucose levels). At 855, low-fidelity monitoring and coaching continues for Patient 2.

[0302] FIG. 8C is a flow chart diagram of an exemplary process 805 of managing a third patient. At 860, patient 3 is selected for evaluation. At 865, an enrollment decision is made, for example, by application of an enrollment algorithm by a computer system, which may use health data (e.g., height, weight, body mass index, blood glucose level) as described above. At 870, patient 3 is enrolled in a stage 1 coaching scheme, where guidance may be provided to the patient, for example, via a handheld device or watch. At 875, low fidelity data is collected for patient 3, and coaching or other guidance for patient 3 is determined based at least in part on the low fidelity data. Coaching and / or other guidance may be provided to patient 3 via handheld device 112, for example, utilizing 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 a treatment, such as an insulin injection program or an oral medication. Treatment selection may in some cases be a decision to engage the patient in a stage 2 coaching scheme that may be based at least in part on high fidelity data (e.g., CGM data) collected about the patient. For example, the factors or process steps described above with reference to FIG. 4 may be applied to low fidelity monitoring 875 or treatment selection 880.

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

[0304] FIG. 9 is a flow chart diagram of a process for monitoring a patient using primary and secondary monitoring technologies. Primary technologies may include receiving or collecting a first type of data ("primary data" or "first data") and secondary technologies may include receiving or collecting a second type of data ("secondary data" or "second data"). For example, primary monitoring may include collecting or collecting high fidelity information about the patient and secondary monitoring may include collecting or collecting low fidelity information about the patient. In an example where the patient is a diabetic, primary technologies may include, for example, continuous glucose monitoring. Secondary technologies may 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 with another technology).

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

[0306] 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 in 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 the sensor and processing the sensor signal to generate at least a portion of the second data.

[0307] In some examples, the secondary monitoring may include monitoring activity using a wearable fitness tracker, which may include, for example, a wearable heart rate monitor, a wearable activity monitor, a smartphone, smart glasses, or a smart watch.

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

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

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

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

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

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

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

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

[0316] 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 data (e.g., activity or single point blood glucose, or both) and correlation during one or more time periods when the first type of data is not available. For example, the first type of monitoring 902 data may include continuous glucose monitoring and the second type of monitoring data 904 may include monitoring activity data with a wearable accelerometer. The wearable accelerometer may be configured to monitor data when continuous glucose monitoring is not occurring.

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

[0318] In some examples, the method may include administering a therapy based at least in part on the determined diabetes information, at 914. The therapy may include, for example, a pharmaceutical intervention such as an oral medication or a drug administered via a pump.

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

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

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

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

[0323] FIG. 10 is a flow chart diagram of an exemplary method 1001 of determining and informing a patient about diabetes information. The method 1001 may be executed on a system such as the system 100 shown in FIG. 1. At 1002, an estimated glucose concentration level may be received from a continuous glucose monitoring (CGM) system for a first period of time. The method may optionally include detecting the estimated glucose concentration level using a CGM sensor. The first period of time may be, for example, several days (e.g., 7, 10, or 14 days) or several weeks (e.g., 4 or 10 weeks). For example, a patient may be enrolled in a CGM study to gather information about the patient's response to various stimuli such as oral medication, exercise, activity, etc.

[0324] At 1004, non-CGM information associated with the patient may be received for a first time 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 about the patient. The physiological information may include, for example, one or more of heart rate, respiration, oxygen concentration, skin tension, skin moisture content, activity, activity patterns, blood ketones, urinary ketones, respiration, or acoustic information.

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

[0326] At 1008, non-CGM information associated with the patient may be received during a second time period. The second time period may be a time period during which an estimated glucose concentration level is not available from the CGM. At 1010, diabetes information for the patient during the second time period may be determined based on the determined relationship and the non-CGM information. Determining the diabetes information for the patient may include determining a patient status. Determining the patient status may include applying the non-CGM information to a model. In some examples, determining the diabetes information may include determining an estimated glucose concentration level. For example, the algorithm may infer an estimated glucose concentration level from activity information that has been calibrated to glucose concentration levels at an individual level (e.g., based on information about the patient) or a population level, or both (e.g., using a predictive learning model).

[0327] In some examples, determining the diabetes information may include determining a qualitative rating such as green, yellow, red, or "good control," "moderate control," or "poor control."

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

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

[0330] The system may improve patient management, for example, by managing costs incurred by continuous glucose monitoring or by enabling glucose estimation to motivate a user (e.g., a patient) to take steps to manage glucose levels. For example, utilizing low-frequency and high-frequency data in the manner described with respect to exemplary method 1001 may provide the benefits of high-fidelity data collection at a reduced cost. For example, the performance of the system during low-fidelity data collection may be comparable to the performance during high-fidelity data collection, so that costly high-fidelity data collection may not need to be performed as frequently. Also, a patient's glycemic control may be improved, for example, at the cost of full-time high-fidelity data collection.

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

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

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

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

[0335] The method may include, at 1106, determining a monitoring scheme based on an evaluation of the patient's engagement or behavior. For example, the method may include determining a hardware or software capability of the device. The hardware or software capability may correspond, for example, to the operation of a user interface. In some examples, the determined capability may include a simple or light-feature interface, which may be applied in response to identifying, as part of the evaluation, a less involved patient, or a patient who may benefit from a less complex interaction. The determined capability may also include a relatively complex or full-featured interface, which may be applied in response to identifying a highly involved 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 setting options, such as programmable alerts or more frequent guidance). In some examples, the user interface may additionally or alternatively adapt based at least in part on the user's age or birthdate (e.g., year). For example, the user interface may use larger fonts or user interface elements (e.g., buttons), or a different presentation scheme (e.g., more contrast or designated color scheme) for elderly users. In some examples, the user interface may provide a visual challenge to see if the user has difficulty identifying or selecting a user interface element, or may prompt the user for information regarding visual acuity, and the user interface may adapt based on the response to the challenge or prompt.

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

[0337] In some examples, determining the monitoring scheme may include determining a goal of the patient. The method may include determining hardware or software features of the monitoring device (e.g., handheld or body-worn device) that relate to or facilitate the goal. In various examples, the goal may include a dietary goal, an exercise goal, a glucose level monitoring goal, or a medication goal. In some examples, at least one hardware or software feature of the monitoring device may be related to prandial glucose management (e.g., a strategy for managing glucose levels before, during, or after a meal, e.g., by exercising before or after a meal, or by administering insulin before a meal (a "pre-bolus" strategy). In some examples, at least one hardware or software feature of the monitoring device may be related to sleep management (e.g., a strategy for controlling glucose levels during sleep, or a strategy for avoiding or minimizing sleep interruptions to address glucose level issues).

[0338] In some examples, the patient goal may be determined, at least in part, based on a first sensor input (eg, data monitored using low fidelity monitoring techniques).

[0339] The 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., second sensor input or high fidelity data) may be determined based at least in part on the first sensor input, for example, based on data collected by low fidelity monitoring techniques. The amount or frequency of data may include the amount of data points, the number of high fidelity sensors used (e.g., the number of CGM sensors used continuously or intermittently to gather CGM data), or the periodicity (consistent or irregular periods) between data collection events. 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 in a specified range of glucose concentration levels or the patient's A1c level.

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

[0341] The method 1101 may further include, at 1112, providing guidance to the patient, for example, via the system 100 shown in FIG. 1. For example, the system may provide an automated message transmitted from a server to the monitoring device based on the patient profile data or the 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 CGM data, information based on the CGM data (e.g., time in range), guidance for the subject (e.g., "consider your exercise session"), predicted, estimated, or measured benefits of exercise on glucose control. In some examples, the application may educate the user on food selection and resulting post-prandial glucose control (e.g., variability), or educate or quantify the relationship between exercise and the glucose-lowering effect of exercise. For example, the application may indicate that the user's selected activity is estimated to bring the user's glucose level to a desired value or range (e.g., "recent activity should bring glucose level to the desired range"). In another example, the application may indicate that a proposed activity is likely to bring the user's glucose level into a desired value or range (e.g., "1 hour of running is estimated to lower glucose levels by 15 mg / dl"). In some examples, guidance may be provided by a chatbot functionality provided as described herein.

[0342] The method 1101 may further include detecting a change in the patient parameter (e.g., improved glucose concentration control at a particular time or specified condition, or improvement in A1C) at 1114. The change may be measured between a first time period during which a first sensor input is collected and a second time 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 may be used to relate characteristics of the monitoring or guidance scheme to changes in the patient parameter. For example, positive changes may correlate with certain aspects of the monitoring scheme or guidance, and the hardware or software functions of the monitoring device may be modified to emphasize the aspects that are correlated with positive changes. Such iterative changes may improve the performance of the monitoring system in guiding the patient toward achieving positive clinical outcomes or management goals. (e.g., toward better controlled glucose levels or lower A1c test results). In some examples, an indication of increase or maximization of the patient parameter may be displayed on the monitoring device.

[0343] The method may be repeated to provide continuing guidance to the patient. For example, after step 1114, the method may return to steps 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.

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

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

[0346] The user interface 1202 may include a chart 1204, which may show glucose concentration levels 1236 (e.g., measured in mg / dL) plotted against a time axis 1234. The user interface 1202 may also show upper and lower limits 1230 and 1232 of a goal range. In various examples, the goal range may be set by a user (e.g., a patient), or may be determined by a device or system (e.g., handheld device 112 or 120 shown in FIG. 1), or may be provided by a coach (e.g., a human coach or a computerized “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 examples, the range may be set (e.g., by the system or by default) at 70-160 mg / dL, and the range may be expanded (e.g., 70-180 mg / dL) or narrowed as appropriate for a particular patient, which may be determined, for example, from CGM patterns, low fidelity data, or input from a user. An expanded view of the chart is shown in FIG. 12B. In various examples, the glucose concentration level may be an estimated blood glucose concentration level (e.g., a level calculated based on GCM data, or other data), or the plotted glucose level may include a blood glucose level from a meter. While the exemplary chart 1204 shows a 24-hour period (e.g., from 12:00 a.m. to 12:00 a.m. the following day), in various other examples, the chart may 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 of time, the plotted values ​​may correspond to daily or weekly averages, or the graph may show a range or distribution of values ​​or averages (e.g., bars showing high and low, and a dot or line showing the median or average). Although glucose concentration levels are shown, other types of analyte levels, or other types of sensor data, may be shown instead of or in addition to the glucose concentration levels (e.g., on the same chart or on a different chart).

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

[0348] The user interface 1202 may include multiple meal indicators, e.g., 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 may be identified from a user input, such as a smartphone input indicating that a meal has been consumed, and may optionally include information about the meal, such as the contents of the meal (e.g., carbohydrates, proteins, fats, or food type, such as "one slice of pizza and a glass of milk"). In some examples, the user's meals are also identified from other types of inputs, including, e.g., geolocation data, motion data, and the like. For example, the geolocation data may indicate that the user is present in the user's kitchen, a restaurant, or another location where food is prepared and / or served. Also, for example, the motion data may indicate a user's motion consistent with eating. Such motion may include, for example, the user repeatedly moving the user's hand to the user's mouth.

[0349] The user interface 1202 may also include activity events, such as walking events 1216. In some examples, the walking events 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 events 1216 may be based at least in part on user input (e.g., input via the user device 132 indicating that walking has occurred).

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

[0351] The user interface may also include guidance comments. For example, the user interface may include a guidance bubble 1210 stating "spikes at 1pm for the past 3 days" and a second guidance bubble 1226 stating "medication is best taken before bedtime." In some examples, the guidance bubbles are provided in the morning and data event indicators appear throughout the day as time progresses. If the guidance bubbles 1210, 1226 are provided in advance, the guidance may prompt the user to take action, for example, modifying breakfast meals or taking a midday walk to address recurrent glucose spikes at 1pm. In some examples, the guidance bubbles 1210, 1226, etc. may be selected to launch a chatbot function to provide guidance to the user.

[0352] In some examples, the user interface may include a gaming feature (e.g., awards or badges) to encourage user engagement. For example, the user interface 1202 may present a badge 1218, which may show a still or animated walking person, and may also present a comment, "Postprandial Walking Skill Unlocked!" to acknowledge the activity behavior by the patient. In some examples, the decision to award the Postprandial Walking skill may be made by the system (e.g., a remote system connected via the network 124 or a processor in the user device 132). The user interface may also include a medication badge (Rx) 1228, on which a message, "Medication Optimization Skill Unlocked," may be displayed. In some examples, the system may determine to award the medication badge 1228 based on fulfillment of a dosing condition (which may be detected by an activity sensor, a posture sensor, a physiological sensor, or any combination thereof), such as administration of a medication within a specified period of time before sleep. In some examples, machine learning techniques may be used to associate the gaming feature with a patient outcome, such as a desired level of glucose control. In this manner, the system may deploy the gaming feature to improve patient outcomes, thereby increasing the effectiveness of the system.

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

[0354] FIG. 13 is a flow chart diagram of a method for identifying or selecting patients who may benefit from an enhanced disease management program, such as intermittent CGM or other high fidelity monitoring for the management of type 2 diabetes, or low fidelity monitoring (e.g., activity monitoring) with optional correlation 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 enhanced monitoring. For example, the method may include determining an estimated likelihood that the patient will benefit from an enhanced monitoring scheme. The estimated likelihood may be a calculated value or percentage, such as 75%, 90%, or 95%, which may optionally be configurable by a user (e.g., a patient or a medical system administrator). The method may include a measurable improvement as an indicator that the patient will benefit (or has benefited) from enhanced monitoring, such as a reduction in A1c, achievement of an A1c goal (e.g., A1c less than 7.0), or reduced glucose variability, or any combination thereof.

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

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

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

[0358] At 1306, the 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 for participation in intermittent high-fidelity monitoring. The second screening algorithm may be based at least in part on results obtained using the first monitoring scheme. In some examples, the intermittent high-fidelity monitoring may include continuous glucose monitoring. In some examples, the screening may be based at least in part on factors of adherence to the use of the first scheme (e.g., low-fidelity monitoring techniques) (e.g., whether the user adhered to the monitoring plan). For example, a factor determining to utilize high-fidelity monitoring may be the extent to which the patient adhered to low-fidelity monitoring instructions or procedures, such as wearing an activity monitor or taking blood glucose meter measurements according to a specified schedule.

[0359] At 1308, a second monitoring scheme may be applied. For example, method 1301 may include providing a second kit to participants of the determined cohort. The second kit may be structured and configured to enable participants of the determined cohort to perform high fidelity monitoring of their health for a second time period using a second monitoring technology and obtain second results. In some examples, the second kit may include a continuous glucose monitor. The second kit may be structured and configured based on the obtained first results. For example, in examples where the second monitoring scheme is continuous glucose monitoring, the number or type (or both) of glucose sensors provided in the second kit may be determined based on the obtained first results. In some examples, a decision may be made to include some sensors of a first type that use a first communication technology (e.g., NFC that must be swiped by the smart device to pull glucose data), or some sensors of a second type that are 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 intervention, or a mix of sensors of the first and second types.

[0360] At 1310, the method may include providing guidance. For example, the method may include presenting the 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 the device in the first kit. The communication may be provided, for example, during the first monitoring. The communication may provide the patient or caregiver with guidance (e.g., coaching information regarding steps to take to lower glucose levels, such as exercise, or feedback regarding glucose control, such as estimated average glucose concentration or variability for a specified time, or both). The guidance may include diabetes management guidance, including, for example, lifestyle changes related to diet or exercise, glucose level monitoring, or medication, or any combination thereof. In some examples, the guidance may include an indication of a time period or time schedule for employing high fidelity monitoring, such as one week, or ten days, or one week per month.

[0361] The method may optionally further include providing a third kit to one or more participants of 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, where the number or type (or both) of sensors is determined at least in part based on the obtained second results.

[0362] While a progression from low to high fidelity is described above, the method may alternatively include a progression from high to low fidelity. For example, the first monitoring scheme may include high fidelity monitoring (e.g., using a CGM), the screening for 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.

[0363] The method 1300 may be implemented in a specialized system that may include hardware components, software components, or both, such as the system 2200 shown in Figures 22A, 22B, 22C, and 23. For example, patient data may be retrieved from electronic storage and analyzed using a process to determine, for example, patients that 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 cohort of patients.

[0364] 14 is a flow chart diagram of an exemplary method of 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, the likelihood being greater than a calculated value. The patient pool may represent, for example, a group of patients in a clinical practice, or a designated insurance pool or program, or a geographic location, or a workplace, or any combination thereof.

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

[0366] At 1406, the patient may be monitored for a second time period using a second monitoring technique, which may produce a second result (or set of results). In various examples, the first time period may be a subset of the second time period or may overlap with the second time period.

[0367] In some examples, the first technique may include high fidelity monitoring, and the second technique may include low fidelity monitoring that may be determined at least in part 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 level). In some examples, the first technique may include activity monitoring using a wearable fitness tracker, such as a heart rate monitor, an activity monitor, a smartphone, smart glasses, or a smart watch, or any combination thereof. In some examples, the second monitoring, low fidelity technique, may include receiving user input data, such as medication data, dietary data, exercise data, sleep data, or any combination thereof.

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

[0369] At 1408, an action that the patient may take may be determined based on the first result and the second result. The action may be calculated to increase the likelihood of fulfillment of the control condition. For example, the action may be calculated to increase a parameter related to the patient's health by more than a predetermined amount with confidence greater than a predetermined confidence level. For example, the action may be calculated to increase the amount (e.g., percentage or minutes or hours) that the estimated glucose concentration level is within a specified range, such as the time within range. In another example, the action may be calculated to change (e.g., increase or decrease) glycemic variability by a specified amount.

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

[0371] In some examples, delivering guidance may include displaying (or otherwise communicating via a device or system) optimized periods during which the patient should employ high-fidelity monitoring.

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

[0373] FIG. 15 shows an example of a method 1501 for setting up a patient user account on a server so that the patient can automatically log in using an app on a mobile device with minimal information input.

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

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

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

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

[0378] It should be noted that the functionality of the server used in the automatic login procedure discussed above may be distributed across multiple servers that may or may not be controlled by the same entity. For example, in one particular example, one or more 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.

[0379] FIG. 16 is a diagram of an exemplary user interface 1600, which may be presented, for example, on a display of a smart device, such as the handheld device 112, or on a display of the wearable device 120. The user interface 1600 may include a trend graph 1602 that may show high fidelity data (e.g., CGM data) plotted against time for a portion of the current day. The user interface screen shown in FIG. 16 may be accessed by selecting a button (labeled "Glucose") on the user interface. The user interface 1600 may include a legend 1604 that provides descriptive information about the plot. A time selector user interface element 1610 may allow a user to control the period for which data is displayed (e.g., today, yesterday, two days ago, or a full week). The user interface 1600 may also provide a time-in-range chart 1606, which may show, for example, a percentage (as shown) or a period (e.g., minutes or hours) within some period (e.g., days of a week as shown, or portions of a day such as morning, afternoon, evening, night, etc.). The interface 1600 may include an input element 1608 that allows 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 may receive user input for the time-in-range chart, allowing the user to select, for example, a particular week for which to display data, or a different size period (e.g., a fraction of a day, or a range of weeks, or months). In some examples, both trend graphs may be displayed simultaneously, or a scrollable portion 1614 (shown in dashed lines) may be visible on the display screen, and the user interface may receive user input (e.g., via a touch screen) to scroll or zoom to show the time-in-range graph in addition to, or as an alternative to, the trend graph.

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

[0381] FIG. 17 is a diagram of an exemplary chat user interface 1700, which may be presented, for example, on the display of the handheld device 112 or on the display of the wearable device 120. The chat user interface 1700 may be accessed by selecting a chat user interface element 1702, which may initiate a chat session in a chat window 1704 with a human coach or a chatbot coach. The chat user interface 1700 may also include a context field 1706. The context field 1706 may include a guidance message that may be provided, for example, 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 voice recognition software. For example, the user may ask, "Why should I eat vegetables?" and the coach (e.g., a chatbot) may respond, "Vegetables tend to help keep glucose in range because they have fewer simple carbohydrates than foods like bread or sweets." In some examples, 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.

[0382] FIG. 18 illustrates a chat interface 1800 with a chart in the context field 1802. The chart may be, for example, a range time chart, such as a percentage-based chart shown in the context field of FIG. 18, or a time-based chart of the context field shown in the user interface 1900 shown in FIG. 19, or the chart may be a trend, as shown in FIGS. 16 and 21. In another example, the user interface 2000 may include a text message in the context field 2002. Users and coaches may interact with the chat fields 1804, 1904, 2004, for example, to ask or answer questions regarding the chart. In space-constrained devices, input from the user may advantageously be received via a microphone and voice recognition software to avoid clashing demands on screen space with the chat field 1804, keyboard (not shown), and context field 1802. For example, the auditor's chat function (e.g., using a microphone and speaker) may be initiated by selecting the chat button 1620 in the interface shown in FIG. 16. In some examples, the chat session may be triggered by sensed data, information about the patient, or other chat trigger conditions. For example, the chat session may be triggered in response to a trend that meets a trend condition or range condition, which may enable, for example, the patient or user to take corrective action (e.g., participate in an activity such as exercise, or change dietary choices, or administer medication). For example, the chat session may be triggered by an estimated glucose concentration level that is likely to rise or fall rapidly, or to be significantly out of range, or is out of range under times or circumstances when glucose is normally within range, or is out of range for more than a specified period of time (e.g., 12 hours, out of range), or is out of range by more than a specified percentage over a specified period of time (e.g., a specified number of days or weeks, more than 60%).

[0383] 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 preferences or characteristics regarding the sophistication or use of the interface by the user. In some examples, the user interface may provide fewer options, a larger display, or simpler information to accommodate users who show a tendency or preference for less sophisticated interactions. In some examples, the user interface may adapt based on the user's age or time of birth (e.g., year). For example, users who meet certain age criteria (e.g., over 60, 65, or 70 years old) may be presented with a user interface with a specified appearance scheme (e.g., color scheme or high contrast) or larger buttons or larger fonts.

[0384] FIG. 21 is a diagram of an exemplary user interface 2000. The user interface 2000 may be in a landscape mode view (e.g., wider than it is long, which may be useful when a handheld smart device is turned sideways). The user interface 2000 may be scrollable laterally to display data for a period of time to the left (i.e., before) or right (i.e., after) the currently displayed data. For example, when a user touches the screen and swipes right, the data may "slide" to the right to show data for hours before 9:00 PM, and in response to a user swipe to the left, the data may slide left to show data for hours after 4:00 PM, for example. The user interface 2100 may also include a user interface element 2102 (e.g., a "View Now" button), and in response to a user selection of the user interface element 2102, the user interface may refresh or slide left or right as necessary to show data for the current time. A slideable user interface may be useful for coaching, for example, a user may receive instructions from a coach to view data for a particular time or event (e.g., dinner) and then receive instructions to select user interface element 2102 to return to the current data.

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

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

[0387] The system may include one or more web service systems, which may include, for example, one or more servers configured to communicate over a network with or regarding the user computing device 2206, the CGM sensor 2202, the activity sensor 2204, or other devices. For example, a first web service system 2212 may collect information related to continuous glucose management, and a second web service system 2214 may collect activity information, and optionally 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 computerized coach via coaching guidance via the user computing device 2206 or telephone follow-up communication. In some examples, the coaching server 2216 may be or include the coaching server 2412 or the coaching server 2512 shown in FIGS. 24 and 25 and described below. Although the web services systems 2212, 2214 and the coaching server 2216 are shown as three separate systems, they may alternatively be part of a single system (e.g., a subsystem), or a single system may perform the tasks of two or more systems.

[0388] FIG. 22B is a diagram of an example system 2200A that is a configuration of the 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 monitor sensor 2202. In some examples, the first communication link is managed by the user computing device 2206, e.g., by an operating system of the user computing device 2206. The first communication link can be, for example, a wireless communication link, such as Bluetooth, Bluetooth LE, or other suitable wireless communication link. The continuous glucose monitor sensor 2202 can transmit CGM data, including, for example, glucose data describing an 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 describing the participant 2201 and / or diagnostic data describing the performance of the continuous glucose monitor sensor 2202.

[0389] The second data application 2210 can be configured to establish a second communication link with the activity sensor 2204. The second communication link can be, for example, a wireless communication link similar to the first communication link. The activity sensor 2204 can provide activity data describing the activity of the participant 2201 to the second data application via the second communication link. For example, an accelerometer or other suitable sensor of the activity sensor 2204 can capture data indicative of the motion 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 an output device, such as, for example, a lamp, a display screen, a speaker, etc., to communicate the UI data to the participant 2201. The UI data can describe, for example, the activity of the participant 2201, captured by the activity sensor 2204.

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

[0391] However, communicating CGM data between the first data application 2208 and the second data application 2210 may raise data security issues. For example, there may be a risk that the CGM data may be maliciously intercepted by another application (not shown) running on the user computing device 2206.

[0392] To prevent the CGM data from being intercepted, the first data application 2208 and the second data application 2210 can be configured to communicate via a secure communication protocol, an example of which is described herein with respect to FIG.

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

[0394] Figure 22C is a flow chart illustrating an example of a process 2270 that may be executed in the system 2200A of Figure 22A to display CGM data on the activity sensor 2204. The process 2270 includes three columns 2271, 2273, 2275. Column 2271 includes actions performed by the first data application 2208. Column 2273 includes actions performed by the second data application 2210. Column 2275 includes actions performed by the activity sensor 2204.

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

[0396] In some examples, the first data application 2208 also adds an error detection code to the CGM data. The error detection code is data that can be used to verify the CGM data. The first data application 2208 generates an error detection code based on the CGM data 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, as described herein, to verify that the CGM data was transmitted correctly. Some error detection code techniques allow the second data application 2210 to correct transmission errors in the CGM data. Any suitable error detection technique can be used. In some examples, a cyclic redundancy check (CRC) technique is used. The error detection code can be encrypted or unencrypted.

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

[0398] The second data application 2210 receives and processes the CGM message 2277 in step 2278. Processing the CGM message 2277 may include decrypting the CGM data included in the CGM message 2277. The decryption may be performed using an encryption key. For example, the second data application 2210 may have access to the same encryption key used by the first data application 2208 to encrypt the CGM data. In other examples, the first data application 2208 encrypts the CGM data using the second data application 2210's public (e.g., non-secret) encryption key. The second data application 2210 may 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 in the CGM message 2277 and / or correct detected errors.

[0399] 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 error correction codes. The second data application 2210 transmits the device CGM message 2279 to the activity sensor 2204, for example, utilizing a wireless transmitter of the user computing device 2206. For example, the second data application 2210 can transmit the device CGM message 2279 directly to an operating system of the user computing device 2206. The operating system can instruct the wireless transmitter of the user computing device 2206 to transmit the device CGM message 2279 to the activity sensor 2204.

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

[0401] 23 is a more detailed diagram of the example system shown in FIG. 22A. In some examples, the first application 2208 may provide synchronized data (e.g., CGM data) 2218, which may be delivered (e.g., via wireless or wired networks) to a sensor data subsystem 2220 and communicated to the data services portion 2222 of the first web services system 2212. The first web services system 2221 may also include a registration subsystem 2224 and a provisioning subsystem 2226, which may provide information to an eligibility subsystem 2228, which may determine the eligibility of a subject (e.g., participant 2201) to receive a CGM sensor system, and may interact with a CGM fulfillment subsystem 2230 (which may be operated by a third party, e.g., a medical supply service) to deliver the CGM sensors to the participant 2201. The data services 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, which may provide information that may be used to determine registration, provisioning, or configuration of the CGM sensor system.

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

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

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

[0405] The second system 2214 (or coaching server) may generate a push notification 2254 for delivery to the participant via the smart device (e.g., second app 2210) or activity sensor (e.g., watch) 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, for example, CGM information, such as a message or guidance regarding glucose concentration level information, or information regarding the provision, delivery, application (e.g., to the participant's body), replacement, scheduling (e.g., when or for how long to wear), or use of a CGM sensor.

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

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

[0408] 22A and 23 may be implemented as hardware systems, software modules or applications, or combinations thereof. The interaction of the various systems and subsystems may improve the delivery of guidance and / or sensors to participants, improve patient management, and promote positive clinical outcomes.

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

[0410] The cloud computing architecture 2410 can include one or more health data servers configured to receive the patient's analyte data. The transceiver 2404 and / or the cloud computing architecture 2410 can receive the patient's analyte data and generate a self-referential data structure that can display or analyze the patient's analyte data in a more meaningful way. For example, the CGM 2402 readings can be used to generate a self-referential data structure to display the patient's analyte data in a meaningful and easy to understand graphical display for use by the patient and / or a coaching personnel operating the coaching server 2412. The display self-referential data structure can include tables encoded with flagged analyte sensor data, such that the self-referential data structure can be used to individually generate various analyte trend displays on demand without querying multiple databases to gather the data required to generate the desired graphical display.

[0411] In some embodiments of the systems, devices, and methods of the present disclosure, health-related and non-health-related data are aggregated, structured, and / or transformed to intelligently generate outputs, including constructing new analytical data, displaying, and controlling devices of the system and 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, and the like. It is recognized that implementation of such embodiments of the present technology improves the operation of the system, for example, by reducing the complexity of data processing and data transmission between devices, reducing the amount of data and processing algorithms stored and manipulated, and thereby speeding up the performance of the system, as described herein. Furthermore, it is envisioned that implementation of such embodiments of the present technology improves the user's ability to manage diabetes or other disorders through continuous analyte monitoring.

[0412] Some advantages of the described method and system may include the following: The self-referential data structure eliminates the need for the processor to search and call the necessary information from various parts of the system to generate the graphic display. For example, without the self-referential data structure, the processor would otherwise have to search, query, and / or call various parts of the system each time a user requests a different graphic or requests a change in the displayed graphic. In this manner, 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, with the self-referential data structure, the system does not need to store or process additional algorithms, such as, for example, pattern recognition algorithms, to generate an output, such as a display to convey pattern information to the user. Furthermore, the self-referential data structure may reduce the amount and frequency of data transmitted for the purpose of generating the graphic display. Correspondingly, associated processing or graphing algorithms to be stored and manipulated are also reduced, improving system performance.

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

[0414] FIG. 25 illustrates an exemplary coaching system 2500 that can be used to implement automated and semi-automated coaching services for users of the CGM system 2400. The coaching system 2500 can include a coaching module 2502. The coaching module 2502 can include subroutines, programs, and 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 can include an initializer module 2504 designed to introduce the patient to available sub-coaching modules and engage the patient in one or more of those modules, an exercise module 2506 designed to encourage and coach the patient in engaging in mobility and physical activity, a diet module 2508 designed to help the patient better understand the relationship between dietary choices and blood glucose levels, and a sleep module 2510 designed to encourage and coach the patient in obtaining quality sleep while monitoring and managing glucose levels to avoid diabetic complications. The sub-coaching modules described are intended as examples and not limitations. One skilled in the art can envision other sub-modules of the coaching module 2502 that can provide support, education, monitoring, and coaching of different skills or activities beneficial to diabetes management and improvement. 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 human personnel trained to coach diabetes patients.

[0415] The coaching module 2502 and its submodules provide coaching by suggesting activities, by making a commitment to perform the activity (e.g., by scheduling a time and / or location to perform the activity), by setting goals (e.g., by asking the patient to commit to performing a desired number of repetitions of the activity or by refraining from the activity for a few days, etc.), by monitoring results (e.g., by examining one or more associated glucose trend graphs), by deriving alternative approaches to the activity in case of suboptimal results (e.g., going for a walk closer to mealtimes if PPW glucose levels do not improve despite walking), and by repetition. The coaching module 2502 provides alarms, scheduling, reminders, and follow-up services to continuously encourage and monitor the patient's progress, interest, and engagement. The coaching module 2502 can provide congratulations in case of good results, encouraging and / or motivational messages when results are mediocre, and alert the coachee when results are alarming or substandard.

[0416] Initializer Module When a patient is newly set up with the CGM system 2400, there is also an opportunity to set up the patient with automated coaching and provide preliminary general or specific education on diabetes and techniques and approaches to living with diabetes. FIG. 26A illustrates an example process 2600A performed by the initializer module 2504. The process 2600A can begin at step 2602A via the patient's action (e.g., by inputting 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). The process 2600A can begin automatically when the analyte sensor application 2405 detects a new patient. In step 2604A, the process determines whether the new patient has set up a new CGM device. If the answer is no, the process 2600B of FIG. 26B is performed. If the answer is yes, the process 2600A moves to step 2606A by displaying a message containing general educational information on blood glucose levels, their meanings, their behavior, and the purpose of the coaching program. The coaching module 2502 and its sub-modules may use colloquial and / or simple conversational language to eliminate potential confusion, generate more 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 may include the following: "Your blood glucose level does not stay constant, it changes. Sometimes it goes up, even up a lot, and sometimes it goes down."

[0417] The process then moves to step 2608A by generating a graphical display of the patient's analyte data (e.g., a glucose trend graph related to the patient's glucose levels over the past few hours). In addition to the graphical display of the patient's analyte data, the process may display educational graphics illustrating what may be considered "spikes" or fluctuations in the analyte data. The educational graphics may include animation, text, or other visual indicators to convey information to the patient and display the patient's glucose trend graph, and if not available, display a general glucose trend graph of the sample to the patient. If available, the initializer module 2504 may query and recall a self-referencing dataset related to the patient's recent past, generate an analyte trend graph from the self-referencing dataset, and display the graph to the patient. The self-referencing dataset may be recalled from storage on the transceiver 2404 or cloud computing architecture 2410.

[0418] In step 2610A, the process may invite the patient to examine their analyte trend graph to determine if they observe a spike or fluctuation in the analyte data. If the answer is no, the process moves to step 2612A by displaying a message or graphic congratulating the patient and encouraging the patient to continue to monitor their blood glucose level and engage in healthy behaviors. The process then moves to process 2600B of FIG. 26B. If in step 2610A the patient indicates that they observe a spike or an undesirable fluctuation in the analyte data, process 2600A moves to step 2614A by asking the patient if they can recall an event or situation before the spike or undesirable fluctuation occurred. Thus, the patient is encouraged to reflect and recall their choices, circumstances, or circumstances to develop an awareness of what impacts their health. If the patient recalls that event E occurred before the spike, the process moves to step 2616A where a message is displayed highlighting the relationship between event E and the patient's blood glucose level and encouraging the patient to note this relationship the next time event E occurs. The process then moves to process 2600B in FIG. 26B. If the patient does not recall what occurred prior to the spike observed in the analyte data, process 2600A moves to step 2618A. A message is displayed encouraging the patient to utilize the tools and sub-modules provided by coaching module 2502 to learn how various activities, situations, and life events affect blood glucose levels. The process then moves to process 2600B in FIG. 26B.

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

[0420] FIG. 26B illustrates an example process 2600B executed by the initializer module 504. The process begins at step 2602B and moves to step 2604B by displaying educational information regarding safe ranges for 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 displayed educational information may indicate, "Safe blood glucose ranges vary based on individual circumstances, but broadly speaking, blood glucose should be between 70 and 180 after meals and below 130 several hours after meals. Before bedtime, blood glucose should be between 100 and 140." The displayed educational information regarding safe ranges may alert the patient to use a custom range if prescribed by the patient's physician. The displayed educational information may further include an introduction to tools available in the coaching module 2502 to assist the patient in maintaining blood glucose levels in a safe range.

[0421] The patient is further encouraged to check their blood glucose level frequently and more frequently after activities that affect their blood glucose level. For example, the patient is instructed to check their glucose reading before and after eating, during physical activity, stress, or before going to bed. Another recommended time to check the glucose level is when calibrating the CGM 2402. If the patient can get used to checking their blood glucose level more frequently, the patient will be more likely and have more opportunities to observe and learn the effects of various choices and activities on their blood glucose level. The process moves to step 2606B by asking the patient to guess what their current blood glucose level is. The coaching module 2502 and its submodules can encourage further engagement from the patient using fun and engaging questions. The patient can input an estimate of their current blood glucose level via an interesting and attractive graphical display, such as a slide bar, scroll bar, text and arrows, or other images designed to work with a touch screen or voice recognition technology. The process then moves to step 2608B by presenting the patient with a recent glucose trend graph of the patient, which may include an indication of the actual current glucose level. The patient is invited to review the trend graph to observe their current and recent blood glucose levels.

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

[0423] In general, the coaching module 2502 can be configured to generate coaching alert tickets and notify the coachee when the patient's responses and interactions with the patient indicate a lack of interest, motivation, or commitment. Living with diabetes can be challenging. Responses indicating a lack of interest and commitment may be indicators of depression or a sign that the patient may need psychological or spiritual help to deal with the challenges of living with diabetes. As part of generating coaching alert tickets, the coaching module 2502 or its submodules can gather relevant contextual information to assist the coachee in efficiently and quickly responding to the patient. For example, in response to an activity in which the patient indicates a lack of enthusiasm, the coaching module 2502 can present questions to the patient and obtain answers relevant to providing coaching and counseling regarding the activity.

[0424] The coaching module can further annotate, label, and categorize the patient's contextual information so that coaching personnel can provide counseling and coaching services more efficiently and effectively. For example, if a patient initiates and predicts healthy activities but fails to achieve the predicted goals, the contextual information used to create a coaching alert ticket can include a label stating "committed but unable to achieve." On the other hand, if a patient refuses to schedule an activity and the patient's response indicates a lack of confidence in the proposed activity, the contextual information can include a label stating "patient does not believe in the proposed activity." Coaching personnel operating the coaching server 2512 can examine the contextual information labels for efficient and timely review of the patient's medical history and the patient's current issues. In some embodiments, coaching personnel operating the coaching server 2512 can specialize in certain areas of providing coaching and assistance to patients. For example, some coaching personnel may specialize and have special training in providing counseling and coaching to patients who are not disciplined in monitoring their diet. The contextual information labels can be used to route the coaching alert ticket to coaching personnel who specialize in dealing with the underlying issues.

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

[0426] Exercise Module The coaching module 2502 may include an exercise module 2506 to encourage and guide the patient to engage in physical activity and observe the benefits and correlation between physical activity and improved glucose levels. FIG. 27 illustrates a process 2700 that may engage a patient with an automated or semi-automated coaching system submodule focused on exercise and physical activity. Beneficial mobility and physical activity for a diabetic patient can be as simple as taking a walk after a meal. Since Post Prandial Walk (PPW) may be a focus area for coaching, the process 2700 of FIG. 27, the process 2800 of FIG. 28, and the process 2900 of FIG. 29 are described in relation to PPW. Those skilled in the art may envision other types of physical activity or mobility that may be implemented using the processes 2700, 2800, and 2900 without departing from the spirit of the described technology.

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

[0428] If the patient indicates an interest in trying PPW, the process moves to step 2714, where the patient is asked to select a meal for practicing PPW and a time when the exercise module 2506 can check with the patient about the results. A follow-up reminder is scheduled based on the patient's response. When the time for the follow-up arrives, the process moves to step 2716, where the patient is asked if the patient can practice PPW as scheduled and what the results were. If the patient's response indicates a practice failure or unexpected results after practicing PPW, the process can perform steps 2708 and 2710 to collect information and create and transmit a coaching alert ticket. The process ends at step 2712. If the results of PPW were successful, the process moves to step 2720, where the patient is asked if he or she would like to repeat the success achieved by scheduling more PPW sessions.

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

[0430] If the patient is not interested in scheduling more PPW sessions, the process may perform steps 2708 and 2710 to gather information and generate and transmit a coaching alert ticket. The process then ends at step 2712. If the patient is interested in repeating the achieved success by scheduling more PPW sessions, the process moves to step 2722 to schedule future PPW sessions based on the patient's desired times and meals. The process then moves to step 2724 where the scheduled PPW sessions are used to perform a follow-up process 2800, as described in connection with FIG. 28. The process 2700 then ends at step 2726.

[0431] As described, in step 2704 of process 2700, the patient is asked if he or she has tried PPW before. If the patient responds yes, the process moves to step 2718, asking the patient what the results of the patient's previous PPW experience were. If the patient indicates unsuccessful or unexpected results, the process can move to step 2728, asking the patient if there is anything the patient could do differently to make PPW more successful. The patient can respond with free text, or by interacting with a menu or other visual interface, such as selecting a radio button from a drop-down menu, or from a menu of pre-populated responses (e.g., "walk longer," "walk faster," "walk to meal times"). The process can move to step 2730, asking the patient if they would like to try one or more of the alternative approaches just indicated. If the patient responds with no interest, the process can execute steps 2708 and 2710 to gather information and generate and transmit a coaching alert ticket. The process then ends at step 2712. If the patient responds affirmatively, the process moves to step 2732 where a future PPW session can be scheduled based on the patient's desired time and meal. The scheduled PPW session is used to perform a follow-up process 2800, as described in connection with FIG. 28. The process 2700 then ends at step 2734.

[0432] FIG. 28 illustrates a process 2800 for performing follow-up on the progress of a patient who has been introduced and scheduled for PPW or other recommended activities beneficial to diabetes management. Process 2800 begins at step 2802. After the pre-scheduled time for the PPW session arrives or a predetermined time after the scheduled time, the process moves to step 2804 and asks the patient if they are able to practice PPW as scheduled. If the patient responds negatively, the process can perform steps 2806 and 2808 to gather context information and create and transmit a coaching alert ticket. The process then ends at step 2810.

[0433] If the patient indicates that they can practice PPW as scheduled, the process moves to step 2812, where the patient is asked if their blood glucose levels were within a safe or desirable range after the PPW session. If the answer is no, the process executes steps 2806 and 2808 to gather information and create and transmit a coaching alert ticket. The process then ends at step 2810. If the answer is yes, the process moves to step 2814, where the patient is asked how many days the patient expects to be able to practice PPW. If the patient's response is less than a minimum threshold (e.g., 0 or 1 day), the process may execute steps 2806 and 2808 to gather information and create and transmit a coaching alert ticket. The process then ends at step 2810. If the answer is equal to or greater than the minimum threshold (e.g., 2 days), the process may move to step 2816, where the predicted number of days of PPW activity is saved and transmitted to the confidence assessor / booster process 2900 as described in connection with FIG. 29. The process then ends in step 2810.

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

[0435] FIG. 29 illustrates an exemplary process 2900 that may be performed by the exercise module 2506 to further follow up, evaluate, or increase the patient's confidence in practicing PPW, or other suggested activities beneficial for diabetes. The process begins at step 2902. The exercise module 2506 may track the number of days the patient practices PPW. The process moves to step 2904, which determines whether the number of days the patient has practiced PPW is equal to or greater than the number of days the patient predicted to practice PPW. If the answer is yes, the process moves to step 2906, which asks the patient on a predefined scale (e.g., a scale of 0 to 10) how confident the patient is that he or she will be able to practice PPW over the next seven days. If the patient's confidence level exceeds a predefined minimum confidence number (e.g., 7), the process moves to step 2908, which displays a message congratulating the patient on their resolve and commitment. The process may then return to step 2902, and repeat the process 2900 after one week or another predefined period of time. If the patient's confidence level in their ability to perform PPW is lower than a predetermined confidence number (e.g., less than 7), the process may move to step 2910, asking if there is anything the patient can do to increase their confidence level that they will be able to achieve the scheduled number of PPW performances. If the answer is no, the process executes steps 2918 and 2920 to collect information and create and transmit a coaching alert ticket. The process ends at step 2922. If the answer is yes, the process may move to step 2912, asking the patient to enter their plan for successfully performing the scheduled number of PPW. The process may move to step 2914, asking the patient if they believe they can follow through with the plan. If the answer is yes, the process may move to step 2916, where the patient's PPW is tracked daily or obtained after a predetermined time (e.g., one week), and then the process may move to step 2902, where the process 2900 is repeated.If the answer is no, the process may perform steps 2918 and 2920 to gather information and create and transmit a coaching alert ticket. The process then ends in step 2922.

[0436] If it is determined in step 2904 that the number of days the patient has performed PPW is less than the scheduled number, the process moves to step 2924. If the number of days the patient has performed PPW is less than or equal to the predetermined minimum number (e.g., less than or equal to 2 days), the process performs steps 2918 and 2920 to collect information and create and transmit a coaching alert ticket. The process then ends at step 2922. If the number of days the patient has performed PPW is more than the predetermined minimum number (e.g., more than 2 days), the process moves to step 2926 to ask the patient if he or she believes that the scheduled number of days of performing PPW can be achieved. If the answer is yes, the process moves to step 2916, where the patient's PPW is tracked daily or obtained after a predetermined time (e.g., one week), and then the process moves to step 2902 and the process 2900 is repeated. If the answer is no, the process performs steps 2918 and 2920 to collect information and create and transmit a coaching alert ticket. The process then ends in step 2922.

[0437] The coaching module 2502 may include a diet module 2508 to encourage and guide the patient to understand and learn the impact of dietary choices on blood glucose levels and diabetes. FIG. 30 illustrates a process 3000 that may engage the patient with an automated or semi-automated coaching system submodule focused on diet. The process 3000 begins at step 3002. At step 3004, the patient is asked if he or she would like to learn how different food and dietary choices affect their blood glucose levels. If the answer is no, the process executes steps 3006 and 3008 to gather information and create and transmit a coaching alert ticket. The process then ends at step 3010. If the answer is yes, a message to the patient is displayed encouraging the patient's interest and involvement. The message may further make the patient aware of the relationship and correlation between diet and blood glucose levels. The messages can encourage the patient to continue to review their blood glucose readings and learn how different meal choices affect their glucose readings.

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

[0439] The process moves to step 3022 and displays a message via a text block or other graphic or visual display linking the patient's meal M to the patient's blood glucose level S. The message can be a sentence populated with the values ​​stored in variables M, F, and S. For example, the message could be "Meal <m>in <f>It can be constructed from the sentence "Eat and the blood glucose level rises". If F = chocolate cake, M = breakfast, and S = rises and stays there, the displayed message reads "Eat chocolate cake for breakfast and the blood glucose level rises and stays there". Various messaging formats and scenarios can be used to enhance understanding and learning about the effects of foods and meals on a patient's blood glucose level.

[0440] The process then moves to step 3024 and asks the patient if they are surprised by the result. If the answer is no, the process can move to step 3026, where the patient is blessed to track their post - meal glucose level and is advised to continue checking their post - meal glucose level. The process then moves to step 3028, where the patient is advised to use a meal - tracking tool to track more meals and their impact on glucose levels. The meal - tracking tool is described in relation to process 3100 of FIG. 31. The process then ends at step 3030. If the patient is surprised by the result of the glucose reading and the patient's answer at step 3024 is yes, the patient may require additional or individual coaching regarding the types of foods and meals and their impact on diabetes. The process can execute steps 3006 and 3008 to collect information and create and transmit a coaching warning ticket. The process then ends at step 3010.

[0441] In step 3014, if the patient knows what to consume for the scheduled meal time M, the process moves to step 3032 and stores the patient's planned meal in variable F. The process moves to step 3034, where the patient is asked how consuming food F for meal M affected the patient's blood glucose level. The patient's response can be stored in variable S. The process moves to step 3036 and displays a message constructed from variables M, F, and S. For example, the message reads "For meal <m>in <f>Eating and blood sugar <s>" with variables F = grilled fish, whole wheat toast, garden salad, M = lunch, and S = dropped. The message displayed might read, "I had grilled fish, whole wheat toast, and garden salad for lunch and my blood glucose went down." The process then moves to step 3024, where the patient is encouraged to use the food tracking tool of FIG. 31 to gain an understanding of the correlation between food and blood glucose.

[0442] FIG. 31 illustrates an example process 3100 that may be performed by the meal module 2508 to implement a meal tracking tool to encourage and guide a patient to understand the relationship between meals and blood glucose levels. The process 3100 begins at step 3102, either via input from a user indicating an interest in starting operation of the tool or by a complementary process or tool, such as process 3000. The process 3100 moves to step 3104, where the patient is asked to schedule a meal M for tracking. The patient's selection is stored and a reminder is scheduled a predetermined period T after the scheduled meal M. T may be, for example, 1 to 2 hours. The process moves to step 3106, where the patient waits a predetermined time T after the meal M. The process moves to step 3108, where the patient is asked what they ate at the scheduled meal M and the patient's response is stored in a variable F. The process then moves to step 3110, where the patient's glucose data is obtained for a period before and a period M after the meal M plus a predetermined time T. Glucose data for the relevant time period can be obtained from the patient, whereupon the patient reviews a glucose trend graph for the relevant time or obtained 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 asked if he or she observes any spikes or undesirable fluctuations in the glucose data. In other embodiments, the meal module can automatically examine and scan the glucose data for fluctuations by comparing the stored glucose values ​​to high or low thresholds. If there are no spikes or undesirable fluctuations in the glucose data, the process moves to step 3114, where a message is displayed encouraging the patient to continue checking their blood glucose levels and learn how to eat safely. For example, the message may read, "OK, every time you check your glucose after a meal, you will learn more about how to eat safely and enjoy food."

[0443] If the patient observes a spike or fluctuation in blood glucose level and the patient's response at step 3112 is yes, the process moves to step 3118, where the patient is asked if they can eat different foods that may have a better impact on their blood glucose level. If the patient indicates a lack of interest or knowledge about what they can do differently, the process can execute steps 3120 and 3122 to gather information and create and transmit a coaching alert ticket. The process then ends at step 3124. If the patient responds indicating a capacity to make better dietary choices, the process moves to step 3126, where the patient is asked to further question the patient to help determine the patient's resolve and interest. For example, in step 3126, the patient may be asked to input into the system what the patient can do differently next time (e.g., what the patient's dietary choices will be in the future). The process moves to step 3128, where it is determined whether the patient's planned choices are similar or different from the patient's previous choices that lead to undesirable fluctuations in blood glucose levels. If the patient's planned selections are the same or similar to the patient's previous selections, the process may perform steps 3120 and 3122 to gather information and create and transmit a coaching alert ticket. The process then ends at step 3124. If the patient's selections differ from the patient's previous selections, which indicate a plan aimed at maintaining safe blood glucose levels, the process may move to step 3104 to schedule a follow-up meal tracking session and process 3100 is repeated.

[0444] FIG. 32 illustrates an exemplary process 3200 that can be implemented in the meal module 2508 to encourage and coach a patient to increase efforts to monitor post-prandial blood glucose by using the meal tracking tool described in connection with FIG. 31. The process 3200 can be performed automatically at predetermined time intervals (e.g., weekly) or can be performed manually by the patient, beginning with step 3202. The meal tracking tool implemented via the process 3100 can be configured to track and store in a variable MT (meals tracked) the number of times the tool has been used and / or the number of meals the patient has tracked. The system can, by default, specify a desired number of meals to be tracked in a variable D, or query the patient, the patient's guardian, or a medical professional and / or coaching factor for the number of meals the patient is expected to track and store in variable D the value. In step 3204, the patient's tracked meals MT is compared to the desired or expected number of meals D to be tracked. If the tracked meal MT is equal to or greater than the expected tracked meal D, the process moves to step 3206, displaying a congratulatory message, and the process ends at step 3208. If the tracked meal MT is less than the expected number D, but more than half of the expected number D, in step 3210, the process moves to step 3212, where the meal module 2508 can be configured to send reminders, suggestions, and invitations to the patient to track meals and check glucose data. The process then ends at step 3214. If the tracked meal MT is less than half the desired number D, the patient may need more personalized coaching to increase efforts in tracking meals and checking glucose data. The process can perform steps 3216 and 3218 to collect information and create and transmit a coaching alert ticket. The process then ends at step 3220.

[0445] Sleep Module FIG. 33 illustrates an exemplary process 3300 that may be implemented by the sleep module 2510 to encourage and guide the patient to monitor overnight glucose behavior and better understand the beneficial effects of proper sleep on blood glucose levels. The process 3300 begins at step 3302. At step 3304, the process displays general and / or patient-specific data regarding the relationship between sleep and blood glucose. For example, such a display may read, "The better you sleep, the safer / healthier you are. Keeping your glucose within range (e.g., 100-140 mg / dL) while sleeping will help you sleep better and manage your diabetes better." The process then moves to step 3306. A glucose trend graph is generated from a self-referential data structure stored in the CGM system 2400 and presented to the patient. The patient is asked to review the glucose trend graphs for the past seven nights to determine the number of nights the patient's glucose level was in a safe range during the first few hours of sleep. In some embodiments, the sleep module 2510 may automatically determine whether the patient's glucose level was safe during the relevant time period. In some examples, machine learning techniques such as those described herein can be used to generate a model of the relationship between a patient's sleep and blood glucose.

[0446] In the context of providing automated coaching, encouraging the patient to study the glucose trend graph and learn how to read and correctly interpret the glucose data and graphs may be preferable to purely determining unsafe glucose fluctuations. Other safety and monitoring tools and modules within the CGM 2400 may better perform these tasks. Thus, in the context of providing automated coaching, the CGM system's ability to automatically analyze the patient's glucose data and double-check the patient's analysis and determination may be used secondarily. The analysis and interpretation of the patient's glucose data may be checked against the CGM system's 2400 automated analysis, and the patient, coaching personnel, or other interested parties may be notified if a discrepancy is detected.

[0447] If, in step 3308, the patient's glucose levels are within the safe range for the number of nights, the process moves to step 3310 where a message is displayed congratulating the patient on the approach and encouraging the patient to continue checking overnight or sleep hour glucose levels and trends. The process ends in step 3312.

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

[0449] If in step 3314 it is determined that the patient's overnight glucose levels have been in the safe range for at least five or six nights, the process moves to step 3324, where the patient is asked if there was anything they would have done differently on the nights when their blood glucose levels remained in the safe range. If the patient does not remember or is not sure, the process moves to step 3326, where a message is displayed encouraging the patient to track their overnight glucose levels for the next seven days (or other period that may be desirable based on the patient's age, medical history, or other factors). The process moves to step 3328, where the patient is asked how many nights he believes his glucose levels will remain in the safe range. The patient's response is stored in variable NP (predicted nights). If in step 3330 the predicted nights are five or more nights, the process moves to step 3332. A message is displayed congratulating the patient on their involvement and commitment to their health.

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

[0451] If, in step 3330, the patient predicts that their glucose levels will remain within the safe range for less than five nights, the process moves to step 3342, which displays a message inviting the patient to discuss with their coach any issues that may be affecting their ability to maintain safe nightly glucose levels. The process then performs steps 3318 and 3320 to collect information and create and transmit a coaching alert ticket. The process ends at step 3322.

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

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

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

[0455] In some examples, the analyte sensor system can be configured to perform high fidelity data collection, where captured data is retrieved after collection. This can be useful for patients who do not have access to wireless networks and / or do not regularly carry a smart device or other user computing device. Post-collection data retrieval can also minimize or eliminate the need for a user to set up a smart device to communicate with the analyte sensor system. This can enable clinicians to provide patients with access to analyte sensors with less training costs.

[0456] FIG. 34 is a diagram of an example system 3400 that can include an analyte sensor system 3402 configured to upload captured analyte data after collection. The analyte sensor system 3402 can be coupled to a host 3401, similar to the host 101 of FIG. 1. The analyte sensor system 3402 can be similar to the analyte sensor 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 the analyte data captured by the analyte sensor 3404. The sensor electronics 3406 can also be programmed to upload the captured analyte data after collection, for example, as described herein with respect to FIGS. 35-37.

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

[0458] The 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 the analyte sensor system 3402 (e.g., its sensor electronics 3406) via wireless communication signals 3410. The upload device 3450, in some examples, 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 in a pharmacist's, clinician's office, or other suitable location. The upload device 3450 can couple to the sensor electronics 3406 to retrieve the collected analyte data. The upload device 3450, in some examples, provides the downloaded analyte data to one or more 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.

[0459] FIG. 35 is a flow chart illustrating an example of a process 3500 that may be performed by the analyte sensor system 3402 (e.g., its sensor electronics 3406) to collect and upload analyte data. In step 3502, the sensor electronics 3402 detects that the analyte sensor system 3402 has been applied to the host 3401. Detection may occur, for example, when the analyte sensor 3404 begins to provide analyte data. In some examples, the sensor electronics 3402 detects that the analyte sensor system 3402 has been applied to the host 3401 when the analyte sensor 3404 provides a sensor reading that exceeds a threshold value over two different time periods. Consider an example in which 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 application of the analyte sensor system 3402 when the analyte sensor 3404 detects an estimated glucose value that exceeds a threshold value (e.g., 60 mg / dL) over two different 30 second time periods. In some examples, the sensor electronics 3406 detects application of the analyte sensor system 3402 when the analyte sensor 3404 detects an estimated glucose value above a threshold value (e.g., 60 mg / dL) for two consecutive 30 second periods.

[0460] In some examples, the sensor electronics 3406 receives a serial number of another sensor identifier of the analyte sensor 3404, for example, to properly calibrate the analyte data received from the analyte sensor 3404. The sensor electronics 3406 may 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 may be used, for example, a Bluetooth LE connection, a near field communication (NFC) connection, etc. Also, in some examples, the analyte sensor 3404 includes a radio frequency identifier (RFID) circuit. The sensor electronics 3404 may illuminate the RFID circuit with electromagnetic radiation, which may cause the RFID circuit to broadcast the sensor identifier. In optional step 3504, the sensor electronics 3406 may establish a wireless communication session with the smart device 3412, for example, as described herein. Step 3504 may be omitted in examples where blind analyte measurements are performed.

[0461] In step 3506, the sensor electronics 3406 periodically receives analyte data from the analyte sensor 3404 and stores the received analyte data, for example, in data storage hardware in communication with the sensor electronics 3406. The analyte data may include analyte values ​​and / or metadata describing the host 3401 and / or diagnostic data describing the performance of the analyte sensor 3404. The sensor electronics may receive and store the analyte data at any suitable period, 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 prompts may occur once per period. In examples where the sensor electronics 3406 has a communication session with the smart device 3412, the sensor electronics 3406 may also transmit some or all of the collected analyte data to the smart device 3412 (e.g., to the host 3401) for display.

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

[0463] If use of the analyte sensor 3404 has not ended, the sensor electronics 3406 may continue to periodically receive and store analyte data in step 3506. If use has ended, the sensor electronics 3406 may enter an upload routine in step 3510. Exemplary upload routines are described herein with respect to FIGS.

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

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

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

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

[0468] 37 is a flow chart illustrating another example of a process 3700 that may be performed by the sensor electronics 3406 to upload collected analyte data. Process 3700 is another exemplary way that the sensor electronics 3406 may upload collected analyte data in step 3510 of process 3500. As described herein, once sensor use is terminated, the analyte sensor device 3402 (or in some examples, just the sensor electronics 3406) is mailed or otherwise physically transported to a location where an upload device is present.

[0469] In the example of FIG. 37, once sensor use is terminated, the sensor electronics 3406 determines 3702 whether an upload request has been received (e.g., from the upload device 3450). The upload request may be transmitted using a suitable wired or wireless communication protocol. In some examples, a wireless protocol such as NFC is used, although other protocols such as Bluetooth, Bluetooth LE, MICS, etc. may also be used. If an upload request is not received, the sensor electronics 3406 continues to wait for an upload request in operation 3702.

[0470] If an upload request is received in operation 3702, the sensor electronics 3406 broadcasts system identification data in step 3704. In step 3704, the sensor electronics uses the system identification data to establish a communication session with the upload device 3450. For example, the upload device 3450 can receive the system identification data and use the system identification data to look up authentication data for 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 in step 3708. The upload device 3450 can then upload the uploaded analyte data to one or more servers 3425, 3426, 3427 for further review. For example, analyte data collected in this manner may constitute high fidelity data that can be used in conjunction with low fidelity data, for example, as described herein.

[0471] Although the methods and systems are often described herein with respect to estimated blood glucose concentration levels, such as levels determined by a CGM that estimates blood glucose concentration levels from measurements of subcutaneous fluid, the methods and systems may also be applied to other types of concentration levels, such as actual blood glucose concentration levels, or levels of other analytes in blood or other bodily fluids or substances. The methods and systems may also be applied to other physiological states or conditions whose management is desirable for health or other reasons.

[0472] Each of these non-limiting examples can stand on its own or can be combined in various permutations or combinations with one or more of the other examples.

[0473] The above detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show, by way of illustration, specific embodiments in which the invention may be practiced. These embodiments are also referred to herein as "examples." Such examples may include elements in addition to those shown or described. However, the inventors also contemplate examples in which only the elements shown or described are provided. Moreover, the inventors also contemplate examples using any combination or permutation of the elements shown or described (or one or more aspects thereof), either with respect to the particular example (or one or more aspects thereof) or with respect to other examples (or one or more aspects thereof) shown or described herein.

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

[0475] In this document, the terms "a" or "an" are used to include one or more, as is common in patent documents, regardless of other instances or uses of "at least one" or "one or more." In this document, the term "or" is used to refer to a non-exclusive "or," such that "A or B" includes "A but not B," "B but not A," and "A and B," unless otherwise specified. In this document, the terms "including" and "in which" are used as the plain English equivalents of the respective terms "comprising" and "wherein." Also, in the following claims, the terms "including" and "comprising" are open-ended, i.e., a system, device, article, composition, formulation, or process that includes elements in addition to those recited after such terms in the claim will still be considered within the scope of that claim. Moreover, in the following claims, the terms "first," "second," and "third," etc. are used merely as labels and are not intended to impose numerical requirements on their objects.

[0476] Geometric terms such as "parallel," "perpendicular," "circular," or "square" do not require absolute mathematical precision unless the context dictates otherwise. Instead, such geometric terms allow for variations due to manufacturing or equivalent functions. For example, if an element is described as "circular" or "generally circular," components that are not exactly circular (e.g., slightly rectangular or multi-sided polygonal) are also encompassed by this description.

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

[0478] The above description is intended to be illustrative, not limiting. For example, the above-described examples (or one or more aspects thereof) may be used in combination with each other. In light of the above description, for example, one of ordinary skill in the art may use other embodiments. The Abstract is provided to comply with 37 C.FR §1.72(b) to enable the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Also, in the above detailed description, various features may be grouped together to simplify the disclosure. This should not be construed as intending that an unclaimed disclosed feature is essential to the claims. Rather, inventive subject matter may include less than all features of a particular disclosed embodiment. Accordingly, it is contemplated that the following claims are incorporated into the detailed description as examples or embodiments, with each claim standing on its own as a separate embodiment, and that such embodiments can be combined with each other in various combinations or permutations. The scope of the present invention should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. [Explanation of symbols]

[0479] 100 Systems 101 Host 102 Analyte Sensor System 104 Analyte Sensors 106 Sensor Electronics 108 Secondary Medical Device 110 Radio communication signals 112 Handheld Devices 114 tablets 116 Smart Pen 118 Computer 120 Wearable Devices 122 Peripheral medical devices 124 Network 125,126,127 Server System 128 Remote Terminal 130,134,136 Wearable Sensors 132 User Devices 138 Wireless Access Point (WAP) 200 Medical Device Systems 202 Potentiostat 204 Processor 206 Command 208 Memory 210 Data Storage 212 Sensors 214 Battery 216 Recharging System 218 Wireless Communications 250 peripheral devices 252 User Interface 254 memory 356 processors 258 Wireless 260 Sensors 262 Power supply 270 Medical Devices 272 User Interface 274 Memory 276 processors 278 Wireless 280 Sensors 282 Treatment 284 Power supply 290 Base 2200, 2200A System 2201 participants 2202 Continuous Glucose Monitoring (CGM) Sensor 2204 Activity Sensor 2206 User Computing Device 2208 First Application 2210 Second Application 2212 First Web Service System 2214 Second Web Service System 2216 Coaching Server 2218 Synchronized Data (CGM Data) 2220 Sensor Data Subsystem 2222 Data Service Part 2224 Registration Subsystem 2226 Provisioning Subsystem 2228 Eligibility Subsystem 2230 CGM Execution Subsystem 2232 Second Sensor Data Subsystem 2234 Synchronized Data (Activity Data) 2236 Activity Detection System 2238 Intervention Engine 2240 Conversation Server 2241 Coach 2242 Coaching Dashboard 2244,2246 Guidance section 2248 Coach Pool 2250 Call Center 2252 Reporting Adverse Events 2254 Push Notifications 2256 Second Push Notification 2258 Web Application Programming Interface (API) 2260 Activity Sensor Authentication System 2262 Authentication System 2264 Group System 2266 Glucose Levels API 2402 CGM 2404 Transmitter / Receiver 2405 Analyte Sensor App 2410 Cloud Computing Architecture 2412 Coaching Server 2414 Coaching Module 2502 Coaching Module 2504 Initializer Module ...

Claims

1. 1. A method for monitoring a patient, comprising: monitoring low fidelity data for the patient using a low fidelity monitoring technique over a first period of time; using a machine learning model to determine whether high-fidelity data collection is warranted for the patient based on the correlation between the low-fidelity data and the high-fidelity data; in response to determining that high fidelity data collection for the patient is warranted, monitoring the high fidelity data of the patient using high fidelity monitoring techniques over a second time period, the high fidelity monitoring techniques including monitoring the glucose data of the patient using a continuous glucose monitoring device; the high fidelity data more faithfully represents the glucose data for the patient than the low fidelity data; Monitoring the high fidelity data for the patient using high fidelity monitoring techniques over a second period of time includes: monitoring the high fidelity data of the patient using the high fidelity monitoring technique over the second time period; monitoring the low fidelity data for the patient using the low fidelity monitoring technique over at least a portion of the second time period; updating the correlations in the machine learning model based on the low fidelity data and the high fidelity data monitored over at least a portion of the second time period.

2. The method of claim 1 , wherein the low-fidelity monitoring technique includes at least one of single-point glucose monitoring, blind continuous glucose monitoring, or optical monitoring techniques.

3. The method of claim 1 or 2, wherein the low-fidelity monitoring technique includes activity monitoring with a wearable fitness tracker.

4. The method of claim 3 , wherein the wearable fitness tracker comprises at least one of a wearable heart rate monitor, an activity monitor, a smartphone, smart glasses, or a smart watch.

5. The method of claim 1 , wherein the low fidelity monitoring technique includes receiving user input data including at least one of medication data, dietary data, exercise data, or sleep data.

6. The method of claim 1 , further comprising determining a goal for the patient based on the low fidelity data.

7. The method of claim 6 , wherein the goal comprises a diet goal, an exercise goal, a glucose level monitoring goal, or a medication goal.

8. 8. The method of claim 6 or 7, wherein determining the goal for the patient is based at least in part on the low fidelity data monitored using the low fidelity monitoring technique over the first time period.

9. 9. The method of claim 1, further comprising providing coaching functions to the patient over the first time period, the coaching functions including automated messages transmitted from a server to the continuous glucose monitoring device, the coaching functions being based on at least one of patient profile data or the low fidelity data.

10. The method of claim 1 , wherein the machine learning model comprises a supervised learning model.

11. The machine learning model is trained using labeled training data; The method of claim 10 , wherein the labeled training data includes sets of low-fidelity data and a label indicating whether each set of low-fidelity data justifies high-fidelity data collection.

12. The method of claim 1 , wherein the machine learning model comprises an unsupervised learning model.

13. The method of claim 12 , wherein the machine learning model is trained using unlabeled training data.

14. The method of claim 1 , wherein the machine learning model comprises a reinforcement learning model.

15. Obtaining low fidelity data; and generating a determination whether the low fidelity data justifies high fidelity data collection; obtaining feedback indicating whether the determination is correct; and The method of claim 14 , further comprising training the machine learning model by:

16. 1. A system comprising: a low-fidelity system configured to collect low-fidelity data relating to the patient over a first time period; a machine learning model configured to determine whether high-fidelity data collection is warranted for the patient based on a correlation between the low-fidelity data and the high-fidelity data; a continuous glucose monitoring device configured to collect high fidelity data associated with the patient over a second time period in response to determining that high fidelity data collection for the patient is warranted; the high fidelity data more faithfully represents the glucose data of the patient than the low fidelity data; the low fidelity system is further configured to collect the low fidelity data associated with the patient over at least a portion of the second time period; The machine learning model is further configured to update the correlation based on the low fidelity data and the high fidelity data collected over at least a portion of the second time period.

17. The system of claim 16 , wherein the low fidelity system includes an activity sensor.

18. The system of claim 16 or 17, wherein the low fidelity system includes a blood glucose meter.

19. 19. The system of claim 16, wherein the continuous glucose monitoring device comprises a continuous glucose monitor.

20. 1. A machine-readable storage medium having stored thereon instructions that, when executed by at least one processor, cause the at least one processor to: monitoring low fidelity data of the patient using a low fidelity monitoring technique over a first period of time; using machine learning techniques to determine whether high-fidelity data collection is warranted for the patient based on the correlation between the low-fidelity data and the high-fidelity data; in response to determining that high fidelity data collection for the patient is warranted, monitoring the high fidelity data of the patient using high fidelity monitoring techniques over a second time period, the high fidelity monitoring techniques including monitoring the glucose data of the patient using a continuous glucose monitoring device; the high fidelity data more faithfully represents the glucose data for the patient than the low fidelity data; Monitoring the high fidelity data for the patient using high fidelity monitoring techniques over a second period of time includes: monitoring the high fidelity data of the patient using the high fidelity monitoring technique over the second period of time; monitoring the low fidelity data for the patient using the low fidelity monitoring technique over at least a portion of the second time period; and updating the correlations in the machine learning technique based on the low fidelity data and the high fidelity data monitored over at least a portion of the second time period.

Images