Digital and user interface for analyte monitoring systems

Abstract

Improved digital interfaces, graphical user interfaces, and alarms for analyte monitoring systems are provided. For example, various implementations of methods, systems, and interfaces for signal loss condition determination, time-range interfaces, GMI measurements, emergency low glucose alarms, alarm suppression features, alarm setting interfaces, and alarm unavailability detection features are disclosed. Furthermore, various implementations of interfaces for alarm logging and compatibility checks for analyte monitoring software applications are described. Additionally, various implementations of interface enhancements are described, including enhanced visibility modes, voice accessibility modes, additional interfaces related to user privacy, caregiver alarms, and other implementations.

Description

Technical Field

[0001] The topics described herein generally relate to digital interfaces, user interfaces, and alarms for analyte monitoring systems, as well as related systems, methods, and apparatus. Background Technology

[0002] Detecting and / or monitoring analyte levels, such as glucose, ketones, lactate, oxygen, and hemoglobin AIC, can be crucial for overall health, especially for individuals with diabetes. Patients with diabetes may experience complications including loss of consciousness, cardiovascular disease, retinopathy, neuropathy, and kidney disease. People with diabetes typically need to monitor their glucose levels to ensure they remain within a clinically safe range, and this information can also be used to determine whether and / or when insulin is needed to lower their glucose levels, or when additional glucose is needed to raise them.

[0003] A growing body of clinical data demonstrates a strong correlation between the frequency of glucose monitoring and glycemic control. However, despite this correlation, many individuals diagnosed with diabetes do not monitor their glucose levels as frequently as they should due to a combination of factors, including convenience, caution in testing, pain associated with glucose testing, and cost.

[0004] To increase patient adherence to frequent glucose monitoring programs, in vivo analyte monitoring systems can be utilized, wherein a sensor control device can be worn on the body of the individual requiring analyte monitoring. To enhance personal comfort and convenience, the sensor control device can have a small shape factor and can be applied by the individual using a sensor applicator. The application process involves inserting at least a portion of a sensor that senses the user's analyte level into bodily fluids located within a layer of the body, such that the sensor is in contact with the bodily fluids, using an applicator or insertion mechanism. The analyte monitoring system can also be configured to transmit analyte data and / or alerts to another device from which a caregiver (e.g., a parent, spouse, or healthcare provider (“HCP”)) can view the data and make treatment decisions. Furthermore, the benefits of analyte monitoring systems are not limited to diabetic patients. For example, analyte monitoring systems can provide useful information and insights to individuals interested in improving their health. As an example, to improve their athletic performance, athletes can utilize a sensor control device worn on the body to collect data related to one or more analytes, such as glucose and / or lactate. Other non-medical applications for analyte monitoring systems are possible and are described in further detail below.

[0005] However, despite their advantages, some people are reluctant to use analyte monitoring systems for various reasons, including the complexity and volume of the data presented, the learning curve associated with the software and user interface of the analyte monitoring system, and the overall lack of actionable information presented.

[0006] Furthermore, as sensor control devices become more convenient, comfortable, and affordable for users, applications outside of medicine have become feasible. For example, high-level athletes are interested in optimizing the levels of analytes (such as blood glucose) that affect performance before or during training and competition. However, some existing user interfaces for sensor control devices are designed for medical use by patients under the care of a physician, rather than for non-medical applications such as sports training and competition. Therefore, the data collected by the sensor control device and the methods used to present the data to the user may not be suitable for non-medical applications. Additionally, sensor control devices used for non-medical (e.g., health and fitness) purposes may be confused with similar devices used for medical purposes, leading to problems in interpreting or using the data.

[0007] Therefore, there is a need for robust, user-friendly, and timely and actionable digital interfaces, graphical user interfaces, and alarms for analyte monitoring systems used for medical and / or non-medical purposes. Summary of the Invention

[0008] This document provides example embodiments of digital and user interface implementations for analyte monitoring systems. Aspects of the invention are set forth in the independent claims, and preferred features are set forth in the dependent claims. Preferred features of each aspect may be provided in combination with each other in specific embodiments, and may also be provided in combination with other aspects. According to some embodiments, methods, systems, and interfaces related to determining signal loss conditions in an analyte monitoring system based on the time elapsed since the last current sensor reading are described. In other embodiments, methods, systems, and interfaces for determining invalid current sensor readings in an analyte monitoring system are described. In still other embodiments, methods, systems, and interfaces related to determining a “no most recent valid sensor reading” alarm condition in an analyte monitoring system are also described.

[0009] According to another embodiment, a method is described for calculating a percentage of time related to an analyte level range or threshold to generate a time-in-range interface. In some embodiments, the calculated percentage of time may include non-configurable and user-configurable analyte level ranges and / or thresholds.

[0010] According to another embodiment, an enhanced visibility mode is provided for the analyte monitoring system software application, wherein many interfaces used with the analyte monitoring system can be modified to achieve better visibility in low-light environments. In some embodiments, the enhanced visibility mode can be manually enabled by the user through the device's operating system. In other embodiments, the enhanced visibility mode can be enabled by a light sensor or according to a predetermined schedule.

[0011] According to another embodiment, a voice accessibility mode is provided for an analyte monitoring system software application, wherein sound output of the analyte monitoring system interface (or a portion thereof) can be generated. In some embodiments, for example, the voice accessibility mode can convert touch portions of a display into auditory output. In other embodiments, certain touch-responsive portions of the interface can be grouped and configured such that the device can convert the text of the entire group into auditory output in response to a user touching any portion associated with the group.

[0012] According to other embodiments, additional implementations of digital and user interface methods for analyte monitoring are provided. In some embodiments, for example, a sensor usage reporting interface is provided, wherein a "view" metric is generated based on the number of instances in which a user views a sensor results interface with valid sensor readings. In other embodiments, an interface for an analyte monitoring software application is provided to allow an "accountless mode" in which the user does not need to create or log in to a cloud-based server to utilize the analyte monitoring software application. In other embodiments, an interface for an analyte monitoring software application is provided to allow the user to opt in or out of sharing the user's sensor readings and / or other product-related data for research purposes. In other embodiments, an interface for an analyte monitoring software application is provided to warn the user of potentially erroneous high sensor readings due to daily use of more than 500 mg of vitamin C supplements.

[0013] According to another embodiment, a method, system, and interface are provided for generating alarms related to an analyte monitoring system on a caregiver's reader device. In some embodiments, for example, a sensor control device worn on a patient's body can wirelessly transmit current sensor readings to the patient's reader device, which in turn can wirelessly transmit the current sensor readings to a cloud-based server. According to one aspect of the embodiment, the cloud-based server can determine whether the received current sensor readings meet an alarm condition, and if so, send an alarm indicator to the caregiver's reader device. In other embodiments, for example, an alarm condition is determined on the patient's reader device, and in response to the detection of the alarm condition, an alarm indicator is sent to the cloud-based server and subsequently "transmitted" to the caregiver's reader device.

[0014] According to some embodiments, methods, systems, and interfaces related to displaying a user interface including at least one glucose management indicator metric (GMI) determined for a time period are described.

[0015] According to some embodiments, methods, systems, and interfaces related to displaying a user interface including at least one GMI metric determined for a time period, a glucose trend interface, a sensor user interface including a time percentage sensor activity metric, and a health information interface are described.

[0016] According to some embodiments, methods, systems, and interfaces relating to displaying a user interface include at least one GMI metric determined for a time period, a plot of glucose data measurements obtained from an object on a level representation of multiple time periods of a day; and a table including columns for each of multiple different time periods of a day, each column including an assessment of hypoglycemic risk and an assessment of glycemic variability at one of the multiple different time periods of a day.

[0017] According to some embodiments, methods, systems, and interfaces for displaying user interfaces are disclosed, including a glucose statistics interface comprising at least one glucose management indicator (GMI) metric defined for a time period; a time-range interface; a plot of glucose readings over the time period, wherein the plot displays a median glucose trajectory and multiple trajectories of glucose readings at different percentiles; and multiple glucose profiles, including a glucose profile for each day of the time period.

[0018] In some embodiments, at least one GMI measure may be a GMI percentage. In some embodiments, at least one GMI measure may be a GMI value in mmol / mol. In some embodiments, at least one GMI measure may be two GMI measures. In some embodiments, both the GMI percentage and the GMI value in mmol / mol may be displayed.

[0019] In some embodiments, systems, methods, and interfaces are provided for emergency low glucose alarms in analyte monitoring systems, wherein the analyte monitoring system includes a sensor control device configured to collect data indicating analyte levels in an indicator. The analyte monitoring system further includes a reader device (e.g., a smartphone) with wireless communication circuitry, and one or more processors coupled to a memory storing instructions that, when executed by the one or more processors, cause the processors to determine whether the data indicating the analyte level satisfies one or more alarm conditions. The one or more alarm conditions include a first alarm condition associated with a first set of alarm settings that can be configured by a user, and a second alarm condition associated with a second set of alarm settings that cannot be configured by a user, wherein the second alarm condition is an emergency low glucose alarm condition. In some embodiments, for example, the second set of alarm settings may include non-configurable switch settings, non-configurable emergency low threshold settings, non-configurable alarm tone settings, and / or non-configurable settings to override a "Do Not Disturb" feature.

[0020] According to other example implementations, methods and systems for alarm suppression are provided. In some implementations, for example, systems and methods for suppressing alarms during an alarm post-presentation period are described. Specifically, a reader device (e.g., a smartphone) includes one or more processors coupled to a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to present a first alarm associated with a first condition, receive data indicating an analyte level from a sensor control device, and determine whether a second alarm condition exists based on the received data indicating an analyte level or the received data lacking an analyte level. If a second alarm condition exists and is the same as the first alarm condition, it is determined whether the alarm post-presentation period has passed. If the alarm post-presentation period has not passed, no action is taken on the first alarm. If the alarm post-presentation period has passed, the first alarm is updated or cleared.

[0021] As another example, in some implementations, systems and methods for suppressing alarms during an active clearing period, which is a predetermined time period after a user clears an alarm. Specifically, a reader device (e.g., a smartphone) includes one or more processors coupled to a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to present a first alarm associated with a first alarm condition, initiate an active clearing period in response to receiving an instruction that the first alarm has been cleared, receive data indicating an analyte level from a sensor control device, and determine whether a second alarm condition exists based on the received data indicating an analyte level or the absence of received data indicating an analyte level. If a second alarm condition exists and is identical to the first alarm condition, it is determined whether the active clearing period has passed or been cancelled. If the active clearing period has passed or been cancelled, a second alarm associated with the first alarm condition is presented. If the active clearing period has not passed and has not been cancelled, no further action is taken.

[0022] According to other embodiments, an alarm settings interface for use with an analyte monitoring software application is also described. In some embodiments, for example, the alarm settings interface may include one or more interfaces for configuring alarm permission settings, such as notification permission settings, critical alarm permission settings, location permission settings, battery optimization settings, or "Do Not Disturb" settings. According to one aspect of these embodiments, the analyte monitoring software application may be configured to remain in an inoperable or partially operational state unless one or more alarm permission settings are enabled.

[0023] According to some embodiments, systems and methods for detecting alarm unavailability conditions are described. Specifically, a reader device (e.g., a smartphone) includes one or more processors coupled to a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to detect one or more alarm unavailability conditions when at least one alarm of an analyte monitoring system is enabled, and to present a notification associated with the detected one or more alarm unavailability conditions. In some embodiments, one or more alarm unavailability conditions may include the following steps or a plurality: a wireless communication circuit is disabled or malfunctioning; one or more system-wide notifications are disabled; one or more application-specific notifications are disabled; an analyte monitoring software application is forcibly closed; one or more critical alarms are disabled; a "Do Not Disturb" overlay feature is disabled; one or more alarm sounds are set to silent; location permission is disabled; one or more battery optimization features are enabled; no active sensor is detected; or a sensor malfunction condition occurs.

[0024] According to some embodiments, systems and interfaces for logging alarms in an analyte monitoring system are also described. In other embodiments, methods and systems for determining the compatibility of analyte monitoring software applications are described.

[0025] According to some embodiments, systems, apparatuses, and methods for sensor user interfaces in in vivo analyte monitoring systems suitable for non-medical purposes are also described.

[0026] According to some implementations, this document provides improvements to the user interface to enable sensor control devices for use in non-medical applications. Other improvements and advantages are also provided. Various configurations of these devices are described in detail through embodiments that are merely examples.

[0027] In some implementations, for example, a method for an electronic interface for a computing device may include receiving sensor data from a sensor control device by at least one processor over a predetermined time period, and determining whether measurements of the sensor data satisfy at least one necessary condition for providing such non-medical information to a display device. The method may further include providing an interactive graphical user interface to the display device, the interactive graphical user interface being configured to display the sensor data based on the determination, wherein the display device indicates only one or more measurements of the sensor data that satisfy at least one condition.

[0028] In an illustrative embodiment, the method includes using at least one necessary condition, which includes at least one of a predetermined upper threshold and a lower threshold for the measured value, wherein the threshold is set to indicate a medical pathology or condition. For example, the method may include providing an interface with out-of-range values ​​falling outside the predetermined threshold range without indicating a specific value to the display device. Furthermore, when the measured value satisfies at least one condition displayed as non-medical information, the method may include indicating the specific value in text form on the display device. In one embodiment, for example, the method may include providing sensor data from a sensor control device indicating the glucose level of a user wearing the control device on the display device, wherein predetermined lower and upper measurement thresholds are 55 and 200 mg / dL, respectively. The method may include having at least one processor determine that measured values ​​falling within the glucose range satisfy at least one condition for display, and thus providing the measured value displayed by the display device, while values ​​falling outside the range trigger an out-of-range indicator. Conversely, the method may further include indicating that the measured value is out of range without providing a precise measured value to the reader device. In one aspect, the method may include providing a graphical user interface with a graph of sensor data changing over time. This method may include configuring the chart with other information, such as an indicator of the target average value of the sensor data. In one aspect, the chart may omit the display of data that is outside the range.

[0029] On the other hand, sensor control devices for non-medical (e.g., health and fitness) purposes are configured such that they cannot be accessed by reader devices or applications configured for use with medical sensor control devices. Similarly, reader devices or applications for non-medical purposes are configured such that they cannot access data transmitted by the medical sensor control device.

[0030] The reader device that receives sensor data from the sensor control device can be a smartphone, tablet, personal digital assistant, or other proprietary or non-proprietary mobile computing platform. One or more applications can be installed on the reader device, which analyzes the data transmitted from the sensor control device and displays non-medical information related to health and nutrition to the individual. Therefore, the reader device includes at least one data processing unit coupled to a computer memory and a wireless interface for receiving data and determining whether the measured values ​​of the sensor data meet at least one necessary condition for display as non-medical information. In some embodiments, the memory may store instructions for limiting the display of measurements from the sensor control device to a restricted range that does not indicate medical pathology, as well as related operations or aspects described above and / or in the detailed description below.

[0031] Many of the embodiments described herein are improved GUIs or GUI features for analyte monitoring systems that are highly intuitive, user-friendly, and provide rapid access to the user's physiological information. More specifically, these embodiments allow users to easily navigate between different user interfaces that can quickly indicate various physical conditions and / or actionable responses to the user, without requiring the user (or HCP) to undergo the arduous task of examining large amounts of analyte data. Furthermore, some GUIs and GUI features and interfaces allow users (and their caregivers) to better understand and improve their respective access to the analyte monitoring system, and / or troubleshoot complex system settings to ensure alarms function properly within the analyte monitoring system. Similarly, many other embodiments described herein include improved digital interfaces, methods, and / or features for analyte monitoring systems that enhance the caregiver's ability to identify adverse patient conditions. Other improvements and advantages are also provided. Various configurations of these devices are described in detail by way of examples only.

[0032] Other systems, apparatuses, methods, features, and advantages of the subject matter described herein will be apparent to those skilled in the art upon examination of the following figures and detailed description. Among the methods described and claimed herein, an analyte monitoring system comprising components for performing each step of the method is also explicitly disclosed and provided. Furthermore, computer programs, computer program products, and computer-readable media for implementing the steps of the method are also disclosed and provided. All such additional systems, apparatuses, methods, features, and advantages are intended to be included in this specification, within the scope of the subject matter described herein, and protected by the appended claims. Unless those features in the claims are explicitly stated, the features of the exemplary embodiments should in no way be construed as limiting the appended claims. Attached Figure Description

[0033] By studying the accompanying drawings, the structural and operational details of the subject matter described herein will become apparent, where the same reference numerals refer to the same parts. The components in the drawings are not necessarily drawn to scale, but rather the emphasis is on illustrating the principles of the subject matter. Furthermore, all illustrations are intended to convey concepts, where relative dimensions, shapes, and other detailed attributes are shown schematically rather than literally or precisely.

[0034] Figure 1 This is a system overview of an analyte monitoring system, which includes a sensor applicator, sensor control unit, reader unit, network, trusted computer system, and local computer system.

[0035] Figure 2A This is a block diagram depicting an example implementation of a reader device.

[0036] Figure 2B and Figure 2C This is a block diagram depicting an example implementation of a sensor control device.

[0037] Figures 3A to 3D This is a flowchart depicting an example implementation of a method for signal loss detection.

[0038] Figures 4A to 4E This is an example implementation of a GUI related to signal loss status and signal loss alarms.

[0039] Figures 4F to 4H This is an example implementation of a GUI that includes a configuration interface for signal loss alarms.

[0040] Figure 4I and Figure 4J This is an example implementation of a GUI that includes a signal loss alarm.

[0041] Figures 5A to 5CThis is a flowchart illustrating an example implementation of a method for generating a graphical representation of an interface within a time frame.

[0042] Figure 6 This is a flowchart depicting an example implementation of a method for enabling enhanced visibility modes.

[0043] Figures 7A-1 to 7I-2 This is an example implementation of the GUI shown in normal mode and enhanced visibility mode.

[0044] Figure 8 This is a flowchart depicting an example implementation of a method for enabling voice accessibility mode.

[0045] Figure 9A and Figure 9B This is an example implementation of the GUI for voice accessibility mode.

[0046] Figure 10A This is an example implementation of a GUI for sensor usage reporting.

[0047] Figure 10B and Figure 10C This is an example implementation of the GUI related to GMI.

[0048] Figure 10D This is an example implementation of a GUI for including GMI snapshot reports.

[0049] Figure 10E and Figure 10F This is an example implementation of a GUI for using insight reports including GMI.

[0050] Figure 10G This is an example implementation of a GUI for glucose profile reporting including GMI.

[0051] Figures 11A to 11D This is an example implementation of an additional GUI related to analyte monitoring software applications.

[0052] Figure 12A and Figure 12B This is a further example implementation of an additional GUI related to analyte monitoring software applications.

[0053] Figure 13A This is a flowchart depicting an example implementation of a method for identifying and presenting alarms in an analyte monitoring system.

[0054] Figures 13B to 13G This is an example implementation of a GUI related to various alarms in an analyte monitoring system.

[0055] Figures 14A to 14IThis is an example implementation of a GUI related to various alarm settings in an analyte monitoring system.

[0056] Figure 15A and Figure 15B This is a flowchart depicting an example implementation of a method for suppressing alarms in an analyte monitoring system.

[0057] Figure 15C This is a block diagram depicting an example implementation of an alarm scheme.

[0058] Figures 16A to 16E This is an example implementation of a GUI related to alarm configuration in an analyte monitoring system.

[0059] Figures 17A to 17I This is also an example implementation of a GUI related to alarm configuration in an analyte monitoring system.

[0060] Figure 18A This is a flowchart illustrating an example implementation of a method for identifying and notifying various alarm unavailability conditions.

[0061] Figure 18B and Figure 18C This is an example implementation of a GUI related to various alarm unavailability conditions in an analyte monitoring system.

