Patent Description:
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 or her health care provider ("HCP") 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 graphical user interfaces for analyte monitoring systems, as well as methods and devices relating thereto, that are robust, user-friendly, and provides for timely and actionable responses.

<CIT> describes analyte monitoring systems, devices, and methods associated with analyte monitoring devices, and devices incorporating the same. Various graphical user interfaces (GUI) and navigation flows are provided for performing various features, activities, functions, etc., associated with the analyte monitoring device or system. Intuitive navigation is provided to enhance the interpretation of analyte measurements.

<CIT> describes an analyte monitoring device having a user interface with a display and a plurality of actuators. The display is configured to render a plurality of display screens, including a home screen and an alert screen. The home screen is divided into a plurality of simultaneously displayed panels, with a first panel displays a rate of change of continuously monitored analyte levels in interstitial fluid, a second panel simultaneously displays a current analyte level and an analyte trend indicator, and a third panel displays status information of a plurality of components of the device. When an alarm condition is detected, the display renders the alert screen in place of the home screen, the alert screen displaying information corresponding to the detected alarm condition. Furthermore, the actuators are configured to affect further output of the analyte monitoring device corresponding to the detected condition.

<CIT> describes a computing device that receives analyte data produced by an analyte monitoring sensor over a communications link from at least one first device. Health data, comprising at least part of the analyte data, may be communicated over a communications link to at least one second device in response to a request. The first device may be positioned over the analyte monitoring sensor using signal strength and location information. External analyte data may be employed to calibrate the analyte monitoring sensor.

Provided herein are example embodiments of graphical user interfaces ("GUIs") for in vivo analyte monitoring systems. 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.

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. 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. 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.

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.

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 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.

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.

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.

<FIG> is a conceptual diagram depicting an example embodiment of an analyte monitoring system <NUM> that includes a sensor applicator <NUM>, a sensor control device <NUM>, and a reader device <NUM>. Here, sensor applicator <NUM> can be used to deliver sensor control device <NUM> to a monitoring location on a user's skin where a sensor <NUM> is maintained in position for a period of time by an adhesive patch <NUM>. Sensor control device <NUM> is further described in <FIG>, and can communicate with reader device <NUM> via a communication path <NUM> 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 <NUM> using screen <NUM> (which, in many embodiments, can comprise a touchscreen), and input <NUM>. A device battery of reader device <NUM> can be recharged using power port <NUM>. While only one reader device <NUM> is shown, sensor control device <NUM> can communicate with multiple reader devices <NUM>. Each of the reader devices <NUM> can communicate and share data with one another. More details about reader device <NUM> is set forth with respect to <FIG> below. Reader device <NUM> can communicate with local computer system <NUM> via a communication path <NUM> using a wired or wireless communication protocol. Local computer system <NUM> 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 <NUM> can communicate via communications path <NUM> with a network <NUM> similar to how reader device <NUM> can communicate via a communications path <NUM> with network <NUM>, by a wired or wireless communication protocol as described previously. Network <NUM> 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 <NUM> can include a server and can provide authentication services and secured data storage and can communicate via communications path <NUM> with network <NUM> by wired or wireless technique.

<FIG> is a block diagram depicting an example embodiment of a reader device <NUM>, which, in some embodiments, can comprise a smartphone. Here, reader device <NUM> can include a display <NUM>, input component <NUM>, and a processing core <NUM> including a communications processor <NUM> coupled with memory <NUM> and an applications processor <NUM> coupled with memory <NUM>. Also included can be separate memory <NUM>, RF transceiver <NUM> with antenna <NUM>, and power supply <NUM> with power management module <NUM>. Further, reader device <NUM> can also include a multi-functional transceiver <NUM> which can communicate over Wi-Fi, NFC, Bluetooth, BTLE, and GPS with an antenna <NUM>. As understood by one of skill in the art, these components are electrically and communicatively coupled in a manner to make a functional device.

