Analyte monitoring systems and methods

Abstract

An improved graphical user and digital interface for analyte monitoring systems is provided. For example, various implementations of the GUI are disclosed herein, including time ranges, analyte level / trend alarms, and sensor user interfaces. Furthermore, various implementations of the digital interface are described, including methods for data backfilling, transmission of expired or faulty sensors, merging data from multiple devices in the analyte monitoring system, transitioning previously activated analyte sensors to new reader devices, and autonomous sensor system alarms, among others.

Description

Technical Field

[0001] The topics described in this article generally relate to improvements in analyte monitoring systems, as well as related computer-based methods and apparatus. Background Technology

[0002] Detecting and / or monitoring analyte levels, such as glucose, ketones, lactate, oxygen, and hemoglobin AIC, is crucial for the health of individuals with diabetes. Patients with diabetes may experience complications including loss of consciousness, cardiovascular disease, retinopathy, neuropathy, and kidney disease. Patients 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, an in vivo analyte monitoring system can be utilized, in which a sensor control device can be worn on the body of the individual requiring analyte monitoring. For increased personal comfort and convenience, the sensor control device can have a small form factor and can be applied by the individual using a sensor applicator. The application process involves using an applicator or insertion mechanism to insert at least a portion of a sensor that senses the user's analyte level into bodily fluids located within the body layer, such that the sensor is in contact with the bodily fluids. The sensor control device can also be configured to transmit analyte data to another device from which the individual, or her healthcare provider (“HCP”) or caregiver, can view the data and make treatment decisions.

[0005] However, despite their advantages, some people are reluctant to use analyte monitoring systems for a variety of 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] Therefore, there is a need for improved digital interfaces, graphical user interfaces and software for analyte monitoring systems, as well as related methods and apparatus that are robust, user-friendly, and provide timely and operational responses. Summary of the Invention

[0007] This document provides exemplary embodiments of improved in vivo analyte monitoring systems, along with associated computer-related methods and apparatus. According to some embodiments, a time range (“TIR”) GUI for the analyte monitoring system is provided, wherein the TIR GUI comprises multiple bars or bar segments, each bar or bar segment indicating the amount of time a user's analyte level is within a predetermined analyte range associated with the bar or bar segment. In some embodiments, for example, the amount of time may be expressed as a percentage of total time.

[0008] According to another embodiment, an analyte level / trend alarm GUI for an analyte monitoring system is provided, wherein the analyte level / trend alarm GUI includes visual notifications (e.g., alarms, alerts, pop-ups, banner notifications, etc.), wherein the visual notifications include alarm conditions, analyte level measurements associated with the alarm conditions, and trend indicators associated with the alarm conditions. In some embodiments, for example, the trend indicator includes a directional trend arrow.

[0009] According to some implementations, a sensor user interface is provided for measuring and facilitating user interaction with the analyte monitoring system. The sensor user interface may include one or more viewing metrics, wherein viewing metrics include instances where the sensor results interface is presented or brought into foreground processing. In some implementations, the sensor user interface may be part of an analyte monitoring system report, such as a monthly summary report, a weekly summary report, or a daily log report.

[0010] According to other embodiments, a method for data backfilling in an analyte monitoring system is provided. In some embodiments, the method for data backfilling can be implemented in an analyte monitoring system including a first device and a second device communicating with each other. According to one aspect of the method, the second device can request historical analyte data from the first device based on a lifetime count metric, wherein the lifetime count metric includes a numerical value indicating a quantity of time elapsed since the first device was activated. In another embodiment, a method for data backfilling is provided, wherein a reader device can determine the last successful transmission of data to a trusted computer system and, in response to a reconnection event, transmit historical data that the trusted computer system has not yet received.

[0011] According to another embodiment, a method is provided for collecting disconnection and reconnection events of wireless communication links in an analyte monitoring system, wherein the disconnection and reconnection events are recorded and sent to a trusted computer system for analysis.

[0012] According to other embodiments, a method for improving the transmission of expired or faulty sensor conditions is provided. In some embodiments, an expired or faulty sensor condition is detected by a sensor control device. Subsequently, an indication of the expired or faulty sensor condition is transmitted by the sensor control device until a first predetermined time period has recently occurred, or until an indication of the expired or faulty sensor condition is received, whichever occurs first. In some embodiments, the sensor control device also allows data backfilling during a second predetermined time period.

[0013] According to another embodiment, a method for merging analyte data from multiple devices is provided. In some embodiments, a method is provided in which analyte data from multiple reader devices is received, combined, and deduplicated. A first type of reporting metric can then be generated based on the combined and deduplicated analyte data. According to another aspect of the embodiment, the analyte data can be further analyzed to resolve any overlapping regions of the deduplicated analyte data. A second type of reporting metric can then be generated based on the deduplicated and non-overlapping analyte data. In some embodiments, for example, the first reporting metric may include an average glucose level, and the second reporting metric may include a low glucose event.

[0014] According to some embodiments, systems and methods are provided for transitioning a previously activated sensor control device to a new reader device. In some embodiments, for example, a method is provided in which a user interface application is installed on the user's new reader device, resulting in the generation of a device identifier. The user can then log in to a trusted computer system, whereby the device identifier associated with the user's user account is updated. According to one aspect of the embodiments, the user is then prompted to scan the previously activated sensor control device. In response to the scan, the previously activated sensor control device can cause the connection to the old reader device to be terminated. The new reader device and the previously activated sensor control device can then be paired, and the new reader device can receive historical glucose data (e.g., backfill data) from the previously activated sensor control device. In some embodiments, the sensor control device can provide historical glucose data throughout the entire wearing period.

[0015] In some embodiments, systems and methods for transitioning a previously activated sensor control device to a new reader device may include a security check performed by the reader device, wherein a user interface application on the reader device compares a sensor serial number received from a trusted computer system with a sensor serial number received from the sensor control device. In some embodiments, systems and methods for transitioning a previously activated sensor control device to a new reader device may include a security check performed by the sensor control device, wherein the sensor control device verifies the authenticity of a received identifier sent by the reader device to the sensor control device.

[0016] According to other embodiments, a method for generating a sensor insertion fault system alarm is provided. In some embodiments, a method is provided in which a sensor control device detects a sensor insertion fault condition. In response, the sensor control device stops performing analyte measurements and transmits a check sensor indicator to a reader device until a predetermined waiting period has elapsed, or until a check sensor indicator is received from the reader device, whichever occurs first. Subsequently, the sensor control device enters a storage state, where it can be reactivated later.

[0017] According to other embodiments, a method for generating a sensor termination system alarm is provided. In some embodiments, a method is provided in which a sensor control device detects a sensor termination condition. In response, the sensor control device stops performing analyte measurements and transmits a replacement sensor indicator to a reader device until a predetermined waiting period has elapsed, or until a replacement sensor indicator is received from the reader device, whichever occurs first. In some embodiments, after receiving the replacement sensor indicator, the sensor control device may also provide historical glucose data in response to a data backfill request from the reader device. Subsequently, the sensor control device enters a terminated state, in which it cannot be reactivated later.

[0018] 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, such as sensor user interfaces, allow users (and their caregivers) to better understand and improve their respective access to the analyte monitoring system. Similarly, many other embodiments described herein include improved digital interfaces and / or features for analyte monitoring systems that improve: the accuracy and completeness of analyte data collected by the analyte monitoring system by allowing data backfilling; the flexibility of the analyte monitoring system by allowing users to switch between different reader devices; and the functionality of the analyte monitoring system by providing more robust inter-device communication under certain adverse conditions, to name just a few.

[0019] The aspects described and claimed herein contribute at least technically to improvements in the GUI, as they help users of the device operate it more accurately, efficiently, and safely. It should be understood that the information presented to the user on the GUI, the order in which that information is presented, and the clarity of its structure can significantly influence how the user interacts with the system and how the system operates. Therefore, the GUI guides the user in accurately and efficiently obtaining necessary readings and / or acquiring information within the technical task of the operating system. Other improvements and advantages are also provided. Various configurations of these devices are described in detail through embodiments that are merely examples.

[0020] 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. 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. Aspects of the embodiments are set forth in the independent claims, and preferred features are set forth in the dependent claims. Preferred features of the dependent claims may be provided in combination in a single embodiment, and preferred features of one aspect may be provided in combination with other aspects. 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

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

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

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

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

[0025] Figures 2D to 2I This is an example implementation of a GUI that includes a sensor results interface.

[0026] Figures 3A to 3F This is an example implementation of a GUI that includes an interface within a time frame.

[0027] Figures 4A to 4O This is an example implementation of a GUI that includes an analysis level and a trend alert interface.

[0028] Figure 5A and Figure 5B This is an example implementation that includes a GUI for using the sensor.

[0029] Figures 5C to 5F This is an example implementation of a reporting GUI that includes sensor usage information.

[0030] Figure 6A and Figure 6B This is a flowchart depicting an example implementation of a method for data backfilling in an analyte monitoring system.

[0031] Figure 6C This is a flowchart illustrating an example implementation of a method for aggregating disconnection and reconnection events in an analyte monitoring system.

[0032] Figure 7 This is a flowchart illustrating an example implementation of a method for transmitting faulty or expired sensors in an analyte monitoring system.

[0033] Figure 8A and Figure 8BThis is a flowchart depicting an example implementation of a method for data merging in an analyte monitoring system.

[0034] Figures 8C to 8E It is a graph depicting the data at each stage of the processing according to an example implementation of a method for data merging in an analyte monitoring system.

[0035] Figures 9A to 9C This is a flowchart depicting an example implementation of a method for sensor overload in an analyte monitoring system.

[0036] Figures 9D to 9F This is an example implementation of the GUI to be displayed based on an example implementation of a method for sensor overload in an analyte monitoring system.

[0037] Figure 10A This is a flowchart depicting an example implementation of a method for generating a system alarm for sensor insertion failure.

[0038] Figures 10B to 10D This is an example implementation of the GUI to be displayed based on an example implementation of a method for generating a sensor insertion fault system alarm.

[0039] Figure 11A This is a flowchart depicting an example implementation of a method for generating a sensor-termination system alarm.

[0040] Figures 11B to 11D This is an example implementation of the GUI to be displayed based on an example implementation of a method for generating sensor termination system alarms.

[0041] In addition, a color version of the accompanying drawings is attached here as Appendix A and is incorporated by reference for all purposes. Detailed Implementation

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

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

[0044] The publications discussed herein are provided solely based on their public disclosure 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 publications by virtue of prior disclosure. Furthermore, the publication dates provided may differ from the actual publication dates, which may require independent verification.

[0045] In general, embodiments of this disclosure include GUIs, software, and digital interfaces for analyte monitoring systems, as well as associated methods and apparatus. 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.

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