[0062] Figures 18D to 18N This is an example implementation of a pattern related to various alarm unavailability conditions in an analyte monitoring system.

[0063] Figures 180 to 18Q This is an example implementation of a GUI related to various alarm unavailability conditions in an analyte monitoring system.

[0064] Figure 19 This is a flowchart depicting an example implementation of a method for recording alarms in an analyte monitoring system.

[0065] Figures 20A to 20C This is an example implementation of a GUI related to alarm logging in an analyte monitoring system.

[0066] Figures 21A to 21J This is an example implementation of a GUI related to compatibility checks in an analyte monitoring system.

[0067] Figure 22 This is a system overview of an analyte monitoring system, which includes sensor control devices, patient reader devices, a network, a trusted computer system, and caregiver reader devices.

[0068] Figure 23A and Figure 23B This is a flowchart describing an example implementation of a method for providing caregiver alerts.

[0069] Figures 24A to 24H This is an example implementation of the GUI associated with the caregiver application and the alarm configuration settings included therein.

[0070] Figure 25 This is a flowchart illustrating the process of using an electronic interface of a computing device to display non-medical data from a sensor control device.

[0071] Figure 26 This is a screenshot showing an example of the user interface provided by the method described in this article.

[0072] Figures 27 to 28 This is a flowchart further illustrating the process of using an electronic interface of a computing device to display non-medical data from a sensor control device.

[0073] Figures 29A to 29F This is an example implementation of a GUI for displaying non-medical data from sensor control devices on wearable devices. Detailed Implementation

[0074] Before describing this subject matter in detail, it should be understood that this disclosure is not limited to the specific embodiments described, as variations are naturally possible. It should also be understood that the terminology used herein is for the purpose of describing specific embodiments only and is not intended to limit the invention, as the scope of this disclosure will be limited only by the appended claims.

[0075] As used herein and in the appended claims, unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” include the plural reference.

[0076] The published texts discussed herein are provided only based on their publication prior to the filing date of this application. Nothing herein should be construed as an admission that this disclosure is not entitled to precede such published texts by virtue of prior disclosure. Furthermore, the publication dates provided may differ from the actual publication dates, which may require independent verification.

[0077] Typically, embodiments of this disclosure include GUIs, alarms, and digital interfaces for analyte monitoring systems, as well as associated systems, methods, and apparatuses. Therefore, many embodiments include in vivo analyte sensors structurally configured such that at least a portion of the sensor is located or can be located within a user's body to obtain information about at least one analyte in the body. However, it should be noted that the embodiments disclosed herein are used with in vivo analyte monitoring systems incorporating in vitro capabilities, as well as purely in vitro or in vitro analyte monitoring systems, including completely non-invasive systems.

[0078] Furthermore, for each embodiment of the methods disclosed herein, systems and apparatuses capable of performing each of those embodiments are covered within the scope of this disclosure. For example, embodiments of sensor control devices, reader devices, local computer systems, and trusted computer systems are disclosed, and these devices and systems may have one or more sensors, analyte monitoring circuitry (e.g., analog circuitry), memory (e.g., for storing instructions), power supply, communication circuitry, transmitter, receiver, processor, and / or controller (e.g., for executing instructions), which can perform any and all method steps, or facilitate the performance of any and all method steps.

[0079] As previously described, many embodiments described herein provide improved GUIs, alarms, and digital interfaces for analyte monitoring systems, wherein the alarms and GUIs are operable, user-friendly, and provide quick access to the user's physiological information. According to some embodiments, for example, methods and interfaces are provided for determining signal loss conditions, invalid current sensor readings, or "no most recent valid sensor reading" conditions in an analyte monitoring system. According to other embodiments, methods and systems are provided for generating interfaces based on configurable and non-configurable analyte level ranges and threshold time ranges. According to other embodiments, methods, systems, and interfaces related to enhanced visibility and voice accessibility modes are provided to improve the visual and auditory accessibility of analyte monitoring software applications. According to some embodiments, for example, methods and interfaces are provided for determining alarm unavailability conditions in an analyte monitoring system. According to other embodiments, methods and systems are provided for determining the compatibility of analyte monitoring software applications. Additional improved digital and user interfaces for analyte monitoring software applications are described.

[0080] This document describes several embodiments of systems, apparatuses, and methods for monitoring and managing an individual's health and nutrition based at least in part on analyte data from in vivo analyte sensors. For example, several embodiments of this disclosure are designed to enable users to track and understand analytes, such as blood glucose, that affect performance over time, before, during, and after training or athletic performance, using commonly available sensor control devices. Thus, athletes and their coaches can better understand the effectiveness of their nutritional choices as they relate to athletic condition and performance. For example, users can use sensor control devices and reader devices to monitor glucose levels, allowing individuals to associate low glucose levels with performance-impairing outcomes such as fatigue. Furthermore, the availability of glucose data measured at frequent intervals over time can inform users when nutritional supplementation is needed and help achieve optimal athletic performance. In other embodiments, monitoring biosensors at a non-medical level ensures that the user's analyte levels remain within a target range. For example, for athletic purposes, athletes may maintain analyte levels within a range, such as between 55 and 200 mg / dL. Advantageously, glucose levels within this range are displayed only at specific values. Therefore, these embodiments can provide users with non-medical analyte data to help promote health and athletic performance, among other benefits.

[0081] According to another embodiment, a method, system, and interface are provided for generating alarms related to an analyte monitoring system on a caregiver's reader device. In some embodiments, for example, a sensor control device worn on a patient's body can wirelessly transmit current sensor readings to the patient's reader device, which in turn can wirelessly transmit the current sensor readings to a cloud-based server. According to one aspect of the embodiment, the cloud-based server can determine whether the received current sensor readings meet an alarm condition, and if so, send an alarm indicator to the caregiver's reader device. In other embodiments, for example, an alarm condition is determined on the patient's reader device, and in response to the detection of the alarm condition, an alarm indicator is sent to the cloud-based server and subsequently "transmitted" to the caregiver's reader device.

[0082] These methods, systems, and digital interfaces collectively and individually improve the accuracy, integrity, and privacy of analyte data collected by analyte monitoring systems, enhance the flexibility of analyte monitoring systems by allowing caregivers to receive information about patient conditions, and improve the alarm capabilities of analyte monitoring systems by providing more robust signal loss detection, to name just a few. These methods, systems, and digital interfaces also improve the convenience, usability, and utility of analyte monitoring systems by allowing people with diabetes to regularly access valuable glucose metrics (GMI), which will help them manage their diabetes. Previously, patients could only learn about their A1C levels through a doctor's blood test order. The user interface described herein utilizes the large amounts of data received from continuous glucose monitors and rapid glucose monitors to calculate and display GMI metrics, a good indicator of A1C, to patients at will. Other improvements and advantages are also provided. Various configurations of these devices are described in detail through implementations that are merely examples.

[0083] Before describing these aspects of the implementation in detail, it is necessary to first describe examples of devices that may exist, for example, in an in vivo analyte monitoring system, and instances of their operation, all of which can be used in conjunction with the implementation described herein.

[0084] Various types of in vivo analyte monitoring systems exist. For example, a "continuous analyte monitoring" system (or "continuous glucose monitoring" system) continuously transmits data from a sensor control device to a reader device without requiring, for example, automatic prompts based on a schedule. As another example, a "flash analyte monitoring" system (or "flash glucose monitoring" system, or simply a "flash" system) is an in vivo system that transmits data from a sensor control device in response to a reader device's request for a scan or data, for example using near-field communication (NFC) or radio frequency identification (RFID) protocols. In vivo analyte monitoring systems can also operate without fingertip calibration.

[0085] In vivo analyte monitoring systems can be distinguished from "ex vivo" systems, which are described as contacting biological samples outside the body (or "ex vivo") and typically include an instrument with 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 levels.

[0086] An in vivo monitoring system may include a sensor that, when positioned within the body, comes into contact with the user's bodily fluids and senses the levels of analytes contained therein. The sensor may be part of a sensor control device residing on the user's body and includes electronics and a power source for enabling and controlling analyte sensing. The sensor control device and variations thereof may also be referred to as a "sensor control unit," a "body electronics" device or unit, a "body" device or unit, or a "sensor data communication" device or unit, to name just a few.

[0087] In vivo monitoring systems may also include means for receiving sensed analyte data from sensor control devices and processing and / or displaying the sensed analyte data to a user in any quantity or form. Such devices and variations thereof may be referred to as “handheld reader devices,” “reader devices” (or simply “readers”), “handheld electronics” (or simply “handheld devices”), “portable data processing” devices or units, “data receivers,” “receiver” devices or units (or simply “receivers”), or “remote” devices or units, to name just a few. Other devices, such as personal computers, have also been used with or incorporated into in vivo and in vitro monitoring systems.

[0088] Example implementation of an in vivo analyte monitoring system

[0089] Figure 1 This is a conceptual diagram depicting an example embodiment of an analyte monitoring system 100, which includes a sensor applicator 150, a sensor control device 102, and a reader device 120. Here, the sensor applicator 150 can be used to deliver the sensor control device 102 to a monitoring location on the user's skin, where a sensor 104 is held in place for a period of time by an adhesive patch 105. The sensor control device 102... Figure 2B and Figure 2C Further description is provided below, and the reader device 120 can be communicated via communication path 140 using wired or wireless technologies. Example wireless protocols include Bluetooth, Bluetooth Low Energy (BLE, BTLE, Bluetooth Smart, etc.), Near Field Communication (NFC), etc. Users can use screen 122 (which may include a touchscreen in many embodiments) and input 121 to view and use applications stored in memory on the reader device 120. The device battery of the reader device 120 can be recharged using power port 123. Although only one reader device 120 is shown, the sensor control device 102 can communicate with multiple reader devices 120. Each reader device 120 can communicate with each other and share data. Further details about the reader device 120 will be referenced below. Figure 2AThe reader device 120 can communicate with the local computer system 170 via communication path 141 using wired or wireless communication protocols. The local computer system 170 may include one or more of a laptop, desktop, tablet, phablet, smartphone, set-top box, video game console, or other computing device, and the wireless communication may include any of a number of applicable wireless networking protocols, including Bluetooth, Bluetooth Low Energy (BTLE), Wi-Fi, or others. As previously described, the local computer system 170 can communicate with the network 190 via communication path 143 via wired or wireless communication, similar to how the reader device 120 can communicate with the network 190 via communication path 142. The network 190 can be any of a number of networks, such as private and public networks, local area networks (LANs) or wide area networks (WANs), etc. The trusted computer system 180 may include a cloud-based platform or server and may provide authentication services, secure data storage, report generation, and may communicate with the network 190 via communication path 144 via wired or wireless technologies. Furthermore, although... Figure 1 A trusted computer system 180 and a local computer system 170 communicating with a single sensor control device 102 and a single reader device 120 are depicted. However, those skilled in the art will understand that the local computer system 170 and / or the trusted computer system 180 are each capable of wired or wireless communication with multiple reader devices and sensor control devices.

[0090] Example implementation of the reader device

[0091] Figure 2A This is a block diagram depicting an example embodiment of a reader device 120, which in some embodiments may include a smartphone. Here, the reader device 120 may include a display 122, an input unit 121, and a processing core 206, which includes a communication processor 222 coupled to a memory 223 and an application processor 224 coupled to a memory 225. It may also include a separate memory 230, an RF transceiver 228 with an antenna 229, and a power supply 226 with a power management module 238. Furthermore, the reader device 120 may also include a multi-function transceiver 232, which may include wireless communication circuitry and can be configured to communicate with the antenna 234 via Wi-Fi, NFC, Bluetooth, BTLE, and GPS. As those skilled in the art will understand, these components are electrically and communicatively coupled in a manner consistent with manufacturing a functional device.

[0092] Example implementation of sensor control device

[0093] Figure 2B and Figure 2CThis is a block diagram depicting an example embodiment of a sensor control device 102 having an analyte sensor 104 and sensor electronics 160 (including analyte monitoring circuitry), which may have most of the processing capabilities for presenting final result data suitable for display to a user. Figure 2B The image depicts a single semiconductor chip 161, which may be a custom application-specific integrated circuit (ASIC). Certain advanced functional units are shown in ASIC 161, including an analog front-end (AFE) 162, power management (or control) circuitry 164, a processor 166, and communication circuitry 168 (which may be implemented as a transmitter, receiver, transceiver, passive circuitry, or other means according to a communication protocol). In this embodiment, both AFE 162 and processor 166 serve as analyte monitoring circuitry; however, in other embodiments, either circuitry may perform analyte monitoring functions. Processor 166 may include one or more processors, microprocessors, controllers, and / or microcontrollers, each of which may be a discrete chip or distributed across multiple different chips (or part of multiple different chips).

[0094] Memory 163 is also included within ASIC 161 and can be shared by various functional units present within ASIC 161, or distributed among two or more of them. Memory 163 can also be a separate chip. Memory 163 can be volatile and / or non-volatile memory. In this embodiment, ASIC 161 is coupled to power supply 172, which can be a coin cell battery, etc. AFE 162 interfaces with and receives measurement data from in vivo analyte sensor 104, and outputs the data in digital form to processor 166, which then processes the data to obtain final results such as discrete and trend values ​​of glucose. This data can then be provided to communication circuitry 168 and transmitted via antenna 171 to reader device 120 (not shown), for example, where the resident software application requires minimal further processing to display the data. According to some embodiments, for example, current glucose values ​​can be transmitted from sensor control device 102 to reader device 120 every minute, and historical glucose values ​​can be transmitted from sensor control device 102 to reader device 120 every five minutes.

[0095] In some embodiments, data acquired from sensor control device 102 may be stored on reader device 120. According to one aspect of some embodiments, such data may include the model and serial number of sensor control device 102, as well as information related to the status, market code, or network address of sensor control device 102. In some embodiments, such data may also include error events detected by sensor control device 102. Furthermore, in some embodiments, one or both of the current glucose value and historical glucose values ​​may include one or more timestamps (e.g., factory time, UTC time, user local time based on time zone, and current time zone).

[0096] In some embodiments, sensor control device 102 may store data such that if reader device 120 is not communicating with sensor control device 102 (e.g., if reader device 120 is out of wireless communication range, powered off, or otherwise unable to communicate with sensor control device 102), the data can then be backfilled to reader device 120 when communication with sensor control device 102 is re-established. According to some embodiments, the data that can be backfilled may include, but is not limited to, current and historical glucose values, and error events. Further details regarding data backfilling can be found in U.S. Patent No. 10,820,842 and U.S. Public Patent No. 2021 / 0282672 (“672 Publication”), which are incorporated herein by reference in their entirety for all purposes.

[0097] According to some implementations, each current glucose value and / or historical glucose value acquired from the sensor control device 102 can be further verified on the reader device 120, for example, by performing a CRC integrity check to ensure that the data has been accurately transmitted. In some implementations, for example, the data quality mask of the current glucose value and / or historical glucose value can be checked to ensure that the reading is correct and can be displayed as a valid reading on the reader device 120.

[0098] According to another aspect of the implementation, the reader device 120 may include a database for storing any or all of the aforementioned data. In some implementations, the database may be configured to retain data for a predetermined period of time (e.g., 30 days, 60 days, 90 days, 6 months, one year, etc.). According to some implementations, the database may be configured to delete data after it has been uploaded to a cloud server. In other implementations, the database may be configured for clinical settings, where data is retained for a longer period of time (e.g., one year) compared to non-clinical settings. In addition to the aforementioned data (e.g., current and / or historical glucose values, error events, etc.), the database on the reader device 120 may also store user configuration information (e.g., login ID, notification settings, regional settings, and other preferences) and application configuration information (e.g., cloud settings, URLs used for uploading data and / or error events, version information, etc.). The database may be encrypted to prevent users from directly inspecting the data content, even if the operating system of the reader device 120 is compromised.

[0099] In some embodiments, to conserve power and processing resources on the sensor control device 102, digital data received from the AFE 162 can be sent to the reader device 120 (not shown) for minimal or no processing. In other embodiments, the processor 166 can be configured to generate certain predetermined data types (e.g., current glucose value, historical glucose value) for storage in the memory 163 or for transmission to the reader device 120 (not shown), and to determine certain alarm conditions (e.g., sensor malfunction conditions), while other processing and alarm functions (e.g., high / low glucose threshold alarms) can be performed on the reader device 120. Those skilled in the art will understand that the methods, functions, and interfaces described herein can be performed, in whole or in part, by processing circuitry on the sensor control device 102, the reader device 120, the local computer system 170, or the trusted computer system 180.

[0100] Figure 2C Similar to Figure 2BAlternatively, it may include two discrete semiconductor chips 162 and 174, which may be packaged together or separately. Here, AFE 162 resides on ASIC 161. Processor 166 is integrated with power management circuitry 164 and communication circuitry 168 on chip 174. AFE 162 may include memory 163, while chip 174 includes memory 165, which may be isolated or distributed within it. In one example embodiment, AFE 162 is combined with power management circuitry 164 and processor 166 on a single chip, while communication circuitry 168 is on a separate chip. In another example embodiment, both AFE 162 and communication circuitry 168 are on a single chip, while processor 166 and power management circuitry 164 are on another chip. It should be noted that other chip combinations are possible, including three or more chips, each responsible for the individual functions described, or sharing one or more functions for fail-safe redundancy.

[0101] Example implementation of a graphical user interface for an analyte monitoring system

[0102] This document describes example implementations of a GUI for an analyte monitoring system, along with related methods and systems. First, those skilled in the art will understand that the GUI and related methods described herein include instructions stored in the non-transitory memory of a reader device 120, a local computer system 170, a trusted computer system 180, and / or any other device or system that is part of or communicates with the analyte monitoring system 100. When these instructions are executed by one or more processors of the reader device 120, the local computer system 170, the trusted computer system 180, or other devices or systems of the analyte monitoring system 100, the one or more processors perform method steps and / or output the GUI described herein. Those skilled in the art will further recognize that the GUI described herein may be stored as instructions in the non-transitory memory of a single centralized device, or alternatively, may be distributed across multiple discrete devices in geographically dispersed locations.

[0103] This document also describes example implementations of alarms, alarm features, and alarm settings for an analyte monitoring system, as well as related methods, systems, and GUIs. First, those skilled in the art will understand that the alarms, alarm features, and alarm settings described herein, along with the related methods and interfaces, may include instructions (e.g., software, firmware, etc.) stored in the non-transitory memory of the sensor control device 102, reader device 120, local computer system 170, trusted computer system 180, and / or any other computing device or system (e.g., a cloud-based server) that is part of or communicates with the analyte monitoring system 100. When executed by one or more processors of the respective system or device, these instructions cause one or more processors to perform any or all of the method steps and / or output the alarms or alarm interfaces described herein. Those skilled in the art will further recognize that the alarms, alarm features, alarm settings, and alarm interfaces described herein may be stored as instructions in the non-transitory memory of a single centralized device, or alternatively, may be distributed across multiple discrete devices in geographically dispersed locations.

[0104] Example implementation of signal loss indicators, alarms, and other error conditions

[0105] Example embodiments of methods and systems for determining signal loss conditions, generating signal loss indicators and alarms, and outputting signal loss interfaces and GUIs will now be described. According to one aspect of the embodiments, a signal loss condition may refer to the state of a device capable of wireless communication in an analyte monitoring system, such as a reader device (e.g., a smartphone), a sensor control unit, or a local computing system, wherein the device has not received a current sensor reading within a predetermined time period. According to another aspect of the embodiments, a signal loss alarm condition may include a state where the device has not received a valid current sensor reading within another predetermined time period. In some embodiments, an invalid current sensor reading may include one of failing to receive a current sensor reading within a predetermined time period, an error related to the sensor signal, or an error related to the sensor temperature.

