Systems, devices, and methods for dietary information collection, dietary evaluation, and analyte data correlation.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2025-12-18
- Publication Date
- 2026-04-15
AI Technical Summary
Existing systems struggle to accurately correlate dietary intake with analyte levels, particularly glucose levels, due to insufficient data points, manual logging requirements, and inaccuracies in detecting meal events, leading to challenges in understanding and mitigating glycemic responses.
Systems and methods for detecting, measuring, and classifying diets in relation to analyte levels, using in vivo analyte monitoring systems with improved graphical user interfaces (GUIs) that provide intuitive and timely feedback on dietary impacts, enabling users to understand and adjust their dietary choices based on analyte responses.
The system enables individuals to make informed dietary adjustments by providing direct and timely feedback on their diet-related analyte responses, encouraging healthier choices and improving health outcomes by maintaining target analyte ranges.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
Related Applications
[0001] This application claims the benefit of priority to U.S. Provisional Application No. 63 / 144,782, filed Feb. 2, 2021, and U.S. Provisional Application No. 63 / 046,849, filed Jul. 1, 2020, both of which are hereby expressly incorporated by reference in their entirety for all purposes. This application is also related to U.S. Application No. 15 / 206,095, filed Jul. 8, 2016, which claims the benefit of priority to and the benefit of U.S. Provisional Application No. 62 / 191,218, filed Jul. 10, 2015, U.S. Provisional Application No. 62 / 191,262, filed Jul. 10, 2015, U.S. Provisional Application No. 62 / 307,344, filed Mar. 11, 2016, and U.S. Provisional Application No. 62 / 307,346, filed Mar. 11, 2016, all of which are hereby expressly incorporated by reference in their entirety for all purposes.
[0002] This divisional application is a divisional application divided from Japanese Patent Application No. 2022-580411, which is referred to as the "present application" above, as the parent application.
Technical Field
[0003] The present subject matter relates generally to systems, devices, and methods for collecting information regarding an individual's analyte levels and information regarding the diets consumed by those individuals. The present subject matter further relates to processing, analyzing, and / or presenting this information for the purpose of correlating dietary information to analyte levels and identifying and implementing adjustments to those individuals' diets, lifestyles, and / or medical treatment regimens.
Background Art
[0004] The increase in the prevalence of type 2 diabetes and metabolic syndrome over the past few decades has been attributed to changes in diet and activity levels. For example, the consumption of relatively readily available high-glycemic index (GI) foods causes a rapid increase in postprandial blood glucose and insulin levels, which is clearly associated with weight gain and obesity. These conditions may further contribute to an increased risk of developing these diseases and other disorders.
[0005] Most people generally understand the importance of their diet. However, in reality, many struggle to translate this general understanding into their specific food choices. These problems exist primarily because people cannot directly see the impact of their choices. This can lead to misunderstandings about food portion sizes, misconceptions about which foods are relatively healthy, and a general lack of awareness regarding the duration and intensity of activities necessary to maintain health. These problems are further exacerbated by advertising, habits, peer pressure, food preferences, and recommendations based on generalization.
[0006] To address these issues, analytes monitoring systems can track and better understand an individual's physiological response. Since high glucose levels are primarily caused by dietary intake, postprandial glucose levels can be correlated with the amount of carbohydrates and other dietary components consumed, as well as the individual's physiological response to the meal. However, analyzing this vast amount of data presents challenges in presenting the data meaningfully and enabling efficient action. Data on dietary choices and their subsequent effects need to be understood not only on a clinical basis but also on an individual basis, so that individuals, diet managers, and / or healthcare professionals can understand and mitigate glucose excursions, such as episodes of hyperglycemia.
[0007] Previous attempts to implement software to track users' dietary intake and correlate it with their analytic data have been plagued by numerous shortcomings. For example, some systems require individuals to perform numerous inconvenient and uncomfortable discrete blood glucose measurements (e.g., fingerstick blood glucose tests). These solutions may also suffer from an insufficient number of data points to adequately determine the glycemic response to a meal. For instance, individuals may perform discrete blood glucose measurements before or after the time when their glycemic response peaks, making it difficult to accurately capture the glycemic response and meaningfully compare meals based on it. A lack of data points also makes it difficult to automatically detect the occurrence of meal events in the user's analytic data. Consequently, some preceding systems rely heavily on manual logging of meals by the user.
[0008] Prior art systems, such as those described in Patent Document 1, which attempt to detect meal events simply based on the presence of elevated glucose levels, are insufficient because they cannot take into account the user's previous eating history and may consequently overestimate the number of meals the user has consumed.
[0009] Therefore, improved systems, devices, and methods are needed for dietary information collection, dietary evaluation and detection, and correlation with analyte levels. [Prior art documents] [Patent Documents]
[0010] [Patent Document 1] U.S. Patent Application Publication No. 2003 / 0208113 [Overview of the project]
[0011] Provided herein are exemplary embodiments of systems, devices, and methods for detecting, measuring, and classifying the diet of a human individual in relation to the measurement of that individual's analytes. These individuals may include those exhibiting or diagnosed with diabetes, those considered pre-diabetic, those with metabolic syndrome, and even those without symptoms of diabetes, pre-diabetes, or metabolic syndrome. These individuals may be any person motivated to improve their health by adjusting their dietary and / or activity practices. As a result, information can be presented to the individual indicating which diet or dietary aspects have the greatest impact on analytes levels. These results can be organized and categorized based on criteria selected in advance, either directly by the individual or based on consultation between the individual and a healthcare professional.
[0012] In many embodiments, individual diet-related analyte responses collected by analyte monitoring systems, such as in vivo analyte monitoring systems, can be compared to or linked with dietary information to discover common consistency (or inconsistency) along with trends, based on relevant historical glucose readings and associated algorithms, variables, weights, comparisons, and trends.
[0013] Many embodiments disclosed herein are intended to engage individuals by providing direct and timely feedback on their diet-related analytic responses. In some embodiments, this analytic response can be provided to the individual to characterize the effects of dietary intake.
[0014] This embodiment is immediately beneficial and enjoyable for individuals to use, thereby encouraging them to experiment with it and better understand how their diet affects their body's analytic responses. Individuals can compare and contrast their current and past analytic data to see how their efforts relate to better diets and dietary categories, and how these choices directly impact their health.
[0015] Exemplary embodiments are also provided in which analyte data can be collected from local populations and linked or associated with dietary information relating to the meals consumed by those local populations. The aggregated information can be processed and presented to the user to identify common analyte-level trends among local populations and determine whether there is any correlation with the common dietary habits of those populations. For example, a person responsible for dietary choices can use the presented information to determine whether they can or should adjust the content, type, and / or timing of meals to mitigate undesirable trends in the aggregated analyte data, such as a reduction in the occurrence of hypoglycemic or hyperglycemic events. These exemplary embodiments are particularly suitable for populations in common living environments, such as elderly care facilities, hospitals, rehabilitation centers, schools, dormitories, military facilities or bases, family residences, prisons or criminal convict groups, and any other such environments in which groups of individuals regularly share one or more meals.
[0016] In at least preferred embodiments, many of the embodiments provided herein are improved graphical user interfaces (GUIs) or GUI functions for analyte monitoring systems that are intuitive, highly intuitive, user-friendly, and provide rapid access to the user's physiological information. More specifically, these embodiments may enable the user (or HCP) to quickly see a variety of physiological states and / or actionable responses and to easily navigate through and between different user interfaces that can correlate analyte data with diet, exercise, stress, or other factors, without requiring the user (or HCP) to perform the difficult task of examining large amounts of analyte data. Furthermore, in preferred embodiments, at least some of the GUIs and GUI functions enable the user (and their caregivers) to better understand and improve their diet, eating habits, and management of other stressors by seeing the correlation between these activities and glucose levels. Similarly, in preferred embodiments, at least an improved digital interface and / or functionality for the dietary monitoring system can, to name just a few, visualize the impact of food choices on analyte (glucose) levels and the amount of time spent within the target analyte range (TIR); visualize good and bad foods present in the user's current diet and their impact on glucose levels and TIR; correlate dietary information with detected dietary events; and improve motivation for the user to maintain and / or increase TIR by informing the user of food options to eat while maintaining the TIR target. Other improvements and benefits are also provided. Various configurations of these devices are described in detail by embodiments, but these are illustrative only.
[0017] Improvements to the GUI in the various embodiments described and claimed herein result in at least the technical effect of assisting the user of a device to operate the device more accurately, more efficiently, and more safely. It will be understood that the information provided to the user on the GUI, the order in which that information is provided, and the clarity of how that information is structured can have a significant impact on how the user interacts with the system and how the system operates. Thus, the GUI guides the user in the technical task of operating the system in order to make the necessary readings and / or to obtain information accurately and efficiently.
[0018] Other systems, devices, methods, features, and advantages of the subject matter described herein will be apparent to those skilled in the art by considering the following figures and detailed description. All such additional systems, devices, methods, features, and advantages are contained herein, within the scope of the subject matter described herein, and are intended to be protected by the appended claims. Features of exemplary embodiments should not be construed as limiting the claims unless those features are explicitly described in the appended claims.
[0019] Details of the subject matter described herein, both in terms of its structure and operation, can be made apparent by examining the accompanying diagrams, where similar reference figures refer to similar parts. Components in the diagrams are not necessarily to scale, and the emphasis is on illustrating the principles of the subject matter. Furthermore, all diagrams are intended to convey concepts, and relative sizes, shapes, and other detailed attributes may be shown schematically rather than literally or precisely. [Brief explanation of the drawing]
[0020] [Figure 1] Figure 1 is a high-level diagram illustrating an exemplary embodiment of an analyte monitoring system for real-time analyte (e.g., glucose) measurement, data acquisition, and / or processing. [Figure 2A] Figure 2A is a block diagram showing an exemplary embodiment of a reader device configured as a smartphone. [Figure 2B] Figure 2B is a block diagram showing an exemplary embodiment of a sensor control device. [Figure 3A] Figure 3A is a flowchart showing an exemplary embodiment of a method for collecting and evaluating dietary information. [Figure 3B] Figure 3B is a flowchart showing an exemplary embodiment of a method for adjusting the automatic meal detection sensitivity setting. [Figure 3C] Figure 3C is a diagram showing an exemplary embodiment of a graphical display of a user's analyte data over time with an overlay of past blood glucose responses. [Figure 3D] Figure 3D is a diagram showing an example of a graph of analyte data over time displaying an exemplary dataset having four different meal events. [Figure 4A] Figure 4A is a diagram showing an exemplary embodiment of a graphical user interface display screen. [Figure 4B] Figure 4B is a diagram showing an exemplary embodiment of a graphical user interface display screen. [Figure 4C] Figure 4C is a diagram showing an exemplary embodiment of a graphical user interface display screen. [Figure 4D] Figure 4D is a diagram showing an exemplary embodiment of a graphical user interface display screen. [Figure 4E] Figure 4E is a diagram showing an exemplary embodiment of a graphical user interface display screen. [Figure 5A] Figure 5A is a diagram showing an exemplary embodiment of a graphical user interface display screen. [Figure 5B] Figure 5B is a diagram showing an exemplary embodiment of a graphical user interface display screen. [Figure 5C] Figure 5C is a diagram showing an exemplary embodiment of a graphical user interface display screen. [Figure 5D] Figure 5D shows an exemplary embodiment of a graphical user interface display screen. [Figure 5E] Figure 5E shows an exemplary embodiment of a graphical user interface display screen. [Figure 5F] Figure 5F shows an exemplary embodiment of a graphical user interface display screen. [Figure 6A] Figure 6A is a block diagram showing an exemplary embodiment of an analyte monitoring system for use with multiple individuals within a local population. [Figure 6B] Figure 6B is a flowchart illustrating an exemplary embodiment of how to use an analyte monitoring system with multiple individuals within a local population. [Figure 7] Figure 7 shows exemplary aggregated analyte data for one or more (or all) individuals within a regional population. [Figure 8A-1-1] Figure 8A-1-1 shows an exemplary embodiment of a graphical user interface for displaying analyte indicators. [Figure 8A-1-2] Figure 8A-1-2 is a continuation of Figure 8A-1-1. [Figure 8A-2-1] Figure 8A-2-1 shows an exemplary embodiment of a graphical user interface for displaying analyte indicators. [Figure 8A-2-2] Figure 8A-2-2 is a continuation of Figure 8A-2-1. [Figure 8B] Figure 8B shows an exemplary embodiment of a graphical user interface for displaying analyte indicators. [Figure 9A-1-1] Figure 9A-1-1 shows an exemplary embodiment of a graphical user interface for logging meal information. [Figure 9A-1-2] Figure 9A-1-2 is a continuation of Figure 9A-1-1. [Figure 9A-2-1] Figure 9A-2-1 shows an exemplary embodiment of a graphical user interface for logging meal information. [Figure 9A-2-2] Figure 9A-2-2 is a continuation of Figure 9A-2-1. [Figure 9B-1] Figure 9B-1 shows an exemplary embodiment of a graphical user interface for logging meal information. [Figure 9B-2] Figure 9B-2 is a continuation of Figure 9B-1. [Figure 9B-3] Figure 9B-3 is a continuation of Figure 9B-2. [Figure 9C-1] Figure 9C-1 shows an exemplary embodiment of a graphical user interface for logging meal information. [Figure 9C-2] Figure 9C-2 shows an exemplary embodiment of a graphical user interface for logging meal information. [Figure 9C-3] Figure 9C-3 shows an exemplary embodiment of a graphical user interface for logging meal information. [Figure 9C-4] Figure 9C-4 shows an exemplary embodiment of a graphical user interface for logging meal information. [Figure 9C-5] Figure 9C-5 shows an exemplary embodiment of a graphical user interface for logging meal information. [Figure 9D-1] Figure 9D-1 shows an exemplary embodiment of a graphical user interface for logging meal information. [Figure 9D-2] Figure 9D-2 is a continuation of Figure 9D-1. [Figure 9D-3] Figure 9D-3 is a continuation of Figure 9D-2. [Figure 9E-1] Figure 9E-1 shows an exemplary embodiment of a graphical user interface for displaying mismatch events. [Figure 9E-2] Figure 9E-2 is a continuation of Figure 9E-1. [Figure 10A-1-1] Figure 10A-1-1 shows an exemplary embodiment of a graphical user interface for logging events unrelated to eating and drinking. [Figure 10A-1-2] Figure 10A-1-2 is a continuation of Figure 10A-1-1. [Figure 10A-1-3] Figure 10A-1-3 is a continuation of Figure 10A-1-2. [Figure 10A-2-1] Figure 10A-2-1 shows an exemplary embodiment of a graphical user interface for logging events unrelated to eating and drinking. [Figure 10A-2-2] Figure 10A-2-2 is a continuation of Figure 10A-2-1. [Figure 10B-1] Figure 10B-1 shows an exemplary embodiment of a graphical user interface for logging events unrelated to food and drink. [Figure 10B-2] Figure 10B-2 is a continuation of Figure 10B-1. [Figure 10C] Figure 10C shows an exemplary embodiment of an application icon. [Figure 11] Figure 11 shows an exemplary embodiment of a typical flowchart for logging meal information. [Figure 12] Figure 12 shows an exemplary embodiment of a graphical user interface for displaying an indicator of time range and a graph of analyte concentration data. [Figure 13A] Figure 13A shows an exemplary embodiment of a graphical user interface for insight reporting. [Figure 13B-1] Figure 13B-1 shows an exemplary embodiment of a graphical user interface for insight reporting. [Figure 13B-2] Figure 13B-2 shows an exemplary embodiment of a graphical user interface for insight reporting. [Figure 13B-3] Figure 13B-3 shows an exemplary embodiment of a graphical user interface for insight reporting. [Figure 13B-4]Figure 13B-4 shows an exemplary embodiment of a graphical user interface for insight reporting. [Figure 13B-5] Figure 13B-5 shows an exemplary embodiment of a graphical user interface for insight reporting. [Figure 13C-1] Figure 13C-1 shows an exemplary embodiment of a graphical user interface for insight reporting. [Figure 13C-2] Figure 13C-2 is a continuation of Figure 13C-1. [Figure 13C-3] Figure 13C-3 is a continuation of Figure 13C-2. [Figure 13D-1] Figure 13D-1 shows an exemplary embodiment of a graphical user interface for insight reporting. [Figure 13D-2] Figure 13D-2 shows an exemplary embodiment of a graphical user interface for insight reporting. [Figure 13D-3] Figure 13D-3 shows an exemplary embodiment of a graphical user interface for insight reporting. [Figure 14A-1] Figure 14A-1 shows an exemplary embodiment of a graphical user interface for displaying meal rankings. [Figure 14A-2] Figure 14A-2 is a continuation of Figure 14A-1. [Figure 14B-1] Figure 14B-1 shows an exemplary embodiment of a graphical user interface for displaying meal rankings. [Figure 14B-2] Figure 14B-2 is a continuation of Figure 14B-1. [Figure 14B-3] Figure 14B-3 is a continuation of Figure 14B-2. [Figure 15A] Figure 15A shows an exemplary embodiment of a graphical user interface for displaying a range time indicator. [Figure 15B]Figure 15B shows an exemplary embodiment of a graphical user interface for displaying a range time indicator. [Figure 15C] Figure 15C shows an exemplary embodiment of a graphical user interface for displaying a range time indicator. [Figure 16A-1] Figure 16A-1 shows an additional exemplary embodiment of a graphical user interface for displaying a range time indicator. [Figure 16A-2] Figure 16A-2 shows an additional exemplary embodiment of a graphical user interface for displaying a range time indicator. [Figure 16B-1-1] Figure 16B-1-1 shows an additional exemplary embodiment of a graphical user interface for displaying a range time indicator. [Figure 16B-1-2] Figure 16B-1-2 is a continuation of Figure 16B-1-1. [Figure 16B-2-1] Figure 16B-2-1 shows an additional exemplary embodiment of a graphical user interface for displaying a range time indicator. [Figure 16B-2-2] Figure 16B-2-2 is a continuation of Figure 16B-2-1. [Figure 16C-1-1] Figure 16C-1-1 shows an additional exemplary embodiment of a graphical user interface for displaying a range time indicator. [Figure 16C-1-2] Figure 16C-1-2 is a continuation of Figure 16C-1-1. [Figure 16C-1-3] Figure 16C-1-3 is a continuation of Figure 16C-1-2. [Figure 16C-2-1] Figure 16C-2-1 shows an additional exemplary embodiment of a graphical user interface for displaying a range time indicator. [Figure 16C-2-2] Figure 16C-2-2 is a continuation of Figure 16C-2-1. [Figure 16D-1-1] Figure 16D-1-1 shows an additional exemplary embodiment of a graphical user interface for displaying a range time indicator. [Figure 16D-1-2] Figure 16D-1-2 is a continuation of Figure 16D-1-1. [Figure 16D-2-1] Figure 16D-2-1 shows an additional exemplary embodiment of a graphical user interface for displaying a range time indicator. [Figure 16D-2-2] Figure 16D-2-2 is a continuation of Figure 16D-2-1. [Figure 17A] Figure 17A shows an additional exemplary embodiment of a graphical user interface for displaying a range time indicator. [Figure 17B] Figure 17B shows an additional exemplary embodiment of a graphical user interface for displaying a range time indicator. [Figure 18A] Figure 18A shows an additional exemplary embodiment of a graphical user interface for displaying a range time indicator. [Figure 18B] Figure 18B shows an additional exemplary embodiment of a graphical user interface for displaying a range time indicator. [Figure 19A] Figure 19A shows an exemplary embodiment for banking time within a target or target range. [Figure 19B] Figure 19B shows an exemplary embodiment for banking time within a target or target range. [Figure 19C] Figure 19C shows an exemplary embodiment for banking time within a target or target range. [Figure 20A] Figure 20A is a flowchart illustrating an exemplary embodiment of a method for analyzing meals and food products. [Figure 20B] Figure 20B is a flowchart illustrating an exemplary embodiment of a method for analyzing meals and food products. [Figure 20C] Figure 20C is a flowchart of an exemplary embodiment of a method for analyzing meals and food products. [Figure 20D]Figure 20D is a flowchart illustrating an exemplary embodiment of a method for analyzing meals and food products. [Figure 21] Figure 21 is a flowchart of an exemplary embodiment of a method for displaying the counters for evaluated meals and foods. [Figure 22A] Figure 22A is a flowchart illustrating an exemplary embodiment of a method for providing food recommendations. [Figure 22B] Figure 22B is a flowchart illustrating an exemplary embodiment of a method for providing food recommendations. [Figure 23] Figure 23 is a flowchart illustrating an exemplary embodiment of a method for reassessing meal grades. [Modes for carrying out the invention]
[0021] Provided herein are exemplary embodiments of systems, devices, and methods for detecting, measuring, and classifying human diets in relation to the individual's analyte levels. Based on the collected analyte data, diet-related events and their impact on the individual's analyte levels can be further understood and used to modify future dietary choices and eating habits. Furthermore, insulin or other drug administration schedules can be adjusted based on the analyte response to a particular diet.
[0022] Before describing this subject in more detail, it is worthwhile to describe exemplary embodiments of systems, devices, and methods that can carry out this subject.
[0023] Numerous systems have been developed for the automated monitoring of analytes such as glucose in bodily fluids, including bloodstream, interstitial fluid ("ISF"), dermal fluid, or other biological fluids. Some of these systems are configured so that at least a portion of the sensors are placed beneath the user's skin surface, for example, within the user's blood vessels or subcutaneous tissue, to obtain information about at least one analyte in the body.
[0024] Therefore, these systems can be called "in vivo" monitoring systems. In vivo analyte monitoring systems include "continuous analyte monitoring" systems (or "continuous glucose monitoring" systems) that can transmit data from a sensor control device to a reader device continuously and automatically, for example, according to a schedule, without prompting. In vivo analyte monitoring systems also include "flash analyte monitoring" systems (or "flash glucose monitoring" systems or simply "flash" systems) that can transfer data from a sensor control device in response to data scanning by a reader device or on request, such as using Near Field Communication (NFC) or Radio Frequency Identification (RFID) protocols. In vivo analyte monitoring systems can also operate without requiring fingerstick calibration.
[0025] In vivo analyte monitoring systems can be distinguished from "in vitro" systems that come into contact with biological samples outside the body (more precisely, "ex vivo"), and typically include a weighing device having a port for receiving an analyte test strip carrying the user's bodily fluids (which can be analyzed to determine the user's blood glucose level). In many embodiments, monitoring is achieved in vivo, but embodiments disclosed herein can be used in conjunction with in vivo analyte monitoring systems that incorporate in vitro functionality, and also include purely in vitro or ex vivo analyte monitoring systems.
[0026] A sensor can be part of a sensor control device that resides on the user's body and houses an electronic device and power supply system that enables and controls the sensing of an object to be analyzed. Sensor control devices and their variations can also be called, to name a few, a "sensor control unit," an "on-body electronic device" device or unit, an "on-body" device or unit, or a "sensor data communication" device or unit.
[0027] In vivo monitoring systems may also include devices that receive analyte data sensed from sensor control devices, process and / or display that sensed analyte data in any number of forms, and present it to the user. These devices and variations may be called, to some extent, “reader devices” (or simply “readers”), “handheld electronic devices” (or “handhelds”), “portable data processing” devices or units, “data receivers”, “receiver” devices or units (or simply “receivers”), or “remote” devices or units. Other devices, such as personal computers, have also been used in or incorporated into in vivo and in vitro monitoring systems.
[0028] Embodiment of an in vivo monitoring system For illustrative purposes only, and not limiting, the graphical user interfaces and associated software described herein may be used in connection with an exemplary analyte monitoring system, such as the one shown in Figure 1. Figure 1 is an exemplary diagram showing an exemplary in vivo analyte monitoring system 100 in which any and / or all of the embodiments described herein may be used. The system 100 may have sensor control devices 102 and reader devices 120 communicating with each other via a local communication path (or link) 140, which may be wired or wireless and unidirectional or bidirectional. In embodiments where the local communication path 140 is wireless, any near-field communication (NFC) protocol, RFID protocol, Bluetooth or Bluetooth Low Energy protocol, Wi-Fi protocol, proprietary protocol, etc., may be used, including communication protocols existing as of the filing date or variants developed thereafter.
[0029] Bluetooth is a well-known, standardized short-range wireless communication protocol, and Bluetooth Low Energy is the same version but requires less power to operate. Bluetooth Low Energy (Bluetooth LE, BTLE, BLE) is also called Bluetooth Smart or Bluetooth Smart Ready. The BTLE version is described in the Bluetooth Specification, version 4.0, published on June 30, 2010, which is expressly incorporated herein by reference for all purposes. The term "NFC" applies to a number of protocols (or standards) that define the operating parameters, modulation schemes, encoding, transfer rates, frame formats, and command definitions of NFC devices. The following is a non-exhaustive list of examples of these protocols, each protocol (with all its sub-species) is expressed herein by reference for all purposes: ECMA-340, ECMA-352, ISO / IEC 14443, ISO / IEC 15693, ISO / IEC 16000-3, ISO / IEC 18092, and ISO / IEC 21481.
[0030] The reader device 120 is also capable of bidirectional or unidirectional wired, wireless, or composite communication with any or all of the drug delivery device 160 on communication path (or link) 143, the local computer system 170 on communication path (or link) 141, and the network 190 on communication path (or link) 142. The same wireless protocol described for link 140 may similarly be used for all or some of links 141, 142, and 143.
[0031] The reader device 120 can communicate with any number of entities via the network 190, which may be part of a telecommunications network such as a Wi-Fi network, a local area network (LAN), a wide area network (WAN), the Internet, or other data networks for unidirectional or bidirectional communication. The trusted computer system 180 can be accessed via the network 190. In an alternative embodiment, communication paths 141 and 142 may be the same path that includes the network 190 and / or additional networks. All communications on paths 140, 141, 142, and 143 may be encrypted, and the sensor control device 102, the reader device 120, the drug delivery device 160, the remote computer system 170, and the trusted computer system 180 may each be configured to encrypt and decrypt those communications transmitted and received.
[0032] Modifications of devices 102 and 120, as well as other components of in vivo-based analyte monitoring systems suitable for use with embodiments of the systems, devices, and methods provided herein, are described in U.S. Patent Publication No. 2011 / 0213225 (Publication 225), which is incorporated herein by reference in its entirety for all purposes.
[0033] The sensor control device 102 may include a housing 103 that houses an in vivo analyte monitoring circuit and a power supply (not shown). The in vivo analyte monitoring circuit may be electrically coupled to an analyte sensor 104 that extends through an adhesive patch 105 and can protrude away from the housing 103. The adhesive patch 105 contains an adhesive layer (not shown) for attachment to the skin surface of the user's body. Other forms of attachment to the body may be used in addition to, or instead of, the adhesive.
[0034] The sensor 104 is adapted to be inserted at least partially into the user's body, where it can come into fluid contact with the user's bodily fluids (e.g., interstitial fluid (ISF), skin fluid, or blood), and can be used, together with an in vivo analyte monitoring circuit, to measure the user's analyte-related data. Generally, the sensor control device 102 and its components can be applied to the body using a mechanical applicator 150 in one or more steps, as described in Publication No. 225 cited herein, or in any other desired manner.
[0035] After activation, the sensor control device 102 wirelessly transmits the collected analyte data (e.g., data corresponding to monitored analyte levels and / or monitored temperature data, and / or stored historical analyte-related data) to the reader device 120, where, in certain embodiments, the data can be algorithmically processed into data representing the user's analyte level, then displayed to the user, and / or otherwise incorporated into the diabetes monitoring regime.
[0036] Various embodiments disclosed herein relate to a reader device 120 which may have a user interface including one or more of the following: a display 122, a keyboard, an optional user interface component 121, etc. Here, the display 122 can output information to the user and / or receive input from the user (for example, if configured as a touchscreen). The reader device 120 may include one or more optional user interface components 121, such as buttons, actuators, touch-sensitive switches, capacitive switches, pressure-sensitive switches, jog wheels, etc. The reader device 120 may also include one or more data communication ports 123 for wired data communication with an external device, such as a local computer system 170. The reader device 120 may also include an integrated or attachable in vitro meter, including an in vitro test strip port (not shown) for receiving an in vitro analyte test strip for performing in vitro blood analyte measurements.
[0037] The drug delivery device 160 is capable of injecting or infusing drugs, such as insulin, into the body of an individual wearing the sensor control device 102. Similar to the reader device 120, the drug delivery device may include a processing circuit, non-temporary memory containing instructions executable by the processing circuit, a wireless or wired communication circuit, and a user interface including one or more of a display, touchscreen, keyboard, input buttons, or instrument. The drug delivery device 160 may include a drug reservoir, pump, infusion tube, and infusion cannula configured to be at least partially implanted in the user's body. The pump can deliver insulin from the reservoir through the tube and then through the cannula into the user's body. The drug delivery device 160 may include instructions executable by a processor for controlling the pump and the amount of insulin delivered. These instructions may also trigger calculations of insulin delivery volume and duration (e.g., bolus infusion and / or basal infusion profiles) based on analyte-level measurements obtained directly or indirectly from the sensor control device 102. Alternatively, the calculation of insulin delivery amount and duration, as well as the control of the pump, can also be performed directly by the reader device 120. The drug delivery device may be configured to communicate directly with the reader device 120 in the form of a closed-loop or semi-closed-loop system. Alternatively, the drug delivery device may include the functionality of the reader device 120 described herein, or vice versa, to obtain a single integrated reader and drug delivery device.
[0038] The computer system 170 may be a personal computer, laptop computer, tablet, or other suitable data processing device. The computer 170 may be local (e.g., accessible via a direct wired connection such as USB) or remote to the reader device 120 and may be (or include) software for data management and analysis and communication with components within the analyte monitoring system 100. The operation and use of the computer 170 are further described in Publication 225, which is incorporated herein by reference. The analyte monitoring system 100 may also be configured to operate with a data processing module (not shown), as described in Publication 225, which is incorporated by reference.
[0039] The trusted computer system 180 may be used to perform authentication of the sensor control device 102 and / or the reader device 120, to store sensitive data received from the devices 102 and / or 120, to output sensitive data to the devices 102 and / or 120, or may be configured in other ways. The trusted computer system 180 may include one or more computers, servers, networks, databases, etc. The trusted computer system 180 may be in the possession of the manufacturer or distributor of the sensor control device 102, either physically or virtually via a secure connection, or may be maintained and operated by a different party (e.g., a third party).
[0040] A trusted computer system 180 can be trusted in the sense that system 100 can assume that computer system 180 provides genuine data or information. A trusted computer system 180 can also be trusted simply because it is owned or controlled by a manufacturer, for example, a typical web server. Alternatively, a trusted computer system 180 can be implemented in a more secure way, such as requiring additional passwords, encryption, firewalls, or other security enhancements for internet access to further protect against forgery attacks or attacks by computer hackers.
[0041] Data processing and software execution within system 100 may be performed by one or more processors in the reader device 120, the computer system 170, and / or the sensor control device 102. For example, raw data measured by sensor 104 can be algorithmically processed into a value that represents the analyte level and is easily suitable for display to the user, which may occur in the sensor control device 102, the reader device 120, or the computer system 170. This information and any other information obtained from the raw data can be displayed (with respect to display 122) in any of the above-described manner on any display residing in either the sensor control device 102, the reader device 120, or the computer system 170. This information may be used by the user to determine any corrective actions necessary to ensure that the analyte level remains within acceptable and / or clinically safe ranges.
[0042] Figures 2A and 2B show exemplary embodiments of the reader device 120 and the sensor control device 102, respectively. As described above, the reader device 120 can be, for example, a mobile communication device such as a Wi-Fi or internet-enabled smartphone, tablet, or personal digital assistant (PDA). Examples of smartphones include, but are not limited to, mobile phones with network connectivity for data communication over the Internet or a local area network (LAN) based on the WINDOWS® operating system, ANDROID® operating system, IPHONE® operating system, PALM WEBOS®, BLACKBERRY® operating system, or SYMBIAN® operating system.
[0043] The reader device 120 may also be configured as a mobile smart wearable electronic assembly, such as an optical assembly (e.g., smart glasses or smart glasses such as GOOGLE GLASSES®) worn over or adjacent to the user's eyes. This optical assembly may have a transparent display that allows the user to see through the display while simultaneously displaying information (as described herein) about the user's analyte level, such that the user's overall field of view is minimally obstructed. The optical assembly may also be capable of wireless communication similar to that of a smartphone. Other examples of wearable electronic devices include devices worn around or near the user's wrist (e.g., a watch), neck (e.g., a necklace), head (e.g., a headband, a hat), chest, etc.
[0044] Figure 2A is a block diagram of an exemplary embodiment of a reader device 120 according to various embodiments disclosed herein. In this example, the reader device 120 is in the form of a smartphone, on which various software, applications, and graphical user interfaces disclosed herein may reside. Here, the reader device 120 includes an input component 121, a display 122, and processing hardware 206, the processing hardware 206 may include one or more processors, microprocessors, controllers, and / or microcontrollers, each of which may be a discrete chip or distributed among (and in part) a number of different chips. Here, the processing hardware 206 includes a communications processor 222 having onboard non-temporary memory 223, and an application processor 224 having onboard non-temporary memory 225. The reader device 120 further includes an RF transceiver 228 coupled with an RF antenna 229, memory 230, a multifunction circuit 232 having one or more associated antennas 234, a power supply 226, and a power management circuit 238. Figure 2A is a simplified diagram of the internal components of a smartphone, which may of course include other hardware and functions (e.g., codecs, drivers, glue logic, etc.).
[0045] The communication processor 222 interfaces with the RF transceiver 228 and performs analog-to-digital conversion, encoding and decoding, digital signal processing, and other functions to facilitate the conversion of voice, video, and data signals into a format suitable for provision to the RF transceiver 228 (e.g., in-phase and perpendicular-phase), so that the RF transceiver 228 can then wirelessly transmit the signals. The communication processor 222 can also interface with the RF transceiver 228 and perform the reverse functions necessary to receive wireless transmissions and convert them into digital data, voice, and video.
[0046] The application processor 224 can be adapted to run any software applications residing on the operating system and reader device 120 (e.g., any sensor interface application including SLL304 or analyte monitoring application), process video and graphics, and perform other functions unrelated to processing communications transmitted and received via the RF antenna 229. Any number of applications can run on the reader device 120 at all times, and typically would include one or more applications related to a diabetes monitoring regime, in addition to other commonly used applications unrelated to such a regime, such as email, calendar, weather, etc.
[0047] The memory 230 may be shared by one or more of the various functional units present within the reader device 120, or distributed among two or more of them (for example, as separate memories present on different chips). The memory 230 may also be a separate chip of its own. The memory 230 may be non-temporary and volatile memory (e.g., RAM, etc.) and / or non-volatile memory (e.g., ROM, flash memory, F-RAM, etc.).
[0048] The multifunction circuit 232 can be implemented as one or more chips and / or components that include communication circuits to perform other functions such as local wireless communication (e.g., Wi-Fi, Bluetooth, Bluetooth Low Energy) and geographic location determination of the reader device 120 (e.g., Global Positioning System (GPS) hardware). One or more other antennas 234 may be associated with the function circuit 232 as needed.
[0049] The power supply system 226 may include one or more batteries, which may be rechargeable or disposable. The power management circuit 238 can regulate battery charging and power supply system monitoring, boost power, perform DC conversion, etc. As mentioned above, the reader device 120 may also include one or more data communication ports, such as a USB port (or connector) or RS-232 port (or any other wired communication port) for data communication with a remote computer system 170 (see Figure 1) or a sensor control device 102, to name a few examples.
[0050] Figure 2B is a block schematic diagram showing an exemplary embodiment of a sensor control device 102 having an analyte sensor 104 and a sensor electronic device 250 (including an analyte monitoring circuit). While any number of chips can be used, here, the majority of the sensor electronic device 250 is integrated on a single semiconductor chip 251, which may be, for example, a custom application-specific integrated circuit (ASIC). Shown within the ASIC 251 are several high-level functional units, including an analog front-end (AFE) 252, a power management circuit 254, a processor 256, and a communication circuit 258 (which may be implemented as a transmitter, receiver, transceiver, passive circuit, or something else according to the communication protocol). In this embodiment shown in Figure 2B, both the AFE 252 and the processor 256 are used as the analyte monitoring circuit, but in other embodiments, either circuit may perform the analyte monitoring function. The processor 256 may include one or more processors, microprocessors, controllers, and / or microcontrollers.
[0051] Non-temporary memory 253 is also included within the ASIC 251 and can be shared by various functional units present within the ASIC 251, or distributed among two or more of those functional units. Memory 253 can be volatile memory and / or non-volatile memory. In this embodiment, the ASIC 251 is coupled to a power supply 260, which may be a coin cell battery, for example. The AFE 252 interfaces with the in vivo analyte sensor 104, receives measurement data from it, and outputs that data in digital format to the processor 256, which then processes the data to obtain the final results, such as discrete analyte values and trend values. This data can then be provided by the antenna 261 to the communication circuit 258 for transmission to a reader device 120 (not shown), where further processing may be performed, for example, by a sensor interface application. Note that the functional components of the ASIC 251 can also be distributed among two or more discrete semiconductor chips.
[0052] The execution of data processing functions within the electronic device of the sensor control device 102 provides the system 100 with the flexibility to schedule communication from the sensor control device 102 to the reader device 120, thereby limiting the number of unnecessary communications and providing further power savings in the sensor control device 102.
[0053] The information can be automatically and / or continuously communicated from the sensor control device 102 to the reader device 120 when the analyte information is available, or it can be stored or logged in the memory of the sensor control device 102 for later output, for example, without being automatically and / or continuously communicated.
[0054] Data can be transmitted from the sensor control device 102 to the reader device 120, either initiated by the sensor control device 102 or the reader device 120. For example, in many exemplary embodiments, the sensor control device 102 can periodically transmit data in a non-prompt manner so that a qualified reader device 120 can receive the transmitted data (e.g., sensed analyte data) if it is within range and listening. This is initiated by the sensor control device 102, as the reader device 120 does not need to send a request or other transmission prompting the sensor control device 102 to communicate first. Transmissions can be performed, for example, using an active Wi-Fi, Bluetooth, or BTLE connection, and can be performed according to a schedule programmed within the device 102 (e.g., every minute, every five minutes, every ten minutes, etc.). Transmissions can also be performed randomly or pseudo-randomly whenever the sensor control device 102 detects a change in the sensed analyte data. Furthermore, transmissions can be performed in a repeating manner, regardless of whether each transmission is actually received by the reader device 120.
[0055] System 100 may also be configured so that the reader device 120 sends a transmission prompting the sensor control device 102 to communicate its data to the reader device 120. This is commonly referred to as "on-demand" data transfer. On-demand data transfer can be initiated based on a schedule stored in the reader device 120's memory or at the user's request via the reader device 120's user interface. For example, if a user wants to check their analyte level, they can perform a scan of the sensor control device 102 using NFC, Bluetooth, BTLE, or Wi-Fi connectivity. Data exchange can be achieved using broadcast only, on-demand transfer only, or any combination thereof.
[0056] Therefore, when the sensor control device 102 is positioned on the body such that at least a portion of the sensor 104 is in contact with bodily fluids and is electrically coupled to an electronic device within the device 102, the sensor control device 102 can communicate sensor-derived analyte information to the reader device 120 on demand or in a non-prompt (broadcast) manner. On-demand transfer can be achieved by first powering on the reader device 120 (or it may be continuously powered on), and executing a software algorithm stored in and accessed from the memory of the reader device 120 to generate one or more requests, commands, control signals, or data packets to send to the sensor control device 102. For example, a software algorithm executed under the control of the processing hardware 206 of the reader device 120 may include a routine for detecting the position of the sensor control device 102 relative to the reader device 120 in order to initiate the transmission of the generated request commands, control signals, and / or data packets.
[0057] Embodiments linking analyte levels to dietary information In many embodiments, the subject matter described herein is implemented by a software application program stored in the memory of a processor-based device, such as one of the reader devices, drug delivery devices, or other computing devices described herein, and executed by the processor-based device. In certain embodiments, the software is implemented as one or more downloadable software applications ("apps") on a reader device, such as a mobile communication device or a smartphone.
[0058] The software may provide a mechanism for the user to define intakes (e.g., types of food, types of beverages, or parts thereof) in any way convenient to the user. These intakes will be generally referred to as meals or meals in this specification, and these terms will be used broadly to refer to all kinds of food and beverages.
[0059] This software can perform many functions related to the collection of dietary information and the association of that dietary information with analyte information collected by the in vivo analyte sensor 104 or by in vitro test strips and meters. This software will be referred to herein as the “Dietary Monitoring Application”.
[0060] A meal monitoring application may allow logging information (including photos of the meal) about each meal an individual has consumed (i.e., each "meal event"). The meal monitoring application can correlate analytic data from the same general period in time in which the user's log entries indicate that a meal was consumed.
[0061] The meal monitoring application can also monitor the user's analytic data and identify when the analytic data changes to indicate or suggest the occurrence of a potential meal event, and attempt to associate that potential meal event with meal information for the same period. The meal monitoring application can prompt the individual to confirm that a potential meal event has occurred and to provide information describing the meal event. If the individual has already entered meal information, the system can prompt the user for additional information about meal events that have not yet been entered. In some embodiments, if a meal is detected and the meal monitoring application determines that meal information has already been entered, the user may not be prompted.
[0062] The meal monitoring application can also associate measured analyte responses with each meal event, regardless of whether the analyte response is also classified as an analyte excursion or whether it includes an analyte excursion, and store the results in non-temporary memory or a database. The meal monitoring application can display each meal to the user along with its associated analyte (e.g., glucose or other analyte) response, for example, as a list sorted in descending order by the magnitude of the blood glucose response, using glucose as an example. The meal monitoring application can display other lists, for example, a list of "good" meals consisting of meals with a blood glucose response magnitude below a predefined magnitude and / or a list of "good" meals consisting of some meals with the lowest blood glucose response magnitudes among all recorded meals. Another example is a list of "bad" meals consisting of meals with a blood glucose response magnitude above a predefined magnitude and / or a list of "bad" meals consisting of some meals with the highest blood glucose response magnitudes among all recorded meals.
[0063] One exemplary embodiment of the magnitude of the glucose response is the peak glucose value detected from the postprandial glucose response. A method for determining this peak glucose measurement is further described herein. Another exemplary embodiment of the magnitude of the glucose response is the difference between the postprandial peak glucose value and the detected glucose value at the start of the meal.
[0064] In yet another exemplary embodiment, the magnitude of the glucose response can be determined in the form of an "area under the curve." The system can determine an area value with an upper limit set by a trace or curve along (or approximating) the glucose data values collected from the start of a detected meal, a) a certain period of time such as 6 hours, b) the start of the next detected meal, c) the time when the glucose trace falls below the value at the start of the meal, or thereafter. In one exemplary embodiment, the endpoint is the first occurrence of any of the preceding events (a-c). The lower limit of the area determination can be the glucose value at the start of the detected meal. The area can be calculated by summing the glucose values between the start and end (including or excluding the start and end values), multiplying this sum by the total time from start to end, and then subtracting the product of the glucose value at the start of the detected meal and the total time from start to end. Other similar magnitude indices along these lines can be implemented.
[0065] If a user repeatedly consumes the same or similar meals, a central glycemic trend (e.g., mean or median glycemic response) can be determined for that meal, and this central trend can be displayed. For example, if the peak of the glycemic response is a preferred indicator, when multiple identical meals are recorded by the system, the median of the peak values can represent the glycemic response indicator for this meal. Other forms of glucose response indicators, such as glucose traces or parametric fit to glucose traces, may be used. Alternatively, the glycemic response for all meals can also be displayed, regardless of whether each meal is the same or similar to another meal in the list or database. In yet another alternative embodiment, the meal monitoring application may generate a glycemic response as representative of all similar meals. For example, if the glycemic response is displayed as a trace, the trace representing all similar meals may consist of the median of the individual's glycemic response over all time intervals, where time is relative to the start of the meal.
[0066] Exemplary embodiments of the diet monitoring application may utilize analytic data analysis software or software-implementable processes such as those disclosed in, for example, U.S. Patent Publication No. 2013 / 0085358, No. 2014 / 0350369, No. 2014 / 0088393, No. 2017 / 0185748, No. 2020 / 0105397, or International Publication No. 2015 / 153482 or PCT / US20 / 12134, all of which are incorporated herein by reference for all purposes. Exemplary embodiments of this software are collectively referred to herein as “Diet Event Detectors.” A Diet Event Detector may be an algorithm, routine, or other set of instructions (part of or separate from the diet monitoring application) capable of detecting and / or quantifying the occurrence of actual or potential diet events in an individual’s monitored analytic data.
[0067] The detection of a meal event may include the detection of an analyte episode or excursion outside the desired acceptable (e.g., medically recommended) target range for the user, and the user may be notified by the software when one or both have been detected. Examples of analyte excursions include violations of the low glucose threshold, high glucose threshold, rate of change (e.g., increase or decrease) threshold, median glucose threshold, and glucose variability threshold.
[0068] Some of the meal event detectors described in these referenced literatures are described only in terms of identifying analyte excursions outside a desired target range. These embodiments can be extended to meal event detection based on teachings contained in others of these referenced literatures (e.g., International Publication No. 2015 / 153482). These embodiments can also be extended to meal event detection by designating in-target episodes in which glucose values are maintained between upper and lower limits for a certain period. Detection of these episodes can be performed by extensions of threshold-based episode detection algorithms.
[0069] A relatively simple example of threshold-based logic involves grouping all consecutive points above or below a threshold and associating them with a meal event, which may, in some cases, be or include, analytic excursions outside the user's target tolerance range.
[0070] Very short episodes (e.g., trends or groupings in analyte data, or outliers) may not be clinically relevant. Embodiments described herein can manage this challenge by requiring a minimum number of readings and / or a minimum duration and / or a minimum area outside the threshold (e.g., integral) to consider an episode for analysis as either a meal event or an analyte excursion. Episodes that do not meet either requirement may be ignored. Software displays and applications for providing upload prompt displays to individuals are disclosed in the cited document, U.S. Patent Publication 2014 / 0088393, which also discloses software applications for providing heuristic meal announcements that can be used herein for data analysis and display, as well as for meal selection.
[0071] A virtually infinite catalog of analyte episode types exists (e.g., analyte data generation with different characteristics), each of which can be used independently and clinically relevant to form the basis for diet reporting, diet effects, diet analysis, diet-based treatment, medication, and diet selection. Blood glucose response and episode characteristics can also be used to classify meals and ensure diet-related data collection. Such analyses and results can be presented to individuals, clinical diet supervisors, or physicians to make future dietary decisions.
[0072] Herein, Figure 3A is a flowchart illustrating an exemplary embodiment of Method 300 for collecting dietary information, correlating it with analyte data, and determining the effect of that diet on blood glucose levels. Method 300 includes operations that can be described as being performed by an electronic device such as a reader device 120, a drug delivery device 160, or a computer system 170 or 180, or their processors. The user may be an individual or a diabetic patient, a clinical manager, a healthcare professional, a dietitian, or someone else. For example only, Method 300 will be described with reference to a diabetic patient using dietary monitoring software as an app downloaded on a reader device 120 configured as a smartphone. For ease of explanation, the analyte monitored in this embodiment and in other embodiments described below will be glucose, but other analytes can be monitored as noted herein.
[0073] Referring to Figure 3A, meal events can be logged by the user in 302. The user can, at their discretion, input meal information directly (via the user interface) into the reader device 120 before, during, or after eating. In some embodiments, the user inputs meal information in response to reminders generated by the meal monitoring application, according to a predetermined schedule that can be set and / or modified by the user. Exemplary embodiments of the user interface for receiving manual logs by the user are described with reference to Figures 4A and 4B.
[0074] The user's analytic data is monitored in 304. This monitoring is, in most embodiments, a process that continues as long as the user is wearing the sensor control device 102 (e.g., a frequently repeated process, automatically, or at the user's discretion). The data collected by the sensor control device 102 can be transferred to the reader device 120 so that the meal monitoring application can access the data. Information indicating the time each analytic data measurement was collected (e.g., a timestamp) can also be transferred to the reader device 120. As already described herein, this data transfer can occur on demand (e.g., by performing a scan by the user), streaming, or in other regularly occurring manner. Analytic data collected by discrete blood glucose measurements (e.g., reading test strips with a meter) can also be entered into the reader device 120 manually or automatically.
[0075] The reader device 120 can algorithmically process the collected analyte data to determine whether a glucose excursion or meal event has occurred in 306. This can be done by using a meal event detector, such as those described herein, which examines the analyte data for one or more analyte values that violate a threshold or other condition indicating the occurrence of a glucose excursion or meal event. This algorithmic processing can also be repeated frequently whenever new analyte data is received from the sensor control device 102, for example, in response to an NFC scan of the reader device 120 or the sensor control device 102 by the user. Manual logging of meal information by the user (302) can be performed concurrently with the monitoring (304) and processing (306) of the analyte data. Those skilled in the art will understand that these methods can be implemented in a system in which analyte data is autonomously and wirelessly transmitted from the sensor control device to the reader at predetermined intervals.
[0076] Each time new data is sent to reader 120, the algorithmic processing may be applied to the new data, which may represent a multi-hour period (e.g., the past 8 hours) to detect a meal event. Steps 308-320 can be performed for each detected meal, starting with the most recently detected meal and repeating for each other detected meal event.
[0077] In some exemplary embodiments, a meal event detector may attempt to detect all meals in analyte data using one or more sets of predefined glucose rate of change (e.g., increase) settings. If the analyte data exceeds a rate of change threshold, such as a series of data points over a predetermined time range where the average increase in value from one point to the next exceeds the threshold, the analyte data can be characterized as a glucose excursion.
[0078] One particular problem that arises from the use of meal monitoring applications is that they may be too sensitive or not sensitive enough to analyte data suggesting the occurrence of meal events. This problem can lead to too many or too few meal events being identified.
[0079] In some embodiments, the settings used by the meal event detector to determine whether a potential meal event has occurred can be adjusted. For example, each setting or threshold used by the meal event detector can be individually configured by the user. In another embodiment, the meal monitoring software can provide the ability to scale the sensitivity of the settings by, for example, providing the user with the option to select one of several different settings, each having a different magnitude.
[0080] The meal monitoring software can set the “Medium” (or “Normal” or “Default”) mode as the default using a predetermined group of settings or settings entered by the user. The meal monitoring software can also provide options to switch to different modes, such as “Low” mode or “High” mode, in which the sensitivity or magnitude of the setting is scaled to be less or more likely to consider a particular span of analyte data for identification as a potential meal event, compared to “Medium” mode. “Low” mode and “High” mode can each be a direct percentage scaling of the “Medium” mode setting. For example, “Low” mode can use “Normal” mode settings adjusted by 5%, 10%, 15%, 20%, 25%, etc., to reduce the likelihood of detecting a meal event. Similarly, for example, “High” mode can use “Normal” mode settings adjusted by 5%, 10%, 15%, 20%, 25%, etc., to increase the likelihood of detecting a meal event. While three setting options have been described here, it is also possible to use two or more setting options. Furthermore, the meal monitoring software application can provide the user with the option to scale the sensitivity of the meal event detector in an analog or virtual analog manner (at least from the user's perspective), such as by using a slider bar on a touchscreen.
[0081] In some embodiments, the meal monitoring application is self-monitoring and optionally self-correcting, so as to be able to continuously or repeatedly monitor the sensitivity of the meal event detector against a desired baseline and notify the user to make adjustments if the sensitivity of the meal event detector appears to require adjustment, or so as to be able to automatically adjust without user input.
[0082] Figure 3B is a flowchart illustrating an exemplary embodiment of Method 330 for automatically adjusting the sensitivity of a meal event detector. Here, Method 330 can utilize a baseline integer or decimal value that represents the typical number of meals a user consumes daily. This baseline value can be set by the user or be a default value set within the meal monitoring application (e.g., 1, 2, 3, 4, 5, etc.). Method 330 can also utilize a variable integer or decimal value that can describe the typical variation in the number of meals a user consumes daily.
[0083] In this embodiment of Method 330, the meal monitoring application runs a meal event detector on analyte data from a past time range (e.g., N days, hours, minutes) using a first set of sensitivity settings (e.g., analyte data size threshold, duration threshold, rate of change threshold, or others) in 332. Here, Method 330 examines analyte data over the past N days, where N can be any desired value. Next, a determination is made in 334 as to whether the number of meal events detected over those N days is less than or equal to a maximum value, which in this embodiment is (baseline value + variation value) multiplied by N. In an example where N is 3, the baseline value is 3 meals / day, and the variation value is 1 meal / day, the determination in 334 would evaluate whether the number of meal events detected is 12 or less (e.g., the maximum value).
[0084] A determination that the number of meal events is greater than the maximum value indicates that the sensitivity setting of the meal event detector is too high. Therefore, the routine of method 330 proceeds to 336 where the sensitivity setting is reduced. The reduction in the sensitivity setting can be to the next lowest set after a given sensitivity setting, or by scaling factors such as 1%, 2%, 5%, 10%, etc. Next, in 338, the meal event detector is run on analyte data from a past time range using the new setting. Then, method 330 proceeds to make another determination in 334. This process can be repeated until the sensitivity setting is reduced sufficiently so as not to violate the conditions of 334.
[0085] If condition 334 is met (for example, the number of detected meal events is 12 or less), the routine proceeds to make a decision in 340 regarding whether the number of detected meal events is greater than or equal to a minimum value, which in this embodiment is (the number obtained by subtracting the variation value from the baseline value) multiplied by N. In an example where N is 3, the baseline value is 3 meals / day, and the variation value is 1 meal / day, the decision in 340 would evaluate whether the number of detected meal events is 6 or greater (for example, the minimum value).
[0086] A determination that the number of meal events is less than a minimum indicates that the setting sensitivity of the meal event detector is not sufficiently high. Therefore, the routine of method 330 proceeds to 342, where the sensitivity setting is increased. The increase in the sensitivity setting can be to the next highest set after a given sensitivity setting, or by scaling factors such as 1%, 2%, 5%, 10%, etc. The routine then proceeds to 338, where the meal event detector is run on analyte data from a past time range using the new setting. Method 330 then proceeds to 334 to make another determination, and this process can be repeated until the sensitivity setting is sufficiently adjusted so as not to violate the conditions of 334 and 340. Once the condition of 340 is met, the routine proceeds to 344, where the adjusted setting is considered appropriate and used in the subsequent normal operation of the meal event detector.
[0087] Method 330 can be repeated at regular intervals. In one exemplary embodiment, Method 330 is performed once a day using data from the past N days measured from midnight to midnight, in order to prevent the settings from being changed multiple times a day.
[0088] In another embodiment, the meal monitoring application can perform automatic sensitivity adjustment by analyzing the data to identify settings that are too high, regardless of whether the settings are too low. For example, a self-adjusting routine can iteratively evaluate whether each of several settings is below the maximum value by starting with the highest setting and determining whether the meal event detector outputs a number of detected meal events smaller than the maximum value using the highest setting, and if so, by using those highest settings for the subsequent normal operation of the meal event detector. If, as a result of the highest setting, the number of detected meal events exceeds the maximum value, the routine can proceed in an order decreasing in magnitude through each iteratively lower setting and stop when a setting is identified that does not exceed the maximum value. That identified setting can then be used for subsequent normal operation. In yet another embodiment, the meal monitoring application can perform automatic sensitivity adjustment in a similar but reverse manner to identify settings that are too low, regardless of whether the settings are too high.
[0089] Returning to Figure 3A, when a glucose excursion or meal event is detected in 306, in 308, the meal monitoring application evaluates whether meal information corresponding to the detected glucose excursion or meal event (collectively referred to as the “detected event”) has already been entered (e.g., by the user in 302). This evaluation can be performed by considering a certain period prior to the time the detected event occurred, and optionally a limited range later (e.g., to compensate for time retention or input inaccuracies), and checking whether any meal information was entered during that period. If so, the meal monitoring application can associate that meal information with the detected event in 314. If multiple entries of meal information are found, the meal monitoring application can either associate all of them with the detected event, or associate only the meal information that occurred most recently with the detected event.
[0090] If no meal information that can be associated with a detected event has been entered, the user is prompted in 310 to enter meal information. Exemplary embodiments of a user interface for prompting the user to log a meal or meal information are described with reference to Figures 4C-E. If no meal event has occurred, the user may refuse or ignore the prompt. Otherwise, meal information may be entered in 312.
[0091] The prompt can take the form of an alarm notification, such as a vibration or sound, that prompts the user to launch the meal monitoring application to acknowledge the prompt. Alternatively, the prompt may be a notification that appears the next time the user accesses the application.
[0092] Regardless of whether the user logs meal information at their own discretion (302) or in response to a prompt (310) (312), the meal information can include various levels of detail and can be entered in the same or similar manner.
[0093] A preferred aspect of the embodiments described herein is that it is easy to input dietary information so as to encourage the use of a dietary monitoring application to more intuitively understand the blood glucose effects of dietary intake, thereby also improving the user's health. Dietary information can be entered in any preferred way, for example, by manual text entry, by selecting a meal name from a list (e.g., a candidate list or a dropdown list), by selecting a meal image from a set of images, by selecting a recognizable indicator of the meal (e.g., a tag or code), or by any combination thereof.
[0094] Meal information may include the type of meal, for example, whether the meal is breakfast, lunch, snack, dinner, or dessert. Meal information may also include the time range in which the meal was consumed (e.g., start and end times). This may be an actual time (e.g., start time in hours:minutes), a generalized or heuristic portion of the day (e.g., early morning, late afternoon), or an approximate time range with any desired level of detail (e.g., 10 minutes, 15 minutes, 30 minutes, 60 minutes, etc.) (e.g., 6-7 a.m., 5-6 p.m., etc.).
[0095] Dietary information can also include the content and quantity of the meal. For example, a meal can be described by including the calorie content, protein, carbohydrates, dairy products, meat, grains, vegetables, nuts, sugars, alcohol or other beverages, along with the respective amounts or sizes of each component. This can be done part by part, for example, one serving of bread with one serving of peanut butter, where each part is associated with its respective amounts of carbohydrates, sugars, protein, etc. Alternatively, a meal may be described solely on a nutritional category basis, for example, 10 grams of carbohydrates, 5 grams of sugars, 8 grams of protein, etc. Heuristic categories (e.g., small portion, medium portion, large portion), in contrast to quantitative categories, can also be used to facilitate data entry.
[0096] To further facilitate the input of meal information, a meal monitoring application can present the user with options to select meals or information related to meals. For example, meals or meal information can be presented to the user in the form of a list or array of items, from which the user can select the most appropriate input describing the meals they have consumed.
[0097] In some embodiments, a user can create a list or sequence of common meals consumed by the user (and / or related information) for use in the meal monitoring application by directly entering a list into the application, by selecting from a list of pre-programmed options in the meal monitoring application, or by creating a list on a separate computing platform and uploading it to the host device on which the meal monitoring application is running. Intakes can be added or removed at any time. As discussed herein, this data entry can be performed using a graphical user interface on the host device.
[0098] A meal monitoring application can be programmed to store information about all past meals a user has consumed and related meal information. This information can be presented to the user as options that they can select to identify a particular meal or aspect of a meal that was consumed more recently. For example, when a user is prompted to enter meal information, the meal monitoring application can present a list of options that the user can select. This list can be ordered so that the most commonly consumed or selected meals are presented first or at the top of the list, and the remaining meals are presented in descending order of consumption frequency (e.g., the most commonly consumed meal is presented first, the second most commonly consumed meal next, and so on, with the least commonly consumed meals presented last).
[0099] Users often need to adjust their selected meals to suit their needs at any given time. Therefore, for any selected meal, users are given the option to customize aspects of that meal, such as adding, removing, or substituting specific side dishes (e.g., using broccoli instead of peas), or modifying beverages, portion sizes, or calorie or carbohydrate content. In all instances where a user inputs information about a selected meal, a similar approach can be taken, where the user is provided with a list of selectable options, presented in descending order of relevance. For example, if a specific type of food is selected, the user may be presented with the amount of that food they have consumed in the past. This can also be done in descending order based on consumption frequency. For instance, if chicken breast is selected as part of a meal, the meal monitoring application can present the portion sizes to select in descending order of consumption frequency (e.g., 8 ounces (approx. 227g), 10 ounces (approx. 283g), 6 ounces (approx. 170g)) based on the user's past history stored on the device. Alternatively, the list may be presented in ascending order of quantity (from least to most) or descending order (from most to least). The same applies, for example, to the amount of carbohydrates, sugars, protein, and any other aspect of the dietary information described herein.
[0100] In this way, following the selection of a specific meal, information about each type of food and beverage within that meal can be entered, and the most relevant options can be presented first using the user's history. Of course, if no customization is needed, the user can end the data entry process after the initial selection of the meal itself without specifying any further variations such as portion sizes.
[0101] A meal monitoring application can be programmed to filter the presented options based on time period. For example, if a user is prompted to enter information about meals consumed during the morning, the meal monitoring application can present a list of commonly consumed breakfast meals and / or morning snacks (in descending order of frequency of consumption) to the user, providing only the most relevant options available (e.g., dinner being excluded). Similarly, if information about meals consumed during the day is entered, only the most commonly consumed lunch and / or afternoon snacks can be presented, and if information about meals consumed late in the day or in the evening, only the most commonly consumed dinner, dessert, and / or nighttime snacks can be presented.
[0102] The meal monitoring application can also be programmed to filter the presentation of options based on the characteristics of the detected event (e.g., the magnitude and / or duration of a glucose excursion or meal event) and / or the correlation between the detected event and past meals associated with the detected event that have similar characteristics. For example, the meal monitoring application may have local access (e.g., stored in local memory) or remote access (e.g., by downloading from a server) to the user's glucose levels over a period of time, e.g., over a period of time, such as a day, week, month, etc., as well as to meal information entered into system 100 over the same or similar period of time.
[0103] When a meal event is detected, the meal monitoring application can identify past detected events that have the same or similar characteristics in the analyte data. This can be done by referring to a correlation database stored locally or remotely for the meal monitoring application within System 100. When the user is prompted to enter meal information based on the detected event, the meal monitoring application can present meal options for selection based on the correlation between the analyte data of the recently detected event and the analyte data of past detected events that already have associated meal information. Time information can also be used in the correlation. For example, if a hypoglycemic event is detected in the evening, and past detected hypoglycemic events occurring in the evening have been previously associated with a particular high-carbohydrate meal (e.g., a spaghetti dinner), the user can be presented with that particular high-carbohydrate meal as the first option to select, followed by other options in order of decreasing potential relevance.
[0104] In other embodiments, when a meal event is detected, a list of all previous meals may be displayed to the user (or accessible, for example, by a virtual selectable button labeled “Previous Meals”). The user may be allowed to select one meal as corresponding to the detected meal event. The list of all previous meals can be sorted by the frequency of past selections of that meal and / or by the magnitude or severity of the glucose response to that meal (this can be the mean or median if the meal has been consumed multiple times in the past). The list can be ordered in several ways, but a preferred embodiment is to order first by the most frequently selected meals, and then by the most recent meals. Each meal can be associated with a unique identification code. Meal names entered by the user that are not identical but similar to each other can be assigned the same code. If the same meal is entered and selected more than once, its unique identification code is stored multiple times, associated with different times of the same meal. When displayed on a list sorted by the magnitude of the glucose response, the meal monitoring application can detect when a meal has been repeated by detecting that they have the same unique code. The meal monitoring application can create a list of all glucose responses for each repeated meal, determine the mean or median of these responses, and associate this with a unique code. Once this is done for all unique codes, a final list for display can be generated for all unique meals, including meals entered only once and those entered repeatedly, and the list can be sorted by the magnitude of the glucose response associated with each unique code.
[0105] If a user selects a meal event associated with an undesirable blood glucose response, a real-time notification can be generated and output to the user, warning them about the potential blood glucose impact of the meal they just ate.
[0106] Such real-time feedback (i.e., feedback returned immediately from the user's perspective) can help users internalize the undesirable effects of the meals they have consumed. For example, if the detected meal event is a dinner meal, the real-time notification could display the average blood glucose response of all other meals of that type (dinner), along with a display of the average blood glucose response and difference for the most recently consumed meal type (e.g., the most recently consumed meal has a typical blood glucose response that is 20% higher than the average blood glucose response of all other dinners). The real-time notification could also warn the user to reduce the amount of food they eat or to take counteracting medications such as insulin.
[0107] In one exemplary embodiment, the notification may include a graphical representation of the user's current analyte data overlaid with the average of all past blood glucose responses for that meal type, on a graph of current analyte data synchronized with the meal start time. Such an example is shown in Figure 3C, where trace 343 of the user's current analyte data is displayed over time. The meal start time is indicated by 344, and the last collected analyte measurement is indicated by 345. If a meal type associated with one or more undesirable past blood glucose responses is selected, the graph in Figure 3C may display an overlaid trace 346 representing the user's average blood glucose response for all past intakes of that meal type (or all past times when an undesirable excursion occurred with that meal type). The start of the overlaid trace 346 can be aligned with the analyte data at meal start time 344. Thus, the user is given real-time visual feedback about the possible consequences of consuming that problematic food. Alternatively, multiple traces may be overlaid, where each trace represents a single past excursion from an intake of that meal type.
[0108] Alternative outputs include reports available from menus provided by the diet monitoring application. Examples of reports include lists of harmful meals (e.g., a "bad meals" list) and lists of beneficial meals (e.g., a "good meals" list). The bad meals list may be a list of previous meals sorted in descending order of glucose response magnitude, while the good meals list may be a list of previous meals sorted in ascending order of glucose response magnitude. The lists may be further modified, for example, by including only meals exceeding a predetermined or user-defined threshold for glucose response magnitude in the bad meals list. The good meals list may include only meals below a predetermined or user-defined threshold for glucose response magnitude. Additionally, symbols may be used to identify meals as good, bad, or neutral, as described above, in the list of previous meals used for selection when entering dietary information. Good and bad meals may be identified in other ways, such as by including them in their respective sublists, with respect to this selection list.
[0109] Furthermore, the application can provide reports and periodic notifications that continuously track the amount of good and bad meals consumed over a set period, such as one or two weeks. For example, each time a user selects this report, the meal monitoring application can count the number of good and bad meals and display the results. In addition, the application can provide a user interface that allows the user or healthcare provider to set a target for the maximum number of bad meals consumed over a set period. The report display can show the current number of bad meals next to the target. Alternatively, the application can also generate periodic notifications regarding these metrics, where the period is, for example, weekly.
[0110] The application can process new data (whenever available, either automatically or manually queried) to detect meals, measure the glucose response to detected meals, and perform meal execution calculations. Alternatively, the application can determine when a glucose response is needed for analysis or reporting; that is, the glucose response is retrieved from memory but recalculated as needed. For example, if the weekly execution calculation for unhealthy meals exceeds (or falls below) a threshold, a notification can be generated to indicate to the user that their eating habits have deteriorated (or to celebrate achieving the goal). The notification may take the form of a standard lock screen notification on Android and iOS phones, or it may be presented in a specific display area of a common application screen, such as the home screen or glucose results screen.
[0111] Users can input a photo or image of a meal. This image can be input to supplement other information entered to describe the meal. Alternatively, this image can constitute the entire description of the meal and its contents. This streamlined data entry makes data entry much easier when users log meals or respond to prompts, thereby encouraging the use of meal monitoring applications. If an image is input, it can be presented with or instead of a textual description of the meal and / or its contents, and the user only needs to recognize the image in a list of options presented to the user for data entry. Thus, when a user is presented with options to identify a meal in response to event detection, these options can be presented in text form only, in icon form only, in image form only, or in a combination of text, icons, and / or images.
[0112] In some embodiments, images of meals can be analyzed using image recognition techniques to identify meal attributes, such as recognizable components of the meal. Meal components can be recognized using a meal component recognition algorithm based on spectral boundaries defined within the image. Once recognized, the meal image can be named by a meal monitoring application that describes the contents of the meal; for example, an image of chicken and broccoli might be labeled "chicken and broccoli." The meal monitoring application can then provide the user with options to specify further information about the particular type of meal detected from the image, such as portion size and nutritional content. The meal can also be linked to past instances in the user's meal history where the same type of meal occurred, which can be used to correlate detected events with specific types of meals.
[0113] Figures 4A–E illustrate exemplary embodiments of the visual arrangement or screens of a graphical user interface (GUI). These screens may be displayed in any of the embodiments of the reader device 120, drug delivery device 160, or local computer system 170 described herein.
[0114] Figure 4A shows an exemplary embodiment of a screen 402 for logging meals and related meal information, such as that used in 302 of Method 300 (see Figure 3A). Screen 402 may include displays 404 and 406 of analyte levels determined from data received from an analyte sensor 104 (not shown). Display 404 is a numerical display (e.g., mg / dL) of the user's current or last received analyte level. Display 406 is a graphical display showing a trace or curve of the user's analyte level (y-axis) against time (x-axis), aligned with a shaded area 407 indicating a normal or desired analyte level range. Such a display 406 can show data over any desired period (e.g., 8 hours or other periods).
[0115] Screen 402 may include visual indicators to show various attributes of the data. For example, graphical display 406 may include an indicator or marker 408 that highlights the data or is otherwise highlighted. Here, indicator 408 indicates a glucose rate of change exceeding a desired maximum rate of change, e.g., a sharp rise over time (or a sharp fall in other embodiments) of the analyte data. Specifically, indicator 408 is a highlighted area below the analyte level curve that corresponds in time to the occurrence of a sharp rise. Thus, the observer can more easily understand whether a recent event or excursion has occurred and what its nature is.
[0116] Screen 402 can be the home screen of the meal monitoring application, or it can be accessed from the home screen or another higher-level page. Here, screen 402 is accessed from the home screen and includes a selectable home screen back button 410 to return there, which can also redirect back to another higher-level page.
[0117] Screen 402 also includes a selectable meal log button or field 412. Selecting the meal log button 412 can lead the user to screen 420 shown in Figure 4B. If the device on which the meal monitoring application is running includes a camera, screen 420 may include a selectable photo capture or select button or field 422. Selecting this opens a camera application that accesses the device's camera and captures a photo or image of the meal for saving and associating with it. Selecting button 422 can also give the user the option to select a photo from a gallery of photos previously used to log meals, or from a gallery of photos stored in the device's general photo gallery. If the user captures a photo of the meal or chooses another method, that photo may be displayed on screen 420. In some embodiments, selecting the meal log button 412 in Figure 4A can cause the meal monitoring application to immediately open the device camera application to allow the user to take a photo, thereby further streamlining the image input process.
[0118] Furthermore, screen 420 includes a text-format entry field 424 for the user to enter free-text information describing a meal. Selecting this field 424 opens a text editor that can be used to enter text information about the meal. This information can be associated with the meal along with a photograph and can form part of a data structure representing the meal. Although not shown here, screen 420 may also include a candidate list or dropdown list that the user can select from a list of previously saved options about a meal or information about a meal, as will be described in detail herein.
[0119] While not all variations are shown, it is recognized that all aspects of meal information described herein, including but not limited to inputting meal time information, meal portion information, nutritional components, and representative meal icons, can be entered via one or more screens similar to those described with respect to Figures 4A and 4B.
[0120] After meal information is entered as either a photograph, a text description, or a selection of a predetermined option, the user can select the save button or field 426 to save the data to memory as a data structure that is associated with and digitally describes the meal.
[0121] Figures 4C–E show exemplary embodiments of screens 428 and 430 for prompting the user to enter diet and related dietary information, for example, as used in 310 of Method 300 (see Figure 3A). Similar to screen 402 in Figure 4A, screens 428 and 430 may include displays 404 and 406 of analyte levels determined from data received from an analyte sensor 104 (not shown). Also similar to screen 402, indicator 408 indicates a glucose rate of change exceeding a desired maximum rate of change, e.g., a sharp rise (or, in other embodiments, a sharp fall) over time in the analyte data. Specifically, indicator 408 is a highlighted region below the analyte level curve that corresponds in time to the occurrence of a sharp rise.
[0122] This sharp increase may be a glucose excursion or meal event detected in 306 of method 300 (see Figure 3A), which can trigger a prompt to the user to enter meal information in 310. Screen 428 in Figure 4C is an example of the home screen of the meal monitoring application. Here, when an excursion or event is detected, the home screen displays a pop-up window 429 that overlays the home screen to notify the user that one or more possible meals have been detected and optionally provides the time each of those meals was detected. The pop-up window 429 includes selectable fields that the user can choose to log meals for each period corresponding to the detected excursion or event, and may also include selectable fields that the user can choose to ignore the notification in window 429. Here, screen 428 includes a graphical display of the user's analyte-level history 406 with indicators 408 for each detected glucose excursion or meal event. When the pop-up screen 429 is displayed, corresponding detected events for which meal information has not yet been entered can be graphically identified or distinguished from events for which meal information has already been entered or events for which meal information is not requested.
[0123] In an alternative embodiment, upon detection of a glucose excursion or meal event, the meal monitoring application may initiate or display screen 430 in Figure 4D to allow the user to identify the detected event (at least partially by indicator 408) and prompt the user to enter meal information via a selectable event detection button or field 412. Alternatively, the meal monitoring application may also display the event detection button 412 on another screen currently displayed to the user. The event detection button 412 may also be labeled as a meal detection button.
[0124] By selecting the option to log meals on the pop-up screen 429 or by selecting the event detection button 412, the meal monitoring application can be transitioned to screen 420 of Figure 4B, reproduced as Figure 4E for ease of explanation. There, as in the exemplary embodiments described with respect to Figures 4A and 4B, the user can enter meal information in photographic form via button 422 and / or in text format via the free text field 424, and save that information via button 426. Since meal event detection occurs after meal consumption, the user may choose to photograph the meal packaging or scan the barcode on the meal packaging instead of photographing the meal itself. All variations of the meal information input process described with respect to Figures 4A and 4B (including, but not limited to, variations of candidate lists and drop-down lists), including all variations of the meal information input process described herein but not shown in Figures 4A and 4B, can also be applied here.
[0125] If a user logs meals at their own discretion, for example using screen 420 in Figure 4B, the meal monitoring application can request the user to describe the time the meal was taken in one of the formats described herein. Once the meal monitoring application detects an event, it can already access the time information for that event. Therefore, if the user is prompted to enter information about a meal event, for example by accessing screen 420 using screen 430, the determined time information can be displayed to the user so that the user has the option to edit the time information if it is inaccurate. If an increase in analyte data is used to detect a meal event, the time when the increase episode begins can be the meal time displayed by default, as described herein, to compensate for sensor and digestion-based lags.
[0126] In some exemplary embodiments, the data entry process is streamlined to further minimize the burden on the user when entering data. The less burdensome it is, the more likely the user is to use the meal monitoring application and, consequently, to enjoy its benefits. In one exemplary embodiment, the meal monitoring application may be configured not to proactively prompt the user for any nutritional information about the meal or the type of meal (e.g., breakfast, lunch, or dinner) when it receives a log entry from the user (e.g., step 302 of Method 300) and / or information from the user in response to a prompt for meal information (e.g., step 310 of Method 300). In another exemplary embodiment, the meal monitoring application may be configured not to allow the user to enter any other information about the meal when it receives a log entry from the user and / or information from the user in response to a prompt, but only to accept an image of the meal and / or a free-text description of the meal.
[0127] Returning to Figure 3A, once meal event information is entered at 312, the meal monitoring application will associate analyte data with that meal information in memory at 314. Specifically, analyte data occurring around the time of the meal event can be associated with the information of that meal event. The analyte data selected to be associated with a meal event can be selected based on the time the meal event occurred and optionally a certain period prior to the meal event, in order to reflect the changes in analyte levels due to the digestion of the meal.
[0128] In some embodiments, analyte data generated from the start of a meal to a certain period after the meal has stopped can be associated with a meal event. Alternatively, analyte data generated from the start of a meal to the end of a detected glucose excursion can be associated with a meal event. In some embodiments, analyte data collected within a fixed time range around a meal event can be associated with the meal event, for example, any combination from 1, 2, or 3 hours before the meal event (e.g., measured by the start of the meal event, the midpoint of the meal event, or the end of the meal event) to 1, 2, 3, 4, 5, 6, 7, or 8 hours after the meal event. In each case, the time during which the meal event occurred can be identified based on user-entered information or algorithmically through analysis of the analyte data.
[0129] Data collected from the analyte sensor 104 may have a time lag compared to the user's actual blood glucose level, for example, if the sensor 104 senses data from the user's interstitial fluid and, to a lesser extent, from skin fluid. Therefore, this sensor-based lag must be taken into account when correlating analyte data with meal intake time, which can typically be on the order of 3 to 20 minutes depending on the type of fluid and sensor placement. This lag is added to the lag time due to the absorption of food by the digestive process. In other words, there is a time difference between the time food is ingested and the time when the results of that ingestion are reflected in the user's blood glucose level. Therefore, in some embodiments, analyte data associated with meal events are selected as described above, with further compensation for digestive lag and / or sensor-based lag. For example, the first analyte data point associated with a meal event is based on the start of that meal event but may be delayed by 10 minutes (5 minutes to compensate for digestive lag + 5 minutes to compensate for sensor-based lag).
[0130] The association between analyte data and meal events can be used in determining the glycemic effect of the meal event in 316. In some embodiments, the determination of the glycemic effect of a meal event can be algorithmically performed by referring to analyte data from the same period as the meal event, and this algorithmic processing may constitute both steps 314 and 316. The determined glycemic effect can be quantitatively determined in terms of maximum (peak) or minimum glucose level, median or mean glucose level, minimum-to-maximum change in glucose level (delta (Δ) glucose value), percentage change in glucose level, duration of glucose response, rate of change in glucose level, area of glucose response, and any combination thereof.
[0131] A meal event detector can output information about the blood glucose response to a meal and can be used to characterize the magnitude or severity of the response. For example, a meal event detector can output the start time and peak time for each detected meal event. The meal start glucose can be the glucose value at the start time of the meal event, and the peak glucose can be the glucose value when the elevated episode of the detected meal event reached its peak. The difference between these glucose values can be determined to provide a delta glucose measure of the blood glucose response to the meal.
[0132] In other embodiments, the “area” of the glucose response is determined in terms of glucose and time; for example, since it can be difficult to accurately assess where the glucose response ends, the sum or integral of each glucose reading is determined from the meal start time to either a) the next meal start time, or b) when the glucose reading falls within the threshold of the meal start glucose value (e.g., within 10 mg / dL). This sum or integral is proportional to the glucose multiplied by the time area of the glucose response. Each of the indicators described herein, as with others, can be used as a basis for ranking and / or sorting the glucose response to meal output to the user, as described below.
[0133] Another problem that arises particularly from the use of meal monitoring and detection software is that, in some cases, multiple meal events may be detected and / or logged in close proximity to each other in time. From the user's perspective, this can result in too many meal events being identified when they were part of the same meal.
[0134] In these cases, the meal monitoring application can cluster or group meal events into a single meal cluster. For example, meal events logged or detected within each other's time range conditions (e.g., 1 hour, 90 minutes, etc.) can be merged into a single meal cluster. The meal monitoring application can then analyze and output to the user the blood glucose response data describing the meal cluster as a whole, separately from each individual event within it, with the intention of corresponding to the user's concept of meals (for example, dinner may be one cluster of different courses). Thus, each meal event or meal cluster that is analyzed and displayed to the user is separated by at least the value of the time range condition, which can result in a more understandable and natural information output. To facilitate this, the meal monitoring application can avoid limiting the number of meal events considered per day.
[0135] Figure 3D is an annotated graph 350 of analyte data over time, displaying an exemplary dataset of four different meal events (352-1, 352-2, 352-3, and 352-4) that were automatically detected or manually logged. These four different meal events are considered a single meal cluster 354 because each event 352 falls within a time range condition that can be a predetermined factory-configured condition or a user-configured condition. In this example, the time range condition is one hour, and all four events 352 are grouped together because each individual event 352 is within one hour of at least one other event 352.
[0136] In some embodiments, a maximum time limit can be placed on the amount of time from the first event 352 for which the meal monitoring application considers other events for clustering. For example, the time range condition could be 1 hour with a maximum meal cluster length (not shown) of 90 minutes from the first event 352-1, in which case meal events 352-1, 352-2, and 352-3 would be grouped as one meal cluster, and meal event 352-4 would be considered a separate meal event from the cluster.
[0137] As described herein, the time of a meal event may be the time entered by the user in the manual logging process, the time when the analytic episode corresponding to the meal event is first detected (e.g., the start of the rise), the time with a delay added to the time when the analytic episode corresponding to the meal event is first detected (e.g., 15 minutes, 25 minutes), the average or median time determined from the duration of the analytic episode (e.g., the average time from the start to the end of the rise or the median time of the data measurements collected during the rise), or any other desired time.
[0138] In some embodiments, multiple different meal event detectors based on different algorithms can be used. Each individual meal event detector routine can be run independently on the collected analyte data to identify detected meal events and / or their start times. The meal monitoring application can then select which results to use for analysis and display to the user. For example, if each meal event detector outputs different start times for the same meal event, the meal monitoring application can average the two and use the averaged meal start time for analysis and display. In another example, the meal monitoring application may consider an event to have been detected only if each meal event detector actually detected the event. In yet another example, the meal monitoring application may consider an event to have been detected if at least one meal event detector actually detected the event.
[0139] In the example shown in Figure 3D, the pre-meal or meal start glucose value 356 could be the glucose value at the start of the first meal event 352-1 in meal cluster 354. If necessary, this value can be obtained from a data measurement occurring at the time closest to before or after the time of meal event 352-1. If no data measurement is present within a maximum time range, such as 30 minutes, the meal monitoring application may consider the pre-meal glucose value unknown.
[0140] The meal peak glucose value may be the highest glucose value occurring in the analyte data collected during or after meal cluster 354. The meal peak glucose time range 358 indicates an exemplary time range window searched for the occurrence of the highest glucose value. The time range 358 may begin at the time of the first meal event 352-1 and end at the time of the last meal event 352-4, or more likely, end at a predetermined time after the last meal event 352-4. In the embodiment shown in Figure 3D, the time range 358 begins at the time of the first meal event 352-1 and ends 2 hours after the last meal event 352-4. Thus, the meal peak glucose value would be the magnitude of the value in region 360 where the analyte data reaches a peak and maintains a constant level. If no reading is present in window 358, the meal peak glucose value may be considered unknown.
[0141] The dietary delta glucose value can be determined by subtracting the pre-meal glucose value from the dietary peak glucose value. If one or both of these values are unknown, the dietary delta glucose value may be considered unknown.
[0142] Returning to Figure 3A, the determined blood glucose response or effect can then be visually output to the user, such as on a smartphone display, as described below with respect to Figures 5A-F, in 318. In many embodiments, this is done immediately along with the presentation of information about the corresponding meal event, so that the user can immediately understand the effect of a particular meal on the user's analyte level, making the use of the application compelling. The determined blood glucose response can be output in quantitative and / or qualitative terms. For example, the determined blood glucose response can be output on the same quantitative scale as determined in 316. This can be done in text format and / or graph format. Alternatively, the determined blood glucose response can be output qualitatively, for example, in text, as low or small, moderate or moderate, or high or severe, or any synonym therefor. A size grade of small or large can also be used. The determined blood glucose response can also, or alternatively, be output as an icon or other image (e.g., a colored shape of varying sizes).
[0143] System 100 may also (or alternatively) issue a medication or other treatment output at 320. In certain embodiments, the output may inform an individual, such as a user or healthcare professional, that medication (e.g., insulin) or treatment may be prescribed, for example, due to the risk or occurrence of high glucose excursion or hyperglycemia. This notification may be a visual and / or auditory notification output by reader device 120.
[0144] The output issued by 320 can directly supply information to the user's medication or treatment program on the same or a different device that is communicating with the device running the meal monitoring application. This information can be used by the treatment program to determine whether changes to the user's treatment profile (e.g., basal insulin delivery schedule or bolus administration) are guaranteed, or to prompt the user about whether changes to the user's treatment profile should be implemented.
[0145] The output issued by 320 can cause the user's drug delivery device 160 to administer a drug to address a potential or actual high glucose state, such as through a bolus dose or by changing the basal drug profile or schedule. This can be done with user approval, like a semi-closed loop, or automatically without user approval, like a true closed loop or artificial pancreas.
[0146] The meal monitoring application can also issue one of the aforementioned medication or action outputs when the user indicates that the meal is one that has caused glucose excursions in the past, such as a sharp rise or high glucose levels, or that it has been consumed recently. In this way, system 100 can proactively address anticipated glucose changes without waiting for actual changes to be detected by sensor 104.
[0147] Outputting information from a meal monitoring application to a medication or treatment program and / or drug delivery device improves the program or device's ability to deliver accurate treatment for the user. More accurate information about the user's dietary history is obtained and available to the program or device, allowing for appropriate, and sometimes subtle, adjustments to the user's treatment. This itself can reduce the occurrence of errors in drug administration (e.g., overdosing or underdosing) and constitutes an improvement to the functionality of electronic and mechanical systems with drug delivery capabilities.
[0148] Figures 5A–F show exemplary embodiments of GUI screens that can display output information to the user or any other individual in step 318 of Method 300 (see Figure 3A) or at other times while using the meal monitoring application. These screens may be displayed on any of the embodiments of the reader device 120, drug delivery device 160, or local computer system 170 described herein.
[0149] Figure 5A shows screen 502 containing a series, list, or group of logged meals 505-1 to 505-N. Group 500 is commonly referred to herein as the ranking report 500. The ranking report 500 shows all or a subset of meal events 505 (and activities, if applicable) for which data has been collected. If meal clusters are identified, meal events within a cluster are grouped together and displayed as a single meal event 505. The ranking of events 505 can be ordered by the magnitude of the glycemic response. When presented to a user, the ranking report 500 may start from the top of the list, first showing the meals 505 that resulted in the largest glycemic response, followed by the meals 505 that resulted in decreasing glycemic responses.
[0150] In another embodiment, the ranking report 500 can display the most recent meals that caused glucose excursions, and the user can scroll (up or down) through a list that is again sorted from the largest to the smallest glucose excursion magnitude. In yet another embodiment, the ranking report 500 can display meals that caused glucose excursions in order from the most recent to the oldest. A toggle sort button can be provided to allow the user to change the criteria by which the ranking of the report 500 is determined (e.g., changing the ranking by meal type, date and time, glucose excursion magnitude, etc.).
[0151] In the embodiment shown in Figure 5A, for each meal 505 in the ranking report 500, an image of the meal may be displayed, if available, along with the date and time the meal was consumed, and an indication of the magnitude of the glucose response, which may be presented in any of the output formats described herein. Instead of, or in addition to, an image, the name of each meal 505 may be described in text format. In addition to ranking meals by their glucose response, the ranking report 500 may also rank the occurrence of a single specific type of meal by its glucose response. For example, the quantity, duration, and glucose response to a commonly consumed spaghetti dinner may be ranked and displayed.
[0152] If a glucose excursion occurs but meal information is not entered, the time, date, and size of the glucose excursion can be displayed in report 500 along with a selectable button or field that prompts the user to enter meal information, such as displaying screen 420 in Figure 4B when selected. If meal information is available but there is no photo, a photo missing indicator can be displayed so that the date and / or time are aligned with other items in report 500.
[0153] If the meal event detection sensitivity setting or glucose excursion sensitivity setting is adjusted while using the meal monitoring application, the data displayed in Ranking Report 500 can be retrospectively adjusted so that all data is displayed in a single common item array of the sensitivity setting. Therefore, each time the user views Ranking Report 500 or otherwise views past meal or analyte information, the meal monitoring application can recalculate the displayed information to retrospectively compensate for the sensitivity adjustment.
[0154] Selecting or clicking a meal within the ranking report 500 can launch a screen displaying additional information about that particular meal. Figure 5B shows an exemplary embodiment of screen 512 that may include a graphical display 514 of historical glucose (e.g., 8-hour, 24-hour, 48-hour, or other) surrounding a meal event. The graphical display 514 may include pre-meal, post-meal, and any time increment surrounding the meal. In one exemplary embodiment, the graphical display 514 is an 8-hour period with data for 2 hours prior to the start of the meal event and data for 6 hours after the start of the meal event. The graphical display 514 may also include any period of various ranges of analyte data associated with the meal event in method 300 (see description of Figure 3A).
[0155] For each excursion detected in the analyte data of the graphical display 514, an excursion indicator 408 (in this case, the shaded area below the glucose curve) can be displayed. Along with all other meal events within a given period in the graphical display 514, the occurrence of a selected meal event can be indicated by a food icon 516, a photograph of the meal, and / or text describing the meal. Alternatively, meal events clustered together can be displayed as a single event. Selecting a specific meal event can instead display another screen 512 focusing on that newly selected meal event. Alternatively, selecting a meal event can also display a pop-up window containing information about that particular meal event.
[0156] In another embodiment, by selecting an individual's meal from screen 502 in Figure 5A, an embodiment of screen 512 can be displayed, which includes a graphic display 514 containing an image of the selected meal, a summary of the meal's contents (e.g., portion type, quantity, etc.), and / or any free text entered by the user regarding that meal. Thus, all or most of the information entered by the user to describe the meal is displayed along with historical analysis data surrounding that meal event.
[0157] In another embodiment, each meal displayed in a ranking report or elsewhere may be displayed with its associated glucose trace. When displayed alongside other meals in a ranking report, users can compare the characteristics of different meals, such as relative peak glucose time and how long the glucose response lasts. The display may highlight some of these characteristics, such as showing the numerical elapsed time of peak glucose relative to the start of the meal.
[0158] Figure 5C shows an exemplary embodiment of screen 520, which illustrates a systematic layout of information to be displayed to the user about a particular meal, such as when a specific meal is selected from a ranking report 500. The date on which the time corresponding to the meal event first occurs is displayed in area 522, followed by the time (or time range, if provided) of the meal event. Below one or more images 524 of the meal, for example, photos of each course of the meal may be displayed if the user has taken them. The peak glucose value and delta glucose value of the meal may be displayed on the right side in 526, along with an optional free-text description of the meal in 528.
[0159] Figure 5D shows an exemplary embodiment of screen 530 with exemplary information about a specific meal entered. Screen 530 is similar to screen 520, but also includes the display of detected meal events 532-1 and 532-2 for which information has not yet been entered, such as missing entries. Each meal event 532 is followed by user-selectable log buttons 533-1 and 533-2 for logging information about the meal event, and user-selectable ignore buttons 534-1 and 534-2 for selection when the user chooses not to enter information about the meal or when no meal actually occurred. If the user chooses to log information about the meal, a logging information screen, such as screen 420 in Figure 4E, can be displayed along with the meal time, which has been pre-entered as the time of the missing entry. When the user returns to screen 530, the information needs to be recalculated to take into account the newly logged data. If the user chooses to ignore the missing entry, the logging of the missing entry is updated, and the ignored entry can be removed from screen 530.
[0160] Figure 5E shows an exemplary embodiment of screen 540, similar to screens 520 and 530. Here, screen 540 includes six photographs of a meal cluster that occurred between 10:50 a.m. and 11:20 a.m. In any embodiment described herein, selecting a particular photograph can cause a pop-up window containing a larger display of that image to appear.
[0161] Figure 5F shows an exemplary embodiment of screen 550, similar to the previous screen, but with logged or detected exercise or other activity 552 and the time at which that activity occurred in relation to a meal event described on screen 550.
[0162] Returning to Figure 3A, Method 300 can be repeated indefinitely so that the meal monitoring application continues to receive, monitor, and store analyte data (e.g., step 304 of Method 300) and retrieve detected events 306. Recently entered information about detected or logged meals can be included in options presented to the user for entering meal information each time a new event is detected.
[0163] The meal monitoring application can be used in conjunction with software that monitors and collects information about the user's activity level. Therefore, with respect to each embodiment described herein relating to meal logging, prompting for information about meals, correlating analyte data with meals, determining the blood glucose effect of meals, and / or outputting information about the relationship between meals and the user's glucose levels, it should be understood that those embodiments are also applicable to user activities other than meal intake. Common examples of such activities include exercise, work, and rest. All embodiments relating to such activities are within the scope of this disclosure. To assist in the collection of activity data, each sensor control device 102 may include, or otherwise be configured to operate in conjunction with, an activity monitor and / or a heart rate monitor that continuously or repeatedly measures each wearer's activity level (e.g., calories burned hourly per day) and / or a system 100 that monitors and enables the recording of the wearer's heart rate.
[0164] Information output by the diet monitoring application, such as the Ranking Report 500, provides users with specific and immediate information about the impact of diet on glucose levels. This output can help users learn to avoid or minimize certain foods in their diet that they were unaware were affecting their glucose levels, for example, foods that were making their glucose levels too high. This output can also help users learn to control their portion sizes by seeing the relative impact of different quantities on glucose levels.
[0165] The meal monitoring application can also recommend that individuals try different meals, times, and ingredients, making it persuasive and enjoyable to use. This meal monitoring application encourages the use of analytes by a wide range of people, including those with type 2 diabetes, prediabetes, metabolic syndrome, and non-diabetic people—basically anyone motivated to improve their health by changing their eating habits and / or activity habits.
[0166] The diet and / or activity monitoring applications described herein can provide substantial benefits to individuals newly diagnosed with type 2 diabetes or prediabetes. Often, when individuals face the prospect of starting drug therapy for diabetes, they are very eager to try modifying their diet and exercise to avoid or delay the need for drug therapy.
[0167] Therefore, a clinical scenario for the use of the various systems and software disclosed herein is, for example, that a newly diagnosed individual, based on fasting glucose and / or A1c testing, is followed up wearing a sensor control device 102 interfaced with a reader device 120, which can be blinded so that the user's current and past analyte levels are stored but not shown to the user. The user wears the sensor control device 102 for a certain period, for example, two weeks, after which analyte data is collected by a healthcare professional and the analyte patterns are revealed to the user. This blinded use minimizes the impact of the system on the user's habits and tendencies, and thus allows healthcare professionals to better understand specific glycemic problems and the best ways to address them with drug therapy. At this point, the physician can use the software application described herein to give the individual the option to try to address their diabetic condition through diet and exercise in conjunction with nutritional training and exercise planning. This can be followed up using a separate sensor control device 102 and reader device 120, allowing healthcare professionals to assess progress and determine whether medication or further dietary / exercise interventions are still necessary.
[0168] Additional metrics and reports for healthcare professionals can be included. For example, a study of 14 patients with normal glucose tolerance (NGT), 12 with impaired glucose tolerance (IGT), and 16 with non-insulin-dependent diabetes mellitus (NIDDM) showed that subjects with type 2 diabetes mellitus (T2DM) did not exhibit a phase 1 insulin response to intravenous glucose challenges. With adequate monitoring of glucose excursion tracking paired with dietary information, healthcare professionals can track changes in the phase 1 insulin response.
[0169] Furthermore, a quarter of adults worldwide have metabolic syndrome. These adults are five times more likely to develop type 2 diabetes. Moreover, there is evidence that most of the damage to human beta cells occurs before a diagnosis of prediabetes is made, demonstrating the need for pre-diabetic intervention. Since progression to type 2 diabetes begins with impaired glucose tolerance (IGT) well before impaired fasting glucose (IFG), sensor-based hyperglycemia and postprandial excursion-based indicators, which have been shown to reliably predict or diagnose the onset of type 1 diabetes, may be applicable to individuals with metabolic syndrome. Thus, the software applications and systems described herein for newly diagnosed diabetic patients are therefore applicable to the metabolic syndrome population.
[0170] Furthermore, since a general correlation between glucose excursion and weight gain is known, the software applications and systems described herein are applicable to people who wish to lose weight.
[0171] To the extent that information is input by a user, device, or other software, that information may be received, read, and, if it includes instructions, executed by a processing circuit (which may be a single processor or distributed across multiple processors or devices having processing capabilities). Those instructions may be stored in the memory of the processing circuit of any and all embodiments of the reader devices, drug delivery devices, meters, computer systems, or other computing devices described herein, and executed by the processing circuit.
[0172] Embodiments of population analytes monitoring for diet and activity planning This specification also provides exemplary embodiments that enable analytic monitoring of a user's local population, population, community, or group. Data collected from this population monitoring can be used for a number of purposes, including providing guidance and dietary and activity plans. These embodiments are described in relation to one exemplary use, namely, the use of population monitoring in an elderly care facility or home. However, these embodiments are not limited to this exemplary use, and numerous other such uses exist and are within the scope of this disclosure. Embodiments of population monitoring can be used alone or in combination with embodiments of dietary assessment and planning, which are also described herein.
[0173] In elderly care facilities, meals are prepared and served by the facility staff. The resident population may be susceptible to diabetes or prediabetes due to age-related declines in insulin response, decreased physical activity, weight gain, and / or other factors. Generally speaking, the residents form a population, and each member of the population may be fitted with in vivo sensors 104, such as a sensor control device 102. Analytical data collected by each member's sensor control device 102 can be automatically read by the reader device while the member is within range of the reader device, for example, when all or most members of the population are at approximately the same distance from each other in a shared area (e.g., a dining room) during meal times (e.g., breakfast, lunch, or dinner). Alternatively, data can also be read from each member of the population at different times relative to each other.
[0174] Figure 6A is a block diagram illustrating an exemplary embodiment of using an analyte monitoring system 600 to collect analyte data from N members of a population. Here, the system 600 includes a reader device 620 capable of communicating with a plurality of sensor control devices 102-1 to 102-N, each located on a plurality of device wearers 601-1 to 601-N, where N can be any desired number. The reader device wearers 601 are physically located in a shared area 610, such as a dining room.
[0175] The reader device 620 may be configured in the same manner as all embodiments of the reader device 120 described herein, but also has the ability to communicate with each of the multiple sensor control devices 102 simultaneously, sequentially, at scheduled intervals, or at random intervals (for example, so that the wearer 601 circulates around the shared area in a day). This communication may occur via a wireless or wired communication path 640, which may be configured similarly to the wireless communication path 140 described with respect to Figure 1. For example, any of the wireless communication protocols described herein may be used, and this communication path may be unidirectional or bidirectional.
[0176] In one exemplary embodiment, a reader device 620 pairs with each sensor control device 102 using the Bluetooth or Bluetooth Low Energy communication protocol. The reader device 620 can collect analyte data from each wearer 601, store the data locally, and / or upload the data to another computer system, such as a remote internet server. Here, the reader device 620 is adapted to communicate with a wireless hub 630, which itself can communicate data to a trusted computer system 180 via a network 190 through any number of servers. The communication link (or path) 641 between the reader device 620 and the wireless hub 630 can operate according to any desired wireless protocol. In this embodiment, the wireless hub 630 is a Wi-Fi hub, and the link 640 is a Wi-Fi connection. Thus, the reader device 620 can function as a Bluetooth to Wi-Fi bridge.
[0177] In other embodiments, the reader device 120 may include electronic circuit hardware and software that allows the reader device 620 to upload data directly to a trusted computer system 180 via the network 190, so that the Wi-Fi hub 630 may be omitted. For example, the reader device 620 may include cellular functionality, satellite communication functionality, cable modem functionality, and Ethernet functionality, etc.
[0178] In many embodiments, the trusted computer system 180 can be local to the resident population 601-1 to 601-N so as not to require communication via the network 190. For example, the reader device 620 can upload data collected via the communication link 641 to the Wi-Fi hub 630, which can then pass the information directly to the trusted computer system 180 via a local wired or wireless connection, or the reader device 620 can directly upload the collected data to the trusted computer system 180 via a local wired or wireless connection.
[0179] The reader device 620 can also perform any amount of desired processing on the analyte data collected from the sensor control devices 102. For example, the reader device 620 can simply pass the raw data collected from each sensor control device 102 to a trusted computer system 180 via the wireless hub 630 and network 190. In another example, the reader device 620 can algorithmically process the collected raw data to determine the analyte level for each wearer 601 and then upload the processed information to the trusted computer system 180.
[0180] The reader device 620 can be programmed to automatically recognize and pair with each sensor control device 102 within its communication range. However, higher selectivity may be desired to enable data collection only from specific sensor control devices 102. In such embodiments, the reader device 620 may be programmed to recognize and pair with only a subset of sensor control devices 102. For example, a sensor control device 102 may include a dedicated identification flag or code that it sends to the reader device 620 during a data acquisition or pairing procedure. The reader device 620 may be programmed to upload data only from the sensor control devices 102 that send this flag or code.
[0181] In another example, the reader device 620 itself, or another reader device 120, may perform a recognition procedure for each sensor control device 102, reading its identification number (e.g., serial number) and associating that identification number with a subset of sensor control devices 102 that communicate with the reader device 620. During this recognition procedure, the name or identification of the wearer 601 of each sensor control device 102 may be associated with its device identification number so that the data collected from each sensor control device 102 can be linked to a specific wearer 601. If the reader device 620 is used for this recognition procedure, the list of sensor identification numbers may be stored locally in the reader device 620's non-temporary memory. If another reader device 120 is used for the recognition procedure, the list of sensor identification numbers may be uploaded to a trusted computer system 180 and then communicated to the reader device 620.
[0182] To enable communication with as many sensor control devices 102 as possible, the reader device 620 can be located in the center of the common area 610. For example, the reader device 620 can be mounted overhead in the center of the room, or, in the case of a dining room, placed on the dining table. In some embodiments, multiple reader devices 620, for example, one reader device 620 on each table, can be used to increase the overall communication area.
[0183] Each sensor control device 102 can include sufficient non-temporary memory to store analyte data over the entire period between readings by the reader device 620. This allows the reader device 620 to collect all or substantially all of the analyte data for each wearer 601 over a day or a week. For example, the sensor control device 102 can include 12 hours of memory to record analyte data overnight, from after dinner to breakfast. Other memory sizes corresponding to different time lengths can also be used (e.g., 8 hours, 24 hours, 72 hours, etc.).
[0184] While these embodiments describe the use of a common reader device 620 for a regional population, each member of the regional population may also use its own reader device 120 to collect analyte data. In such cases, each reader device 120 can communicate directly with a trusted computer system 180, or with a data collection hub that then uploads the data to an appropriate computer system.
[0185] Figure 6B is a flowchart illustrating an exemplary embodiment of method 650 for monitoring populations for meal and / or activity planning. Similar to system 600 in Figure 6A, method 650 is described in relation to data collection from residents of an elderly care facility during mealtimes.
[0186] The shipped sensor control devices 102 are first received by the facility at 652. Facility staff can optionally upload the identification number of each sensor control device 102 to a trusted computer system 180 at 654. Next, each wearer to be monitored 601 can apply the sensor control device 102 at 656 so that the analyte sensor is positioned in vivo and ready to sense analyte data.
[0187] Next, each applied sensor control device 102 can be initialized, activated, or recognized in 658 by the reader device 620 or another reader device 120, as previously described, in order to identify a subset of sensor control devices 102 that will transmit data to the reader device 620. This recognition procedure can be performed by each wearer 601 or a member of the facility staff and may optionally include associating the wearer's name or identification with their sensor control device 102. This data can be uploaded in 660 to a trusted computer system 180, which can then communicate the list of sensor control devices 102 (and optionally the associated wearers 601) to the reader device 620 in 662.
[0188] The reader device 620 monitors for the presence of sensor control devices 102 in the shared area 610, and then, in 664, when those sensor control devices 102 are found in the shared area 610, it may pair with each of the subset of sensor control devices 102. If the shared area 610 is a dining hall, many sensor control devices 102 are likely to be found in a short time span. After establishing a connection with a particular recognized sensor control device 102, the reader device 620 can, in 667, read or upload analyte data stored in that sensor control device 102, which may represent a series of analyte level measurements by the wearer 601 since the device 102 was last read, or the entire history of analyte level measurements stored in the device 102's memory (in this case, measurements that overlap with those already collected can be ignored). After collecting the analyte data, the reader device 620 can disconnect from its sensor control device 102 at 668, and if the reader device 620 determines at 669 that another sensor control device 102 exists and needs to be read, it can proceed to pair with the next recognized sensor control device 102 and collect analyte data from it (returning to 664).
[0189] This process is repeated until analyte data has been collected from all recognized sensor control devices 102 within range of the reader device 620. Since specific residents may have different meal schedules, and their presence in the shared area 610 may be unpredictable, the reader device 620 can continuously monitor the sensor control devices 102 throughout the day. The reader device 620 can be programmed to wait for a sufficient period of time to elapse after data has been collected from a specific wearer 601 before attempting to re-pair with that wearer's sensor control device 102. For example, if a wearer temporarily leaves the shared area 610, the reader device 620 will not attempt to collect data again upon their re-entry. This waiting period may be, for example, 30 minutes, 1 hour, 90 minutes, etc. After the waiting period has expired, when the reader device 620 next recognizes a sensor control device 102, the reader device 620 restarts the data collection procedure. Thus, this process can be continuously repeated.
[0190] All data from the sensor control devices 102 can be stored in the non-temporary memory of a reliable computer system 180, and the aggregated data can be examined or processed in 672 to identify trends among resident facility populations. An example of a set of aggregated data is shown in Figure 7 in a human-readable format, where the X-axis represents time and the Y-axis represents analyte concentration, although each axis can also represent a different index. Each point (X) in the distribution represents a reading of analyte concentration collected by the reader device 620 from a specific sensor control device 102. Thus, the distribution includes not only readings from the same wearer 601 at different times, but also readings from different wearers 601 (also at different times). Furthermore, the aggregated data can include readings collected from each wearer on different days, for example, making it possible to identify trends unrelated to the occurrence of a single meal.
[0191] Menu information, such as meal content (e.g., calorie content, carbohydrate content, sugar content, protein content, etc.), meal times per day, and meal types (e.g., breakfast, lunch, snack, or dinner), can also be provided to a reliable computer system 180 and linked to aggregated data so that correlations between analyte data and meal information can be identified. Meal events can be detected in aggregated data using one of the meal event detectors described herein, or by analyzing a predefined period for each day, assuming that scheduled meals are provided. By comparing the analyte patterns of the resident population after previous meals with the meal information, factors causing undesirable analyte events can be identified, and meals can be adjusted to minimize these events. Even when no specific excursions occur, meal content, type, and timing can be adjusted to provide maximum stability or analyte levels across the resident facility population.
[0192] The reliable computer system 180 can be programmed to present aggregated data to the user in the form of a graph, as shown in Figure 7, or in the form of a summary report. The reliable computer system 180 can also be programmed to determine or present analyte indicators for individual wearers and statistics for the entire population (e.g., analyte median or mean, standard deviation, or mean maximum or minimum). Figure 7 shows a trend line 702 representing the team analyte concentrations of the resident population over a period of time with indicators for the first meal 704 and subsequent meals 706.
[0193] A reliable computer system 180 can identify trends in the resident population and pinpoint instances where a portion of the population (e.g., 5%, 10%, 20%, etc.) violates a threshold or the population is progressing in an undesirable manner. Thresholds can be, for example, low analyte thresholds, high analyte thresholds, rate of change thresholds, etc. A population may progress in an undesirable manner, for example, by having undesirably high or low mean, median, or minimum-to-maximum fluctuations, even without an excessive number of glucose excursions. The reliable computer system 180 can be further programmed to refer to dietary information (e.g., excessive carbohydrate content, excessive sugar content, meals being too frequent or too infrequent) to provide potential causes of trends and to provide recommendations on how dietary aspects can be modified to mitigate the trends. These recommendations may include adjustments to dietary content, meal timing, introduction or elimination of snacks, and adjustments to insulin dosage and administration timing (e.g., basal and bolus doses).
[0194] The reliable computer system 180 can also determine the analyte (e.g., blood glucose) response or effect of each meal and provide a report identifying meals associated with the most desirable or undesirable analyte characteristics. This information can be used, for example, by facility managers to modify dietary plans to maintain improved analyte levels across the entire population. For example, the reliable computer system 180 can determine and store the blood glucose response of each meal and output a ranking to help identify meals that cause the most severe response. Any of the indices described herein can be used to quantify or otherwise indicate the severity of the blood glucose response, including but not limited to peak glucose values, delta glucose values, and / or glucose area.
[0195] Statistical analysis can output, for example, mean glucose, median glucose, or glucose variability with the standard deviation and / or interquartile range for each meal. This output can also include threshold comparison results, such as outputting the mean or median of populations exceeding a threshold, outputting the proportion of populations with mean or median values exceeding a threshold, or outputting the variability of populations exceeding a threshold.
[0196] In addition to the actions already mentioned, any number of actions can be taken for members of a population identified as exceeding a threshold for a given diet, such as reducing the amount of food, providing alternative foods, or increasing insulin or other medications. A reliable computer system 180 can also identify individuals experiencing low glucose levels, which may indicate that too much insulin is being administered for a particular diet.
[0197] Housing typically provides recreational activities and, consequently, the ability to select the types of activities and schedule them at the most effective times to reduce glucose elevation. The embodiments described with respect to Figures 6A, 6B, and 7 can be used in combination with other activities experienced by the population, such as exercise.
[0198] For example, in much the same way as described above for diet, information on exercise events of a population can also be linked to aggregate data so that a reliable computer system 180 can present linked data and / or determine whether there is a correlation between the trends of the analytes and the time, duration, and / or intensity of exercise events. Each sensor control device 102 may include activity monitoring that continuously measures the activity level of each wearer (e.g., calories burned hourly per day), or may be configured to operate in conjunction with activity monitoring.
[0199] Meal monitoring application In another embodiment, in addition to the features described above, the dietary monitoring application categorizes food and beverage choices according to blood glucose (or other analytes) responses. It can be used in conjunction with the analytes monitoring system 100 to help people better understand the impact of their own diet on glucose levels. Users can directly see how food and beverage choices, along with their quantities, affect glucose levels. Users can learn which foods have the greatest impact. This application also helps dispel myths about healthy eating (e.g., problematic high-carbohydrate foods such as orange juice and breakfast cereals, which may be mistakenly perceived as healthy). This application may be a standalone application or may be incorporated in whole or in part into other applications.
[0200] Dietary monitoring applications can be used by diabetic patients with an underlying motivation to change their eating habits, including those with type 2 diabetes receiving basal insulin, or those with type 1 or type 2 diabetes undergoing polypharmacy-based insulin therapy. They can also be used by prediabetic patients or non-diabetic patients who want to minimize glucose excursions by controlling their diet. Users of dietary monitoring applications have uncontrolled diabetes and want to bring it under control, but find it unsustainable to follow a prescribed "diabetic diet" for extended periods because they don't want to give up the foods they enjoy. Users of dietary monitoring applications may also have under control of their diabetes, but their usual eating habits may no longer be working due to reasons such as taking new medications, starting a new exercise plan, pregnancy, or other lifestyle changes.
[0201] A meal monitoring application may allow users to see good and bad foods (or good and bad eating behaviors) present in their current diet to help them determine what modifications they can make to achieve glucose control and improve the time their glucose levels remain within the target range. The application can assist users by providing data visualizations of glucose spike differences and time in range (TIR) impacts of different food choices. The application can also prompt users to log meals if it detects a meal that is "not very healthy" (e.g., a meal that resulted in the user's blood glucose levels falling outside the target or target range). The application may gamify TIR to motivate users to select beneficial foods and increase their TIR metric. The application may also include encouraging and celebratory messages to motivate users to continue good eating behaviors.
[0202] A meal monitoring application may present an onboarding sequence to help users customize the application based on their stated needs and goals so that they can have the desired experience. The application may prompt the user to indicate the type of diabetes they have. A list of options may include Type 1, Type 2, Prediabetes, Pregnant, Other, and Unknown. After the user selects an appropriate answer to the prompt, the application may prompt the user to specify their level of diabetes education. A list of possible answers may include Beginner, Intermediate, and Experienced but still learning. The application may prompt the user to specify their goals when using the application. A list of possible answers may include Diet for glucose control, Keep glucose within range, and Both (Full guidance). A user who selects Diet for glucose control may want to learn what and how much to eat based on the meals they have logged and how those meals affect their glucose. A user who selects Keep glucose within range may want an application that helps them understand how what they eat affects their glucose, notifies them only when their glucose spikes, and helps them bring their glucose levels back within the target range. Users who select 1130 for both may want to learn what they should eat and what they should do to achieve their target glucose range.
[0203] During the onboarding process, the application may introduce various milestones that users should complete to encourage them to log more meals. The application may set milestones that users should complete, which may include logging their first meal, staying within a target range after eating, and logging a certain number of meals (e.g., 5, 10, 15, 20, 25, 50 meals). Furthermore, the application may display counters to track the user's progress at various milestones. For example, to show the user's progress toward the goal of logging 10 meals, a counter showing the number of logged meals, along with a graphical progress indicator, may be displayed. The application may set milestones by default. Alternatively, users may set or modify milestones.
[0204] Many metrics exist that can be used to assess the glucose effects of a meal (and other events). A meal monitoring application may utilize and evaluate any desired metric, and in some embodiments, it may utilize and evaluate the amount of time the user spends above an upper threshold, the amount of time the user spends within a certain range, or the amount of time the user spends below a lower threshold. For example, a meal monitoring application may evaluate the amount of time the user's glucose level spends above a threshold (e.g., approximately 180 mg / dL, alternatively approximately 250 mg / dL, alternatively approximately 120 mg / dL, or another value). Such a metric may be called time-above-threshold. A time-above-threshold episode may be triggered when the glucose level exceeds the threshold for the duration of the current period. In embodiments, but not limited to such examples, the use of time the user's glucose level exceeds a threshold of approximately 180 mg / dL for at least a preset period of time may be used, which may be called time-above-threshold 180 or TA180. A meal monitoring application may also evaluate the amount of time a user spends within a certain range, i.e., within range time, or "TIR" (e.g., approximately 70 mg / dL to approximately 180 mg / dL, approximately 70 mg / dL to approximately 120 mg / dL, or approximately 140 mg / dL to approximately 250 mg / dL, or within other ranges). Another option is to evaluate the amount of time spent below a value such as approximately 180 mg / dL. Such indicators are sometimes called time-below thresholds.
[0205] These metrics can be determined in percentage form by dividing the time the analyte level was above the threshold (or within the range) by the total time. For example, if glucose is within the 6-hour TIR threshold over a total 24-hour period, the TIR metric is 25%. Or, if the user's glucose level is above the 3-hour threshold over a total 24-hour period, the time-excess threshold metric is 12.5%. Alternatively, this metric may be expressed in units of time increments instead of percentiles; using the above example, the TIR would be 6 hours (over a total 24-hour period). The total period may be a predetermined fixed length or a quantity that changes over time. For example, the TIR up to the current time of the current week may be the total time glucose has been within the range from 12:00 AM Sunday to the current time of the week divided by the total elapsed time from 12:00 AM Sunday. The metric may also be calculated according to the amount of readings within the range over a certain elapsed time divided by the total number of readings over that elapsed time. For example, after 24 hours, glucose readings may be collected every 15 minutes. If the application is accessed, for example, from a homepage, the TIR calculation can be performed according to the following formula: TIR = # readings within range / # readings from the start of the period In this example, if the period starts at 12:00 AM, the total number of readings at 15-minute intervals will be 48 at 12:00 PM (12 hours after 12:00 AM). However, at 11:45 PM (23.75 hours after 12:00 AM), the total number of readings at 15-minute intervals will be 95. Therefore, the denominator changes with the passage of the day and is reset at the end of the set period, for example, when the number of readings at 12:00 AM each night reaches 96 if the period is one day. Similar calculations for the time exceeding threshold index can be performed by using the amount of time or the number of readings that exceed the threshold instead of the amount of time or the number of readings within the range.
[0206] In many embodiments, the application user has glucose monitored, such as by a sensor control device 102 of system 100. As seen in Figures 8A-1 to 8A-2, the analyte levels are (i) transferred from the sensor to the user interface application 802, then (ii) transferred from the user interface application 802 to a cloud including server 804, then (iii) transferred from server 804 to the diet monitoring server 806, where, if results exist, they can be returned to the diet monitoring application. The cloud may include one or more servers 804, 806 having the same or different functions. For example, analyte data may be uploaded to a first server or group of servers responsible for collecting analyte data, and then downloaded to the diet monitoring application by a second server or group of servers responsible for downloading the data for use by the diet monitoring application. As seen in the first screen, the diet monitoring home screen 810, a graph 812 of glucose concentration (in mg / dl or mmol / L units) is displayed for a certain period, for example, one day, or part of a day. The time displayed in graph 812 may show glucose concentrations measured starting at 12:00 a.m. on the current date. The target range 818 is highlighted in the graph, for example, by shading it in a different color from the graph's background color, for example, by shading it in green. As seen in Figure 8B, when a meal event is detected, the meal monitoring application may mark the event with indicator 820 at the time determined by the episode detector to be the start of the event. Notification to the user of the detected event may come at a time after the time determined by the episode detector to be the start of the event. The indicator may be a circle with a "?" indicating that meal information (or other information that can be logged, such as exercise or stress) is missing for this event, and the user is prompted to log the ingested meal (see log entry screen 826) that caused the rise in glucose levels.Next, the meal monitoring application returns to the home screen 810, which may display a display of the consumed meal 832 (for example, an image of the food eaten).
[0207] In an alternative embodiment, the home screen may include a graph of glucose concentrations (in mg / dl or mmol / L units) displayed for a certain period, e.g., a day, or part of a day. The time displayed on the graph may show measured glucose concentrations starting from 12:00 a.m. on the current date. The target range may be highlighted in the graph, for example, by shading it in a different color from the graph's background color, e.g., green. The upper glucose threshold (e.g., approximately 250 mg / dL) and lower glucose threshold (e.g., approximately 75 mg / dL) may also be shown on the graph with lines of different colors to clearly indicate to the user whether these thresholds are above or below. Furthermore, detected events may be color-coded to indicate whether the event is above the range (e.g., orange or red) or within the range (green). Additionally, a TIR display up to the current time of the day or week may be displayed to allow the user to easily see how well their glucose management is going. A graphic showing the current sensor life may also be displayed on the home screen 810.
[0208] The target range 818 (similar to the episode detector threshold) may be set by the user and / or HCP. For example, the target range may be set to approximately 80 mg / dL to approximately 170 mg / dL, alternatively approximately 70 mg / dL to approximately 180 mg / dL, or approximately 65 mg / dL to approximately 120 mg / dL.
[0209] According to another embodiment, a configurable target may be used. Target 854 itself may be set or configured by default by the patient or HCP. This target is a threshold compared to an aggregate of blood glucose response indicators (e.g., TA180 not exceeding 30%, or TIR at least 70%) over a certain period of time (one week, or up to the present time of the current week, or up to the present time of the current date). Target 854 may also be progressively adjusted by the diet monitoring application if the user is currently meeting the assigned target or goal after a predetermined period of time. For example, if the user has consistently reached the target of 30% of glucose measurements within the target range, for example, over the past week, the diet monitoring application may set a new achievement target of maintaining 35% of the user's measured analyte levels within the target range. Similarly, if the user has not consistently reached the target of 30% of glucose measurements within the target range, the diet monitoring application may set a new achievement target for the user of maintaining 25% of the measured analyte levels within the target range.
[0210] The home screen 810 may also include a display of the amount of time the user has been within the target range ("Time Within Range" or "TIR") for different periods, e.g., two or more periods, or alternatively, three or more periods. The home screen 810 can display the percentage value of TIR 850 for the current date (e.g., measured from 12:00 a.m. to the current time), the TIR for the previous week, and the TIR up to the present for the current week (e.g., measured for a certain period, e.g., from 12:00 a.m. on Sunday to the current time, alternatively from 12:00 a.m. on Monday to the current time, or alternatively from 7 days ago to the current time). The value of these three ways of displaying TIR is that it provides the user with an understanding of their current situation compared to the previous week, in terms of the current time up to the present and the current time up to the present date. Using this information, the user can make choices about their eating habits, such as avoiding certain foods when they are feeling worse than last week, or indulging in foods that may cause high blood sugar when they are feeling better than last week. In addition to reporting a numerical value representing the percentage of time spent in the target range 818, the TIR display 850 can visually indicate the amount of time the user has spent in the target range 818. For example, for each period of the TIR display 850, circles 852-1, 852-2, and 852-3 may be shown at the center of the circles along with the numerical percentage of TIR. Circles 852-1, 852-2, and 852-3 may graphically display the amount of TIR (progress indicator) and the target / target percentage of TIR. For example, with respect to a hypothetical clock face on the circle, the TIR percentage display could be shown as a colored line starting at the 12 o'clock position and extending to X% of the circle's circumference, indicating that the user has spent X% of TIR so far during that period. Furthermore, a display of the target percentage 854 (e.g., a bullseye, a circle, "x", or other separator) may be included around the circle to make it easy for the user to see whether their TIR is above or below the target percentage. Each of the circles 852-1, 852-2, and 852-3 for different time periods may include a display such as (1) a numerical percentage of TIR, (2) a graph or visual representation of the amount of TIR (progress indicator), or (3) a display of the target / target percentage.
[0211] Event Detection The meal monitoring application may have three configurable settings for episode detection: a high threshold, a low threshold, and a minimum duration. An analyte level greater than the high threshold for a duration greater than the duration threshold can be described as an "above-range episode." For example, if the high threshold is approximately 180 mg / dL and the duration threshold is set to 30 minutes, an above-range episode will be detected if glucose exceeds approximately 180 mg / dL for at least approximately 30 minutes, and the user will be prompted to log their meal. Analyte levels, such as glucose readings, can be classified into one of three possible states: (1) a range episode, (2) a hyperglycemic episode, or (3) a hypoglycemic episode. A more detailed description of exemplary embodiments of software or software-implementable processes relating to meal event detection can be found in any of U.S. Patent Publications 2013 / 0085358, 2014 / 0350369, 2014 / 0088393, 2017 / 0185748, 2020 / 0105397, or International Publication 2015 / 153482 or PCT / US20 / 12134, all of which are incorporated prior to this by reference in their entirety for any purpose.
[0212] In any embodiment of the application, as shown in Figure 10C, when the episode detector detects an event, the meal monitoring application may increment a numeric badge 847 located on the meal monitoring application icon 849 by one. The meal monitoring application may also add an icon (e.g., "?") on the glucose graph at the time estimated by the episode detector to be the start of the event, and position it with an offset of either a glucose value or a predetermined amount relative to the glucose value at that time. The numeric badge may be decremented by one when the user provides information about the relevant event and saves that information, or after a certain period of time has elapsed, where the elapsed period may be a certain time value from the event or a quantized full-day period relative to the event. In a further embodiment, the meal monitoring application may also issue a notification when a new event is detected. When the user selects the "?" icon, a log entry screen 826 may appear that allows the user to enter event information. When screen 826 is opened in this way, the event time may be set by default to the time estimated by the episode detector to be the start of the event, i.e., the time associated with the icon. However, this time is still editable by the user.
[0213] Meal logging The meal monitoring application can prompt the user to log meals, for example, when an event or episode is detected and / or when an event outside the target range is detected. Users of the meal monitoring application can also log meals voluntarily without prompting. As seen in Figure 9A-1, if a user wants to add a meal voluntarily, on the home screen 810, the user can select the option to add a meal, for example by tapping the "+" icon 836, after which a log entry screen 826 pops up with multiple fields for the user to enter meal information. The log entry screen 826 may also include a "Description" field 828 where the user can enter a description of the meal consumed. The log entry screen 826 may also include options 830 indicating the relative size of the meal consumed, selectable buttons indicating different meal sizes such as "Small," "Normal," and "Large." Users can also add a photo of the meal to be associated with it. For example, the log entry screen 826 may include a camera icon 834 that, when tapped, opens the camera of the device on which the meal monitoring application is installed, allowing the user to take a picture of the meal, or alternatively, select a picture from the photo library. The log entry screen 826 may or may not include a field to include the carbohydrate content of the meal. After the meal information has been entered, the user can log the meal by clicking "Save," after which the user may be directed to the log details screen 840. As seen on the log details screen 840, the logged meal 832 is displayed on the graph 812, and a brief description 842 of the logged details of the meal is displayed below the graph in the brief description window 842. As seen on the log details screen 844, the user can choose to enlarge the brief description window 842 to view the full logged details.
[0214] As seen in Figures 9A-1 and 9B, instead of entering a description of a meal, the user can also select an item from a list of frequently consumed meals by selecting or opening the “Frequently consumed items” dropdown menu 860. This alternative method for logging meals allows for quick entry of meal information if the user has already logged meals in the past. As seen in Figure 9B, the user can tap or otherwise open the “Frequently consumed items” pulldown menu 860 to open a list 864 of items the user has consumed in the past. The user can scroll down the list 864 and select the meal they want to log by, for example, tapping Input or selecting it in another way. Tapping Input will open a log entry screen 826 corresponding to the selected food item, with a pre-filled description. The user can then select the relative quantity of the consumed meal from the Quantity Options 830. After the meal information has been entered, the user can log the meal by clicking “Save”. After the meal has been logged, the user can access the same information described for manual entry of a new meal in Figures 9A-1 and 9A-2.
[0215] In alternative embodiments of the application, an alternative log entry screen 870 may be used in the meal monitoring application, as shown in Figures 9C-1 to 9C-5. The log entry screen 870 may include, but is not limited to, all options and fields as discussed with respect to other log entry screens, including a field to add a meal description 828, an option to select a meal size 830, an option to associate a photo 834 with the meal, a frequently used food menu 860 (see Figure 9C-2) where the user can select meals previously entered by the user, and an option 846 to indicate that no food was consumed (e.g., an Other (No Food / Beverage) toggle switch). The user may also change or enter a time associated with an event, for example, by clicking on the time 872 displayed on the log entry screen 870. As shown in Figure 9C-5, a time screen 874 may be opened, where the user can select a time to associate with an event, for example, by turning a clock handle to a certain time or by entering the time in digital format.
[0216] In an alternative embodiment, the user can log meals from the home screen by tapping a plus sign or other link and selecting "Food." A GUI can then appear, displaying lists of recent meals, frequently eaten meals, and all meals in different selectable tabs. If the user selects a meal that has already been entered, the meal entry can be pre-filled with information about past meals and the current date and time can be assigned. Furthermore, the user may be able to edit the meal entry as needed. An option to add a new meal may also appear. If the user selects the option to add a new meal, another GUI may appear containing multiple tags to associate with the meal. The user can edit the entry to add a name for the meal. The user can also select a camera icon to add an image to associate with the meal entry. The user can also select meal tags to specify the type of meal consumed. Meal tags can include breakfast, lunch, dinner, dessert, snack, or other appropriate names. The user can also select one or more descriptive tags to describe the content or characteristics of the meal. For example, a descriptive tag might relate to the carbohydrate content of the meal, e.g., low-carbohydrate or high-carbohydrate. Description tags can also relate to the specific contents of a meal and list the type of food, such as vegetables, chicken, beef, pork, fish, salad, pasta, or vegetarian. Users can also select portion tags, which can list relative portions. These tags may include average, larger, and smaller sizes compared to the user's usual portion sizes. Users can also enter the amount of carbohydrates associated with the meal. Meal time and date can be automatically associated with the meal entry. Time and date can be edited by the user as needed. Users can also enter notes related to the meal entry. Notes can include more detailed descriptions of the meal that can be used in natural language search to analyze the individual foods contained in the meal.
[0217] After multiple meals have been logged, the food memo GUI can display lists of recently eaten meals, frequently eaten meals, and all meals in different selectable tabs. If the user selects a meal that has already been entered, the meal entry is pre-filled with past meal information and assigned the current date and time. Furthermore, the user can edit the meal entry as needed. Risk tags may be associated with each meal or food that can indicate whether the meal is low-risk, dangerous, or high-risk, or alternatively low-risk, medium-risk (or moderate), or high-risk. These risk tags may be determined in a similar manner to the determination of “good” and “bad” meals described elsewhere in this application. For example, a meal in which the user remains above the target range or approximately 180 mg / dl for a certain period, e.g., at least about 1 hour, may be classified as “bad” or “high-risk,” while a meal in which the user remains within the target range of approximately 70 mg / dL to approximately 180 mg / dL for a certain period may be classified as “good” or “low-risk.” A meal in which the user remains above the target range or approximately 180 mg / dl for a shorter period than the duration of a bad or high-risk meal—for example, about 15 to 60 minutes, or alternatively, about 30 to 60 minutes—may be classified as "dangerous" or "medium risk."
[0218] Users can also tap on links to recommendations, which may result in an in-app modal GUI. The in-app modal GUI may contain details of suggested meal plans from the ADA or other organizations.
[0219] The user may also be prompted to enter meal information when an event is detected. When an event is detected, the meal monitoring application increments a badge on the application icon and displays a "?" icon 820 on the analyte level graph at the time the episode detector estimates the meal started. As seen in the home screen 810 of Figure 10A-1, the user can add information to this event by tapping the "?" icon, which opens the log entry screen 826. Alternatively, the user can tap the "?" icon to open a window 824 that prompts the user to add details about the meal. The user can click "Edit" 822, which opens a larger log entry screen 826. When the user is on the log entry screen 826, by either tapping "?" or clicking "Edit", the user can enter a description of the meal 828, and selectable buttons indicating different meal sizes 830, such as "Small", "Regular", "Large", etc., may also be displayed. The user can also associate a photo with the meal. For example, the log entry screen 826 may include a camera icon 834 that, when tapped, opens the camera of the device on which the meal monitoring application is installed, allowing the user to take a picture of the meal or, alternatively, select a picture from the photo library. The log entry screen 826 may or may not include a field for including the carbohydrate content of the meal. The log entry screen 826 may also include an option 846 to indicate that the glucose increase was not caused by the meal, as seen in Figure 10A-2. In the log entry screen 826, this option 846 is a selectable box labeled "The glucose increase was not caused by the meal." In an alternative embodiment shown in Figure 10B, this option 846 appears as a toggle switch labeled "Other (No Food / Beverage)."If option 846 is selected, the symbol 848 (e.g., "X") may be incorporated into the display space reserved for the photo to highlight that this event is not associated with a meal. After the information related to the event has been entered, the user can click "Save" to log the information. After the event information has been logged, a smaller version of the symbol 848 or "meal" may be associated with the event on the graph in the log details screen 840. Details of the logged event may be displayed in an abbreviated form in the window 842 below the graph.
[0220] Therefore, as summarized in the flowchart of Figure 11, there are two ways in which a user can input a meal into the meal monitoring application. The user may either choose to log a meal 902 or be prompted by the application to log a meal 904. In one method, the user can input a description of the meal 910, select the size of the meal consumed (e.g., small, regular, large) 912, add a photo of the meal 914, then save the meal information 916 and associate it with that meal event. The user can also edit the time associated with the meal input. Alternatively, the user may choose to log a meal by opening a menu of frequent foods (e.g., a dropdown menu) 920, selecting a meal from the list of frequent foods 922, selecting an appropriate meal size 924, and saving the meal information 926, which will then be associated with that meal event. Alternatively, the user may indicate that an increase in glucose is not due to a meal 930.
[0221] In an alternative embodiment of the application, as seen in FIG. 9D, the meal monitoring application can also include a menu screen 880 that includes, but is not limited to, a meal log icon 882, a meal ranking icon 884, a discrepancy excursion icon 886, and a settings icon 888. When the user selects the meal log icon 882, a meal log screen 890 opens, which can include the same details as described with respect to the log entry screen 826. The meal log screen 890 can include fields for the name 904 of the meal, a field for comments 906, and an option to add an image of the meal. The meal log screen 890 can also include an option to select a meal from a list of meals 860 entered previously (see, e.g., "meal selection").
[0222] In this alternative embodiment of the application, the user can also view a list of detected events and have the option to associate a meal with these detected events. As seen in FIG. 9E, when the user selects the discrepancy excursion icon 886, a discrepancy excursion screen 890 appears along with a list of detected events. Each input 892-1 to 892-4 can include the time or time range 894 when the event / excursion occurred, a portion of the glucose concentration graph 896 indicating the event, and the glucose concentration value 898 associated with the event. The user can select the option to log a meal associated with a particular event, where a log entry or meal log screen as described herein is presented and the user can enter meal information as described in relation to other embodiments. [[ID=**]]
[0223] Meal Monitoring Insights The meal monitoring application is designed to provide users with multiple insights by grouping various analyses together. As seen in Figure 12, the home screen 810 provides insights into how successful the user has been in reaching their goals over various periods and which foods caused spikes in glucose concentration. Small icons 820 on graph 812 give the user insights into which foods caused glucose spikes that pushed them outside the target range 818. Users can identify “bad foods” at a glance if the image is related to that event, or they can click the icon to view more details in the log of that meal. The TIR display 852-2 for the current date can inform the user how carefully they need to eat for the rest of the day to achieve the TIR goal 854, which is clearly shown in the TIR circle 852-2. If the TIR display 852-3 up to the present time of the current week shows that they are above the TIR goal 854, the user can be informed that they can have a “cheat day” or “cheat meal” and still achieve the TIR goal 854. However, if the TIR display 852-3 for the current week up to this point is below the TIR target 854, it can inform the user that they need to make better food choices to compensate for poor choices earlier in the week. The TIR display 852-1 for the past week can give the user insight into whether the current week up to this point is better than the previous week. If the TIR display 852-2 for the current week shows a higher percentage TIR compared to the previous week, the user may be encouraged to see that the better choices they made during the current week have succeeded in keeping them within the target range.
[0224] As shown in Figure 13A, the Weekly Insights screen 930 can provide the user with additional insights into the impact of consuming specific foods. The Weekly Insights screen 930 may include a TIR display 932 of the total for the week to date, a trend statement 934, a display 940 of groupings of foods for which the user's glucose rose above the target range or had a TA180 above a certain threshold after eating, and a display 950 of groupings of foods for which the user's glucose remained within the range or had a TA180 below a certain threshold after eating. The food grouping displays 940, 950 may be displayed for different time periods 936 (e.g., all day, morning, afternoon, evening, and night) and may be expandable and collapsible. In the alternative insights report 930 shown in Figure 13C, the screen may include a filter with an option to select the time period 937 to display. The TIR display 932 of the total for the week to date ("Weekly Total") can show the user whether they have reached their goal for that week. Trend statement 934 can inform the user of which period of the day had the most out-of-range measurements (e.g., "Time spent most time above range: afternoon"). Display 940 of food groupings that resulted in the user staying outside the range can give the user insight into which foods the user ate consistently caused glucose levels to exceed the target range and / or 180 mg / dl (TA180) (e.g., “bad” foods). Display 950 of food groupings allows the user to see if there were any foods that consistently kept them within the target range (e.g., “good” foods). Display 950 of food groupings that resulted in the user staying within the target range can give the user insight into which foods the user ate to consistently keep glucose levels within the target range. Display 950 allows the user to see which “good” foods consistently kept their glucose levels within the target range.The grouping of the foods shown and the display of the periods may be programmed, for example by default, to first display the "bad" period of one day (e.g., the highest TA180) during which the user was outside the target range for the longest time. Alternatively, the program may be programmed to first display, for example by default, the period during which the user stayed within the target / target range for the most time (the highest percentage of TIR), and to display the "good" foods associated with this period as an effort to encourage good behavior.
[0225] Meals can be associated with episodes according to some rules. All episodes can be classified into in-range episodes and out-of-range episodes. In-range episodes precede and follow each out-of-range episode.
[0226] In-range episode → Out-of-range episode → In-range episode (Ep1) (Ep2) (Ep3) All logged meals can be characterized as belonging to an episode based on the following rules: - If a meal is logged within 30 minutes of the end of an episode, the meal belongs only to the subsequent episode. For example, if a meal in Ep1 is logged within 30 minutes before the start of Ep2, the logged meal is assigned to Ep2 and not to Ep1.
[0227] - If a meal is logged between 30 minutes and 1 hour before the end of the current episode, the meal belongs to both the current episode and the next episode. For example, if a meal in Ep1 is logged 1 hour before the start of Ep2, the logged meal is assigned to both Ep1 and Ep2.
[0228] - If a meal is logged more than 1 hour before the end / start of the next episode of the current episode, the meal belongs only to the current episode. For example, if a meal is logged in Ep1 1 hour and 1 minute before the start of Ep2, the logged meal is assigned only to Ep1.
[0229] Therefore, for example, if a meal is logged in Episode 1 (a range-bound episode) 15 minutes before Episode 2 (an out-of-range episode, e.g., above 180 mg / dL) ends, that meal will be assigned to Episode 2, not Episode 1.
[0230] Figures 13B-1 to 13B-5 and 13C illustrate how to access the Weekly Insights report. As seen in Figure 13B-1, from the home screen 810, the user can tap or select the lightbulb icon 952 to open the Weekly Insights Weekly Range screen 952, which contains a list of various weeks with relevant date ranges. Each week's input may include a TIR display 852 that includes a visual or graphic representation (e.g., a colored bar around a circle or other progress indicator) of the amount of time the user spent within the target range, in addition to reporting a numerical value of the percentage of time spent within the target range. Within-range time for the entire week can be calculated according to the following formula: TIR 週 = # readings within the range of weeks / # total readings within the range of weeks For example, if glucose readings are taken every 15 minutes, the total number of readings in a week is 672. The time remaining within the current week can be calculated using the following formula: TIR 現在の週の現時点までの時点 = # readings within range / # readings from the start of the week For example, if glucose readings are taken every 15 minutes, a week can be set to start at 12:00 AM on Sunday, with the TIR at noon on Tuesday. 現在の週の現時点までの時点 The denominator will be 240 readings.
[0231] The user can select a specific week to view the insights report 930 for that week, which opens the insights report screen 930 for the selected week. The TIR display can also be filtered to represent the entire week or a specific time of day (e.g., morning, afternoon, or evening). The insights report 930 may have a default setting that displays the period of the day in which the user stayed within the target range for the longest time, which includes a display of “good” foods associated with this period as an effort to enforce good behavior. The background color of the screen can be colored to indicate that the user was within the range, for example, the background color can be set to green for the display of “good” foods. As seen in Figures 13B-3 and 13B-4, the user can also choose to view the period in which the user was above the target range or around 180 mg / dl for the longest time ("time spent in the hyperglycemic range") 940, which will display the “bad” foods eaten before or during the time when the user's glucose level was above the target range. To characterize a food as "bad," the hyperglycemia range of 180 (time above 180) can be greater than approximately 1 hour, alternatively greater than approximately 30 minutes, and alternatively greater than approximately 1.5 hours. The background color of the screen can be colored to indicate that the user has exceeded the target range; for example, the background color can be set to yellow, orange, or red to display "bad" foods. Furthermore, for any of the foods displayed on the insights report screen 930, the user can select a specific food input icon to view episode details 955 related to that meal.
[0232] The meal monitoring application can rank episodes to determine which meals to display in the Insights Report 930. All episodes, both within and outside the range, that occur weekly can be ranked in ascending order by duration. Episodes with the longest duration within the range (e.g., top 5, alternatively top 7, alternatively top 10, alternatively top 5-top 10) can be displayed along with the meals associated with them. Similarly, episodes with the longest duration outside the range (e.g., top 5, alternatively top 7, alternatively top 10, alternatively top 5-top 10) can be displayed along with the meals associated with them. Within the display of top episodes, users can scroll to view meals associated with that particular episode. Users can also scroll between episodes to identify recurring themes (e.g., chocolate bars appearing in all of their top 5 episodes). Ranked episodes can also be filtered to include only episodes from a specific period of a day, similar to the TIR display.
[0233] Users can also click on an episode to view the glucose trace for that specific episode. The episode details screen 955 may include a graph of the user's glucose levels for the relevant period including that meal (highlighted by a corresponding icon), and a simplified screen (expandable to reveal more meal details) may be displayed below the graph. The glucose concentration graph 812 can color-code target range concentrations in green 818 and concentrations above the target range (e.g., area under the curve) in yellow, orange, or red 958.
[0234] In an alternative embodiment, the Weekly Insights screen 960 may include a TIR display 852 for that week, a trend statement 934, and a display 940 of “bad” foods that tend to raise the user’s glucose levels above the target range (see Figure 13D-3). The Weekly Insights screen 960 may also include a display 964 showing how much of the entered meals were within and outside the range. Similar to the TIR display 852, the meal display 964 when within and outside the range may include a visual representation (e.g., a colored bar around a circle) of the number of entered meals that the user stayed within the target range, in addition to reporting a numerical value for the percentage of meals the user stayed within the target range. Another circle may show meals that resulted in the user’s glucose levels rising above the target range. The Weekly Insights screen 960 may also include a graph 968 showing the median or mean glucose levels for the week, displayed over a period of time, with the day divided into segments (e.g., night, morning, afternoon, and evening). Graph 968 can be color-coded to show which parts of the graph are within the range and which parts are outside the range.
[0235] In an alternative embodiment, the weekly insights screen may include a TIR display for the week, a trend statement, a display of “bad” foods that tend to raise the user’s glucose levels above the target range, and a display of “good” foods that, after the user’s consumption, kept glucose within the range or had a TA180 below a certain threshold. In a simplified layout, meals may be grouped according to whether they are above or within the range, and may not be subdivided according to the time of day, or may be separated by meals consumed on different days.
[0236] In an alternative embodiment, the weekly insights screen may include a TIR display for that week, a trend statement, a display of “bad” foods that tend to raise the user’s glucose levels above the target range, and a display of “good” foods that, after the user ate, kept glucose within the range or had a TA180 below a certain threshold. Bad and good foods may be placed in separate tabs that the user can switch between. Individual meals may be displayed on meal cards that may include a magnified photo of the meal, the name of the meal, the size of the meal, the date and time the meal was consumed, and TIR displays for the period before and after the meal (e.g., two hours after the meal).
[0237] In an alternative embodiment of the application, as shown in Figures 14A and 14B, the user can access a list of meals ranked according to the corresponding recorded glucose levels. The meal ranking screen 970 can be accessed from the meal ranking icon 884 on the menu screen 880. The meal ranking screen 970 can list all meals logged over different periods 974 (e.g., daily, weekly, bi-weekly, monthly, all). In the meal list 972, meals can be ordered from the highest glucose level to the lowest glucose level, or alternatively, from the lowest glucose level to the highest glucose level, where the glucose level may be the highest glucose concentration associated with that meal event. As shown in Figure 14B, the user can select a meal, and the meal details screen 978 or log details screen 840 can open, displaying all the details of the meal, including a photo, description, maximum glucose level, time over 180, and a glucose concentration graph including the relevant period over which the meal was eaten.
[0238] As shown in Figures 13D-1 to 13D-3, in an alternative embodiment of the application, the user may also have access to a time-of-day (TOD) instance ranking instead of a meal-specific ranking. The user can view meals, beverages, and snacks by each TOD instance. As shown in the alternative home screen 980, the user can easily view meals and beverages related to the glucose response curve, along with the daily TIR display 852. By clicking a meal icon, the user can open a log details screen 984 that provides more detailed information about the meal, which may include a photo of the meal, a description, and the time above range from which that meal occurred.
[0239] Alternative TIR displays are shown in Figures 15A–C, which highlight range time using a circle (Figure 15A), highlight the percentage of range time using a circle with a shaded portion (filling a bucket) (Figure 15B), and highlight range time using a bar (Figure 15C). As seen in Figure 15A, the TIR display 1002 shows a circle with the target (number of hours in TIR) inside. The current number of hours spent by the user in the target / target range can be displayed in two ways: the number may be listed inside the circle along with the target value, or the number of hours may be visually displayed as a band or progress indicator (e.g., colored green) extending around the circle to X% of the circle's circumference to indicate that the user has spent X% of TIR (where X% is the time spent in range divided by the target time (hours)). As seen in Figure 15B, the TIR display 1004 shows a circle with the target percentage listed near the circle (e.g., above or below). The percentage of TIR can be displayed in two ways: the numerical value may be listed inside a circle, or the number of hours may be visually represented as a band or progress indicator (e.g., black) extending along the circumference of the circle to X% of the circle's circumference to indicate that the user has spent X% of TIR. The inside of the circle may also be partially shaded to reflect the current percentage of TIR (similar to filling a bucket with water), where the shaded percentage is proportional to the percentage of TIR up to that point in the period. For example, if the user has 88% TIR, 88% of the circle's area will be shaded. As seen in Figure 15C, the TIR display 1006 can also visually show the user's TIR against the TIR target using bars or other progress indicators. The TIR display 1006 displays both the TIR target up to the current date and the TIR target up to the current week. The length of the bar may represent the total target, and the bar may be filled to represent the percentage of TIR achieved by the user for that particular period. The daily and weekly TIR bars can be different colors.
[0240] In an alternative embodiment, as seen in Figures 16A-1 to 16A-2, the TIR display 1010 can display the elapsed time within the range, along with the range time and target time reported at the center of the circle. A band or progress indicator (e.g., colored green) can extend along the perimeter of the circle to X% of the circle's circumference to indicate that the user has spent X% of the TIR (where X% is the time spent within the range divided by the target time (hours)). For example, in Figure 16A-1, the user has been within the range for 11 hours so far, and the circle shows a visual representation of the percentage of time within the range relative to the time target (16 hours) using a band or progress indicator (e.g., colored green) that extends along the perimeter of the circle to cover 11 / 16 of the circle's circumference. Figure 16A-2 shows the elapsed time within the target / target range at the end of the day. Figures 16B-1 to 16B-2 illustrate alternative TIR displays 1012, 1014, 1016, and 1018 with a simple ring option. TIR displays 1012, 1014, 1016, and 1018 display the current percentage of TIR in the center or within a circle and include bands to visually indicate TIR, as described in other TIR displays. Instead of listing target percentages within the circle, alternative TIR displays 1016 and 1018 may include markers that intersect with the circle at positions along its perimeter corresponding to the target percentage, allowing the user to quickly determine whether their TIR percentage is above or below the target percentage. Figures 16C-1 to 16C-2 illustrate alternative TIR displays 1020, 1022, 1024, 1026, and 1028 with a cumulative ring option. TIR displays may compare two or more different time periods.For example, the TIR display can show TIR displays up to the present time in the current week and up to the present time on the current date (1020), TIR displays up to the present time in the current week and up to the previous week without a circle (1022), TIR displays up to the present time in the current week and up to the previous week with a circle (1024), TIR displays up to the present time on the current date and up to the present time in the current week (1026), and TIR displays up to the previous week and up to the present time in the current week (1028). Figures 16D-1 to 16D-2 show alternative TIR displays 1030, 1032, 1034, and 1036 with alternative cumulative ring options that report the percentage spent on the target / target range at the center of the circle and a colored band (progress indicator) showing the relative percentage of TIR along a portion of the perimeter of the circle. The TIR display optionally includes a marker of the target percentage along the perimeter of the circle corresponding to the relative position of the target.
[0241] Figures 17A and 17B show further alternative TIR displays that indicate the percentage of time spent within range using a shaded circle (filling a bucket). The target percentage or time can be listed near the circle. Figure 17A reports TIR as a percentage of 1040, and Figure 17B reports TIR as a total of 1044 hours. For each TIR display, the center of the circle can be shaded to indicate the target percentage the user was within range, where the shaded percentage is proportional to the percentage of TIR up to the present time for that period.
[0242] Figures 18A and 18B show a further alternative TIR display that uses a progress bar to indicate the time within the range. The progress bar having a length equal to the target time or percentage can have a progress indicator (shaded or colored extension) for explaining the user's TIR. For example, if the target is to be within 16 hours of a day and the user is within the range for 14 hours, the progress indicator (shaded or colored extension) can fill 14 / 16 of the entire bar. The TIR display can show the TIR for that day (1050), or both the TIR for that day and that week (1054), or report other periods (e.g., the previous week, the previous month, or the current month).
[0243] TIR Banking As described above, the diet monitoring application may calculate a tracking metric and display it to the user in a way that indicates whether it is ahead of or behind the TIR target. Specifically, the tracking metric may be the average postprandial TA180 metric over all of the logged meals for the previous week. The postprandial TA180 is not the same as the TA180 metric calculated over the entire 24 hours and may be larger. These two metrics are correlated to some extent, and the linear correlation coefficient (or other function fit) can be estimated based on either population data, per person, or both.
[0244] The postprandial TA180 metric can be displayed in a number of ways. The TA180 can be displayed as is, or it can be converted to a value equivalent to 24 hours by applying the correlation coefficient. The diet monitoring application can provide a default 24-hour TA180 target value and / or require / allow the user to set the value. Typical TA180 target values considered to be under good control for diabetics are about 30%, alternatively about 25% - about 35%, alternatively about 20% - about 40%.
[0245] According to several embodiments, a dietary monitoring application can determine a target value set at a level that is achievable for the user, based on past glucose data collected from the user (e.g., over one or two days). For example, if the measured TA180 is substantially greater than 30%, the app can determine an achievable target TA180 that is approximately 5% to 10% lower than the measured value. The dietary monitoring application can also determine a new target value after the user has achieved or is close to achieving a past goal. It is also possible for the dietary monitoring application to determine a new target value only after the user has maintained the current goal for a certain period of time.
[0246] The meal monitoring application can display tracking metrics as progress bars. When a new goal is set, the tracking metrics can begin averaging subsequent meals, excluding meals eaten before the new goal was set. An example of a progress bar is shown in Figure 19A.
[0247] The progress bar 1060 can indicate that the user is ahead of the goal, meaning that the user is taking good behaviors by choosing foods and avoiding overeating, thereby exceeding the goal. The shaded bar extension 1064 to the right of the midline 1062 (e.g., shaded green) is proportional to the difference between the average measurement TA 180 and the goal, assuming that the measurement is smaller (better) than the goal.
[0248] In contrast, Figure 19B shows an example of a progress bar when the measured TA180 is greater than (worse than) the target. The shaded bar extension 1066 to the left of the median line 1062 is proportional to the difference between the target and the average measured TA180, assuming that the measured value is greater than (worse than) the target. This example of a progress bar shows that the user is behind the target, meaning that the user is not taking good behaviors such as selecting foods and avoiding overeating, and is not reaching the target goal. The progress bar 1060 may or may not actually show the measured TA180 value and the target value, or the difference between them.
[0249] As shown in Figure 19C, a meal monitoring application can help users "bank" lower-than-target TA180s, with the aim of making them feel that it's okay to eat "bad" meals without falling behind their goals. The purpose of this feature is to make users feel more in control by managing their glucose levels. For example, a meal monitoring application can list logged meals that the application considers "bad" based on the recorded TA180s for those meals, as described with reference to other embodiments. This would be done, for example, by determining a "bad" meal-after TA180 threshold by applying a correlation coefficient to a target TA180 or a fixed TA180, such as 30%. In some embodiments, for example, the application can display "bad" meals and provide a user interface (UI) means for the user to identify bad meals that they actually want to continue eating (e.g., without which they cannot live).
[0250] Figure 19C shows an exemplary embodiment of a progress bar displaying additional information to facilitate the “banking concept.” The width of this meal impact indicator 1068 corresponds to the TA180 previously measured for that meal, showing how that meal may contribute to / change the average TA180 index. For example, assuming the average is one week's worth of meals, that would be 7 × 3 = 21 meals. With a target of 30%, the average measured TA180 is 24%, and the TA180 for a “bad” meal is 45%. This bad meal falls within the margin (green bar).
[0251] Impact = 45% / 21 = 2.1% Margin = 30% - 24% = 6% Figure 19C can show that because the user is behaving very well, they can easily eat their favorite "bad" foods without jeopardizing the progress indicator. This encourages the user to try to behave well and reward themselves later. In some embodiments, the progress bar can rotate through all the favorite foods shown, either each time it is displayed or via a timer. Alternatively, or in addition to the above, the application can provide the user with a means to select their favorite foods or to toggle through all selections, and the app would calculate and display the "impact" (i.e., the percentage progressed beyond the goal) needed to cover that meal.
[0252] alert The application may also display various alerts and notifications that remind and / or recommend the user to log their meals in order to help the user improve or maintain blood glucose control. For example, a lock screen notification may appear to inform the user that a high glucose meal has been detected and prompt the user to log good foods based on the detected glucose spike. Alternatively, the notification may be a celebratory notification that informs the user that they have stayed within range after a meal or that they have logged a certain number of meals. The application may also present an in-app modal to remind and / or recommend the user in response to the user tapping a notification on the lock screen. The in-app modal may be a more vivid and visual modal within the application that provides more context to prompt action. The in-app modal may present graphics and text that gently encourage the user to log their meals by reminding the user that there can be many reasons for the detected glucose spike and that logging their meals will help identify the cause of the glucose spike. The in-app modal may include possible answers such as allowing the user to indicate that they have not eaten anything, or allowing the user to select a link to add food, which may open a food logging screen (an example of which is described elsewhere in this application). Alternatively, the in-app modal may be a celebratory notification, for example, including words of encouragement and graphics that praise the user for staying within their goals.
[0253] guidance In an alternative embodiment, the user may have access to a guidance GUI that provides insights into a number of statistics and metrics about how the user has spent the week so far. The guidance GUI may include a counter showing the user's progress in meeting milestones, such as how many meals have been logged that week, and a progress indicator that graphically shows how many more meals need to be logged to meet the goal, for example, logging 10 meals. The guidance GUI may also include a TIR display up to the end of the day or the end of the week, which may be displayed to make it easy for the user to see how well they are managing their glucose. Grouping of meals consumed above and below the weekly range may be accessible in a separate tab. These groupings may include foods from different types of meals grouped together. These groupings may allow the user to know whether each logged meal was a good or bad meal without having to wait to view a summary of the weekly insights report. Groupings of out-of-range meals may be colored red, and groupings of within-range meals may be colored green. The guidance GUI may also include a recommendations section, which may contain a list of dietary and / or food recommendations that may help the user increase TIR to achieve their goals. The recommendations may include a list of ADA-approved dietary suggestions and may also include other dietary and food options that have been determined to have a positive effect on the user's TIR and improve glycemic control, or alternatively, have been determined to have a positive effect on glycemic control in the population or subset of the population to which the user belongs (e.g., relevant postprandial glucose traces remained within the target range). The suggested dietary or food may include the name of the dietary or food, a photograph, and the type of meal it is suggested for (e.g., breakfast, lunch, dinner, and / or snack).
[0254] The GUI associated with the various tabs on the logbook screen may also include information from the application. The log GUI may include a list of various events detected on a given day, such as meals, alarms, exercise, and insulin administration. Each input may include glucose level, trend arrows, a graphical representation of the event type, and time. The logbook graph GUI may include a glucose trace with the target or target range highlighted in green. Event markers, which may be color-coded, corresponding to the various events listed in the log GUI may also be plotted on the glucose trace. For event markers corresponding to meals, a window may appear associated with the event marker, listing the time of the event, glucose level, and graph symbol. In addition, the graph GUI may include meal tiles associated with meal event markers. Meal tiles may include the name of the meal, a photo of the meal, tags, a text description, quantity, and time / date of the meal. The logbook insights GUI may include a TIR tile, which includes a TIR display up to the current point in the day or the current point in the week, and may be displayed in a way that makes it easy for the user to see how well they are managing their glucose along with their target TIR. The Insight GUI may also include a glucose tile containing a graphical representation of the glucose level for the day, in addition to a list of the highest glucose level recorded for the day along with the time it was recorded, the lowest glucose level recorded for the day along with the time it was recorded, and the percentage of time spent when within range, above the high glucose threshold ("very high"), and outside the range (which may include time spent above the target range (e.g., above the lower glucose threshold rather than the high glucose threshold) and below the target range). The graphical representation may be in the shape of a circle with color-coded sections corresponding to the percentage of time spent when within range, above range, and outside the range.The Insight GUI may also include a food tile that lists the amount of carbohydrates consumed that day, the daily target amount of carbohydrates, the number of meals logged, the number of meals within the range, and the number of meals above the range. The Insight GUI may also include an exercise tile that lists the amount of time exercised and / or the duration of exercise.
[0255] Evaluation and Recommendations The application may also be able to identify good and bad meals over time. In one exemplary method, as shown in Figure 20A, method 1300 for analyzing dietary data may include receiving an entered log entry associated with the consumed meal in step 1302. The log entry may include the contents and size of the consumed meal.
[0256] In step 1304, the ingested meal may be associated with at least one postprandial glucose trace. The postprandial glucose trace may include analyte levels from the start time (or estimated start time) of the meal to the end time. The end time may be at least about 2 hours, alternatively at least about 4 hours, alternatively at least about 4.5 hours, or alternatively around the start time of the next meal.
[0257] In step 1306, the grade of the ingested meal may be determined based on at least one characteristic of at least one postprandial glucose trace.
[0258] In step 1308, the grade may be displayed in the graphical user interface in relation to the diet consumed.
[0259] The steps described above are merely illustrative, and possible methods include those in a different order, or those in which certain steps are omitted or added.
[0260] This application may also be able to identify good and bad foods over time. In one exemplary method, as shown in Figure 20B, method 1320 for analyzing dietary data may include, in step 1322, receiving entered log entries associated with the consumed meal, and in step 1324, identifying at least one food contained in the consumed meal. In step 1326, at least one food may be associated with at least one postprandial glucose trace related to the consumed meal. In step 1328, a food grade may be determined based on the postprandial glucose trace. In step 1330, the grade for the food may be displayed in a graphical user interface in relation to at least one food. The steps described above are illustrative only, and conceivable methods include methods in which the steps are in a different order, or in which certain steps are omitted or added.
[0261] The application may also be able to identify good and bad foods for different populations. In one exemplary method, as seen in Figure 20C, method 1340 for analyzing dietary data may include, in step 1342, receiving entered log entries associated with a ingested meal, and in step 1344, identifying at least one food contained in the ingested meal. In step 1346, the at least one food may be associated with at least one postprandial glucose trace related to the ingested meal. In step 1348, the application may store at least one food and at least one postprandial glucose trace related to the ingested meal in a database. The database may contain multiple foods and associated postprandial glucose traces for a population.
[0262] In step 1350, the application may determine a grade for at least one food. The grade may be based on a subset of postprandial glucose traces associated with at least one food. The subset of postprandial glucose traces may be based on or associated with a population segment. A population segment may have common disease conditions, such as prediabetes, type 1 diabetes, type 2 diabetes, or gestational diabetes. For example, a segment of users diagnosed with type 2 diabetes may have a high incidence of high-fat, high-calorie foods classified as very bad, while for other segments, such as users with prediabetes and type 1 diabetes, these types of foods are mainly classified as moderately bad. Therefore, the system may report that this category of foods is likely to be bad for users with type 2 diabetes, but for other user segments, the system may report that these types of foods are only moderately bad.
[0263] In step 1352, the application may display a grade associated with at least one food product in its graphical user interface.
[0264] The steps described above are merely illustrative, and possible methods include those in a different order, or those in which certain steps are omitted or added.
[0265] The application may also classify users based on how they react to various foods and recommend different foods based on the classification. In one exemplary method, as seen in Figure 20D, method 1360 for recommending food selection may include, in step 1362, receiving an entered log entry from the user associated with a meal consumed, and in step 1364, identifying at least one food contained in the meal consumed. In step 1366, the application may associate at least one food with at least one postprandial glucose trace associated with the meal consumed. In step 1368, the application may determine a classification of at least one food based on at least one characteristic of the at least one postprandial glucose trace.
[0266] In step 1370, the application may analyze classification and at least one food using a population model that includes a database of food classifications and associated foods for multiple population segments. The database may include meals, postprandial glucose traces, user demographics, and user preferences. The population model may use machine learning techniques to divide the population into multiple population segments. The population model may include a first model that assigns users to segments of the multiple population segments based on an analysis of classification, at least one food, at least one postprandial glucose trace associated with at least one food, user demographic information, and / or user preferences. The population model may also include a second model that maps segments of the multiple population segments to multiple good food items and multiple bad food items.
[0267] In step 1372, the application may associate the user with a segment of multiple population segments based on classification and at least one food. A segment of multiple population segments may be associated with multiple foods that have a positive classification. In step 1374, the application may display recommended foods. A recommended food may be one of multiple foods that have a positive classification for a segment of multiple population segments.
[0268] The steps described above are merely illustrative, and possible methods include those in a different order, or those in which certain steps are omitted or added.
[0269] The application may also sort or classify meals and foods as good and bad foods and display a current count of the meals or foods analyzed. In one exemplary method 1380, as shown in Figure 21, in step 1382, the application may classify several foods as good or bad foods based on the effect of each of several foods on the subject's postprandial glucose level. In step 1384, the application may display several foods that have been determined to be good for the subject. In step 1386, the application may display several foods that have been determined to be bad for the subject. In step 1388, the application may display a counter indicating the number or quantity of foods sorted or classified as good and bad foods.
[0270] The application may also prioritize TODs with the highest glucose pattern, such as the TOD period with the longest duration above the threshold amount or the TOD period with the highest AUC. The system may also determine and display recommendations for alternative foods or meals that the user should try to improve blood glucose control.
[0271] In one exemplary method 1390, in Figure 22A, in step 1392, the application may determine the TOD period having the highest glucose pattern based on an index determined by reference to the upper glucose threshold. As shown in other parts of the present application, the upper glucose threshold may be about 180 mg / dL, alternatively about 175 mg / dL, alternatively about 170 mg / dL, alternatively about 190 mg / dL, or alternatively about 200 mg / dL, and may vary from individual to individual.
[0272] In step 1394, the application may determine the meals most frequently logged during the TOD period with the highest glucose pattern. The meals most frequently logged during the TOD period with the highest glucose pattern may be associated with postprandial glucose traces with a high glucose pattern.
[0273] In step 1396, the application may display alternative meal suggestions to replace the meals most frequently logged during the TOD period with the highest glucose pattern.
[0274] The method may also include additional steps. For example, it may include a step of displaying a comparison between the postprandial glucose trace associated with an alternative meal suggestion and the postprandial glucose trace associated with the most frequently logged meal after the user ate the alternative meal suggestion. The method may also include a step of displaying the alternative meal suggestion in a list of frequently logged foods. The alternative meal suggestion may be displayed at the top of the list. The method may also include a step of determining the alternative meal suggestion by searching a database of healthy options for TOD periods with the highest glucose pattern.
[0275] The application can also facilitate experimentation with other foods based on natural language learning. As shown in Figure 22B, one exemplary method 1400 describes a method for recommending alternative food options. In step 1402, the application receives an input log entry associated with a meal consumed. The input log entry may include a text description of the meal consumed. In step 1404, the application may identify at least one food included in the text description of at least one logged meal. In step 1406, the application may associate at least one food with at least one postprandial glucose trace associated with the meal consumed. In step 1408, the application may determine the classification of at least one food as positive or negative, good or bad, or other equivalent classifications, based on the effect of at least one food on the postprandial glucose trace.
[0276] In step 1410, the application may store in a database at least one food, at least one postprandial glucose trace associated with the ingested meal, and a classification. The database may include multiple foods, associated postprandial glucose traces, and classifications for populations and multiple alternative food options.
[0277] In step 1414, in response to classifying at least one food as a bad food, the application may determine an alternative food option from several alternative food options. The alternative food option may be classified as a good food for multiple individuals. In step 1416, the application may display a recommendation that includes the alternative food option as a substitute for at least one food classified as a bad food.
[0278] The method may also include the steps of determining the TOD period with the highest glucose pattern for the user based on an index determined by referencing an upper glucose threshold, determining the food that was most frequently logged during the TOD period with the highest glucose pattern, and displaying additional alternative food options to replace the most frequently logged food.
[0279] The method may also prompt the user for input regarding food preferences and, based on the database and the food preferences entered by the user, display additional alternative food options to replace at least one food classified as a bad food.
[0280] The application can also assign new grades to meals or foods, or remove grades from associations with meals or foods. As shown in Figure 23, one exemplary method 1430 illustrates how meal or food data is analyzed. In step 1432, the application may receive user-entered log entries associated with consumed meals or foods.
[0281] In step 1434, the application may determine a grade for the ingested meal or food based on at least one characteristic of at least one postprandial glucose trace associated with the ingested meal. In step 1436, the application may display the grade in relation to the meal. For example, the grade may be modified by the user. Meal-related grade.
[0282] The grade may be changeable. The grade may be removed after a certain period of time has passed since the grade was first assigned to or associated with a meal or food, or may no longer be associated with a meal. Optionally, the method may include step 1438, which allows a new grade to be determined for a meal or food after a certain period of time has passed since the initial grade was assigned, or the user may change the grade. This period may be approximately 6 months, alternatively 3 months, alternatively 4 months, or alternatively 5 months.
[0283] For the various methods described, meals and foods may be graded based on various characteristics of the postprandial glucose traces associated with the meal. A meal or food may be assigned a poor grade in a variety of circumstances, including but not limited to the determination that at least one postprandial glucose trace contains at least two postprandial glucose traces with a high glucose pattern, and at least one postprandial glucose trace does not contain at least one postprandial glucose trace with a range postprandial pattern. A meal or food may be assigned a good grade in a variety of circumstances, including but not limited to the determination that at least one postprandial glucose trace contains at least one postprandial glucose trace with a range postprandial pattern. A meal or food may be assigned an indeterminate grade in a variety of circumstances, including but not limited to the determination that at least one postprandial glucose trace does not contain at least one postprandial glucose trace with a range postprandial pattern, and does not contain at least two postprandial glucose traces with a high glucose pattern.
[0284] A high glucose pattern can be based on the area under the curve above approximately 180 mg / dL, or alternatively, the amount of time above approximately 180 mg / dL. The target range for determining the amount of time within that range may be approximately 70 mg / dL to 180 mg / dL.
[0285] The grade may be represented as a number or letters. Alternatively, the grade may be represented as multiple stars, with more stars indicating a better grade and fewer stars indicating a lower grade. For example, the grading could be based on a model that maps the input to a grade variable, for example, in the range of 0 to 4, where 0 corresponds to one star and 4 corresponds to five stars.
[0286] In one embodiment, the grade may also be based on a relationship between the start time of an ingested meal and at least one characteristic. In another embodiment, the grade may also be based on additional logged meals, each associated with at least one postprandial glucose trace. Additionally or alternatively, the grade may further be based on a model that maps multiple inputs to a grade variable.
[0287] Various aspects of this subject matter are described below in connection with and / or supplement to the embodiments described herein, with an emphasis here on the interrelationships and interchangeability of the embodiments described below. In other words, unless otherwise specified or unless it is logically impossible, the fact that each feature of an embodiment can be combined with any other feature is emphasized. The embodiments described herein are reproduced and expanded upon in the following paragraphs without express reference to the drawings.
[0288] In many cases, methods for processing analyte data are provided. The methods include the steps of receiving analyte data sensed from an individual; detecting episodes of the received analyte data; displaying a first episode marker associated with the detected episode on a graph of the analyte data; providing a screen configured to receive information about the detected episode; and, after receiving information about the detected episode, displaying a second episode marker associated with the detected episode on a graph of the analyte data.
[0289] In some embodiments, the method further includes the step of displaying a notification indicating that an episode has been detected. In some embodiments, the step of displaying the notification includes the step of displaying a numerical value on an icon corresponding to the number of detected episodes. In some embodiments, the numerical value is incremented when an episode is detected. In some embodiments, the numerical value is decremented after information about the detected episode has been received. In some embodiments, the numerical value is decremented after a predetermined amount of time has elapsed since the episode was detected.
[0290] In some embodiments, the step of displaying a notification includes the step of displaying an alert.
[0291] In some embodiments, the first episode marker is different from the second episode marker.
[0292] In some embodiments, the first episode marker includes a question mark.
[0293] In some embodiments, the second episode marker includes an image related to the received information.
[0294] In some embodiments, the second episode marker includes X.
[0295] In some embodiments, the detected episode is an out-of-range episode.
[0296] In some embodiments, the first episode marker is placed at a time on the graph of the analyte data at the estimated start time of the detected episode.
[0297] In some embodiments, the analyte data is glucose data.
[0298] Many methods are provided for processing analyte data using an in vivo analyte monitoring system, which includes the steps of: receiving analyte data sensed from an individual; processing the analyte data to detect, by a processing circuit, multiple portions of analyte data that meet a criterion over a period of time; and associating one or more feeding events with one or more of the multiple portions of analyte data, wherein each of the one or more feeding events has a relevant time period in which one or more of the associated portions of the multiple portions of analyte data met the criterion.
[0299] In some embodiments, this criterion requires that a portion of the analyte data exceed the threshold analyte concentration level over a certain period of time. In some embodiments, the threshold analyte concentration level is approximately 180 mg / dl.
[0300] In some embodiments, this criterion requires that a portion of the analyte data fall within a specified range over a certain period. In some embodiments, this range is defined by a minimum analyte concentration level of approximately 80 mg / dL to a maximum analyte concentration level of approximately 170 mg / dL.
[0301] In some embodiments, this period is approximately 30 minutes.
[0302] In some embodiments, the method further includes the step of ranking each of one or more meal events according to their relevance time. In some embodiments, the relevance time of each of the one or more meal events is ranked in ascending order. In some embodiments, the method further includes the step of displaying a group of one or more meal events, each of which has a relevance time ranked as one of the top five longest relevance times of the one or more meal events. In some embodiments, each of the displayed group of one or more meal events is associated with a first period of day. In some embodiments, the first period of day is the period in which multiple portions of the analyte data meet the criteria of the highest time amount. In some embodiments, this criterion requires that a portion of the analyte data is within a range over a certain period of time. In some embodiments, this criterion requires that a portion of the analyte data is above a threshold analyte concentration level over a certain period of time. In some embodiments, the method further includes the step of displaying a graph of the analyte data over time, with the first period of day highlighted. In some embodiments, the method further includes the step of displaying a second group of one or more meal events, each of which has an associated time ranked as one of the top five longest associated times of one or more meal events, and each of the displayed second group of one or more meal events is associated with a second period of day, which is different from a first period of day. In some embodiments, this criterion requires that a portion of the analyte data is within a range over a period of time. In some embodiments, this criterion requires that a portion of the analyte data is above a threshold analyte concentration level over a period of time. In some embodiments, the method further includes the step of displaying a graph of analyte data over time, with a first period of day highlighted.
[0303] In many cases, a method is provided for displaying a graphical interface relating to physiological analyte data and dietary information on the electronic interface of a device, the method including the steps of: receiving analyte data sensed from an individual; processing the analyte data and, by a processing circuit, detecting multiple portions of the analyte data that satisfy a criterion over a period of time; generating multiple displays of dietary events, each of which displays corresponds to when one of the multiple portions of the analyte data satisfies a criterion over a period of time; associating dietary information, event time, and associated time with at least one of the multiple displays of dietary events, where associated time is the amount of time during which one or more corresponding portions of the multiple portions of the analyte data satisfy the criterion; and displaying a first grouping of at least one of the multiple displays of dietary events having associated dietary information, where the event time of each display of dietary events in the first grouping occurs in a first period of a day.
[0304] In some embodiments, the method further includes the step of displaying a graph element that shows the amount of time during which the analyte data is within a target range for a second period.
[0305] In some embodiments, the first period is determined to have the highest amount of time during which multiple portions of the analyte data satisfy a criterion. In some embodiments, the criterion requires that a portion of the analyte data exceeds a threshold analyte concentration level over a certain period of time. In some embodiments, the threshold analyte concentration is approximately 180 mg / dL, and the period is approximately 30 minutes. In some embodiments, the criterion requires that a portion of the analyte data falls within a certain range over a certain period of time. In some embodiments, this range is defined by a minimum analyte concentration level of approximately 80 gm / dL to a maximum analyte concentration level of approximately 170 mg / dL.
[0306] In some embodiments, the method further includes the step of displaying a statement indicating which period of the day has the highest amount of time during which multiple parts of the analyte data meet the criteria.
[0307] In some embodiments, the method further includes the step of displaying a second grouping of at least a portion of a plurality of displays of meal events having associated meal information, wherein the event time of each display of meal events in the second grouping occurs in a second period of the day, and the second period is different from the first period.
[0308] In some embodiments, the associated time for at least a portion of the multiple representations of a meal event is ranked in ascending order. In some embodiments, each of the first groupings has associated time ranked as one of the top five longest associated times for at least a portion of the multiple representations of a meal event. In some embodiments, the first period of a day is the period in which multiple portions of the analyte data meet the criterion of the highest amount of time.
[0309] In many embodiments, a method is described for displaying a graphical interface relating to physiological analyte data on the electronic interface of a device, the method comprising the steps of: receiving analyte data sensed from an individual; determining the amount of time the received analyte data is within a target range for a first period; and displaying a first graph element indicating the amount of time the analyte data is within a target range for a first period, wherein the first graph element includes a numerical value corresponding to the amount of time the received analyte data is determined to be within a target range for a first period, and a progress indicator having a length proportional to the amount of time the analyte data is determined to be within a target range for a first period.
[0310] In some embodiments, the first period is the current date.
[0311] In some embodiments, the first period is selected from the group consisting of the current date, the current week, and the previous week.
[0312] In some embodiments, the progress indicator is part of the progress bar.
[0313] In some embodiments, the progress indicator is part of a pie chart.
[0314] In some embodiments, the method further includes the step of displaying a target associated with a progress indicator.
[0315] In some embodiments, the method further includes a second graph element indicating the amount of time during which the analyte data is within a target range for a second period, the second graph element including a numerical value corresponding to the amount of time during which the received analyte data is determined to be within the target range for the second period, and a progress indicator having a length proportional to the amount of time during which the analyte data is determined to be within the target range for the second period. In some embodiments, the method further includes a third graph element indicating the amount of time during which the analyte data is within a target range for a third period, the third graph element including a numerical value corresponding to the amount of time during which the received analyte data is determined to be within the target range for the third period, and a progress indicator having a length proportional to the amount of time during which the analyte data is determined to be within the target range for the third period. In some embodiments, each of the first, second, and third periods is individually selected from the group consisting of the current date, the current week, and the previous week.
[0316] In many embodiments, a method for displaying a graphical interface relating to physiological analyte data on an electronic interface of a device, the method comprising the steps of: receiving analyte data sensed from an individual; determining the amount of time the received analyte data is within target ranges for first, second, and third periods; and displaying on the electronic interface a first graph element showing the amount of time the analyte data is within target ranges for first period, a second graph element showing the amount of time the analyte data is within target ranges for second period, and a third graph element showing the amount of time the analyte data is within target ranges for third period, each of the first, second, and third graph elements including first, second, and third progress indicators, the length of which is proportional to the amount of time the analyte data is determined to be within target ranges for first, second, and third periods, respectively.
[0317] In some embodiments, the first period is the current date.
[0318] In some embodiments, the second period is the previous week.
[0319] In some embodiments, the third period is the current week.
[0320] In some embodiments, each of the first, second, and third graph elements constitutes at least a portion of a circular shape, and the first, second, and third progress indicators extend along the perimeter of each of the at least portions of the circular shape of the first, second, and third graph elements.
[0321] In some embodiments, each of the first, second, and third graph elements further includes a target indicator associated with a target value, where the target value corresponds to the amount or percentage of time the analyte data is within a target range. In some embodiments, the target indicator is positioned along the perimeter of at least a portion of a circular shape, and the position of the target indicator is proportional to the target value.
[0322] In some embodiments, the method further includes the step of displaying a numerical representation of the amount of time during which the received analyte data is determined to be within the target range for first, second, and third periods, in relation to the first, second, and third graph elements, respectively. In some embodiments, the numerical representation of the amount of time during which the received analyte data is determined to be within the target range is displayed at the center of at least a portion of the circular shape of the first, second, and third graph elements. In many embodiments, an apparatus is provided for processing analyte data, comprising a non-volatile memory on which a program is stored, an input unit configured to receive measured analyte data, and a processor connected to the non-volatile memory and the input unit, wherein the processor is configured to execute a program, and the execution of the program causes the processor to detect episodes of the received analyte data, display a first episode marker associated with the detected episode on a graph of the analyte data, provide a screen configured to receive information about the detected episode, and, after receiving information about the detected episode, display a second episode marker associated with the detected episode on a graph of the analyte data.
[0323] In some embodiments, program execution causes the processor to display a notification indicating that an episode has been detected. In some embodiments, the notification display may include displaying a numerical value on an icon corresponding to the number of detected episodes. In some embodiments, the numerical value is incremented when an episode is detected. In some embodiments, the numerical value is decremented after information about the detected episode has been received. In some embodiments, the numerical value is decremented after a predetermined amount of time has elapsed since the episode was detected.
[0324] In some embodiments, the notification is displayed as an alert.
[0325] In some embodiments, the first episode marker is different from the second episode marker.
[0326] In some embodiments, the first episode marker includes a question mark.
[0327] In some embodiments, the second episode marker includes an image related to the received information.
[0328] In some embodiments, the second episode marker includes X.
[0329] In some embodiments, the detected episode is an out-of-range episode.
[0330] In some embodiments, the first episode marker is placed at a time on the graph of the analyte data at the estimated start time of the detected episode.
[0331] In some embodiments, the analyte data is glucose data.
[0332] In many embodiments, an apparatus for processing analyte data is provided, comprising a non-volatile memory on which a program is stored, an input unit configured to receive measured analyte data, and a processor connected to the non-volatile memory and the input unit, the processor being configured to execute a program, which in turn causes the processor to process the analyte data to detect multiple portions of the analyte data that satisfy a criterion over a period of time, and to associate one or more meal events with one or more of the multiple portions of the analyte data, wherein each of the one or more meal events has a related time in which one or more of the associated portions of the multiple portions of the analyte data satisfy the criterion.
[0333] In some embodiments, this criterion requires that a portion of the analyte data exceeds a threshold analyte concentration level over a certain period of time. In some embodiments, the threshold analyte concentration level is approximately 180 mg / dl.
[0334] In some embodiments, this criterion requires that a portion of the analyte data fall within a specified range over a certain period. In some embodiments, this range is defined by a minimum analyte concentration level of approximately 80 mg / dL to a maximum analyte concentration level of approximately 170 mg / dL.
[0335] In some embodiments, this period is approximately 30 minutes.
[0336] In some embodiments, program execution further causes the processor to rank each of one or more meal events according to their relevance time. In some embodiments, the relevance time of each of the one or more meal events is ranked in ascending order. In some embodiments, program execution further causes the processor to display a group of one or more meal events, each of which has a relevance time ranked as one of the top five longest relevance times of the one or more meal events. In some embodiments, each of the displayed group of one or more meal events is associated with a first period of the day. In some embodiments, the first period of the day is the period in which multiple portions of the analyte data meet a criterion of the highest amount over time. In some embodiments, this criterion requires that a portion of the analyte data is within a range over time. In some embodiments, this criterion requires that a portion of the analyte data is above a threshold analyte concentration level over time. In some embodiments, program execution further causes the processor to display a graph of the analyte data over time, with the first period of the day highlighted. In some embodiments, program execution further causes the processor to display a second group of one or more meal events, each of which has an associated time ranked as one of the top five longest associated times of one or more meal events, and each of the displayed second group of one or more meal events is associated with a second period of day, the second period of day being different from a first period of day. In some embodiments, this criterion requires that a portion of the analyte data is within a range over a certain period of time. In some embodiments, this criterion requires that a portion of the analyte data is above a threshold analyte concentration level over a certain period of time. In some embodiments, program execution further causes the processor to display a graph of analyte data over time, with the first period of day highlighted.
[0337] In many embodiments, the device is for displaying a graphical interface on the electronic interface of a device relating to physiological analyte data and dietary information, the device comprising a non-volatile memory on which a program is stored, an input unit configured to receive measured analyte data, a display configured to visually present an analysis of the measured analyte data, and a processor connected to the non-volatile memory, the input unit, and the display, the processor being configured to execute a program, the execution of which causes the processor to perform the steps of: detecting multiple portions of analyte data that exceed a threshold analyte concentration level over a certain period of time; generating multiple displays of dietary events, each of which corresponds to the time when one of the multiple portions of analyte data exceeded a threshold analyte concentration level for a minimum threshold time; associating dietary information and event times with at least a portion of the multiple displays of dietary events; and controlling the display to visually present a first grouping of at least a portion of the multiple displays of dietary events having the associated dietary information, each of which event times of the displays of dietary events within the first grouping occur within a first period of a day.
[0338] In some embodiments, program execution further causes the processor to display a graph element indicating the amount of time during which the analyte data is within a target range for a second period.
[0339] In some embodiments, the first period is determined to have the highest amount of time during which multiple portions of the analyte data satisfy a criterion. In some embodiments, this criterion requires that a portion of the analyte data exceeds a threshold analyte concentration level over a certain period of time. In some embodiments, the threshold analyte concentration is approximately 180 mg / dL, and this period is approximately 30 minutes. In some embodiments, this criterion requires that a portion of the analyte data falls within a certain range over a certain period of time. In some embodiments, this range is defined by a minimum analyte concentration level of approximately 80 gm / dL to a maximum analyte concentration level of approximately 170 mg / dL.
[0340] In some embodiments, program execution further causes the processor to display a statement indicating which period of the day has the highest amount of time during which multiple parts of the analyte data meet the criteria.
[0341] In some embodiments, the execution of the program involves the processor displaying a second grouping of at least a portion of a plurality of displays of meal events having associated meal information, wherein the event time of each meal event in the second grouping occurs in a second period of the day, and the second period is different from the first period.
[0342] In some embodiments, the associated time for at least a portion of the multiple representations of a meal event is ranked in ascending order. In some embodiments, each of the first groupings has associated time ranked as one of the top five longest associated times for at least a portion of the multiple representations of a meal event. In some embodiments, the first period of a day is the period in which multiple portions of the analyte data meet the criterion of the highest amount of time.
[0343] In many embodiments, the device is for displaying a graphical interface related to physiological analyte data on the electronic interface of a device, the device comprising a non-volatile memory on which a program is stored, an input unit configured to receive measured analyte data and dietary information, a display configured to visually present an analysis of the measured analyte data, and a processor connected to the non-volatile memory, the input unit and the display, the processor being configured to execute a program, the execution of which causes the processor to determine the amount of time the received analyte data is within a target range for a first period, and to control the display to visually present a first graph element indicating the amount of time the analyte data is within a target range for a first period, the first graph element including a numerical value corresponding to the amount of time the received analyte data is determined to be within a target range for a first period, and a progress indicator having a length proportional to the amount of time the analyte data is determined to be within a target range for a first period.
[0344] In some embodiments, the first period is the current date.
[0345] In some embodiments, the first period is selected from the group consisting of the current date, the current week, and the previous week.
[0346] In some embodiments, the progress indicator is part of the progress bar.
[0347] In some embodiments, the progress indicator is part of a pie chart.
[0348] In some embodiments, program execution further causes the processor to display a target associated with a progress indicator.
[0349] In some embodiments, program execution causes the processor to determine the amount of time the received analyte data is within a target range for a second period, and to control the display to visually present a second graph element indicating the amount of time the analyte data is within a target range for a second period, wherein the second graph element includes a numerical value corresponding to the amount of time the received analyte data is determined to be within a target range for a second period, and a progress indicator having a length proportional to the amount of time the analyte data is determined to be within a target range for a second period. In some embodiments, program execution causes the processor to determine the amount of time the received analyte data is within a target range for a third period, and to control the display to visually present a third graph element indicating the amount of time the analyte data is within a target range for a third period, wherein the third graph element includes a numerical value corresponding to the amount of time the received analyte data is determined to be within a target range for a third period, and a progress indicator having a length proportional to the amount of time the analyte data is determined to be within a target range for a third period. In some embodiments, each of the first, second, and third periods is individually selected from the group consisting of the current date, the current week, and the previous week.
[0350] In many embodiments, the device is for displaying a graphical interface related to physiological analyte data on the electronic interface of a device, the device comprising a non-volatile memory on which a program is stored, an input unit configured to receive measured analyte data, a display configured to visually present an analysis of the measured analyte data, and a processor connected to the non-volatile memory, the input unit, and the display, the processor being configured to execute the program, and by executing the program, the processor determines that the received analyte data is within the target range for first, second, and third periods. The method involves determining the amount of time and controlling the display to visually present a first graph element showing the amount of time the analyte data is within the target range for a first period, a second graph element showing the amount of time the analyte data is within the target range for a second period, and a third graph element showing the amount of time the analyte data is within the target range for a third period, wherein each of the first, second, and third graph elements includes first, second, and third progress indicators, and the length of each progress indicator is proportional to the amount of time the analyte data is determined to be within the target range for the first, second, and third periods, respectively.
[0351] In some embodiments, the first period is the current date.
[0352] In some embodiments, the second period is the previous week.
[0353] In some embodiments, the third period is the current week.
[0354] In some embodiments, each of the first, second, and third graph elements constitutes at least a portion of a circle, and the first, second, and third progress indicators extend along the perimeter of each of the circular shapes of the first, second, and third graph elements.
[0355] In some embodiments, each of the first, second, and third graph elements further includes a target indicator associated with a target value, where the target value corresponds to the amount or percentage of time the analyte data is within a target range. In some embodiments, the target indicator is positioned along the perimeter of at least a portion of a circle, and the position of the target indicator is proportional to the target value.
[0356] In some embodiments, program execution further causes the processor to display numerical representations of the amount of time during which the received analyte data is determined to be within the target range for first, second, and third periods, in relation to the first, second, and third graph elements, respectively. In some embodiments, the numerical representations of the amount of time during which the received analyte data is determined to be within the target range are displayed at the center of at least a portion of the circular shape of the first, second, and third graph elements.
[0357] Many methods describe how to analyze dietary data. This method includes the steps of receiving an input log entry associated with an consumed meal, wherein the log entry includes the contents and size of the consumed meal; associating the consumed meal with at least one postprandial glucose trace; determining the grade of the consumed meal based on at least one characteristic of the at least one postprandial glucose trace; and displaying the grade associated with the consumed meal in a graphical user interface.
[0358] In some methods, the meal content includes a textual description of the meal.
[0359] In some methods, meals are selected from a list of frequently consumed items.
[0360] In some methods, a poor grade is assigned to an ingested meal in response to the determination that at least one postprandial glucose trace contains at least two postprandial glucose traces with a high glucose pattern.
[0361] In some methods, a poor grade is assigned to an ingested meal in response to the determination that at least one postprandial glucose trace does not contain at least one postprandial glucose trace with an within-range postprandial pattern.
[0362] In some methods, a good grade can be assigned to an ingested meal in response to the determination that at least one postprandial glucose trace contains at least one postprandial glucose trace with an within-range postprandial pattern.
[0363] In some methods, a non-deterministic grade is assigned to an ingested meal in response to a determination that at least one postprandial glucose trace does not include at least one postprandial glucose trace with a ranged postprandial pattern, and does not include at least two postprandial glucose traces with a high glucose pattern.
[0364] In some methods, the grade is represented by a star system, where more stars indicate a better grade, and fewer stars indicate a lower grade. In other methods, multiple gray stars indicate an uncertain grade.
[0365] In some methods, the grade is based on at least one characteristic of at least one postprandial glucose trace. In some methods, at least one characteristic is the degree of a high glucose pattern. In some methods, the degree of a high glucose pattern is based on the area under the curve above approximately 180 mg / dL. In some methods, the degree of a high glucose pattern is based on the amount of time above approximately 180 mg / dL. In some methods, at least one characteristic of at least one postprandial glucose trace is the amount of time within the target range. In some methods, the target range is approximately 70 mg / dL to approximately 180 mg / dL. In some methods, the grade is further based on the relationship between the start time of the ingested meal and at least one characteristic.
[0366] In some methods, the grade is further based on additional logged meals, and each additional logged meal is associated with at least one postprandial glucose trace.
[0367] In some methods, the grade is further based on a model that maps multiple inputs to a grade variable. In some methods, the grade variable ranges from 0 to 4, where 0 corresponds to a 1-star grade and 4 corresponds to a 5-star grade.
[0368] In many systems, a system for analyzing meal data is described. This system comprises an input unit configured to receive input log entries associated with ingested meals, the log entry including the contents and size of the ingested meal, a display configured to visually present the meal data, and one or more processors coupled to the input unit, the display, and a memory for storing instructions, wherein when an instruction is executed by one or more processors, the one or more processors are caused to associate the ingested meal with at least one postprandial glucose trace, determine the grade of the ingested meal based on at least one characteristic of the at least one postprandial glucose trace, and display the grade associated with the ingested meal in a graphical user interface.
[0369] In some systems, meal information includes a text description of the meal.
[0370] In some systems, meal contents are selected from a list of frequently consumed items.
[0371] In some systems, a poor grade is assigned to an ingested meal in response to the determination that at least one postprandial glucose trace contains at least two postprandial glucose traces with a high glucose pattern.
[0372] In some systems, a poor grade is assigned to an ingested meal in response to the determination that at least one postprandial glucose trace does not contain at least one postprandial glucose trace with an within-range postprandial pattern.
[0373] In some systems, a good grade is assigned to an ingested meal in response to the determination that at least one postprandial glucose trace contains at least one postprandial glucose trace with an within-range postprandial pattern.
[0374] In some systems, an indeterminate grade is assigned to an ingested meal in response to a determination that at least one postprandial glucose trace does not contain at least one postprandial glucose trace with a ranged postprandial pattern, and does not contain at least two postprandial glucose traces with a high glucose pattern.
[0375] In some systems, grades are represented by a star system, where more stars indicate a better grade, and fewer stars indicate a lower grade. In some systems, multiple gray stars indicate an uncertain grade.
[0376] In some systems, the grade is based on at least one characteristic of at least one postprandial glucose trace. In some systems, at least one characteristic is the degree of a high glucose pattern. In some systems, the degree of a high glucose pattern is based on the area under the curve above approximately 180 mg / dL. In some systems, the degree of a high glucose pattern is based on the amount of time above approximately 180 mg / dL. In some systems, at least one characteristic of at least one postprandial glucose trace is the amount of time within the target range. In some systems, the target range is approximately 70 mg / dL to approximately 180 mg / dL. In some systems, the grade is further based on the relationship between the start time of the ingested meal and at least one characteristic.
[0377] In some systems, the grade is further based on additional logged meals, and each additional logged meal is associated with at least one postprandial glucose trace.
[0378] In some systems, the grade is further based on a model that maps multiple inputs to a grade variable. In some ways, the grade variable ranges from 0 to 4, where 0 corresponds to a 1-star grade and 4 corresponds to a 5-star grade.
[0379] Many methods describe how to analyze dietary data. The methods include the steps of receiving an entered log entry associated with a meal consumed; identifying at least one food item in the meal consumed; associating at least one food item with at least one postprandial glucose trace associated with the meal consumed; determining the grade of at least one food item based on at least one characteristic of the at least one postprandial glucose trace; and displaying the grade associated with at least one food item in a graphical user interface.
[0380] In some methods, the input log entries include a text description of the consumed meal, and the step of identifying them includes a step of using natural language processing.
[0381] In some methods, at least one food item is assigned a poor grade in response to the determination that at least one postprandial glucose trace associated with the ingested meal contains at least two postprandial glucose traces with a high glucose pattern.
[0382] In some methods, at least one food is assigned a poor grade in response to the determination that at least one postprandial glucose trace does not contain at least one postprandial glucose trace having an within-range postprandial pattern.
[0383] In some methods, a good grade is assigned to at least one food in response to the determination that at least one postprandial glucose trace contains at least one postprandial glucose trace having an within-range postprandial pattern.
[0384] In some methods, a good grade is assigned to at least one food in response to the determination that at least one postprandial glucose trace does not include at least one postprandial glucose trace having a ranged postprandial pattern and does not include at least two postprandial glucose traces having a high glucose pattern.
[0385] In some methods, the grade is represented by a star system, where more stars indicate a better grade, and fewer stars indicate a lower grade. In other methods, multiple gray stars indicate an uncertain grade.
[0386] In some methods, the grade is based on at least one characteristic of at least one postprandial glucose trace. In some methods, at least one characteristic of at least one postprandial glucose trace is the degree of a high glucose pattern. In some methods, the degree of a high glucose pattern is based on the area under the curve above approximately 180 mg / dL. In some methods, the degree of a high glucose pattern is based on the amount of time above approximately 180 mg / dL. At least one characteristic of at least one postprandial glucose trace is the amount of time within the target range. In some methods, the target range is approximately 70 mg / dL to 180 mg / dL.
[0387] In some methods, the grade is further based on the relationship between the start time of the meal consumed and at least one characteristic of at least one postprandial glucose trace.
[0388] In some methods, the grade is further based on additional logged meals containing at least one food item, and each additional logged meal is associated with at least one postprandial glucose trace.
[0389] In some methods, the grade is further based on a model that maps multiple inputs to a grade variable. In some methods, the grade variable ranges from 0 to 4, where 0 corresponds to a 1-star grade and 4 corresponds to a 5-star grade.
[0390] Many systems describe a system for analyzing dietary data. The system comprises an input unit configured to receive entered log entries associated with ingested meals, a display configured to visually present food data, and one or more processors coupled to the input unit, the display, and a memory for storing instructions. When an instruction is executed by one or more processors, it causes one or more processors to: identify at least one food item in the ingested meal; associate at least one food item with at least one postprandial glucose trace associated with the ingested meal; determine the grade of at least one food item based on at least one characteristic of the at least one postprandial glucose trace; and display the grade associated with at least one food item in a graphical user interface.
[0391] In some systems, the input log entries include a text description of the consumed meal, and the identification step involves using natural language processing.
[0392] In some systems, at least one food item is assigned a poor grade in response to the determination that at least one postprandial glucose trace associated with the ingested meal contains at least two postprandial glucose traces with a high glucose pattern.
[0393] In some systems, at least one food item is assigned a poor grade in response to the determination that at least one postprandial glucose trace does not contain at least one postprandial glucose trace with an within-range postprandial pattern.
[0394] In some systems, at least one food is assigned a good grade in response to the determination that at least one postprandial glucose trace contains at least one postprandial glucose trace having an within-range postprandial pattern.
[0395] In some systems, a good grade is assigned to at least one food item in response to the determination that at least one postprandial glucose trace does not include at least one postprandial glucose trace with a ranged postprandial pattern and does not include at least two postprandial glucose traces with a high glucose pattern.
[0396] In some systems, grades are represented by a star system, where more stars indicate a better grade, and fewer stars indicate a lower grade. In some systems, multiple gray stars indicate an uncertain grade.
[0397] In some systems, the grade is based on at least one characteristic of at least one postprandial glucose trace. In some systems, at least one characteristic of at least one postprandial glucose trace is the degree of a high glucose pattern. In some systems, the degree of a high glucose pattern is based on the area under the curve above approximately 180 mg / dL. In some systems, the degree of a high glucose pattern is based on the amount of time above approximately 180 mg / dL. In some systems, at least one characteristic of at least one postprandial glucose trace is the amount of time within the target range. In some systems, the target range is approximately 70 mg / dL to 180 mg / dL.
[0398] In some systems, the grade is further based on the relationship between the start time of the meal consumed and at least one characteristic of at least one postprandial glucose trace.
[0399] In some systems, the grade is further based on additional logged meals containing at least one food item, and each additional logged meal is associated with at least one postprandial glucose trace.
[0400] In some systems, the grade is further based on a model that maps multiple inputs to a grade variable. In some systems, the grade variable ranges from 0 to 4, where 0 corresponds to a 1-star grade and 4 corresponds to a 5-star grade.
[0401] Many methods describe how to analyze dietary data. The method includes the steps of: receiving an entered log entry associated with a meal consumed; identifying at least one food item in the meal consumed; associating the at least one food item with at least one postprandial glucose trace associated with the meal consumed; storing the at least one food item and the at least one postprandial glucose trace associated with the meal consumed in a database, wherein the database contains multiple food items and associated postprandial glucose traces for a population; determining the grade of the at least one food item, wherein the grade is based on a subset of postprandial glucose traces associated with the at least one food item, and the subset of postprandial glucose traces is based on a population segment; and displaying the grade associated with the at least one food item in a graphical user interface.
[0402] In some methods, population segments have prediabetes.
[0403] In some methods, population segments have type 1 diabetes.
[0404] In some methods, population segments have type 2 diabetes.
[0405] In some methods, the grade is based on at least one characteristic of a subset of postprandial glucose traces associated with at least one food. In some methods, at least one characteristic is the degree of high pattern. In some methods, the degree of high pattern is based on the area under the curve above approximately 180 mg / dL. In some methods, the degree of high pattern is based on the amount of time above approximately 180 mg / dL. In some methods, at least one characteristic of at least one postprandial glucose trace is the amount of time within the target range. In some methods, the target range is approximately 70 mg / dL to approximately 180 mg / dL. In some methods, the grade is further based on the relationship between the start time of the ingested meal and at least one characteristic of a subset of postprandial glucose traces associated with at least one food.
[0406] In some methods, the grade is further based on additional entered log entries associated with a meal containing at least one food item, and each entered log entry is associated with at least one postprandial glucose trace.
[0407] Many systems describe a system for analyzing dietary data. This system comprises an input unit configured to receive input log entries associated with ingested meals, a display configured to visually present the dietary data, and one or more processors coupled to the input unit, the display, and a memory for storing instructions, wherein when an instruction is executed by one or more processors, it causes the system to: identify at least one food item in the ingested meal; associate at least one food item with at least one postprandial glucose trace associated with the ingested meal; store at least one food item and at least one postprandial glucose trace associated with the ingested meal in a database, the database containing multiple food items and associated postprandial glucose traces for a population; determine the grade of at least one food item, the grade being determined based on a subset of postprandial glucose traces associated with at least one food item, the subset of postprandial glucose traces being based on a population segment; and display the grade associated with at least one food item in a graphical user interface.
[0408] In some systems, population segments have prediabetes.
[0409] In some systems, population segments have type 1 diabetes.
[0410] In some systems, population segments have type 2 diabetes.
[0411] In some systems, the grade is based on at least one characteristic of a subset of postprandial glucose traces associated with at least one food. In some systems, at least one characteristic is the degree of high pattern. In some systems, the degree of high pattern is based on the area under the curve above approximately 180 mg / dL. In some systems, the degree of high pattern is based on the amount of time above approximately 180 mg / dL. In some systems, at least one characteristic of at least one postprandial glucose trace is the amount of time within the target range. In some systems, the target range is approximately 70 mg / dL to approximately 180 mg / dL. In some systems, the grade is further based on the relationship between the start time of the ingested meal and at least one characteristic of a subset of postprandial glucose traces associated with at least one food.
[0412] In some systems, the grade is further based on additional entered log entries associated with a meal containing at least one food item, and each entered log entry is associated with at least one postprandial glucose trace.
[0413] Many methods describe how to recommend food choices. The method includes the steps of: receiving an entered log entry from a user associated with a meal consumed; identifying at least one food item in the meal consumed; associating the at least one food item with at least one postprandial glucose trace associated with the meal consumed; determining the classification of at least one food item based on at least one characteristic of the at least one postprandial glucose trace; analyzing the classification and at least one food item using a population model that includes a database of food classifications and associated foods for multiple population segments; associating the user with a segment of the multiple population segments based on the classification and at least one food item, wherein the segment of the multiple population segments is associated with multiple foods having a positive classification; and displaying recommended foods, wherein the recommended foods are one of multiple foods having a positive classification for the segment of the multiple population segments.
[0414] In some methods, the database further includes meals, postprandial glucose traces, user demographics, and user preferences. In some methods, the population model uses machine learning techniques to divide the population into multiple population segments. In some methods, the population model includes a first model that assigns users to segments of the multiple population segments based on an analysis of classification, at least one food, at least one postprandial glucose trace associated with at least one food, user demographic information, and user preferences. In some methods, the population model includes a second model that maps segments of the multiple population segments to multiple good food items and multiple bad food items.
[0415] A system for recommending food choices is described. The system comprises an input unit configured to receive entered log entries from a user associated with a meal consumed, a display configured to visually present foods, and one or more processors coupled to the input unit, the display, and a memory for storing instructions. When an instruction is executed by one or more processors, it causes one or more processors to: identify at least one food contained in a meal consumed; associate the at least one food with at least one postprandial glucose trace associated with the meal consumed; determine the classification of the at least one food based on at least one characteristic of the at least one postprandial glucose trace; analyze the classification and at least one food using a population model that includes a database of food classifications and associated foods for multiple population segments; associate the user with a segment of multiple population segments based on the classification and at least one food, wherein the segment of multiple population segments is associated with multiple foods having a positive classification; and display recommended foods, wherein the recommended foods are one of multiple foods having a positive classification for the segment of multiple population segments.
[0416] In some systems, the database further includes meals, postprandial glucose traces, user demographics, and user preferences. In some systems, the population model uses machine learning techniques to divide the population into multiple population segments. In some systems, the population model includes a first model that assigns users to segments of the multiple population segments based on classification, analysis of at least one food, at least one postprandial glucose trace associated with at least one food, user demographic information, and user preferences. In some systems, the population model includes a second model that maps segments of the multiple population segments to multiple good food items and multiple bad food items.
[0417] Many methods describe a method for classifying meals. The method includes the steps of receiving analyte data and dietary information from a subject; classifying several foods as good or bad foods based on the effect each of the several foods has on the subject's postprandial glucose level; displaying several foods determined to be good for the subject; displaying several foods determined to be bad for the subject; and displaying a counter indicating the number of foods classified as good or bad.
[0418] In some methods, the method further includes the steps of displaying several foods that have been determined to have a neutral effect on the subject, and displaying a counter indicating the number of foods classified as good, bad, and neutral.
[0419] In some cases, the counter is displayed on the home screen.
[0420] Many systems describe a system for classifying meals. The system comprises an input unit configured to receive analyte data and meal information from a subject, a display configured to visually present a meal grouping, and one or more processors coupled to the input unit, the display, and a memory for storing instructions. When an instruction is executed by one or more processors, it causes one or more processors to classify several foods as good or bad foods based on the effect each of the several foods has on the subject's postprandial glucose level, to display several foods determined to be good for the subject, to display several foods determined to be bad for the subject, and to display counters indicating the number of foods classified as good or bad.
[0421] In some systems, the instruction further causes one or more processors to display several foods that have been determined to have a neutral effect on the subject, and to display counters indicating the number of foods classified as good, bad, and neutral.
[0422] In some systems, the instruction causes one or more processors to further perform the task of displaying the counter on the home screen.
[0423] Many methods describe how to recommend meals. The method includes the steps of determining the period of the day with the highest glucose pattern based on an index determined by reference to the upper glucose threshold, determining the meals that were most frequently logged during the period of the day with the highest glucose pattern, and displaying alternative meal suggestions to replace the meals that were most frequently logged during the period of the day with the highest glucose pattern.
[0424] In some methods, the upper glucose threshold is approximately 180 mg / dL.
[0425] In some methods, the indicator is the area under the curve above approximately 180 mg / dL.
[0426] In some methods, the indicator is the time when the level is above approximately 180 mg / dL.
[0427] In some methods, meals that are most frequently logged during the 24-hour period with the highest glucose pattern are associated with postprandial glucose traces that have a high glucose pattern.
[0428] In some methods, the method further includes a step of displaying a comparison between the postprandial glucose trace associated with the alternative meal suggestion and the postprandial glucose trace associated with the most frequently logged meal, after the user has eaten the alternative meal suggestion.
[0429] In some methods, the method further includes a step of displaying alternative meal suggestions for frequently logged foods. In some methods, the alternative meal suggestions appear at the top of the list.
[0430] Some methods further include the step of determining alternative meal suggestions by searching a database of healthy options for the period of the day with the highest glucose pattern.
[0431] In some methods, a day is defined as breakfast, lunch, or dinner.
[0432] Many systems describe a system for recommending meals. The system comprises an input unit configured to receive analyte data and dietary information from a subject, a display configured to visually present meals or foods, and one or more processors coupled to the input unit, the display, and a memory for storing instructions. When an instruction is executed by one or more processors, it causes one or more processors to determine the period of the day with the highest glucose pattern based on an index determined by referencing an upper glucose threshold, determine the meals that were most frequently logged during the period of the day with the highest glucose pattern, and display alternative meal suggestions to replace the meals that were most frequently logged during the period of the day with the highest glucose pattern.
[0433] In some systems, the upper glucose threshold is approximately 180 mg / dL.
[0434] In some systems, the indicator is the area under the curve above approximately 180 mg / dL.
[0435] In some systems, the indicator is the time when the level is above approximately 180 mg / dL.
[0436] In some systems, meals that are most frequently logged during the 24-hour period with the highest glucose pattern are associated with postprandial glucose traces that also exhibit a high glucose pattern.
[0437] In some systems, the instruction further causes one or more processors to display a comparison of the postprandial glucose trace associated with the alternative meal suggestion with the postprandial glucose trace associated with the most frequently logged meal, after the user has eaten the alternative meal suggestion.
[0438] In some systems, the instruction causes one or more processors to further display alternative meal suggestions in a list of frequently logged foods. In some systems, the alternative meal suggestions appear at the top of the list.
[0439] In some systems, the instruction further directs one or more processors to determine alternative meal suggestions by searching a database of healthy options for the period of the day with the highest glucose pattern.
[0440] In some systems, a day is defined as breakfast, lunch, or dinner.
[0441] Many methods describe how to recommend alternative food options. The method includes receiving an entered log entry associated with a meal consumed, the entered log entry including a text description of the meal consumed; identifying at least one food included in the text description of at least one logged meal; associating at least one food with at least one postprandial glucose trace associated with the meal consumed; determining the classification of at least one food as positive or negative (or as good food or bad food) based on the impact of at least one food on the postprandial glucose trace; storing at least one food, at least one postprandial glucose trace associated with the meal consumed, and the classification in a database, the database including multiple foods, associated postprandial glucose traces, and classifications for a population and multiple alternative food options; determining an alternative food option from multiple alternative food options in response to classifying at least one food as a bad food; and displaying recommendations that include the alternative food option as a substitute for at least one food classified as a bad food.
[0442] In some ways, alternative food options are classified as good foods for multiple individuals.
[0443] In some methods, the method further includes the steps of determining the period of day with the highest glucose pattern for the user based on an index determined by reference to an upper glucose threshold, determining the food that was most frequently logged during the period of day with the highest glucose pattern, and displaying additional alternative food options to replace the most frequently logged food.
[0444] In some methods, the method further includes the steps of prompting the user to input food preferences and displaying additional alternative food options to replace at least one food classified as a bad food, based on the database and the food preferences entered by the user.
[0445] Many systems describe a system for recommending alternative food options. The system comprises an input unit configured to receive an input log entry associated with a meal consumed, the input log entry containing a text description of the meal consumed, a display configured to visually present a meal or food, and one or more processors coupled to the input unit, the display, and a memory for storing instructions, the instructions, when executed by one or more processors, to identify at least one food contained in the text description of at least one logged meal, associate at least one food with at least one postprandial glucose trace associated with the meal consumed, and postprandial glucose The system determines whether the classification of at least one food is positive or negative based on the effect of at least one food on glucose trace, stores the classification of at least one food, at least one postprandial glucose trace associated with the ingested meal, and the classification in a database, the database storing multiple foods, associated postprandial glucose traces, and classifications for a population and multiple alternative food options, determines alternative food options from multiple alternative food options in response to classifying at least one food as a bad food, and displays recommendations that include alternative food options as substitutes for the at least one food classified as a bad food.
[0446] In some systems, alternative food options are classified as good foods for multiple individuals.
[0447] In some systems, the instruction further causes one or more processors to determine the period of the day with the highest glucose pattern for the user, based on an index determined by referencing an upper glucose threshold; to determine the food that was logged most frequently during the period with the highest glucose pattern; and to display additional alternative food options to replace the most frequently logged food.
[0448] In some systems, the instruction causes one or more processors to further prompt the user for input of food preferences and, based on the database and the food preferences entered by the user, display additional alternative food options to replace at least one food classified as a bad food.
[0449] Many methods describe how to recommend alternative food options. The method includes the steps of: identifying at least one food in the text description of at least one logged meal; associating at least one food with at least one postprandial glucose trace associated with the meal consumed; determining whether the classification of at least one food is positive or negative based on the impact of at least one food on the postprandial glucose trace; storing at least one food, at least one postprandial glucose trace associated with the meal consumed, and the classification in a database, the database including multiple foods, associated postprandial glucose traces, and classifications for populations and multiple alternative food options; determining alternative food options from multiple alternative food options in response to classifying at least one food as a bad food; and displaying recommendations that include the alternative food options as substitutes for at least one food classified as a bad food.
[0450] In some ways, alternative food options are classified as good foods for multiple individuals.
[0451] In some methods, the method further includes the steps of determining the period of day with the highest glucose pattern for the user based on an index determined by reference to an upper glucose threshold, determining the food that was most frequently logged during the period of day with the highest glucose pattern, and displaying additional alternative food options to replace the most frequently logged food.
[0452] In some methods, the method further includes the steps of prompting the user to input food preferences and displaying additional alternative food options to replace at least one food classified as a bad food, based on the database and the food preferences entered by the user.
[0453] Many methods describe how to analyze dietary data. The method includes the steps of receiving an input log entry from a user associated with a meal consumed, determining the grade of the meal consumed based on at least one characteristic of at least one postprandial glucose trace associated with the meal consumed, wherein the grade is modifiable, and displaying the grade associated with the meal consumed in a graphical user interface.
[0454] In some cases, the grade may be changed by the user.
[0455] In some methods, the entered log entries are received at a first time, and the method further includes the step of removing the grade for the consumed meals after a certain period following the first time. In some methods, this period is approximately 6 months.
[0456] In some methods, the entered log entries are received at a first time, and the method further includes a step of determining a new grade for at least one logged meal after a certain period following the first time. In some methods, this period is approximately 6 months.
[0457] In many systems, a system for analyzing meals is described. The system comprises an input unit configured to receive entered log entries from a user associated with ingested meals, a display configured to visually present meals or foods and grades, and one or more processors coupled to the input unit, the display, and a memory for storing instructions, the instructions, when executed by one or more processors, cause one or more processors to determine the grade of an ingested meal based on at least one characteristic of at least one postprandial glucose trace associated with the ingested meal, the grade being modifiable, and to display the grade associated with the ingested meal in a graphical user interface.
[0458] In some ways, the grade can be changed by the user.
[0459] In some methods, the entered log entry is received at a first time, and an instruction causes one or more processors to perform a further step of removing the grade for the ingested food after a certain period following the first time. In some methods, this period is approximately six months.
[0460] In some methods, the entered log entries are received at a first time, and a further step is included to determine a new grade for at least one logged meal after a certain period following the first time. In some methods, this period is approximately 6 months.
[0461] Systems, devices, and methods for detecting, measuring, and classifying an individual's diet based on analyte measurements. These results and related information can be presented to show the individual which diets are causing the most severe analyte response. These results can be organized and classified based on pre-selected criteria or past diets and results, so as to organize and present the results in a format that references glucose as the monitored analyte. Various embodiments disclosed herein relate to methods, systems, and software applications intended to engage an individual by providing direct and timely feedback on the individual's diet-related blood glucose response.
[0462] It should be noted that all features, elements, components, functions, and steps described in relation to any embodiment provided herein are intended to be freely combined and substituted with those from any other embodiment. If a feature, element, component, function, or step is described in relation to only one embodiment, it should be understood that that feature, element, component, function, or step can be used in all other embodiments described herein unless expressly otherwise stated. Accordingly, this paragraph serves as a prerequisite and written support for introducing claims that combine features, elements, components, functions, and steps from different embodiments or substitute features, elements, components, functions, and steps from one embodiment with those from another embodiment, even if such combinations or substitutions are not explicitly stated in particular cases. In particular, it is clearly acknowledged that explicitly describing all possible combinations and substitutions would be excessively burdensome, given that the permissibility of each such combination and substitution is readily apparent to those skilled in the art.
[0463] To the extent that embodiments disclosed herein include or operate in relation to memory, storage, and / or computer-readable media, such memory, storage, and / or computer-readable media are non-transient. Therefore, to the extent that memory, storage, and / or computer-readable media are covered by one or more claims, such memory, storage, and / or computer-readable media are merely non-transient.
[0464] In many cases, entities are described herein as being joined to other entities. The terms “joined” and “connected” (or any of these forms) are used interchangeably herein and should be understood to generally refer to both direct joining of two entities (without negligible (e.g., parasitic) intervening entities) and indirect joining of two entities (by one or more negligible intervening entities). Where entities are shown as directly joined, or described as joined without any mention of intervening entities, they may also be joined indirectly, unless the context explicitly indicates otherwise.
[0465] The subject matter described herein and in the accompanying figures is made sufficiently detailed and clear so that it may at any time include mean-plus-function claims in accordance with Section 112(f) of the United States Patent Act. However, a claim shall be construed as calling this mean-plus-function form only if the phrase “means” is explicitly stated in that claim.
[0466] Aspects of the present invention are described in the independent claims, and preferred features are described in the dependent claims. Preferred features of the dependent claims may be provided in combination in a single embodiment, and preferred features of one embodiment may be provided in combination with other embodiments.
[0467] As used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly indicates otherwise.
[0468] The publications discussed herein are provided solely for disclosure prior to the filing date of this application. Nothing in this specification should be construed as acknowledging that this disclosure does not have prior rights to such disclosure by prior disclosure. Furthermore, the publication dates provided may differ from the actual publication dates and should be verified on a case-by-case basis.
[0469] The embodiments are susceptible to various modifications and alternative forms, specific examples of which are shown in the drawings and described in detail herein. These embodiments are not limited to any particular form disclosed, but rather encompass all modifications, equivalents, and alternatives that fall within the spirit of this disclosure. Furthermore, any feature, function, step, or element of an embodiment may be described in or added to the claims, as well as any negative limitation that would define the scope of the claims by a feature, function, step, or element not included in the claims.
[0470] Clause Exemplary embodiments are described in the following numbered clauses.
[0471] Clause 1 A method for processing analyte data, comprising: receiving analyte data sensed from an individual; detecting episodes of the received analyte data; displaying a first episode marker associated with the detected episode on a graph of the analyte data; providing a screen configured to receive information about the detected episode; and, after receiving information about the detected episode, displaying a second episode marker associated with the detected episode on a graph of the analyte data.
[0472] Clause 2 The method described in Clause 1, further comprising the step of displaying a notification indicating that the above episode has been detected.
[0473] Clause 3 The step of displaying the above notice is the method described in Clause 2, which includes the step of displaying a number on an icon corresponding to the number of detected episodes.
[0474] Clause 4 The above value is incremented when an episode is detected, in the manner described in Clause 3.
[0475] Clause 5 The above value is decremented in the manner described in Clause 3 after the information of the detected episode has been received.
[0476] Clause 6 The above value is decremented after a predetermined time has elapsed since the above episode was detected, in the manner described in Clause 3.
[0477] Clause 7 The step of displaying the above notice shall be the method described in Clause 2, including the step of displaying an alert.
[0478] Clause 8 The first episode marker described above is different from the second episode marker described above, in the manner described in Clause 1.
[0479] Clause 9 The first episode marker described above includes a question mark, in the manner described in Clause 1.
[0480] Clause 10 The second episode marker described above includes an image related to the received information, as described in Clause 1.
[0481] Clause 11 The second episode marker described above includes X, in the manner described in Clause 1.
[0482] Clause 12 The above-detected episode is an out-of-scope episode, as described in Clause 1.
[0483] Clause 13 The first episode marker described above is placed at the time on the graph of the analyte data at the estimated start time of the detected episode, in the manner described in Clause 1.
[0484] Clause 14 The above analyte data is glucose data, as described in Clause 1.
[0485] Clause 15 An apparatus for processing analyte data, comprising: an input unit configured to receive measured analyte data; a display configured to visually present an analysis of the measured analyte data; and one or more processors coupled to the input unit, the display, and a memory for storing instructions, wherein, when the instructions are executed by the one or more processors, the one or more processors cause the one or more processors to: detect an episode of the received analyte data; display a first episode marker associated with the detected episode on a graph of the analyte data; provide a screen configured to receive information about the detected episode; and, after receiving information about the detected episode, display a second episode marker associated with the detected episode on a graph of the analyte data.
[0486] The device described in Clause 15, which executes a program causing the processor to display a notification indicating that the episode has been detected.
[0487] Clause 17 The above notice includes the device described in Clause 16, which displays a numerical value on an icon corresponding to the number of detected episodes.
[0488] Cl...
Claims
1. A system for recommending alternative food options, An input unit configured to receive an input log entry associated with a meal consumed, wherein the input log entry includes a text description of the meal consumed. A display configured to visually present a meal or food, The input unit, the display, and one or more processors coupled to the memory for storing instructions Equipped with, When the instruction is executed by one or more processors, the one or more processors will: Identifying at least one food item included in the text description of at least one logged meal, Associating the at least one food with at least one postprandial glucose trace associated with the ingested meal, Based on the effect of the at least one food on the postprandial glucose trace, the classification of the at least one food is determined to be positive or negative. The method of storing the at least one food, the at least one postprandial glucose trace associated with the ingested meal, and the classification in a database, wherein the database includes multiple food items, associated postprandial glucose traces, and classifications for multiple alternative food options. In response to classifying at least one food as a bad food, a choice of alternative food is made from the multiple alternative food options. To display recommendations that include the alternative food options as alternatives to at least one food classified as a bad food, and A system that enables this to happen.
2. The system according to claim 1, wherein the alternative food options are classified as good foods for multiple individuals.
3. The instruction is given to one or more processors. Based on an index determined by referring to the upper glucose threshold, the period of the day with the highest glucose pattern for the user is determined, To determine the food that was most frequently logged during the 1-day period having the highest glucose pattern, To display additional alternative food options to replace the most frequently logged food mentioned above. The system according to claim 1, further comprising the following:
4. The instruction is given to one or more processors, Prompting the user to input their food preferences, Based on the database and the food preferences entered by the user, display additional alternative food options to replace at least one food classified as a bad food. The system according to claim 1, further comprising the following:
5. The instruction is provided to one or more processors Receiving the input log entries associated with the aforementioned alternative food options, Associating the aforementioned alternative food options with additional postprandial glucose tracing, To display an additional postprandial glucose trace associated with the aforementioned alternative food option. The system according to claim 1, further comprising the following:
6. The system according to claim 5, wherein the additional postprandial glucose trace associated with the alternative food option is displayed in comparison to the at least one postprandial glucose trace associated with the ingested meal.
7. The system according to claim 1, wherein the recommendations, including the alternative food options, are displayed in a list of frequently logged foods.
8. The system according to claim 7, wherein the alternative food option is displayed at the top of the list of frequently logged foods.
9. A method for recommending alternative food options, A step of identifying at least one food item included in the text description of at least one logged meal, The steps of associating the at least one food with at least one postprandial glucose trace associated with the at least one logged meal, A step of determining whether the classification of the at least one food is positive or negative based on the effect of the at least one food on the at least one postprandial glucose trace, A step of storing the at least one food, the at least one postprandial glucose trace associated with the logged meal, and the classification in a database, wherein the database includes a plurality of food, associated postprandial glucose traces, and classifications for a plurality of alternative food options. In response to classifying at least one food as a bad food, the steps include determining an alternative food option from the plurality of alternative food options, A step of displaying a recommendation that includes the alternative food options as alternatives to at least one food classified as a bad food; Methods that include...
10. The method according to claim 9, wherein the alternative food options are classified as good foods for multiple individuals.
11. The steps include determining the period of day with the highest glucose pattern for the user based on an index determined by referring to the upper glucose threshold, The steps include determining the food that was most frequently logged during the 1-day period having the highest glucose pattern, The steps include displaying additional alternative food options to replace the most frequently logged food, and The method according to claim 9, further comprising:
12. A step of prompting the user to input their food preferences, A step of displaying additional alternative food options to replace the at least one food classified as a bad food, based on the database and the food preferences entered by the user. The method according to claim 9, further comprising:
13. The steps of receiving an input log entry associated with the alternative food option, The steps include associating the aforementioned alternative food option with additional postprandial glucose tracing, The steps include displaying an additional postprandial glucose trace associated with the aforementioned alternative food option. The method according to claim 9, further comprising:
14. The method according to claim 13, wherein the additional postprandial glucose trace associated with the alternative food option is displayed in comparison to the at least one postprandial glucose trace associated with the ingested meal.
15. The method according to claim 9, wherein the recommendations, including the alternative food options, are displayed in a list of frequently logged foods.
16. The method according to claim 9, wherein the upper glucose threshold is approximately 180 mg / dl.