Improving analyte monitoring by facilitating timely resolution of requested user actions

Abstract

In an embodiment, a method of facilitating resolution of requested user actions for analyte monitoring includes generating, on a device executing a continuous analyte monitoring (CAM) application, one or more requested actions to be displayed within the CAM application. The method also includes presenting the one or more requested actions within a centralized location of the CAM application and identifying a user selection of at least one requested action within the centralized location. The method further includes automatically presenting a software instance to address the at least one requested action in response to the user selection, receiving user input via the automatically presented software instance, and resolving the at least one requested action based on the received user input.

Description

IMPROVING ANALYTE MONITORING BY FACILITATING TIMELY RESOLUTION OF REQUESTED USER ACTIONS CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to and benefit of U.S. Provisional Patent Application No. 63 / 778,190 filed March 26, 2025, which application is hereby expressly incorporated by reference herein in its entirety as if fully set forth below and for all applicable purposes.INTRODUCTION

[0002] Many diseases or conditions are dependent upon maintaining analyte levels within an acceptable range. As one example, diabetes is a metabolic condition affecting hundreds of millions of people. For these people, monitoring blood glucose levels and regulating those levels to be within an acceptable range is important not only to mitigate long-term issues such as heart disease and vision loss, but also to avoid the effects of hyperglycemia and hypoglycemia. Maintaining blood glucose levels within an acceptable range can be challenging, as glucose levels are almost constantly changing over time and in response to everyday events, such as eating or exercising.

[0003] Advances in medical technologies have enabled development of various systems for monitoring analytes such as blood glucose, including continuous analyte monitoring (CAM) systems such as continuous glucose monitoring (CGM) systems, which measure and record glucose concentrations in substantially real-time. CAM systems are important tools for users of these systems to ensure that measured analyte values are within the acceptable range.SUMMARY

[0004] In an embodiment, one general aspect includes a method of facilitating resolution of requested user actions for analyte monitoring. The method includes generating, on a device executing a continuous analyte monitoring (CAM) application, one or more requested actions to be displayed within the CAM application. The method also includes presenting the one or more requested actions within a centralized location of the CAM application and identifying a user selection of at least one requested action within the centralized location. The method further includes automatically presenting a software instance to address the at least one requested action in response to the user selection, receiving user input via the automatically presented software instance, and resolving the at least one requested action based on the received user input.

[0005] In an embodiment, another general aspect includes a system for facilitating resolution of requested user actions for analyte monitoring. The system includes a memory comprising executable instructions and a processor in communication with the memory. The processor is configured to execute the executable instructions to generate one or more requested actions to be displayed within a continuous analyte monitoring (CAM) application and to present the one or more requested actions within a centralized location of the CAM application. The processor is further configured to execute the executable instructions to identify a user selection of at least one requested action within the centralized location, automatically present a software instance to address the at least one requested action in response to the user selection, receive user input via the automatically presented software instance, and resolve the at least one requested action based on the received user input.

[0006] In an embodiment, another general aspect includes a computer-program product that includes a non-transitory computer-usable medium having computer-readable program code embodied therein. The computer-program product is adapted to be executed to implement a method. The method includes generating one or more requested actions to be displayed within a continuous analyte monitoring (CAM) application and presenting the one or more requested actions within a centralized location of the CAM application. The method also includes identifying a user selection of at least one requested action within the centralized location, automatically presenting a software instance to address the at least one requested action in response to the user selection, receiving user input via the automatically presented software instance, and resolving the at least one requested action based on the received user input.BRIEF DESCRIPTION OF THE DRAWINGS

[0007] FIG. 1A illustrates an example of a therapy management system, in accordance with certain embodiments.

[0008] FIG. IB illustrates an example analyte sensor system including an example continuous analyte sensor(s) with sensor electronics, in accordance with certain embodiments.

[0009] FIG. 2 illustrates example inputs and example outputs that are generated based on the inputs, in accordance with certain embodiments.

[0010] FIG. 3 A illustrates an example of a process for creating and using a centralized location for requested actions within a continuous analyte monitoring (CAM) application, in accordance with certain embodiments.

[0011] FIG. 3B illustrates an example of a user interface for presenting requested actions, in accordance with certain embodiments.

[0012] FIG. 3C illustrates an example of a card for presenting requested actions, in accordance with certain embodiments.

[0013] FIG. 3D illustrates an exemplary flow interface for requested actions, in accordance with certain embodiments.

[0014] FIG. 4A illustrates an example of a process for organizing requested actions within a CAM application, in accordance with certain embodiments.

[0015] FIG. 4B illustrates an exemplary flow interface allowing for action status filtering, in accordance with certain embodiments.

[0016] FIG. 4C illustrates an exemplary flow allowing for requested action grouping and contextual data entry facilitation, in accordance with certain embodiments.

[0017] FIG. 5 A illustrates an example of a process for assisting resolution of requested actions within a CAM application, in accordance with certain embodiments.

[0018] FIG. 5B illustrates an example user interface sequence for addressing requested actions, in accordance with certain embodiments.

[0019] FIG. 5C illustrates another example user interface sequence for addressing requested actions, in accordance with certain embodiments.

[0020] FIG. 6 illustrates an example of a process for implementing group resolution of requested actions within a CAM application, in accordance with certain embodiments.

[0021] FIG. 7 illustrates an example of a process for graphical presentation of requested actions in association with other data, in accordance with certain embodiments.

[0022] FIG. 8 illustrates an example of a process for implementing an express onboarding flow, in accordance with certain embodiments.

[0023] FIG. 9A illustrates another example of a process for implementing an express onboarding flow, in accordance with certain embodiments.

[0024] FIG. 9B illustrates an exemplary express onboarding flow, in accordance with certain embodiments.

[0025] FIG. 10 illustrates an example of a process for determining and utilizing onboarding requested actions based on historical sensor life, in accordance with certain embodiments.

[0026] FIG. 11 illustrates another example of a process for implementing an express onboarding flow, in accordance with certain embodiments.

[0027] FIG. 12 illustrates another example of a process for implementing an express onboarding flow, in accordance with certain embodiments.

[0028] FIG. 13 A illustrates an example of a process for implementing an abbreviated onboarding flow based on a prior application installation, in accordance with certain embodiments.

[0029] FIG. 13B illustrates an exemplary abbreviated onboarding flow allowing for use of an existing in-session sensor, in accordance with certain embodiments.

[0030] FIG. 14 illustrates an example of a process for inferring information related to a user, in accordance with certain embodiments.

[0031] FIG. 15 is a block diagram depicting a computer system configured for facilitating timely resolution of requested actions.DETAILED DESCRIPTION

[0032] For certain patients, analyte measurements (e.g., analyte levels or concentrations) are generated and provided by wearable continuous analyte monitoring (CAM) systems. The analyte measurements are often viewable both in real time and retrospectively, for example, on a display device such as a smartphone or smartwatch. The analyte measurements may be viewed by patients, healthcare providers or caregivers or other users, for example, to enable improved control of the measured analyte and / or a related disease or condition. Diabetes patients, for example, often wear continuous glucose monitoring (CGM) devices that generate and provide glucose measurements.

[0033] To assist patients and other users with better managing analyte levels, a variety of CAM software applications (hereinafter “CAM applications”) have been developed by various providers.CAM applications enable users to be much more involved in the patients’ medical care. In particular, CAM applications can assist patients, caregivers, healthcare providers, or other users in improving lifestyle and / or clinical / patient outcomes by meeting a variety of challenges, such as analyte control, exercise, and / or other health factors. For example, CGM applications can assist patients, caregivers, healthcare providers, or other users in overnight glucose control (e.g., reduce incidence of hypoglycemic events or hyperglycemic excursions), glucose control during and after meals (e.g. use historical information and trends to increase glycemic control), hyperglycemia corrections (e.g., increase time in target zone while avoiding hypoglycemic events from overcorrection), and / or hypoglycemia treatments (e.g., address hypoglycemia while avoiding “rebound” hyperglycemia), to name a few.

[0034] CAM applications can provide assistance of the type described above in the form of user guidance. The user guidance can include, for example, a graphical summary of a patient’s data over time, information, warnings, and / or recommendations. As an example, a CAM application may help a user respond to a health condition in real time by predicting events or trends and providing treatment recommendations to address occurring or potential events or trends in real time. This type of calculated guidance and support may relieve the cognitive burden on the user. Some CAM applications may also allow data to be exported in various formats to be shared with third parties and / or to connect users directly with healthcare professionals for feedback, which may support an improved patient-professional dialogue. Thus, if properly utilized, CAM applications may increase quality of care while at the same time offering the potential to reduce costs for healthcare systems.

[0035] Oftentimes, CAM applications request that a user take various actions, for example, in support of a patient’s health and / or to improve CAM functionality provided by the CAM applications. The various actions can include, for example, reminders or instructions to administer treatment or medication (e.g., administer insulin, take oral medication, etc.), exercise (e.g., take a 10-minute walk), acknowledge an alert (e g., acknowledge an alert for hyperglycemia or hypoglycemia), eat a meal, rest or sleep, enter data (e.g., contextual data as further discussed below), combinations of the foregoing and / or the like. Such actions may be referred to herein as “requested actions.” Some requested actions may be scheduled (e.g., a daily reminder to take a medication at 8 am), while others may be dynamically determined by the CAM applications in response to an event or condition (e.g., an instruction to intake fast-acting carbohydrates inresponse to detected hypoglycemia or a detected trend towards hypoglycemia). In some aspects, requested actions can be monitored and logged by the CAM applications.

[0036] More particularly, in some aspects, some requested actions can relate to an instruction or reminder for a user to enter contextual data related to patient health dynamics, such as diet, activity, sickness, hormones, stress, sleep, medication and / or other rapidly changing factors. For example, a given requested action could be to input a meal, a completed activity, a wake-up time, a user rating or assessment of sleep or health, etc. In some aspects, contextual data can indicate, for example, the patient health dynamics in relation to specific times (e.g., a time of a meal or activity). Contextual data can be used to provide, for example, more accurate analyte predictions for individual patients according to their specific health dynamics. In addition, or alternatively, contextual data can facilitate the interpretation of analyte measurements to determine potential causes of health conditions and effects of patient behavior.

[0037] In some aspects, some requested actions can relate to an onboarding process for a CAM system and / or application. For example, a patient that is new to the CAM system and / or application can be required to execute an onboarding process that includes supplying profile data, completing training (e.g., educational content such as videos, wizards, etc.), and / or the like. Such requested actions related to an onboarding process may be periodically referred to herein as “onboarding requested actions.” In some aspects, completion of the onboarding process can be a prerequisite to using the CAM system and / or application.

[0038] For effective analyte monitoring, it is desirable for the CAM application to continuously, or frequently, capture the attention of users, and to stimulate the users’ interest in actively engaging with the application, for example, by causing the users to see, understand, and complete requested actions. Engagement generally indicates a degree of interaction a user has with a given technology, such as the CAM application. Because health technologies, including CAM applications, are voluntary use systems, the extent of user engagement with these technologies and applications is generally determined by the users’ perceived quality of experience, ongoing benefit of usage, and / or consideration of viable alternatives to using the technology.

[0039] In general, however, it is time-consuming and non-intuitive for patients and other users of CAM applications to identify and keep up with requested actions. Typically, users of CAM applications are tasked with managing a multitude of individual notifications generated by theCAM applications, some of which may be simply informative and others of which may include instructions or reminders. This can result in suboptimal user engagement with the CAM application.

[0040] Conventionally, requested actions of the type described above are presented to users only via individual notifications for each requested action, such as via push notifications and / or an in-app notifications. These notifications may repeat after a period of time if the requested actions have not been completed (e.g., as individual reminders for the same requested actions). Due to the abundance of such potentially redundant notifications, users may be confused, become irritated, and / or develop reminder or requested action fatigue. This is particularly true for users who would prefer a more passive, user-initiated approach to completing actions. Accordingly, it can be difficult for users to identify and resolve all of their requested actions. As a result, users may fail to take the requested actions with any regularity or timeliness, which failure may negatively impact patient health.

[0041] For many of the same reasons, it is typically burdensome for users of CAM applications to comply with requested actions to supply contextual data. This is especially problematic when the same or similar contextual data is to be entered for multiple requested actions, which can result in further user fatigue. In addition, many separate reminders are currently generated for logging events such as meals and moming / evening medications (e.g., individual notifications for several medications taken at once), which is likewise fatiguing for users. As a consequence of the foregoing, there may be reduced engagement with the CAM applications and less contextual data entered by users. The lack of contextual data can increase an amount of processing, data estimation, and data extrapolation that must be performed to make recommendations to users. This increased processing can carry an increased resource cost for the CAM system and / or a user device executing a CAM application, such as a smartphone or smartwatch.

[0042] Further to the above problems, visualizations of user-provided contextual data in conjunction with analyte data are usually produced in a static way and are not easily generated or customizable by the patient or other user. This makes customizing analytical visualizations difficult, which may decrease a user’s understanding of their compliance with one or more therapy recommendations. Also, it is technically challenging to visually integrate contextual data with analyte measurements in a way that draws attention to potential cause / effect relationships.Conventional charts or graphs, for example, may be unproductive since they typically require the patient, caregiver, or healthcare professional to study and interpret the data. This challenge complicates the task of obtaining contextual data in the first place, as the patient may not be convinced that inputting such information is worthwhile.

[0043] Adding to the above problems, CAM onboarding is currently time-consuming and interferes with a user’s ability to immediately interact with the CAM application. For example, CAM applications are typically non-usable until onboarding has been completed. Further, the CAM application may implement features that are not used by the patient (e.g., because the patient does not know how the feature works or because the patient is not interested in the feature). This problem is compounded if, for example, the CAM application needs to be reinstalled on the same or different device (e.g., due to a new user device).

[0044] In response to the above problems, in certain aspects described herein, a therapy management system can provide a CAM application that implements a centralized “requested actions list” location storing all requested actions for a user. In contrast to methods using repetitive notifications, the requested actions of the requested actions list can be more easily and intuitively reviewed, managed and resolved. In certain aspects, this requested actions list can also facilitate contextual data entry, especially in the scenario of multiple requested actions soliciting the same or similar contextual data. Further, in certain aspects, onboarding requested actions for the CAM application can be divided into individual modules for non-linear completion, which modules can be managed or completed utilizing the requested actions list.

[0045] Advantageously, in certain aspects, the improved ability for a user (e.g., patient) to enter or log contextual data in response to requested actions can result in an increased amount of contextual data, an increased amount of relevant data to be analyzed to determine pattems / suggestions, less data that needs to be estimated / approximated / predicted and, hence, a reduced processing burden for the CAM system and / or a user device executing a CAM application.

[0046] Advantageously, in certain aspects, using the approaches described herein, the CAM system may receive contextual data and events more frequently from users. This increase in contextual data may improve monitoring functionality of the CAM system, for example, by improving an accuracy of analyte (e.g., glucose) predictions for individual patients according to their specific contextual data. This improved accuracy may in turn improve the generation ofadditional actions for the patient. These additional actions, such as diet, exercise, and medication recommendations, may be followed and completed by the patient, resulting in a favorable improvement of the patient’s analyte levels.

[0047] Advantageously, in certain aspects, the approaches described herein can reduce user fatigue by providing a more relevant and less irritating presentation of requested actions via, for example, the centralized requested actions list discussed above. This reduced user fatigue can increase a likelihood that a user will comply with the requested actions and a likelihood of therapy compliance with CAM suggestions, which results in improved patient health.

[0048] Advantageously, in certain aspects, better indications of requested actions can increase user engagement, which in turn can increase a likelihood that the user completes the actions, thereby improving health. In an example, improved action clarity via, for example, the centralized requested actions list discussed above, can make it easier for users to follow instructions to improve health. In another example, as a result of the increase in contextual data and better indications of requested actions, the patient’s time in range (e.g., an amount of time during which the user’s analyte levels are within a predetermined desirable range) is maximized or increased, thereby improving the patient’s physical state and overall health. In another example, better indications of requested actions can result in an improved user understanding of contextual and / or event data in the context of CAM readings, thereby improving patient health. In certain aspects, in the case of onboarding, such indications can result in an improved onboarding experience for the user.

[0049] The techniques described herein for improved analyte monitoring by facilitating timely resolution of requested actions are described more fully herein with respect to FIGS. 1A-B, 2, 3A-D, 4A-C, 5A-C, 6-8, 9A-B, 10-12, 13A-B, and 14 below. Note that although certain aspects herein are periodically described with respect to the management of diabetes, a continuous glucose monitoring (CGM) system, and a CGM application, the techniques described herein are similarly applicable to any type of health management system that includes any type of analyte sensor (e.g., lactate sensor, ketone sensor, etc.), and / or any type of health management application (e.g., any type of CAM application).

[0050] As used herein, the term “continuous” analyte monitoring refers to monitoring one or more analytes in a fully continuous, semi-continuous, periodic manner, which results in a data stream of analyte values over time. A data stream of analyte values over time is what allows formeaningful data and insights to be derived using the algorithms described herein for facilitating timely resolution of requested actions. In other words, single point-in-time measurements collected as a result of a patient visiting their health care professional every few months results in sporadic data points (e.g., that are, at best, months apart in timing) that cannot form the basis of any meaningful data or insight to be derived. As such, without the continuous analyte monitoring system of the embodiments herein, it is simply impossible to continuously facilitate timely resolution of requested actions, as described herein.

[0051] Further, the data stream of analyte values collected over time, with the continuous analyte monitoring system presented herein, include real-time analyte values, which allows for deriving meaningful data and insight in real-time using the systems and algorithms described herein. The derived real-time data and insight in turn allows for facilitating timely resolution of requested actions. Real-time analyte values herein refer to analyte values that become available and actionable within seconds or minutes of being produced as a result of at least one sensor electronics module of the continuous analyte monitoring system (1) converting sensor current(s) (i.e., analog electrical signals) generated by the continuous analyte sensor(s) into sensor count values, (2) calibrating the count values to generate at least glucose and / or other analyte concentration values using calibration techniques described herein to account for the sensitivity of the continuous analyte sensor(s), and (3) transmitting measured glucose and / or other analyte concentration data, including glucose and / or other analyte concentration values, to a display device via wireless connection.