[0106] Figure 3AThis is a flowchart depicting an example implementation of a method 300 for determining a signal loss condition. In step 302, a current sensor reading is received. According to many embodiments, the current sensor reading may be received by a reader device (e.g., a smartphone). In other embodiments, the current sensor reading may be received by a sensor control device, a local computing system, or any other device capable of communicating with the analyte sensor or sensor control device. In step 304, the time elapsed since the last current sensor reading was received is determined. In some embodiments, this step can be performed by obtaining the current time from the device's clock (or alternatively, from a clock communicating with the device, such as a web time server) and comparing the current time with a timestamp associated with the last received current sensor reading. In step 306, the time elapsed since the last received current sensor reading is compared with a predetermined signal loss indicator threshold. In some embodiments, for example, the signal loss indicator threshold may be a time period equal to or less than twenty minutes (e.g., 1, 2, 3, 4, 5, 10, or 15 minutes). In step 308, if the elapsed time is not greater than the signal loss indicator threshold, method 300 returns to step 304 to determine the next elapsed time value. If the elapsed time exceeds a signal loss indicator threshold, a signal loss indicator is generated. According to some implementations, the signal loss indicator may be a visual message or notification output to a device display. In some implementations, the signal loss indicator message may include a portion of the sensor results screen (e.g., Figure 4A (The implementation shown is illustrated in the figure). In other implementations, the signal loss indicator may include a new screen, pop-up window, or banner notification that may persist on the display until cleared by the user, or be configured to disappear after a certain period of time. In other implementations, the signal loss indicator may be an audible or vibration signal output to the device.

[0107] Although not shown, according to some embodiments, once the signal loss condition has been resolved (e.g., new current sensor readings are received), the device can receive historical sensor readings to fill in any missing data on the device. Further details regarding data backfilling are described in the '672 publication text, which is incorporated herein by reference in its entirety for all purposes.

[0108] Figure 3B This is a flowchart depicting another example implementation of method 310 for determining signal loss conditions. Similar example implementations to method 300 (as per [reference]) Figure 3A(As described), method 310 may further include the following steps: in step 312, receiving a current sensor reading; in step 314, determining the time elapsed since the last current sensor reading was received; in step 316, comparing the time elapsed since the last received current sensor reading with a predetermined signal loss indicator threshold; and in step 318, generating a signal loss indicator in response to determining that the elapsed time is greater than the signal loss indicator threshold. (Refer to below...) Figure 4A An example describing a signal loss indicator. According to one aspect of the implementation, in step 320, method 310 may further include a step of determining whether the current sensor reading is valid. If the current sensor reading is determined to be valid, then in step 324, the valid current sensor reading is output to the device's display. (For example, see...) Figure 7E-1 However, if the current sensor reading is invalid, an invalid sensor reading indicator is generated in step 322. As an example only, if the current sensor reading is invalid due to the sensor being too hot, the invalid sensor reading indicator could output a message to the device's display indicating that the sensor is too hot to provide an accurate sensor reading. (See, for example, [link to relevant documentation]). Figure 4C (See below for reference) Figures 4A to 4E Describe other exemplary invalid sensor reading indicators.

[0109] Figure 3C This is a flowchart depicting an example implementation of a method 330 for determining a situation where there is no most recent valid sensor reading. In step 332, the device (e.g., a reader device or smartphone) receives the current sensor reading. In step 334, it is determined whether the current sensor reading is valid. If the current sensor reading is valid, then in step 336, the valid current sensor reading is output to the device's display. (See, for example, [link to relevant documentation]). Figure 7E-1 According to method 330, if the current sensor reading is invalid, an invalid reading indicator is generated in step 338. (For example, see...) Figure 4C ).

[0110] Still referencing Figure 3CIn step 340, the time elapsed since the last valid current sensor reading is determined. In some embodiments, this step can be performed by obtaining the current time from the device's clock (or alternatively, from a clock communicating with the device, such as a network time server) and comparing the current time with a timestamp associated with the last valid current sensor reading. In step 342, the time elapsed since the last valid current sensor reading is compared with a predetermined no-recent-valid-sensor-reading alarm threshold. In some embodiments, for example, the no-recent-valid-sensor-reading alarm threshold may be a time period greater than five minutes (e.g., 10, 15, 20, 25, or 30 minutes). Furthermore, according to some embodiments, the no-recent-valid-sensor-reading alarm threshold may be user-configurable. If it is determined that the elapsed time is not greater than the alarm threshold, method 330 returns to step 332 to receive the next current sensor reading. However, if the elapsed time is greater than the alarm threshold, in step 344, a no-recent-valid-sensor-reading alarm is generated. According to some embodiments, the no-recent-valid-sensor-reading alarm may include a visual notification (e.g., pop-up, banner, new screen) output to the device's display. (See, for example, see...) Figure 4I and Figure 4J ).

[0111] Figure 3DThis is a flowchart depicting an example implementation of a method 350 for prioritizing and generating various error and analyte level indicators associated with current sensor readings. In step 352, a device (e.g., a reader device or smartphone) receives the current sensor reading. In step 354, the time elapsed since the last current sensor reading was received is determined. In some implementations, this step can be performed by obtaining the current time from the device's clock (or alternatively, from a clock communicating with the device, such as a web time server) and comparing the current time with a timestamp associated with the last received current sensor reading. In step 356, the time elapsed since the last received current sensor reading is compared with a predetermined signal loss indicator threshold. In some implementations, for example, the signal loss indicator threshold may be a time period equal to or less than twenty minutes (e.g., 1, 2, 3, 4, 5, 10, or 15 minutes). In step 358, if the elapsed time is greater than the signal loss indicator threshold, a signal loss indicator is generated. However, if the elapsed time is not greater than the signal loss indicator threshold, method 350 continues to check various errors associated with the current sensor readings in a predetermined priority order. In step 360, it is determined whether an error related to the sensor signal exists. For example, a software algorithm on the sensor control device can determine whether an early signal attenuation condition has been detected, and if so, this information can be sent to the device either as a separate packet or as part of the current sensor reading. If an error related to the sensor signal is detected, a sensor error indicator can be generated in step 362. (See, for example, [link to relevant documentation]). Figure 4E ).

[0112] If no error related to the sensor signal is detected, method 350 proceeds to step 364 to determine whether an error related to the temperature of the sensor or skin exists. According to one aspect of the implementation, the sensor control device may include a temperature sensing element (e.g., a thermistor) capable of sensing the temperature of the sensor or skin. In some implementations, the sensor control device may send a raw temperature reading to the device, wherein the device may determine whether the received temperature reading exceeds one or more predetermined temperature thresholds. In other implementations, the sensor control device itself may determine whether the temperature reading exceeds one or more predetermined temperature thresholds, and if so, send an indication to the device only if the threshold is exceeded (either as part of the current sensor reading or as a separate group). If an error related to the temperature of the sensor or skin is detected, a temperature error indicator may be generated in step 366. (See, for example, see...) Figure 4C and Figure 4D ).

[0113] If no error related to sensor or skin temperature is detected, method 350 proceeds to step 368 to determine if an analyte level condition exists. In some implementations, for example, an analyte level condition may include one or more of the following: glucose level outside a non-configurable glucose level range, glucose level above a high glucose level threshold, glucose level below a low glucose level threshold, predicted glucose level above a high predicted glucose level threshold, predicted glucose level below a low predicted glucose level threshold, glucose level within a user-configured target range, or glucose level outside a user-configured target range. If an analyte level condition is determined to exist, in step 370, an analyte condition indicator is generated. (See, for example, see...) Figure 7D-1 and Figure 7F-1 If it is determined that there is no analyte level, then in step 372, the valid current sensor reading is output to the device's display. (For example, see...) Figure 7E-1 ).

[0114] Although the above description refers to glucose level conditions, those skilled in the art will understand that conditions related to other analyte levels and thresholds (e.g., ketone levels, lactate levels, etc.) can also be implemented using any of the exemplary implementation methods described herein, and are fully within the scope of this disclosure.

[0115] Those skilled in the art will also understand that Figure 3D The priority order depicted herein, and the priority order described regarding the aforementioned errors and analyte level conditions, are merely illustrative. In other embodiments not shown, for example, temperature error determination may occur before sensor signal error determination. Other combinations and priority orders are possible and are entirely within the scope of this disclosure.

[0116] Figures 4A to 4J It is a reference Figures 3A to 3D An example implementation of the GUI used in conjunction with the described methods.

[0117] Figure 4A This is a GUI 400 depicting a signal loss indicator 402 as part of the sensor results screen. According to one aspect of the embodiment, the signal loss indicator 402 may indicate that no current sensor reading was received within a time period including a signal loss indicator threshold. According to another aspect of the embodiment, the signal loss indicator 402 may be accompanied by placeholder characters (e.g., three dashed lines 404) instead of numerical analyte level values ​​and trend arrow indicators, such as... Figure 7E-1As shown. Furthermore, according to some embodiments, the signal loss indicator 402 may include an information icon that, when pressed by the user, can display additional information and user guidance related to the error condition in an information window (408A or 408B). According to another embodiment, the GUI 400 may further include information related to historical sensor readings, such as a glucose trend line 406. In this way, the user is notified of the current signal loss condition, but can also view previous historical sensor readings.

[0118] Figures 4B to 4E This is an example implementation of a GUI that includes various error indicators as part of the sensor results screen. Figure 4B The GUI 410 depicts a Bluetooth off indicator 412 to indicate that the device's Bluetooth transmitter has been disabled or turned off. The Bluetooth off indicator 412 may also be accompanied by placeholder characters 416 (in place of digital analyzer level and trend arrow indicators) and an information icon 414, which, when pressed by the user, causes an information window 420 to display additional information and user guidance related to the error condition. The GUI 410 further includes information related to historical sensor readings, such as a glucose trend line 418.

[0119] Figure 4C and Figure 4D GUIs 430 and 450 respectively depict a sensor overheat indicator 432 and a sensor overcool indicator 452, each indicating an error related to sensor temperature or skin temperature. Indicators 432 and 452 are further accompanied by placeholder characters and information icons 424 and 454 (displayed as thermometer icons), which, when pressed by the user, cause information windows 440 and 460 to display additional information and user guidance related to the error condition. GUIs 430 and 450 may also include information related to historical sensor readings, such as glucose trend lines.

[0120] Figure 4EThis is a GUI 470 depicting a sensor error indicator 472 for indicating errors related to the sensor signal. In some embodiments, the sensor error may be an error related to the sensor signal detected on a sensor control device. For example, the error may be associated with the detection of early signal attenuation. As another example, the error may be associated with a rate of change exceeding a predetermined threshold, such as that measured by the sensor control device. Those skilled in the art will understand that the sensor error indicator 472 may indicate other signal-related errors diagnosed by the sensor control device and is fully within the scope of this disclosure. According to another aspect of the embodiments, the indicator 472 is accompanied by an information icon 474, which, when pressed by the user, causes an information window 480 to display additional information and user guidance related to the error condition. For example, the information window 480 may include instructions for the user to check the analyte readings after a predetermined time period (e.g., ten minutes). According to some embodiments, the predetermined time period presented in the information window 480 may be variable based on the remaining time until the error condition is expected to be resolved. In other embodiments, the predetermined time period may be a static value.

[0121] Figures 4F to 4H These are GUIs 482 and 489, which depict an interface for allowing users to configure alarms for no most recent valid sensor readings (sometimes also called "signal loss alarms"). First refer to... Figure 4F The GUI 482 includes a switch 484 that can be toggled between an "on" and an "off" position to activate or deactivate the signal loss alarm, respectively. If the switch is to the "on" position, additional configuration settings are displayed, such as... Figure 4G As shown. According to another aspect of the embodiment, these additional settings may include an alarm tone setting 486 and a Do Not Disturb overlay switch 488. In some embodiments, if the Do Not Disturb overlay switch 488 is enabled, a signal loss alarm will be displayed even if the Do Not Disturb mode of the device operating system is enabled. Furthermore, according to other embodiments, pressing the alarm tone setting 486 may result in the display of a GUI 489, which includes a plurality of radio buttons 490 to allow the user to select a specific alarm tone (e.g., custom, standard, etc.).

[0122] Figure 4I and Figure 4JThese are GUIs 494 and 498 depicting an alarm interface for an alarm indicating no recent valid sensor reading or a "signal loss alarm." As shown, alarm interface 496 may include a window or banner notification containing the text "Signal Loss Alarm, Glucose Alarm Unavailable." According to some embodiments, alarm interface 496 may be configured to display whether the device is currently locked, whether a third-party application (e.g., YouTube) is in the foreground, or whether analyte monitoring software is in the foreground. In some embodiments, alarm interface 496 may be configured as a temporary notification that may disappear after a predetermined amount of time without user interaction. In other embodiments, alarm interface 496 may remain on the display until the user has acknowledged or deactivated the alarm.

[0123] Example implementation of a method for generating an interface within a time range

[0124] Example implementations of methods for generating time-range interfaces will now be described. According to one aspect of the implementation, the time-range interface can provide useful information to a patient attempting to monitor and manage their analyte levels by presenting information in a histogram format, which can provide a unique perspective on the patient's glycemic control. In many implementations, the time-range interface provides the percentage of time during which the patient's analyte level falls within a specific analyte level range within a predetermined reporting period. Furthermore, according to some implementations, some analyte level ranges can be based on consensus criteria, while other analyte level ranges can be customized to suit the patient's individual goals. Further details regarding time-range interfaces are described in the '672 publication text, which is incorporated herein by reference in its entirety for all purposes.

[0125] Figure 5AThis is a flowchart depicting an example implementation of method 500 for generating an interface within a time range. In step 502, multiple historical sensor readings are received. According to many implementations, the multiple historical sensor readings may be received by a reader device (e.g., a smartphone). In other implementations, the multiple historical sensor readings may be received by a sensor control device, a local computing system, or any other device capable of communicating with the analyte sensor or sensor control device. In step 504, a first time percentage above (or below) a non-configurable analyte threshold can be calculated using the multiple historical sensor readings received during a predetermined reporting period. In some implementations, for example, the predetermined reporting period may be a user-configurable date range. In step 506, a second time percentage above, below, or within a user-configurable analyte range can be calculated using the same multiple historical sensor readings received during the predetermined reporting period. In step 508, a graphical representation of the first and second time percentages within the predetermined reporting period is generated and output to a display of the device. In this way, method 500 provides a time-range interface that may include information about patient glycemic control based on both a non-configurable threshold (e.g., according to consensus criteria) and a user-configurable threshold or range.

[0126] Figure 5B This is a flowchart depicting an example implementation of a method 510 for generating an interface within another time frame. In step 512, multiple historical sensor readings are received by a device (e.g., a reader device or smartphone). In step 514, a first percentage of time below a first non-configurable analyte threshold can be calculated using the multiple historical sensor readings received during a predetermined reporting period. As an example only, in some implementations, the first non-configurable analyte threshold may include a threshold of 54 mg / dL (3 mmol / L) that the user cannot change. In step 516, a second percentage of time below a second non-configurable analyte threshold can be calculated using the multiple historical sensor readings received during the predetermined reporting period. According to some implementations, the second non-configurable analyte threshold may include a threshold of 70 mg / dL (3.9 mmol / L) that the user cannot change.

[0127] Still referencing Figure 5B In step 518, a third time percentage below the configurable analyte range can be calculated using multiple historical sensor readings received during a predetermined reporting period. In step 520, a fourth time percentage above the configurable analyte range can be calculated using multiple historical sensor readings received during the predetermined reporting period. According to one aspect of the implementation, the configurable analyte range may include a target glucose range (e.g., an upper target analyte level and a lower target analyte level) that can be changed by the user.

[0128] In step 522, a fifth time percentage above the third non-configurable analyte threshold can be calculated using multiple historical sensor readings received during a predetermined reporting period. As an example only, in some embodiments, the third non-configurable analyte threshold may include a threshold of 250 mg / dL (13.9 mmol / L) that the user cannot change. In step 524, a sixth time percentage within the configurable analyte range can be calculated using multiple historical sensor readings received during the predetermined reporting period. As mentioned above, the configurable analyte range may include a target glucose range (e.g., an upper target analyte level and a lower target analyte level) that can be changed by the user.

[0129] In step 526, based on the received historical sensor readings, a graphical representation of the first, second, third, fourth, fifth, and sixth time percentages can be generated for the predetermined reporting period. According to some embodiments, for example, each time percentage can be graphically represented as a single bar, with the length of each bar proportional to the percentage value. In other embodiments, the time percentage can be graphically represented as a portion of a single bar, with the length of each portion proportional to the percentage value. In still other embodiments, the time percentage can be graphically represented as a portion or segment of a circle (e.g., a pie chart), with the area of ​​each portion or segment proportional to the percentage value.

[0130] although Figure 5B The example implementation describes calculating and generating a graphical representation of six time percentages, wherein three time percentages are associated with a non-configurable threshold / range and three time percentages are associated with a configurable threshold / range. However, those skilled in the art will recognize that method 510 can be used to calculate and generate graphical representations of any number of time percentages with any combination of non-configurable and configurable ranges and / or thresholds. Further details of the graphical representation of the interface within the time range are described in the '672 disclosure, which is incorporated herein by reference in its entirety for all purposes.

[0131] Figure 5C This is a flowchart depicting an example implementation of method 530 for generating an interface within a time range to illustrate historical sensor readings that do not fall within one of configurable or non-configurable thresholds / ranges. In some cases, one or more historical sensor readings may not fall within one of the configurable or non-configurable thresholds / ranges, such that the sum of the time percentages is not equal to 100%. For example, one or more historical sensor readings may include non-numerical values ​​(e.g., error conditions) or values ​​that do not fall within any configurable or non-configurable thresholds / ranges. In one aspect, method 530 may apply adjustments to address these situations.

[0132] In step 532, a device (e.g., a reader device or smartphone) receives multiple historical sensor readings. In step 534, a first time percentage above (or below) a non-configurable analyte threshold can be calculated using the multiple historical sensor readings received during a predetermined reporting period. In step 536, a second time percentage above, below, or within the range of user-configurable analytes can be calculated using the same multiple historical sensor readings received during the predetermined reporting period. In step 538, it is determined whether the sum of the first and second time percentages equals 100. If so, method 530 proceeds to step 542, where a graphical representation of the first and second time percentages is generated for the reporting period. If the sum of the first and second time percentages does not equal 100, method 530 proceeds to step 540. In step 540, it is determined which time percentage has the highest value. Subsequently, the time percentage with the highest value is adjusted. In some embodiments, for example, the time percentage with the highest value is adjusted such that the sum of the first and second time percentages equals 100. In other embodiments, also as an example, the time percentage with the highest value is adjusted by multiplying it by a factor. In other implementations, the minimum value of the time percentage is adjusted so that the sum of the time percentages equals 100. After the adjustment is applied in step 540, method 530 proceeds to step 542, where a graphical representation of the first and second time percentages is generated for the reporting period.

[0133] Although described using first and second time percentages Figure 5C This is an example implementation, but those skilled in the art will understand that method 530 can be applied to any number of time percentages. As an example, method 530 can be used to adjust percentages when six time percentages exist, as referenced... Figure 5B As described.

[0134] According to another aspect of the implementation, when multiple time percentages share a maximum value, individual percentages can be adjusted based on a predetermined priority order. For example, in some implementations, the priority order can be (from highest priority to lowest priority): time percentages above 250 mg / dL, time percentages above the target glucose range, time percentages within the target glucose range, time percentages below the target glucose range, time percentages below 70 mg / dL, and time percentages below 54 mg / dL.

[0135] Example implementations related to enhanced visibility patterns

[0136] Methods and example implementations of GUIs related to enhanced visibility patterns will now be described. In certain environments, it may be necessary to enhance the display of a computing device for better visibility relative to many of the digital and graphical interfaces described herein. For example, certain color shadows in a chart or graph may be difficult to see in low-light settings due to a lack of contrast between colors. As another example, the interface may be modified to utilize certain background colors that provide less eye strain in low-light settings.

