FIELD
The subject matter described herein relates generally to improvements to analyte monitoring systems, as well as computer-related methods and devices relating thereto.
BACKGROUND
The detection and/or monitoring of analyte levels, such as glucose, ketones, lactate, oxygen, hemoglobin A1C, or the like, can be vitally important to the health of an individual having diabetes. Patients suffering from diabetes mellitus can experience complications including loss of consciousness, cardiovascular disease, retinopathy, neuropathy, and nephropathy. Diabetics are generally required to monitor their glucose levels to ensure that they are being maintained within a clinically safe range, and may also use this information to determine if and/or when insulin is needed to reduce glucose levels in their bodies, or when additional glucose is needed to raise the level of glucose in their bodies.
Growing clinical data demonstrates a strong correlation between the frequency of glucose monitoring and glycemic control. Despite such correlation, however, many individuals diagnosed with a diabetic condition do not monitor their glucose levels as frequently as they should due to a combination of factors including convenience, testing discretion, pain associated with glucose testing, and cost.
To increase patient adherence to a plan of frequent glucose monitoring, in vivo analyte monitoring systems can be utilized, in which a sensor control device may be worn on the body of an individual who requires analyte monitoring. To increase comfort and convenience for the individual, the sensor control device may have a small form-factor and can be applied by the individual with a sensor applicator. The application process includes inserting at least a portion of a sensor that senses a user's analyte level in a bodily fluid located in a layer of the human body, using an applicator or insertion mechanism, such that the sensor comes into contact with a bodily fluid. The sensor control device may also be configured to transmit analyte data to another device, from which the individual, her health care provider (“HCP”), or a caregiver can review the data and make therapy decisions.
Despite their advantages, however, some people are reluctant to use analyte monitoring systems for various reasons, including the complexity and volume of data presented, a learning curve associated with the software and user interfaces for analyte monitoring systems, and an overall paucity of actionable information presented.
Thus, needs exist for improved digital interfaces, graphical user interfaces, and software for analyte monitoring systems, as well as methods and devices relating thereto, that are robust, user-friendly, and provide for timely and actionable responses.
SUMMARY
Provided herein are example embodiments of improvements to in vivo analyte monitoring systems, and computer-related methods and devices relating thereto. According to some embodiments, a Time-in-Ranges (“TIR”) GUI of an analyte monitoring system is provided, wherein the TIR GUI comprises a plurality of bars or bar portions, wherein each bar or bar portion indicates an amount of time that a user's analyte level is within a predefined analyte range correlating with the bar or bar portion. In some embodiments, for example, the amount of time can be expressed as a percentage of total time.
According to another embodiment, an Analyte Level/Trend Alert GUI of an analyte monitoring system is provided, wherein the Analyte Level/Trend Alert GUI comprises a visual notification (e.g., alert, alarm, pop-up window, banner notification, etc.), wherein the visual notification includes an alarm condition, an analyte level measurement associated with the alarm condition, and a trend indicator associated with the alarm condition. In some embodiments, for example, the trend indicator comprises a directional trend arrow.
According to some embodiments, a sensor usage interface is provided for measuring and promoting user engagement with an analyte monitoring system. The sensor usage interface can comprise one or more view metrics, wherein a view metric comprises an instance in which a sensor results interface is rendered or brought into a foreground process. In some embodiments, the sensor usage interface can be a portion of an analyte monitoring system report, such as, for example, a monthly summary report, a weekly summary report, or a daily log report.
According to other embodiments, methods for data backfilling in an analyte monitoring system are provided. In some embodiments, a method for data backfilling can be implemented in an analyte monitoring system comprising a first device and a second device in communication with each other. According to one aspect of the method, the second device can request historical analyte data from the first device according to a lifecount metric, wherein the lifecount metric comprises a numeric value indicative of an amount of time elapsed since the activation of the first device. In another embodiment, a method for data backfilling is provided wherein a reader device can determine a last successful transmission of data to a trusted computer system, and transmit historical data not yet received by the trusted computer system in response to a reconnection event.
According to another embodiment, a method for collecting disconnection and reconnection events for wireless communication links in an analyte monitoring system is provided, wherein the disconnection and reconnection events are logged and sent to a trusted computer system for analysis.
According to other embodiments, a method for improved expired or failed sensor transmissions is provided. In some embodiments, an expired or failed sensor condition is detected by a sensor control device. Subsequently, an indication of the expired or failed sensor condition is transmitted by a sensor control device until a first predetermined time period has elapsed, or until a receipt of the indication of the expired or failed sensor condition is received, whichever occurs first. In some embodiments, the sensor control device also allows for data backfilling during a second predetermined time period.
According to another embodiment, methods for merging analyte data from multiple devices is provided. In some embodiments, a method is provided wherein analyte data from a plurality of reader devices is received, combined, and de-duplicated. Subsequently, a first type of report metric can be generated based on the combined and de-duplicated analyte data. According to another aspect of the embodiments, the analyte data can be further analyzed to resolve any overlapping regions of de-duplicated analyte data. Subsequently, a second type of report metric can be generated based on the de-duplicated and non-overlapping analyte data. In some embodiments, for example, the first report metric can comprise average glucose levels and the second report metric can comprise low glucose events.
According to some embodiments, systems and methods for transitioning a previously activated sensor control device to a new reader device are provided. In some embodiments, for example, a method is provided wherein a user interface application is installed on a user's new reader device, causing a device identifier to be generated. Subsequently, the user can login to a trusted computer system, wherein a device identifier associated with the user's user account is updated. According to an 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 a connection with an old reader device to be terminated. Subsequently, the new reader device and the previously activated sensor control device can 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 for the full duration of the wear.
In some embodiments, the systems and methods for transitioning a previously activated sensor control device to a new reader device can include a security check performed by the reader device, wherein the user interface application on the reader device compares a sensor serial number received from the trusted computer system with a sensor serial number received from the sensor control device. In some embodiments, the systems and methods for transitioning a previously activated sensor control device to a new reader device can 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.
According to other embodiments, methods for generating a sensor insertion failure system alarm are provided. In some embodiments, a method is provided wherein a sensor insertion failure condition is detected by a sensor control device. In response, the sensor control device stops taking analyte measurements and transmits a check sensor indicator to a reader device until either a predetermined waiting period has elapsed, or a check sensor indicator receipt is received from the reader device, whichever occurs first. Subsequently, the sensor control device enters a storage state, in which it can be later re-activated.
According to other embodiments, methods for generating a sensor termination system alarm are provided. In some embodiments, a method is provided wherein a sensor termination condition is detected by a sensor control device. In response, the sensor control device stops taking analyte measurements and transmits a replace sensor indicator to a reader device until either a predetermined waiting period has elapsed, or a replace sensor indicator receipt is received from the reader device, whichever occurs first. In some embodiments, after receiving the replace sensor indicator receipt, the sensor control device can also provide historical glucose data in response to data backfilling requests from the reader device. Subsequently, the sensor control device enters a termination state, in which it cannot be later re-activated.
Many of the embodiments provided herein are improved GUIs or GUI features for analyte monitoring systems that are highly intuitive, user-friendly, and provide for rapid access to physiological information of a user. More specifically, these embodiments allow a user to easily navigate through and between different user interfaces that can quickly indicate to the user various physiological conditions and/or actionable responses, without requiring the user (or an HCP) to go through the arduous task of examining large volumes of analyte data. Furthermore, some of the GUIs and GUI features, such as the sensor usage interfaces, allow for users (and their caregivers) to better understand and improve their respective levels of engagement with their analyte monitoring systems. Likewise, many other embodiments provided herein comprise improved digital interfaces and/or features for analyte monitoring systems that improve upon: the accuracy and integrity of the analyte data being collected by the analyte monitoring system by allowing for data backfilling, flexibility of the analyte monitoring system by allowing users to transition between different reader devices, alarming functionality of the analyte monitoring system by providing for more robust inter-device communications during certain adverse conditions, to name only a few.
The improvements to the GUIs in the various aspects described and claimed herein produce a technical effect at least in that they assist the user of the device to operate the device more accurately, more efficiently and more safely. It will be appreciated that the information that is provided to the user on the GUI, the order in which that information is provided and the clarity with which that information is structured can have a significant effect on the way the user interacts with the system and the way the system operates. The GUI therefore guides the user in the technical task of operating the system to take the necessary readings and/or obtain information accurately and efficiently. Other improvements and advantages are provided as well. The various configurations of these devices are described in detail by way of the embodiments which are only examples.
Other systems, devices, methods, features and advantages of the subject matter described herein will be or will become apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, devices, methods, features, and advantages be included within this description, be within the scope of the subject matter described herein, and be protected by the accompanying claims. Aspects of the embodiments are set out in the independent claims and preferred features are set out in the dependent claims. The 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 conjunction with other aspects. In no way should the features of the example embodiments be construed as limiting the appended claims, absent express recitation of those features in the claims.
BRIEF DESCRIPTION OF THE FIGURES
The details of the subject matter set forth herein, both as to its structure and operation, may be apparent by study of the accompanying figures, in which like reference numerals refer to like parts. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the subject matter. Moreover, all illustrations are intended to convey concepts, where relative sizes, shapes and other detailed attributes may be illustrated schematically rather than literally or precisely.
FIG. 1 is a system overview of an analyte monitoring system comprising a sensor applicator, a sensor control device, a reader device, a network, a trusted computer system, and a local computer system.
FIG. 2A is a block diagram depicting an example embodiment of a reader device.
FIGS. 2B and 2C are block diagrams depicting example embodiments of sensor control devices.
FIGS. 2D to 2I are example embodiments of GUIs comprising sensor results interfaces.
FIGS. 3A to 3F are example embodiments of GUIs comprising time-in-ranges interfaces.
FIGS. 4A to 4O are example embodiments of GUIs comprising analyte level and trend alert interfaces.
FIGS. 5A and 5B are example embodiments of GUIs comprising sensor usage interfaces.
FIGS. 5C to 5F are example embodiments of report GUIs including sensor usage information.
FIGS. 6A and 6B are flow diagrams depicting example embodiments of methods for data backfilling in an analyte monitoring system.
FIG. 6C is a flow diagram depicting an example embodiment of a method for aggregating disconnect and reconnect events in an analyte monitoring system.
FIG. 7 is a flow diagram depicting an example embodiment of a method for failed or expired sensor transmissions in an analyte monitoring system.
FIGS. 8A and 8B are flow diagrams depicting example embodiments of methods for data merging in an analyte monitoring system.
FIGS. 8C to 8E are graphs depicting data at various stages of processing according to an example embodiment of a method for data merging in an analyte monitoring system.
FIGS. 9A to 9C are flow diagrams depicting example embodiments of methods for sensor transitioning in an analyte monitoring system.
FIGS. 9D to 9F are example embodiments of GUIs to be displayed according to an example embodiment of a method for sensor transitioning in an analyte monitoring system.
FIG. 10A is a flow diagram depicting an example embodiment of a method for generating a sensor insertion failure system alarm.
FIGS. 10B to 10D are example embodiments of GUIs to be displayed according to an example embodiment of a method for generating a sensor insertion failure system alarm.
FIG. 11A is a flow diagram depicting an example embodiment of a method for generating a sensor termination system alarm.
FIGS. 11B to 11D are example embodiments of GUIs to be displayed according to an example embodiment of a method for generating a sensor termination system alarm.
In addition, attached hereto as Appendix A, and incorporated by reference for all purposes, are color versions of the figures.
DETAILED DESCRIPTION
Before the present subject matter is described in detail, it is to be understood that this disclosure is not limited to the particular embodiments described, as such may, of course, vary. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting, since the scope of the present disclosure will be limited only by the appended claims.
As used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise.
The publications discussed herein are provided solely for their disclosure prior to the filing date of the present application. Nothing herein is to be construed as an admission that the present disclosure is not entitled to antedate such publication by virtue of prior disclosure. Further, the dates of publication provided may be different from the actual publication dates which may need to be independently confirmed.
Generally, embodiments of the present disclosure include GUIs, software, and digital interfaces for analyte monitoring systems, and methods and devices relating thereto. Accordingly, many embodiments include in vivo analyte sensors structurally configured so that at least a portion of the sensor is, or can be, positioned in the body of a user to obtain information about at least one analyte of the body. It should be noted, however, that the embodiments disclosed herein can be used with in vivo analyte monitoring systems that incorporate in vitro capability, as well as purely in vitro or ex vivo analyte monitoring systems, including systems that are entirely non-invasive.
Furthermore, for each and every embodiment of a method disclosed herein, systems and devices capable of performing each of those embodiments are covered within the scope of the present disclosure. For example, embodiments of sensor control devices, reader devices, local computer systems, and trusted computer systems are disclosed, and these devices and systems can have one or more sensors, analyte monitoring circuits (e.g., an analog circuit), memories (e.g., for storing instructions), power sources, communication circuits, transmitters, receivers, processors and/or controllers (e.g., for executing instructions) that can perform any and all method steps or facilitate the execution of any and all method steps.
Improved graphical user and digital interfaces for analyte monitoring systems are provided. For example, disclosed herein are various embodiments of GUIs including Time-in-Ranges, Analyte Level/Trend Alert, and sensor usage interfaces. In addition, various embodiments of digital interfaces are described, including methods for data backfilling, expired or failed sensor transmissions, merging data from multiple devices in an analyte monitoring system, transitioning a previously activated analyte sensor to a new reader device, and autonomous sensor system alarms, among other embodiments.
As previously described, a number of embodiments described herein provide for improved GUIs for analyte monitoring systems, wherein the GUIs are highly intuitive, user-friendly, and provide for rapid access to physiological information of a user. According to some embodiments, a Time-in-Ranges GUI of an analyte monitoring system is provided, wherein the Time-in-Ranges GUI comprises a plurality of bars or bar portions, wherein each bar or bar portion indicates an amount of time that a user's analyte level is within a predefined analyte range correlating with the bar or bar portion. According to another embodiment, an Analyte Level/Trend Alert GUI of an analyte monitoring system is provided, wherein the Analyte Level/Trend Alert GUI comprises a visual notification (e.g., alert, alarm, pop-up window, banner notification, etc.), and wherein the visual notification includes an alarm condition, an analyte level measurement associated with the alarm condition, and a trend indicator associated with the alarm condition. In sum, these embodiments provide for a robust, user-friendly interfaces that can increase user engagement with the analyte monitoring system and provide for timely and actionable responses by the user, to name a few advantages.
In addition, a number of embodiments described herein provide for improved digital interfaces for analyte monitoring systems. According to some embodiments, improved methods, as well as systems and device relating thereto, are provided for data backfilling, aggregation of disconnection and reconnection events for wireless communication links, expired or failed sensor transmissions, merging data from multiple devices, transitioning of previously activated sensors to new reader devices, generating sensor insertion failure system alarms, and generating sensor termination system alarms. Collectively and individually, these digital interfaces improve upon the accuracy and integrity of analyte data being collected by the analyte monitoring system, the flexibility of the analyte monitoring system by allowing users to transition between different reader devices, and the alarming capabilities of the analyte monitoring system by providing for more robust inter-device communications during certain adverse conditions, to name only a few. Other improvements and advantages are provided as well. The various configurations of these devices are described in detail by way of the embodiments which are only examples.
Before describing these aspects of the embodiments in detail, however, it is first desirable to describe examples of devices that can be present within, for example, an in vivo analyte monitoring system, as well as examples of their operation, all of which can be used with the embodiments described herein.
There are various types of in vivo analyte monitoring systems. “Continuous Analyte Monitoring” systems (or “Continuous Glucose Monitoring” systems), for example, can transmit data from a sensor control device to a reader device continuously without prompting, e.g., automatically according to a schedule. “Flash Analyte Monitoring” systems (or “Flash Glucose Monitoring” systems or simply “Flash” systems), as another example, can transfer data from a sensor control device in response to a scan or request for data by a reader device, such as with a Near Field Communication (NFC) or Radio Frequency Identification (RFID) protocol. In vivo analyte monitoring systems can also operate without the need for finger stick calibration.
In vivo analyte monitoring systems can be differentiated from “in vitro” systems that contact a biological sample outside of the body (or “ex vivo”) and that typically include a meter device that has a port for receiving an analyte test strip carrying bodily fluid of the user, which can be analyzed to determine the user's blood sugar level.
In vivo monitoring systems can include a sensor that, while positioned in vivo, makes contact with the bodily fluid of the user and senses the analyte levels contained therein. The sensor can be part of the sensor control device that resides on the body of the user and contains the electronics and power supply that enable and control the analyte sensing. The sensor control device, and variations thereof, can also be referred to as a “sensor control unit,” an “on-body electronics” device or unit, an “on-body” device or unit, or a “sensor data communication” device or unit, to name a few.
In vivo monitoring systems can also include a device that receives sensed analyte data from the sensor control device and processes and/or displays that sensed analyte data, in any number of forms, to the user. This device, and variations thereof, can be referred to as a “handheld reader device,” “reader device” (or simply a “reader”), “handheld electronics” (or simply a “handheld”), a “portable data processing” device or unit, a “data receiver,” a “receiver” device or unit (or simply a “receiver”), or a “remote” device or unit, to name a few. Other devices such as personal computers have also been utilized with or incorporated into in vivo and in vitro monitoring systems.
Example Embodiment of In Vivo Analyte Monitoring System
FIG. 1 is a conceptual diagram depicting an example embodiment of an analyte monitoring system 100 that includes a sensor applicator 150, a sensor control device 102, and a reader device 120. Here, sensor applicator 150 can be used to deliver sensor control device 102 to a monitoring location on a user's skin where a sensor 104 is maintained in position for a period of time by an adhesive patch 105. Sensor control device 102 is further described in FIGS. 2B and 2C, and can communicate with reader device 120 via a communication path 140 using a wired or wireless technique. Example wireless protocols include Bluetooth, Bluetooth Low Energy (BLE, BTLE, Bluetooth SMART, etc.), Near Field Communication (NFC) and others. Users can view and use applications installed in memory on reader device 120 using screen 122 (which, in many embodiments, can comprise a touchscreen), and input 121. A device battery of reader device 120 can be recharged using power port 123. While only one reader device 120 is shown, sensor control device 102 can communicate with multiple reader devices 120. Each of the reader devices 120 can communicate and share data with one another. More details about reader device 120 is set forth with respect to FIG. 2A below. Reader device 120 can communicate with local computer system 170 via a communication path 141 using a wired or wireless communication protocol. Local computer system 170 can include one or more of a laptop, desktop, tablet, phablet, smartphone, set-top box, video game console, or other computing device and wireless communication can include any of a number of applicable wireless networking protocols including Bluetooth, Bluetooth Low Energy (BTLE), Wi-Fi or others. Local computer system 170 can communicate via communications path 143 with a network 190 similar to how reader device 120 can communicate via a communications path 142 with network 190, by a wired or wireless communication protocol as described previously. Network 190 can be any of a number of networks, such as private networks and public networks, local area or wide area networks, and so forth. A trusted computer system 180 can include a cloud-based platform or server, and can provide for authentication services, secured data storage, report generation, and can communicate via communications path 144 with network 190 by wired or wireless technique. In addition, although FIG. 1 depicts trusted computer system 180 and local computer system 170 communicating with a single sensor control device 102 and a single reader device 120, it will be appreciated by those of skill in the art that local computer system 170 and/or trusted computer system 180 are each capable of being in wired or wireless communication with a plurality of reader devices and sensor control devices.
Example Embodiment of Reader Device
FIG. 2A is a block diagram depicting an example embodiment of a reader device 120, which, in some embodiments, can comprise a smart phone. Here, reader device 120 can include a display 122, input component 121, and a processing core 206 including a communications processor 222 coupled with memory 223 and an applications processor 224 coupled with memory 225. Also included can be separate memory 230, RF transceiver 228 with antenna 229, and power supply 226 with power management module 238. Further, reader device 120 can also include a multi-functional transceiver 232, which can comprise wireless communication circuitry, and which can be configured to communicate over Wi-Fi, NFC, Bluetooth, BTLE, and GPS with an antenna 234. As understood by one of skill in the art, these components are electrically and communicatively coupled in a manner to make a functional device.
Example Embodiments of Sensor Control Devices
FIGS. 2B and 2C are block diagrams depicting example embodiments of sensor control devices 102 having analyte sensors 104 and sensor electronics 160 (including analyte monitoring circuitry) that can have the majority of the processing capability for rendering end-result data suitable for display to the user. In FIG. 2B, a single semiconductor chip 161 is depicted that can be a custom application specific integrated circuit (ASIC). Shown within ASIC 161 are certain high-level functional units, including an analog front end (AFE) 162, power management (or control) circuitry 164, processor 166, and communication circuitry 168 (which can be implemented as a transmitter, receiver, transceiver, passive circuit, or otherwise according to the communication protocol). In this embodiment, both AFE 162 and processor 166 are used as analyte monitoring circuitry, but in other embodiments either circuit can perform the analyte monitoring function. Processor 166 can include one or more processors, microprocessors, controllers, and/or microcontrollers, each of which can be a discrete chip or distributed amongst (and a portion of) a number of different chips.
A memory 163 is also included within ASIC 161 and can be shared by the various functional units present within ASIC 161, or can be distributed amongst 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 with power source 170, which can be a coin cell battery, or the like. AFE 162 interfaces with in vivo analyte sensor 104 and receives measurement data therefrom and outputs the data to processor 166 in digital form, which in turn processes the data to arrive at the end-result glucose discrete and trend values, etc. This data can then be provided to communication circuitry 168 for sending, by way of antenna 171, to reader device 120 (not shown), for example, where minimal further processing is needed by the resident software application to display the data. According to some embodiments, for example, a current glucose value can be transmitted from sensor control device 102 to reader device 120 every minute, and historical glucose values can be transmitted from sensor control device 102 to reader device 120 every five minutes.
In some embodiments, to conserve power and processing resources on sensor control device 102, digital data received from AFE 162 can be sent to reader device 120 (not shown) with minimal or no processing. In still other embodiments, processor 166 can be configured to generate certain predetermined data types (e.g., current glucose value, historical glucose values) either for storage in memory 163 or transmission to reader device 120 (not shown), and to ascertain certain alarm conditions (e.g., sensor fault conditions), while other processing and alarm functions (e.g., high/low glucose threshold alarms) can be performed on reader device 120. Those of skill 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 sensor control device 102, reader device 120, local computer system 170, or trusted computer system 180.
FIG. 2C is similar to FIG. 2B but instead includes two discrete semiconductor chips 162 and 174, which can be packaged together or separately. Here, AFE 162 is resident 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 and chip 174 includes memory 165, which can be isolated or distributed within. In one example embodiment, AFE 162 is combined with power management circuitry 164 and processor 166 on one chip, while communication circuitry 168 is on a separate chip. In another example embodiment, both AFE 162 and communication circuitry 168 are on one chip, and 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 bearing responsibility for the separate functions described, or sharing one or more functions for fail-safe redundancy.
Example Embodiments of Graphical User Interfaces for Analyte Monitoring Systems
Described herein are example embodiments of GUIs for analyte monitoring systems. As an initial matter, it will be understood by those of skill in the art that the GUIs described herein comprise instructions stored in a 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 in communication with, analyte monitoring system 100. These instructions, when executed by one or more processors of the reader device 120, local computer system 170, trusted computer system 180, or other device or system of analyte monitoring system 100, cause the one or more processors to perform the method steps and/or output the GUIs described herein. Those of skill in the art will further recognize that the GUIs described herein can be stored as instructions in the memory of a single centralized device or, in the alternative, can be distributed across multiple discrete devices in geographically dispersed locations.
Example Embodiments of Sensor Results Interfaces
FIGS. 2D to 2I depict example embodiments of sensor results interfaces or GUIs for analyte monitoring systems. According to one aspect of the embodiments, the sensor results GUIs described herein are configured to display analyte data and other health information through a user interface application (e.g., software) installed on a reader device, such as a smart phone or a receiver, like those described with respect to FIG. 2B. Those of skill in the art will also appreciate that a user interface application with a sensor results interface or GUI can also be implemented on a local computer system or other computing device (e.g., wearable computing devices, smart watches, tablet computer, etc.).
Referring first to FIG. 2D, sensor results GUI 235 depicts an interface comprising a first portion 236 that can include a numeric representation of a current analyte concentration value (e.g., a current glucose value), a directional arrow to indicate an analyte trend direction, and a text description to provide contextual information such as, for example, whether the user's analyte level is in range (e.g., “Glucose in Range”). First portion 236 can also comprise a color or shade that is indicative of an analyte concentration or trend. For example, as shown in FIG. 2D, first portion 236 is a green shade, indicating that the user's analyte level is within a target range. According to some embodiments, for example, a red shade can indicate an analyte level below a low analyte level threshold, an orange shade can indicate an analyte level above a high analyte level threshold, and a yellow shade can indicate an analyte level outside a target range. In addition, according to some embodiments, sensor results GUI 235 also includes a second portion 237 comprising a graphical representation of analyte data. In particular, second portion 237 includes an analyte trend graph reflecting an analyte concentration, as shown by the y-axis, over a predetermined time period, as shown by the x-axis. In some embodiments, the predetermined time period can be shown in five-minute increments, with a total of twelve hours of data. Those of skill in the art will appreciate, however, that other time increments and durations of analyte data can be utilized and are fully within the scope of the present disclosure. Second portion 237 can also include a point 239 on the analyte trend graph to indicate the current analyte concentration value, a shaded green area 240 to indicate a target analyte range, and two dotted lines 238a and 238b to indicate, respectively, a high analyte threshold and a low analyte threshold. According to some embodiments, GUI 235 can also include a third portion 241 comprising a graphical indicator and textual information representative of a remaining amount of sensor life.
Referring next to FIG. 2E, another example embodiment of a sensor results GUI 245 is depicted. According to one aspect of the embodiments, first portion 236 is shown in a yellow shade to indicate that the user's current analyte concentration is not within a target range. In addition, second portion 237 includes: an analyte trend line 241 which can 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).
According to another aspect of the embodiments, data on sensor results GUI 245 is automatically updated or refreshed according to an update interval (e.g., every second, every minute, every 5 minutes, etc.). For example, according to many of the embodiments, as analyte data is received by the reader device, sensor results GUI 245 will update: (1) the current analyte concentration value shown in first portion 236, and (2) the analyte trend line 241 and current analyte data point 239 show in second portion 237. Furthermore, in some embodiments, the automatically updating analyte data can cause older historical analyte data (e.g., in the left portion of analyte trend line 241) to no longer be displayed.
FIG. 2F is another example embodiment of a sensor results GUI 250. According to the depicted embodiment, sensor results GUI 250 includes first portion 236 which is shown in an orange shade to indicate that the user's analyte levels are above a high glucose threshold (e.g., greater than 250 mg/dL). Sensor results GUI 250 also depicts health information icons 251, such as an exercise icon or an apple icon, to reflect user logged entries indicating the times when the user had exercised or eaten a meal.
FIG. 2G is another example embodiment of a sensor results GUI 255. According to the depicted embodiments, sensor results GUI 255 includes first portion 236 which is also shown in an orange shade to indicate that the user's analyte levels are above a high glucose threshold. As can be seen in FIG. 2G, first portion 236 does not report a numeric value but instead displays the text “HI” to indicate that the current analyte concentration value is outside a glucose reporting range high limit. Although not depicted in FIG. 2G, those of skill in the art will understand that, conversely, an analyte concentration below a glucose reporting range low limit will cause first portion 236 not to display a numeric value, but instead, the text “LO”.
FIG. 2H is another example embodiment of a sensor results GUI 260. According to the depicted embodiments, sensor results GUI 260 includes first portion 236 which is shown in a green shade to indicate that the user's current analyte level is within the target range. In addition, according to the depicted embodiments, first portion 236 of GUI 260 includes the text, “GLUCOSE GOING LOW,” which can indicate to the user that his or her analyte concentration value is predicted to drop below a predicted low analyte level threshold within a predetermined amount of time (e.g., predicted glucose will fall below 75 mg/dL within 15 minutes). Those of skill in the art will understand that if a user's analyte level is predicted to rise above a predicted high analyte level threshold within a predetermined amount of time, sensor results GUI 260 can display a “GLUCOSE GOING HIGH” message.
FIG. 2I is another example embodiment of a sensor results GUI 265. According to the depicted embodiments, sensor results GUI 265 depicts first portion 236 when there is a sensor error. According to one aspect of the embodiments, first portion 236 includes three dashed lines 266 in place of the current analyte concentration value to indicate that a current analyte value is not available. In some embodiments, three dashed lines 266 can indicate one or more error conditions such as, for example, (1) a no signal condition; (2) a signal loss condition; (3) sensor too hot/cold condition; or (4) a glucose level unavailable condition. Furthermore, as can be seen in FIG. 2I, first portion 236 comprises a gray shading (instead of green, yellow, orange, or red) to indicate that no current analyte data is available. In addition, according to another aspect of the embodiments, second portion 237 can be configured to display the historical analyte data in the analyte trend graph, even though there is an error condition preventing the display of a numeric value for a current analyte concentration in first portion 236. However, as shown in FIG. 2I, no current analyte concentration value data point is shown on the analyte trend graph of second portion 237.
Example Embodiments of Time-in-Ranges Interfaces
FIGS. 3A to 3F depict example embodiments of GUIs for analyte monitoring systems. In particular, FIGS. 3A to 3F depict Time-in-Ranges (also referred to as Time-in-Range and/or Time-in-Target) GUIs, each of which comprise a plurality of bars or bar portions, wherein each bar or bar portion indicates an amount of time that a user's analyte level is within a predefined analyte range correlating with the bar or bar portion. In some embodiments, for example, the amount of time can be expressed as a percentage of a predefined amount of time.
Turning to FIGS. 3A and 3B, an example embodiment of a Time-in-Ranges GUI 305 is shown, wherein Time-in-Ranges GUI 305 comprises a “Custom” Time-in-Ranges view 305A and a “Standard” Time-in-Ranges view 305B, with a slidable element 310 that allows the user to select between the two views. According to one aspect of the embodiments, Time-in-Ranges views 305A, 305B can each comprise multiple bars, wherein each bar indicates an amount of time that a user's analyte level is within a predefined analyte range correlating with the bar. In some embodiments, Time-in-Ranges views 305A, 305B further comprise a date range indicator 308, showing relevant dates associated with the displayed plurality of bars, and a data availability indicator 314, showing the period(s) of time in which analyte data is available for the displayed analyte data (e.g., “Data available for 7 of 7 days”).
Referring to FIG. 3A, “Custom” Time-in-Ranges view 305A includes six bars comprising (from top to bottom): a first bar indicating that the user's glucose range is above 250 mg/dL for 10% of a predefined amount of time, a second bar indicating that the user's glucose range is between 141 and 250 mg/dL for 24% of the predefined amount of time, a third bar 316 indicating that the user's glucose range is between 100 and 140 mg/dL for 54% of the predefined amount of time, a fourth bar indicating that the user's glucose range is between 70 and 99 mg/dL for 9% of the predefined amount of time, a fifth bar indicating that the user's glucose range is between 54 and 69 mg/dL for 2% of the predefined amount of time, and a sixth bar indicating that the user's glucose range is less than 54 mg/dL for 1% of the predefined amount of time. Those of skill in the art will recognize that the glucose ranges and percentages of time associated with each bar can vary depending on the ranges defined by the user and the available analyte data of the user. Furthermore, although FIGS. 3A and 3B show a predefined amount of time 314 equal to seven days, those of skill in the art will appreciate that other predefined amounts of time can be utilized (e.g., one day, three days, fourteen days, thirty days, ninety days, etc.), and are fully within the scope of the present disclosure.
According to another aspect of the embodiments, “Custom” Time-in-Ranges view 305A also includes a user-definable custom target range 312 that includes an actionable “edit” link that allows a user to define and/or change the custom target range. As shown in “Custom” Time-in-Ranges view 305A, the custom target range 312 has been defined as a glucose range between 100 and 140 mg/dL and corresponds with third bar 316 of the plurality of bars. Those of skill in the art will also appreciate that, in other embodiments, more than one range can be adjustable by the user, and such embodiments are fully within the scope of the present disclosure.
Referring to FIG. 3B, “Standard” Time-in-Ranges view 305B includes five bars comprising (from top to bottom): a first bar indicating that the user's glucose range is above 250 mg/dL for 10% of a predefined amount of time, a second bar indicating that the user's glucose range is between 181 and 250 mg/dL for 24% of the predefined amount of time, a third bar indicating that the user's glucose range is between 70 and 180 mg/dL for 54% of the predefined amount of time, a fourth bar indicating that the user's glucose range is between 54 and 69 mg/dL for 10% of the predefined amount of time, and a fifth bar indicating that the user's glucose range is less than 54 mg/dL for 2% of the predefined amount of time. As with the “Custom” Time-in-Ranges view 305A, those of skill in the art will recognize that the percentages of time associated with each bar can vary depending on the available analyte data of the user. Unlike the “Custom” Time-in-Ranges view 305A, however, the glucose ranges shown in “Standard” view 305B cannot be adjusted by the user.
FIGS. 3C and 3D depict another example embodiment of Time-in-Ranges GUI 320 with multiple views, 320A and 320B, which are analogous to the views shown in FIGS. 3A and 3B, respectively. According to some embodiments, Time-in-Ranges GUI 320 can further include one or more selectable icons 322 (e.g., radio button, check box, slider, switch, etc.) that allow a user to select a predefined amount of time over which the user's analyte data will be shown in the Time-in-Range GUI 320. For example, as shown in FIGS. 3C and 3D, selectable icons 322 can be used to select a predefined amount of time of seven days, fourteen days, thirty days, or ninety days. Those of skill in the art will appreciate that other predefined amounts of time can be utilized and are fully within the scope of the present disclosure.
FIG. 3E depicts an example embodiment of a Time-in-Target GUI 330, which can be visually output to a display of a reader device (e.g., a dedicated reader device, a meter device, etc.). According to one aspect of the embodiments, Time-in-Target GUI 330 includes three bars comprising (from top to bottom): a first bar indicating that the user's glucose range is above a predefined target range for 34% of a predefined amount of time, a second bar indicating that the user's glucose range is within the predefined target range for 54% of the predefined amount of time, and a third bar indicating that the user's glucose range is below the predefined target range for 12% of the predefined amount of time. Those of skill in the art will recognize that the percentages of time associated with each bar can vary depending on the available analyte data of the user. Furthermore, although FIG. 3E shows a predefined amount of time 332 equal to the last seven days and a predefined target range 334 of 80 to 140 mg/dL, those of skill in the art will appreciate that other predefined amounts of time (e.g., one day, three days, fourteen days, thirty days, ninety days, etc.) and/or predefined target ranges (e.g., 70 to 180 mg/dL) can be utilized, and are fully within the scope of the present disclosure.
FIG. 3F depicts another example embodiment of a Time-in-Ranges GUI 340, which includes a single bar comprising five bar portions including (from top to bottom): a first bar portion indicating that the user's glucose range is “Very High” or above 250 mg/dL for 1% (14 minutes) of a predefined amount of time, a second bar portion 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 predefined amount of time, a third bar portion indicating that the user's glucose range is within a “Target Range” or between 70 and 180 mg/dL for 78% (18 hours and 43 minutes) of the predefined amount of time, a fourth bar portion indicating that the user's glucose range is “Low” or between 54 and 69 mg/dL for 3% (43 minutes) of the predefined amount of time, and a fifth bar portion indicating that the user's glucose range is “Very Low” or less than 54 mg/dL for 0% (0 minutes) of the predefined amount of time. As shown in FIG. 3F, according to some embodiments, Time-in-Ranges GUI 340 can display text adjacent to each bar portion indicating an actual amount of time, e.g., in hours and/or minutes.
According to one aspect of the embodiment shown in FIG. 3F, each bar portion of Time-in-Ranges GUI 340 can comprise a different color. In some embodiments, bar portions can be separated by dashed or dotted lines 342 and/or interlineated with numeric markers 344 to indicate the ranges reflected by the adjacent bar portions. In some embodiments, the time in ranges reflected by the bar portions can be further expressed as a percentage, an actual amount of time (e.g., 4 hours and 19 minutes), or, as shown in FIG. 3F, both. Furthermore, those of skill in the art will recognize that the percentages of time associated with each bar portion can vary depending on the analyte data of the user. In some embodiments of Time-in-Ranges GUI 340, the Target Range can be configured by the user. In other embodiments, the Target Range of Time-in-Ranges GUI 340 is not modifiable by the user.
Example Embodiments of Analyte Level and Trend Alert Interfaces
FIGS. 4A to 4O depict example embodiments of Analyte Level/Trend Alert GUIs for analyte monitoring systems. According to one aspect of the embodiments, the Analyte Level/Trend Alert GUIs comprise a visual notification (e.g., alert, alarm, pop-up window, banner notification, etc.), wherein the visual notification includes an alarm condition, an analyte level measurement associated with the alarm condition, and a trend indicator associated with the alarm condition.
Turning to FIGS. 4A to 4C, example embodiments of a High Glucose Alarm 410, Low Glucose Alarm 420, and a Serious Low Glucose Alarms 430 are depicted, respectively, wherein each alarm comprises a pop-up window 402 containing an alarm condition text 404 (e.g., “Low Glucose Alarm”), an analyte level measurement 406 (e.g., a current glucose level of 67 mg/dL) associated with the alarm condition, and a trend indicator 408 (e.g., a trend arrow or directional arrow) associated with the alarm condition. In some embodiments, an alarm icon 412 can be adjacent to the alarm condition text 404.
Referring next to FIGS. 4D to 4G, additional example embodiments of Low Glucose Alarms 440, 445, Serious Low Glucose Alarm 450, and High Glucose Alarm 455 are depicted, respectively. As shown in FIG. 4D, Low Glucose Alarm 440 is similar to the Low Glucose Alarm of FIG. 4B (e.g., comprises a pop-up window containing an alarm condition text, an analyte level measurement associated with the alarm condition, and a trend indicator associated with the alarm condition), but further includes a critical alert icon 442 to indicate that the alarm has been configured as a critical alert (e.g., will display, play a sound, vibrate, even if the device is locked or if the device's “Do Not Disturb” setting has been enabled). With respect to FIG. 4E, Low Glucose Alarm 445 is also similar to the Low Glucose Alarm of FIG. 4B, but instead of including a trend arrow, Log Glucose Alarm 445 includes a textual trend indicator 447. According to one aspect of some embodiments, textual trend indicator 447 can be enabled through a device's Accessibility settings such that the device will “read” the textual trend indicator 447 to the user via the device's text-to-speech feature (e.g., Voiceover for iOS or Select-to-Speak for Android).
Referring next to FIG. 4F, Low Glucose Alarm 450 is similar to the Low Glucose Alarm of FIG. 4D (including the critical alert icon), but instead of displaying an analyte level measurement associated with an alarm condition and a trend indicator associated with the alarm condition, Low Glucose Alarm 450 displays a out-of-range indicator 452 to indicate that the current glucose level is either above or below a predetermined reportable analyte level range (e.g., “HI” or “LO”). With respect to FIG. 4G, High Glucose Alarm 455 is similar to the High Glucose Alarm of FIG. 4A (e.g., comprises a pop-up window containing an alarm condition text, an analyte level measurement associated with the alarm condition, and a trend indicator associated with the alarm condition), but further includes an instruction to the user 457. In some embodiments, for example, the instruction can be a prompt for the user to “Check blood glucose.” Those of skill in the art will appreciate that other instructions or prompts can be implemented (e.g., administer a corrective bolus, eat a meal, etc.).
Furthermore, although FIGS. 4A to 4G depict example embodiments of Analyte Level/Trend Alert GUIs that are displayed on smart phones having an iOS operating system, those of skill in the art will also appreciate that the Analyte Level/Trend Alert GUIs can be implemented on other devices including, e.g., smart phones with other operating systems, smart watches, wearables, reader devices, tablet computing devices, blood glucose meters, laptops, desktops, and workstations, to name a few. FIGS. 4H to 4J, for example, depict example embodiments of a High Glucose Alarm, Low Glucose Alarm, and a Serious Low Glucose Alarm for a smart phone having an Android Operating System. Similarly, FIGS. 4K to 4O depict, respectively, example embodiments of a Serious Low Glucose Alarm, Low Glucose Alarm, High Glucose Alarm, Serious Low Glucose Alarm (with a Check Blood Glucose icon), and High Glucose Alarm (with an out-of-range indicator) for a reader device.
Example Embodiments of Sensor Usage Interfaces
FIGS. 5A to 5F depict example embodiments of sensor usage interfaces relating to GUIs for analyte monitoring systems. According to one aspect of the embodiments, sensor usage interfaces provide for technological improvements including the capability to quantify and promote user engagement with analyte monitoring systems. According to some embodiments, for example, a sensor usage interface can include the visual display of one or more “view” metrics, each of which can be indicative of a measure of user engagement with the analyte monitoring system. A “view” can comprise, for example, an instance in which a sensor results interface is rendered or brought into the foreground. In some embodiments, a sensor user interface can include a visual display of a “scan” metric indicative of another measure of user engagement with the analyte monitoring system. A “scan” can comprise, for example, an instance in which a user uses a reader device (e.g., smart phone, dedicated reader, etc.) to scan a sensor control device, such as, for example, in a Flash Analyte Monitoring system.
FIGS. 5A and 5B depict example embodiments of sensor usage interfaces 500 and 510, respectively. According to one aspect of the embodiments, sensor usage interfaces 500 and 510 can be rendered and displayed, for example, by a mobile app or software residing in non-transitory memory of reader device 120, such as those described with respect to FIGS. 1 and 2A. Referring to FIG. 5A, sensor user interface 500 can comprise: a predetermined time period interval 508 indicative of a time period (e.g., a date range) during which view metrics are measured, a Total Views metric 502, which is indicative of a total number of views over the predetermined time period 508; a Views Per Day metric 504, which is indicative of an average number of views per day over the predetermined time period 508; and a Percentage Time Sensor Active metric 506, which is indicative of the percentage of predetermined time period 508 that reader device 120 is in communication with sensor control device 102, such as those described with respect to FIGS. 1, 2B, and 2C. Referring to FIG. 5B, sensor user interface 510 can comprise a Views per Day metric 504 and a Percentage Time Sensor Active metric 508, each of which is measured for predetermined time period 508.
According to another aspect of the embodiments, although predetermined time period 508 is shown as one week, those of skill in the art will recognize that other predetermined time periods (e.g., 3 days, 14 days, 30 days) can be utilized. In addition, predetermined time period 508 can be a discrete period of time—with a start date and an end date—as shown in sensor usage interface 500 of FIG. 5A, or can be a time period relative to a current day or time (e.g., “Last 7 Days,” “Last 14 Days,” etc.), as shown in sensor usage interface 510 of FIG. 5B.
FIG. 5C depicts an example embodiment of sensor usage interface 525, as part of analyte monitoring system report GUI 515. According to one aspect of the embodiments, GUI 515 is a snapshot report covering a predetermined time period 516 (e.g., 14 days), and comprising a plurality of report portions on a single report GUI, including: a sensor usage interface portion 525, a glucose trend interface 517, which can include an glucose trend graph, a low glucose events graph, and other related glucose metrics (e.g., Glucose Management Indicator); a health information interface 518, which can include information logged by the user about the user's average daily carbohydrate intake and medication dosages (e.g., insulin dosages); and a comments interface 519, which can include additional information about the user's analyte and medication patterns presented in a narrative format. According to another aspect of the embodiments, sensor usage interface 525 can comprise a Percentage Time Sensor Active metric 526, an Average Scans/Views metric 527 (e.g., indicative of an average sum of a number of scans and a number of views), and a Percentage Time Sensor Active graph 528. As can be seen in FIG. 5C, an axis of the Percentage Time Sensor Active graph can be aligned with a corresponding axis of one or more other graphs (e.g., average glucose trend graph, low glucose events graph), such that the user can visually correlate data between multiple graphs from two or more portions of the report GUI by the common units (e.g., time of day) from the aligned axes.
FIG. 5D depicts an example embodiment of another analyte monitoring system report GUI 530 including sensor usage information. According to one aspect of the embodiments, GUI 530 is a monthly summary report including a first portion comprising a legend 531, wherein legend 531 includes a plurality of graphical icons each of which is adjacent to a descriptive text. As shown in FIG. 5D, legend 531 includes an icon and descriptive text for “Average Glucose,” an icon and descriptive text for “Scans/Views,” and an icon and descriptive text for “Low Glucose Events.” GUI 530 also includes a second portion comprising a calendar interface 532. For example, as shown in FIG. 5D, GUI 530 comprises a monthly calendar interface, wherein each day of the month can include one or more of an average glucose metric, low glucose event icons, and a sensor usage metric 532. In some embodiments, such as the one shown in FIG. 5D, the sensor usage metric (“scans/views”) is indicative of a total sum of a number of scans and a number of views for each day.
FIG. 5E depicts an example embodiment of another analyte monitoring system report GUI 540 including sensor usage information. According to one aspect of the embodiments, GUI 540 is a weekly summary report including a plurality of report portions, wherein each report portion is representative of a different day of the week, and wherein each report portion comprises a glucose trend graph 541, which can include the user's measured glucose levels over a twenty-four hour period, and a health information interface 543, which can include information about the user's average daily glucose, carbohydrate intake, and/or insulin dosages. In some embodiments, glucose trend graph 541 can include sensor usage markers 542 to indicate that a scan, a view, or both had occurred at a particular time during the twenty-four hour period.
FIG. 5F depicts an example embodiment of another analyte monitoring system report GUI 550 including sensor usage information. According to one aspect of the embodiments, GUI 550 is a daily log report comprising a glucose trend graph 551, which can include the user's glucose levels over a twenty-four hour period. In some embodiments, glucose trend graph 551 can include sensor usage markers 552 to indicate that a scan, a view, or both had occurred at a particular time during the twenty-four hour period. Glucose trend graph 551 can also include logged event markers, such as logged carbohydrate intake markers 553 and logged insulin dosage markers 554, as well as glucose event markers, such as low glucose event markers 555.
It will be understood by those of skill in the art that any of the GUIs, reports interfaces, or portions thereof, as described herein, are meant to be illustrative only, and that the individual elements, or any combination of elements, depicted and/or described for a particular embodiment or figure are freely combinable with any elements, or any combination of elements, depicted and/or described with respect to any of the other embodiments.
Example Embodiments of Digital Interfaces for Analyte Monitoring Systems
Described herein are example embodiments of digital interfaces for analyte monitoring systems. According to one aspect of the embodiments, a digital interface can comprise a series of instructions, routines, subroutines, and/or algorithms, such as software and/or firmware stored in a non-transitory memory, executed by one or more processors of one or more devices in an analyte monitoring system, wherein the instructions, routines, subroutines, or algorithms are configured to enable certain functions and inter-device communications. As an initial matter, it will be understood by those of skill in the art that the digital interfaces described herein can comprise instructions stored in a non-transitory memory of a 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 in communication with, analyte monitoring system 100, as described with respect to FIGS. 1, 2A, and 2B. These instructions, when 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 analyte monitoring system 100, cause the one or more processors to perform the method steps described herein. Those of skill in the art will further recognize that the digital interfaces described herein can be stored as instructions in the memory of a single centralized device or, in the alternative, can be distributed across multiple discrete devices in geographically dispersed locations.
Example Embodiments of Methods for Data Backfilling
Example embodiments of methods for data backfilling in an analyte monitoring system will now be described. According to one aspect of the embodiments, gaps in analyte data and other information can result from interruptions to communication links between various devices in an analyte monitoring system 100. These interruptions can occur, for example, from a device being powered off (e.g., a user's smart phone runs out of battery), or a first device temporarily moving out of a wireless communication range from a second device (e.g., a user wearing sensor control device 102 inadvertently leaves her smart phone at home when she goes to work). As a result of these interruptions, reader device 120 may not receive analyte data and other information from sensor control device 102. It would thus be beneficial to have a robust and flexible method for data backfilling in an analyte monitoring system to ensure that once a communication link is re-established, each analyte monitoring device can receive a complete set of data, as intended.
FIG. 6A is a flow diagram depicting an example embodiment of a method 600 for data backfilling in an analyte monitoring system. According to one aspect of the embodiments, method 600 can be implemented to provide data backfilling between a sensor control device 102 and a reader device 120. At Step 602, analyte data and other information is autonomously communicated between a first device and a second device at a predetermined interval. In some embodiments, the first device can be a sensor control device 102, and the second device can be a reader device 120, as described with respect to FIGS. 1, 2A, and 2B. According to one aspect of the embodiments, analyte data and other information can include, but is not limited to, one or more of: data indicative of an analyte level in a bodily fluid, a rate-of-change of an analyte level, a predicted analyte level, a low or a high analyte level alert condition, a sensor fault condition, or a communication link event. According to another aspect of the embodiments, autonomous communications at a predetermined interval can comprise streaming analyte data and other information according to a standard wireless communication network protocol, such as a Bluetooth or Bluetooth Low Energy protocol, at one or more predetermined rates (e.g., every minute, every five minutes, every fifteen minutes, etc.). In some embodiments, different types of analyte data or other information can be autonomously communicated between the first and second devices at different predetermined rates (e.g., historical glucose data every 5 minutes, current glucose value every minute, etc.).
At Step 604, a disconnection event or condition occurs that causes an interruption to the communication link between the first device and the second device. As described above, the disconnection event can result from the second device (e.g., reader device 120, smart phone, etc.) running out of battery power or being powered off manually by a user. A disconnection event can also result from the first device being moved outside a wireless communication range of the second device, from the presence of a physical barrier that obstructs the first device and/or the second device, or from anything that otherwise prevents wireless communications from occurring between the first and second devices.
At Step 606, the communication link is re-established between the first device and the second device (e.g., the first device comes back into the wireless communication range of the second device). Upon reconnection, the second device requests historical analyte data according to a last lifecount metric for which data was received. According to one aspect of the embodiments, the lifecount metric can be a numeric value that is incremented and tracked on the second device in units of time (e.g., minutes), and is indicative of an amount of time elapsed since the sensor control device was activated. For example, in some embodiments, after the second device (e.g., reader device 120, smart phone, etc.) re-establishes a Bluetooth wireless communication link with the first device (e.g., sensor control device 120), the second device can determine the last lifecount metric for which data was received. Then, according to some embodiments, the second device can send to the first device a request for historical analyte data and other information having a lifecount metric greater than the determined last lifecount metric for which data was received.
In some embodiments, the second device can send a request to the first device for historical analyte data or other information associated with a specific lifecount range, instead of requesting historical analyte data associated with a lifecount metric greater than a determined last lifecount metric for which data was received.
At Step 608, upon receiving the request, the first device retrieves the requested historical analyte data from storage (e.g., non-transitory memory of sensor control device 102), and subsequently transmits the requested historical analyte data to the second device at Step 610. At Step 612, upon receiving the requested historical analyte data, the second device stores the requested historical analyte data in storage (e.g., non-transitory memory of reader device 120). According to one aspect of the embodiments, when the requested historical analyte data is stored by the second device, it can be stored along with the associated lifecount metric. In some embodiments, the second device can also output the requested historical analyte data to a display of the second device, such as, for example to a glucose trend graph of a sensor results GUI, such as those described with respect to FIGS. 2D to 2I. For example, in some embodiments, 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.
Furthermore, those of skill in the art will appreciate that the method of data backfilling can be implemented between multiple and various devices in an analyte monitoring system, wherein the devices are in wired or wireless communication with each other.
FIG. 6B is a flow diagram depicting another example embodiment of a method 620 for data backfilling in an analyte monitoring system. According to one aspect of the embodiments, method 620 can be implemented to provide data backfilling between a reader device 120 (e.g., smart phone, dedicated reader) and a trusted computer system 180, such as, for example, a cloud-based platform for generating reports. At Step 622, analyte data and other information is communicated between reader device 120 and trusted computer system 180 based on a plurality of upload triggers. According to one aspect of the embodiments, analyte data and other information can include, but are not limited to, one or more of: data indicative of an analyte level in a bodily fluid (e.g., current glucose level, historical glucose data), a rate-of-change of an analyte level, a predicted analyte level, a low or a high analyte level alert condition, information logged by the user, information relating to sensor control device 102, alarm information (e.g., alarm settings), wireless connection events, and reader device settings, to name a few.
According to another aspect of the embodiments, the plurality of upload triggers can include (but is not limited to) one or more of the following: activation of sensor control device 102; user entry or deletion of a note or log entry; a wireless communication link (e.g., Bluetooth) reestablished between reader device 120 and sensor control device 102; alarm threshold changed; alarm presentation, update, or dismissal; internet connection re-established; reader device 120 restarted; a receipt of one or more current glucose readings from sensor control device 102; sensor control device 120 terminated; signal loss alarm presentation, update, or dismissal; signal loss alarm is toggled on/off; view of sensor results screen GUI; or user sign-in into cloud-based platform.
According to another aspect of the embodiments, in order to track the transmission and receipt of data between devices, reader device 120 can “mark” analyte data and other information that is to be transmitted to trusted computer system 180. In some embodiments, for example, upon receipt of the analyte data and other information, trusted computer system 180 can send a return response to reader device 120, to acknowledge that the analyte data and other information has been successfully received. Subsequently, reader device 120 can mark the data as successfully sent. In some embodiments, the analyte data and other information can be marked by reader device 120 both prior to being sent and after receipt of the return response. In other embodiments, the analyte data and other information can be marked by reader device 120 only after receipt of the return response from trusted computer system 180.
Referring to FIG. 6B, at Step 624, a disconnection event occurs that causes an interruption to the communication link between reader device 120 and trusted computer system 180. For example, the disconnection event can result from the user placing the reader device 120 into “airplane mode” (e.g., disabling of the wireless communication modules), from the user powering off the reader device 120, or from the reader device 120 moving outside of a wireless communication range.
At Step 626, the communication link between reader device 120 and trusted computer system 180 (as well as the internet) is re-established, which is one of the plurality of upload triggers. Subsequently, reader device 120 determines the last successful transmission of data to trusted computer system 180 based on the previously marked analyte data and other information sent. Then, at Step 628, reader device 120 can transmit analyte data and other information not yet received by trusted computer system 180. At Step 630, reader device 120 receives acknowledgement of successful receipt of analyte data and other information from trusted computer system 180.
Although FIG. 6B is described above with respect to a reader in communication with a trusted computer system, those of skill in the art will appreciate 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 embodiments, along with their variations and permutations, are fully within the scope of the present disclosure.
In addition to data backfilling, example embodiments of methods for aggregating disconnect and reconnect events for wireless communication links in an analyte monitoring system are described. According to one aspect of the embodiments, there can be numerous and wide-ranging causes for interruptions to wireless communication links between various devices in an analyte monitoring system. Some causes can be technical in nature (e.g., a reader device is outside a sensor control device's wireless communication range), while other causes can relate to user behavior (e.g., a user leaving his or her reader device at home). In order to improve connectivity and data integrity in analyte monitoring systems, it would therefore be beneficial to gather information regarding the disconnect and reconnect events between various devices in an analyte monitoring system.
FIG. 6C is a flow diagram depicting an example embodiment of a method 640 for aggregating disconnect and reconnect events for wireless communication links in an analyte monitoring system. In some embodiments, for example, method 640 can be used to detect, log, and upload to trusted computer system 180, Bluetooth or Bluetooth Low Energy disconnect and reconnect events between a sensor control device 102 and a reader device 120. According to one aspect of the embodiments, trusted computer system 180 can aggregate disconnect and reconnect events transmitted from a plurality of analyte monitoring systems. The aggregated data can then by analyzed to determine whether any conclusions can be made about how to improve connectivity and data integrity in analyte monitoring systems.
At Step 642, analyte data and other information are communicated between reader device 120 and trusted computer system 180 based on a plurality of upload triggers, such as those previously described with respect to method 620 of FIG. 6B. At Step 644, a disconnection event occurs that causes an interruption to the wireless communication link between sensor control device 102 and reader device 120. Example disconnection events can include, but are not limited to, a user placing the reader device 120 into “airplane mode,” the user powering off the reader device 120, the reader device 120 running out of power, the sensor control device 102 moving outside a wireless communication range of the reader devices 120, or a physical barrier obstructing the sensor control device 102 and/or the reader device 120, to name only a few.
Referring still to FIG. 6C, at Step 646, the wireless communication link between the sensor control device 102 and reader device 120 is re-established, which is one of the plurality of upload triggers. Subsequently, reader device 120 determines a disconnect time and a reconnect time, wherein the disconnect time is the time that the interruption to the wireless communication link began, and the reconnect time is the time that the wireless communication link between the sensor control device 102 and reader device 120 is re-established. According to some embodiments, the disconnection and reconnection times can also be stored locally in an event log on reader device 120. At Step 648, reader device 120 transmits the disconnect and reconnect times to trusted computer system 180.
According to some embodiments, the disconnect and reconnect times can be stored in non-transitory memory of trusted computer system 180, such as in a database, and aggregated with the disconnect and reconnect times collected from other analyte monitoring systems. In some embodiments, the disconnect and reconnect times can also be transmitted to and stored on a different cloud-based platform or server from trusted computer system 180 that stores analyte data. In still other embodiments, the disconnect and reconnect times can be anonymized.
In addition, those of skill in the art will recognize that method 640 can be utilized to collect disconnect and reconnect 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 a wearable computing device (e.g., smart watch, smart glasses); between reader device 120 and a medication delivery device (e.g., insulin pump, insulin pen); between sensor control device 102 and a wearable computing device; between sensor control device 102 and a medication delivery device; and any other combination of devices within an analyte monitoring system. Those of skill in the art will further appreciate that method 640 can be utilized to analyze disconnect and reconnect times for different wireless communication protocols, such as, for example, Bluetooth or Bluetooth Low Energy, NFC, 802.11x, UHF, cellular connectivity, or any other standard or proprietary wireless communication protocol.
Example Embodiments of Improved Expired/Failed Sensor Transmissions
Example embodiments of methods for improved expired and/or failed sensor transmissions in an analyte monitoring system will now be described. According to one aspect of the embodiments, expired or failed sensor conditions detected by a sensor control device 102 can trigger critical alerts on reader device 120. However, if the reader device 120 is in “airplane mode,” powered off, outside a wireless communication range of sensor control device 102, or otherwise unable to wirelessly communicate with the sensor control device 102, then the reader device 120 may not receive these important alerts. This can cause the user to miss important information such as, for example, the need to promptly replace a sensor control device 102. Failure to take action on a detected sensor fault can also lead to the user being unaware of adverse glucose conditions (e.g., hypoglycemia and/or hyperglycemia) due to a terminated sensor.
FIG. 7 is a flow diagram depicting an example embodiment of a method 700 for improved expired or failed sensor transmissions in an analyte monitoring system. According to one aspect of the embodiments, method 700 can be implemented to provide for improved sensor transmissions by a sensor control device 102 after an expired or failed sensor condition has been detected. At Step 702, an expired or failed sensor condition is detected by sensor control device 102. In some embodiments, the sensor fault condition can comprise one or both of a sensor insertion failure condition or a sensor termination condition. According to some embodiments, for example, a sensor insertion failure condition or a sensor termination condition can include, but is not limited to, one or more of the following: a FIFO overflow condition detected, a sensor signal below a predetermined insertion failure threshold, moisture ingress detected, an electrode voltage exceeding a predetermined diagnostic voltage threshold, an early signal attenuation (ESA) condition, or a late signal attenuation (LSA) condition, to name a few.
Referring again to FIG. 7, at Step 704, sensor control device 102 stops acquiring measurements of analyte levels from the analyte sensor in response to the detection of the sensor fault condition. At Step 706, sensor control device 102 begins transmitting an indication of a sensor fault condition to reader device 120, while also allowing for the reader device 120 to connect to the sensor control device 102 for purposes of data backfilling. According to one aspect of the embodiments, the transmission of the indication of the sensor fault condition can comprise transmitting a plurality of Bluetooth or Bluetooth Low Energy advertising packets, each of which can include the indication of the sensor fault condition. In some embodiments, the plurality of Bluetooth or BLE advertising packets can be transmitted repeatedly, continuously, or intermittently. Those of skill in the art will recognize that other modes of wirelessly broadcasting or multicasting the indication of the sensor fault condition can be implemented. According to another aspect of the embodiments, in response to receiving the indication of the sensor fault condition, reader device 120 can visually display an alert or prompt for a confirmation by the user.
At Step 708, sensor control device 102 can be configured to monitor for a return response or acknowledgment of receipt of the indication of the sensor fault condition from reader device 120. In some embodiments, for example, a return response or acknowledgement of receipt can be generated by reader device 120 when a user dismisses an alert on the reader device 120 relating to the indication of the sensor fault condition, or otherwise responds to a prompt for confirmation of the indication of the sensor fault condition. If a return response or acknowledgement of receipt of the indication of the sensor fault condition is received by sensor control device 102, then at Step 714, sensor control device 102 can enter either a storage state or a termination 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 is capable of being re-activated by a reader device 120. By contrast, in the termination state, the sensor control device 102 cannot be re-activated and must be removed and replaced.
If a receipt of the fault condition indication is not received by sensor control device 102, then at 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 can be one of: one hour, two hours, five hours, etc. Subsequently, at Step 712, if a receipt of the fault condition indication is still not received by sensor control device 102, then at Step 712, the sensor control device 102 will also stop allowing for data backfilling after a second predetermined time period. In some embodiments, for example, the second predetermined time period can be one of: twenty-four hours, forty-eight hours, etc. Sensor control device 102 then enters a storage state or a termination state at Step 714.
By allowing sensor control device 102 to continue transmissions of sensor fault conditions for a predetermined time period, the embodiments of the present disclosure mitigate the risk of unreceived sensor fault alerts. In addition, although the embodiments described above are in reference to a sensor control device 102 in communication with a reader device 120, those of skill in the art will recognize that indications of sensor fault conditions can also be transmitted between a sensor control device 102 and other types of mobile computing devices, such as, for example, wearable computing devices (e.g., smart watches, smart glasses) or tablet computing devices.
Example Embodiments of Data Merging in Analyte Monitoring Systems
Example embodiments of methods for merging data received from one or more analyte monitoring systems will now be described. As described earlier with respect to FIG. 1, a trusted computer system 180, such as a cloud-based platform, can be configured to generate various reports based on received analyte data and other information from a plurality of reader devices 120 and sensor control devices 102. A large and diverse population of reader devices and sensor control devices, however, can give rise to complexities and challenges in 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 serially over time, each of which can comprise different versions. This can lead to further complications in that, for each user, there may be sets of duplicative and/or overlapping data. It would therefore be beneficial to have methods for merging data at a trusted computer system for purposes of report generation.
FIG. 8A is a flow diagram depicting an example embodiment of a method 800 for merging data associated with a user 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 embodiments, method 800 can be implemented to merge analyte data in order to generate different types of report metrics utilized in various reports. At Step 802, data is received from one or more reader devices 120 and combined for purposes of merging. At Step 804, the combined data is then de-duplicated to remove historical data from multiple readers originating from the same sensor control device. According to one aspect of the embodiments, the process of de-duplicating data can include (1) identifying or assigning a priority associated with each reader device from which analyte data is received, and (2) in the case where there is “duplicate” data, preserving the data associated with the reader device with a higher priority. In some embodiments, for example, a newer reader device (e.g., newer model, having a more recent version of software installed) is assigned a higher priority than an older reader device (e.g., older model, having an older version of software installed). In some embodiments, priority can be assigned by device type (e.g., smart phone having a higher priority over a dedicated reader).
Referring still to FIG. 8A, at Step 806, a determination is made as to whether one or more of the report metrics to be generated requires resolution of overlapping data. If not, at Step 808, a first type of report metric can be generated based on de-duplicated data without further processing. In some embodiments, for example, the first type of report metric can include average glucose levels used in reports, such as a snapshot or monthly summary report (as described with respect to FIGS. 5C and 5D). If it is determined that one or more of the report metrics to be generated requires resolution of overlapping data, then at Step 810, a method for resolving overlapping regions of data is performed. An example embodiment method for resolving overlapping regions of data is described below with respect to FIG. 8B. Subsequently, at Step 812, a second type of report metric based on data that has been de-duplicated and processed to resolve overlapping data segments, is generated. In some embodiments, for example, the second type of report metric can include low glucose event calculations used in reports, such as the daily log report (as described with respect to FIG. 5F).
FIG. 8B is a flow diagram depicting an example embodiment of a method 815 for resolving overlapping regions of analyte data, which can be implemented, for example, in Step 810 of method 800, as described with respect to FIG. 8A. At Step 817, the de-duplicated data from each reader (resulting from Step 804 of method 800, as described with respect to FIG. 8A) can be sorted from earliest to most recent. At Step 819, based on the report metric to be generated, the de-duplicated and sorted data is then isolated according to a predetermined period of time. In some embodiments, for example, if the report metric is a graph reflecting glucose values over a specific day, then the de-duplicated and sorted data can be isolated for that specific day. Next, at Step 821, contiguous sections of the de-duplicated and sorted data for each reader device are isolated. According to one aspect of the embodiments, non-contiguous data points can be discarded or disregarded (e.g., not used) for purposes of generating report metrics. At Step 823, for each contiguous section of de-duplicated and sorted data of a reader device, a determination is made as to whether there are any overlapping regions with other contiguous sections of de-duplicated and sorted data from other reader devices. At Step 825, for each overlapping region identified, the de-duplicated and sorted data from the reader device with the higher priority is preserved. At Step 827, if it is determined that all contiguous sections have been analyzed according to the previous steps, then method 815 ends at Step 829. Otherwise, method 815 then returns to Step 823 to continue identifying and resolving any overlapping regions between contiguous sections of de-duplicated and sorted data for different reader devices.
FIGS. 8C to 8E are graphs (840, 850, 860) depicting various stages of de-duplicated and sorted data from multiple reader devices, as the data is processed according to method 815 for resolving overlapping regions of data. Referring first to FIG. 8C, graph 840 depicts de-duplicated and sorted data from three different reader devices: a first reader 841 (as reflected by the circular data points), a second reader 842 (as reflected by diamond-shaped data points), and a third reader 843 (as reflected by the square-shaped data points). According to one aspect of graph 840, the data is depicted at Step 821 of method 815, after it has been de-duplicated, sorted, and isolated to a predetermined time period. As can be seen in FIG. 8C, a contiguous section of data for each of the three reader devices (841, 842, and 843) has been identified, and three traces are shown. According to another aspect of the graph 840, non-contiguous points 844 are not included in the three traces.
Referring next to FIG. 8D, graph 850 depicts the data from readers 841, 842, 843 at Step 823 of method 815, wherein three overlapping regions between the contiguous sections of data have been identified: a first overlapping region 851 between all three contiguous sections of data; a second overlapping region 852 between two contiguous sections of data (from reader device 842 and reader device 843); and a third overlapping region 853 between two contiguous sections of data (also from reader device 842 and reader device 843).
FIG. 8E is a graph 860 depicting data at Step 825 of method 815, wherein a single trace 861 indicates the merged, de-duplicated, and sorted data from three reader devices 841, 842, 843 after overlapping regions 851, 852, and 853 have been resolved by using the priority of each reader device. According to graph 860, the order of priority from highest to lowest is: reader device 843, reader device 842, and reader device 841.
Although FIGS. 8C, 8D, and 8E depict three contiguous sections of data with three discrete overlapping regions identified, those of skill in the art will understand that either fewer or more contiguous sections of data (and non-contiguous data points) and overlapping regions are possible. For example, those of skill in the art will recognize that where a user has only two reader devices, there may be fewer contiguous sections of data and overlapping regions, if any at all. Conversely, if a user has five reader devices, those of skill in the art will understand that there may be five contiguous sections of data with three or more overlapping regions.
Example Embodiments of Sensor Transitioning
Example embodiments of methods for sensor transitioning will now be described. According to one aspect of the embodiments, as mobile computing and wearable technologies continue to advance at a rapid pace and become more ubiquitous, users are more likely to replace or upgrade their smart phones more frequently. In the context of analyte monitoring systems, it would therefore be beneficial to have sensor transitioning methods to allow a user to continue using a previously activated sensor control device with a new smart phone. In addition, it would also be beneficial to ensure that historical analyte data from the sensor control device could be backfilled to the new smart phone (and subsequently uploaded to the trusted computer system) in a user-friendly and secure manner.
FIG. 9A is a flow diagram depicting an example embodiment of a method 900 for transitioning a sensor control device. According to one aspect of the embodiments, method 900 can be implemented in an analyte monitoring system to allow a user to continue using a previously activated sensor control device with a new reader device (e.g., smart phone). At Step 902, a user interface application (e.g., mobile software application or app) is installed on reader device 120 (e.g., smart phone), which causes a new unique device identifier, or “device ID,” to be created and stored on reader device 120. At Step 904, after installing and launching the app, the user is prompted to enter their user credentials for purposes of logging into trusted computer system 180 (e.g., cloud-based platform or server). An example embodiment of a GUI 988 for prompting the user to enter their user credentials is shown in FIG. 9D. According to an aspect of the embodiments, GUI 988 can include a username field 990, which can comprise a unique username or an e-mail address, and a masked or unmasked password field 992, to allow the user to enter their password.
Referring again to FIG. 9A, at Step 906, after user credentials are entered into the app, a prompt is displayed requesting user confirmation to login to trusted computer system 180. An example embodiment of GUI 994 for requesting user confirmation to login to trusted computer system 180 is shown in FIG. 9E. According to an aspect of the embodiments, GUI 994 can also include a warning, such as the one shown in FIG. 9E, that confirming the login will cause the user to be logged off from other reader devices (e.g., the user's old smart phone).
If the user confirms login, then at Step 908, the user's credentials are sent to trusted computer system 180 and subsequently verified. In addition, according to some embodiments, the device ID can also be transmitted from the reader device 120 to trusted computer system 180 and stored in a non-transitory memory of trusted computer system 180. According to some embodiments, for example, in response to receiving the device ID, trusted computer system 180 can update a device ID field associated with the user's record in a database.
After the user credentials are verified by trusted computer system 180, at Step 910, the user is prompted by the app to scan the already-activated sensor control device 102. According to one aspect of the embodiments, the scan can comprise bringing the reader device 120 in close proximity to 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 can be a Near Field Communication (NFC) wireless communication protocol. Those of skill in the art, however, will recognize that other wireless communication protocols can be implemented (e.g., infrared, UHF, 802.11x, etc.). An example embodiment of GUI 998 for prompting the user to scan the already-activated sensor control device 102 is shown in FIG. 9F.
Referring still to FIG. 9A, at Step 912, scanning of sensor control device 102 by reader device 120 causes sensor control device 102 to terminate an existing wireless communication link with the user's previous reader device, if there is currently one established. According to an aspect of the embodiments, the existing wireless communication link can comprise a link established according to a second wireless communication protocol that is different from the first wireless communication protocol. In some embodiments, for example, the second wireless communication protocol can be a Bluetooth or Bluetooth Low Energy protocol. Subsequently, sensor control device 102 enters into a “ready to pair” state, in which sensor control device 102 is available to establish a wireless communication link with reader device 120 according to the second wireless communication protocol.
At Step 914, reader device 120 initiates a pairing sequence via the second wireless communication protocol (e.g., Bluetooth or Bluetooth Low Energy) with sensor control device 102. Subsequently, at Step 916, sensor control device 102 completes the pairing sequence with reader device 120. At Step 918, sensor control device 102 can begin sending current glucose data to reader device 120 according to the second wireless communication protocol. In some embodiments, for example, current glucose data can be wirelessly transmitted to reader device 120 at a predetermined interval (e.g., every minute, every two minutes, every five minutes).
Referring still to FIG. 9A, at Step 920, reader device 120 receives and stores current glucose data received from sensor control device 102 in a non-transitory memory of reader device 120. In addition, according to some embodiments, reader device 120 can request historical glucose data from sensor control device 102 for backfilling purposes. According to some embodiments, for example, reader device 120 can request historical glucose data from sensor control device 102 for the full wear duration, which is stored in a non-transitory memory of sensor control device 102. In other embodiments, reader device 120 can request historical glucose data for a specific predetermined time range (e.g., from day 3 to present, from day 5 to present, last 3 days, last 5 days, lifecount >0, etc.). Those of skill will appreciate that other backfilling schemes can be implemented (such as those described with respect to FIGS. 6A and 6B) and are fully within the scope of the present disclosure.
Upon receipt of the request at Step 922, sensor control device 102 can retrieve historical glucose data from a non-transitory memory and transmit it to reader device 120. In turn, at Step 924, reader device 120 can store the received historical glucose data in a non-transitory memory. In addition, according to some embodiments, reader device 120 can also display the current and/or historical glucose data in the app (e.g., on a sensor results screen). In this regard, a new reader can display all available analyte data for the full wear duration of a sensor control device. In some embodiments, reader device 120 can also transmit the current and/or historical glucose data to trusted computer system 180. At Step 926, the received glucose data can be stored in a non-transitory memory (e.g., a database) of trusted computer system 180. In some embodiments, the received glucose data can also be de-duplicated prior to storage in non-transitory memory.
FIG. 9B is a flow diagram depicting another example embodiment of a method 930 for transitioning a sensor control device, wherein method 930 includes a security check performed by the user interface application (“app side check”). Like method 900 of FIG. 9A, method 930 can be implemented in an analyte monitoring system to allow a user to continue using a previously activated sensor control device with a new reader device (e.g., smart phone). In one aspect, method 930 includes many of the same or similar method steps as 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 or similar to, respectively, Steps 902, 904, 906, 918, 920, 922, 924, and 926 of method 900.
According to one aspect of the embodiments, method 930 can include a security check performed by the user interface application installed on reader device 120. Referring still to FIG. 9B, at Step 938, after the user has confirmed their login, the user's credentials are sent to trusted computer system 180 and subsequently verified. In addition, according to some embodiments, the device ID can also be transmitted from the reader device 120 to trusted computer system 180 and stored in a non-transitory memory of trusted computer system 180. According to some embodiments, for example, in response to receiving the device ID, trusted computer system 180 can update a device ID field associated with the user's record in a database. In addition, according to some embodiments, trusted computer system 180 can retrieve a stored sensor serial number associated with sensor control unit 102 and transmit the stored sensor serial number to reader device 120.
After the user credentials are verified by trusted computer system 180, at Step 940, the user is prompted by the app to scan the already-activated sensor control device 102. According to one aspect of the embodiments, the scan can comprise bringing the reader device 120 in close proximity to 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 can be a Near Field Communication (NFC) wireless communication protocol. Those of skill in the art, however, will recognize that other wireless communication protocols can be implemented (e.g., infrared, UHF, 802.11x, etc.). An example embodiment of GUI 998 for prompting the user to scan the already-activated sensor control device 102 is shown in FIG. 9F.
Referring still to FIG. 9B, at Step 942, scanning of sensor control device 102 by reader device 120 can cause sensor control device 102 to transmit the serial number of the sensor control unit to reader device 120. At Step 944, 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, then at Step 945, the user interface application can output a message to the display of reader device 120 indicating that the sensor control device 102 cannot be transitioned, and, subsequently, method 930 ends. If the serial numbers match, then a pairing process is initiated, wherein, at Step 946, sensor control device 102 terminates an existing wireless communication link with the user's previous reader device, if there is currently one established. According to an aspect of the embodiments, the existing wireless communication link can comprise a link established according to a second wireless communication protocol that is different from the first wireless communication protocol. In some embodiments, for example, the second wireless communication protocol can be a Bluetooth or Bluetooth Low Energy protocol. Subsequently, sensor control device 102 enters into a “ready to pair” state, in which sensor control device 102 is available to establish a wireless communication link with reader device 120 according to the second wireless communication protocol. Subsequently, reader device 120 initiates and completes a pairing sequence via the second wireless communication protocol (e.g., Bluetooth or Bluetooth Low Energy) with sensor control device 102. Referring still to FIG. 9B, method 930 then proceeds to Steps 948 to 956, which are the same or similar to, respectively, Steps 918 to 926 of method 900, as described with respect to FIG. 9A.
Referring next to FIG. 9C, a flow diagram depicts another example embodiment of a method 960 for transitioning a sensor control device, wherein method 960 includes a security check performed by sensor control device 102 (“patch side check”). Like methods 900 and 930 of FIGS. 9A and 9B, method 960 can be implemented in an analyte monitoring system to allow a user to continue using a previously activated sensor control device with a new reader device (e.g., smart phone). In one aspect, method 960 also includes many of the same or similar method steps as 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 or similar to, respectively, Steps 902, 904, 906, 918, 920, 922, 924, and 926 of method 300.
According to one aspect of the embodiments, method 960 can include a security check performed by sensor control device 102. Referring still to FIG. 9C, at Step 968, after the user has confirmed their login, the user's credentials are sent to trusted computer system 180 and subsequently verified. In addition, according to some embodiments, the device ID can also be transmitted from the reader device 120 to trusted computer system 180 and stored in a non-transitory memory of trusted computer system 180. According to some embodiments, for example, in response to receiving the device ID, trusted computer system 180 can update a device ID field associated with the user's record in a database. In addition, according to some embodiments, trusted computer system 180 can retrieve a stored Account ID associated with the user and transmit the stored Account ID to reader device 120.
After the user credentials are verified by trusted computer system 180, at 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 can be a compressed or truncated version of the Account ID. In other embodiments, the user interface application can generate a Receiver ID based on the Account ID using an algorithm, such as a hash function. In still other embodiments, the Receiver ID can be the Account ID. Subsequently, or in parallel, the user is prompted by the app to scan the already-activated sensor control device 102. According to one aspect of the embodiments, the scan can comprise bringing the reader device 120 in close proximity to 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 can be a Near Field Communication (NFC) wireless communication protocol. Those of skill in the art, however, will recognize that other wireless communication protocols can be implemented (e.g., infrared, UHF, 802.11x, etc.). An example embodiment of GUI 998 for prompting the user to scan the already-activated sensor control device 102 is shown in FIG. 9F.
Referring still to FIG. 9C, according to another aspect of the embodiments, at Step 972, the scanning of sensor control device 102 by reader device 120 can cause the sensor control device 102 to prepare for a pairing sequence with reader device 120. Subsequently, at Step 974, reader device 120 can initiate the pairing sequence via a second wireless communication protocol (e.g., Bluetooth or Bluetooth Low Energy) with sensor control device 102. According to some embodiments, reader device 120 can also transmit the Receiver ID to sensor control device 102 as part of, or shortly after, the pairing sequence is executed. At Step 976, sensor control device 102 then verifies that the Receiver ID is authentic. In some embodiments, sensor control device 102 can verify the received Receiver ID by comparing it with a Receiver ID stored in non-transitory memory of sensor control device 102. In other embodiments, the received Receiver ID can be verified using a hash function stored in non-transitory memory of sensor control device 102. Those of skill in the art will appreciate that other methods for verifying the authenticity of the received Receiver ID are possible and are fully within the scope of the present disclosure.
According to one aspect of some embodiments, if sensor control device 102 is unable to verify the Receiver ID, then sensor control device 102 can transmit an indication to reader device 120 that causes the user interface application to output a message on the display of the reader device 120 indicating a failed sensor transition. In other embodiments, user interface application can output the message on the display of the reader device 120 indicating a failed sensor transition if an indication is not received from sensor control device 102 that the Receiver ID was successfully verified within a predetermined amount of time.
If the Receiver ID is verified by sensor control device 102, sensor control device 102 can terminate an existing wireless communication link (e.g., a Bluetooth or Bluetooth Low Energy link) with the user's previous reader device, if there is currently one 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 or similar to, respectively, Steps 918 to 926 of method 900, as described with respect to FIG. 9A.
Referring again to FIG. 9C, although the verification of the Receiver ID is described at Step 976, those of skill in the art will recognize that, in some embodiments, the Receiver ID can be verified earlier at Step 972 as part of, or in response to, the reader device 120 scanning the sensor control device 102. Similarly, although the termination of the existing wireless communication link is described with respect to Step 976, those of skill in the art will recognize that, in some embodiments, the termination of the existing wireless communication can occur earlier at Step 972 as part of, or in response to, the reader device 120 scanning the sensor control device 102.
Furthermore, although shown as different steps of different methods, those of skill in the art will recognize that the “app side check” and the “patch side check” can both be performed as part of a single sensor transitioning process. That is, according to some embodiments, in a single sensor transition, the app can verify the serial number (as described with respect to method 930 of FIG. 3B) and the sensor control device 102 can verify the Receiver ID (as described with respect to method 960 of FIG. 9C). Conversely, the sensor transition process can be implemented without the use of either methods 930 or 960.
According to some embodiments, any of methods 900, 930, and/or 950 of FIGS. 9A, 9B, and 9C can 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 steps of requesting and transmitting historical (backfill) glucose data can be optional.
Although methods 900, 930, and 960 of FIGS. 9A, 9B, and 9C are described with respect to glucose measurements, those of skill in the art will appreciate that sensor control device 102 can be configured to measure other analytes (e.g., lactate, ketone, etc.) as well. In addition, although methods 900, 930, and 960 describe certain method steps performed by reader device 120, those of skill in the art will understand that any or all of these method steps can be performed by other devices in an analyte monitoring system, such as, for example, a local computer system, a wearable computing device, or a medication delivery device.
Example Embodiments of Check Sensor and Replace Sensor System Alarms
Example embodiments of autonomous check sensor and replace sensor system alarms, and methods relating thereto, will now be described. According to one aspect of the embodiments, certain adverse conditions affecting the operation of the analyte sensor and sensor electronics can be detectable by the sensor control device. For example, an improperly inserted analyte sensor can be detected if an average glucose level measurement over a predetermined period of time is determined to be below an insertion failure threshold. Due to its small form factor and a limited power capacity, however, the sensor control device may not have sufficient alarming capabilities. As such, it would be advantageous for the sensor control device to transmit indications of adverse conditions to another device, such as a reader device (e.g., smart phone), to alert the user of those conditions.
FIG. 10A is a flow diagram depicting an example embodiment of a method 1000 for generating a sensor insertion failure system alarm (also referred to as a “check sensor” system alarm). At Step 1002, a sensor insertion failure condition is detected by sensor control device 102. In some embodiments, for example, a sensor insertion failure condition can be detected when an average glucose value during a predetermined time period (e.g., average glucose value over five minutes, eight minutes, 15 minutes, etc.) is below an insertion failure glucose level threshold. At Step 1004, in response to the detection of the insertion failure condition, sensor control device 102 stops taking glucose measurements. At Step 1006, sensor control device 102 generates a check sensor indicator and transmits it via wireless communication circuitry to reader device 120. Subsequently, as shown at Steps 1012 and 1014, sensor control device 102 will continue to transmit the check sensor indicator until either: (1) a receipt of the indicator is received from reader device 120 (step 1012); or (2) a predetermined waiting period has elapsed (Step 1014), whichever occurs first.
According to another aspect of the embodiments, if a wireless communication link is established between sensor control device 102 and reader device 120, then reader device 120 will receive the check sensor indicator at Step 1008. In response to receiving the check sensor indicator, reader device 120 will display a check sensor system alarm at Step 1010. FIGS. 10B to 10D are example embodiments of check sensor system alarm interfaces, as displayed on reader device 120. In some embodiments, for example, the check sensor system alarm can be a notification box, banner, or pop-up window that is output to a display of a smart phone, such as interfaces 1020 and 1025 of FIGS. 10B and 10C. In some embodiments, the check sensor alarm can be output to a display on a reader device 120, such as a glucose meter or a receiver device, such as interface 1030 of FIG. 10D. According to the embodiments, reader device 120 can also transmit a check sensor indicator receipt back to sensor control device 102. In some embodiments, for example, the check sensor indicator receipt can be automatically generated and sent upon successful display of the check sensor system alarm 1020, 1025, or 1030. In other embodiments, the check sensor indicator receipt is generated and/or transmitted in response to a predetermined user input (e.g., dismissing the check sensor system alarm, pressing a confirmation ‘OK’ button 1032, etc.).
Subsequently, at Step 1011, reader device 120 drops sensor control device 102. According to one aspect of the embodiments, for example, Step 1011 can comprise one or more of: terminating an existing wireless communication link with sensor control device 102; unpairing from sensor control device 102; revoking an authorization or digital certificate associated with sensor control device 102; creating or modifying a record stored on reader device 120 to indicate that sensor control device 102 is in a storage state; or transmitting an update to trusted computer system 180 to indicate that sensor control device 102 is in a storage state.
Referring back to FIG. 10A, if either the check sensor indicator receipt is received (at Step 1012) by sensor control device 102 or the predetermined wait period has elapsed (Step 1014), then at Step 1016, sensor control device 102 stops the transmission of check sensor indicators. Subsequently, at Step 1018, sensor control device 102 enters a storage state in which sensor control device 102 does not take glucose measurements and the wireless communication circuitry is either de-activated or transitioned into a dormant mode. According to one aspect, while in a ‘storage state,’ sensor control device 102 can be re-activated by reader device 120.
Although method 1000 of FIG. 10A is described with respect to glucose measurements, those of skill in the art will appreciate that sensor control device 102 can be configured to measure other analytes (e.g., lactate, ketone, etc.) as well. In addition, although method 1000 of FIG. 10A describes certain method steps performed by reader device 120 (e.g., receiving check sensor indicator, displaying a check sensor system alarm, and sending a check sensor indicator receipt), those of skill in the art will understand that any or all of these method steps can be performed by other devices in an analyte monitoring system, such as, for example, a local computer system, a wearable computing device, or a medication delivery device. It will also be understood by those of skill in the art that method 1000 of FIG. 10A can combined with any of the other methods described herein, including but not limited to method 700 of FIG. 7, relating to expired and or failed sensor transmissions.
FIG. 11A is a flow diagram depicting an example embodiment of a method 1100 for generating a sensor termination system alarm (also referred to as a “replace sensor” system alarm). At Step 1102, a sensor termination condition is detected by sensor control device 102. As described earlier, a sensor termination condition can include, but is not limited to, one or more of the following: a FIFO overflow condition detected, a sensor signal below a predetermined insertion failure threshold, moisture ingress detected, an electrode voltage exceeding a predetermined diagnostic voltage threshold, an early signal attenuation (ESA) condition, or a late signal attenuation (LSA) condition, to name a few.
At Step 1104, in response to the detection of a sensor termination condition, sensor control device 102 stops taking glucose measurements. At Step 1106, sensor control device 102 generates a replace sensor indicator and transmits it via wireless communication circuitry to reader device 120. Subsequently, at Step 1112, sensor control device 102 will continue to transmit the replace sensor indicator while determining whether a replace sensor indicator receipt has been received from reader device 102. According to one aspect of the embodiments, sensor control device 102 can continue to transmit the replace sensor indicator until either: (1) a predetermined waiting period has elapsed (Step 1113), or (2) a receipt of the replace sensor indicator is received (Step 1112) and sensor control device 102 has successfully transmitted backfill data (Steps 1116, 1120) to reader device 120.
Referring still to FIG. 11A, if a wireless communication link is established between sensor control device 102 and reader device 120, then reader device 120 will receive the replace sensor indicator at Step 1108. In response to receiving the replace sensor indicator, reader device 120 will display a replace sensor system alarm at Step 1110. FIGS. 11B to 11D are example embodiments of replace sensor system alarm interfaces, as displayed on reader device 120. In some embodiments, for example, the replace sensor system alarm can be a notification box, banner, or pop-up window that is output to a display of a smart phone, such as interfaces 1130 and 1135 of FIGS. 11B and 11C. In some embodiments, the check sensor alarm can be output to a display on a reader device 120, such as a glucose meter or a receiver device, such as interface 1140 of FIG. 11D. According to the embodiments, to acknowledge receipt of the indicator, reader device 120 can also transmit a replace sensor indicator receipt back to sensor control device 102. In some embodiments, for example, the replace sensor indicator receipt can be automatically generated and sent upon successful display of the replace sensor system alarm 1130, 1135, or 1140. In other embodiments, the replace sensor indicator is generated and/or transmitted in response to a predetermined user input (e.g., dismissing the check sensor system alarm, pressing a confirmation ‘OK’ button 1142, etc.).
At Step 1114, after displaying the replace sensor system alarm and transmitting the replace sensor indicator receipt, reader device 120 can then request historical glucose data from sensor control device 102. At Step 1116, sensor control device 102 can collect and send to reader device 120 the requested historical glucose data. According to one aspect of the embodiments, the step of requesting, collecting, and communicating historical glucose data can comprise a data backfilling routine, such as the methods described with respect to FIGS. 6A and 6B.
Referring again to FIG. 11A, in response to receiving the requested historical glucose data, reader device 120 can send a historical glucose data received receipt to sensor control device 102 at Step 1118. Subsequently, at Step 1119, reader device 120 drops sensor control device 102. According to one aspect of the embodiments, for example, Step 1119 can comprise one or more of: terminating an existing wireless communication link with sensor control device 102; unpairing from sensor control device 102; revoking an authorization or digital certificate associated with sensor control device 102; creating or modifying a record stored on reader device 120 to indicate that sensor control device 102 has been terminated; or transmitting an update to trusted computer system 180 to indicate that sensor control device 102 has been terminated.
At Step 1120, sensor control device 102 receives the historical glucose data received receipt. Subsequently, at Step 1122, sensor control device 102 stops the transmission of the replace sensor indicator and, at Step 1124, sensor control device 102 can enter into a termination state in which sensor control device 102 does not take glucose measurements and the wireless communication circuitry is either de-activated or in a dormant mode. According to one aspect of the embodiments, when in a termination state, sensor control device 102 cannot be re-activated by reader device 120.
Although method 1100 of FIG. 11A is described with respect to glucose measurements, those of skill in the art will appreciate that sensor control device 102 can be configured to measure other analytes (e.g., lactate, ketone, etc.) as well. In addition, although method 1100 of FIG. 11A describes certain method steps performed by reader device 120 (e.g., receiving replace sensor indicator, displaying a replace sensor system alarm, and sending a replace sensor indicator receipt), those of skill in the art will understand that any or all of these method steps can be performed by other devices in an analyte monitoring system, such as, for example, a local computer system, a wearable computing device, or a medication delivery device. It will also be understood by those of skill in the art that method 1100 of FIG. 11A can combined with any of the other methods described herein, including but not limited to method 700 of FIG. 7, relating to expired and or failed sensor transmissions.
It should be noted that all features, elements, components, functions, and steps described with respect to any embodiment provided herein are intended to be freely combinable and substitutable with those from any other embodiment. If a certain feature, element, component, function, or step is described with respect to only one embodiment, then it should be understood that that feature, element, component, function, or step can be used with every other embodiment described herein unless explicitly stated otherwise. This paragraph therefore serves as antecedent basis and written support for the introduction of claims, at any time, that combine features, elements, components, functions, and steps from different embodiments, or that substitute features, elements, components, functions, and steps from one embodiment with those of another, even if the following description does not explicitly state, in a particular instance, that such combinations or substitutions are possible. It is explicitly acknowledged that express recitation of every possible combination and substitution is overly burdensome, especially given that the permissibility of each and every such combination and substitution will be readily recognized by those of ordinary skill in the art.
While the embodiments are susceptible to various modifications and alternative forms, specific examples thereof have been shown in the drawings and are herein described in detail. It should be understood, however, that these embodiments are not to be limited to the particular form disclosed, but to the contrary, these embodiments are to cover all modifications, equivalents, and alternatives falling within the spirit of the disclosure. Furthermore, any features, functions, steps, or elements of the embodiments may be recited in or added to the claims, as well as negative limitations that define the inventive scope of the claims by features, functions, steps, or elements that are not within that scope.
Patent Application
20210378601