[0052] For example, the at least one sensor electronics module may be configured to sample the analog electrical signals at a particular sampling period (or rate), such as every 1 second (1 Hz), 5 seconds, 10 seconds, 30 seconds, 1 minute, 3 minutes, 5 minutes, etc., and to transmit the measured glucose and / or other analyte concentration data to a display device at a particular transmission period (or rate), which may be the same as (or longer than) the sampling period, such as every 1 minute (0.016 Hz), 5 minutes, 10 minutes, etc.

[0053] The real-time analyte data that is continuously generated by the continuous analyte monitoring system described herein, therefore, allows the therapy management system herein to facilitate timely resolution of requested actions, in real-time, which is technically impossible to perform using existing or conventional techniques or systems. Further, because of the real-timenature of this data, it is also humanly impossible to continuously process a real-time data stream of analyte values over time to derive meaningful data and insight using the algorithms and systems described herein to facilitate timely resolution of requested actions. In other words, deriving meaningful data and insight from a stream of real-time data that is continuously generated, processed, calibrated, and analyzed, using the algorithms and systems described herein, is not a task that can be mentally performed. For example, executing the algorithms described in relation to FIGS. 3A-D, 4A-C, 5A-C, 6-8, 9A-B, 10-12, 13A-B, and 14, in real-time and on a continuous basis, which would involve using a stream of real-time data that is continuously generated by a patient’s continuous analyte monitoring system and / or significantly large amount of population data (e.g., hundreds or thousands of data points for each one of thousands or millions of patients in the patient population) is not a task that can be mentally performed, especially in real-time at times.

[0054] Further, certain embodiments herein are directed to a technical solution to a technical problem associated with analyte sensor systems. In particular, each analyte sensor system that is manufactured by a sensor manufacturer might perform slightly differently. As such, there might be inconsistencies between sensors and the measurements they generate once in use. Accordingly, certain embodiments herein are directed to determining the performance of an analyte sensor system during a manufacturing calibration process (in vitro), which includes quantifying certain sensor operating parameters, such as a calibration slope (also known as calibration sensitivity), a calibration baseline, etc.

[0055] Generally, calibration sensitivity refers to the amount of electrical current produced by an analyte sensor of an analyte sensor system when immersed in a predetermined amount of a measured analyte. The amount of electrical current may be expressed in units of picoAmps (pA) or counts. The amount of measured analyte may be expressed as a concentration level in units of milligrams per deciliter (mg / dL), and the calibration sensitivity may be expressed in units of pA / (mg / dL) or counts / (mg / dL). The calibration baseline refers to the amount of electrical current produced by the analyte sensor when no analyte is detected, and may be expressed in units of pA or counts.

[0056] The calibration sensitivity, calibration baseline, and other information related to the sensitivity profile for the analyte sensor system may be programmed into the sensor electronicsmodule of the analyte sensor system during the manufacturing process, and then used to convert the analyte sensor electrical signals into measured analyte concentration levels. For example, the calibration slope (calibration sensitivity) may be used to predict an initial in vivo sensitivity (Mo) and a final in vivo sensitivity (Mf), which are programmed into the sensor electronics module and used to convert the analyte sensor electrical signals into measured analyte concentration levels.

[0057] In certain embodiments, during in vivo use, the sensor electronics module of an analyte sensor system samples the analog electrical signals produced by the analyte sensor to generate analyte sensor count values, and then determines the measured analyte concentration levels based on the analyte sensor count values, the initial in vivo sensitivity (Mo), and the final in vivo sensitivity (Mf). For example, measured analyte concentration levels may be determined using a sensitivity function M(t) that is based on the initial in vivo sensitivity (Mo) and the final in vivo sensitivity (Mf). The sensitivity function M(t) may expressed in several different ways, such as a simple correction factor that is not dependent on elapsed time (ti) of in vivo use, a linear relationship between sensitivity and time (ti), an exponential relationship between sensitivity and time (ti), etc. Equation 1 presents one technique for determining a measured analyte concentration level (ACL) from an analyte sensor count value (count) at a time ti:ACL = count / M(ti) Eq. 1 A calibration baseline (baseline) may also be used to determine a measured analyte concentration level (ACL) from an analyte sensor count value (count) at a time ti, and Equation 2 presents one technique:ACL = (count - baseline) / M(ti) Eq. 2 Example of a Therapy Management System

[0058] FIG. 1A illustrates an example of a therapy management system 100 operable to facilitate timely resolution of requested actions, in accordance with certain embodiments of the disclosure. The system 100 may be utilized for generating and presenting information related to patient health, for example, using various user interfaces associated with system 100. Each user of system 100, such as user 102, may interact with a mobile health application, such as mobile health application (“application”) 106 (e.g., a CAM application such as a diabetes intervention application that provides therapy management guidance), and / or a health monitoring device, suchas a CAM system 104 (e.g., a glucose monitoring system). User 102, in certain embodiments, may be the patient or, in some cases, the patient’s caregiver. In the embodiments described herein, the user is assumed to be the patient for simplicity only, but is not so limited. As shown, system 100 may include a CAM system 104, a display device 107 that executes CAM application 106, a therapy management engine 112, and a user database 110.

[0059] CAM system 104 may be configured to generate time-series data, such as analyte measurements (e.g., sensor data), for the user 102, e.g., on a continuous basis, and transmit the analyte measurements to the display device 107 for use by CAM application 106. In some embodiments, the CAM system 104 may transmit the analyte measurements to the display device 107 through a wireless connection (e.g., Bluetooth connection). In certain embodiments, display device 107 is a smart phone. However, in certain embodiments, display device 107 may instead be any other type of computing device such as a laptop computer, a smartwatch, a tablet, or any other computing device capable of executing CAM application 106.

[0060] Note that, while in certain examples the CAM system 104 is assumed to be a glucose monitoring system, CAM system 104 may operate to monitor one or more additional or alternative analytes. As discussed, the term “analyte” as used herein is a broad term, and is to be given its ordinary and customary meaning to a person of ordinary skill in the art (and is not to be limited to a special or customized meaning), and refers without limitation to a substance or chemical constituent in the body or a biological sample (e.g., bodily fluids, including, blood, serum, plasma, interstitial fluid, cerebral spinal fluid, lymph fluid, ocular fluid, saliva, oral fluid, urine, excretions, or exudates).

[0061] Analytes can include naturally occurring substances, artificial substances, metabolites, and / or reaction products. In some embodiments, the analyte measured and used by the devices and methods described herein may include albumin, alkaline phosphatase, alanine transaminase, aspartate aminotransferase, bilirubin, blood urea nitrogen, calcium, CO2, chloride, creatinine, glucose, gamma-glutamyl transpeptidase, hematocrit, lactate, lactate dehydrogenase, magnesium, oxygen, pH, phosphorus, potassium, ketones, sodium, total protein, uric acid, metabolic markers, and / or drugs.