[0137] Figure 6 This is a flowchart depicting an example embodiment of a method 600 for enabling an enhanced visibility mode. In step 602, a graphical representation of a digital or graphical user interface, including any interface described herein, is generated based on the normal visibility mode and output to a display of the device. According to many embodiments, the device may be a reader device, such as a smartphone. In other embodiments, the device may be a local computing system or any other device capable of communicating with an analyte sensor or sensor control device. In step 604, the device receives an instruction to enable the enhanced visibility mode. According to one aspect of the embodiment, the instruction to enable the enhanced visibility mode may be a user-configurable setting of the device's operating system (e.g., iOS, Android). In other embodiments, the instruction to enable the enhanced visibility mode may be a user-configurable setting within an analyte monitoring software application. In some embodiments, the instruction to enable the enhanced visibility mode may be automatically generated in response to light detected above or below a predetermined activation threshold by a light sensor (e.g., a photoelectric device, photosensor, phototransistor, photoresistor, and / or photodiode). In other embodiments, the instruction to enable the enhanced visibility mode may be generated based on a predetermined schedule (e.g., 6:00 PM to 6:00 AM) or a seasonal schedule (e.g., sunset to sunrise). Those skilled in the art will understand that other activation mechanisms can be utilized, and are fully within the scope of this disclosure.

[0138] Still referencing Figure 6 In step 606, an enhanced visibility mode is enabled on the device. According to some embodiments, the enhanced visibility mode may remain enabled until manually disabled by the user. In other embodiments, the enhanced visibility mode may be disabled after a timer expires, or alternatively, disabled according to a predetermined schedule or seasonal schedule. In other embodiments, the enhanced visibility mode may be disabled in response to a light sensor detecting light above or above a predetermined deactivation threshold. Subsequently, in step 608, a graphical representation of a digital or graphical user interface, including any interface described herein, is generated based on the enhanced visibility mode and output to the device's display.

[0139] Figures 7A-1 to 7I-2This refers to the GUI (User-Defined Interface) that describes the interface used in analyte monitoring software applications. Specifically, each GUI is displayed in both normal and enhanced visibility modes. Figure 7A-1 and Figure 7A-2 It is a GUI that depicts the sensor warm-up interface for analyte monitoring software applications, displayed according to normal visibility mode and enhanced visibility mode respectively. Figure 7B-1 and Figure 7B-2 It is a GUI that depicts the main screen of the analyte monitoring software application, displayed according to normal visibility mode and enhanced visibility mode respectively. Figure 7C-1 and Figure 7C-2 It is a GUI that depicts the menu interface for analyte monitoring software applications, displayed according to normal visibility mode and enhanced visibility mode respectively. Figure 7D-1 , Figure 7D-2 , Figure 7E-1 , Figure 7E-2 , Figure 7F-1 and Figure 7F-2 It is a GUI that describes the sensor results interface for analyte monitoring software applications, displayed according to normal visibility mode and enhanced visibility mode. Figure 7G-1 , Figure 7G-2 , Figure 7H-1 , Figure 7H-2 , Figure 7I-1 and Figure 7I-2 This describes a GUI for a reporting interface used in analyte monitoring software applications, displayed according to normal visibility mode and enhanced visibility mode. These described embodiments are intended to illustrate examples of GUIs and interfaces in normal and enhanced visibility modes, and those skilled in the art will readily understand that the disclosure of enhanced visibility mode is not limited to the specific embodiments shown and / or described.

[0140] Example implementations related to voice accessibility modes

[0141] The methods and example implementations of the GUI related to enhanced accessibility modes will now be described. According to one aspect of the implementation, a voice accessibility mode can be enabled to provide an auditory description of the interface on the device's display. In some implementations, the voice accessibility mode may further include gesture recognition, such that when a user touches the display (e.g., drags a finger on a portion of the display), the voice accessibility mode translates the touched portion of the display into an auditory output. In this way, the voice accessibility mode can be configured to increase accessibility for blind and visually impaired users, as well as users with reading difficulties.

[0142] Figure 8This is a flowchart depicting an example implementation of a method 800 for enabling a voice accessibility mode. In step 802, a graphical representation of a digital or graphical user interface, including any interface described herein, is generated based on the normal visibility mode and output to the device's display. According to many implementations, the device may be a reader device, such as a smartphone. In other implementations, the device may be a local computing system or any other device capable of communicating with an analyte sensor or sensor control device. In step 804, the device receives an instruction to enable the voice accessibility mode. According to one aspect of the implementation, the instruction to enable the voice accessibility mode may be a user-configurable setting of the device's operating system (e.g., iOS, Android). In other implementations, the instruction to enable the voice accessibility mode may be a user-configurable setting within an analyte monitoring software application.

[0143] Still referencing Figure 8 In step 806, a voice accessibility mode is enabled on the device. According to some embodiments, the voice accessibility mode may remain enabled until manually disabled by the user. Subsequently, in step 808, a text-enhanced graphical representation of a digital or graphical user interface and associated auditory output are generated based on the voice accessibility mode. For example, in some embodiments, certain graphics, non-text icons, or indicators (e.g., trend arrows) on the interface may be replaced with descriptive text or text elements, which can then be converted into auditory output via the voice accessibility mode. In other embodiments, certain gesture-responsive portions of the interface may be configured to cause the device to convert text into auditory speech. In other embodiments, certain touch-responsive portions of the interface may be grouped and configured such that the device converts the text in the entire group into auditory speech in response to a user touching any portion associated with that group. In other embodiments, the voice accessibility mode may be integrated with a virtual assistant (e.g., Siri, Alexa), allowing the user to input text without requiring any touch-based input.

[0144] Figure 9A This is a GUI 900 depicting a low glucose alert interface 905 on a smartphone display, where a voice accessibility mode is enabled. According to one aspect of the embodiment, the alert interface 905 includes text modified by the voice accessibility mode. Specifically, standard abbreviations, such as mg / dL, have been replaced with unabbreviated terms. Furthermore, non-text trend arrows have been replaced with descriptive text (e.g., “slowly changing”). According to another aspect of the embodiment, the voice accessibility mode can convert the modified text portions into auditory output.

[0145] Figure 9BThis is another GUI 910 depicting the sensor results interface 910 of the analyte monitoring software application, in which a voice accessibility mode has been enabled. As indicated by the highlighted upper left portion, if the user touches the graphical icon 912, an auditory output is generated (e.g., saying, "Check blood glucose"). According to another aspect of the embodiment, GUI 910 includes groupings of different graphical elements of the interface such that if the user touches any part of the interface 914, an auditory output is generated (e.g., saying, "251 mg / dL and changing slowly. Check blood glucose").

[0146] Additional example implementations of digital and user interface technologies for analyte monitoring

[0147] Additional example implementations of digital and user interface methods for analyte monitoring will now be described. First refer to Figure 10A GUI 1000 depicts a sensor usage report interface. According to one aspect of the implementation, the sensor usage report interface may include a total view metric 1002, indicating the total number of views over a predetermined time period; a daily view metric 1004, indicating the average number of views per day over a predetermined time period; and a time percentage sensor activity metric 1006, indicating the percentage of a predetermined time period during which the device communicates with a sensor control device. Furthermore, GUI 1000 may include an information icon, which, when pressed, causes an information window 1008 to display additional information related to sensor usage information. According to one aspect of the implementation, a "view" may be defined as an instance where the sensor results interface is presented or placed in the foreground. According to other embodiments, a "view" may be defined as an instance when a user first views a sensor results interface with valid sensor readings in the sensor lifetime count. Further details regarding the view metrics are described in the '672 disclosure, which is incorporated herein by reference in its entirety for all purposes.

[0148] Figures 10B to 10G Various interfaces associated with the glucose management indicator, or GMI, are described. Hemoglobin A1C has been used to measure patients’ average blood glucose levels over the past three months. It is commonly used as an indicator of a patient’s control of diabetes or in the detection of diabetes or prediabetes. It is also a risk marker for diabetic complications. Given the increasing use of continuous glucose monitoring and rapid monitoring systems, a new term, “glucose management indicator” or “GMI,” has been established based on population data from clinical trials using CGM systems and on average glucose conversions from continuous or rapid monitoring systems. See Bergenstal, RM, et al., “Glucose Management Indicator (GMI): A New Terminology for Estimating AIC from Continuous Glucose Monitoring.” Diabetes Care 41(11):2275-80 (November 2018), which is explicitly incorporated herein by reference in its entirety for all purposes.

[0149] GMI can be reported as a percentage of the reporting period or as a value in mmol / mol for the reporting period. The percentage of GMI for the reporting period can be calculated using formula (1). The GMI value in mmol / mol can be calculated using formula (2).

[0150] GMI(%)=round_to_0.1{3.31+0.02392*(G avg )}(1)

[0151] GMI(mmol / mol)=round{12.71+4.70587*(G avg )}(2).

[0152] Figure 10B An example implementation of a user interface related to a GUI for an analyte monitoring system is depicted. According to one aspect of the implementation, the user interface 1010 may be presented and displayed, for example, by a mobile application or software residing in a non-transitory memory of the reader device 120, such as regarding… Figure 1 and Figure 2A Those described. References Figure 10B The user interface 1010 may include a time interval 1012 indicating the time period (e.g., date range) during which the GMI metric is determined. GMI metrics 1014, 1015 may be displayed as a GMI percentage, a GMI value in mmol / mol, or both. Additional indications 1018 regarding the number of days 1018 in which data is considered within the time interval 1012 may also be displayed. In one embodiment, the user interface 1010 may include one or more GMI metrics 1014, 1015. In another embodiment, the user interface 1010 may include a GMI percentage 1014 for the time period 1012 and a GMI value 1015 in mmol / mol. When displaying more than one GMI metric, one of the GMI metrics may be displayed more prominently than another. For example, the GMI percentage 1014 may be displayed in a larger font or a different color than the GMI value 1015 in mmol / mol. The user interface 1010 may also include an indication of the current remaining lifespan of the sensor. For example, a statement 1022 indicating that the sensor will end in a certain number of days may be displayed at the bottom. The user interface 1010 may also include options 1020 for sharing or otherwise saving one or more GMI metrics. The user interface 1010 may also include links (e.g., "i") 1024 for clicking to obtain more information about GMI. After the user clicks link 1024, a GUI 1026 with a description of GMI may be displayed. For example, as... Figure 10CAs shown, this description can explain why GMI uses average sensor glucose data and can be used as an indicator of how well a patient's glucose levels have been controlled.

[0153] Figure 10D An example implementation of GMI measurement 1033 as part of the Analyte Monitoring System Reporting GUI 1031 is depicted. According to one aspect of the implementation, GUI 1031 can be displayed on a computing device (e.g., a personal computer, desktop computer, laptop computer, reader device, tablet computer, etc.) via a web browser, a web-enabled client, or software residing in non-transitory memory of the computing device. In some implementations where the user interface is displayed via a web browser or a web-enabled client, software instructions can be executed on a remote server (or a group of remote servers), which in turn can cause the web browser or web-enabled client residing on the computing device to display the user interface. According to one aspect of the implementation, GUI 1031 is a snapshot report covering a predetermined time period 1035 (e.g., 14 days) and includes multiple reporting sections on a single reporting GUI, including: a GMI metric 1033, a sensor user interface section 1036, a glucose trend interface 1039 which may include a glucose trend chart, a low glucose event chart, a health information interface 1040 which may include information recorded by the user regarding the user's average daily carbohydrate intake and medication dosage (e.g., insulin dosage); and an annotation interface 1042 which may include additional information about the user's analyte and medication patterns presented in a narrative format. GMI metric 1033 may be reported as a GMI percentage, a GMI value in mmol / mol, or both. According to another aspect of the implementation, sensor user interface 1036 may include a time-percentage sensor activity metric 1044, an average scan / view metric 1046 (e.g., indicating the average sum of scans and views), and a time-percentage sensor activity graph 1048. Figure 10D As can be seen, the axes of the time percentage sensor activity graph can be aligned with the corresponding axes of one or more other graphs (e.g., the average glucose trend graph, the low glucose event graph), allowing users to visually correlate data between multiple graphs from two or more parts of the reporting GUI through a common unit from the aligned axes (e.g., time of day).

[0154] Figure 10E and Figure 10FAn example implementation of a GMI metric 1064, as part of an analyte monitoring system reporting GUI 1060, 1061, is depicted, providing insights into a patient's diabetes management. According to one aspect of the implementation, GUI 1060, 1061 can be displayed on a computing device (e.g., a personal computer, desktop computer, laptop computer, reader device, tablet computer, etc.) via a web browser, a web-enabled client, or software residing in non-transitory memory of the computing device. In some implementations where the user interface is displayed via a web browser or a web-enabled client, software instructions can be executed on a remote server (or a group of remote servers), which in turn can cause the web browser or web-enabled client residing on the computing device to display the user interface. The insight reporting GUI 1060, 1061 covers a predetermined time period 1062 (e.g., 14 days) and includes multiple reporting sections on a single reporting GUI, including: GMI metric 1064, a dynamic glucose profile (“AGP”) graph 1070, and a glucose control assessment (GCA) 1072. In some implementations, the Insight Report GUIs 1060, 1061 also include an indicator 1074 for high glucose variability. Mathematical systems and methods can be used to prepare reports utilizing the relationship between median glucose, glucose variability, and the risk of hypoglycemia, and these can be implemented in computer software. Insight Reports 1060, 1061 can be generated based on this relationship. Examining the GMI metric 1064, AGP plot 1070, GCA table 1072, and indicator 1074 can provide good reference in the decision-making process for diabetes treatment. Further details can be found in WO 2014 / 145335 entitled “Systems and methods for managing diabetes based on median glucose, glucose variability, and the risk of hypoglycemia,” which is explicitly incorporated herein by reference in its entirety for all purposes.

[0155] The Insight Report GUIs 1060 and 1061 may include one or more GMI measures 1066 and 1068. In one implementation, the Insight Report GUIs 1060 and 1061 may include a GMI percentage 1066 for a time period 1062, a GMI value 1068 in mmol / mol, and / or both a GMI value 1068 in mmol / mol. When displaying more than one GMI measure, one of the GMI measures may be displayed more prominently than the other. In another implementation, the numerical value of the GMI measure may be displayed more prominently than the unit. For example, the numerical value of the GMI percentage 1064 or the GMI value 1068 may be displayed in a larger font, and / or bold or italic, and / or a different color than the unit.

[0156] AGP chart 1070 displays the 5th (1076th), 25th (1078th), 50th (median) (1080th), 75th (1082nd), and 95th (1084th) percentile glucose readings per hour, presented on a “typical” day based on all days within the selected time range. AGP chart 1070 may also include two horizontal lines: a “median target” line of 154 mg / dL (1085th) and a low glucose line of 70 mg / dL (1087th).

[0157] The first GCA 1072 measurement, “Low Glucose Probability” (“LLG”) 1086, is the probability that a low glucose value has exceeded an allowable, user-defined threshold. The second measurement, “Median Glucose (Compared to Target)” 1088, is an indication of when median glucose exceeds an individual’s median target setting. The third measurement, “Below-Median Variability (Median to X Percentile)” (1090), is a measure of the distribution of glucose data below the median. It is calculated as the difference between the 50th and Xth percentile glucose readings over a time period. The lower percentile (“X”) can be, for example, 5%, optionally 10%, optionally 15%. It is noteworthy that when below-median variability is high, it is difficult to achieve the median target without increasing the likelihood of low glucose (1086). Therefore, factors leading to increased glucose variability must be addressed before increasing the insulin dose, otherwise the risk of low glucose will increase. Insights 1060 and 1061 also outline factors that may contribute to high variability below the median, including “unstable diet,” “incorrect or missed medication,” “alcohol consumption,” “variable activity levels,” or “illness,” which require review and resolution by a healthcare professional during their consultation with the patient. Indicators in the various GCA 1072 categories can be colored, preferably green, yellow, and red, where green indicates “low” levels, yellow indicates “medium” levels, and red indicates “high” levels of variability, such as… Figure 10F As depicted in [the text]. Alternatively, the indicator can be displayed as a circle with various shade levels (no shade (empty), half-shaded, or solid), which can correspond to "low" risk (no shade), "medium" risk (half-filled), and "high" risk (solid circle), as [example image would be inserted here]. Figure 10E As seen in the text.

[0158] Indicators of high glucose variability 1074 include possible factors that can lead to glucose variability below the median. Examples include, but are not limited to, unstable diet, incorrect or missed medication, alcohol consumption, changes in activity levels, and disease.

[0159] Sections of Insight Reports 1060 and 1061, such as AGP 1070 and GCA 1072, can be divided into time slots throughout the day. These time slots can be adjusted based on a patient's specific schedule. Users can set typical times for breakfast, lunch, dinner (apple icon), and bedtime (person in bed icon). These times correspond to clinically relevant daily events for diabetic patients, whose insulin treatment is associated with eating and sleep events. The result is three daytime slots and two nighttime slots, with default time boundaries of 3 AM, 8 AM, 12 PM, 6 PM, and 10 PM.

[0160] Figure 10G This is an example implementation of GMI metric 1092 as part of a glucose profile report GUI 1091, which provides insights into a patient's diabetes management. According to one aspect of the implementation, GUI 1091 can be displayed on a computing device (e.g., a personal computer, desktop computer, laptop computer, reader device, tablet computer, etc.) via a web browser, a web-enabled client, or software residing in non-transitory memory of the computing device. In some implementations where the user interface is displayed via a web browser or a web-enabled client, software instructions can be executed on a remote server (or a group of remote servers), which in turn can cause the web browser or web-enabled client residing on the computing device to display the user interface. According to one aspect of the implementation, GUI 1091 is a glucose profile report covering a predetermined time period 1093 (e.g., 14 days) and includes multiple report sections on a single report GUI, including: a glucose statistics and target section 1094 including GMI metric 1092, a time range section 1095, an active glucose profile (AGP) section 1096, and a daily glucose profile section 1097.

[0161] The Glucose Statistics and Targets section 1094 includes the relevant date range, a time indication (e.g., percentage) of sensor activation within the specified date range, a list of glucose ranges and targets for patients with diabetes (type 1 or type 2). Targets indicate the percentage or amount of reading a patient should achieve for a specific glucose range over a specific time period. Mean glucose levels (in mg / dL or mmol / L) are also reported. The GMI metric 1092 may also be reported as a percentage of GMI, a GMI value in mmol / mol, or both. The percentage of glucose variability may also be reported, defined as the percentage of the variable coefficient.

[0162] The time range section 1095 depicts a time range (also referred to as within a time range and / or within a time target) GUI, each GUI comprising multiple bars or bar segments, wherein each bar or bar segment indicates the amount of time within which the user's analyte level falls within a predefined analyte range associated with the bar or bar segment. In some implementations, for example, the amount of time may be expressed as a percentage of a predefined amount of time. The GUI section 1095 within the time range includes a single bar comprising five sub-bars, which (from top to bottom) indicate: the first sub-bar indicates that the user's glucose range is "very high" or above 250 mg / dL at 1% (14 minutes) of the predefined time amount; the second sub-bar indicates that the user's glucose range is "high" or between 180 and 250 mg / dL at 18% (4 hours and 19 minutes) of the predefined time amount; the third sub-bar indicates that the user's glucose range is within the "target range" or between 70 and 180 mg / dL at 78% (18 hours and 43 minutes) of the predefined time amount; the fourth sub-bar indicates that the user's glucose range is "low" or between 54 and 69 mg / dL at 3% (43 minutes) of the predefined time amount; and the fifth sub-bar indicates that the user's glucose range is "very low" or less than 54 mg / dL at 0% (0 minutes) of the predefined time amount. Figure 10G As seen in some implementations, within a time range, GUI 1095 can display text adjacent to each bar section, which indicates the actual amount of time, for example, in hours and / or minutes.