<FIG> are block diagrams depicting example embodiments of sensor control devices <NUM> having analyte sensors <NUM> and sensor electronics <NUM> (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>, a single semiconductor chip <NUM> is depicted that can be a custom application specific integrated circuit (ASIC). Shown within ASIC <NUM> are certain high-level functional units, including an analog front end (AFE) <NUM>, power management (or control) circuitry <NUM>, processor <NUM>, and communication circuitry <NUM> (which can be implemented as a transmitter, receiver, transceiver, passive circuit, or otherwise according to the communication protocol). In this embodiment, both AFE <NUM> and processor <NUM> are used as analyte monitoring circuitry, but in other embodiments either circuit can perform the analyte monitoring function. Processor <NUM> 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 <NUM> is also included within ASIC <NUM> and can be shared by the various functional units present within ASIC <NUM>, or can be distributed amongst two or more of them. Memory <NUM> can also be a separate chip. Memory <NUM> can be volatile and/or non-volatile memory. In this embodiment, ASIC <NUM> is coupled with power source <NUM>, which can be a coin cell battery, or the like. AFE <NUM> interfaces with in vivo analyte sensor <NUM> and receives measurement data therefrom and outputs the data to processor <NUM> 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 <NUM> for sending, by way of antenna <NUM>, to reader device <NUM> (not shown), for example, where minimal further processing is needed by the resident software application to display the data.

<FIG> is similar to <FIG> but instead includes two discrete semiconductor chips <NUM> and <NUM>, which can be packaged together or separately. Here, AFE <NUM> is resident on ASIC <NUM>. Processor <NUM> is integrated with power management circuitry <NUM> and communication circuitry <NUM> on chip <NUM>. AFE <NUM> includes memory <NUM> and chip <NUM> includes memory <NUM>, which can be isolated or distributed within. In one example embodiment, AFE <NUM> is combined with power management circuitry <NUM> and processor <NUM> on one chip, while communication circuitry <NUM> is on a separate chip. In another example embodiment, both AFE <NUM> and communication circuitry <NUM> are on one chip, and processor <NUM> and power management circuitry <NUM> 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.

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 <NUM>, local computer system <NUM>, trusted computer system <NUM>, and/or any other device or system that is part of, or in communication with, analyte monitoring system <NUM>. These instructions, when executed by one or more processors of the reader device <NUM>, local computer system <NUM>, trusted computer system <NUM>, or other device or system of analyte monitoring system <NUM>, 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.

<FIG> depict example embodiments of GUIs for analyte monitoring systems. In particular, <FIG> 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 <FIG>, an example embodiment of a Time-in-Ranges GUI <NUM> is shown, wherein Time-in-Ranges GUI <NUM> comprises a "Custom" Time-in-Ranges view 305A and a "Standard" Time-in-Ranges view 305B, with a toggle, switch, or slidable element <NUM> 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 <NUM>, showing relevant dates associated with the displayed analyte data, and a data availability indicator <NUM>, showing the period(s) of time in which analyte data is available for the displayed analyte data (e.g., "Data available for <NUM> of <NUM> days").

Referring to <FIG>, "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 <NUM>/dL for <NUM>% of a predefined amount of time, a second bar indicating that the user's glucose range is between <NUM> and <NUM>/dL for <NUM>% of the predefined amount of time, a third bar <NUM> indicating that the user's glucose range is between <NUM> and <NUM>/dL for <NUM>% of the predefined amount of time, a fourth bar indicating that the user's glucose range is between <NUM> and <NUM>/dL for <NUM>% of the predefined amount of time, a fifth bar indicating that the user's glucose range is between <NUM> and <NUM>/dL for <NUM>% of the predefined amount of time, and a sixth bar indicating that the user's glucose range is less than <NUM>/dL for <NUM>% 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 <FIG> show a predefined amount of time <NUM> 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 <NUM> 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 <NUM> has been defined as a glucose range between <NUM> and <NUM>/dL and corresponds with third bar <NUM> of the plurality of bars.

Referring to <FIG>, "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 <NUM>/dL for <NUM>% of a predefined amount of time, a second bar indicating that the user's glucose range is between <NUM> and <NUM>/dL for <NUM>% of the predefined amount of time, a third bar indicating that the user's glucose range is between <NUM> and <NUM>/dL for <NUM>% of the predefined amount of time, a fourth bar indicating that the user's glucose range is between <NUM> and <NUM>/dL for <NUM>% of the predefined amount of time, and a fifth bar indicating that the user's glucose range is less than <NUM>/dL for <NUM>% 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.

<FIG> depict another example embodiment of Time-in-Ranges GUI <NUM> with multiple views, 320A and 320B, which are analogous to the views shown in <FIG>, respectively. According to some embodiments, Time-in-Ranges GUI <NUM> can further include one or more selectable icons <NUM> (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 <NUM>. For example, as shown in <FIG>, selectable icons <NUM> 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> depicts an example embodiment of a Time-in-Target GUI <NUM>, 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 <NUM> 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 <NUM>% of a predefined amount of time, a second bar indicating that the user's glucose range is within the predefined target range for <NUM>% of the predefined amount of time, and a third bar indicating that the user's glucose range is below the predefined target range for <NUM>% 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> shows a predefined amount of time <NUM> equal to the last seven days and a predefined target range <NUM> of <NUM> to <NUM>/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., <NUM> to <NUM>/dL) can be utilized, and are fully within the scope of the present disclosure.

<FIG> depicts another example embodiment of a Time-in-Ranges GUI <NUM>, 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 <NUM>/dL for <NUM>% (<NUM> minutes) of a predefined amount of time, a second bar portion indicating that the user's glucose range is "High" or between <NUM> and <NUM>/dL for <NUM>% (<NUM> hours and <NUM> 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 <NUM> and <NUM>/dL for <NUM>% (<NUM> hours and <NUM> minutes) of the predefined amount of time, a fourth bar portion indicating that the user's glucose range is "Low" or between <NUM> and <NUM>/dL for <NUM>% (<NUM> 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 <NUM>/dL for <NUM>% (<NUM> minutes) of the predefined amount of time.

According to one aspect of the embodiment shown in <FIG>, each bar portion of Time-in-Ranges GUI <NUM> can comprise a different color. In some embodiments, bar portions can be separated by dashed or dotted lines <NUM> and/or interlineated with numeric markers <NUM> 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., <NUM> hours and <NUM> minutes), or, as shown in <FIG>, 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 <NUM>, the Target Range can be configured by the user. In other embodiments, the Target Range of Time-in-Ranges GUI <NUM> is not modifiable by the user.

<FIG> 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 <FIG>, example embodiments of a High Glucose Alarm <NUM>, Low Glucose Alarm <NUM>, and a Serious Low Glucose Alarms <NUM> (sometimes, also referred to as "an Urgent Low Glucose Alarm") are depicted, respectively, wherein each alarm comprises a pop-up window <NUM> containing an alarm condition text <NUM> (e.g., "Low Glucose Alarm"), an analyte level measurement <NUM> (e.g., <NUM>/dL) associated with the alarm condition, and a trend indicator <NUM> (e.g., trend arrow) associated with the alarm condition. In some embodiments, an alarm icon <NUM> can be adjacent to the alarm condition text <NUM>.

Referring next to <FIG>, additional example embodiments of Low Glucose Alarms <NUM>, <NUM>, Serious Low Glucose Alarm <NUM>, and High Glucose Alarm <NUM> are depicted, respectively. As shown in <FIG>, Low Glucose Alarm <NUM> is similar to the Low Glucose Alarm of <FIG> (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 <NUM> 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>, Low Glucose Alarm <NUM> is also similar to the Low Glucose Alarm of <FIG>, but instead of including a trend arrow, Log Glucose Alarm <NUM> includes a textual trend indicator <NUM>. According to one aspect of some embodiments, textual trend indicator <NUM> can be enabled through a device's Accessibility settings such that the device will "read" the textual trend indicator <NUM> 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>, Low Glucose Alarm <NUM> is similar to the Low Glucose Alarm of <FIG> (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 <NUM> displays a out-of-range indicator <NUM> 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>, High Glucose Alarm <NUM> is similar to the High Glucose Alarm of <FIG> (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 <NUM>. 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 <FIG> 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. <FIG>, 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, <FIG> 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. As described above, the Serious Low Glucose Alarm is sometimes also referred to as an Urgent Low Glucose Alarm, and can display the text "Urgent Low Glucose Alarm" in place of "Serious Low Glucose Alarm.

Claim 1:
An analyte monitoring system (<NUM>), comprising:
an on-body unit comprising an analyte sensor and sensor electronics, wherein the on-body unit is configured to transmit data indicative of an analyte level of a user; and
a reader device (<NUM>) comprising a display (<NUM>), a transceiver configured to receive the data indicative of the analyte level, and a memory coupled with one or more processors, wherein the memory is configured to store instructions that, when executed by the one or more processors, cause the one or more processors to:
output to the display a first view comprising a first set of graphical elements, wherein, in the first view, each graphical element of the first set is representative of an amount of time that the analyte level of the user is within a predefined analyte range associated with a correlating graphical element of the first set, and wherein at least one analyte range associated with the first set is customizable by the user, and
characterised in that the instructions that, when executed by the one or more processors, further cause the one or more processors to:
output to the display a second view comprising a second set of graphical elements, wherein, in the second view, each graphical element of the second set is representative of an amount of time that the analyte level of the user is within a predefined analyte range associated with a correlating graphical element of the second set, and wherein none of the analyte ranges associated with the second set are customizable by the user, and
output to the display a switch element, wherein the switch element is configured to cause the first view or the second view to output to the display of the reader device.