[0062] Other analytes are contemplated as well, including but not limited to acetaminophen, dopamine, ephedrine, terbutaline, ascorbate, uric acid, oxygen, d-amino acid oxidase, plasmaamine oxidase, xanthine oxidase, NADPH oxidase, alcohol oxidase, alcohol dehydrogenase, pyruvate dehydrogenase, diols, Ros, NO, bilirubin, cholesterol, triglycerides, gentisic acid, ibuprophen, L-Dopa, methyl dopa, salicylates, tetracycline, tolazamide, tolbutamide, acarboxyprothrombin; acylcamitine; adenine phosphoribosyl transferase; adenosine deaminase; albumin; alpha-fetoprotein; amino acid profiles (arginine (Krebs cycle), histidine / urocanic acid, homocysteine, phenylalanine / tyrosine, tryptophan); andrenostenedione; antipyrine; arabinitol enantiomers; arginase; benzoylecgonine (cocaine); biotinidase; biopterin; c-reactive protein; carnitine; camosinase; CD4; ceruloplasmin; chenodeoxycholic acid; chloroquine; cholesterol; cholinesterase; conjugated 1-0 hydroxy-cholic acid; cortisol; creatine kinase; creatine kinase MM isoenzyme; cyclosporin A; d-penicillamine; de-ethylchloroquine; dehydroepiandrosterone sulfate; DNA (acetylator polymorphism, alcohol dehydrogenase, alpha 1 -antitrypsin, cystic fibrosis, Duchenne / Becker muscular dystrophy, glucose-6-phosphate dehydrogenase, hemoglobin A, hemoglobin S, hemoglobin C, hemoglobin D, hemoglobin E, hemoglobin F, D-Punjab, betathalassemia, hepatitis B virus, HCMV, HIV-1, HTLV-1, Leber hereditary optic neuropathy, MCAD, RNA, PKU, Plasmodium vivax, sexual differentiation, 21 -deoxy cortisol); desbutylhalofantrine; dihydropteridine reductase; diptheria / tetanus antitoxin; erythrocyte arginase; erythrocyte protoporphyrin; esterase D; fatty acids / acylglycines; free 0-human chorionic gonadotropin; free erythrocyte porphyrin; free thyroxine (FT4); free tri-iodothyronine (FT3); fumarylacetoacetase; galactose / gal-1 -phosphate; galactose- 1 -phosphate uridyltransferase; gentamicin; glucose-6-phosphate dehydrogenase; glutathione; glutathione perioxidase; glycocholic acid; glycosylated hemoglobin; halofantrine; hemoglobin variants; hexosaminidase A; human erythrocyte carbonic anhydrase I; 17-alpha-hydroxyprogesterone; hypoxanthine phosphoribosyl transferase; immunoreactive trypsin; lactate; lead; lipoproteins ((a), B / A-l, 0); lysozyme; mefloquine; netilmicin; phenobarbitone; phenyloin; phytanic / pristanic acid; progesterone; prolactin; prolidase; purine nucleoside phosphorylase; quinine; reverse triiodothyronine (rT3); selenium; serum pancreatic lipase; sissomicin; somatomedin C; specific antibodies (adenovirus, anti-nuclear antibody, anti-zeta antibody, arbovirus, Aujeszky's disease virus, dengue virus, Dracunculus medinensis, Echinococcus granulosus, Entamoeba histolytica, enterovirus, Giardia duodenalisa, Helicobacter pylori, hepatitis B virus, herpes virus, HIV-1, IgE (atopic disease), influenza virus, Leishmania donovani, leptospira, measles / mumps / rubella, Mycobacterium leprae, Mycoplasma pneumoniae, Myoglobin, Onchocerca volvulus,parainfluenza virus, Plasmodium falciparum, poliovirus, Pseudomonas aeruginosa, respiratory syncytial virus, rickettsia (scrub typhus), Schistosoma mansoni, Toxoplasma gondii, Trepenoma pallidium, Trypanosoma cruzi / rangeli, vesicular stomatis virus, Wuchereria bancrofti, yellow fever virus); specific antigens (hepatitis B virus, HIV-1); succinyl acetone; sulfadoxine; theophylline; thyrotropin (TSH); thyroxine (T4); thyroxine-binding globulin; trace elements; transferrin; UDP-galactose-4-epimerase; urea; uroporphyrinogen I synthase; vitamin A; white blood cells; and zinc protoporphyrin. Salts, sugar, protein, fat, vitamins, and hormones naturally occurring in blood or interstitial fluids can also constitute analytes in certain embodiments.

[0063] The analyte can be naturally present in the biological fluid, for example, a metabolic product, a hormone, an antigen, an antibody, and the like. Alternatively, the analyte can be introduced into the body, for example, a contrast agent for imaging, a radioisotope, a chemical agent, a fluorocarbon-based synthetic blood, or a drug or pharmaceutical composition, including but not limited to insulin; ethanol; cannabis (marijuana, tetrahydrocannabinol, hashish); inhalants (nitrous oxide, amyl nitrite, butyl nitrite, chlorohydrocarbons, hydrocarbons); cocaine (crack cocaine); stimulants (amphetamines, methamphetamines, Ritalin, Cylert, Preludin, Didrex, PreState, Voranil, Sandrex, Plegine); depressants (barbituates, methaqualone, tranquilizers such as Valium, Librium, Miltown, Serax, Equanil, Tranxene); hallucinogens (phencyclidine, lysergic acid, mescaline, peyote, psilocybin); narcotics (heroin, codeine, morphine, opium, meperidine, Percocet, Percodan, Tussionex, Fentanyl, Darvon, Talwin, Lomotil); designer drugs (analogs of fentanyl, meperidine, amphetamines, methamphetamines, and phencyclidine, for example, Ecstasy); anabolic steroids; and nicotine. The metabolic products of drugs and pharmaceutical compositions are also contemplated analytes. Analytes such as neurochemicals and other chemicals generated within the body can also be analyzed, such as ascorbic acid, uric acid, dopamine, noradrenaline, 3-methoxytyramine (3MT), 3,4-dihydroxyphenylacetic acid (DOPAC), homovanillic acid (HVA), 5 -hydroxy tryptamine (5HT), histamine, Advanced Glycation End Products (AGEs) and 5-hydroxyindoleacetic acid (FH1AA).

[0064] CAM application 106 may be a mobile health application that is configured to receive and analyze time-series data, including analyte measurements, from the CAM system 104 and / or other devices, as described in greater detail relative to FIGS. IB and 2. In some embodiments, CAM application 106 may transmit analyte measurements received from the CAM system 104 to a user database 110 (and / or the therapy management engine 112), and the user database 110 (and / orthe therapy management engine 112) may store the analyte measurements in a user profile 118 of user 102 for processing and analysis, for example, by the therapy management engine 112. In some embodiments, CAM application 106 may store the analyte measurements in a user profile 118 of user 102 locally for processing and analysis, for example, by the therapy management engine 112.

[0065] In certain embodiments, therapy management engine 112 refers to a set of software instructions with one or more software modules, including a data analysis module (DAM) 111. In some embodiments, therapy management engine 112 executes entirely on one or more computing devices in a private or a public cloud. In some other embodiments, therapy management engine 112 executes partially on one or more local devices, such as display device 107 (e g., via CAM application 106) and / or CAM system 104, and partially on one or more computing devices in a private or a public cloud. In some other embodiments, therapy management engine 112 executes entirely on one or more local devices, such as display device 107 (e.g., via CAM application 106) and / or CAM system 104.

[0066] In certain embodiments, DAM 111 of therapy management engine 112 may be configured to receive and / or process a set of inputs 127 (described in more detail below) (also referred to herein as “input data”) to determine one or more outputs 130 (also referred to herein as “metrics data”). Inputs 127 may be stored in the user profile 118 in the user database 110. DAM 111 can fetch inputs 127 from the user database 110 and compute a plurality of outputs 130 which can then be stored as application data 126 in the user profile 118. Such outputs 130 may include health-related metrics.

[0067] In certain embodiments, CAM application 106 is configured to take as input information relating to user 102 and store the information in a user profile 118 for user 102 in user database 110. For example, CAM application 106 may obtain and record user 102’s demographic info 119, disease progression info 121, and / or medication info 122 in user profile 118. In certain embodiments, demographic info 119 may include one or more of the user’s age, body mass index (BMI), ethnicity, gender, etc. In certain embodiments, disease progression info 121 may include information about the user 102’s disease, such as, for diabetes, whether the user is Type I, Type II, pre-diabetes, or whether the user has gestational diabetes. In certain embodiments, disease progression info 121 also includes the length of time since diagnosis, the level of disease control, level of compliance with disease management therapy, predicted pancreatic function, other typesof diagnosis (e.g., heart disease, obesity) or measures of health (e.g., heart rate, exercise, stress, sleep, etc.), and / or the like. In certain embodiments, medication info 122 may include information about the amount and type of medication taken by user 102, such as insulin or non-insulin diabetes medications and / or non-diabetes medication taken by user 102.

[0068] In certain embodiments, CAM application 106 may obtain demographic info 119, disease progression info 121, and / or medication info 122 from the user 102 in the form of user input or from other sources. In certain embodiments, as some of this information changes, CAM application 106 may receive updates from the user 102 or from other sources. In certain embodiments, user profde 118 associated with the user 102, as well as other user profiles associated with other users are stored in a user database 110, which is accessible to CAM application 106, as well as to the therapy management engine 112, over one or more networks (not shown).

[0069] In certain embodiments, CAM application 106 collects inputs 127 through user 102 input and / or a plurality of other sources, including CAM system 104, other applications running on display device 107, and / or one or more other sensors and devices. In certain embodiments, such sensors and devices include one or more of, but are not limited to, an insulin pump, other types of analyte sensors, sensors or devices provided by display device 107 (e.g., accelerometer, camera, global positioning system (GPS), heart rate monitor, etc.) or other user accessories (e.g., a smartwatch), or any other sensors or devices that provide relevant information about the user 102. In certain embodiments, user profde 118 also stores application configuration information indicating the current configuration of CAM application 106, including its features and settings.

[0070] User database 110, in some embodiments, refers to a storage server that may operate in a public or private cloud. User database 110 may be implemented as any type of data store, such as relational databases, non-relational databases, key-value data stores, file systems including hierarchical file systems, and the like. In some exemplary implementations, user database 110 is distributed. For example, user database 110 may comprise a plurality of persistent storage devices, which are distributed. Furthermore, user database 110 may be replicated so that the storage devices are geographically dispersed.

[0071] User database 110 may include other user profiles 118 associated with a plurality of other users served by system 100. More particularly, similar to the operations performed withrespect to the user 102, the operations performed with respect to these other users may utilize an analyte monitoring system, such as CAM system 104, and also interact with the same CAM application 106, copies of which execute on the respective display devices of the other users 102. For such users, user profiles 118 are similarly created and stored in user database 110.

[0072] FIG. IB is a diagram 150 conceptually illustrating an example CAM system 104 including example continuous analyte sensor(s) with sensor electronics, in accordance with certain aspects of the present disclosure. For example, CAM system 104 may be configured to continuously monitor one or more analytes of a patient, in accordance with certain aspects of the present disclosure.

[0073] CAM system 104 in the illustrated embodiment includes sensor electronics module 138 and one or more continuous analyte sensor(s) 140 (individually referred to herein as continuous analyte sensor 140 and collectively referred to herein as continuous analyte sensors 140) associated with sensor electronics module 138. Sensor electronics module 138 may be in wireless communication (e.g., directly or indirectly) with one or more of display devices 107a, 107b, 107c, and 107d. In certain embodiments, sensor electronics module 138 may also be in wireless communication (e.g., directly or indirectly) with one or more medical devices, such as medical devices 108 (individually referred to herein as medical device 108 and collectively referred to herein as medical devices 108), and / or one or more other non-analyte sensors 142 (individually referred to herein as non-analyte sensor 142 and collectively referred to herein as non-analyte sensor 142).

[0074] In certain embodiments, a continuous analyte sensor 140 may comprise one or more sensors for detecting and / or measuring analyte(s). The continuous analyte sensor 140 may be a multi-analyte sensor configured to continuously measure two or more analytes or a single analyte sensor configured to continuously measure a single analyte as a non-invasive device, a subcutaneous device, a transcutaneous device, a transdermal device, and / or an intravascular device. In certain embodiments, the continuous analyte sensor 140 may be configured to continuously measure analyte levels of a patient using one or more techniques, such as enzymatic techniques, chemical techniques, physical techniques, electrochemical techniques, spectrophotometric techniques, polarimetric techniques, calorimetric techniques, iontophoretic techniques, radiometric techniques, immunochemical techniques, and the like. The term“continuous,” as used herein, can mean fully continuous, semi-continuous, periodic, etc. In certain aspects, the continuous analyte sensor 140 provides a data stream indicative of the concentration of one or more analytes in the patient. The data stream may include raw data signals, which are then converted into a calibrated and / or fdtered data stream used to provide estimated analyte value(s) to the patient.

[0075] In certain embodiments, the continuous analyte sensor 140 may be a multi-analyte sensor, configured to continuously measure multiple analytes in a patient’s body. For example, in certain embodiments, the continuous multi-analyte sensor 140 may be a single sensor configured to measure lactate, glucose, ketones (e.g., 3-beta-hydroxybutyrate, acetoacetate, acetone, etc.), glycerol, and / or free fatty acids in the patient’s body.

[0076] In certain embodiments, one or more multi-analyte sensors may be used in combination with one or more single analyte sensors. As an illustrative example, a multi-analyte sensor may be configured to continuously measure lactate and glucose and may, in some cases, be used in combination with an analyte sensor configured to measure only ketones or only potassium. Information from each of the multi-analyte sensor(s) and single analyte sensor(s) may be combined to provide therapy management support using methods described herein. In further embodiments, other non-contact and or periodic or semi-continuous, but temporally limited, measurements for physiological information may be integrated into the system such as by including weight scale information or non-contact heart rate monitoring from a sensor pad under the patient while in a chair or bed, through an infra-red camera detecting temperature and / or blood flow patterns of the patient, and / or through a visual camera with machine vision for height, weight, or other parameter estimation without physical contact.

[0077] In certain embodiments, the continuous analyte sensor(s) 140 may comprise a percutaneous wire that has a proximal portion coupled to the sensor electronics module 138 and a distal portion with several electrodes, such as a measurement electrode and a reference electrode. The measurement (or working) electrode may be coated, covered, treated, embedded, etc., with one or more chemical molecules that react with a particular analyte, and the reference electrode may provide a reference electrical voltage. The measurement electrode may generate the analog electrical signal, which is conveyed along a conductor that extends from the measurement electrode to the proximal portion of the percutaneous wire that is coupled to the sensor electronicsmodule 138. After the CAM system 104 has been applied to epidermis of the patient, continuous analyte sensor(s) 140 penetrates the epidermis, and the distal portion extends into the dermis and / or subcutaneous tissue under epidermis. Other configurations of continuous analyte sensor(s) 140 may also be used, such as a multi-analyte sensor that includes multiple measurement electrodes, each generating an analog electrical signal that represents the concentration levels of a particular analyte.

[0078] Generally, a single-analyte sensor generates an analog electrical signal that is proportional to the concentration level of a particular analyte. Similarly, each multi-analyte sensor generates multiple analog electrical signals, and each analog electrical signal is proportional to the concentration level of a particular analyte. As an illustrative example, continuous analyte sensor 140 may include a single-analyte sensor configured to measure lactate concentration levels, and another single-analyte sensor configured to measure glucose concentration levels of the patient. As another illustrative example, continuous analyte sensor(s) 140 may include a single-analyte sensor configured to measure glucose concentration levels, and one or more multi-analyte sensors configured to measure lactate concentration levels, ketone concentration levels, creatinine concentration levels, etc. As yet another illustrative example, continuous analyte sensor(s) 140 may include a multi-analyte sensor configured to measure lactate concentration levels, glucose concentration levels, ketone concentration levels, creatinine concentration levels, etc. Accordingly, continuous analyte sensor(s) 140 is configured to generate at least one analog electrical signal that is proportional to the concentration level of a particular analyte, and sensor electronics module 138 is configured to convert the analog electrical signal into an analyte sensor count values, calibrate the analyte sensor count values based on the sensitivity profile of the continuous analyte sensor(s) 140 to generate measured analyte concentration levels, and transmit the measured analyte concentration level data, including the measured analyte concentration levels, to a display device, such as display devices 107b, 107c, and / or 107d, via a wireless connection. For example, sensor electronics module 138 may be configured to sample the analog electrical signal at a particular sampling period (or rate), such as every 1 second (1 Hz), 5 seconds, 10 seconds, 30 seconds, 1 minute, 3 minutes, 5 minutes, etc., and to transmit the measured analyte concentration data to the display device at a particular transmission period (or rate), which may be the same as (or longer than) the sampling period, such as every 1 minute (0.016 Hz), 5 minutes, 10 minutes, 30 minutes, at the conclusion of the wear period, etc. Depending on the sampling andtransmission periods, the measured analyte concentration data transmitted to the display device include at least one measured analyte concentration level having an associated time tag, sequence number, etc.

[0079] In certain embodiments, continuous analyte sensor(s) 140 may incorporate a thermocouple within, or alongside, the percutaneous wire to provide an analog temperature signal to the sensor electronics module 138, which may be used to correct the analog electrical signal or the measured analyte data for temperature. In other embodiments, the thermocouple may be incorporated into the sensor electronics module 138 above the adhesive pad, or, alternatively, the thermocouple may contact the epidermis of the patient through openings in the adhesive pad.

[0080] In certain embodiments, the sensor electronics module 138 includes, inter alia, processor 133, storage element or memory 134, wireless transmitter / receiver (transceiver) 136, one or more antennas coupled to wireless transceiver 136, analog electrical signal processing circuitry, analog to-digital (A / D) signal processing circuitry, digital signal processing circuitry, a power source for continuous analyte sensor(s) 140 (such as a potentiostat), etc.

[0081] Processor 133 may be a general-purpose or application-specific microprocessor, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc., that executes instructions to perform control, computation, input / output, etc. functions for the sensor electronics module 138. Processor 133 may include a single integrated circuit, such as a micro processing device, or multiple integrated circuit devices and / or circuit boards working in cooperation to accomplish the appropriate functionality. In certain embodiments, processor 133, memory 134, wireless transceiver 136, the A / D signal processing circuitry, and the digital signal processing circuitry may be combined into a system-on-chip (SoC).

[0082] Generally, processor 133 may be configured to sample the analog electrical signal using the A / D signal processing circuitry at regular intervals (such as the sampling instant or period) to generate analyte sensor count values based on the analog electrical signals produced by the continuous analyte sensor(s) 140, calibrate the analyte sensor count values based on the sensitivity profile of the continuous analyte sensor(s) 140 to generate measured analyte concentration levels, and generate measured analyte data from the measured analyte concentration levels, generate sensor data packages that include, inter alia, the measured analyte concentration level data. Processor 133 may store the measured analyte concentration level data in memory 134, andgenerate the sensor data packages at regular intervals (such as the transmission period) for transmission by wireless transceiver 136 to a display device, such as display devices 107b, 107c, 107d, and / or 107a. Processor 133 may also add additional data to the sensor data packages, such as supplemental sensor information that includes a sensor identifier, a sensor status, temperatures that correspond to the measured analyte data, etc. The sensor data packages are then wirelessly transmitted over a wireless connection to the display device. In certain embodiments, the wireless connection is a Bluetooth or Bluetooth Low Energy (BLE) connection. In such embodiments, the sensor data packages are transmitted in the form of Bluetooth or BLE data packets to the display device

[0083] In various embodiments, memory 134 may include volatile and nonvolatile medium. For example, memory 134 may include combinations of random access memory (RAM), dynamic RAM (DRAM), static RAM (SRAM), read only memory (ROM), flash memory, cache memory, and / or any other type of non-transitoiy computer-readable medium. Memory 134 may store one or more analyte sensor system applications, modules, instruction sets, etc. for execution by processor 133, such as instructions to generate measured analyte data from the analyte sensor count values, etc.

[0084] Memory 134 may also store certain sensor operating parameters 135, such as a calibration slope (or calibration sensitivity), a calibration baseline, etc. In particular, the calibration sensitivity, calibration baseline, and other information related to the sensitivity profde for the sensor electronics module 138 may be programmed into the sensor electronics module 138 during the manufacturing process, and then used to convert the analyte sensor electrical signals into measured analyte concentration levels. For example, as discussed above, the calibration slope may be used to predict an initial in vivo sensitivity (Mo) and a final in vivo sensitivity (Mr), which are stored in memory 134 and used to convert the analyte sensor electrical signals into measured analyte concentration levels. In certain embodiments, calibration sensitivity (Mcc) 146 and / or calibration baseline 147 may be stored in memory 134.

[0085] In certain embodiments, sensor electronics module 138 includes electronic circuitry associated with measuring and processing the continuous analyte sensor data, including prospective algorithms associated with processing and calibration of the sensor data. Sensor electronics module 138 can be physically connected to continuous analyte sensor(s) 140 and canbe integral with (non-releasably attached to) or releasably attachable to continuous analyte sensor(s) 140. Sensor electronics module 138 may include hardware, firmware, and / or software that enable measurement of levels of analyte(s) via continuous analyte sensor(s) 140. For example, sensor electronics module 138 can include a potentiostat, a power source for providing power to the sensor, other components useful for signal processing and data storage, and a telemetry module for transmitting data from the sensor electronics module to, e.g., one or more display devices. Electronics can be affixed to a printed circuit board (PCB), or the like, and can take a variety of forms. For example, the electronics can take the form of an integrated circuit (IC), such as an Application-Specific Integrated Circuit (ASIC), a microcontroller, and / or a processor.

[0086] Display devices 107b, 107c, 107d, and / or 107a are configured for displaying displayable sensor data, including analyte data, which may be transmitted by sensor electronics module 138. Each of display devices 107b, 107c, 107d, or 107a may include a display such as a touchscreen display 109b, 109c, 109d, and / or 109a for displaying sensor data to a patient or other user and / or for receiving inputs from the patient. For example, a graphical user interface (GUI) may be presented to the patient for such purposes. In certain embodiments, the display devices may include other types of user interfaces such as a voice user interface instead of, or in addition to, a touchscreen display for communicating sensor data to the patient of the display device and / or for receiving patient inputs. Display devices 107a, 107b, 107c, and 107d may be examples of display device 107 illustrated in FIG. 1 used to display sensor data to a patient of the system of FIG. 1 and / or to receive input from the patient.

[0087] In certain embodiments, one, some, or all of the display devices are configured to display or otherwise communicate (e.g., verbalize) the sensor data as it is communicated from the sensor electronics module (e.g., in a customized data package that is transmitted to display devices based on their respective preferences), without any additional prospective processing required for calibration and real-time display of the sensor data.

[0088] The plurality of display devices may include a custom display device specially designed for displaying certain types of displayable sensor data associated with analyte data received from sensor electronics module. In certain embodiments, the plurality of display devices may be configured for providing alerts / alarms based on the displayable sensor data. Display device 107b is an example of such a custom device. In certain embodiments, one of the plurality of displaydevices is a smartphone, such as display device 107c which represents a mobile phone, using a commercially available operating system (OS), and configured to display a graphical representation of the continuous sensor data (e.g., including current and historic data). Other display devices can include other hand-held devices, such as display device 107d which represents a tablet, display device 107a which represents a smart watch or fitness tracker, medical device 108 (e.g., an insulin delivery device or a blood glucose meter), and / or a desktop or laptop computer (not shown).

[0089] Because different display devices provide different user interfaces, content of the data packages (e.g., amount, format, and / or type of data to be displayed, alarms, and the like) can be customized (e.g., programmed differently by the manufacture and / or by an end user, such as the patient) for each particular display device. Accordingly, in certain embodiments, a plurality of different display devices can be in direct wireless communication with a sensor electronics module (e.g., such as an on-skin sensor electronics module 138 that is physically connected to continuous analyte sensor(s) 140) during a sensor session to enable a plurality of different types and / or levels of display and / or functionality associated with the displayable sensor data.

[0090] As mentioned, sensor electronics module 138 may be in communication with a medical device 108. Medical device 108 may be a passive device in some example embodiments of the disclosure. For example, medical device 108 may be an insulin pump for administering insulin to a patient. For a variety of reasons, it may be desirable for such an insulin pump to receive and track lactate, glucose, ketones, glycerol and free fatty acid values transmitted from CAM systems 104, where continuous analyte sensor 140 is configured to measure lactate, glucose, ketones, glycerol, and / or free fatty acids.

[0091] Further, as mentioned, sensor electronics module 138 may also be in communication with other non-analyte sensors 142. Non-analyte sensors 142 may include, but are not limited to, an altimeter sensor, an accelerometer sensor, a global positioning system (GPS) sensor, a temperature sensor, a respiration rate sensor, etc. Non-analyte sensors 142 may also include monitors such as heart rate monitors, blood pressure monitors, pulse oximeters, caloric intake monitors, indirect calorimetry devices, continuous positive airway pressure machines, and medicament delivery devices. One or more of these non-analyte sensors 142 may provide data totherapy management engine 112 described further below. Tn some aspects, a patient may manually provide some of the data for processing by the therapy management engine 112 of FIG. 1.

[0092] In certain embodiments, non-analyte sensors 142 may further include sensors for measuring skin temperature, core temperature, sweat rate, and / or sweat composition.

[0093] In certain embodiments, the non-analyte sensors 142 may be combined in any other configuration, such as, for example, combined with one or more continuous analyte sensors 140. As an illustrative example, a non-analyte sensor, e.g., a temperature sensor, may be combined with a continuous glucose sensor 140 to form a glucose / temperature sensor used to transmit sensor data to the sensor electronics module 138 using common communication circuitry. As another illustrative example, a non-analyte sensor, e.g., a temperature sensor, may be combined with a multi-analyte sensor 140 configured to measure lactate and glucose to form a lactate / glucose / temperature sensor used to transmit sensor data to the sensor electronics module 138 using common communication circuitry.

[0094] In certain embodiments, a wireless access point (WAP) may be used to couple one or more of CAM system 104, the plurality of display devices, medical device(s) 108, and / or non-analyte sensor(s) 142 to one another. For example, such WAP may provide Wi-Fi and / or cellular connectivity among these devices. Near Field Communication (NFC) and or Bluetooth may also be used among devices depicted in diagram 150 of FIG. IB.

[0095] FIG. 2 illustrates example inputs and example metrics that are generated based on the inputs in accordance with certain embodiments of the disclosure. In particular, FIG. 2 illustrates example inputs 127 on the left, CAM application 106 and therapy management engine 112, with DAM 111, in the middle, and example outputs 130 on the right. In certain embodiments, CAM application 106 may obtain inputs 127, in the form of time-series data, through one or more channels (e.g., continuous analyte sensor(s) 140, non-analyte sensor(s) 142, various applications executing on display device 107, etc.). Inputs 127 may be further processed by DAM 111 to output a plurality of metrics, such as outputs 130. Further, inputs (e.g., inputs 127) and metrics (e.g., outputs 130) may be used by the DAM 111 and / or any computing device in the system 100 to perform various processes. Any of inputs 127 may be used for computing any of outputs 130. In certain embodiments, each one of outputs 130 may correspond to one or more values, e.g., discrete numerical values, ranges, or qualitative values (high / medium / low or stable / unstable). In someembodiments, some or all of outputs 130 may include time-series data and / or be provided in the form of time-series data.

[0096] In certain embodiments, inputs 127 include food consumption information. Food consumption information may include information about one or more of meals, snacks, and / or beverages, such as one or more of the size, content (carbohydrate, fat, protein, etc.), sequence of consumption, and time of consumption. In certain embodiments, food consumption may be provided by the user through manual entry, by providing a photograph through an application that is configured to recognize food types and quantities, and / or by scanning a bar code or menu. In various examples, meal size may be manually entered as one or more of calories, quantity (e.g., 'three cookies'), menu items (e.g., 'Royale with Cheese'), and / or food exchanges (1 fruit, 1 dairy). In some examples, meals may also be entered with the user's typical items or combinations for this time or setting (e.g., workday breakfast at home, weekend brunch at restaurant). In some examples, meal information may be received via a convenient user interface provided by CAM application 106.

[0097] In certain embodiments, inputs 127 include activity information. Activity information may be provided, for example, the one or more non-analyte sensors 142 of FIG. IB. In certain embodiments, activity information may additionally be provided through manual input by user 102. Activity information may include, for example, a time series for each of heart rate, activity minutes, step count, floors climbed, location information (e.g., GPS data), calories burned, sleep duration and / or quality, activity level (e.g., light, medium, or heavy), and / or similar information. In addition, or alternatively, the activity information can include one or more time series for recorded activities of one or more defined activity types (e.g., walk, run, sprint, swim, weightlift etc.), where each activity is associated with a duration and / or time period.

[0098] In certain embodiments, inputs 127 include patient statistics, such as one or more of age, height, weight, body mass index, body composition (e.g., % body fat), stature, build, or other information. Patient statistics may be provided through a user interface, by interfacing with an electronic source such as an electronic medical record, and / or from measurement devices. The measurement devices may include one or more of a wireless, e.g., Bluetooth-enabled, weight scale and / or camera, which may, for example, communicate with the display device 107 to provide patient data.

[0099] In certain embodiments, inputs 127 include information relating to the user’s medication intake. For example, the user’s medication intake may include the user’s insulin delivery. Such information may be received, via a wireless connection on a smart pen, via user input, and / or from an insulin pump (e.g., medical device 108). Insulin delivery information may include one or more of insulin volume, time of delivery, etc. Other configurations, such as insulin action time or duration of insulin action, may also be received as inputs.

[0100] In certain embodiments, inputs 127 include physiological information received from non-analyte sensor(s) 142 , which may detect one or more of heart rate, respiration, oxygen saturation, body temperature, etc. (e.g., to detect illness, stress levels, etc.). In certain embodiments, inputs 127 include time, such as time of day, or time from a real-time clock.

[0101] In certain embodiments, inputs 127 include analyte data, which may be provided as input from CAM system 104, for example, in any of the ways described with respect to FIG. 1A. An example of analyte data is glucose data, which may be provided and / or stored as a time series corresponding to time-stamped glucose measurements over time. Other types of analyte data, such as ketone data, potassium data, lactate data, etc., may similarly be provided and / or stored as a time series.

[0102] As described above, in certain embodiments, DAM 111 generates, determines, and / or computes outputs 130 based on inputs 127 associated with user 102. An example list of outputs 130 is illustrated in FIG. 2. In certain embodiments, outputs 130 generated, determined, or computed by DAM 111 include metabolic rate. Metabolic rate is a metric that may indicate or include a basal metabolic rate (e.g., energy consumed at rest) and / or an active metabolism, e.g., energy consumed by activity, such as exercise or exertion. In some examples, basal metabolic rate and active metabolism may be tracked as separate metric. In certain embodiments, the metabolic rate may be calculated by DAM 111 based on one or more of inputs 127, such as one or more of activity information, sensor input, time, user input, etc.

[0103] In certain embodiments, outputs 130 generated, determined, or computed by DAM 111 include an activity level metric. The activity level metric may indicate a level of activity of the user. In certain embodiments, the activity level metric may be determined, for example based on input from an activity sensor or other physiologic sensors. In certain embodiments, the activity level metric may be calculated by DAM 111 based on one or more of inputs 127, such as one ormore of activity information, physiological information, analyte data, time, user input, etc. Activity level may indicate whether the user is exercising, at rest, sleeping, etc.

[0104] In certain embodiments, outputs 130 generated, determined, or computed by DAM 111 include an insulin resistance metric (also referred to herein as an “insulin resistance”). The insulin resistance metric may be determined using historical data, real-time data, or a combination thereof, and may, for example, be based upon one or more inputs 127, such as one or more of food consumption information, blood glucose information, insulin delivery information, the resulting glucose levels, etc. In certain embodiments, the insulin on board metric may be determined using insulin delivery information, and / or known or learned (e.g., from patient data) insulin time action profiles, which may account for both basal metabolic rate (e g., update of insulin to maintain operation of the body) and insulin usage driven by activity or food consumption.

[0105] In certain embodiments, outputs 130 generated, determined, or computed by DAM 111 include a meal state metric. The meal state metric may indicate the state the user is in with respect to food consumption. For example, the meal state may indicate whether the user is in one of a fasting state, pre-meal state, eating state, post-meal response state, or stable state. In certain embodiments, the meal state may also indicate nourishment on board, e.g., meals, snacks, or beverages consumed, and may be determined, for example from food consumption information, time of meal information, and / or digestive rate information, which may be correlated to food type, quantity, and / or sequence (e.g., which food / beverage was eaten first.).

[0106] In certain embodiments, outputs 130 generated, determined, or computed by DAM 111 include health and sickness metrics. Health and sickness metrics may be determined, for example, based on one or more of user input (e.g., pregnancy information or known sickness information), from non-analyte sensor(s) 142, such as physiologic sensors (e.g., temperature), activity sensors, or a combination thereof. In certain embodiments, based on the values of the health and sickness metrics, for example, the user’s state may be defined as being one or more of healthy, ill, rested, or exhausted. In certain embodiments, health and sickness metric may indicate the user’s heart rate, stress level, etc.

[0107] In certain embodiments, outputs 130 generated, determined, or computed by DAM 111 include analyte level metrics. Analyte level metrics may be determined from analyte data (e.g., glucose measurements obtained from CAM system 104). In some examples, an analyte levelmetric may also be determined, for example, based upon historical information about analyte levels in particular situations, e.g., given a combination of food consumption, insulin, and / or activity. An analyte level metric may include a rate of change of the analyte, time in range, time spent below a threshold level, time spent above a threshold level, or the like. In certain embodiments, an analyte trend may be determined based on the analyte level over a certain period of time. As described above, example analytes may include glucose, ketones, lactate, potassium and others described herein.

[0108] In certain embodiments, outputs 130 generated, determined, or computed by DAM 111 include a disease stage. For example disease stages for Type II diabetics may include a pre-diabetic stage, an oral treatment stage, and a basal insulin treatment stage. In certain embodiments, degree of glycemic control (not shown) may also be determined as an outcome metric, and may be based, for example, on one or more of glucose levels, variation in glucose level, or insulin dosing patterns.

[0109] In certain embodiments, outputs 130 generated, determined, or computed by DAM 111 include clinical metrics. Clinical metrics generally indicate a clinical state a user is in with respect to one or more conditions of the user, such as diabetes. For example, in the case of diabetes, clinical metrics may be determined based on glycemic measurements, including one or more of A1C, trends in A1C, time in range, time spent below a threshold level, time spent above a threshold level, and / or other metrics derived from glucose values. In certain embodiments, clinical metrics may also include one or more of estimated Al C, glycemic variability, hypoglycemia, and / or health indicator (time magnitude out of target zone).Example Operations for Facilitating Timely Resolution of Requested Actions

[0110] FIG. 3A illustrates an example of a process 300 for creating and using a centralized location for requested actions within a CAM application, such as the CAM application 106 of FIGS. 1 A-B, in accordance with certain embodiments. In some embodiments, the process 300 can be executed, for example, by the therapy management engine 112 of FIGS. 1A-B and 2. In addition, or alternatively, the process 300 can be executed, for example, by the CAM application 106 of FIGS. 1A-B and 2. In addition, or alternatively, the process 300 can be executed generally by any of the display devices 107 of FIGS. 1 A-B and 2. Although any number of systems, in whole or in part, can implement the process 300, to simplify discussion, the process 300 will be describedprimarily in relation to the therapy management engine 112 and CAM application 106 of FIGS.1A-B and 2.[oni] At block 302, the therapy management engine 112 generates one or more requested actions to be displayed within the CAM application 106. In some aspects, the one or more requested actions can be automatically compiled, for example, from disparate types of features provided by of the CAM application 106. For example, the one or more requested actions can include, for example, a request for acknowledgement of data and / or an event (e.g., a request for user acknowledgement of an analyte value or of an alert triggered based on an analysis of analyte data, etc.), an indication of an incomplete task within the CAM application 106, and / or a request for physical action by the patient (e g., a therapeutic action such as eating or taking medication). In other examples, the requested actions can include entering contextual data, taking medication, providing or taking a photograph (e.g., of a meal), physical activity logging (e.g., exercise), meal logging, an instruction to enter a meal in response to a glucose spike detection, behavioral change suggestions (e.g., a suggestion to take a walk following a meal), entry of fasting glucose, goal tracking / progress (e.g., an instruction towards achieving a goal), survey, education (e.g., education that requires user input), combinations of the foregoing and / or the like.

[0112] At block 310, the therapy management engine 112 presents, within the CAM application 106, the one or more requested actions within a centralized location of the CAM application 106. The one or more requested actions can be presented, for example, as a requested actions list. The centralized location can be, for example, a designated user interface container within a user interface. In some aspects, the user interface can be organized into containers of related data, such as cards, one of which is the centralized location for requested actions. Examples of the centralized location will be described relative to FIGS. 3B-D. After block 310, the process 300 ends.

[0113] In certain aspects, the process 300 can address various technical challenges in the art such as, for example, that requested actions are presented to users only via individual notifications for each requested action (e.g. push notifications and / or an in-app notifications). In certain aspects, the process 300 addresses the technical challenges, for example, by creating a centralized location within the CAM application 106 where all requested actions (e.g., a requested actions list) are compiled for review and completion.

[0114] FIG. 3B illustrates an example of a user interface 325 for presenting requested actions, in accordance with certain embodiments. The user interface 325 includes a configurable selection of user interface containers, shown as cards, that each present collections of related data. As shown, the user interface 325 includes a card 326 that presents a requested actions list. In the example of FIG. 3B, the requested actions list includes requested actions of logging a fasting glucose and taking medication. The requested actions shown in the card 326 can be generated, for example, as discussed relative to block 302 of FIG. 3A. In certain aspects, the user interface 325 and / or the card 326 can be presented, for example, as part of block 310 of FIG. 3A.

[0115] FIG. 3C illustrates an example of a card 328 for presenting requested actions, in accordance with certain embodiments. In certain aspects, the card 328 can be included in a user interface similar to the user interface 325 of FIG. 3B. As shown, the card 328 presents a requested actions list that includes requested actions of education and taking a medication. The requested actions shown in the card 328 can be generated, for example, as discussed relative to block 302 of FIG. 3 A. In certain aspects, the card 328 can be presented, for example, as part of block 310 of FIG. 3A.

[0116] FIG. 3D illustrates an exemplary flow interface 350 for requested actions, in accordance with certain embodiments. The flow interface 350 can be implemented utilizing a CAM application, such as the CAM application 106 of FIGS. 1A-B. In some embodiments, the flow interface 350 can be implemented, for example, by the therapy management engine 112 of FIGS. 1A-B and 2. In addition, or alternatively, the flow interface 350 can be implemented, for example, by the CAM application 106 of FIGS. 1A-B and 2. In addition, or alternatively, the flow interface 350 can be implemented generally by any of the display devices 107 of FIGS. 1A-B and 2. Although any number of systems, in whole or in part, can implement the flow interface 350, to simplify discussion, the flow interface 350 will be described primarily in relation to the therapy management engine 112 and CAM application 106 of FIGS. 1A-B and 2.

[0117] As shown, the exemplary flow interface 350 includes a requested actions list 330 that includes currently outstanding actions 332 and 334. A level of completion is included for a first outstanding action 332, and an overview of medication dosing is included for a second outstanding action 334.

[0118] FIG. 4A illustrates an example of a process 400 for organizing requested actions within a CAM application, such as the CAM application 106 of FIGS. 1A-B, in accordance with certain embodiments. In some embodiments, the process 400 can be executed, for example, by the therapy management engine 112 of FIGS. 1A-B and 2. In addition, or alternatively, the process 400 can be executed, for example, by the CAM application 106 of FIGS. 1A-B and 2. In addition, or alternatively, the process 400 can be executed generally by any of the display devices 107 of FIGS.1 A-B and 2. Although any number of systems, in whole or in part, can implement the process 400, to simplify discussion, the process 400 will be described primarily in relation to the therapy management engine 112 and CAM application 106 of FIGS. 1 A-B and 2.

[0119] At block 402, the therapy management engine 112 generates one or more requested actions to be displayed within the CAM application 106. In some aspects, the one or more requested actions can be generated, for example, as discussed relative to block 302 of FIG. 3A.

[0120] At block 406, the therapy management engine 112 organizes the one or more requested actions, for example, into a requested actions list, according to one or more predetermined criteria. The one or more predetermined criteria can include various parameters such as time associated with the one or more actions (e.g., AM or PM), resolution status (e.g., complete or incomplete), action type (e.g., meals, medication, etc.), priority, severity, and / or the like. In some aspects, the one or more criteria can be supplied by the patient or other user. In addition, or alternatively, the predetermined criteria can be part of the configuration of the therapy management engine 112 and / or the CAM application 106. The requested actions list can be represented via any suitable abstract data type or other structure for indicating the organization.

[0121] In some aspects, the organizing at block 406 can include arranging the one or more requested actions by the predetermined criteria (e.g., sorting requested actions by a parameter such as time, separating requested actions by action type, etc.). For example, the therapy management engine 112 can use the predetermined criteria to condense or collapse multiple similar or related requested actions items into a single element within a requested actions list. As particular examples, multiple requested actions for meals could be condensed or collapsed into a single element for meals, and multiple requested actions for taking medication could be condensed or collapsed into a single element for taking medication.

[0122] In some aspects, block 406 can include the therapy management engine 112 automatically detecting correspondences (e.g., relatedness or similarity) between various of the one or more requested actions and automatically condensing, collapsing, or otherwise grouping together (e.g., linking) each set of corresponding requested actions. For example, the therapy management engine 112 can automatically detect correspondence and group together multiple requested actions for meals, multiple requested actions for different medications that are taken at the same time or within the same window of time (e.g., AM or PM medications), etc.

[0123] In some aspects, the organizing at block 406 can include filtering the one or more requested actions by the predetermined criteria (e.g., by action type, time, resolution status, etc.). For example, the requested actions could be filtered down to requested actions for medication, requested actions for AM medications, requested actions for PM medications, incomplete requested actions, completed requested actions, and / or the like.

[0124] At block 410, the therapy management engine 112 presents, within the CAM application 106, the organized one or more requested actions within a centralized location of the CAM application 106. For example, the therapy management engine 112 can present, within the CAM application 106, the requested actions list resulting from the organization at block 406. In general, the organized one or more requested actions can be presented, for example, as discussed relative to block 310 of FIG. 3A. In some aspects, as part of the presentation at block 410, the therapy management engine 112 enables single elements representative of multiple requested actions to be manipulated, reordered, and / or dismissed via stacking, swiping, or other user interface interaction. In this way, any manipulation, reordering or dismissal of the single element can be aggregately applied to each requested action that is condensed or collapsed into that element. After block 410, the process 400 ends.

[0125] In certain aspects, the process 400 can address various technical challenges in the art such as, for example, that requested actions are presented to users only via individual notifications for each requested action (e.g. push notifications and / or an in-app notifications). In certain aspects, the process 400 addresses these technical challenges, for example, by organizing requested actions according to predetermined criteria, as discussed above, thereby simplifying review and completion. Further, in certain aspects, the process 400 can alleviate a user burden associated withcontextual data entry, for example, by enabling multiple requested actions to be reviewed and manipulated together and in an organized manner.

[0126] FIG. 4B illustrates an exemplary flow interface 425 allowing for action status filtering, in accordance with certain embodiments. The flow interface 425 can be implemented utilizing a CAM application, such as the CAM application 106 of FIGS. 1A-B. In some embodiments, the flow interface 425 can be implemented, for example, by the therapy management engine 112 of FIGS. 1A-B and 2. In addition, or alternatively, the flow interface 425 can be implemented, for example, by the CAM application 106 of FIGS. 1A-B and 2. In addition, or alternatively, the flow interface 425 can be implemented generally by any of the display devices 107 of FIGS. 1A-B and 2. Although any number of systems, in whole or in part, can implement the flow interface 425, to simplify discussion, the flow interface 425 will be described primarily in relation to the therapy management engine 112 and CAM application 106 of FIGS. 1A-B and 2.

[0127] As shown, the exemplary flow interface 425 initially includes a requested actions list 426 that includes currently outstanding (incomplete) actions 428 and 430. Upon selection of a link 432, the exemplary flow interface 425 is updated to include a completed actions list 434 that includes completed actions 436 and 438. Upon selection of a link 440, the exemplary flow interface 425 is updated to include the requested actions list 426 that includes currently outstanding (incomplete) actions 428 and 430.

[0128] FIG. 4C illustrates an exemplary flow 450 allowing for requested action grouping and contextual data entry facilitation, in accordance with certain embodiments. The flow 450 can be implemented utilizing a CAM application, such as the CAM application 106 of FIGS. 1A-B. In some embodiments, the flow 450 can be implemented, for example, by the therapy management engine 112 of FIGS. 1A-B and 2. In addition, or alternatively, the flow 450 can be implemented, for example, by the CAM application 106 of FIGS. 1A-B and 2. In addition, or alternatively, the flow 450 can be implemented generally by any of the display devices 107 of FIGS. 1A-B and 2. Although any number of systems, in whole or in part, can implement the flow 450, to simplify discussion, the flow 450 will be described primarily in relation to the therapy management engine 112 and CAM application 106 of FIGS. 1A-B and 2.

[0129] As shown, the exemplary flow 450 initially includes a requested actions list 452 that groups current requested actions 454 and 456 by time of medication. Upon selection of the firstaction 454, the exemplary flow 450 is updated to present data logging fields 458, where some of the fields 458 are prepopulated with relevant historically extracted or submitted information. After such data has been logged and submitted via selection of a save option 460, subsequent selection of the first action 454 results in display of historically logged data 462.

[0130] FIG. 5A illustrates an example of a process 500 for assisting resolution of requested actions within a CAM application, such as the CAM application 106 of FIGS. 1A-B, in accordance with certain embodiments. In some embodiments, the process 500 can be executed, for example, by the therapy management engine 112 of FIGS. 1A-B and 2. In addition, or alternatively, the process 500 can be executed, for example, by the CAM application 106 of FIGS. 1A-B and 2. In addition, or alternatively, the process 500 can be executed generally by any of the display devices 107 of FIGS. 1A-B and 2. Although any number of systems, in whole or in part, can implement the process 500, to simplify discussion, the process 500 will be described primarily in relation to the therapy management engine 112 and the CAM application 106 of FIGS. 1A-B and 2.

[0131] At block 502, the therapy management engine 112 generates one or more requested actions to be displayed within the CAM application 106. In general, the one or more requested actions can be generated, for example, as discussed relative to block 302 of FIG. 3A.

[0132] At block 510, the therapy management engine 112 presents, within the CAM application 106, the one or more requested actions within a centralized location of the CAM application 106. In general, the one or more requested actions can be presented, for example, as discussed relative to block 310 of FIG. 3A. In some aspects, block 510 can include presenting organized requested actions, as discussed relative to block 410 of FIG. 4A.

[0133] At block 512, the therapy management engine 112 identifies a user selection of one or more of the requested action(s) within the centralized location. For example, with reference to FIGS. 3B and 3C, a user can select one or more of the requested actions shown in the card 326 or the card 328, respectively. In an example, the user can select a requested action for taking medication. In another example, the user can select a requested action for data logging, such as a requested action for logging a fasting glucose. In another example, the user can select a requested action for education.

[0134] At block 514, the therapy management engine 112 automatically generates and presents, in the CAM application 106, a software instance to address the user-selected requestedaction(s). The software instance can include, for example, one or more user interfaces that guide the user through resolution of one or more of the user-selected requested action(s). In an example, for a requested action of taking medication, the generated and presented software instance can include one or more user interfaces for enabling the user to log or enter the taking of the medication. In another example, for a requested action of logging a fasting glucose, the generated and presented software instance can include one or more user interfaces for enabling the user to log the fasting glucose. Further examples of the software instance will be described relative to FIGS. 5B and 5C.

[0135] In some aspects, the generation and presentation of the software instance can be driven by artificial intelligence (e.g., machine learning), for example, based on an analysis of historical requested actions for the user or a population of users and subsequent actions taken by the user, for example, to resolve the historical requested actions. For example, every morning at 8 am, a requested action may be generated to correct a hyperglycemic condition, and at 8:15 am, the user may go on a one-hour run that corrects the hyperglycemic condition. According to this example, the therapy management engine 112 can learn an association between the daily hyperglycemic condition and the daily run such that, when the user selects a requested action to correct the hyperglycemic condition, the therapy management engine 112 generates and presents a software instance for entering an activity.

[0136] In addition, or alternatively, the generation and presentation of the software instances can be manually driven, for example, by automatically and generating software instances corresponding to the user selection (e.g., generating an instance for meal entry in response to userselection of a requested action for meal entry). In addition, or alternatively, the generation and presentation of the software instance can be driven by reminders or pre-existing goals (e.g., providing software instances for entering activities or meals that further a defined user goal, such as physical fitness, analyte management, etc.).

[0137] At block 518, the therapy management engine 112 receives user input via the generated software instance. For example, the therapy management engine 112 can receive user input indicating details for medication taken, fasting glucose, and / or the like. In another example, the therapy management engine 112 can receive user input indicating acknowledgement of, orprogress towards completion of, educational content that is presented (e.g., education videos, wizards, text, etc.).

[0138] At block 520, the therapy management engine 112 resolves the user-selected requested action(s) utilizing the received user input. For example, the therapy management engine 112 can indicate, in storage and / or in a user interface, that the user-selected requested action(s) are complete using a timestamp associated with the user input. In addition, or alternatively, a corresponding log or storage can be updated to include all or part of the received user input. After block 520, the process 500 ends.

[0139] In certain aspects, the process 500 can address various technical challenges in the art such as, for example, that entry of contextual data is burdensome for users. The process 500 can assist resolution of requested actions for contextual data entry, for example, by automatically generating and presenting one or more structures (e.g., software instances) that facilitate resolution of such requested actions.

[0140] FIG. 5B illustrates an example user interface sequence 525 for addressing requested actions, in accordance with certain embodiments. The user interface sequence 525 can be presented, for example, in the CAM application 106, as discussed above. The user interface sequence 525 begins with a first main user interface 526A being presented, for example, in the CAM application 106.

[0141] In the example of FIG. 5B, a user selects, from the first main user interface 526A, a requested action for logging a fasting glucose. In response, the therapy management engine 112 can generate and present, in the CAM application 106, a software instance that includes a user interface 528. The user interface 528 facilitates user entry of the fasting glucose, thereby completing that requested action. Thereafter, the therapy management engine 112 can present a second main user interface 526B, which view indicates that the requested action for logging a fasting glucose is resolved.

[0142] Thereafter, in the example of FIG. 5B, the user selects, from the second main user interface 526B, a requested action for taking medication. In response, the therapy management engine 112 can generate and present, in the CAM application 106, a software instance that includes a user interface 530. The user interface 530 facilitates user entry of a taking of the medication, thereby completing that requested action. Thereafter, the therapy management engine 112 canpresent a third main user interface 526C, which view indicates that the requested action for taking medication is resolved.

[0143] Thereafter, in the example of FIG. 5B, the user selects, from the third main user interface 526C, a requested action for taking a mid-day medication. In response, the therapy management engine 112 can generate and present, in the CAM application 106, a software instance that includes a user interface 532. The user interface 532 facilitates user entry of a taking of the mid-day medication, thereby completing that requested action. Thereafter, the therapy management engine 112 can present a fourth main user interface 526D, which view indicates that the requested action for taking the mid-day medication is resolved.

[0144] Thereafter, in the example of FIG. 5B, the user selects, from the fourth main user interface 526D, a requested action for taking an evening medication. In response, the therapy management engine 112 can generate and present, in the CAM application 106, a software instance that includes a user interface 534. The user interface 534 facilitates user entry of a taking of the evening medication, thereby completing that requested action. Thereafter, the therapy management engine 112 can present a fifth main user interface 526E, which view indicates that the requested action for taking the evening medication is resolved.

[0145] FIG. 5C illustrates another example user interface sequence 550 for addressing requested actions, in accordance with certain embodiments. The user interface sequence 550 can be presented, for example, in the CAM application 106, as discussed above. The user interface sequence 550 begins with a first main user interface 552A being presented, for example, in the CAM application 106.

[0146] In the example of FIG. 5C, a user selects, from the first main user interface 552A, a requested action for education. In response, the therapy management engine 112 can generate and present, in the CAM application 106, a software instance for a multi-step educational wizard that guides the user through user interfaces 554A, 554B, 554C, 554D, 554E, and 554F. Following the user interface 554F, the requested action for education is completed. Thereafter, the therapy management engine 112 can present a second main user interface 552B, which view indicates that the requested action for education is resolved.

[0147] FIG. 6 illustrates an example of a process 600 for implementing group resolution of requested actions within a CAM application, such as the CAM application 106 of FIGS. 1A-B, inaccordance with certain embodiments. In some embodiments, the process 600 can be executed, for example, by the therapy management engine 112 of FIGS. 1A-B and 2. In addition, or alternatively, the process 600 can be executed, for example, by the CAM application 106 of FIGS.1A-B and 2. In addition, or alternatively, the process 600 can be executed generally by any of the display devices 107 of FIGS. 1A-B and 2. Although any number of systems, in whole or in part, can implement the process 600, to simplify discussion, the process 600 will be described primarily in relation to the therapy management engine 112 and CAM application 106 of FIGS. 1A-B and 2.

[0148] At block 602, the therapy management engine 112 generates a set of requested actions to be displayed within the CAM application 106. In general, the set of requested actions can be generated, for example, as discussed relative to block 302 of FIG. 3A.

[0149] At block 610, the therapy management engine 112 presents, within the CAM application 106, the set of requested actions within a centralized location of the CAM application 106. In general, the set of requested actions can be presented, for example, as discussed relative to block 310 of FIG. 3A. In some aspects, block 610 can include presenting organized requested actions, as discussed relative to block 410 of FIG. 4A.

[0150] At block 612, the therapy management engine 112 identifies a selection (e.g., a user selection) of a plurality of requested actions within the centralized location. For example, a user may select multiple actions to be dismissed or resolved via a single resolving action, instead of individually addressing each requested action. For example, with reference to FIGS. 3B and 3C, a user can select both of the requested actions shown in the card 326 or the card 328, respectively. In a more particular example, the user may select a requested action to eat a scheduled meal and a requested action to intake carbohydrates based on the user’s current analyte levels (e.g., to address analyte levels that are low or trending low).

[0151] At block 618, the therapy management engine 112 identifies an indication of a desired action to be applied to the selected plurality of requested actions. For example, the therapy management engine 112 can receive, via the CAM application 106, user input associating the selected plurality of requested actions with a single resolving action. Continuing the previous example, if the selected plurality of requested actions includes a requested action to eat a scheduled meal and a requested action to intake carbohydrates based on the user’s current analyte levels, theuser input can associate both requested actions with an identification of a single sugary meal to facilitate relevant data logging. In some aspects, prior to block 618, or as part of block 618, the therapy management engine 112 can automatically generate and present a software instance to address the selected plurality of requested actions, as discussed relative to block 514 of FIG. 5A, where the generated and presented software instance is used to receive the user input indicating the desired action.

[0152] At block 620, the therapy management engine 112 applies the indicated action to the selected plurality of requested actions. In some aspects, the therapy management engine 112 can resolve the selected plurality of requested actions. For example, the therapy management engine 112 can indicate, in storage and / or in a user interface, that the selected plurality of requested actions are complete using a timestamp associated with the desired action. In addition, or alternatively, a corresponding log or storage can be updated to include all or part of any user input associated with the indication of the desired action. After block 620, the process 600 ends.

[0153] In certain aspects, the process 600 can address various technical challenges in the art such as, for example, that entry of contextual data is burdensome for users. The process 600 can streamline resolution of requested actions for contextual data entry, for example, by allowing a single resolving action to be applied to a grouping of requested actions, as discussed above.

[0154] FIG. 7 illustrates an example of a process 700 for graphical presentation of requested actions in association with other data, in accordance with certain embodiments. The graphical presentation can occur within a CAM application, such as the CAM application 106 of FIGS.1A-B. In some embodiments, the process 700 can be executed, for example, by the therapy management engine 112 of FIGS. 1A-B and 2. In addition, or alternatively, the process 700 can be executed, for example, by the CAM application 106 of FIGS. 1A-B and 2. In addition, or alternatively, the process 700 can be executed generally by any of the display devices 107 of FIGS.1 A-B and 2. Although any number of systems, in whole or in part, can implement the process 700, to simplify discussion, the process 700 will be described primarily in relation to the therapy management engine 112 and CAM application 106 of FIGS. 1A-B and 2.

[0155] At block 702, the therapy management engine 112 generates one or more requested actions to be displayed within the CAM application 106. In general, the one or more requested actions can be generated, for example, as discussed relative to block 302 of FIG. 3A. In someaspects, the requested actions can include both current unresolved requested actions as well as historical requested actions that have been completed.

[0156] At block 710, the therapy management engine 112 presents, within the CAM application 106, the one or more requested actions within a centralized location of the CAM application 106. In general, the one or more requested actions can be presented, for example, as discussed relative to block 310 of FIG. 3A. In some aspects, block 710 can include presenting organized requested actions, as discussed relative to block 410 of FIG. 4A.

[0157] At block 712, the therapy management engine 112 identifies a selection of one or more of the requested action(s) within the centralized location. For example, with reference to FIGS. 3B and 3C, a user can select one or more of the requested actions shown in the card 326 or the card 328, respectively. In an example, the user can select a requested action for taking medication. In another example, the user can select a requested action for data logging, such as a requested action for logging a fasting glucose. In another example, the user can select a requested action for education.

[0158] At block 714, the therapy management engine 112 identifies a request to present the requested actions within a graphical presentation. For example, via a combination of blocks 712 and 714, the user can request that one or more current or historical requested actions be presented within a graph, where the time of each requested action is indicated on the graph in conjunction with corresponding analyte values and / or other logged events (e.g., logged events that do not correspond to any of the requested actions on the requested actions list). In some aspects, the user can color-code different requested action groups, and this color coding can persist or be maintained in a resulting summary graph.

[0159] At block 716, in response to the request, the therapy management engine 112 generates and displays, in the CAM application 106, one or more graphical presentations of the requested actions in conjunction with additional data retrieved from the CAM application 106 that is correlated to the selected requested action(s). After block 716, the process 700 ends.

[0160] In certain aspects, the process 700 can address various technical challenges in the art such as, for example, that visualizations of user-provided contextual data in conjunction with analyte data are usually static way and are not easily generated or customizable. In certain aspects,the process 700 can enable requested actions to be grouped and associated with other data for easier integration into visualizations.Example Operations far Facilitating Timely Resolution of Onboarding Requested Actions

[0161] In certain aspects, various principles discussed above relative to FIGS. 3A-D, 4A-C, 5A-C, 6 and 7 can be further leveraged to streamline an onboarding process for the CAM system 104 and / or the CAM application 106. For example, a patient that is new to the CAM system 104 and / or the CAM application 106 can be encouraged or required to execute an onboarding process that includes various onboarding requested actions such as supplying profde data, completing education or training (e.g., educational content such as videos, wizards, etc.), and / or the like.

[0162] In certain aspects, the onboarding requested actions may be broken into individual modules, and these modules may be integrated into a requested actions list, as needed, for review and completion. In certain aspects, the CAM application 106 may permit a user to access one or more of the individual modules independently of activation of a CAM system such as the CAM system 104. For example, the user may enter the CAM application 106 and review educational content, complete metadata entry or logging components, or otherwise interact with one or more onboarding modules prior to establishing communications with or activating a CAM system. In this way, at least a portion of the onboarding functionality of the CAM application 106 may be accessible without requiring prior activation. In some aspects, if a user exits a standard or linear execution of the onboarding process before completion, or otherwise skips one or more requested actions, a requested actions list may be created based on the remaining onboarding requested actions to be performed by the user. In certain aspects, the CAM system 104 and / or the CAM application 106 can allow the user to interact therewith in at least a limited capacity prior to completion of the onboarding process. In some aspects, the requested actions list can be presented within a centralized location of the CAM application 106, as discussed above relative to FIGS.3A-D, 4A-C, 5A-C, 6, and 7. In addition, or alternatively, individual requested actions, or groups of requested actions, can be presented as notifications. Examples will be described relative to FIGS. 8-14.

[0163] FIG. 8 illustrates an example of a process 800 for implementing an express onboarding flow, in accordance with certain embodiments. The express onboarding flow can occur within a CAM application, such as the CAM application 106 of FIGS. 1A-B. In some embodiments, theprocess 800 can be executed, for example, by the therapy management engine 112 of FIGS. 1 A-B and 2. In addition, or alternatively, the process 800 can be executed, for example, by the CAM application 106 of FIGS. 1 A-B and 2. In addition, or alternatively, the process 800 can be executed generally by any of the display devices 107 ofFIGS. 1 A-B and 2. Although any number of systems, in whole or in part, can implement the process 800, to simplify discussion, the process 800 will be described primarily in relation to the therapy management engine 112 and CAM application 106 ofFIGS. 1A-B and 2.

[0164] At block 802, the therapy management engine 112 presents a plurality of onboarding requested actions to a user of the CAM application 106. For example, the plurality of onboarding requested actions can be presented to the user during initial onboarding process, for example, in response to an initial execution of the CAM application 106 (e.g., following successful installation of the CAM application 106).

[0165] In some aspects, the plurality of onboarding requested actions can be the same for all users. Alternatively, in some aspects, at least some of the plurality of onboarding requested actions can be based on predetermined criteria such as a location of the user (e.g., different or additional actions for different geographic locations), a history of the user, any features used or not used by the user (e.g., the user can be given onboarding requested actions to educate the user on advantages of unused features), etc. The history of the user can include, for example, a historical sensor life of continuous analyte sensors 140 utilized by the user (e.g., a mean or median sensor life).

[0166] At block 804, the therapy management engine 112 identifies a subset of the plurality of onboarding requested actions that have not been completed by the user. For simplicity, the identified subset will be referred to as a “set of incomplete onboarding requested actions.” In some aspects, one or more of the set of incomplete onboarding requested actions may be incomplete due to the user exiting the initial onboarding process prior to completion. In addition, or alternatively, one or more of the set of incomplete onboarding requested actions may be incomplete as a result of being skipped by the user during the initial onboarding process.

[0167] In various aspects, one or more features of the CAM system 104 and the CAM application 106 can be made available to the user even though some onboarding requested actions are incomplete. In some aspects, only selected features of the CAM system 104 and / or the CAM application 106 may be made available to the user. In some of these aspects, features of the CAMsystem 104 and / or the CAM application 106 corresponding to the set of incomplete onboarding requested actions can be disabled until such requested actions are complete. Alternatively, in some aspects, an entire feature set of the CAM system 104 and the CAM application 106 can be made available to the user (e.g., temporarily for a predetermined period to allow more time for completion, or indefinitely in some cases).

[0168] In some aspects, the set of incomplete onboarding requested actions can further include additional requested actions that were not part of the initial onboarding process. For example, the therapy management engine 112 can dynamically determine user characteristics, for example, based on user behavior in the CAM application 106, and integrate that information into existing unfinished onboarding requested actions. By way of more particular example, if the user connects a smart insulin pen or logs an insulin dose in the CAM application 106, the therapy management engine 112 can identify the user as an insulin user and automatically add, to the set of incomplete onboarding requested actions, onboarding requested actions corresponding to such status (e.g., onboarding requested actions requesting initial profile information for insulin users or application configuration information applicable to insulin users). In some aspects, a binary confirmation request may be presented to the user to confirm the need for the additional onboarding requested actions (e.g., a prompt to confirm that the user is an insulin user).

[0169] At block 806, the therapy management engine 112 organizes the set of incomplete onboarding requested actions according to one or more predetermined criteria. In some aspects, the therapy management engine 112 can organize the set of incomplete onboarding requested actions into a requested actions list, as discussed relative to block 406 of FIG. 4A. For example, in certain aspects, predetermined priorities can be associated with different onboarding requested actions or with different types of onboarding requested actions. In addition, or alternatively, priorities can be determinable or calculable based on an amount of time each onboarding requested action has been unresolved. In some aspects, as part of the block 806, the therapy management engine 112 can determine dependencies between individual actions of the set of incomplete onboarding requested actions and can order or prioritize the onboarding requested actions within the set based on those dependencies.

[0170] At block 810, the therapy management engine 112 presents, within the CAM application 106, the organized set of incomplete onboarding requested actions within a centralizedlocation of the CAM application 106. In general, the set of incomplete onboarding requested actions can be presented, for example, in any of the ways discussed relative to block 310 of FIG.3A, block 410 of FIG. 4A, block 510 of FIG. 5A, block 610 of FIG. 6, and / or block 710 of FIG.7. After block 810, the process 800 ends.

[0171] FIG. 9A illustrates another example of a process 900 for implementing an express onboarding flow, in accordance with certain embodiments. The express onboarding flow can occur within a CAM application, such as the CAM application 106 of FIGS. 1A-B. In some embodiments, the process 900 can be executed, for example, by the therapy management engine 112 of FIGS. 1A-B and 2. In addition, or alternatively, the process 900 can be executed, for example, by the CAM application 106 of FIGS. 1A-B and 2. In addition, or alternatively, the process 900 can be executed generally by any of the display devices 107 of FIGS. 1A-B and 2. Although any number of systems, in whole or in part, can implement the process 900, to simplify discussion, the process 900 will be described primarily in relation to the therapy management engine 112 and CAM application 106 of FIGS. 1 A-B and 2.

[0172] At block 902, the therapy management engine 112 presents a plurality of onboarding requested actions to a user of the CAM application 106. For example, the plurality of onboarding requested actions can be presented to the user during initial onboarding process, for example, in response to an initial execution of the CAM application 106 (e.g., following successful installation of the CAM application 106). In general, the block 902 can include any of the functionality described relative to block 802 of FIG. 8.

[0173] At block 904, the therapy management engine 112 identifies a subset of the plurality of onboarding requested actions that have not been completed by the user. For simplicity, the identified subset will be referred to as a “set of incomplete onboarding requested actions.” In general, the block 904 can include the therapy management engine 112 executing any of the functionality discussed above relative to block 804 of FIG. 8.

[0174] At block 910, the therapy management engine 112 generates and presents, within the CAM application 106, at least one notification for each incomplete onboarding requested action in the set of incomplete onboarding requested actions. Each notification can be, for example, a push notification, an in-app notification, and / or the like. In some aspects, each notification can include a link to a corresponding incomplete onboarding requested action. Upon user-selection ofthe link, the CAM application 106, for example, can present the incomplete onboarding requested action to the user for completion (and the corresponding requested action can be removed). In certain aspects, each notification can appear as a new window, tab, and / or section within the CAM application 106. After block 910, the process 900 ends.

[0175] FIG. 9B illustrates an exemplary express onboarding flow 925 allowing for the prevention of application functionality prior to onboarding completion, in accordance with certain embodiments. The express onboarding flow 925 can be implemented utilizing a CAM application, such as the CAM application 106 of FIGS. 1A-B. In some embodiments, the express onboarding flow 925 can be implemented, for example, by the therapy management engine 112 of FIGS. 1A-B and 2. In addition, or alternatively, the express onboarding flow 925 can be implemented, for example, by the CAM application 106 of FIGS. 1A-B and 2. In addition, or alternatively, the express onboarding flow 925 can be implemented generally by any of the display devices 107 of FIGS. 1A-B and 2. Although any number of systems, in whole or in part, can implement the express onboarding flow 925, to simplify discussion, the express onboarding flow 925 will be described primarily in relation to the therapy management engine 112 and CAM application 106 of FIGS. 1A-B and 2.

[0176] As shown, in response to determining that one or more predetermined portions of CAM application onboarding have not been completed by a user, an initial notification 926 is presented on a screen 928 of the user’s receiver device. In response to selecting the initial notification 926, a notification page 930 is presented that provides contextual information 932 as well as a selectable icon 934 for initiating required onboarding actions.

[0177] FIG. 10 illustrates an example of a process 1000 for determining and utilizing onboarding requested actions based on historical sensor life, in accordance with certain embodiments. In some embodiments, the process 1000 can be executed, for example, by the therapy management engine 112 of FIGS. 1A-B and 2. In addition, or alternatively, the process 1000 can be executed, for example, by the CAM application 106 ofFIGS. 1A-B and 2. In addition, or alternatively, the process 1000 can be executed generally by any of the display devices 107 of FIGS. 1A-B and 2. Although any number of systems, in whole or in part, can implement the process 1000, to simplify discussion, the process 1000 will be described primarily in relation to the therapy management engine 112 and CAM application 106 ofFIGS. 1 A-B and 2.

[0178] At block 1001, the therapy management engine 112 determines a historical sensor life for a user. The historical sensor life can include, for example, a lifespan of one or more continuous analyte sensors 140 previously applied by the user (e.g., a time that the sensor successfully operated after being applied to the user’s body). For example, the determined historical sensor life can be, for example, lifespan of one or more continuous analyte sensors 140 (e.g., the latest sensor, the last two sensors, etc.), the mean or median lifespan of all continuous analyte sensors applied by the user, and / or the like.

[0179] At block 1003, the therapy management engine 112 determines an onboarding requested action for the user based on an analysis of the historical sensor life determined at block 1001. For example, in some aspects, the historical sensor life can be compared to a predetermined threshold. If the historical sensor life determined at block 1001 is below the predetermined threshold, an onboarding requested action may be determined for the user. The onboarding requested action may be, for example, education that details (e.g., via one or more images, text, video animation, or the like) correct sensor application and / or overlay application. In some aspects, the onboarding requested action can include a request for user acknowledgement.

[0180] At block 1010, the therapy management engine 112 generates and presents the onboarding requested action from block 1003 to the user, for example, in the CAM application 106. In some aspects, the onboarding requested action can be presented as part of an initial onboarding process in response to an initial execution of the CAM application 106 (e.g., after successful installation of the CAM application 106). In some of these aspects, the onboarding requested action can be required for completion during initial onboarding. In others of these aspects, the onboarding requested action can be skipped and completed at a later time. In addition, or alternatively, the onboarding requested action can be presented within a centralized location of the CAM application 106, as discussed relative to blocks 310, 410, 510, 610, 710, and 810 of FIGS. 3A, 4A, 5A, 6, 7, and 8, respectively. In addition, or alternatively, the block 1010 can include presenting, within the CAM application 106, at least one notification for the onboarding requested action, as discussed relative to block 910 of FIG. 9A. After block 1010, the process 1000 ends.

[0181] FIG. 11 illustrates another example of a process 1100 for implementing an express onboarding flow, in accordance with certain embodiments. The express onboarding flow can occurwithin a CAM application, such as the CAM application 106 of FIGS. 1A-B. In some embodiments, the process 1100 can be executed, for example, by the therapy management engine 112 of FIGS. 1A-B and 2. In addition, or alternatively, the process 1100 can be executed, for example, by the CAM application 106 of FIGS. 1A-B and 2. In addition, or alternatively, the process 1100 can be executed generally by any of the display devices 107 of FIGS. 1A-B and 2. Although any number of systems, in whole or in part, can implement the process 1100, to simplify discussion, the process 1100 will be described primarily in relation to the therapy management engine 112 and CAM application 106 of FIGS. 1 A-B and 2.

[0182] At block 1102, the therapy management engine 112 generates a plurality of onboarding requested actions that are to be resolved within the CAM application 106. In general, the plurality of requested onboarding actions can be generated, for example, as discussed relative to block 302 of FIG. 3 A.

[0183] At block 1104, the therapy management engine 112 identifies a subset of the plurality of onboarding requested actions that have not been completed by the user. For simplicity, the identified subset will be referred to as a “set of incomplete onboarding requested actions.” In general, the block 1104 can include the therapy management engine 112 executing any of the functionality discussed above relative to block 804 of FIG. 8.

[0184] At block 1108, the therapy management engine 112 disables one or more features of the CAM application 106 corresponding to the set of incomplete onboarding requested actions. For example, certain functionality (e g., viewing analyte measurements) may be restricted until certain onboarding actions are completed. In certain aspects, the disabled one or more features can include any feature of the CAM system 104 and / or of the CAM application 106, such as viewing of analyte measurements, sharing of analyte measurements with other users or devices, integration of any of the display devices 107, combinations of the foregoing and / or the like.

[0185] At block 1110, the therapy management engine 112 presents, within the CAM application 106, the set of incomplete onboarding requested actions within a centralized location of the CAM application 106. In general, the set of incomplete onboarding requested actions can be presented, for example, in any of the ways discussed relative to block 310 of FIG. 3A, block 410 of FIG. 4A, block 510 of FIG. 5 A, block 610 of FIG. 6, and / or block 710 of FIG. 7. In some aspects, block 510 can include presenting organized requested onboarding actions, as discussedrelative to block 810 of FIG. 8. Tn some aspects, to further indicate that the set of incomplete onboarding requested actions are currently causing feature disablement, such actions can be prioritized or highlighted, for example, in the centralized location of the CAM application 106.

[0186] At block 1118, the therapy management engine 112 identifies completion of one or more of the set of incomplete onboarding requested actions. In some aspects, the therapy management engine 112 can identify the completion, for example, by receiving user input that satisfies the one or more of the set of incomplete onboarding requested actions, as generally discussed relative to block 518 of FIG. 5 A. In addition, or alternatively, the therapy management engine 112 can identify the completion, for example, via an indication of a desired action to be applied to the one or more of the set of incomplete onboarding requested actions, as generally discussed relative to block 618 of FIG. 6. Other examples of identifying completion will be apparent to one skilled in the art after a detailed review of the present disclosure.

[0187] At block 1120, the therapy management engine 112 removes the completed onboarding requested action(s) from the centralized location of the CAM application 106. In general, the removal can include, for example, performing any of the resolution functionality discussed above relative to block 520 of FIG. 5A and / or block 620 of FIG. 6.

[0188] At block 1122, the therapy management engine 112 enables one or more features of the CAM application 106 corresponding to the completed onboarding requested action(s). After block 1122, the process 1100 ends.

[0189] FIG. 12 illustrates another example of a process 1200 for implementing an express onboarding flow, in accordance with certain embodiments. The express onboarding flow can occur within a CAM application, such as the CAM application 106 of FIGS. 1A-B. In some embodiments, the process 1200 can be executed, for example, by the therapy management engine 112 of FIGS. 1A-B and 2. In addition, or alternatively, the process 1200 can be executed, for example, by the CAM application 106 of FIGS. 1A-B and 2. In addition, or alternatively, the process 1200 can be executed generally by any of the display devices 107 of FIGS. 1A-B and 2. Although any number of systems, in whole or in part, can implement the process 1200, to simplify discussion, the process 1200 will be described primarily in relation to the therapy management engine 112 and CAM application 106 of FIGS. 1A-B and 2.

[0190] At block 1201, the therapy management engine 112 identifies a feature of the CAM application 106 that has not been utilized by a user within a predetermined period of time after one or more onboarding requested actions corresponding to the feature have been completed. In certain aspects, certain onboarding requested actions may be highlighted and / or prioritized within a requested actions list if certain criteria are met (e.g., if the user does not use a certain feature within a certain time, an onboarding requested action focused on that feature may be prioritized and / or highlighted). If the user does not use a feature within a predetermined time after completing, for example, an onboarding tutorial for the feature may be advisable, the feature may be disabled to save resources, as further discussed below. If the user wants to use the feature after a predetermined time has passed, the feature may be reestablished, and a corresponding reminder presenting onboarding guidance for such feature may be presented within the requested actions list. In certain aspects, this facilitates a continuous monitoring of compliance, which may be correlated to adjustable insurance premiums or other motivational benefits. In some aspects, this feature can be gamified.

[0191] At block 1208, in response to the identification at block 1201, the therapy management engine 112 disables the identified feature within the CAM application 106 (e.g., to save resources). In general, the block 1208 can include executing any of the disablement functionality discussed above relative to block 1108 of FIG. 11.

[0192] At block 1209, the therapy management engine 112 creates, within the CAM application 106, one or more onboarding requested actions corresponding to the disabled feature. The one or more onboarding requested actions can include, for example, instruction for the user to take, or re-take, an onboarding tutorial for the feature.

[0193] At block 1210, the therapy management engine 112 presents, within the CAM application 106, the created onboarding requested action(s) within a centralized location of the CAM application 106. In general, the created onboarding requested action(s) can be presented, for example, in any of the ways discussed relative to block 310 of FIG. 3A, block 410 of FIG. 4A, block 510 of FIG. 5A, block 610 of FIG. 6, and / or block 710 of FIG. 7. In some aspects, block 510 can include presenting organized requested onboarding actions, as discussed relative to block 810 of FIG. 8. In some aspects, to further indicate that the set of incomplete onboarding requestedactions are currently causing feature disablement due to feature non-use, such actions can be prioritized or highlighted, for example, in the centralized location of the CAM application 106.

[0194] At block 1218, the therapy management engine 112 identifies completion of the created onboarding requested action(s). In some aspects, the therapy management engine 112 can identify the completion, for example, in any of the ways discussed relative to block 1118 of FIG. 11.

[0195] At block 1220, in response to the identified completion at block 1218, the therapy management engine 112 removes, from the CAM application 106, the created onboarding requested action(s). In general, the removal can include, for example, performing any of the resolution functionality discussed above relative to block 520 of FIG. 5A, block 620 of FIG. 6, and / or block 1120 of FIG. 11.

[0196] At block 1222, in further response to the identified completion at block 1218, the therapy management engine 112 enables the identified feature (from block 1201) within the CAM application 106. After block 1222, the process 1200 ends.Example Operations for Abbreviated Onboarding

[0197] In certain aspects, when a user reinstalls a CAM application such as the CAM application 106, or performs a hard reset of their user device (e.g., any of the display devices 107 discussed relative to FIGS. 1A-B and 2), the CAM application may ask for certain information related to an active CAM system 104, such as a data matrix code (which users usually do not keep). Further in certain aspects, all historical analyte values may be locally stored and deleted when the CAM application is reinstalled or the user device is reset.

[0198] In certain aspects, to resolve this problem, analyte values and user details including data matrix information and a user’s unique device identifier can be stored remotely (e.g., in the cloud or otherwise on a remote server). In certain aspects, these historical analyte values can restored to the user device, and user details can then be used to reestablish communications between the reinstalled CAM application and the currently running CAM system. After a reset, the identifier of the device can be matched to the remotely stored device identifier, and the application and all user data can be automatically restored to the user device. In some aspects, this restoration can be conditional upon the device implementing the same or greater level of security. An example of abbreviated onboarding will be discussed relative to FIG. 13 A.

[0199] FIG. 13 A illustrates an example of a process 1300 for implementing an abbreviated onboarding flow based on a prior application installation, in accordance with certain embodiments. In certain aspects, the process 1300 can address various technical challenges in the art such as, for example, that CAM onboarding is currently time-consuming and interferes with a user’s ability to immediately interact with a CAM application such as the CAM application 106.

[0200] In some embodiments, the process 1300 can be executed, for example, by the therapy management engine 112 of FIGS. 1A-B and 2. In addition, or alternatively, the process 1300 can be executed, for example, by the CAM application 106 of FIGS. 1A-B and 2. In addition, or alternatively, the process 1300 can be executed generally by any of the display devices 107 of FIGS. 1A-B and 2. Although any number of systems, in whole or in part, can implement the process 1300, for clarity, the process 1300 will be described primarily in relation to a remote server, a user device, and a CAM application. In certain aspects, the remote server can correspond, for example, to the therapy management engine 112 executing in a public or private cloud. In certain aspects, the user device can correspond, for example, to any of the display devices 107 discussed relative to FIGS. 1A-B and 2. In certain aspects, the CAM application can correspond to the CAM application 106 of FIGS. 1 A and 2.

[0201] At block 1302, the remote server confirms an initial installation of the CAM application on the user device. At block 1304, the remote server identifies establishment of a first successful communications connection between an initial installation of the CAM application on the user device and a currently running CAM system (e.g., a CAM system 104, as discussed relative to FIGS. 1A-B and 2).

[0202] At block 1306, the remote server receives, from the initial installation of the CAM application 106, a unique identifier of the user device and details of the first successful communications connection. At block 1308, the remote server stores the details at the remote server and a correspondence of such details to the unique identifier of the user device. At block 1310, the remote server determines a subsequent installation of the CAM application, on the user device, utilizing (e.g., based on) the unique identifier of the user device.

[0203] At block 1312, the remote server sends, to the user device, the details of the first successful communications connection to facilitate establishment of a second communicationsconnection between the subsequent installation of the CAM application on the user device and the currently running CAM system. After block 1312, the process 1300 ends.

[0204] In certain aspects, onboarding can also be abbreviated and simplified, for example, by removing optional input fields from the onboarding process (e.g., input fields requesting data not required for operation of the CAM system 104 and / or the CAM application 106). In addition, or alternatively, certain input data for input data can be inferred or determined without user input. For example, country and language information can be inferred from the phone's region settings. In another example, other techniques (e.g., GPS) can be used to determine location. For example, location-specific onboarding that meets location-centric regulatory requirements can be retrieved and displayed.

[0205] In certain aspects, various CAM modules (and onboarding requested actions) can be dynamically enabled or disabled based on regulations associated with the current location. In another example, illustrations within the CAM application can dynamically retrieved and displayed based on the determined current location (e.g., to meet local guidelines / customs)

[0206] FIG. 13B illustrates an exemplary abbreviated onboarding flow 1325 allowing for use of an existing in-session sensor, in accordance with certain embodiments. The abbreviated onboarding flow 1325 can be implemented utilizing a CAM application, such as the CAM application 106 of FIGS. 1A-B. In some embodiments, the abbreviated onboarding flow 1325 can be implemented, for example, by the therapy management engine 112 of FIGS. 1A-B and 2. In addition, or alternatively, the abbreviated onboarding flow 1325 can be implemented, for example, by the CAM application 106 of FIGS. 1A-B and 2. In addition, or alternatively, the abbreviated onboarding flow 1325 can be implemented generally by any of the display devices 107 of FIGS.1 A-B and 2. Although any number of systems, in whole or in part, can implement the abbreviated onboarding flow 1325, to simplify discussion, the abbreviated onboarding flow 1325 will be described primarily in relation to the therapy management engine 112 and CAM application 106 of FIGS. 1A-B and 2.

[0207] As shown, the exemplary abbreviated onboarding flow 1325 initially determines 1326 that an existing in-session sensor is being used. This situation may arise when a CAM application (such as the CAM application 106 of FIGS. 1A-B) needs to be reinstalled on an existing receiver device (or needs to be newly installed on a new receiver device) during a current sensor session.In response, a confirmation 1328 is made that the currently in-session sensor is still being used, and in response to such confirmation 1328, onboarding continues 1330 and 1332 utilizing a sensor number 1334 that was previously stored for the existing in-session sensor (e.g., in a cloud computing environment, distributed storage environment, etc.). Also, when a user logs into a newly installed CAM application that is associated with a currently active sensor session, the CAM application may compare an identifier of the receiver device to a previously stored receiver device identifier that is associated with the currently active sensor session. If the identifiers do not match, an indication 1336 may be provided to the user indicating that a previously used receiver device may need to be turned off for a predetermined amount of time (such as 15 minutes) in order to remove an existing connection between the sensor and the previously used receiver device. If the identifiers do match, the indication 1336 may not be provided to the user.

[0208] FIG. 14 illustrates an example of a process 1400 for inferring information related to a user, in accordance with certain embodiments. In certain aspects, the process 1400 can address various technical challenges in the art such as, for example, that CAM onboarding is currently time-consuming and interferes with a user’s ability to immediately interact with a CAM application such as the CAM application 106.

[0209] In some embodiments, the process 1400 can be executed, for example, by the therapy management engine 112 of FIGS. 1A-B and 2. In addition, or alternatively, the process 1400 can be executed, for example, by the CAM application 106 of FIGS. 1A-B and 2. In addition, or alternatively, the process 1400 can be executed generally by any of the display devices 107 of FIGS. 1A-B and 2. Although any number of systems, in whole or in part, can implement the process 1400, for clarity, the process 1400 will be described primarily in relation to a user device and a CAM application. In certain aspects, the user device can correspond, for example, to any of the display devices 107 discussed relative to FIGS. 1A-B and 2. In certain aspects, the CAM application can correspond to the CAM application 106 of FIGS. 1A and 2.

[0210] At block 1401, the CAM application identifies one or more of a current location of the user device and a language currently being used on the user device.

[0211] At block 1403, the CAM application configures one or more features thereof based on the current location and / or the language currently being used on the user device. The block 1403 can include, for example, conditionally enabling or disabling certain features and / or executingdynamic retrieval of content (e.g., images, text, documents, settings, etc.). Tn another example, the CAM application can pre-set units of measure to be displayed therein (e.g., metric system or imperial system). In another example, the CAM application can pre-select images to be included therein (e.g., country-specific, custom-specific, age-specific), application sites to be included therein, and / or the like.

[0212] At block 1405, the CAM application generates one or more location-specific and / or language-specific onboarding requested actions that are to be resolved within the CAM application of the user device. In some aspects, these onboarding requested actions can be generated, for example, in correspondence to the configured features of the CAM application noted above relative to block 1403. In some aspects, these onboarding requested actions can correspond to location-centric regulatory requirements.

[0213] At block 1410, the CAM application presents the one or more generated onboarding requested actions within a centralized location thereof, for example, in any of the ways discussed relative to block 310 of FIG. 3 A, block 410 of FIG. 4A, block 510 of FIG. 5 A, block 610 of FIG.6, block 710 of FIG. 7, and / or block 1210 of FIG. 12. After block 1410, the process 1400 ends.

[0214] FIG. 15 is a block diagram depicting a computer system 1500 configured for facilitating timely resolution of requested actions, for example, according to certain embodiments disclosed herein. Although depicted as a single physical device, in embodiments, the computer system 1500 may be implemented using virtual device(s), and / or across a number of devices, such as in a cloud environment and / or via separate modules of portable or cloud devices. As illustrated, the computer system 1500 includes a processor 1505, a memory 1510, a storage 1515, a network interface 1525, and one or more VO interfaces 1520. In the illustrated embodiment, the processor 1505 retrieves and executes programming instructions stored in the memory 1510, as well as stores and retrieves application data residing in the storage 1515. The processor 1505 is generally representative of a single CPU and / or GPU, multiple CPUs and / or GPUs, a single CPU and / or GPU having multiple processing cores, and the like.

[0215] The memory 1510 is generally included to be representative of a random access memory (RAM). The storage 1515 may be any combination of disk drives, flash-based storage devices, and the like, and may include fixed and / or removable storage devices, such as fixed diskdrives, removable memory cards, caches, optical storage, network attached storage (NAS), or storage area networks (SAN).

[0216] In some embodiments, the I / O devices 1535 (such as keyboards, monitors, etc.) can be connected via the I / O interface(s) 1520. Further, via the network interface 1525, the computer system 1500 can be communicatively coupled with one or more other devices and components, such as the user database 110. In certain embodiments, the computer system 1500 is communicatively coupled with other devices via a network, which may include the Internet, local network(s), and the like. The network may include wired connections, wireless connections, or a combination of wired and wireless connections. As illustrated, the processor 1505, memory 1510, storage 1515, network interface(s) 1525, and the I / O interface(s) 1520 are communicatively coupled by one or more interconnects 1530. In certain embodiments, the computer system 1500 is representative of the display device 107 associated with the user. In certain embodiments, as discussed above, the display device 107 can include the user’s laptop, computer, smartphone, and the like. In another embodiment, the computer system 1500 is a server executing in a cloud environment.

[0217] In the illustrated embodiment, the storage 1515 includes the user profile 118 and a requested actions list 1580. The requested actions list 1580 can correspond, for example, to any of the requested actions lists discussed above relative to FIGS. 3A-D, 4A-C, 5A-C, 6-8, 9A-B, 10, 12, 13A-B, and 14. The memory 1510 includes the therapy management engine 112. The therapy management engine 112 can be executed by the computer system 1500 to perform, for example, any operations discussed above relative to 3A-D, 4A-C, 5A-C, 6-8, 9A-B, 10-12, 13A-B, and 14.Example Clauses

[0218] Implementation examples are described in the following numbered clauses:

[0219] Clause 1: A method of facilitating resolution of requested user actions for analyte monitoring, the method comprising, on a device executing a continuous analyte monitoring (CAM) application: generating one or more requested actions to be displayed within the CAM application; presenting the one or more requested actions within a centralized location of the CAM application; identifying a user selection of at least one requested action of the one or more requested actions within the centralized location; automatically presenting a software instance to address the at least one requested action in response to the user selection; receiving user input via the automaticallypresented software instance; and resolving the at least one requested action based on the received user input.

[0220] Clause 2: The method of Clause 1, wherein the presenting the one or more requested actions within the centralized location comprises presenting the one or more requested actions as a requested actions list.

[0221] Clause 3: The method of Clause 1, wherein the centralized location comprises a designated user interface container within a user interface of the CAM application.

[0222] Clause 4: The method of Clause 3, wherein the designated user interface container comprises a card configured to present the one or more requested actions.

[0223] Clause 5: The method of Clause 1, wherein the generating the one or more requested actions comprises automatically compiling the one or more requested actions from disparate features of the CAM application.

[0224] Clause 6: The method of Clause 1, wherein the one or more requested actions comprise at least one indication of an incomplete task within the CAM application.

[0225] Clause 7: The method of Clause 1, wherein the one or more requested actions comprise at least one indication of a request for physical action by a user.

[0226] Clause 8: The method of Clause 1, wherein the one or more requested actions comprise at least one of: entering contextual data, taking medication, providing a photograph, physical activity logging, food logging, a behavioral change suggestion, entry of fasting glucose, an instruction towards achieving a goal, a survey, or education.

[0227] Clause 9: The method of Clause 1, further comprising organizing the one or more requested actions according to one or more predetermined criteria, wherein the presenting comprises presenting the organized one or more requested actions.

[0228] Clause 10: The method of Clause 9, wherein the one or more predetermined criteria comprise at least one of: time, action type, resolution status, priority, or severity.

[0229] Clause 11: The method of Clause 1, further comprising automatically generating the software instance, the software instance comprising a user interface to guide a user through resolution of the one or more requested actions.

[0230] Clause 12: The method of Clause 11, wherein the automatically generating comprises selecting the software instance based on an analysis of historical requested actions for at least one user and subsequent actions taken by the at least one user to resolve the historical requested actions.

[0231] Clause 13: The method of Clause 1, wherein: the one or more requested actions comprise a plurality of requested actions; the user input indicates an action to be applied to the plurality of requested actions; and the resolving comprises applying the indicated action to the plurality of requested actions.

[0232] Clause 14: The method of Clause 1, further comprising: identifying a request to present the one or more requested actions within a graphical presentation; and in response to the request, generating and displaying one or more graphical presentations of the one or more requested actions in conjunction with additional data retrieved from the CAM application that is correlated to the one or more requested actions.

[0233] Clause 15: The method of Clause 14, wherein the generating and displaying the one or more graphical presentations comprises indicating a time of each selected requested action on the graphical presentation.

[0234] Clause 16: The method of Clause 14, wherein the additional data correlated to the one or more requested actions comprises corresponding analyte values.

[0235] Clause 17: The method of Clause 14, wherein the additional data correlated to the one or more requested actions comprises logged events that do not correspond to any of the requested actions.

[0236] Clause 18: The method of Clause 14, wherein the generating and displaying the one or more graphical presentations comprises color-coding different requested action groups, and maintaining the color-coding within a resulting summary graph.

[0237] Clause 19: A method of facilitating resolution of onboarding requested user actions for analyte monitoring, the method comprising, on a device executing a continuous analyte monitoring (CAM) application: presenting a plurality of onboarding requested actions to a user of the CAM application identifying a subset of the plurality of onboarding requested actions that have not been completed by the user; organizing the subset of the plurality of onboarding requested actionsaccording to one or more predetermined criteria; and presenting the organized subset of the plurality of onboarding requested actions within a centralized location of the CAM application.

[0238] Clause 20: The method of Clause 19, wherein the organizing the subset comprises prioritizing the onboarding requested actions based on at least one of predetermined priorities or dependencies between individual onboarding requested actions.

[0239] Clause 21: The method of Clause 19, wherein the one or more predetermined criteria comprise at least one of: time, action type, resolution status, priority, or severity.

[0240] Clause 22: The method of Clause 19, wherein the identifying the subset comprises automatically adding an onboarding requested action based on user behavior within the CAM application.

[0241] Clause 23 : The method of Clause 19, further comprising disabling one or more features of the CAM application corresponding to the subset of the plurality of onboarding requested actions.

[0242] Clause 24: The method of Clause 23, further comprising: identifying completion of at least one onboarding requested action of the subset; and responsive to the identified completion: removing the at least one onboarding requested action from the centralized location; and enabling at least one feature of the CAM application corresponding to the at least one onboarding requested action.

[0243] Clause 25 : A method of facilitating resolution of onboarding requested user actions for analyte monitoring, the method comprising, on a device executing a continuous analyte monitoring (CAM) application: presenting a plurality of onboarding requested actions to a user of the CAM application; identifying a subset of the plurality of onboarding requested actions that have not been completed by the user; and presenting, within the CAM application, at least one notification for each incomplete onboarding requested action of the subset.

[0244] Clause 26: The method of Clause 25, wherein each notification includes a selectable link that, upon user selection, presents a corresponding incomplete onboarding requested action within the CAM application.

[0245] Clause 27: The method of Clause 25, wherein the at least one notification comprises at least one of a push notification or an in-app notification.

[0246] Clause 28: The method of Clause 25, wherein the at least one notification is presented as at least one of a new window, tab, or section within the CAM application.

[0247] Clause 29: The method of Clause 25, further comprising preventing access to at least one feature of the CAM application until completion of at least one onboarding requested action of the subset.

[0248] Clause 30: The method of Clause 25, wherein the presenting comprises causing display of a notification page that provides contextual information and a selectable icon for initiating one or more onboarding actions of the subset.

[0249] Clause 31 : The method of Clause 25, further comprising disabling one or more features of the CAM application corresponding to the subset of the plurality of onboarding requested actions.

[0250] Clause 32: The method of Clause 31, further comprising: identifying completion of at least one onboarding requested action of the subset; and responsive to the identified completion, enabling at least one feature of the CAM application corresponding to the at least one onboarding requested action.

[0251] Clause 33: A method of facilitating resolution of requested user actions for analyte monitoring, the method comprising, on a device executing a continuous analyte monitoring (CAM) application: generating one or more requested actions to be displayed within the CAM application; and presenting the one or more requested actions within a centralized location of the CAM application.

[0252] Clause 34: The method of Clause 33, wherein the presenting the one or more requested actions within the centralized location comprises presenting the one or more requested actions as a requested actions list.

[0253] Clause 35: The method of Clause 33, wherein the centralized location comprises a designated user interface container within a user interface of the CAM application.

[0254] Clause 36: The method of Clause 35, wherein the designated user interface container comprises a card configured to present the one or more requested actions.

[0255] Clause 37: The method of Clause 33, wherein the generating the one or more requested actions comprises automatically compiling the one or more requested actions from disparate features of the CAM application.

[0256] Clause 38: The method of Clause 33, wherein the one or more requested actions comprise at least one indication of an incomplete task within the CAM application.

[0257] Clause 39: The method of Clause 33, wherein the one or more requested actions comprise at least one indication of a request for physical action by a user.

[0258] Clause 40: The method of Clause 33, wherein the one or more requested actions comprise at least one of: entering contextual data, taking medication, providing a photograph, physical activity logging, food logging, a behavioral change suggestion, entry of fasting glucose, an instruction towards achieving a goal, a survey, or education.

[0259] Clause 41: The method of Clause 33, further comprising organizing the one or more requested actions according to one or more predetermined criteria, wherein the presenting comprises presenting the organized one or more requested actions.

[0260] Clause 42: The method of Clause 41, wherein the one or more predetermined criteria comprise at least one of: time, action type, resolution status, priority, or severity.

[0261] Clause 43: A method of facilitating resolution of requested user actions for analyte monitoring, the method comprising, on a device executing a continuous analyte monitoring (CAM) application: generating one or more requested actions to be displayed within the CAM application; organizing the one or more requested actions according to one or more predetermined criteria; and presenting the organized one or more requested actions within a centralized location of the CAM application.

[0262] Clause 44: The method of Clause 43, wherein the one or more predetermined criteria comprise at least one of: time associated with the one or more requested actions, resolution status, action type, priority, or severity.

[0263] Clause 45: The method of Clause 43, wherein the organizing comprises condensing multiple related requested actions into a single element within a requested actions list.

[0264] Clause 46: The method of Clause 45, wherein the presenting the organized one or more requested actions comprises enabling manipulation of the single element such that the manipulation is applied to each requested action condensed into the single element.

[0265] Clause 47: The method of Clause 43, wherein the organizing comprises filtering the one or more requested actions based on resolution status.

[0266] Clause 48: The method of Clause 43, wherein the organizing comprises grouping requested actions by time of medication, the method further comprising, upon user selection of at least one of the grouped requested actions, presenting one or more pre-populated data logging.

[0267] Clause 49: The method of Clause 43, wherein the one or more requested actions comprise at least one indication of an incomplete task within the CAM application.

[0268] Clause 50: The method of Clause 43, wherein the one or more requested actions comprise at least one indication of a request for physical action by a user.

[0269] Clause 51: The method of Clause 43, wherein the one or more requested actions comprise at least one of: entering contextual data, taking medication, providing a photograph, physical activity logging, food logging, a behavioral change suggestion, entry of fasting glucose, an instruction towards achieving a goal, a survey, or education.

[0270] Clause 52: A method of facilitating resolution of requested user actions for analyte monitoring, the method comprising, on a device executing a continuous analyte monitoring (CAM) application: generating a set of requested actions to be displayed within the CAM application; presenting the set of requested actions within a centralized location of the CAM application; identifying a selection of a plurality of requested actions within the centralized location; identifying an indication of an action to be applied to the selected plurality of requested actions; and applying the indicated action to the selected plurality of requested actions.

[0271] Clause 53: The method of Clause 52, wherein the identifying the selection of the plurality of requested actions comprises receiving user input selecting multiple requested actions to be resolved via a single resolving action.

[0272] Clause 54: The method of Clause 52, wherein the selected plurality of requested actions comprises a requested action to eat a scheduled meal and a requested action to intake carbohydrates based on current analyte levels.

[0273] Clause 55: The method of Clause 52, wherein the identifying the indication of the action comprises automatically generating and presenting a software instance to receive user input specifying the action to be applied to the selected plurality of requested actions.

[0274] Clause 56: The method of Clause 52, wherein the applying the indicated action comprises indicating the selected plurality of requested actions as complete using a timestamp associated with the indicated action.

[0275] Clause 57: The method of Clause 52, wherein the applying the indicated action comprises updating a log to include user input associated with the indicated action.

[0276] Clause 58: A method of facilitating resolution of requested user actions for analyte monitoring, the method comprising, on a device executing a continuous analyte monitoring (CAM) application: generating one or more requested actions to be displayed within the CAM application; presenting the one or more requested actions within a centralized location of the CAM application; identifying a selection of one or more requested actions within the centralized location; identifying a request to present the selected one or more requested actions within a graphical presentation; and in response to the request, generating and displaying one or more graphical presentations of the requested actions in conjunction with additional data retrieved from the CAM application that is correlated to the selected one or more requested actions.

[0277] Clause 59: The method of Clause 58, wherein the one or more requested actions comprise both current unresolved requested actions and historical requested actions that have been completed.

[0278] Clause 60: The method of Clause 58, wherein the generating and displaying the one or more graphical presentations comprises indicating a time of each selected requested action on the graphical presentation.

[0279] Clause 61: The method of Clause 58, wherein the additional data correlated to the selected one or more requested actions comprises corresponding analyte values.

[0280] Clause 62: The method of Clause 58, wherein the additional data correlated to the selected one or more requested actions comprises logged events that do not correspond to any of the requested actions.

[0281] Clause 63: The method of Clause 58, wherein the generating and displaying the one or more graphical presentations comprises color-coding different requested action groups, and maintaining the color-coding within a resulting summary graph.

[0282] Clause 64: A method of determining and utilizing onboarding requested actions based on historical sensor life, the method comprising, on a device executing a continuous analyte monitoring (CAM) application: determining historical sensor life for a user; determining an onboarding requested action for the user based on an analysis of the historical sensor life; and generating and presenting the onboarding requested action in the CAM application.

[0283] Clause 65: The method of Clause 64, wherein the determining the historical sensor life comprises determining a lifespan of one or more continuous analyte sensors previously applied by the user.

[0284] Clause 66: The method of Clause 64, wherein the determining the historical sensor life comprises determining at least one of a mean or a median lifespan of continuous analyte sensors applied by the user.

[0285] Clause 67 : The method of Clause 64, wherein the determining the onboarding requested action comprises comparing the historical sensor life to a predetermined threshold.

[0286] Clause 68: The method of Clause 64, wherein the onboarding requested action comprises education detailing at least one of correct sensor application or correct overlay application.

[0287] Clause 69: The method of Clause 64, wherein the onboarding requested action comprises a request for user acknowledgement.

[0288] Clause 70: A method of facilitating resolution of onboarding requested user actions for analyte monitoring, the method comprising, on a device executing a continuous analyte monitoring (CAM) application: generating a plurality of onboarding requested actions that are to be resolved within the CAM application; identifying a subset of the plurality of onboarding requested actions that have not been completed by a user; disabling one or more features of the CAM application corresponding to the subset of the plurality of onboarding requested actions; presenting the subset of the plurality of onboarding requested actions within a centralized location of the CAM application; identifying completion of at least one onboarding requested action of the subset; andresponsive to the identified completion: removing the at least one onboarding requested action from the centralized location; and enabling at least one feature of the CAM application corresponding to the at least one onboarding requested action.

[0289] Clause 71 : The method of Clause 70, wherein the disabling the one or more features of the CAM application comprises restricting viewing of analyte measurements within the CAM application.

[0290] Clause 72: The method of Clause 70, wherein the disabling the one or more features comprises restricting sharing of analyte measurements with at least one of other users or other devices.

[0291] Clause 73: The method of Clause 70, wherein the presenting the subset within the centralized location comprises at least one of prioritizing or highlighting the subset of onboarding requested actions that correspond to the disabled one or more features.

[0292] Clause 74: The method of Clause 70, wherein the identifying completion of the at least one onboarding requested action comprises receiving user input satisfying the at least one onboarding requested action.

[0293] Clause 75: The method of Clause 70, wherein the removing the at least one onboarding requested action comprises indicating, in at least one of storage or within a user interface of the CAM application, that the at least one onboarding requested action has been completed.

[0294] Clause 76: A method of facilitating resolution of onboarding requested user actions for analyte monitoring, the method comprising, on a device executing a continuous analyte monitoring (CAM) application: identifying a feature of the CAM application that has not been utilized by a user within a predetermined period of time after one or more onboarding requested actions corresponding to the feature have been completed; disabling the feature within the CAM application in response to the identifying the feature; creating, within the CAM application, at least one onboarding requested action corresponding to the disabled feature; presenting the at least one onboarding requested action within a centralized location of the CAM application; identifying completion of the at least one onboarding requested action; and responsive to the identified completion: removing the at least one onboarding requested action from the centralized location; and enabling the feature of the CAM application.

[0295] Clause 77: The method of Clause 76, wherein the feature comprises at least one of viewing analyte measurements or sharing analyte measurements.

[0296] Clause 78: The method of Clause 76, wherein the disabling the feature comprises preventing access to the feature within the CAM application until completion of the one or more onboarding requested actions.

[0297] Clause 79: The method of Clause 76, wherein the at least one onboarding requested action comprises a tutorial for the disabled feature.

[0298] Clause 80: A method for implementing an abbreviated onboarding flow based on a prior application installation, the method comprising: confirming, at a remote server, an initial installation of a continuous analyte monitoring (CAM) application on a user device; identifying, at the remote server, an establishment of a first successful communications connection between the initial installation of the CAM application and a currently running CAM system; receiving, at the remote server, from the initial installation of the CAM application, a unique identifier of the user device and details of the first successful communications connection; storing, at the remote server, the details and a correspondence of the details to the unique identifier of the user device; determining, by the remote server, a subsequent installation of the CAM application on the user device based on the unique identifier of the user device; and sending, from the remote server to the user device, the details of the first successful communications connection to facilitate the establishment of a second communications connection between the subsequent installation of the CAM application on the user device and the currently running CAM system.

[0299] Clause 81: A method for implementing an abbreviated onboarding flow, the method comprising, on a user device executing a continuous analyte monitoring (CAM) application: identifying, by the CAM application, one or more of a current location of the user device and a language currently being used on the user device; configuring one or more features of the CAM application based on at least one of the current location or the language currently being used on the user device; generating one or more onboarding requested actions that are to be resolved within the CAM application, the one or more onboarding requested actions comprising at least one of the following: one or more location-specific onboarding requested actions; or one or more languagespecific onboarding requested actions; and presenting the one or more onboarding requested actions within a centralized location of the CAM application.

[0300] Clause 82: The method of Clause 81 , wherein the configuring the one or more features comprises setting units of measure to be displayed.

[0301] Clause 83 : A system for facilitating resolution of requested user actions for analyte monitoring, the system comprising: a memory comprising executable instructions; a processor in communication with the memory and configured to execute the instructions to: generate one or more requested actions to be displayed within a continuous analyte monitoring (CAM) application; present the one or more requested actions within a centralized location of the CAM application; identify a user selection of at least one requested action of the one or more requested actions within the centralized location; automatically present a software instance to address the at least one requested action in response to the user selection; receive user input via the automatically presented software instance; and resolve the at least one requested action based on the received user input.

[0302] Clause 84: A system for facilitating resolution of requested user actions for analyte monitoring, the system comprising: a memory comprising executable instructions; a processor in communication with the memory and configured to execute the instructions to: present a plurality of onboarding requested actions to a user of a continuous analyte monitoring (CAM) application identify a subset of the plurality of onboarding requested actions that have not been completed by the user; organize the subset of the plurality of onboarding requested actions according to one or more predetermined criteria; and present the organized subset of the plurality of onboarding requested actions within a centralized location of the CAM application.

[0303] Clause 85: A system for facilitating resolution of onboarding requested user actions for analyte monitoring, the system comprising: a memory comprising executable instructions; a processor in communication with the memory and configured to execute the instructions to: present a plurality of onboarding requested actions to a user of a continuous analyte monitoring (CAM) application; identify a subset of the plurality of onboarding requested actions that have not been completed by the user; and present, within the CAM application, at least one notification for each incomplete onboarding requested action of the subset.

[0304] Clause 86: A system for facilitating resolution of requested user actions for analyte monitoring, the system comprising: a memory comprising executable instructions; a processor in communication with the memory and configured to execute the instructions to: generate one ormore requested actions to be displayed within a continuous analyte monitoring (CAM) application; and present the one or more requested actions within a centralized location of the CAM application.

[0305] Clause 87: A system for facilitating resolution of requested user actions for analyte monitoring, the system comprising: a memory comprising executable instructions; a processor in communication with the memory and configured to execute the instructions to: generate one or more requested actions to be displayed within a continuous analyte monitoring (CAM) application organize the one or more requested actions according to one or more predetermined criteria; and present the organized one or more requested actions within a centralized location of the CAM application.

[0306] Clause 88: A system for facilitating resolution of requested user actions for analyte monitoring, the system comprising: a memory comprising executable instructions; a processor in communication with the memory and configured to execute the instructions to: generate a set of requested actions to be displayed within a continuous analyte monitoring (CAM) application; present the set of requested actions within a centralized location of the CAM application; identify a selection of a plurality of requested actions within the centralized location; identify an indication of an action to be applied to the selected plurality of requested actions; and apply the indicated action to the selected plurality of requested actions.

[0307] Clause 89: A system for facilitating resolution of requested user actions for analyte monitoring, the system comprising: a memory comprising executable instructions; a processor in communication with the memory and configured to execute the instructions to: generate one or more requested actions to be displayed within a continuous analyte monitoring (CAM) application; present the one or more requested actions within a centralized location of the CAM application; identify a selection of one or more requested actions within the centralized location; identify a request to present the selected one or more requested actions within a graphical presentation; and in response to the request, generate and display one or more graphical presentations of the requested actions in conjunction with additional data retrieved from the CAM application that is correlated to the selected one or more requested actions.

[0308] Clause 90: A system for determining and utilizing onboarding requested actions based on historical sensor life, the system comprising: a memory comprising executable instructions; a processor in communication with the memory and configured to execute the instructions to:determine historical sensor life for a user; determine an onboarding requested action for the user based on an analysis of the historical sensor life; and generate and present the onboarding requested action in a continuous analyte monitoring (CAM) application.

[0309] Clause 91 : A system for facilitating resolution of onboarding requested user actions for analyte monitoring, the system comprising: a memory comprising executable instructions; a processor in communication with the memory and configured to execute the instructions to: generate a plurality of onboarding requested actions that are to be resolved within a continuous analyte monitoring (CAM) application; identify a subset of the plurality of onboarding requested actions that have not been completed by a user; disable one or more features of the CAM application corresponding to the subset of the plurality of onboarding requested actions; present the subset of the plurality of onboarding requested actions within a centralized location of the CAM application; identify completion of at least one onboarding requested action of the subset; and responsive to the identified completion: remove the at least one onboarding requested action from the centralized location; and enable at least one feature of the CAM application corresponding to the at least one onboarding requested action.

[0310] Clause 92: A system for facilitating resolution of onboarding requested user actions for analyte monitoring, the system comprising: a memory comprising executable instructions; a processor in communication with the memory and configured to execute the instructions to: identify a feature of a continuous analyte monitoring (CAM) application that has not been utilized by a user within a predetermined period of time after one or more onboarding requested actions corresponding to the feature have been completed; disable the feature within the CAM application in response to the identification of the feature; create, within the CAM application, at least one onboarding requested action corresponding to the disabled feature; present the at least one onboarding requested action within a centralized location of the CAM application; identify completion of the at least one onboarding requested action; and responsive to the identified completion: remove the at least one onboarding requested action from the centralized location; and enable the feature of the CAM application.

[0311] Clause 93 : A system for implementing an abbreviated onboarding flow based on a prior application installation, the system comprising: a memory comprising executable instructions; a processor in communication with the memory and configured to execute the instructions to:confirm an initial installation of a continuous analyte monitoring (CAM) application on a user device; identify an establishment of a first successful communications connection between the initial installation of the CAM application and a currently running CAM system; receive, from the initial installation of the CAM application, a unique identifier of the user device and details of the first successful communications connection; store the details and a correspondence of the details to the unique identifier of the user device; determine a subsequent installation of the CAM application on the user device based on the unique identifier of the user device; and send, to the user device, the details of the first successful communications connection to facilitate the establishment of a second communications connection between the subsequent installation of the CAM application on the user device and the currently running CAM system.

[0312] Clause 94: A system for implementing an abbreviated onboarding flow, the system comprising: a memory comprising executable instructions; a processor in communication with the memory and configured to execute the instructions to: identify one or more of a current location of a user device and a language currently being used on the user device; configure one or more features of a continuous analyte monitoring (CAM) application CAM application based on at least one of the current location or the language currently being used on the user device; generate one or more onboarding requested actions that are to be resolved within the CAM application, the one or more onboarding requested actions comprising at least one of the following: one or more location-specific onboarding requested actions; or one or more language-specific onboarding requested actions; and present the one or more onboarding requested actions within a centralized location of the CAM application.

[0313] Clause 95: An apparatus, comprising: at least one memory comprising executable instructions; and at least one processor configured to execute the executable instructions and cause the apparatus to perform a method in accordance with any combination of Clauses 1-82.

[0314] Clause 96: An apparatus, comprising means for performing a method in accordance with any combination of Clauses 1-82.

[0315] Clause 98: A non-transitory computer-readable medium comprising executable instructions that, when executed by at least one processor of an apparatus, cause the apparatus to perform a method in accordance with any combination of Clauses 1-82.

[0316] Clause 99: A computer program product embodied on a computer-readable storage medium comprising code for performing a method in accordance with any combination of Clauses 1-82.Additional Considerations

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

[0318] 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 can be practiced. These embodiments are also referred to herein as “examples.” Such examples can include elements in addition to those shown or described. However, the present inventors also contemplate examples in which only those elements shown or described are provided. Moreover, the present inventors also contemplate examples using any combination or permutation of those elements shown or described (or one or more aspects thereof), either with respect to a particular example (or one or more aspects thereof), or with respect to other examples (or one or more aspects thereof) shown or described herein.

[0319] In the event of inconsistent usages between this document and any documents so incorporated by reference, the usage in this document controls.

[0320] In this document, the terms “a” or “an” are used, as is common in patent documents, to include one or more than one, independent of any other instances or usages of “at least one” or “one or more.” In this document, the term “or” is used to refer to a nonexclusive or, such that “A or B” includes “A but not B,” “B but not A,” and “A and B,” unless otherwise indicated. 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, that is, a system, device, article, composition, formulation, or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall 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.

[0321] Method examples described herein can be machine or computer-implemented at least in part. Some examples can include a computer-readable medium or machine-readable medium encoded with instructions operable to configure an electronic device to perform methods as described in the above examples. An implementation of such methods can include code, such as microcode, assembly language code, a higher-level language code, or the like. Such code can include computer readable instructions for performing various methods. The code may form portions of computer program products. Further, in an example, the code can be tangibly stored on one or more volatile, non-transitory, or non-volatile tangible computer-readable media, such as during execution or at other times. Examples of these tangible computer-readable 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 memories (RAMs), read only memories (ROMs), and the like.

[0322] The above description is intended to be illustrative, and not restrictive. For example, the above-described examples (or one or more aspects thereof) may be used in combination with each other. Other embodiments can be used, such as by one of ordinary skill in the art upon reviewing the above description. The Abstract is provided to comply with 37 C.F.R. § 1.72(b), to allow 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 streamline the disclosure. This should not be interpreted as intending that an unclaimed disclosed feature is essential to any claim. Rather, inventive subject matter may lie in less than all features of a particular disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description as examples or embodiments, with each claim standing on its own as a separate embodiment, and it is contemplated that such embodiments can be combined with each other in various combinations or permutations. The scope of the invention should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

CLAIMS1. A method of facilitating resolution of requested user actions for analyte monitoring, the method comprising, on a device executing a continuous analyte monitoring (CAM) application:generating one or more requested actions to be displayed within the CAM application; presenting the one or more requested actions within a centralized location of the CAM application;identifying a user selection of at least one requested action of the one or more requested actions within the centralized location;automatically presenting a software instance to address the at least one requested action in response to the user selection;receiving user input via the automatically presented software instance; andresolving the at least one requested action based on the received user input.

2. The method of claim 1, wherein the presenting the one or more requested actions within the centralized location comprises presenting the one or more requested actions as a requested actions list.

3. The method of claim 1, wherein the centralized location comprises a designated user interface container within a user interface of the CAM application.

4. The method of claim 1, wherein the one or more requested actions comprise at least one of the following:an indication of an incomplete task within the CAM application; oran indication of a request for physical action by a user.

5. The method of claim 1 , wherein the one or more requested actions comprise at least one of: entering contextual data, taking medication, providing a photograph, physical activity logging, food logging, a behavioral change suggestion, entry of fasting glucose, an instruction towards achieving a goal, a survey, or education.

6. The method of claim 1, further comprising organizing the one or more requested actions according to one or more predetermined criteria, wherein the presenting comprises presenting the organized one or more requested actions.

7. The method of claim 1, further comprising automatically generating the software instance, the software instance comprising a user interface to guide a user through resolution of the one or more requested actions.

8. The method of claim 7, wherein the automatically generating comprises selecting the software instance based on an analysis of historical requested actions for at least one user and subsequent actions taken by the at least one user to resolve the historical requested actions.

9. The method of claim 1, wherein:the one or more requested actions comprise a plurality of requested actions;the user input indicates an action to be applied to the plurality of requested actions; and the resolving comprises applying the indicated action to the plurality of requested actions.

10. The method of claim 1, further comprising:identifying a request to present the one or more requested actions within a graphical presentation; andin response to the request, generating and displaying one or more graphical presentations of the one or more requested actions in conjunction with additional data retrieved from the CAM application that is correlated to the one or more requested actions.

11. The method of claim 10, wherein the additional data correlated to the one or more requested actions comprises corresponding analyte values.

12. A system for facilitating resolution of requested user actions for analyte monitoring, the system comprising:a memory comprising executable instructions;a processor in communication with the memory and configured to execute the instructions to:generate one or more requested actions to be displayed within a continuous analyte monitoring (CAM) application;present the one or more requested actions within a centralized location of the CAM application;identify a user selection of at least one requested action of the one or more requested actions within the centralized location;automatically present a software instance to address the at least one requested action in response to the user selection;receive user input via the automatically presented software instance; and resolve the at least one requested action based on the received user input.

13. The system of claim 12, wherein the processor is further configured to execute the instructions to automatically generate the software instance, the software instance comprising a user interface to guide a user through resolution of the one or more requested actions.

14. The system of claim 13, wherein the automatically generating comprises selecting the software instance based on an analysis of historical requested actions for at least one user and subsequent actions taken by the at least one user to resolve the historical requested actions.

15. A computer-program product comprising a non-transitory computer-usable medium having computer-readable program code embodied therein, the computer-readable program code adapted to be executed to implement a method comprising:generating one or more requested actions to be displayed within a continuous analyte monitoring (CAM) application;presenting the one or more requested actions within a centralized location of the CAM application;identifying a user selection of at least one requested action of the one or more requested actions within the centralized location;automatically presenting a software instance to address the at least one requested action in response to the user selection;receiving user input via the automatically presented software instance; andresolving the at least one requested action based on the received user input.

Images