[0163] according to Figure 10G In one aspect of the illustrated implementation, each bar segment of the GUI 1095 within a time range may include a different color. In some implementations, bar segments may be separated by dashed lines or dashed lines and / or inserted with numerical markers to indicate the range reflected by adjacent bar segments. In some implementations, the time within the range reflected by the bar segments may be further expressed as a percentage, an actual amount of time (e.g., 4 hours and 19 minutes), or as... Figure 10G As shown, both represent [the data]. Furthermore, those skilled in the art will recognize that the percentage of time associated with each bar segment can vary based on the user's analysis data. In some embodiments of the time-range GUI 1095, the target range can be configured by the user. In other embodiments, the target range of the time-range GUI 1095 cannot be modified by the user.

[0164] The glucose profile report GUI 1091 also includes similar information about... Figure 10E and Figure 10FThe AGP plot 1070 describes the AGP section 1096. The AGP plot displays hourly glucose readings at the 5th, 25th, 50th (median), 75th, and 95th percentiles, presented on a “typical” day based on all days within the selected time range. The AGP plot may also include two horizontal lines indicating the boundaries of the target range defined in the Glucose Statistics and Target section 1094 and the Time Range section 1095. For example, the first line may correspond to the lower boundary of the target range (e.g., 70 mg / dL), and the second line may correspond to the upper boundary of the target range (e.g., 250 mg / dL). The first and second lines may also be color-coded and correspond to the same color (e.g., green) as the target range bar section in the Time Range section 1095. Thus, the AGP plot of AGP section 1096 readily shows the amount of time spent within the target range (or the number of reads falling within the target range).

[0165] The glucose profile report GUI 1091 may also include a daily glucose profile section 1297. The daily glucose profile section 1097 displays multiple daily profiles, one for each day of the time period 1093. Each daily profile may represent the midnight to midnight period, with the date displayed in the same box as the profile. In addition to displaying the date, each profile may also indicate the corresponding day of the week. Each profile may also include an indication of the target glucose range (e.g., shaded areas or lines indicating the upper and lower boundaries of the target area) to indicate which portions of each daily profile fall within the target range. Portions in the chart that fall outside the target range may also be color-coded as further indication of readings or analyte levels exceeding the target range. The color coding may correspond to the colors used in the time range section 1095. For example, portions of the chart above the target range of "high" levels (e.g., 181–250 mg / dL) may be coded in yellow. Portions in the chart below the target range of "low" levels (e.g., 54–69 mg / dL) may be coded in red. Color coding can include coloring the area under a curve with a certain color, changing a portion of a chart to a certain color, or highlighting the area with a corresponding color.

[0166] Figures 11A to 11D and Figures 12A to 12B Various GUIs for improving the usability and user privacy of analyte monitoring software are described. Figure 11A This is a GUI 1100 that depicts the first startup interface that can be displayed to the user when the analyte monitoring software is first launched. According to one aspect of the implementation, the GUI 1100 may include a "Start Now" button 1102, which, when pressed, navigates the user to... Figure 11BThe GUI 1110 depicts a country confirmation interface 1112 that prompts the user to confirm their country. According to another aspect of the implementation, the selected country may restrict and / or enable certain interfaces within the analyte monitoring software application for regulatory compliance purposes.

[0167] Next turn Figure 11C GUI 1120 depicts a user account creation interface that allows a user to initiate the process of creating a cloud-based user account. According to one aspect of the implementation, the cloud-based user account can allow the user to share information with healthcare professionals, family, and friends; review more complex analyte reports using a cloud-based reporting platform; and back up the user's historical sensor readings to a cloud-based server. In some implementations, GUI 1120 may also include a "skip" link 1122, which allows the user to utilize the analyte monitoring software application in an "account-free mode" (e.g., without creating or linking to a cloud-based account). When the "skip" link 1122 is selected, an information window 1124 may be displayed to notify the user that certain features are unavailable in "account-free mode." The information window 1124 may further prompt the user to return to GUI 1120 or continue without creating an account.

[0168] Figure 11D This is a GUI 1130 depicting the menu interface displayed within the analyte monitoring software application when the user is in "accountless mode". According to one aspect of the implementation, the GUI 1130 includes a "login" link 1132, which allows the user to exit "accountless mode" and log in from within the analyte monitoring software application by creating a cloud-based user account or using an existing cloud-based user account.

[0169] Next reference Figure 12A The GUI 1240 depicts a research consent interface 1240 that prompts the user to choose to refuse or choose to join (via button 1242) to allow the user's sensor readings and / or other product-related data to be used for research purposes.

[0170] Next reference Figure 12B The GUI 1250 depicts a “Vitamin C” warning interface 1252 that displays a warning to the user that using more than 500mg of vitamin C supplements daily can lead to falsely high sensor readings.

[0171] Example implementations of methods and systems for alarm interfaces

[0172] Various exemplary implementations relating to alarm and alarm suppression methods, alarm interfaces, alarm setting interfaces, compatibility check interfaces, and alarm logging interfaces, as well as other related features, for analyte monitoring systems will now be described. Those skilled in the art will understand that any one or more exemplary implementations of the methods, interfaces, and systems described herein can be implemented independently or in combination with any other implementations described in this application.

[0173] Figure 13A An example implementation of a method 1300 for determining one or more alarm conditions and presenting an alarm associated with the determined one or more alarm conditions is described. In step 1302, a current sensor reading is received. In some implementations, the current sensor reading may include one or more signals from a glucose sensor disposed in a sensor control device 102, wherein at least a portion of the glucose sensor is configured to be positioned under the skin of an object and in contact with bodily fluids. In other implementations, the current sensor reading may be a glucose level measurement received by a reader device 120. In some implementations, the reader device 120 may communicate directly with the sensor control device 102. In other implementations, the reader device 120 may receive the glucose level measurement via another computing device (e.g., a cloud-based server). In step 1304, a determination is made regarding the presence of one or more alarm conditions. According to some implementations, for example, one or more alarm conditions may include at least one of the following: a low glucose condition, an emergency low glucose condition (sometimes also referred to as a “severe low glucose condition” or a “fixed low glucose condition”), a high glucose condition, a rapidly decreasing glucose (rate of change) condition, a rapidly increasing glucose (rate of change) condition, a predicted low glucose condition, or a predicted high glucose condition, and other alarm conditions. In some embodiments, the alarm condition may also include a signal loss condition, wherein no valid current glucose reading is received within a predetermined time period (e.g., one minute, five minutes, ten minutes, twenty minutes, etc.). In some embodiments, the signal loss condition may be a result of a loss of wireless connectivity (e.g., Bluetooth connectivity) between the reader device 120 and the sensor control device 102. Other signal loss conditions and their details are described in the '672 disclosure, which is incorporated herein by reference in its entirety for all purposes. As previously mentioned, the determination steps may be performed by the reader device 120, the sensor control device 102, or any other computing device described with respect to the analyte monitoring system 100.

[0174] Still referencing Figure 13AIn step 1306, if one or more alarm conditions are determined to exist, an alarm associated with the determined alarm condition is presented. In some embodiments, the presentation of the alarm may include a visual notification (e.g., a pop-up window, banner notification, full-screen notification, etc.). In other embodiments, the presentation of the alarm may include a visual notification accompanied by sound and / or vibration indications. In other embodiments, the presentation of the alarm may include sound and / or vibration indications without visual notifications.

[0175] Those skilled in the art will understand that the method steps described herein can be performed by a single device or by multiple devices. For example, in some embodiments, the determination of one or more alarm conditions can be performed by the sensor control device 102, and the presentation of the alarm can be performed by the reader device 120. In other embodiments, both the determination of the alarm condition and the presentation of the alarm can be performed by the reader device 120.

[0176] Figures 13B to 13D This is an example implementation that includes a GUI for alarms used in an analyte monitoring system. For example, Figure 13B This is a GUI 1310 depicting an alarm for an analyte monitoring system, wherein the alarm includes alarm status text 1312 (e.g., "High Glucose Alarm"), an analyte level measurement 1314 associated with the alarm status (e.g., current glucose level is 241 mg / dL), and a trend indicator 1315 associated with the alarm status (e.g., a trend arrow or directional arrow). Additionally, an alarm time indicator 1316 is shown. In some embodiments, the alarm time indicator 1316 may indicate the amount of time elapsed since the alarm status was triggered (e.g., now, 5 minutes ago, 10 minutes ago). In other embodiments, the alarm time indicator 1316 may indicate the specific time the alarm status was triggered (e.g., 6:12 PM). In some embodiments, an alarm icon 1318 may also be adjacent to the alarm status text 1312.

[0177] Figure 13C This is a GUI 1320 that describes another alarm for an analyte monitoring system, wherein the alarm includes a low glucose alarm for a low glucose alarm condition. Figure 13D This is GUI1330, which describes another alarm used in an analyte monitoring system, including a signal loss alarm for signal loss conditions. Additional details about the alarms are described in the '672 published text, which is incorporated herein by reference in its entirety for all purposes.

[0178] Example implementation of emergency low glucose alarm

[0179] An example implementation of an emergency low glucose alarm will now be described. In a general sense, an emergency low glucose alarm for an analyte monitoring system is similar to previous implementations regarding... Figures 13B to 13D The described alarms share certain similarities. According to one aspect of the implementation, an emergency low-glucose alarm will be presented to the user when their glucose level has dropped below an emergency low-glucose threshold (e.g., below 55 mg / dL). According to another aspect of the implementation, due to the critical nature of the user's condition, the emergency low-glucose alarm will override other settings of the reader device 120, including the reader device's operating system, such as "Mute" or "Do Not Disturb" settings. Furthermore, in many implementations, the glucose threshold level, which is typically adjustable for other alarms, cannot be changed for the emergency low-glucose alarm.

[0180] Figures 13E to 13G This is an example implementation including a GUI for an emergency low glucose alarm in an analyte monitoring system. As described above, the implementation of these alarms is similar to... Figures 13B to 13D The illustrated implementations have some similarities. For example, Figure 13E This is a GUI 1340 depicting an emergency low glucose alarm for an analyte monitoring system, wherein the alarm includes emergency low glucose alarm status text 1312, an analyte level measurement 1344 associated with the alarm status (e.g., 55 mg / dL), and a trend indicator 1345 associated with the alarm status (e.g., a trend arrow or directional arrow). Additionally, an alarm time indicator 1346 and an alarm icon 1348 are also shown. Figure 13F This is another GUI 1350 depicting an emergency low glucose alert. (Example) Figure 13F As seen in the GUI1350, a key alarm icon 1352 and an out-of-range ("Low (LO)") text indicator 1354 are displayed, indicating that the glucose level has dropped below the minimum threshold within the measurable range. Figure 13G This is another GUI 1360 depicting an emergency low glucose alarm, similar to the previously described implementation, but with... Figure 13E and Figure 13F The implementations shown are presented in different mobile operating systems (e.g., Android) to represent iOS.

[0181] According to one aspect of these embodiments, the alarms described herein may include alarms with configurable settings (e.g., low glucose alarm, high glucose alarm, signal loss alarm) and alarms with non-configurable settings (e.g., emergency low glucose alarm) operating on a single computing device within the same analyte monitoring system. In some embodiments, for example, the analyte monitoring system may include a reader device including wireless communication circuitry configured to receive data indicating analyte levels from a sensor control device, and one or more processors coupled to a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to: (1) determine whether the data indicating analyte levels satisfies one or more alarm conditions, wherein the one or more alarm conditions include a first alarm condition associated with a first set of alarm settings configurable by the object and a second alarm condition associated with a second set of alarm settings not configurable by the object, and wherein the second alarm condition is an emergency low glucose alarm condition; and (2) in response to the determination that at least one of the one or more alarm conditions is satisfied, present an alarm associated with at least one of the one or more alarm conditions.

[0182] Figures 14A to 14E This is an example implementation of a GUI that includes alarm settings for alarms in an analyte monitoring system. Figure 14A The GUI 1400 depicts the alarm settings interface, which includes three selectable alarm options: low glucose alarm option 1402, high glucose alarm option 1404, and signal loss alarm option 1406. Each selectable alarm option has a text indicator next to it to indicate whether the alarm is on or off. Additionally, in some implementations, a selectable "Learn More" option for additional information is provided below the selectable alarms. Figure 14B This is a GUI 1410 depicting the low glucose alarm settings interface. According to one aspect of the embodiment, GUI 1410 can be displayed when the user selects a low glucose alarm in the previous GUI 1400. According to another aspect of the embodiment, GUI 1410 includes a text label for "Low Glucose Alarm" adjacent to a switch 1406 configured to toggle between an on and off position. Those skilled in the art will understand that, instead of a toggle, GUI 1410 may include any one or more of a switch checkbox, a switch slider switch, a switch radio button, a switch button, etc. Figure 14B As can be seen, when switch 1406 is in the off position, no other settings for the low glucose alarm are available and / or visible.

[0183] Figure 14CThis is GUI 1420, depicting the low glucose alarm setting interface after switch 1406 has been switched to the ON position. After switch 1406 is switched to the ON position, as... Figure 14C As can be seen, GUI 1420 may include multiple configurable settings, including (but not limited to) a low glucose alarm threshold setting 1422, a low glucose alarm tone setting 1424, and a low glucose alarm coverage setting 1426. According to one aspect of the implementation, the low glucose alarm threshold setting 1422 can be configured by the user, allowing the user to select a low glucose threshold (e.g., ...). Figure 14D As shown in GUI 1430, a low glucose alarm is triggered when the user's glucose level drops below a selected low glucose threshold. According to another aspect of the embodiment, the low glucose alarm tone setting 1424 can be configured by the user, allowing the user to select a standard alarm (e.g., using the operating system's alarm tone) or a custom low glucose alarm (e.g., allowing the user to select a specific tone or output), such as... Figure 14E As shown in GUI 1440. According to some embodiments, the low glucose alarm tone can be one or both of an auditory notification and a vibration notification. According to another embodiment, the low glucose alarm overlay setting 1426 can be configured by the user such that when enabled, the low glucose alarm will always output an audible (or vibrating) sound and display a visual notification on the display of the reader device 120 (e.g., on a lock screen), even if the reader device 120 is muted or configured in "Do Not Disturb" mode.

[0184] although Figures 14B to 14E A GUI with configurable alarm settings for low glucose alarms is described, but those skilled in the art will recognize that similar GUIs can be used for configurable alarm settings for high glucose alarms or signal loss alarms, and are fully within the scope of this disclosure.

[0185] Figures 14F to 14I This is an additional example implementation that includes a GUI for alarm settings in an analyte monitoring system. Figure 14F This refers to the GUI 1450, which depicts the alarm settings interface and includes four selectable alarm options: Emergency Low Glucose Alarm Option 1452 (also known as "Emergency Low Glucose Alarm" or "Fixed Low Glucose Alarm"), Low Glucose Alarm Option, High Glucose Alarm Option, and Signal Loss Alarm Option. In one respect, GUI 1450 is similar to... Figure 14A The GUI 1400, in addition to the GUI 1450, also includes an emergency low glucose alarm 1452. Figure 14GThis is a GUI 1460 depicting the emergency low glucose alarm settings interface. According to one aspect of the embodiment, GUI 1460 can be displayed when the user selects the emergency low glucose alarm in the previous GUI 1450. According to another aspect of the embodiment, GUI 1460 includes an information section 1460 indicating that the emergency low glucose alarm is "on and cannot be modified." Furthermore, with... Figure 14C Similar to GUI 1420, GUI 1460 further includes: a text label for “Emergency Low Glucose Alarm” adjacent to switch 1464, an emergency low glucose alarm threshold setting 1466, an emergency low glucose alarm tone setting 1468, and an emergency low glucose alarm overlay setting 1470.