[0047] Improved graphical user and digital interfaces are provided for analyte monitoring systems. For example, various implementations of the GUI are disclosed, including time ranges, analyte level / trend alarms, and sensor user interfaces. Furthermore, various implementations of the digital interface are described, including methods for data backfilling, transmission of expired or faulty sensors, merging data from multiple devices in the analyte monitoring system, transitioning previously activated analyte sensors to new reader devices, and autonomous sensor system alarms, among others.

[0048] As previously described, many embodiments described herein provide improved GUIs for analyte monitoring systems, which are highly intuitive, user-friendly, and provide rapid access to the user's physiological information. According to some embodiments, a time-range GUI for the analyte monitoring system is provided, wherein the time-range GUI comprises multiple bars or bar portions, each bar or barportion indicating the amount of time within a predetermined analyte range associated with the bar or barportion. According to another embodiment, an analyte level / trend alert GUI for the analyte monitoring system is provided, wherein the analyte level / trend alert GUI includes visual notifications (e.g., alerts, alarms, pop-ups, banner notifications, etc.), and wherein the visual notifications include an alert condition, an analyte level measurement associated with the alert condition, and a trend indicator associated with the alert condition. In summary, these embodiments provide a robust, user-friendly interface that increases user engagement with the analyte monitoring system and provides timely and actionable responses to the user, to name just a few advantages.

[0049] Furthermore, several embodiments described herein provide improved digital interfaces for analyte monitoring systems. According to some embodiments, improved methods, and associated systems and apparatuses are provided for data backfilling, aggregation of wireless communication link disconnection and reconnection events, expired or faulty sensor transmissions, merging data from multiple devices, transitioning previously activated sensors to new reader devices, generating sensor insertion failure system alarms, and generating sensor termination system alarms. These digital interfaces collectively and individually improve the accuracy and completeness of analyte data collected by the analyte monitoring system, enhance the flexibility of the analyte monitoring system by allowing users to switch between different reader devices, and improve the alarm capability of the analyte monitoring system by providing more robust inter-device communication under certain adverse conditions, to name just a few. Other improvements and advantages are also provided. Various configurations of these apparatuses are described in detail through embodiments that are merely examples.

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

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

[0052] In vivo analyte monitoring systems can be distinguished from "ex vivo" systems, which contact biological samples (or "ex vivo") outside the body and typically include an instrumentation device 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.

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

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

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

[0056] Figure 1This 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 2A The 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.

[0057] Example implementation of the reader device

[0058] 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 source 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.

[0059] Example implementation of sensor control device

[0060] Figure 2B and Figure 2C This 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).

[0061] 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), where, for example, a resident software application requires minimal further processing to display the data. According to some implementations, for example, the current glucose value can be transmitted from the sensor control device 102 to the reader device 120 every minute, and the historical glucose value can be transmitted from the sensor control device 102 to the reader device 120 every five minutes.