[0186] In many implementations, the aforementioned settings are not configurable for the user and are displayed only for informational purposes. For example, with switch 1406 in GUIs 1410 and 1420 ( Figure 14B and Figure 14C Unlike other implementations, switch 1464 cannot be switched to the "off" position or state. Similarly, according to another aspect of some implementations, the emergency low glucose alarm threshold setting 1466, the emergency low glucose alarm tone setting 1468, and the emergency low glucose alarm coverage setting 1470 cannot be modified or disabled.

[0187] In other embodiments, one or more of the foregoing settings may be configurable by the user, while the remaining settings are displayed only for informational purposes. For example, in some embodiments, the text label and switch 1464, the alarm threshold setting 1466, and the alarm coverage setting 1470 may be non-configurable, while the alarm tone setting 1468 may be configurable to allow the user to select a specific tone or vibration. Other combinations of configurable and non-configurable settings are possible, and those skilled in the art will recognize that such combinations are entirely within the scope of this disclosure.

[0188] According to another aspect of some implementations, certain settings may become "active" under certain conditions. Figure 14H It is a GUI 1480 that depicts the emergency low glucose alarm settings interface, similar to... Figure 14GThe GUI 1460. As seen in the bottom third of the interface, the emergency low glucose alarm overlay setting 1482 is displayed as "Off". Additionally, a key alarm icon or badge is displayed next to the "Off" status, indicating that corrective action is required. In some implementations, further guidance 1484 may be displayed on the interface (e.g., "Please update your notification settings so that you can receive the alarm even when your phone is in Do Not Disturb mode"). According to one aspect of some implementations, the GUI 1480 presents an active "Open Settings" link 1486 near the bottom of the interface. When link 1486 is selected, the GUI 1490 is displayed (…). Figure 14I In many embodiments, GUI 1490 is provided through a notification settings interface provided by the operating system of reader device 120, rather than from an analyte monitoring software application running on reader device 120. According to another aspect of the embodiments, GUI 1490 includes a "Do Not Disturb Overlay" setting 1492, which can be enabled by the user. According to one aspect of some embodiments, once the overlay setting 1492 is enabled, the "Open Settings" link 1486 of GUI 1480 can be switched to a hidden or inactive state.

[0189] Although the foregoing figures and descriptions relate to alarms and alarm interfaces of a reader device, those skilled in the art will understand that such alarms and alarm interfaces can also be implemented within a sensor control device, a local computing system, a trusted computing system, or an analyte monitoring system, or in any other computing device communicating with an analyte monitoring system. Furthermore, as previously described, any GUIs and features described herein may include instructions stored in the memory of the reader device, sensor control device, or any other computing device that is part of or communicates with an analyte monitoring system.

[0190] Example implementation of alarm suppression feature

[0191] Example implementations of methods and systems for alarm suppression features in analyte monitoring systems will now be described. Typically, if an analyte monitoring system lacks the ability to modulate alarms, adverse effects ranging from mild stimulation to desensitization can occur. Specifically, these effects can lead to dangerous consequences, such as users ignoring or disregarding critical alarms from the analyte monitoring system. Therefore, there is a need for robust methods and systems for alarm suppression features in analyte monitoring systems.

[0192] As previously described, those skilled in the art will recognize that the method steps described herein may include instructions (e.g., software, firmware, etc.) stored in the non-transitory memory of the sensor control device 102, the reader device 120, or any other computing device or system that is part of or communicates with the analyte monitoring system 100. Furthermore, the method steps described herein may be performed by a single centralized device or multiple devices.

[0193] Figure 15A This is a flowchart illustrating an example embodiment of a method 1500 for suppressing alarms during an alarm post-presentation period in an analyte monitoring system. According to one aspect of the embodiment, the alarm post-presentation period comprises a predetermined amount of time after an alarm has been presented, during which the same alarm will not be repeated in response to the same alarm condition. In many embodiments, the alarm post-presentation period may be the same for all alarms. In other embodiments, an alarm post-presentation period may be configured for each alarm. Furthermore, method 1500 assumes that the user does not deactivate or otherwise take any action in response to the alarm.

[0194] In step 1502, a first alarm is presented, wherein the first alarm is associated with a first alarm condition. In some embodiments, method 1300 may be used to determine the first alarm condition, as per [the relevant information]. Figure 13A As described, and the presentation of the first alert may include information about Figures 13B to 13G Any interface described herein. In step 1504, sensor readings are received. In some embodiments, sensor readings may include the current glucose value. In other embodiments, sensor readings may include historical glucose values. Subsequently, in step 1506, it is determined whether an alarm condition exists related to the received sensor reading (or, in the case of a signal loss alarm condition, a lack of alarm condition). If no alarm condition exists, it is determined in step 1516 whether the alarm post-presentation period has elapsed. According to some embodiments, the alarm post-presentation period may be a predetermined amount of time (e.g., 1, 2, 5, 10, 15 minutes, etc.). In other embodiments, the alarm post-presentation period may be based on an incrementing count value. In step 1516, if the alarm post-presentation period has not yet elapsed, no further action is taken on the first alarm, and method 1500 returns to step 1504 and receives the next sensor reading. However, if the alarm post-presentation period has elapsed, the presentation of the first alarm is cleared in step 1518. In some embodiments, the first alarm is cleared when the visual notification is removed from the display. In other implementations, the first alarm is cleared when the audible sound or vibration stops, or when the repetition of the audible sound or vibration stops.

[0195] Returning to step 1506, if an alarm condition is determined to exist, then in step 1508, it is determined whether the current alarm condition is the same as the first alarm condition. If it is determined that the current alarm condition is different from the first alarm condition, then in step 1510, the first alarm is cleared and a second alarm associated with the current (e.g., the second) alarm condition is presented.

[0196] For illustrative purposes, and not intended to limit the implementation, if the first alarm presented in step 1502 is a low glucose alarm associated with a low glucose condition, and subsequently it is determined in steps 1504, 1506, and 1508 that the alarm condition is a high glucose condition, then in step 1510, the low glucose alarm is cleared and a high glucose alarm is presented.

[0197] Returning to step 1508, if it is determined that the current alarm condition is the same as the first alarm condition, then in step 1512, it is subsequently determined whether the current alarm condition is part of the same event (episode) as the first alarm condition. If it is determined that the current alarm condition is not part of the same event as the first alarm condition, then in step 1514, the alarm is updated. According to some implementations, the step of updating the alarm may include presenting a new notification interface (e.g., a new analyte level measurement 1314, such as...). Figure 13B (As shown). In some implementations, the new notification interface can completely replace the previous notification interface. In other implementations, the new notification interface can be stacked on top of the previous notification interface.

[0198] For illustrative purposes, and not intended to limit the implementation, if the first alarm presented in step 1502 is a high glucose alarm associated with a high glucose condition (e.g., 241 mg / dL), and it is subsequently determined in steps 1504, 1506, and 1508 that the current alarm condition is also a high glucose condition (e.g., 255 mg / dL), but it is determined in step 1512 that the high glucose condition is part of an event different from the first high glucose condition, then the high glucose alarm is updated in step 1514 (e.g., a new notification interface indicating an analyte measurement of 255 mg / dL replaces the previous notification interface).

[0199] Returning to step 1512, if it is determined that the current alarm condition is part of the same event as the first alarm condition, then in step 1516, it is determined whether the alarm post-presentation period has passed. If the alarm post-presentation period has passed, then the alarm is updated in step 1518. If the alarm post-presentation period has not yet passed, no action is taken on the first alarm, and method 1500 returns to step 1504 to receive the next sensor reading.

[0200] Referring to step 1512 of method 1500, according to one aspect of the implementation, in order to determine whether the current (e.g., second) alarm condition is part of the same event as a previous (e.g., first) alarm condition, certain criteria may be evaluated. For example, in some implementations, it can be determined that the hyperglycemic event has ended under the following conditions:

[0201] (1) Sensor readings <HG 阈值 –HG 容限

[0202] In formula (1) above, the sensor reading can be the current glucose value or a historical glucose value, HG 阈值 It is a high glucose threshold, HG 容限 It is a high glucose threshold tolerance. Furthermore, in some implementations, HG... 容限 It can be equal to F_HIGH*HG 阈值 +C_HIGH, where F_HIGH is a positive fraction with one decimal place and C_HIGH is a scalar factor.

[0203] As another example, in some implementations, it can be determined that the hypoglycemic event has ended under the following conditions:

[0204] (2) Sensor readings <LG 阈值 +LG 容限

[0205] In formula (2) above, LG 阈值 It is a low glucose threshold, LG 容限 It is a low glucose threshold tolerance.

[0206] As another example, in some implementations, it can be determined that an emergency hypoglycemic event has ended under the following conditions:

[0207] (3) Sensor reading > ULG 阈值 +ULG 容限

[0208] In formula (3) above, ULG 阈值 It is the emergency low glucose threshold, ULG 容限 It is the emergency low glucose threshold tolerance.

[0209] Those skilled in the art will understand that other methods for identifying analyte events may be used in addition to or in place of the formulas described above. Further descriptions of such methods are described, for example, in U.S. Patent No. 9,622,689, U.S. Public Patent Application No. 2018 / 0226150, and Application No. 2018 / 0217917, all of which are incorporated herein by reference in their entirety for all purposes.

[0210] Furthermore, those skilled in the art will understand that any of the above steps or combinations of steps are optional for method 1500. For example, according to some embodiments, steps 1512 and 1514, which involve determining whether the current alarm condition is part of the same event as the first alarm condition, may be optional, and thus step 1508 will proceed to step 1516.

[0211] Figure 15B This is a flowchart illustrating an example embodiment of a method 1550 for suppressing alarms during an active all-clear period in an analyte monitoring system. According to one aspect of the embodiment, when a user clears an alarm, the visual and / or audible presentation of the alarm ceases, and an all-clear period is activated during which repetition of the same alarm is not triggered. The active all-clear period comprises a predetermined amount of time after the user clears the alarm. In many embodiments, the active all-clear period may be the same for all alarms. In other embodiments, the active all-clear period may be configured to be customized for one or more alarms. Those skilled in the art will also recognize that any combination, subset, or all of the steps of method 1550 can be implemented in conjunction with any combination, subset, or all of the steps of method 1500 described above.

[0212] In step 1552, a first alarm is presented, wherein the first alarm is associated with a first alarm condition. In some embodiments, method 1300 may be used to determine the first alarm condition, as per [the relevant information]. Figure 13A As described, and the presentation of the first alert may include information about Figures 13B to 13G Any interface described. In step 1554, the user clears the presented alarm to begin the active clearing period. According to some implementations, the active clearing period can be a predetermined amount of time (e.g., 5, 10, 15, 20, 30 minutes, etc.). In other implementations, the active clearing period can be based on an incrementing counter value or a countdown timer.

[0213] In step 1556, sensor readings are received. In some embodiments, the sensor readings may include the current glucose value. In other embodiments, the sensor readings may include historical glucose values. Subsequently, in step 1558, it is determined whether an alarm condition is associated with the received sensor reading (or, in the case of a signal loss alarm condition, a missing alarm condition). If no alarm condition exists, method 1550 returns to step 1556 to receive the next sensor reading. If an alarm condition exists, in step 1560, it is determined whether the current (e.g., second) alarm condition is the same as a previous (e.g., first) alarm condition. If the current (e.g., second) alarm condition (e.g., high glucose condition) is different from the previous (e.g., first) alarm condition (e.g., low glucose condition), in step 1562, the first alarm (e.g., low glucose alarm) is cleared, and a second alarm (e.g., high glucose alarm) associated with the second alarm condition (e.g., high glucose condition) is presented. In some embodiments, the alarm is cleared when a visual notification is removed from the display. In other embodiments, the alarm is cleared when an audible sound or vibration stops, or when the repetition of an audible sound or vibration stops.

[0214] Returning to step 1560, if it is determined that the current (e.g., second) condition is the same as the previous (e.g., first) condition, then in step 1564, a determination is made as to whether the proactive clearing period has passed or been cancelled. If the proactive clearing period has passed or been cancelled, then in step 1566, a second alarm associated with the alarm condition is presented. If the proactive clearing period has neither passed nor been cancelled, no further action is taken (e.g., the second alarm is not presented), and method 1550 returns to step 1556 to receive the next sensor reading. In one aspect, this proactive clearing period thus prevents a second alarm from being prematurely triggered after the first alarm based on the same alarm condition, after the user has cleared the first alarm.

[0215] According to one aspect of the implementation, the active clearance period has elapsed when a predetermined amount of time has passed since the user cleared the first alarm. For example, the active clearance period can range from 5 minutes to 1440 minutes. Those skilled in the art will recognize that other time measurements (e.g., timers, counters, etc.) can also be implemented for the active clearance period, and these values ​​are within the scope of this disclosure.

[0216] According to another aspect of the implementation, the active release period can also be cancelled by one or more predefined events and / or conditions (before a predetermined amount of time has elapsed): alarm threshold setting change, alarm disabling, glucose event end, sensor termination (e.g., sensor control device entering end-of-life state), sensor termination, new sensor startup, and / or device reset. Those skilled in the art will recognize that other events and / or conditions can be used to cancel the active release period, and these events and / or conditions are within the scope of this disclosure.

[0217] Furthermore, certain types of alarms can be configured with specific active clearing periods. For example, according to some implementations, a signal loss alarm can be configured such that the active clearing period is not activated until a predetermined number of consecutive signal loss alarms have occurred. A signal loss alarm can also be automatically cleared after a predetermined number of consecutive signal loss alarms have occurred. For illustration, as... Figure 15C As shown, a signal loss alarm can be configured to automatically activate an active cancellation period when six consecutive occurrences occur within a 30-minute timeframe, without user intervention. While the above example is provided for a signal loss alarm, those skilled in the art will recognize that these implementations can also be applied to other types of alarms.

[0218] Example implementation of alarm settings interface

[0219] An example implementation of a method and system for setting up an alarm GUI in an analytical material monitoring system will now be described. (As previously discussed...) Figure 14H and Figure 14I As described, some alarms may require users to configure specific operating system features that may interfere with the alarm. For example, some operating systems used in mobile computing devices include features such as "Do Not Disturb" or "Mute," which may interfere with the sound, visual, or vibration alarm presentation of the aforementioned alarms. While these operating system features can be disabled on a system-wide basis or customized for each application, the actual process of correctly configuring these features can be difficult and / or error-prone for users. Therefore, it would be beneficial to include an easy-to-use alarm settings GUI for users to mitigate the risk of these operating system features interfering with alarms.

[0220] Figures 16A to 16E An example implementation of an alarm settings interface in an analyte monitoring system is depicted. Figure 16AThis is a GUI 1605 that depicts the alarm settings interface, providing the user with instructions 1607 to configure certain system settings and permissions of the reader device 120 to enable alarms. In some embodiments, the GUI 1605 further includes a button or link 1608 that, when pressed by the user, causes the reader device 120 to display a notification permission interface 1612, such as... Figure 16B As shown. According to some embodiments, the notification permission interface 1612 may include an "Allow" button or link 1614 to allow the analyte monitoring software application to send a notification to the reader device 120.

[0221] Next reference Figure 16C GUI 1615 depicts another alarm settings interface that provides the user with instructions 1616 to configure certain system settings, thereby allowing critical alarms to be received, even when the reader device 120 is in "Do Not Disturb" mode. In some embodiments, GUI 1615 further includes a button or link 1617 that, when pressed by the user, causes the reader device 120 to display a critical alarm permission interface 1622, such as... Figure 16D As shown. According to some implementations, the critical alarm permission interface 1622 may include an "Allow" button or link 1624 to allow the analyte monitoring software application to send critical alarms to the reader device 120.

[0222] According to one aspect of some implementations, if the user has not enabled any one or both of the following: (1) notification permission ( Figure 16B (1) and (2) critical alert permission ( Figure 16D If so, then display to the user Figure 16E Another interface shown. Specifically, Figure 16E This refers to a GUI 1625 depicting another alarm settings interface, which provides the user with instructions 1627 on how to manually configure notification permissions and critical alarm settings for the analyte monitoring software application. According to some embodiments, if it is determined that the user has not enabled one or more required alarm permission settings, the analyte monitoring software application can remain inoperable or partially operational until the required alarm permission settings are enabled. In this respect, further operation of the analyte monitoring software application is prevented by other means when a predetermined set of alarm permission settings is not enabled. Similarly, in some embodiments, if it is determined that the user has later disabled one or more required alarm permission settings, the interface can prompt the user to manually correct the alarm permission settings, further preventing the user from further operation of the analyte monitoring software application. In this respect, the analyte monitoring software application can mitigate the risk that the user will not receive critical alarms and other alerts for adverse conditions.

[0223] Figures 17A to 17IAn additional example implementation of the alarm setting interface in an analyte monitoring system is depicted. Typically, Figures 17A to 17I and Figures 16A to 16E The alarm settings interfaces depicted in the images share many similarities. However, Figures 17A to 17I The interface shown is designed for different operating systems and includes different alarm permission settings. For example, Figure 17B and Figure 17C GUI 1710 and 1715 point to enabling location licensing. Figure 17D GUI 1720 refers to the interface used to enable system settings to ignore battery optimization settings (e.g., so that alarms are not disabled during low power conditions). GUIs 1725, 1730, 1735, and 1740 (e.g., Figures 17E to 17H This refers to the interface that allows analyte monitoring software applications to override the "Do Not Disturb" feature in the operating system.

[0224] According to one aspect of some implementations, if the user has not enabled one or more of the aforementioned alarm permission settings, a message is displayed to the user. Figure 17I Another interface shown. Similar to the one about Figure 16E The described implementation method, Figure 17I This is a GUI 1745 depicting another alarm settings interface, which provides the user with instructions 1747 on how to manually configure system settings for the analyte monitoring software application. According to some embodiments, if it is determined that the user has not enabled one or more required alarm permission settings, further operation of the analyte monitoring software application is prevented. Furthermore, in some embodiments, if it is determined that the user has disabled one or more required alarm permission settings, the interface can prompt the user to manually correct the alarm permission settings, further preventing the user from further operation of the analyte monitoring software application. In this respect, the analyte monitoring software application can mitigate the risk that the user will not receive critical alarms and other alerts for adverse conditions.

[0225] Example implementation of alarm unavailable features and interface

[0226] This section will now describe an example implementation of a method, system, and associated GUI for detecting the unavailability of alarms in an analyte monitoring system. As previously mentioned, certain operating system features (e.g., power optimization features, "Do Not Disturb" features, etc.) can interfere with alarms in an analyte monitoring system. Furthermore, users may unknowingly perform actions on their analyte monitoring system, which may also interfere with alarms. Therefore, a robust method and system are needed for detecting the unavailability of alarms in an analyte monitoring system.

[0227] Figure 18AAn example implementation of a method for determining the presence of alarm unavailability in an analyte monitoring system is described. In step 1802, one or more alarms are enabled in the analyte monitoring system. In many implementations, the one or more alarms may include a low glucose alarm, an emergency low glucose alarm, a high glucose alarm, and / or a signal loss alarm, among other examples, which may be enabled on one or more of the reader device 120, the sensor control device 102, or any other computing device that is part of or communicates with the analyte monitoring system.

[0228] In step 1804, it is determined whether one or more alarm unavailability conditions exist. According to one aspect of the implementation, alarm unavailability conditions may include any one or more of the following: wireless communication circuitry (e.g., Bluetooth or Bluetooth Low Energy) is disabled and / or not functioning; system-wide notifications are disabled; application-specific notifications are disabled; mute or silent mode is enabled; the analyte monitoring software application has been forcibly closed by the user or system (i.e., no longer running in the background or foreground); critical alarms are disabled; the "Do Not Disturb" feature is disabled; the "Do Not Disturb" channel is closed; alarm sounds are set to mute; location permission is disabled; and / or battery optimization is enabled. In some implementations, other alarm unavailability conditions may further include: no active sensor detected or sensor malfunction (e.g., temperature too high, temperature too low, sensor not communicating with reader device 120). Those skilled in the art will recognize that these foregoing alarm unavailability conditions are merely illustrative and do not represent an exhaustive list of all alarm unavailability conditions. Other conditions relating to the analyte sensor, sensor control device 102, or reader device 120 that may cause interference: (1) the determination of an alarm condition, or (2) the presentation of an alarm in the analyte monitoring system is possible and is well within the scope of this disclosure.

[0229] Refer again Figure 18A If no alarm unavailability condition is detected, method 1800 returns to step 1802 and continues to monitor for alarm unavailability conditions (as long as at least one alarm is enabled). However, if one or more alarm unavailability conditions are detected, in step 1806, one or more notifications associated with the detected alarm unavailability conditions are presented to the user.

[0230] According to one aspect of the implementation, one or more notifications associated with the detected unavailability of one or more alarms may include banner notifications or pop-ups displayed to the user outside the analyte monitoring software application (e.g., on the lock screen), such as GUI 1810. Figure 18B ) and GUI 1815 ( Figure 18C As seen in ().

[0231] According to another aspect of the implementation, one or more notifications associated with the detected unavailability of one or more alarms may include a modal window, as seen in GUIs 1815 to 1865. Figures 18D to 18N In some implementations, the modal can provide information about the specific reason why the alarm is unavailable, as well as a confirmation ("OK") button, such as... Figure 18D (Location permission not enabled) Figure 18F (Inactive sensor) and Figure 18G (Bluetooth disabled) As seen. In some implementations, the mode may provide multiple possible reasons for the alarm's unavailability, along with a confirmation ("OK") button, such as Figure 18E As seen. In other implementations, the mode may provide multiple possible reasons for the alarm's unavailability and a "Settings" button that opens the corresponding settings interface to allow the user to correct the situation, such as... Figure 18J and Figure 18K As seen in other embodiments, the pattern may present a specific alarm that is unavailable, the reason for the alarm's unavailability, and a "Settings" button that opens the corresponding settings interface to allow the user to correct the situation. These examples are merely illustrative, and those skilled in the art will recognize that other combinations and arrangements of patterns can be implemented, and are entirely within the scope of this disclosure.

[0232] According to another aspect of the implementation, one or more notifications associated with the detected unavailability of one or more alarms may include in-app notifications within the analyte monitoring software application, as seen in GUI 1875 and GUI 1880. Figure 18O and Figure 18P In some implementations, notifications associated with an alarm unavailability condition may be presented as an in-app banner notification 1877 located on the same interface as the analyte trend chart 1879. Although not shown, in some implementations, the in-app banner notification 1877 may persist through different interfaces within the analyte monitoring software application (e.g., reports, logs, etc.). In this respect, the in-app banner notification 1877 allows the user to continue viewing recent and historical analyte data and reports. According to some implementations, the banner notification may also be configured as an active link such that when the user presses it, an alarm troubleshooting interface 1885 is displayed. In some implementations, the alarm troubleshooting interface 1885 may further include one or more active links 1887 to specific system settings that can be changed. Figure 18QIn some embodiments, the alarm troubleshooting interface 1885 may also include an information prompt 1888 to resolve one or more alarm unavailability conditions. Furthermore, in some embodiments, the alarm troubleshooting interface 1885 may also include a correct settings section 1889 to indicate correctly configured settings. In this regard, in-app notifications may be configured to prompt the user to take corrective action regarding alarm unavailability.

[0233] Example implementation of alarm logging features

[0234] This document will now describe example implementations of methods, systems, and associated GUIs for logging alarms in an analyte monitoring system. Many of the alarms described herein typically provide timely and important information to users of analyte monitoring systems. However, these alarms are generally intended to convey current or recent information. It is also beneficial for users of analyte monitoring systems to be able to review alarm events and their corresponding conditions.

[0235] Figure 19 An example implementation of a method 1900 for determining one or more alarm conditions and recording alarms associated with the determined one or more alarm conditions is described. In step 1902, a current sensor reading is received. In some implementations, the current sensor reading may include one or more signals from a glucose sensor disposed in a sensor control device 102, wherein at least a portion of the glucose sensor is configured to be positioned under the skin of an object and in contact with bodily fluids. In other implementations, the current sensor reading may be a glucose level measurement received by a reader device 120. In some implementations, the reader device 120 may communicate directly with the sensor control device 102. In other implementations, the reader device 120 may receive the glucose level measurement via another computing device (e.g., a cloud-based server).

[0236] In step 1904, a determination is made regarding the presence or absence of one or more alarm conditions. According to some embodiments, one or more alarm conditions may include, for example, at least one of the following: a low glucose condition, an emergency low glucose condition (sometimes also referred to as an "emergency low glucose condition" or a "fixed low glucose condition"), a high glucose condition, a rapidly decreasing glucose (rate of change) condition, a rapidly increasing glucose (rate of change) condition, a predicted low glucose condition, or a predicted high glucose condition, and other alarm conditions. In some embodiments, alarm conditions may also include a signal loss condition, wherein no valid current sensor reading is received within a predetermined time period (e.g., one minute, five minutes, ten minutes, twenty minutes, etc.). In some embodiments, a signal loss condition may be a result of a loss of wireless connection (e.g., Bluetooth connection) between the reader device 120 and the sensor control device 102. Other signal loss conditions and their details are described in the '672 disclosure text, which is incorporated herein by reference in its entirety for all purposes. As previously stated, the determination step may be performed by the reader device 120, the sensor control device 102, or any other computing device described with respect to the analyte monitoring system 100.

[0237] Still referencing Figure 19 In step 1906, if one or more alarm conditions are determined to exist, an alarm entry is created in the log. In some implementations, the creation of the log entry may occur before the alarm is presented (e.g., a pop-up window, banner notification, full-screen notification, sound indicator, vibration indicator, etc.). In other implementations, the creation of the log entry may occur after the alarm is presented. In other implementations, the creation of the log entry may occur when or after the user de-emerges from the alarm presentation.

[0238] According to one aspect of the implementation, the log may be a discrete file on any one or more of the sensor control device 102, the reader device 120, or any other computing device that is part of or communicates with the analyte monitoring system 100. In some implementations, for example, the log may be part of an analyte monitoring software application residing in the memory of the reader device 120.

[0239] Those skilled in the art will also understand that the method steps described herein can be performed by a single device or by multiple devices. For example, in some embodiments, the determination of one or more alarm conditions can be performed by the sensor control device 102, and the presentation of the alarm can be performed by the reader device 120. In other embodiments, both the determination of the alarm condition and the presentation of the alarm can be performed by the reader device 120.

[0240] Figures 20A to 20CAn example implementation of an alarm logging interface for an analyte monitoring system is depicted. Figure 20A This is a GUI 2010 depicting the log interface of an analyte monitoring software application installed on a reader device 120. According to one aspect of the implementation, the log interface may include multiple log entries for a selected time period (e.g., "August 1, 2019"), wherein the multiple log entries may include user-inputted notes (e.g., exercise, food, medication), and log entries 2012 for alarm generation. Further details regarding the log interface are described in U.S. Public Patent Application No. 2019 / 0183393, which is incorporated herein by reference in its entirety for all purposes.

[0241] According to one aspect of some implementations, users cannot modify the log entries generated by the alert. Instead, in these implementations, other log entries (e.g., user-entered comments) can be added, edited, or deleted.

[0242] According to another aspect of some implementations, the log entry 2012 generated by the alarm can be configured such that when the user presses a key, a detailed log interface 2020 is displayed, such as... Figure 20B As shown. In some embodiments, the log detail interface 2020 may include an analyte trend chart 2022 and an icon 2024 to indicate the time of the alarm event. According to some embodiments, the icon 2024 may also be graphically associated with a banner 2025 that provides further information about the analyte level or sensor reading at the time of the alarm. Furthermore, additional alarm information 2026, including, for example, the alarm type and specific time, may be displayed on the same log detail interface 2020. In some embodiments, other information, such as user-entered notes 2027 about food or exercise, may be displayed on the same log detail interface 2020 to provide the user with further context about the environment during the alarm event.

[0243] Figure 20C This is another example implementation of the log detail interface 2030. Similar to the previous implementations, the log detail interface 2030 also includes an icon 2032 indicating the time of the alarm event. However, the log detail interface 2030 includes a pop-up mode 2034 that provides further alarm information, such as the type of alarm (“low glucose alarm”) and the specific time of the alarm (“1:38 PM”). In some implementations, the pop-up mode 2034 may also include other log entries, such as one or more user-entered food and / or medication (“rapid-acting insulin”) entries, to provide the user with further context about the environment during the alarm event.

[0244] about Figure 20B and Figure 20CIn some implementations, the log details interface can also be configured to allow users to add and / or edit comments or other user-inputted log entries. However, in many implementations, the log entries generated by the alerts and the associated alert information cannot be modified to maintain data integrity.

[0245] Example implementation of compatibility checks for analyte monitoring software applications

[0246] Example implementations of methods, systems, and associated GUIs for registration and compatibility checks in analyte monitoring software applications will now be described. According to some implementations, the various alarms and alarm features described in the preceding sections can be associated with an analyte monitoring software application residing in the memory of the reader device 120 (or other computing device used in conjunction with the analyte monitoring system). Therefore, in such implementations, it is advantageous to include certain registration and compatibility check features during the setup of the analyte monitoring software application to ensure that alarms and other features function as intended.

[0247] Figures 21A to 21F An example implementation of the registration and compatibility check interface used during the setup of an analyte monitoring software application is depicted. Figure 21A The GUI 2110 prompts the user to check the audio connection to ensure that the alarm can be correctly output to the appropriate device. In some embodiments, the GUI 2110 may also include an icon, link, or button (not shown) configured to play an audible sound when pressed for testing purposes.

[0248] Figure 21B It is a GUI 2120 that depicts a compatibility interface that displays information about the features and updates of the operating system, which can affect the user's ability to receive alerts. Figure 21C The GUI 2130 depicts a compatibility interface, which includes information and icons, links, or buttons 2132 for displaying a compatibility guide. According to one aspect of the implementation, the compatibility guide may list all devices, operating systems, operating system types, and operating system versions identified as compatible or incompatible with the analyte monitoring software application. In some implementations, the compatibility guide may also provide the user with information or instructions on what to do if the analyte monitoring software application is determined to be incompatible with the reader device and / or operating system.

[0249] According to one aspect of the implementation, GUI 2130 also includes a next button 2134 configured to perform a compatibility check. In some implementations, the compatibility check includes comparing the type and version of the reader device's operating system with a list, table, or database of compatible operating system types and versions stored on the reader device. In some implementations, for example, the list, table, or database may be encrypted data storage residing on the reader device, accessible only by the analyte monitoring software application. In other implementations, the compatibility check may include retrieving an updated list, table, or database of compatible operating system types and versions from a remote computing system (e.g., a cloud-based server). If the remote computing system is inaccessible, the analyte monitoring software application may use a list, table, or database stored locally on the reader device. In other implementations, the compatibility check may include sending the type and version of the reader device's operating system to the remote computing system. The remote computing system then sends a response back to the reader device.

[0250] According to one aspect of some implementation methods, compatibility checks can produce two or more results, such as Figures 21D to 21F As shown. In many implementations, for example, if it is determined that the operating system has been tested and is compatible with the analyte monitoring software application, GUI 2140 is displayed, and the analyte monitoring software application functions with a predetermined feature set enabled.

[0251] In some implementations, if it is determined that the operating system type or version has not been tested for compatibility with the analyte monitoring software application, the GUI 2150 displays a warning that certain features may not function correctly. Furthermore, in some implementations where the operating system type or version has not been tested, certain features of the analyte monitoring software application may be disabled. In other implementations, if the operating system type or version has not been tested, the analyte monitoring software application may still run with a predetermined set of features enabled.

[0252] According to many implementations, if it is determined that the operating system type or version is incompatible with the analyte monitoring software application, GUI 2160 is displayed, and a limited set of features is enabled for the analyte monitoring software application. For example, in some implementations where the operating system type or version is incompatible with the analyte monitoring software application, alarms may be disabled. In other implementations, both alarms and sensor readings may be disabled, but the user can still view historical data or reports (if available). In other implementations, the entire analyte monitoring software application may be disabled.

[0253] Although the above compatibility checks describe the operating system type and version of the reader device, those skilled in the art will recognize that other aspects of hardware and software can be analyzed as part of the compatibility checks, including but not limited to the reader device model, reader device hardware components (e.g., minimum requirements for processor, memory, and storage), other software applications installed on the same reader device, sensor control device type, sensor control device version, sensor control device model, sensor control device firmware version, sensor control device hardware components, region and / or geographic information, etc. This list is illustrative only, and those skilled in the art will understand that other factors regarding the compatibility of various software and / or hardware components of the computing device in the analyte monitoring system are entirely within the scope of this disclosure.

[0254] Figures 21G to 21J An example implementation of an additional interface related to compatibility checks for analyte monitoring software applications is described. Figure 21G and Figure 21H These are GUIs 2165 and 2170, respectively. Each GUI displays a notification indicating incompatibility between the reader device's operating system and the analyte monitoring software application. According to some implementations, the notification may be displayed in response to a determination of incompatibility during the registration or setup process of the analyte monitoring software application, as mentioned above. Figures 21A to 21F As described. In other embodiments, the notification may be displayed as part of a compatibility check event that occurs after the registration or setup process of the analyte monitoring software application, for example, as part of a compatibility check performed each time an update to the reader device's operating system is detected or each time a predetermined event occurs (e.g., user login, new sensor startup, reinstallation of the analyte monitoring software application, etc.). In other embodiments, the notification may be displayed as part of a compatibility check manually initiated by the user of the analyte monitoring software application. Similarly, Figure 21I and Figure 21JThese are GUIs 2175 and 2180, respectively, each displaying a notification that a recent reader (e.g., a telephone) or operating system update may affect a user's ability to receive alerts. According to some implementations, the notification may be displayed in response to an alert availability check performed during the registration or setup process of the analyte monitoring software application. In other implementations, the notification may be displayed as part of an alert availability check event that occurs each time an update to the reader device's operating system is detected, or each time a predetermined event occurs (e.g., user login, new sensor activation, reinstallation of the analyte monitoring software application, etc.). In other implementations, the notification may be displayed as part of an alert availability check manually initiated by the user of the analyte monitoring software application. In some implementations, the alert availability check may include routines for checking the operating system's notification permissions, critical alert settings of the operating system, the forced shutdown status of the analyte monitoring software application, or any other related settings, configurations, and / or the aforementioned alert availability-related conditions.

[0255] Those skilled in the art will understand that any GUI (or portions thereof) described herein is intended to be illustrative only, and that any single element or combination of elements depicted and / or described for a particular embodiment or figure may be freely combined with any other element or combination of any other element depicted and / or described for any other embodiment.

[0256] Example implementation of the interface for caregiver applications and alerts

[0257] Example implementations of methods and interfaces related to caregiver applications and alerts will now be described. First, those skilled in the art will understand that the GUI and related methods described herein include instructions stored in the memory of reader device 120, local computer system 170, trusted computer system 180, and / or any other device or system that is part of or communicates with analyte monitoring system 100. When these instructions are executed by one or more processors of reader device 120, local computer system 170, trusted computer system 180, or other devices or systems of analyte monitoring system 100, the one or more processors perform method steps and / or output the GUI described herein. Those skilled in the art will further recognize that the GUI described herein may be stored as instructions in the memory of a single centralized device, or alternatively, may be distributed across multiple discrete devices in geographically dispersed locations.

[0258] Figure 22This is a conceptual diagram depicting an example embodiment of an analyte monitoring system 2200 capable of transmitting analyte data and other information to a caregiver. According to one aspect of the embodiment, the analyte monitoring system 2200 is generally similar to the analyte monitoring system 100, as referenced... Figure 1 As described. Specifically, the analyte monitoring system 2200 may include a sensor control device 102 (worn by the patient 2201-A) that wirelessly communicates with the reader device 120-1 via a communication link 140. According to many embodiments, the sensor control device 102 may include communication circuitry configured to wirelessly transmit data with the reader device 120-1 via Bluetooth or a near-field communication protocol. According to some embodiments, the reader device 120-1 may be a smartphone, a receiver device, or a blood glucose meter. Furthermore, the reader device 120-1 may wirelessly communicate with a trusted computer system 180 via a network 190. In some embodiments, the reader device 120-1 may include communication circuitry configured to wirelessly transmit data with the trusted computer system 180 via an 802.11x communication protocol or a cellular communication protocol.

[0259] Still referencing Figure 22 The analyte monitoring system 2200 also includes a second reader device 120-2 belonging to the caregiver 2201-B. The second reader device 120-2 may include communication circuitry configured to wirelessly transmit data to a trusted computer system 180 via a network 190 through an 802.11x communication protocol or a cellular communication protocol. According to many embodiments, the network 190 may be the Internet.

[0260] According to another aspect of the embodiment, sensor control device 102 includes an analyte sensor, at least a portion of which is configured to be positioned within the body of patient 2201-A. Sensor control device 102 can wirelessly transmit data indicating the analyte level of patient 2201-A to reader device 120-1, which in turn can wirelessly transmit the data to trusted computer system 180. According to another aspect of the embodiment, second reader device 120-2 includes analyte monitoring software configured to be operated by caregiver 2201-B. Furthermore, second reader device 120-2 (which may be a smartphone) is configured to receive data indicating the analyte level of patient 2201-A, which is wirelessly transmitted from trusted computer system 180 to reader device 120-2 via network 190.

[0261] In this way, caregiver 2201-B can receive timely information about the analyte levels of patient 2201-A. In some implementations, for example, analyte monitoring software installed on the caregiver's reader device 120-2 can be configured to receive alarms associated with the analyte levels of patient 2201-A.

[0262] Figure 23A This is a flowchart describing an example implementation of a method 2300 for providing caregiver alerts related to an analyte monitoring system. In step 2302, a sensor control unit worn by the patient transmits the current sensor readings to the patient's reader device. According to many embodiments, the patient's reader device may be a smartphone, including communication circuitry configured to wirelessly transmit data to the sensor control unit according to Bluetooth, Bluetooth Low Energy, or Near Field Communication protocols. Those skilled in the art will recognize that other standard wireless communication protocols can be used and are fully within the scope of this disclosure. In step 2304, the patient's reader device then sends the current sensor readings to a cloud-based server. According to many embodiments, the communication circuitry of the patient's reader device may be further configured to wirelessly communicate data with the cloud-based server according to the 802.11x protocol, cellular communication protocols, or any other standard wireless communication protocol.

[0263] Still referencing Figure 23A In step 2306, the cloud-based server determines whether the received current sensor reading meets a caregiver alarm condition. According to one aspect of method 2300, the caregiver alarm condition can be configured by the caregiver and can operate independently of the patient's own alarm condition. In some implementations, for example, the caregiver alarm condition can be one of the following: a high glucose level condition, a low glucose level condition, or a signal loss condition. In other implementations, the caregiver alarm condition may also include a rate of change condition, a predicted glucose level condition, or a failure to clear an alarm on the patient's device. In step 2308, if the received current sensor reading meets a caregiver alarm condition, the cloud-based server then sends an alarm indicator associated with the caregiver alarm condition to the caregiver's reader device. In step 2310, in response to receiving the alarm indicator, the caregiver's reader device presents an alarm.

[0264] Figure 23BThis is a flowchart illustrating another example embodiment of method 2320 for providing caregiver alerts related to an analyte monitoring system. In step 2322, a sensor control unit worn by the patient transmits the current sensor readings to the patient's reader device. According to many embodiments, the patient's reader device may be a smartphone, including communication circuitry configured to wirelessly transmit data to the sensor control unit according to Bluetooth, Bluetooth Low Energy, or Near Field Communication protocols. Those skilled in the art will recognize that other standard wireless communication protocols can be used and are fully within the scope of this disclosure. In step 2324, the patient's reader device determines whether the received current sensor readings meet an alarm condition. In some embodiments, the alarm condition may, for example, be one of the following: a high glucose condition, a low glucose condition, a signal loss condition, a rate of change condition, or a predicted glucose level condition, etc.

[0265] Still referencing Figure 23B In step 2326, if the alarm condition is met, the patient's reader device presents an alarm to the patient and further sends an alarm indicator associated with the determined alarm condition to the cloud-based server. In step 2328, the cloud-based server then sends the received alarm indicator associated with the determined alarm condition to the caregiver's reader device. In step 2330, the caregiver's reader device presents an alarm based on the received alarm indicator associated with the determined alarm condition.

[0266] According to one aspect of method 2320, the analyte monitoring system is configured such that alerts configured by the patient are presented only to the caregiver. In other words, according to an implementation of method 2320, the alert indicators received by the caregiver are merely "via" a cloud-based server, without any independent evaluation performed by the cloud-based server or the caregiver's reader device.

[0267] Figures 24A to 24H Various GUIs and alarm interfaces of analyte monitoring software applications configured to operate on a caregiver's reader device are described. Figure 24A It is a GUI that depicts a home interface with multiple connections, each connection being depicted as an overview card. Figure 24B It is a GUI that depicts the graphs of specific connections. Figure 24C It is a GUI that describes the alarm configuration interface for toggling on / off low glucose alarms, high glucose alarms, and alarms with no recent data. Figure 24D This is a GUI that depicts another alarm configuration interface for high glucose alarms, where the interface indicates the current value of the high glucose alarm threshold. Figure 24E This is a GUI that describes another alarm configuration interface for high glucose alarms, which includes user-configurable settings for high glucose alarm thresholds. Figure 24FIt is a GUI that describes the alarm configuration interface for an alarm with no recent data, where the interface indicates the current value of the notification period after which the alarm with no recent data will be triggered. Figure 24G It is another GUI that depicts the alarm configuration interface for a no recent data alarm, where the interface includes user-configurable settings for a notification period after which a no recent data alarm is triggered. Figure 24H An alarm interface for high glucose alerts is described.

[0268] Example implementation for displaying non-medical data from a sensor control device

[0269] Example implementations of methods, apparatus, and systems (including graphical user interfaces) for displaying non-medical data from sensor control devices will now be described. Figure 25 This is a flowchart illustrating process 2500 of an electronic interface for displaying non-medical data from sensor control device 102 (e.g., a reader device as described herein). To initiate display 2502, at least one processor of the computing device may receive sensor data 2504 collected by sensor control device 102, such as data indicating glucose levels. The sensor control device may use any suitable wireless or wired connection to provide sensor data at periodic intervals, such as once per second, every 15, 30, or 45 seconds, once per minute, or every 2, 3, 4, or 5 minutes. Alternatively, or additionally, the sensor control device may provide sensor data in response to detected events, such as the user's heart rate, respiratory rate, or in response to a user input request for data indication to the reader device. If the sensor control device and the reader device are not manufactured for the same non-medical application, the reader device will be unable to receive data from the sensor control device, and process 2500 will terminate, optionally providing an error message (not shown) to the user.

[0270] At 2506, at least one processor can determine whether each measurement of the sensor data received at box 2504 is greater than or equal to a predetermined upper threshold, which must not satisfy at least one condition to be displayed as non-medical information. For example, a measurement of sensor data 2504 exceeding the predetermined upper threshold 2506 may indicate a medical pathology or condition, making it inappropriate to transmit the value for non-medical purposes. If so, the processor can provide an upper out-of-range indicator 2508 to the user interface for display without indicating the sensor data value.

[0271] If, after determining at 2506 that the sensor data does not exceed the upper threshold, at 2510, at least one processor can determine whether the sensor value is less than or equal to a predetermined lower threshold, which must not satisfy at least one condition for display as non-medical information. For example, a measurement of sensor data 2504 less than the predetermined lower threshold 2510 could indicate a medical pathology or condition, making it inappropriate to transmit the value for non-medical purposes. If so, the processor can provide a lower out-of-range indicator 2512 to the user interface for display without indicating the sensor data value. If not, at 2514, the processor can provide the measurement value to the user interface for display.

[0272] At 2516, after sensor data or an out-of-range indicator has been provided for display on the user interface, the processor waits for the next measurement value, which may be provided periodically or in response to events as described above. The processor may continue process 2500 until terminated by the user, or in response to the expiration of a time period or the occurrence of any other suitable termination event. Thus, using process 2500, the processor can provide a signal to display a sensor value indicator on the reader device only when the measured value falls within a range that satisfies at least one condition displayed as non-medical information.

[0273] Figure 26 This shows that process 2500 or method 2700 can be used. Figure 27 A screenshot of an example display window 2600 provided by an interactive graphical user interface. Display window 2600 may include a graph 2606 indicating analyte measurements provided by sensor data over time 2608 and a graphical object 2612 providing display text for current or recent measurements. Furthermore, graph 2606 may include an indicator 2604 for a target average value 2604 of the measured analyte (e.g., glucose) value and a range 2602 indicating limits for non-medical values ​​within which only measurements are allowed to be displayed. For example, in the embodiment shown for monitoring glucose levels used in exercise, graph 2606 includes a range 2602 between an upper threshold measurement of 200 mg / dL and a lower threshold measurement of 55 mg / dL. Thresholds are merely illustrative, and other values ​​may also be used to define limits for non-medical information, depending on the analyte and intended application.

[0274] For measurements within glucose level range 2602, the processor of the reader device can cause graph 2606 to indicate recent and past measurements as segments or points on line 2614. Conversely, for measurements outside the range, the processor can cause graph 2606 to indicate the out-of-range condition, for example, by displaying a dashed line 2610 indicating that the data exceeds the glucose threshold limit. Furthermore, if the user's glucose level is outside the range, the processor can cause graphical object 2612 to display an out-of-range message, such as glucose level "above 200 mg / dL" or "below 55 mg / dL".

[0275] In summary, and with additional examples, Figure 27 Operation of a method 2700 for performing an electronic interface for displaying non-medical data from a sensor control device 102 is illustrated. At 2710, the method for the electronic interface includes receiving sensor data collected by the sensor control device 102 by at least one processor. In one embodiment of the invention, the electronic interface receives analytes affecting performance, such as blood glucose and / or lactate, before or during sports training and competition, so that the user can track and understand glucose levels to maintain optimal performance. At 2720, the method further includes determining, by at least one processor, whether each measurement of the sensor data meets at least one condition for display as non-medical information. For example, for applications providing glucose monitoring for sports purposes, a range of non-medical glucose levels, such as 55 mg / dL and 200 mg / dL, can be defined between specified levels.

[0276] In 2730, method 2700 may include providing an interactive graphical user interface to a display device, the interactive graphical user interface being configured to display sensor data based on determination, wherein the display device indicates only one or more measurements of the sensor data that satisfy at least one condition. For example, as Figure 26 As shown, for applications measuring blood glucose in athletes, a non-medical glucose level range between 55 mg / dL and 200 mg / dL can be defined. If a user's analyte measurement falls within this range, it satisfies at least one condition for display as non-medical information. Conversely, if a user's analyte measurement exceeds the limits of the glucose range, it can be considered an indication of a medical pathology or condition. Therefore, at least one processor can determine that data exceeding the range fails to meet the defined condition for non-medical information and prevent the graphical user interface from displaying data exceeding the range.

[0277] The processor and memory storing the instructions for performing the operations of method 2700 may be, or may include, components for performing the operations shown in blocks 2710, 2720, and 2730. These components may include more detailed algorithms for performing the operations. For example, a more detailed algorithm for performing operation 2710 may include initiating a wireless session with a sensor control device using a wireless protocol (e.g., Bluetooth Low Energy (BLE)), receiving wireless signals from the sensor control device, generating digital data in a transmitting layer based on the wireless signals, and providing the digital data to an application layer. As a further example, a more detailed algorithm for performing operation 2720 may include combining... Figure 4A and Figure 4B Operations 406 and 410 are described. A more detailed algorithm for performing operation 2730 may include combining... Figure 25 Operations 2508, 2512, and 2514 are described, wherein these operations are in the state of upstream branch operations 2506 and 2510, and wherein the processor formats data to generate a display by the target display device.

[0278] Figure 28 Optional operations or aspects 2800 may be included in method 2700 by at least one processor of the reader device. These operations or aspects 2800 may be included in method 2700 in any order of operation. Including or omitting any upstream operation of operation or aspect 2800 does not necessarily require the inclusion or omission of any downstream operation.

[0279] In one aspect, at 2810, the determining operation 2720 of method 2700 may further include applying at least one condition, including a measured value not exceeding a predetermined upper threshold. For example, when the electronic interface is collecting glucose analyte data for exercise, the predetermined upper threshold may be 200 g / dL. Similarly, at 2820, the determining operation 2720 of method 2700 may further include applying at least one condition, including a measured value not less than a predetermined lower threshold. For example, where glucose levels are measured for exercise purposes and non-medical purposes, the predetermined lower threshold 2510 value for glucose may be 55 mg / dL. At 2830, the determining operation 2720 of method 2700 may further include providing an out-of-range indicator to the interface, which indicates that one or more measured values ​​of the sensor data do not meet at least one condition. In one aspect, the out-of-range indicator indicates that one of the measured values ​​is out of range, rather than indicating the value out of range, for example, as... Figure 26 As shown by the dashed line 2610.

[0280] On the other hand, at 2840, the providing operation 2730 of method 2700 may further include providing an indicator of a value range to the interface, the value range satisfying at least one condition for display as non-medical information. For example, if the user's glucose level is between a predetermined upper and lower threshold range of 55 mg / dL and 200 mg / dL, at least one condition for displaying as non-medical information may be satisfied, and the processor may accordingly cause the display range indicator 2602, as shown. Figure 26 As shown. Furthermore, at 2850, providing operation 2730 may further include providing an indicator of the target average value of the sensor data to the interface, for example, as... Figure 26 As shown in 2604. Optionally, the target average value can be set by the user based on the activity. For example, the processor can provide a menu of target value options for different activities and set the target value based on the activity selected by the user. In a related aspect, at 2860, providing operation 2730 may further include providing the interface with a graph of the sensor data over time, for example, as... Figure 26 As shown in 2606 and 2614.

[0281] On the other hand, in 2870, method 2700 may further include at least one processor determining text for display in an interactive graphical user interface based at least in part on whether at least one condition for display as non-medical information is satisfied. For example, the processor may restrict the user interface output to display glucose levels falling within a predetermined upper and lower threshold range, such as... Figure 26 As shown in 2612. For example, when a user's glucose level exceeds an upper threshold, the graphical object 2612 displays the message "Glucose level above 200 mg / dL". Similarly, for measurements falling below a lower threshold, the processor can cause object 2612 to display "Below 55 mg / dL".

[0282] In one aspect as described above, at 2880, sensor data from the sensor control device used in method 2700 can indicate the glucose level of a person wearing the sensor control device. However, the method is not limited to glucose as an analyte and can similarly control the use and display of any useful analyte for non-medical purposes, such as blood oxygen levels and / or lactate. In another aspect, the sensor control device and the reader device can be configured such that only devices configured for compatible non-medical applications can access the data from the sensor control device. Thus, for example, a medical sensor control device cannot provide data to a non-medical reader device, and a non-medical sensor control device cannot provide data to a medical reader device.

[0283] In some implementations, non-medical data from the sensor control device can be output to the display of a wearable device, such as a fitness tracker or smartwatch. In some implementations, the non-medical data can be displayed simultaneously on both the wearable device and the reader device. In other implementations, the user can select the device to display non-medical data.

[0284] Figures 29A to 29F Various example implementations of user interfaces for displaying non-medical data on wearable devices are described. Figure 29A A system 2900 for displaying non-medical data from a sensor control device is depicted, wherein the system 2900 includes a reader device 120 and a wearable device 2905. According to one aspect of the embodiment, the reader device 120 may include software stored in a memory, which may be related to… Figure 26 This is part of the same software described. In some embodiments, the software may be configured to display a user interface 2901, which may include a sensor information section 2902 and a pairing button 2903. The sensor information section 2902 may include information about a sensor control device (not shown), including but not limited to an image of the sensor control device, model name, model number, serial number, connection status, and remaining days of use (e.g., the amount of time until the sensor expires). The pairing button 2903 may be configured to initiate a pairing sequence.

[0285] Figure 29BA system 2900 for displaying non-medical data from a sensor control device on a wearable device is described, wherein a pairing sequence has been initiated on a reader device 120. According to some embodiments, multiple selectable pairing codes 2906-1, 2906-2, and 2906-3 are output to the display of the reader device 120. Additionally, a single pairing code 2906-1 is output to the display of the wearable device 2905. Thus, a user can select the correct pairing code 2906-1 on the reader device 120 that matches the pairing code displayed on the wearable device 2905. Once the correct pairing code 2906-1 is selected, the reader device 120 can pair with the wearable device 2905. Subsequently, according to some embodiments, the reader device 120 can send sensor context information to the wearable device 2905, enabling the wearable device 2905 to then communicate directly with a sensor control device (not shown). According to another aspect of some embodiments, the existing communication link between the reader device 120 and the sensor control device (not shown) is disabled before a communication link is established between the wearable device 2905 and the sensor control device. Further details regarding the establishment of multiple communication links between the multiple devices and the sensor control device are described in International Publication No. WO 2021 / 087013A1, which is incorporated herein by reference in its entirety for all purposes.

[0286] Figures 29C to 29F The interface on the wearable device 2905 is depicted once a communication link has been established between the wearable device 2905 and the sensor control device (not shown). For example, Figure 29CThe wearable device 2905 depicts a real-time glucose level reading 2907 received from a sensor control device and a trend indicator 2908 (e.g., an arrow indicating whether the glucose level is rising, falling, or remaining constant). According to some embodiments, the wearable device 2905 may also be configured to display a graph (not shown). According to one aspect of the embodiment, the graph may include a first axis indicating a unit of time and a second axis indicating analyte concentration (e.g., glucose concentration). According to another aspect of the embodiment, the graph may reflect analyte level measurements over time, displayed as a plotted line, discrete data points, or both. In some embodiments, a graph may be displayed instead of the real-time glucose level reading 2907 and the trend indicator 2908. In other embodiments, the graph may be displayed on the same screen as one or both of the real-time glucose level reading 2905 and / or the trend indicator 2908. Furthermore, in some embodiments, one or more status indicators 2909 may also be displayed on the wearable device 2905. Status indicator 2909 may include lights, for example, to indicate active connection / pairing with a sensor control device, active connection / pairing with an application (e.g., on reader device 120), ongoing events, battery indicators, or sensor remaining life indicators. Although Figure 29C One or more indicators 2909 are depicted as multiple lights, but those skilled in the art will recognize that other types of indicators (e.g., textual, numerical (as percentages or fractions), graphical) may also be used, and are fully within the scope of this disclosure.

[0287] Figure 29D An event interface on wearable device 2905 is depicted. According to some embodiments, a user can indicate that an event is occurring by selecting an event start button 2910 on the event interface. An event can be one or more of exercise, sleep, or meals, to name a few. For example, a user can choose to start an event during exercise or competition to track their glucose levels. During the event, the user can mark their glucose data via a flag interface, such as... Figure 29E As shown. According to one aspect of the implementation, a flag will mark the user's glucose data at a specific time point during an event of interest. Figure 29F This is the alarm interface on the wearable device 2905. According to some embodiments, an alarm can notify the user when the glucose level exceeds a predetermined threshold (e.g., a low glucose threshold, a high glucose threshold, etc.). In some embodiments, the predetermined threshold may also be a rate of change threshold or a signal loss threshold. The alarm may be a visual indicator, such as displaying numbers or text in red, a flashing light, flashing text, or an activated backlight. According to some embodiments, the alarm may also be an audible or vibration indicator. The alarm can be deactivated (e.g., via deactivation button 2915) or marked (e.g., via mark button 2916) for later viewing.

[0288] While many of the embodiments described herein relate to glucose monitoring, those skilled in the art will understand that these same embodiments can be used to monitor other analytes, such as lactate and ketones. This is only by way of illustration; for example, regarding process 2500 (… Figure 25 ), display window 2600 ( Figure 26 ) and / or methods 2700 and 2800 ( Figure 27 and Figure 28 Those skilled in the art will understand that any or all of the foregoing embodiments can be implemented for monitoring analytes other than glucose, such as lactic acid or ketones. Similarly, implementations of alarms, for example regarding... Figure 29F Those described can be based on lactate threshold (e.g., low lactate threshold, high lactate threshold) or ketone threshold.

[0289] Furthermore, those skilled in the art will understand that the embodiments described herein are not limited to monitoring only one analyte at a time, although each of the embodiments described herein is capable of doing so. For example, according to some embodiments, a single sensor control device may include, for example, analyte sensors capable of sensing levels of glucose and lactate in a user's bodily fluids within its housing. Similarly, any and all of the foregoing processes, display windows, methods, and / or alarms can be configured for the purpose of monitoring multiple analytes simultaneously (e.g., glucose and lactate, glucose and ketones, etc.).

[0290] In summary, improved digital interfaces, graphical user interfaces, and alarms for analyte monitoring systems are provided. For example, various implementations of methods, systems, and interfaces for determining signal loss conditions, time-range interfaces, GMI measurements, emergency low glucose alarms, alarm suppression features, alarm setting interfaces, and alarm unavailability detection features are disclosed. Furthermore, various implementations of interfaces for alarm logging and compatibility checking for analyte monitoring software applications are described. In addition, various implementations of interface enhancements are described, including enhanced visibility modes, voice accessibility modes, additional interfaces related to user privacy, caregiver alarms, and other implementations.

[0291] It should be noted that all features, elements, components, functions, and steps described with respect to any embodiment provided herein are intended for free combination and substitution with any other embodiment. If a feature, element, component, function, or step is described with respect to only one embodiment, it should be understood that, unless expressly stated otherwise, that feature, element, component, function, or step may be used with every other embodiment described herein. Therefore, this paragraph may at any time serve as a premise and written support for the introduction of the claims, which combine features, elements, components, functions, and steps from different embodiments, or substitute features, elements, components, functions, and steps from another embodiment for those features, elements, components, functions, and steps from that embodiment, even if not expressly indicated in the following description; such combinations or substitutions are possible in certain circumstances. It is expressly acknowledged that a detailed description of every possible combination and substitution is very cumbersome, especially considering that the permissibility of each such combination and substitution will be readily recognized by those skilled in the art.

[0292] While the embodiments are readily adaptable to various modifications and alternatives, specific examples have been shown in the accompanying drawings and described in detail herein. However, it should be understood that these embodiments are not limited to the specific forms disclosed; rather, they will cover all modifications, equivalents, and alternatives falling within the spirit of this disclosure. Furthermore, any features, functions, steps, or elements of the embodiments may be stated in or added to the claims, and the scope of the invention may be negatively limited by features, functions, steps, or elements not within the scope of the claims.

Claims

1. An analyte monitoring system, comprising: A sensor control device includes an analyte sensor, wherein at least a portion of the analyte sensor is configured to contact a bodily fluid of a subject; and The reader device includes: A wireless communication circuit is configured to receive current sensor readings from the sensor control device; and One or more processors are coupled to a memory that stores instructions that, when executed by the one or more processors, cause the one or more processors to: Determine the time elapsed since the current sensor reading was received. Determine whether the elapsed time exceeds the signal loss indicator threshold. In response to the determination that the elapsed time exceeds the signal loss indicator threshold, a signal loss indicator is generated. Determine whether the current sensor reading is invalid, and In response to the determination that the current sensor reading is invalid: Generate invalid sensor reading indicators. Determine the time elapsed since the last valid current sensor reading was received. Determine whether the elapsed time since the last valid current sensor reading exceeds the most recent valid sensor reading alarm threshold, and In response to determining that the elapsed time since the last valid current sensor reading exceeds the most recent valid sensor reading alarm threshold, a no most recent valid reading alarm is generated.

2. The analyte monitoring system of claim 1, wherein, The signal loss indicator threshold is five minutes.

3. The analyte monitoring system according to claim 1, wherein, The reader device is a smartphone.

4. The analyte monitoring system according to claim 1, wherein, When the instruction is executed by the one or more processors, the one or more processors further cause the one or more processors to output a signal loss message to the display of the reader device.

5. The analyte monitoring system according to claim 1, wherein, The invalid sensor reading indicator is either a sensor error indicator or a temperature error indicator.

6. The analyte monitoring system according to claim 5, wherein, The temperature error indicator is based on the temperature measurement value obtained by the sensor control device.

7. The analyte monitoring system according to claim 5, wherein, The sensor error indicator is based on early signal attenuation detected by the sensor control device.

8. The analyte monitoring system according to claim 1, wherein, When the instruction is executed by the one or more processors, in response to the determination that the current sensor reading is not invalid, the one or more processors further cause the one or more processors to display the current sensor reading as valid.

9. An analyte monitoring system, comprising: A sensor control device includes an analyte sensor, wherein at least a portion of the analyte sensor is configured to contact a bodily fluid of a subject; and The reader device includes: A wireless communication circuit is configured to receive current sensor readings from the sensor control device; and One or more processors are coupled to a memory that stores instructions that, when executed by the one or more processors, cause the one or more processors to: Determine the time elapsed since the current sensor reading was received. Determine whether the elapsed time exceeds the signal loss indicator threshold. In response to the determination that the elapsed time exceeds the signal loss indicator threshold, a signal loss indicator is generated. In response to the determination that the elapsed time has not exceeded the signal loss indicator threshold, Determine whether the current sensor reading is invalid, and In response to the determination that the current sensor reading is invalid, an invalid sensor reading indicator is generated. Determine the time elapsed since the last valid current sensor reading was received. Determine whether the elapsed time since the last valid current sensor reading exceeds the most recent valid sensor reading alarm threshold, and In response to determining that the elapsed time since the last valid current sensor reading exceeds the most recent valid sensor reading alarm threshold, a no most recent valid reading alarm is generated.

10. The analyte monitoring system according to claim 9, wherein, The invalid sensor reading indicator is either a sensor error indicator or a temperature error indicator.

11. The analyte monitoring system according to claim 10, wherein, The temperature error indicator is based on the temperature measurement value obtained by the sensor control device.

12. The analyte monitoring system according to claim 10, wherein, The sensor error indicator is based on early signal attenuation detected by the sensor control device.

13. The analyte monitoring system according to claim 9, wherein, When the instruction is executed by the one or more processors, in response to the determination that the current sensor reading is not invalid, the one or more processors further cause the one or more processors to display the current sensor reading as valid.

14. A non-volatile computer-readable medium storing instructions that, when executed by one or more processors of a reader device, cause the one or more processors to: The current sensor reading is received from a sensor control device, including an analyte sensor, via a wireless communication circuit, wherein... At least a portion of the analyte sensor is configured to contact the bodily fluid of the object; Determine the time elapsed since the current sensor reading was received. Determine whether the elapsed time exceeds the signal loss indicator threshold. In response to the determination that the elapsed time exceeds the signal loss indicator threshold, a signal loss indicator is generated. Determine whether the current sensor reading is invalid, and In response to the determination that the current sensor reading is invalid: Generate invalid sensor reading indicators. Determine the time elapsed since the last valid current sensor reading was received. Determine whether the elapsed time since the last valid current sensor reading exceeds the most recent valid sensor reading alarm threshold, and In response to determining that the elapsed time since the last valid current sensor reading exceeds the most recent valid sensor reading alarm threshold, a no most recent valid reading alarm is generated.

Images