[0062] 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 transmission to the reader device 120 (not shown), and to determine certain alarm conditions (e.g., sensor failure 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.

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

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

[0065] This document describes an example implementation of a GUI for an analyte monitoring system. First, those skilled in the art will understand that the GUI described herein includes 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 cause the one or more processors to 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.

[0066] Example implementation of sensor results interface

[0067] Figures 2D to 2I An example implementation of a sensor results interface or GUI for an analyte monitoring system is described. According to one aspect of the implementation, the sensor results GUI described herein is configured to display analyte data and other health information, such as information about..., via a user interface application (e.g., software) installed on a reader device (e.g., a smartphone or receiver). Figure 2BThose described herein. Those skilled in the art will also understand that user interface applications with sensor result interfaces or GUIs can also be implemented on local computer systems or other computing devices (e.g., wearable computing devices, smartwatches, tablets, etc.).

[0068] First refer to Figure 2D The sensor results GUI 235 depicts an interface including a first portion 236, which may include a numerical representation of the current analyte concentration value (e.g., the current glucose value), a directional arrow indicating the direction of the analyte trend, and a text description providing contextual information, such as whether the user's analyte level is within range (e.g., "glucose is within range"). The first portion 236 may also include colors or shading to indicate the analyte concentration or trend. For example, as... Figure 2D As shown, the first portion 236 is a green shading, indicating that the user's analyte level is within the target range. According to some embodiments, for example, a red shading may indicate analyte levels below a low analyte level threshold, an orange shading may indicate analyte levels above a high analyte level threshold, and a yellow shading may indicate analyte levels outside the target range. Furthermore, according to some embodiments, the sensor results GUI 235 also includes a second portion 237, which includes a graphical representation of the analyte data. Specifically, the second portion 237 includes an analyte trend graph, which reflects the analyte concentration over a predetermined time period (as shown on the x-axis) (as shown on the y-axis). In some embodiments, the predetermined time period may be displayed in five-minute increments, for a total of twelve hours of data. However, those skilled in the art will understand that other time increments and durations of analyte data can be employed, and are entirely within the scope of this disclosure. The second portion 237 may also include a point 239 on the analyte trend graph indicating the current analyte concentration value, a green shading area 240 indicating the target analyte range, and two dashed lines 238a and 238b indicating the high and low analyte thresholds, respectively. According to some implementations, GUI 235 may also include a third part 241, which includes a graphical indicator and text information representing the remaining sensor lifetime.

[0069] Next reference Figure 2E This describes another example implementation of the sensor results GUI 245. According to one aspect of the implementation, a first section 236 is shown in yellow shading to indicate that the user's current analyte concentration is outside the target range. Furthermore, a second section 237 includes: an analyte trend line 241, which may reflect historical analyte levels over time, and a current analyte data point 239 to indicate the current analyte concentration value (shown in yellow to indicate that the current value is outside the target range).

[0070] According to another aspect of the implementation, the data on the sensor results GUI 245 is automatically updated or refreshed according to update intervals (e.g., every second, every minute, every 5 minutes, etc.). For example, according to many implementations, as the reader device receives analyte data, the sensor results GUI 245 will update: (1) the current analyte concentration value displayed in the first section 236, and (2) the analyte trend line 241 and the current analyte data point 239 displayed in the second section 237. Furthermore, in some implementations, automatically updated analyte data may result in older historical analyte data no longer being displayed (e.g., on the left side of the analyte trend line 241).

[0071] Figure 2F This is another example implementation of the sensor results GUI 250. According to the depicted implementation, the sensor results GUI 250 includes a first portion 236 displayed in orange shading to indicate that the user's analyte level is above a high glucose threshold (e.g., greater than 250 mg / dL). The sensor results GUI 250 also depicts health information icons 251, such as exercise icons or apple icons, to reflect user-recorded entries indicating when the user exercised or ate.

[0072] Figure 2G This is another example implementation of the sensor results GUI 255. According to the depicted implementation, the sensor results GUI 255 includes a first portion 236, also displayed in orange shading, to indicate that the user's analyte level is above a high glucose threshold. Figure 2G As can be seen, the first section, 236, does not report numerical values ​​but instead displays the text "High (HI)" to indicate that the current analyte concentration value is outside the upper limit of the glucose reporting range. Although Figure 2G Not described herein, but those skilled in the art will understand that, conversely, analyte concentrations below the lower limit of the glucose reporting range will cause the first section 236 to not display a numerical value, but instead display the text “Low (LO)”.

[0073] Figure 2HThis is another example implementation of the sensor results GUI 260. According to the depicted implementation, the sensor results GUI 260 includes a first portion 236 displayed in green shading to indicate that the user's current analyte level is within a target range. Furthermore, according to the depicted implementation, the first portion 236 of the GUI 260 includes the text "Glucose Low," which may indicate to the user that his or her analyte concentration value is predicted to decrease below a predicted low analyte level threshold within a predetermined time period (e.g., predicted glucose will decrease to below 75 mg / dL within 15 minutes). Those skilled in the art will understand that the sensor results GUI 260 may display a "Glucose High" message if the user's analyte level is predicted to rise above a predicted high analyte level threshold within a predetermined time period.

[0074] Figure 2I This is another example implementation of the sensor results GUI 265. According to the depicted implementation, when a sensor error is present, the sensor results GUI 265 depicts a first portion 236. According to one aspect of the implementation, the first portion 236 includes three dashed lines 266 in place of the current analyte concentration value to indicate that the current analyte value is unavailable. In some implementations, the three dashed lines 266 may indicate one or more error conditions, such as (1) a no-signal condition; (2) a signal loss condition; (3) a sensor overheating / overcooling condition; or (4) a glucose level unavailable condition. Furthermore, as... Figure 2I As can be seen, the first portion 236 includes a gray shading (instead of green, yellow, orange, or red) to indicate that no current analyte data is available. Furthermore, according to another aspect of the embodiment, the second portion 237 can be configured to display historical analyte data in the analyte trend graph, even if an error condition prevents the display of the current analyte concentration value in the first portion 236. However, as... Figure 2I As shown in the figure, the current analyte concentration data points are not displayed on the analyte trend graph in Part 237.

[0075] Example implementation of the interface within the time range

[0076] Figures 3A to 3F An example implementation of a GUI for an analyte monitoring system is described. Specifically, Figures 3A to 3F A GUI is described within a time range (also referred to as within a time scope and / or within a time target), each GUI comprising multiple bars or bar segments, wherein each bar or bar segment indicates the amount of time within a predetermined analyte range associated with the user's analyte level. In some implementations, for example, the amount of time may be expressed as a percentage of the predetermined amount of time.

[0077] Go to Figure 3Aand Figure 3B An example implementation of a time-range GUI 305 is shown, wherein the time-range GUI 305 includes a “custom” time-range view 305A and a “standard” time-range view 305B, having a swivelable element 310 that allows the user to select between the two views. According to one aspect of the implementation, the time-range views 305A, 305B may each include a plurality of bars, wherein each bar indicates the amount of time within a predetermined analyte range associated with that bar. In some implementations, the time-range views 305A, 305B also include a date range indicator 308 indicating the relevant dates associated with the displayed plurality of bars, and a data availability indicator 314 indicating the availability of analyte data for the time period of the displayed analyte data (e.g., “data for 7 days out of 7”).

[0078] refer to Figure 3A The “customized” time range view 305A includes six bars, including (from top to bottom): the first bar indicates that the user's glucose range is above 250 mg / dL within 10% of the amount at a predetermined time; the second bar indicates that the user's glucose range is between 141 and 250 mg / dL within 24% of the amount at a predetermined time; the third bar 316 indicates that the user's glucose range is between 100 and 140 mg / dL within 54% of the amount at a predetermined time; the fourth bar indicates that the user's glucose range is between 70 and 99 mg / dL within 9% of the amount at a predetermined time; the fifth bar indicates that the user's glucose range is between 54 and 69 mg / dL within 2% of the amount at a predetermined time; and the sixth bar indicates that the user's glucose range is less than 54 mg / dL within 1% of the amount at a predetermined time. Those skilled in the art will recognize that the glucose range and time percentage associated with each bar can vary depending on the user-defined range and the user's available analyte data. Furthermore, although... Figure 3A and Figure 3B The quantity 314, which is equal to seven days, is shown, but those skilled in the art will understand that other quantities of time (e.g., one day, three days, fourteen days, thirty days, ninety days, etc.) may be used and are fully within the scope of this disclosure.

[0079] According to another aspect of the embodiment, the "customized" time range view 305A also includes a user-definable customized target range 312, which includes an operable "edit" link that allows the user to define and / or change the customized target range. As shown in the "customized" time range view 305A, the customized target range 312 has been defined as a glucose range between 100 and 140 mg / dL, and corresponds to the third of a plurality of bars 316. Those skilled in the art will understand that in other embodiments, the user may adjust more than one range, and these embodiments are entirely within the scope of this disclosure.

[0080] refer to Figure 3B The "Standard" time range view 305B includes five bars (from top to bottom): the first bar indicates that the user's glucose range is above 250 mg / dL within 10% of the predetermined time amount; the second bar indicates that the user's glucose range is between 181 and 250 mg / dL within 24% of the predetermined time amount; the third bar indicates that the user's glucose range is between 70 and 180 mg / dL within 54% of the predetermined time amount; the fourth bar indicates that the user's glucose range is between 54 and 69 mg / dL within 10% of the predetermined time amount; and the fifth bar indicates that the user's glucose range is less than 54 mg / dL within 2% of the predetermined time amount. Similar to the "Customized" time range view 305A, those skilled in the art will recognize that the percentage of time associated with each bar can vary depending on the user's available analyte data. However, unlike the "Customized" time range view 305A, the glucose range shown in the "Standard" view 305B cannot be adjusted by the user.

[0081] Figure 3C and Figure 3D Another example implementation of a GUI 320 with multiple views 320A and 320B over a time span is depicted, which are respectively similar to Figure 3A and Figure 3B The view shown. According to some embodiments, the time-range GUI 320 may also include one or more selectable icons 322 (e.g., radio buttons, checkboxes, sliders, switches, etc.) that allow the user to select a predetermined time period at which the user's analytics data will be displayed in the time-range GUI 320. For example, as... Figure 3C and Figure 3D As shown, the amount of the scheduled time can be selected using selectable icon 322, which may be seven days, fourteen days, thirty days, or ninety days. Those skilled in the art will understand that other amounts of the scheduled time may be used, and are entirely within the scope of this disclosure.

[0082] Figure 3EAn example implementation of a time-target within-GUI 330 is depicted, which can be visually output to the display of a reader device (e.g., a dedicated reader device, instrumentation device, etc.). According to one aspect of the implementation, the time-target within-GUI 330 includes three bars, including (from top to bottom): a first bar indicating that the user's glucose range is above a predetermined target range within 34% of the amount at a predetermined time; a second bar indicating that the user's glucose range is within the predetermined target range within 54% of the amount at a predetermined time; and a third bar indicating that the user's glucose range is below the predetermined target range within 12% of the amount at a predetermined time. Those skilled in the art will recognize that the time percentage associated with each bar can vary depending on the user's available analyte data. Furthermore, although... Figure 3E The predetermined time amount 332 is shown to be equal to the last seven days, and the predetermined target range 334 is 80 to 140 mg / dL. However, those skilled in the art will understand that other predetermined time amounts (e.g., one day, three days, fourteen days, thirty days, ninety days, etc.) and / or predetermined target ranges (e.g., 70 to 180 mg / dL) may be used, and are well within the scope of this disclosure.

[0083] Figure 3F Another example implementation of the GUI 340 within a time range is depicted, comprising a single bar comprising five bar sections, the five bar sections comprising (from top to bottom): the first bar section indicating that the user's glucose range is "very high" or above 250 mg / dL for 1% (14 minutes) of the predetermined time amount; the second bar section indicating that the user's glucose range is "high" or between 180 and 250 mg / dL for 18% (4 hours and 19 minutes) of the predetermined time amount; the third bar section indicating that the user's glucose range is within the "target range" or between 70 and 180 mg / dL for 78% (18 hours and 43 minutes) of the predetermined time amount; the fourth bar section indicating that the user's glucose range is "low" or between 54 and 69 mg / dL for 3% (43 minutes) of the predetermined time amount; and the fifth bar section indicating that the user's glucose range is "very low" or less than 54 mg / dL for 0% (0 minutes) of the predetermined time amount. Figure 3F As shown, according to some implementations, the GUI 340 can display text adjacent to each bar section within a time range, which indicates the amount of actual time, for example, in hours and / or minutes.

[0084] according to Figure 3FIn one aspect of the illustrated embodiment, each bar segment of the GUI 340 within a time range may include a different color. In some embodiments, the bar segments may be separated by dashed lines or dashed lines 342 and / or inserted with numerical markers 344 to indicate the range reflected by adjacent bar segments. In some embodiments, the time within the range reflected by the bar segments may be further expressed as a percentage, an amount of actual time (e.g., 4 hours and 19 minutes), or as... Figure 3F 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 340, the target range can be configured by the user. In other embodiments, the target range of the time-range GUI 340 cannot be modified by the user.

[0085] Example implementation of the analyte level and trend alert interface

[0086] Figures 4A to 4O An example implementation of an analyte level / trend alert GUI for an analyte monitoring system is described. According to one aspect of the implementation, the analyte level / trend alert GUI includes visual notifications (e.g., alerts, alarms, pop-ups, banner notifications, etc.), wherein the visual notifications include an alert condition, an analyte level measurement associated with the alert condition, and a trend indicator associated with the alert condition.

[0087] Go to Figures 4A to 4C Example implementations of high glucose alarm 410, low glucose alarm 420, and severe low glucose alarm 430 are depicted, wherein each alarm includes a pop-up window 402 containing alarm condition text 404 (e.g., "Low Glucose Alarm"), an analyte level measurement 406 associated with the alarm condition (e.g., current glucose level is 67 mg / dL), and a trend indicator 408 associated with the alarm condition (e.g., trend arrow or directional arrow). In some implementations, an alarm icon 412 may be adjacent to the alarm condition text 404.

[0088] Next reference Figures 4D to 4G Additional example implementations of low glucose alarms 440 and 445, severe low glucose alarm 450, and high glucose alarm 455 are described respectively. Figure 4D As shown, the low glucose alarm 440 is similar to Figure 4BThe low glucose alarm (e.g., including a pop-up window containing alarm condition text, an analyte level measurement associated with the alarm condition, and a trend indicator associated with the alarm condition), but also includes a critical alert icon 442 to indicate that the alarm has been configured as a critical alarm (e.g., it will be displayed, played, and vibrated even if the device is locked or if the device's "Do Not Disturb" setting is enabled). About Figure 4E Low glucose alert 445 is also similar Figure 4B The low glucose alert 445 includes a text trend indicator 447, but does not include a trend arrow. According to one aspect of some implementations, the text trend indicator 447 can be enabled via device accessibility settings, such that the device "reads" the text trend indicator 447 to the user via the device's text-to-speech features (e.g., Voiceover on iOS or Select-to-Speech on Android).

[0089] Next reference Figure 4F Low glucose alarm 450 is similar to Figure 4D A low glucose alarm (including a key alarm icon), but instead of displaying the analyte level measurement associated with the alarm condition and a trend indicator associated with the alarm condition, low glucose alarm 450 displays an out-of-range indicator 452 to indicate that the current glucose level is above or below a predetermined range of reportable analyte levels (e.g., "High (HI)" or "Low (LO)"). About Figure 4G High glucose alert 455 is similar to Figure 4A The high glucose alert includes (e.g., a pop-up window containing alert condition text, an analyte level measurement associated with the alert condition, and a trend indicator associated with the alert condition), but also includes instructions 457 for the user. In some implementations, the instruction may be, for example, prompting the user to “check blood glucose.” Those skilled in the art will understand that other instructions or prompts may be given (e.g., administering a corrective bolus, eating, etc.).

[0090] Furthermore, despite Figures 4A to 4G An example implementation of an analyte level / trend alert GUI displayed on a smartphone with the iOS operating system is described, but those skilled in the art will understand that the analyte level / trend alert GUI can be implemented on other devices, such as smartphones with other operating systems, smartwatches, wearable devices, reader devices, tablet computing devices, blood glucose meters, laptops, desktop computers, and workstations. For example, Figures 4H to 4J Example implementations of high glucose alarms, low glucose alarms, and severe low glucose alarms for smartphones running the Android operating system are described. Similarly, Figures 4K to 4OExample implementations of critical low glucose alarm, low glucose alarm, high glucose alarm, critical low glucose alarm (with a glucose check icon), and high glucose alarm (with an out-of-range indicator) for a reader device are described respectively.

[0091] Example implementation of sensor user interface

[0092] Figures 5A to 5F Example implementations of a sensor user interface related to a GUI for an analyte monitoring system are described. According to one aspect of the implementation, the sensor user interface provides technical improvements, including the ability to quantify and facilitate user interaction with the analyte monitoring system. According to some implementations, for example, the sensor user interface may include a visual display of one or more “view” metrics, each “view” metric indicating a measurement of user interaction with the analyte monitoring system. For example, a “view” may include an instance where a sensor results interface is presented or brought into the foreground. In some implementations, the sensor user interface may include a visual display of a “scan” metric, indicating another measurement of user interaction with the analyte monitoring system. For example, a “scan” may include an instance where a user uses a reader device (e.g., a smartphone, a dedicated reader, etc.) to scan a sensor control device, such as in a rapid analyte monitoring system.

[0093] Figure 5A and Figure 5B Example embodiments of sensor user interfaces 500 and 510 are depicted respectively. According to one aspect of the embodiments, sensor user interfaces 500 and 510 can be presented and displayed, for example, by a mobile application or software residing in the non-transitory memory of the reader device 120, such as regarding… Figure 1 and Figure 2A Those described. References Figure 5A The sensor user interface 500 may include: a predetermined time interval 508, indicating a time period (e.g., a date range) during which viewing metrics are measured; a total viewing metric 502, indicating the total number of views during the predetermined time interval 508; a daily viewing metric 504, indicating the average number of views per day during the predetermined time interval 508; and a percentage time sensor active metric 506, indicating the percentage of the predetermined time interval 508 during which the reader device 120 communicates with the sensor control device 102, for example, regarding... Figure 1 , Figure 2B and Figure 2C Those described. References Figure 5BThe sensor user interface 510 may include a daily viewing metric 504 and a sensor activation time percentage metric 508, each of which is measured within a predetermined time period 508.

[0094] According to another aspect of the implementation, although the predetermined time period 508 is shown as one week, those skilled in the art will recognize that other predetermined time periods (e.g., 3 days, 14 days, 30 days) can be used. Furthermore, the predetermined time period 508 can be a discrete time period—having a start date and an end date—such as… Figure 5A The sensor user interface 500 is shown, or it can be a time period relative to the current date or time (e.g., "last 7 days", "last 14 days", etc.), such as Figure 5B The sensor interface 510 is shown.

[0095] Figure 5C An example implementation of a sensor user interface 525 as part of an analyte monitoring system reporting GUI 515 is depicted. According to one aspect of the implementation, GUI 515 is a snapshot report covering a predetermined time period 516 (e.g., 14 days) and includes multiple reporting sections on a single reporting GUI, including: a sensor user interface section 525; a glucose trend interface 517, which may include a glucose trend graph, a low glucose event graph, and other relevant glucose metrics (e.g., glucose management indicators); a health information interface 518, 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 519, which may include additional information about the user's analyte and medication patterns presented in a narrative format. According to another aspect of the implementation, sensor user interface 525 may include a percentage-time sensor activation metric 526, an average scan / view metric 527 (e.g., an average sum of scans and views), and a percentage-time sensor activation graph 528. Figure 5C As can be seen, the axis of the percentage time sensor activation graph can be aligned with the corresponding axis 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 axis (e.g., time of day).

[0096] Figure 5D An example implementation of a GUI 530 for another analytical monitoring system report, which includes sensor usage information, is depicted. According to one aspect of the implementation, GUI 530 is a monthly summary report comprising a first section including a legend 531, wherein the legend 531 includes multiple graphic icons, each adjacent to descriptive text. Figure 5D As shown, illustration 531 includes icons and descriptive text for "Average Glucose," icons and descriptive text for "Scan / View," and icons and descriptive text for "Low Glucose Events." The GUI 530 also includes a second part, which includes a calendar interface 532. For example, as... Figure 5D As shown, GUI 530 includes a calendar interface, wherein each day of a month may include one or more of the following: average glucose metric, low glucose event icon, and sensor usage metric 532. In some implementations, for example... Figure 5D In the implementation shown, the sensor uses a metric (“scan / view”) to indicate the sum of the number of scans and views per day.

[0097] Figure 5E An example implementation of another analyte monitoring system reporting GUI 540, including sensor usage information, is depicted. According to one aspect of the implementation, GUI 540 is a weekly summary report comprising multiple report sections, each representing a different day of the week, and each report section including a glucose trend graph 541, which may include glucose levels measured by the user over a 24-hour period, and a health information interface 543, which may include information about the user's average daily glucose, carbohydrate intake, and / or insulin dosage. In some implementations, the glucose trend graph 541 may include sensor usage markers 542 to indicate that a scan, view, or both has occurred at a specific time during the 24-hour period.

[0098] Figure 5F An example implementation of another analyte monitoring system reporting GUI 550, including sensor usage information, is depicted. According to one aspect of the implementation, GUI 550 is a daily log report including a glucose trend graph 551, which may include the user's glucose levels over a 24-hour period. In some implementations, the glucose trend graph 551 may include sensor usage markers 552 to indicate that a scan, view, or both has occurred at a specific time during the 24-hour period. The glucose trend graph 551 may also include recorded event markers, such as recorded carbohydrate intake markers 553 and recorded insulin dose markers 554, as well as glucose event markers, such as a low glucose event marker 555.

[0099] Those skilled in the art will understand that any GUI, reporting interface, or part 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 element or combination of elements depicted and / or described for any other embodiment.

[0100] Example implementation of a digital interface for an analyte monitoring system

[0101] This document describes an example implementation of a digital interface for an analyte monitoring system. According to one aspect of the implementation, the digital interface may include a series of instructions, routines, subroutines, and / or algorithms executed by one or more processors of one or more devices in the analyte monitoring system, such as software and / or firmware stored in non-transitory memory, wherein the instructions, routines, subroutines, or algorithms are configured to enable certain functions and inter-device communication. First, those skilled in the art will understand that the digital interface described herein may include instructions stored in the non-transitory memory of sensor control device 102, 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 the analyte monitoring system 100, as referenced... Figure 1 , Figure 2A and Figure 2B As described herein, when these instructions are executed by one or more processors of the sensor control device 102, reader device 120, local computer system 170, trusted computer system 180, or other device or system of the analyte monitoring system 100, the one or more processors cause the one or more processors to perform the method steps described herein. Those skilled in the art will further recognize that the digital interface described herein can be stored as instructions in the memory of a single centralized device, or alternatively, can be distributed across multiple discrete devices in geographically dispersed locations.

[0102] Example implementation of a method for data backfilling

[0103] An example implementation of a method for data backfilling in an analyte monitoring system will now be described. According to one aspect of the implementation, gaps in analyte data and other information can be caused by interruptions in communication links between various devices in the analyte monitoring system 100. These interruptions can occur, for example, from a device power outage (e.g., a user's smartphone battery depletes), or from a first device temporarily being moved out of wireless communication range from a second device (e.g., a user wearing sensor control device 102 inadvertently leaves her smartphone at home while she goes to work). As a result of these interruptions, reader device 120 may be unable to receive analyte data and other information from sensor control device 102. Therefore, it would be beneficial to have a robust and flexible method for data backfilling in the analyte monitoring system to ensure that each analyte monitoring device can receive the complete dataset as expected once the communication link is re-established.

[0104] Figure 6AThis is a flowchart depicting an example embodiment of a method 600 for data backfilling in an analyte monitoring system. According to one aspect of the embodiment, method 600 can be implemented to provide data backfilling between a sensor control device 102 and a reader device 120. In step 602, analyte data and other information are autonomously transmitted between a first device and a second device at predetermined intervals. In some embodiments, the first device may be the sensor control device 102, and the second device may be the reader device 120, as per [reference needed]. Figure 1 , Figure 2A and Figure 2B As described. According to one aspect of the implementation, analyte data and other information may include, but are not limited to, one or more of the following: data indicating analyte levels in bodily fluids, rates of change of analyte levels, predicted analyte levels, low or high analyte level alarm conditions, sensor failure conditions, or communication link events. According to another aspect of the implementation, autonomous transmission at predetermined intervals may include streaming analyte data and other information at one or more predetermined rates (e.g., every minute, every five minutes, every fifteen minutes, etc.) according to standard wireless communication network protocols, such as Bluetooth or Bluetooth Low Energy protocols. In some implementations, different types of analyte data or other information may be autonomously transmitted between the first and second devices at different predetermined rates (e.g., historical glucose data every 5 minutes, current glucose values ​​every minute, etc.).

[0105] In step 604, a disconnection event or condition occurs that causes the communication link between the first device and the second device to be interrupted. As described above, the disconnection event can be caused by the second device (e.g., reader device 120, smartphone, etc.) running out of battery power or by the user manually turning off the power. The disconnection event can also be caused by the first device moving out of the wireless communication range of the second device, by the presence of a physical barrier that obstructs the first device and / or the second device, or by anything that otherwise prevents wireless communication between the first and second devices.

[0106] In step 606, a communication link is re-established between the first and second devices (e.g., the first device returns to the wireless communication range of the second device). Once reconnected, the second device requests historical analyte data based on the last lifetime count metric of the received data. According to one aspect of the implementation, the lifetime count metric may be a value that is incremented and tracked on the second device in units of time (e.g., minutes) and indicates the amount of time elapsed since the sensor control device was activated. For example, in some implementations, after the second device (e.g., reader device 120, smartphone, etc.) re-establishes a Bluetooth wireless communication link with the first device (e.g., sensor control device 120), the second device may determine the last lifetime count metric of the received data. Then, according to some implementations, the second device may send a request to the first device for historical analyte data and other information having a lifetime count metric greater than the determined last lifetime count metric of the received data.

[0107] In some implementations, the second device may send a request to the first device for historical analyte data or other information associated with a specific lifetime count range, rather than requesting historical analyte data associated with a lifetime count metric greater than a determined last lifetime count metric of the received data.

[0108] In step 608, once a request is received, the first device retrieves the requested historical analyte data from memory (e.g., the non-temporary memory of sensor control device 102), and then transmits the requested historical analyte data to the second device in step 610. In step 612, once the requested historical analyte data is received, the second device stores the requested historical analyte data in memory (e.g., the non-temporary memory of reader device 120). According to one aspect of the implementation, when the requested historical analyte data is stored by the second device, it may be stored together with an associated lifetime count metric. In some implementations, the second device may also output the requested historical analyte data to a display of the second device, such as a glucose trend graph to a sensor results GUI, for example, regarding... Figures 2D to 2I Those described. For example, in some implementations, the requested historical analyte data can be used to fill in gaps in a glucose trend graph by displaying the requested historical analyte data along with previously received analyte data.

[0109] Furthermore, those skilled in the art will understand that the data backfilling method can be implemented among multiple and various devices in an analyte monitoring system, wherein the devices are connected to each other via wired or wireless communication.

[0110] Figure 6BThis is a flowchart depicting another example implementation of a method 620 for data backfilling in an analyte monitoring system. According to one aspect of the implementation, method 620 can be implemented to provide data backfilling between a reader device 120 (e.g., a smartphone, a dedicated reader) and a trusted computer system 180 (e.g., a cloud-based platform for generating reports). In step 622, analyte data and other information are transferred between the reader device 120 and the trusted computer system 180 based on multiple upload triggers. According to one aspect of the implementation, the analyte data and other information may include, but is not limited to, one or more of the following: data indicating analyte levels in bodily fluids (e.g., current glucose levels, historical glucose data), rates of change in analyte levels, predicted analyte levels, low or high analyte level alarm conditions, user-recorded information, information associated with sensor control device 102, alarm information (e.g., alarm settings), wireless connection events, and reader device settings, etc.

[0111] According to another aspect of the implementation, multiple upload triggers may include (but are not limited to) one or more of the following: activation of sensor control device 102; user input or deletion of comments or log entries; re-establishment of a wireless communication link (e.g., Bluetooth) between reader device 120 and sensor control device 102; change of alarm threshold; alarm display, update, or deactivation; re-establishment of internet connection; restart of reader device 120; receipt of one or more current glucose readings from sensor control device 102; termination of sensor control device 120; display, update, or deactivation of signal loss alarm; signal loss alarm on / off; sensor results screen GUI view; or user login to a cloud-based platform.

[0112] According to another aspect of the implementation, in order to track the transmission and reception of data between devices, the reader device 120 may "mark" analyte data and other information to be transmitted to the trusted computer system 180. In some implementations, for example, upon receiving analyte data and other information, the trusted computer system 180 may send a return response to the reader device 120 to confirm that the analyte data and other information have been successfully received. Subsequently, the reader device 120 may mark the data as successfully transmitted. In some implementations, the analyte data and other information may be marked by the reader device 120 before transmission and after receiving the return response. In other implementations, the analyte data and other information may be marked by the reader device 120 only after receiving the return response from the trusted computer system 180.

[0113] refer to Figure 6BIn step 624, a disconnection event occurs, which causes the communication link between the reader device 120 and the trusted computer system 180 to be interrupted. For example, the disconnection event may be caused by the user putting the reader device 120 into "airplane mode" (e.g., disabling the wireless communication module), by the user turning off the reader device 120, or by the reader device 120 moving out of the wireless communication range.

[0114] In step 626, the communication link between the reader device 120 and the trusted computer system 180 (and the Internet) is re-established, one of multiple upload triggers. Subsequently, the reader device 120 determines the final successful transmission of data to the trusted computer system 180 based on previously tagged analyte data and other information sent. Then, in step 628, the reader device 120 may transmit the analyte data and other information that the trusted computer system 180 has not yet received. In step 630, the reader device 120 receives confirmation from the trusted computer system 180 that the analyte data and other information have been successfully received.

[0115] Although the reader described above for communicating with a trusted computer system... Figure 6B However, those skilled in the art will understand that the data backfilling method can be applied between other devices and computer systems in an analyte monitoring system (e.g., between a reader and a local computer system, between a reader and a medical delivery device, between a reader and a wearable computing device, etc.). These implementations, as well as their variations and arrangements, are entirely within the scope of this disclosure.

[0116] In addition to data backfilling, example implementations of a method for aggregating disconnection and reconnection events of wireless communication links in an analyte monitoring system are described. According to one aspect of the implementation, interruptions of wireless communication links between various devices in an analyte monitoring system can have a variety of and wide-ranging causes. Some causes may be inherently technical (e.g., a reader device is outside the wireless communication range of a sensor control device), while others may be related to user behavior (e.g., a user leaves his or her reader device at home). Therefore, collecting information about disconnection and reconnection events between various devices in an analyte monitoring system is beneficial for improving connectivity and data integrity.

[0117] Figure 6CThis is a flowchart illustrating an example implementation of a method 640 for aggregating disconnection and reconnection events of wireless communication links in an analyte monitoring system. In some implementations, for example, method 640 may be used to detect, record, and upload Bluetooth or Bluetooth Low Energy disconnection and reconnection events between sensor control device 102 and reader device 120 to a trusted computer system 180. According to one aspect of the implementation, the trusted computer system 180 may aggregate disconnection and reconnection events transmitted from multiple analyte monitoring systems. The aggregated data can then be analyzed to determine whether any conclusions can be drawn regarding how to improve connectivity and data integrity in the analyte monitoring system.

[0118] In step 642, based on multiple upload triggers, analyte data and other information, such as previously mentioned data, are transmitted between the reader device 120 and the trusted computer system 180. Figure 6B The methods described in method 620. In step 644, a disconnection event occurs that causes an interruption of the wireless communication link between sensor control device 102 and reader device 120. Examples of disconnection events may include, but are not limited to, user putting reader device 120 into "airplane mode", user turning off reader device 120, reader device 120 running out of power, sensor control device 102 moving out of wireless communication range of reader device 120, or physical barriers blocking sensor control device 102 and / or reader device 120, to name just a few.

[0119] Still referencing Figure 6C In step 646, the wireless communication link between the sensor control device 102 and the reader device 120 is re-established, which is one of multiple upload triggers. Subsequently, the reader device 120 determines the disconnection time and reconnection time, where the disconnection time is the time when the interruption of the wireless communication link begins, and the reconnection time is the time when the wireless communication link between the sensor control device 102 and the reader device 120 is re-established. According to some embodiments, the disconnection and reconnection times may also be stored locally in an event log on the reader device 120. In step 648, the reader device 120 transmits the disconnection and reconnection times to the trusted computer system 180.

[0120] According to some implementations, disconnection and reconnection times may be stored in a non-transitory memory of the trusted computer system 180, such as in a database, and aggregated with disconnection and reconnection times collected from other analyte monitoring systems. In some implementations, disconnection and reconnection times may also be transferred to and stored on a cloud-based platform or server different from the trusted computer system 180 that stores the analyte data. In other implementations, disconnection and reconnection times may be anonymized.

[0121] Furthermore, those skilled in the art will recognize that method 640 can be used to collect disconnection and reconnection times between other devices in an analyte monitoring system, including, for example: between reader device 120 and trusted computer system 180; between reader device 120 and wearable computing device (e.g., smartwatch, smart glasses); between reader device 120 and drug delivery device (e.g., insulin pump, insulin pen); between sensor control device 102 and wearable computing device; between sensor control device 102 and drug delivery device; and combinations of any other devices within the analyte monitoring system. Those skilled in the art will further understand that method 640 can be used to analyze disconnection and reconnection times of different wireless communication protocols, such as Bluetooth or Bluetooth Low Energy, NFC, 802.11x, UHF, cellular connectivity, or any other standard or proprietary wireless communication protocol.

[0122] Example implementation of improved expired / faulty sensor transmission

[0123] An example implementation of a method for improving the transmission of expired and / or faulty sensors in an analyte monitoring system will now be described. According to one aspect of the implementation, an expired or faulty sensor condition detected by sensor control device 102 can trigger a critical alarm on reader device 120. However, if reader device 120 is in "airplane mode," powered off, outside the wireless communication range of sensor control device 102, or otherwise unable to wirelessly communicate with sensor control device 102, reader device 120 may fail to receive these critical alarms. This could cause the user to miss important information, such as the need for rapid replacement of sensor control device 102. Failure to take action on detected sensor faults could also result in the user being unaware of adverse glucose conditions (e.g., hypoglycemia and / or hyperglycemia) due to sensor termination.

[0124] Figure 7This is a flowchart depicting an example embodiment of a method 700 for improving the transfer of expired or faulty sensors in an analyte monitoring system. According to one aspect of the embodiment, method 700 can be implemented as providing improved sensor transfer by a sensor control device 102 after an expired or faulty sensor condition has been detected. In step 702, the sensor control device 102 detects an expired or faulty sensor condition. In some embodiments, the sensor fault condition may include one or both of a sensor insertion fault condition or a sensor termination condition. According to some embodiments, for example, a sensor insertion fault condition or a sensor termination condition may include, but is not limited to, one or more of the following: a detected FIFO overflow condition, a sensor signal below a predetermined insertion fault threshold, detected moisture ingress, an electrode voltage exceeding a predetermined diagnostic voltage threshold, an early signal attenuation (ESA) condition, or a late signal attenuation (LSA) condition, etc.

[0125] Refer again Figure 7 In step 704, in response to the detection of a sensor malfunction condition, the sensor control device 102 stops acquiring measurements of the analyte level from the analyte sensor. In step 706, the sensor control device 102 begins transmitting an indication of the sensor malfunction condition to the reader device 120, while also allowing the reader device 120 to connect to the sensor control device 102 for data backfilling. According to one aspect of the embodiment, the transmission of the indication of the sensor malfunction condition may include the transmission of multiple Bluetooth or Bluetooth Low Energy advertising packets, each of which may include an indication of the sensor malfunction condition. In some embodiments, multiple Bluetooth or BLE advertising packets may be transmitted repeatedly, continuously, or intermittently. Those skilled in the art will recognize that other modes of wireless broadcasting or multicasting of the indication of the sensor malfunction condition may be implemented. According to another aspect of the embodiment, in response to receiving an indication of a sensor malfunction condition, the reader device 120 may visually display an alarm or prompt for user confirmation.

[0126] In step 708, the sensor control device 102 may be configured to monitor for a return response or acknowledgment received from the reader device 120 upon receiving a sensor fault condition indication. In some embodiments, for example, the reader device 120 may generate a return response or receive acknowledgment when a user clears an alarm associated with the sensor fault condition indication on the reader device 120, or otherwise responds to a prompt for acknowledging the sensor fault condition indication. If the sensor control device 102 receives a return response or receive acknowledgment regarding the sensor fault condition indication, then in step 714, the sensor control device 102 may enter a storage state or a terminated state. According to some embodiments, in the storage state, the sensor control device 102 is placed in a low-power mode, and the sensor control device 102 can be reactivated by the reader device 120. Conversely, in the terminated state, the sensor control device 102 cannot be reactivated and must be removed and replaced.

[0127] If the sensor control device 102 does not receive a fault condition indication, in step 710, the sensor control device 102 will stop transmitting the fault condition indication after a first predetermined time period. In some embodiments, for example, the first predetermined time period may be one of one hour, two hours, five hours, etc. Subsequently, in step 712, if the sensor control device 102 still does not receive a fault condition indication, then in step 712, the sensor control device 102 will also stop allowing data backfilling after a second predetermined time period. In some embodiments, for example, the second predetermined time period may be one of 24 hours, 48 ​​hours, etc. Then, in step 714, the sensor control device 102 enters a storage state or a termination state.

[0128] By allowing the sensor control device 102 to continue transmitting sensor fault conditions for a predetermined period of time, embodiments of this disclosure mitigate the risk of not receiving sensor fault alarms. Furthermore, although the above embodiments refer to the sensor control device 102 communicating with the reader device 120, those skilled in the art will recognize that indications of sensor fault conditions can also be transmitted between the sensor control device 102 and other types of mobile computing devices (e.g., wearable computing devices (e.g., smartwatches, smart glasses) or tablet computing devices).

[0129] Example Implementation of Data Merging in Analyte Monitoring System

[0130] An example implementation of a method for merging data received from one or more analyte monitoring systems will now be described. (As previously discussed...) Figure 1The described trusted computer system 180 (e.g., a cloud-based platform) can be configured to generate various reports based on analyte data and other information received from multiple reader devices 120 and sensor control devices 102. However, a large number and variety of reader devices and sensor control devices can introduce complexity and challenges to generating reports based on the received analyte data and other information. For example, a single user may have multiple reader devices and / or sensor control devices (either simultaneously or continuously over time), each of which may include different versions. This can lead to further complexity because there may be duplicate and / or overlapping datasets for each user. Therefore, having a method for merging data in the trusted computer system would be beneficial for generating reports.

[0131] Figure 8A This is a flowchart depicting an example implementation of a method 800 for merging user-associated data and generating one or more report metrics, wherein the data originates from multiple reader devices and multiple sensor control devices. According to one aspect of the implementation, method 800 may be implemented to merge analyte data to generate different types of report metrics used in various reports. In step 802, data is received from one or more reader devices 120 and combined for merging purposes. In step 804, the combined data is then deduplicated to remove historical data from multiple readers originating from the same sensor control device. According to one aspect of the implementation, the deduplication process may include (1) identifying or assigning a priority to each reader device from which analyte data is received, and (2) retaining data associated with the reader device having a higher priority in the presence of “duplicate” data. In some implementations, for example, newer reader devices (e.g., newer models with newer versions of software) are assigned a higher priority than older reader devices (e.g., older models with older versions of software). In some implementations, priority may be assigned by device type (e.g., smartphones with higher priority than dedicated readers).

[0132] Still referencing Figure 8A In step 806, it is determined whether one or more reporting metrics to be generated require parsing overlapping data. If not, then in step 808, a first type of reporting metric can be generated based on the deduplicated data without further processing. In some implementations, for example, the first type of reporting metric may include the average glucose level used in the report, such as a snapshot or monthly summary report (e.g., regarding...). Figure 5C and Figure 5D(As described). If it is determined that one or more report metrics to be generated require parsing overlapping data, then in step 810, a method for parsing the overlapping data regions is executed. See below for reference. Figure 8B An example implementation method for parsing overlapping data regions is described. Subsequently, in step 812, a second type of reporting metric is generated based on data that has been deduplicated and processed to parse overlapping data segments. In some implementations, for example, the second type of reporting metric may include a calculation of low glucose events used in the report, such as daily log reports (e.g., regarding...). Figure 5F (As described).

[0133] Figure 8B This is a flowchart describing an example implementation of a method 815 for parsing overlapping data regions of an analysis object. For example, this method can be implemented in step 810 of method 800, as per [reference to...]. Figure 8A As described. In step 817, the deduplicated data from each reader (generated by step 804 of method 800, as per...) Figure 8A The data described can be sorted from earliest to most recent. In step 819, based on the report metric to be generated, the deduplicated and sorted data are then isolated according to a predetermined time period. In some implementations, for example, if the report metric is a graph reflecting glucose values ​​on a specific date, the deduplicated and sorted data can be isolated for that specific date. Next, in step 821, contiguous sections of the deduplicated and sorted data for each reader device are isolated. According to one aspect of the implementation, non-contiguous data points can be discarded or ignored (e.g., not used) for the purpose of generating the report metric. In step 823, for each contiguous section of the deduplicated and sorted data of the reader device, it is determined whether there are any overlapping areas with other contiguous sections of the deduplicated and sorted data from other reader devices. In step 825, for each identified overlapping area, the deduplicated and sorted data from the reader device with higher priority is saved. In step 827, if it is determined that all contiguous sections have been analyzed according to the preceding steps, method 815 ends in step 829. Otherwise, method 815 then returns to step 823 to continue identifying and parsing any overlapping areas between consecutive portions of the deduplicated data and sorted data from different reader devices.

[0134] Figures 8C to 8E These are graphs (840, 850, 860) depicting the various stages of deduplication and sorting of data from multiple reader devices when data is processed according to method 815 for parsing overlapping data regions. First, refer to... Figure 8CGraph 840 depicts deduplicated and sorted data from three different reader devices: a first reader 841 (reflected by circular data points), a second reader 842 (reflected by diamond-shaped data points), and a third reader 843 (reflected by square data points). According to one aspect of graph 840, the data is depicted in step 821 of method 815 after the data has been deduplicated, sorted, and isolated to a predetermined time period. Figure 8C As can be seen in the graph, continuous data portions of each of the three reader devices (841, 842, and 843) have been identified, and three tracks are shown. According to another aspect of graph 840, discontinuous point 844 is not included in the three tracks.

[0135] Next reference Figure 8D The graph 850 depicts the data from readers 841, 842, and 843 in step 823 of method 815, wherein three overlapping regions between consecutive portions of the data have been identified: a first overlapping region 851 between all three consecutive portions of the data; a second overlapping region 852 between two consecutive portions of the data (from reader devices 842 and 843); and a third overlapping region 853 between two consecutive portions of the data (also from reader devices 842 and 843).

[0136] Figure 8E This is a graph 860 depicting the data at step 825 of method 815, where a single trajectory 861 indicates the merged, deduplicated, and sorted data from the three reader devices 841, 842, and 843 after the overlapping regions 851, 852, and 853 have been resolved by using the priority of each reader device. According to graph 860, the priority order from highest to lowest is: reader device 843, reader device 842, and reader device 841.

[0137] although Figure 8C , Figure 8D and Figure 8E Three consecutive data portions with three identified discrete overlapping regions are depicted; however, those skilled in the art will understand that fewer or more consecutive data portions (and non-consecutive data points) and overlapping regions are possible. For example, those skilled in the art will recognize that in the case where the user has only two reader devices, fewer consecutive data portions and overlapping regions (if any) may exist. Conversely, if the user has five reader devices, those skilled in the art will understand that five consecutive data portions with three or more overlapping regions may exist.

[0138] Exemplary implementation of sensor overload

[0139] An example implementation of the method for sensor overload will now be described. According to one aspect of the implementation, as mobile computing and wearable technologies continue to develop rapidly and become more prevalent, users are more likely to replace or upgrade their smartphones more frequently. Therefore, in the case of an analyte monitoring system, having a sensor overload method that allows users to continue using both the previously activated sensor control device and the new smartphone would be beneficial. Furthermore, ensuring that historical analyte data from the sensor control device can be backfilled into the new smartphone (and subsequently uploaded to a trusted computer system) in a user-friendly and secure manner would also be beneficial.

[0140] Figure 9A This is a flowchart depicting an example implementation of a method 900 for switching sensor control devices. According to one aspect of the implementation, method 900 can be implemented in an analyte monitoring system to allow a user to continue using a previously activated sensor control device and a new reader device (e.g., a smartphone). In step 902, a user interface application (e.g., a mobile software application or app) is installed on reader device 120 (e.g., the smartphone), which causes a new unique device identifier, or “device ID,” to be created and stored on reader device 120. In step 904, after the application is installed and launched, the user is prompted to enter their user credentials in order to log in to a trusted computer system 180 (e.g., a cloud-based platform or server). Figure 9D An example implementation of a GUI 988 for prompting a user to enter their user credentials is shown. According to one aspect of the implementation, the GUI 988 may include a username field 990, which may include a unique username or email address, and a masked or unmasked password field 992 to allow the user to enter their password.

[0141] Refer again Figure 9A In step 906, after the user credentials are entered into the application, a prompt is displayed asking the user to confirm logging into the trusted computer system 180. Figure 9E An example implementation of a GUI 994 for requesting user confirmation of login to a trusted computer system 180 is shown. According to one aspect of the implementation, the GUI 994 may also include warnings, such as... Figure 9E The warning shown indicates that confirming login will cause the user to log out from other reader devices (such as the user's old smartphone).

[0142] If the user confirms login, in step 908, the user's credentials are sent to the trusted computer system 180 and subsequently verified. Furthermore, according to some embodiments, the device ID may also be transferred from the reader device 120 to the trusted computer system 180 and stored in the non-transitory memory of the trusted computer system 180. According to some embodiments, for example, in response to receiving the device ID, the trusted computer system 180 may update the device ID field associated with the user record in the database.

[0143] After the trusted computer system 180 verifies the user credentials, in step 910, the application prompts the user to scan the activated sensor control device 102. According to one aspect of the implementation, the scan may include bringing the reader device 120 close to the sensor control device 102 and causing the reader device 120 to transmit one or more wireless interrogation signals according to a first wireless communication protocol. In some implementations, for example, the first wireless communication protocol may be a Near Field Communication (NFC) wireless communication protocol. However, those skilled in the art will recognize that other wireless communication protocols (e.g., infrared, UHF, 802.11x, etc.) may be implemented. Figure 9F An example implementation of a GUI 998 for prompting the user to scan an already activated sensor control device 102 is shown.

[0144] Still referencing Figure 9A In step 912, the scanning of the sensor control device 102 by the reader device 120 causes the sensor control device 102 to terminate the existing wireless communication link with the user's previous reader device (if one has been established). According to one aspect of the implementation, the existing wireless communication link may include a link established according to a second wireless communication protocol different from the first wireless communication protocol. In some implementations, for example, the second wireless communication protocol may be Bluetooth or Bluetooth Low Energy. Subsequently, the sensor control device 102 enters a "ready to pair" state, wherein the sensor control device 102 can be used to establish a wireless communication link with the reader device 120 according to the second wireless communication protocol.

[0145] In step 914, the reader device 120 initiates a pairing sequence with the sensor control device 102 via a second wireless communication protocol (e.g., Bluetooth or Bluetooth Low Energy). Subsequently, in step 916, the sensor control device 102 completes the pairing sequence with the reader device 120. In step 918, the sensor control device 102 may begin transmitting current glucose data to the reader device 120 according to the second wireless communication protocol. In some embodiments, for example, the current glucose data may be wirelessly transmitted to the reader device 120 at predetermined intervals (e.g., every minute, every two minutes, every five minutes).

[0146] Still referencing Figure 9A In step 920, the reader device 120 receives current glucose data from the sensor control device 102 and stores it in the non-temporary memory of the reader device 120. Furthermore, according to some embodiments, for backfilling purposes, the reader device 120 can request historical glucose data from the sensor control device 102. According to some embodiments, for example, the reader device 120 can request historical glucose data for the entire wearing period from the sensor control device 102, which is stored in the non-temporary memory of the sensor control device 102. In other embodiments, the reader device 120 can request historical glucose data for a specific predetermined time range (e.g., from day 3 to now, from day 5 to now, the last 3 days, the last 5 days, lifetime count > 0, etc.). Those skilled in the art will understand that other backfilling schemes can be implemented (e.g., regarding...). Figure 6A and Figure 6B (Those described), and entirely within the scope of this disclosure.

[0147] Once a request is received in step 922, sensor control device 102 can retrieve historical glucose data from non-transitory memory and transmit it to reader device 120. Conversely, in step 924, reader device 120 can store the received historical glucose data in non-transitory memory. Furthermore, according to some embodiments, reader device 120 can also display current and / or historical glucose data in an application (e.g., on a sensor results screen). In this respect, the new reader can display all available analyte data throughout the entire wearing period of the sensor control device. In some embodiments, reader device 120 can also transmit current and / or historical glucose data to trusted computer system 180. In step 926, the received glucose data can be stored in the non-transitory memory (e.g., a database) of trusted computer system 180. In some embodiments, the received glucose data can also be deduplicated before being stored in non-transitory memory.

[0148] Figure 9B This is a flowchart depicting another example implementation of a method 930 for switching sensor control devices, wherein method 930 includes a security check (“application-side check”) performed by a user interface application. Similar to... Figure 9AMethod 900 can be implemented in an analyte monitoring system to allow a user to continue using a previously activated sensor control device and a new reader device (e.g., a smartphone). In one aspect, method 930 includes a number of method steps that are the same as or similar to those described with respect to method 900. For example, steps 932, 934, 936, 948, 950, 952, 954, and 956 of method 930 are the same as or similar to steps 902, 904, 906, 918, 920, 922, 924, and 926 of method 900, respectively.

[0149] According to one aspect of the implementation, method 930 may include a security check performed by a user interface application installed on the reader device 120. Still referring to... Figure 9B In step 938, after the user has confirmed their login, the user's credentials are sent to the trusted computer system 180 and subsequently verified. Furthermore, according to some embodiments, the device ID may also be transferred from the reader device 120 to the trusted computer system 180 and stored in the non-transitory memory of the trusted computer system 180. According to some embodiments, for example, in response to receiving the device ID, the trusted computer system 180 may update the device ID field associated with the user record in the database. Furthermore, according to some embodiments, the trusted computer system 180 may retrieve the stored sensor serial number associated with the sensor control unit 102 and transfer the stored sensor serial number to the reader device 120.

[0150] After the trusted computer system 180 verifies the user credentials, in step 940, the application prompts the user to scan the activated sensor control device 102. According to one aspect of the implementation, the scan may include bringing the reader device 120 close to the sensor control device 102 and causing the reader device 120 to transmit one or more wireless interrogation signals according to a first wireless communication protocol. In some implementations, for example, the first wireless communication protocol may be a Near Field Communication (NFC) wireless communication protocol. However, those skilled in the art will recognize that other wireless communication protocols (e.g., infrared, UHF, 802.11x, etc.) may be implemented. Figure 9F An example implementation of a GUI 998 for prompting the user to scan an already activated sensor control device 102 is shown.

[0151] Still referencing Figure 9BIn step 942, the scanning of sensor control device 102 by reader device 120 may cause sensor control device 102 to transmit the serial number of sensor control unit to reader device 120. In step 944, the user interface application on reader device 120 then compares the serial number received from sensor control unit 102 with the serial number received from trusted computer system 180. If the serial numbers do not match, in step 945, the user interface application may output a message to the display of reader device 120 indicating that sensor control device 102 cannot be converted, and subsequently, method 930 ends. If the serial numbers match, a pairing process is initiated, wherein, in step 946, sensor control device 102 terminates the existing wireless communication link with the user's previous reader device (if one has been established). According to one aspect of the implementation, the existing wireless communication link may include a link established according to a second wireless communication protocol different from the first wireless communication protocol. In some implementations, for example, the second wireless communication protocol may be Bluetooth or Bluetooth Low Energy protocol. Subsequently, the sensor control device 102 enters a "pairing ready" state, whereby it can establish a wireless communication link with the reader device 120 according to a second wireless communication protocol. Then, the reader device 120 initiates and completes a pairing sequence with the sensor control device 102 via the second wireless communication protocol (e.g., Bluetooth or Bluetooth Low Energy). Still referring to... Figure 9B Method 930 then proceeds to steps 948 to 956, which are the same as or similar to steps 918 to 926 of method 900, as per [reference to...]. Figure 9A As described.

[0152] Next reference Figure 9C The flowchart depicts another example implementation of a method 960 for switching sensor control devices, wherein method 960 includes a security check (“patch-side check”) performed by sensor control device 102. Similar to... Figure 9A and Figure 9B Methods 900 and 930 can be implemented in an analyte monitoring system to allow the user to continue using previously activated sensor control devices and new reader devices (e.g., smartphones). In one aspect, method 960 also includes numerous method steps that are the same as or similar to those described with respect to method 900. For example, steps 962, 964, 966, 978, 980, 982, 984, and 986 of method 960 are the same as or similar to steps 902, 904, 906, 918, 920, 922, 924, and 926 of method 300, respectively.

[0153] According to one aspect of the implementation, method 960 may include a security check performed by sensor control device 102. Still referring to... Figure 9CIn step 968, after the user has confirmed their login, the user's credentials are sent to the trusted computer system 180 and subsequently verified. Furthermore, according to some embodiments, the device ID may also be transferred from the reader device 120 to the trusted computer system 180 and stored in the non-transitory memory of the trusted computer system 180. According to some embodiments, for example, in response to receiving the device ID, the trusted computer system 180 may update the device ID field associated with the user record in the database. Furthermore, according to some embodiments, the trusted computer system 180 may retrieve the stored account ID associated with the user and transfer the stored account ID to the reader device 120.

[0154] After the trusted computer system 180 verifies the user credentials, in step 970, the user interface application receives the account ID and generates a receiver ID based on the received account ID. In some embodiments, for example, the receiver ID may be a compressed or truncated version of the account ID. In other embodiments, the user interface application may use an algorithm such as a hash function to generate the receiver ID based on the account ID. In other embodiments, the receiver ID may be the account ID. Subsequently, or in parallel, the application prompts the user to scan the activated sensor control device 102. According to one aspect of the embodiment, scanning may include bringing the reader device 120 close to the sensor control device 102 and causing the reader device 120 to transmit one or more wireless interrogation signals according to a first wireless communication protocol. In some embodiments, for example, the first wireless communication protocol may be a near-field communication (NFC) wireless communication protocol. However, those skilled in the art will recognize that other wireless communication protocols (e.g., infrared, UHF, 802.11x, etc.) may be implemented. Figure 9F An example implementation of a GUI 998 for prompting the user to scan an already activated sensor control device 102 is shown.

[0155] Still referencing Figure 9CAccording to another aspect of the embodiment, in step 972, the scanning of the sensor control device 102 by the reader device 120 may cause the sensor control device 102 to prepare a pairing sequence with the reader device 120. Subsequently, in step 974, the reader device 120 may initiate a pairing sequence with the sensor control device 102 via a second wireless communication protocol (e.g., Bluetooth or Bluetooth Low Energy). According to some embodiments, the reader device 120 may also transmit a receiver ID to the sensor control device 102, either as part of executing the pairing sequence or shortly thereafter. In step 976, the sensor control device 102 then verifies that the receiver ID is authentic. In some embodiments, the sensor control device 102 may verify the received receiver ID by comparing the received receiver ID with a receiver ID stored in a non-transitory memory of the sensor control device 102. In other embodiments, a hash function stored in the non-transitory memory of the sensor control device 102 may be used to verify the received receiver ID. Those skilled in the art will understand that other methods for verifying the authenticity of a received receiver ID are possible and are fully within the scope of this disclosure.

[0156] According to one aspect of some implementations, if the sensor control device 102 cannot verify the receiver ID, the sensor control device 102 may transmit an indication to the reader device 120, which causes the user interface application to output a message indicating a sensor overload failure on the display of the reader device 120. In other implementations, if no indication is received from the sensor control device 102 that the receiver ID has been successfully verified within a predetermined time period, the user interface application may output a message indicating a sensor overload failure on the display of the reader device 120.

[0157] If the receiver ID is verified by sensor control device 102, sensor control device 102 can terminate the existing wireless communication link (e.g., Bluetooth or Bluetooth Low Energy link) with the user's previous reader device (if one has been established). Subsequently, sensor control device 102 can complete the pairing sequence with reader device 120, and then method 960 proceeds to 978 to 986, which are the same as or similar to steps 918 to 926 of method 900, as per [reference to previous steps]. Figure 9A As described.

[0158] Refer again Figure 9CAlthough the verification of the receiver ID is described in step 976, those skilled in the art will recognize that in some embodiments, the receiver ID may be verified earlier in step 972 as part of or in response to the reader device 120 scanning sensor control device 102. Similarly, although the termination of the existing wireless communication link is described with respect to step 976, those skilled in the art will recognize that in some embodiments, the termination of the existing wireless communication may occur earlier in step 972 as part of or in response to the reader device 120 scanning sensor control device 102.

[0159] Furthermore, although shown as different steps in different methods, those skilled in the art will recognize that both "application-side checks" and "patch-side checks" can be performed as part of a single sensor transition process. That is, according to some implementations, in a single sensor transition, the application can verify the serial number (e.g., regarding...) Figure 3B (as described in method 930), and the sensor control device 102 can verify the receiver ID (as per relevant information). Figure 9C (as described in method 960). Conversely, the sensor transition process can be implemented without using method 930 or 960.

[0160] According to some implementation methods Figure 9A , Figure 9B and Figure 9C Any of methods 900, 930, and / or 950 may terminate after the pairing step is completed and the sensor control device begins transmitting current glucose data to the new reader device (e.g., steps 918, 948, 978). That is, the step of requesting and transmitting historical (backfilling) glucose data may be optional.

[0161] Although a description of glucose measurement is provided Figure 9A , Figure 9B and Figure 9C Methods 900, 930, and 960 are described, but those skilled in the art will understand that sensor control device 102 can also be configured to measure other analytes (e.g., lactates, ketones, etc.). Furthermore, although methods 900, 930, and 960 describe certain method steps performed by reader device 120, those skilled in the art will understand that any or all of these method steps can be performed by other devices in the analyte monitoring system, such as a local computer system, a wearable computing device, or a drug delivery device.

[0162] Example implementation of checking sensors and replacing sensor system alarms

[0163] An example implementation of an autonomous sensor inspection and replacement sensor system alarm, along with related methods, will now be described. According to one aspect of the implementation, certain adverse conditions affecting the operation of the analyte sensor and sensor electronics can be detected by a sensor control device. For example, if it is determined that the average glucose level measurement over a predetermined time period is below an insertion failure threshold, an incorrectly inserted analyte sensor can be detected. However, due to its small form factor and limited power capacity, the sensor control device may not have sufficient alarm capability. Therefore, the sensor control device transmits an indication of adverse conditions to another device, such as a reader device (e.g., a smartphone), to warn the user that those conditions would be advantageous.

[0164] Figure 10A This is a flowchart illustrating an example implementation of a method 1000 for generating a sensor insertion failure system alarm (also known as a "check sensor" system alarm). In step 1002, a sensor insertion failure condition is detected by the sensor control device 102. In some implementations, for example, a sensor insertion failure condition can be detected when the average glucose value over a predetermined time period (e.g., average glucose values ​​over five minutes, eight minutes, 15 minutes, etc.) is below an insertion failure glucose level threshold. In step 1004, in response to the detection of the insertion failure condition, the sensor control device 102 stops glucose measurement. In step 1006, the sensor control device 102 generates a check sensor indicator and transmits it to the reader device 120 via a wireless communication circuit. Subsequently, as shown in steps 1012 and 1014, the sensor control device 102 continues to transmit the check sensor indicator until: (1) the indicator is received from the reader device 120 (step 1012); or (2) a predetermined waiting period has elapsed (step 1014), whichever occurs first.

[0165] According to another aspect of the embodiment, if a wireless communication link is established between the sensor control device 102 and the reader device 120, the reader device 120 will receive a check sensor indicator in step 1008. In response to receiving the check sensor indicator, the reader device 120 will display a check sensor system alarm in step 1010. Figures 10B to 10D This is an example implementation of a check sensor system alarm interface displayed on reader device 120. In some implementations, for example, the check sensor system alarm may be a notification box, banner, or pop-up window output to a smartphone display, such as... Figure 10B and Figure 10C Interfaces 1020 and 1025. In some embodiments, the check sensor alarm output can be shown on the display of the reader device 120, such as a blood glucose meter or a receiver device, for example... Figure 10DThe interface 1030. According to embodiments, the reader device 120 can also transmit the check sensor indicator reception back to the sensor control device 102. In some embodiments, for example, the check sensor indicator reception can be automatically generated and sent upon successful display of check sensor system alarms 1020, 1025, or 1030. In other embodiments, the check sensor indicator reception is generated and / or transmitted in response to predetermined user input (e.g., clearing the check sensor system alarm, pressing the "OK" confirmation button 1032, etc.).

[0166] Subsequently, in step 1011, the reader device 120 discards the sensor control device 102. According to one aspect of the implementation, for example, step 1011 may include one or more of the following: terminating the existing wireless communication link with the sensor control device 102; disconnecting from the sensor control device 102; revoking the authorization or digital certificate associated with the sensor control device 102; creating or modifying a record stored on the reader device 120 to indicate that the sensor control device 102 is in a stored state; or transmitting an update to the trusted computer system 180 to indicate that the sensor control device 102 is in a stored state.

[0167] Return to reference Figure 10A If the sensor control device 102 receives a check sensor indicator reception (in step 1012) or a predetermined waiting period has elapsed (in step 1014), then in step 1016, the sensor control device 102 stops transmitting the check sensor indicator. Subsequently, in step 1018, the sensor control device 102 enters a storage state, in which the sensor control device 102 does not perform glucose measurement, and the wireless communication circuit is disabled or switched to sleep mode. According to one aspect, while in the "storage state," the sensor control device 102 can be reactivated by the reader device 120.

[0168] Although a description of glucose measurement is provided Figure 10A Method 1000, however, will be understood by those skilled in the art that the sensor control device 102 can also be configured to measure other analytes (e.g., lactates, ketones, etc.). Furthermore, although Figure 10A Method 1000 describes certain method steps performed by the reader device 120 (e.g., receiving a check sensor indicator, displaying a check sensor system alarm, and sending a check sensor indicator received), but those skilled in the art will understand that any or all of these method steps can be performed by other devices in the analyte monitoring system, such as a local computer system, a wearable computing device, or a drug delivery device. Those skilled in the art will also understand that... Figure 10A Method 1000 can be combined with any other method described herein, including but not limited to... Figure 7 Method 700 involves the transmission of expired and / or faulty sensors.

[0169] Figure 11A This is a flowchart depicting an example implementation of a method 1100 for generating a sensor termination system alarm (also known as a "replacement sensor" system alarm). In step 1102, a sensor termination condition is detected by the sensor control device 102. As previously described, the sensor termination condition may include, but is not limited to, one or more of the following: a detected FIFO overflow condition, a sensor signal below a predetermined insertion fault threshold, detected moisture ingress, an electrode voltage exceeding a predetermined diagnostic voltage threshold, an early signal attenuation (ESA) condition, or a late signal attenuation (LSA) condition, etc.

[0170] In step 1104, in response to the detection of a sensor termination condition, the sensor control device 102 stops performing glucose measurement. In step 1106, the sensor control device 102 generates a replacement sensor indicator and transmits it to the reader device 120 via a wireless communication circuit. Subsequently, in step 1112, the sensor control device 102 continues to transmit the replacement sensor indicator while determining whether a replacement sensor indicator has been received from the reader device 102. According to one aspect of the embodiment, the sensor control device 102 may continue to send the replacement sensor indicator until: (1) a predetermined waiting period has elapsed (step 1113), or (2) a replacement sensor indicator has been received (step 1112), and the sensor control device 102 has successfully transmitted the backfill data to the reader device 120 (steps 1116, 1120).

[0171] Still referencing Figure 11A If a wireless communication link is established between the sensor control device 102 and the reader device 120, the reader device 120 will receive a replacement sensor indicator in step 1108. In response to receiving the replacement sensor indicator, the reader device 120 will display a replacement sensor system alarm in step 1110. Figures 11B to 11D This is an example implementation of a replacement sensor system alert interface displayed on reader device 120. In some implementations, for example, the replacement sensor system alert may be a notification box, banner, or pop-up window output to a smartphone display, such as... Figure 11B and Figure 11C Interfaces 1130 and 1135. In some embodiments, the check sensor alarm output can be sent to a display on the reader device 120, such as a blood glucose meter or a receiver device, for example... Figure 11DThe interface 1140. According to an embodiment, to confirm receipt of the indicator, the reader device 120 may also transmit the replacement sensor indicator reception back to the sensor control device 102. In some embodiments, for example, a replacement sensor indicator reception may be automatically generated and sent upon successful display of a replacement sensor system alarm 1130, 1135, or 1140. In other embodiments, the replacement sensor indicator reception is generated and / or transmitted in response to predetermined user input (e.g., clearing the replacement sensor system alarm, pressing the "OK" confirmation button 1142, etc.).

[0172] In step 1114, after displaying a replacement sensor system alarm and transmitting a replacement sensor instruction received, the reader device 120 can then request historical glucose data from the sensor control device 102. In step 1116, the sensor control device 102 can collect the requested historical glucose data and send it to the reader device 120. According to one aspect of the embodiment, the steps of requesting, collecting, and transmitting historical glucose data may include a data backfilling routine, such as regarding... Figure 6A and Figure 6B The method described.

[0173] Refer again Figure 11A In response to receiving the requested historical glucose data, the reader device 120 may send the received historical glucose data reception to the sensor control device 102 in step 1118. Subsequently, in step 1119, the reader device 120 discards the sensor control device 102. According to one aspect of the implementation, for example, step 1119 may include one or more of the following: terminating the existing wireless communication link with the sensor control device 102; disconnecting from the sensor control device 102; revoking the authorization or digital certificate associated with the sensor control device 102; creating or modifying a record stored on the reader device 120 to indicate that the sensor control device 102 has been terminated; or transmitting an update to the trusted computer system 180 to indicate that the sensor control device 102 has been terminated.

[0174] In step 1120, the sensor control device 102 receives the received historical glucose data. Subsequently, in step 1122, the sensor control device 102 stops transmitting replacement sensor indicators, and in step 1124, the sensor control device 102 may enter a terminated state, in which the sensor control device 102 does not perform glucose measurements, and the wireless communication circuit is disabled or in sleep mode. According to one aspect of the embodiment, when in the terminated state, the sensor control device 102 cannot be reactivated by the reader device 120.

[0175] Although a description of glucose measurement is provided Figure 11AMethod 1100, however, will be understood by those skilled in the art that the sensor control device 102 can also be configured to measure other analytes (e.g., lactates, ketones, etc.). Furthermore, although Figure 11A Method 1100 describes certain method steps performed by the reader device 120 (e.g., receiving a replacement sensor indicator, displaying a replacement sensor system alarm, and sending a replacement sensor indicator received), but those skilled in the art will understand that any or all of these method steps can be performed by other devices in the analyte monitoring system, such as a local computer system, a wearable computing device, or a drug delivery device. Those skilled in the art will also understand that... Figure 11A Method 1100 may be combined with any other method described herein, including but not limited to Figure 7 Method 700 involves the transmission of expired and / or faulty sensors.

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

[0177] 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 coupled to sensor electronics, the sensor control device being configured to transmit data indicating analyte levels; as well as A reader device includes a display, wireless communication circuitry configured to receive data indicating the level of the analyte, and one or more processors coupled to a memory configured to store instructions that, when executed by the one or more processors, cause the one or more processors to output a sensor usage interface to the display, including one or more viewing metrics. The viewing metric includes the count of instances where the sensor results interface is presented or foreground processing is applied. The sensor user interface also includes a percentage time sensor activation metric, which indicates the percentage of a predetermined time period during which the reader device communicates with the sensor control device.

2. The analyte monitoring system of claim 1, wherein, The sensor user interface also includes one or more scan metrics. The scanning metric includes instances where a user scans the sensor control device using the reader device.

3. The analyte monitoring system of claim 1, wherein, One or more of the viewing metrics include a total number of viewing metrics, wherein the total number of viewing metrics indicates the total number of views within a predetermined time period.

4. The analyte monitoring system of claim 1, wherein, One or more of the viewing metrics include a daily viewing metric, wherein the daily viewing metric indicates the average number of views per day over a predetermined time period.

5. The analyte monitoring system of claim 1, wherein, The sensor user interface also includes a predetermined time period descriptor, wherein the predetermined time period descriptor indicates that one or more of the viewing metrics are measured during the predetermined time period.

6. The analyte monitoring system of claim 5, wherein, The scheduled time period is one week.

7. The analyte monitoring system of claim 5, wherein, The predetermined time period is a date range.

8. The analyte monitoring system of claim 5, wherein, The scheduled time period is relative to the current day.

9. The analyte monitoring system of claim 1, wherein, When the instruction is executed by the one or more processors, it further causes the one or more processors to output an analyte monitoring system report interface to the display. The analytical substance monitoring system reporting interface includes the sensor user interface.

10. The analyte monitoring system of claim 9, wherein, The analyte monitoring system reporting interface also includes a glucose trend interface, which includes a glucose trend graph, a low glucose event graph, and a glucose management indicator metric.

11. The analyte monitoring system of claim 9, wherein, The analyte monitoring system reporting interface also includes a health information interface, which includes daily carbohydrate intake measurements and drug dosage measurements.

12. The analyte monitoring system of claim 9, wherein, The analyte monitoring system reporting interface also includes an annotation interface, which includes information about the user's analyte and drug patterns presented in a narrative format.

13. The analyte monitoring system of claim 9, wherein, One or more of the viewing metrics include a percentage-time sensor activation graph and an average scan and view metric, wherein the average scan and view metric indicates the average sum of the number of scans and the number of views.

14. The analyte monitoring system according to claim 13, wherein, The axis of the percentage time sensor activation graph is aligned with the corresponding axis of one or more of the glucose trend graphs or low glucose event graphs.

15. An analyte monitoring system, comprising: A sensor control device includes an analyte sensor coupled to sensor electronics, the sensor control device being configured to transmit data indicating analyte levels; as well as A reader device includes a display, wireless communication circuitry configured to receive data indicating the analyte level, and one or more processors coupled to a memory configured to store instructions that, when executed by the one or more processors, cause the one or more processors to output an analyte monitoring report to the display, including a calendar interface comprising multiple days, wherein each day includes an average glucose measurement, one or more low glucose event icons, a sensor usage measurement, and a percentage-time sensor activation measurement, and wherein the sensor usage measurement indicates the sum of the number of scans and views per day. The number of views indicates the count of instances where the sensor results interface was presented or brought into foreground processing. The percentage time sensor activation metric indicates the percentage of a predetermined time period during which the reader device communicates with the sensor control device.

16. An analyte monitoring system, comprising: A sensor control device includes an analyte sensor coupled to sensor electronics, the sensor control device being configured to transmit data indicating analyte levels; as well as A reader device includes a display, wireless communication circuitry configured to receive data indicating the level of the analyte, and one or more processors coupled to a memory configured to store instructions that, when executed by the one or more processors, cause the one or more processors to output a weekly summary report to the display, comprising multiple report sections, each representing a different day of the week, and each report section including a glucose trend graph with one or more sensor usage markers and a percentage-time sensor activation metric. Each sensor uses a marker to indicate the count of instances in which the sensor results interface was presented or brought into foreground processing. The percentage time sensor activation metric indicates the percentage of a predetermined time period during which the reader device communicates with the sensor control device.

Images