Tracking, reporting and visualizing pregnancy-related analyte data

Abstract

Techniques are disclosed for generating a user interface view including sensor data representing an analyte level of a recipient. In certain embodiments, a technique includes accessing sensor data that includes a plurality of analyte readings for the recipient during a plurality of time periods, where each analyte reading indicates an analyte level of the recipient at a respective time. The technique further includes generating a first user interface (UI) view including one or more UI elements based on the plurality of analyte levels of the recipient; and in response to receiving the user selection of the pregnancy pattern, automatically modifying a parameter of at least one UI element included in the one or more UI elements to reflect a pregnancy-specific parameter. The technique further includes generating a second UI view based on the plurality of analyte levels of the recipient and the pregnancy-specific parameter.

Description

[0001] Cross - reference to related applications

[0002] This application claims the benefit and priority of U.S. Provisional Application No. 63 / 384,058, filed on November 16, 2022, which is assigned to the assignee of the present application and is hereby incorporated by reference in its entirety as if fully set forth herein and for all applicable purposes. Background Art

[0003] Diabetes is a condition in which the pancreas fails to produce sufficient insulin (type 1 or insulin - dependent) and / or insulin is ineffective (type 2 or non - insulin - dependent). In a diabetic state, the patient has hyperglycemia, which can cause a series of physiological disorders associated with the degeneration of small blood vessels (renal failure, skin ulcers, or vitreous hemorrhage in the eyes). Hypoglycemic reactions (hypoglycemia) can be caused by an unintentional overdose of insulin or by excessive exercise or insufficient food intake following normal doses of insulin or hypoglycemic agents.

[0004] By convention, diabetic patients carry self - monitoring blood glucose (SMBG) monitors, which may require uncomfortable finger - pricking methods. Due to lack of comfort and convenience, diabetic patients typically only measure their glucose levels two to four times a day. Unfortunately, these time intervals are too far apart, making it possible for diabetic patients to become aware of high or low blood glucose levels too late, thus sometimes triggering dangerous side effects. In fact, due to the limitations of conventional methods, patients are less likely to obtain timely SMBG values, and further, patients will not know whether their blood glucose values are rising (higher) or falling (lower).

[0005] Accordingly, a variety of non - invasive, transdermal (e.g., percutaneous) and / or implantable sensors for continuously detecting and / or quantifying blood glucose values are being developed. Generally, in a diabetes management system, a transmitter associated with the sensor wirelessly transmits raw data or minimally processed data for subsequent display and / or analysis at one or more display devices, which may include mobile devices, servers, or any other type of communication device. Then, a display device such as a mobile device can utilize a trusted software application (e.g., approved and / or provided by the sensor manufacturer), which obtains the raw data or minimally processed data and provides the user with information about the user's blood glucose level. Since a diabetes management system using such implantable sensors can provide the user with more up - to - date information, the system can reduce the risk that the user is unable to regulate the user's blood glucose level.

[0006] This background is provided to introduce a brief context for the following detailed description of the invention and its specific embodiments. This background is not intended to assist in determining the scope of the claimed subject matter and is not to be regarded as limiting the claimed subject matter to specific embodiments that solve any or all of the disadvantages or problems presented above. Summary of the Invention

[0007] Certain embodiments provide a method for generating a user interface view that includes sensor data representing an analyte level of a recipient. The method includes accessing sensor data that includes a plurality of analyte readings of the recipient over a plurality of time periods, where each analyte reading indicates the analyte level of the recipient at a corresponding time. The method further includes: generating a first UI view that includes one or more user interface (UI) elements based on the plurality of analyte levels of the recipient; and automatically modifying parameters of at least one of the one or more UI elements included therein to reflect pregnancy-specific parameters in response to receiving a user selection of a pregnancy mode. The method further includes generating a second UI view based on the plurality of analyte levels of the recipient and the pregnancy-specific parameters.

[0008] Certain embodiments provide a method for generating a user interface view that includes sensor data representing an analyte level of a recipient. The method includes accessing sensor data that includes a plurality of analyte readings of the recipient over a plurality of time periods, where each analyte reading indicates the analyte level of the recipient at a corresponding time. The method further includes: generating a first UI view that includes one or more user interface (UI) elements based on the plurality of analyte levels of the recipient; and automatically modifying at least one of the one or more UI elements included therein to reflect pregnancy-specific information in response to receiving a user selection of a pregnancy mode. The method further includes generating a second UI view based on the plurality of analyte levels of the recipient and the pregnancy-specific information. Brief Description of the Drawings

[0009] Figure 1 Depicts a health management system that can be used in conjunction with certain embodiments of the present disclosure.

[0010] Figure 2 Illustrates in more detail an example health management system according to certain embodiments disclosed herein Figure 1 of.

[0011] Figure 3 Illustrates an analyte sensor system housing according to certain embodiments disclosed herein Figure 1 in perspective view.

[0012] Figure 4 Is a block diagram conceptually illustrating an example analyte processing system according to certain embodiments disclosed herein.

[0013] Figure 5 Illustrates an example user interface view associated with sensor data representing analyte levels, according to certain embodiments disclosed herein.

[0014] Figures 6A to 6E Illustrates a boot sequence presented to a user when a pregnancy assistant is enabled, according to certain embodiments disclosed herein.

[0015] Figures 7A to 7H Illustrates various user interface (UI) dashboards for enabling a pregnancy assistant and viewing pregnancy-specific information, according to certain embodiments disclosed herein.

[0016] Figure 8A and Figure 8B Illustrates a UI view showing analyte concentration readings as a function of time for a normal target analyte concentration range and a pregnancy-specific target analyte concentration range, according to certain embodiments disclosed herein.

[0017] Figures 9A to 9D Illustrates widgets included in a performance report that have been updated to reflect a pregnancy-specific target analyte concentration range and pregnancy-specific information, according to certain embodiments disclosed herein.

[0018] Figure 10A and Figure 10B Illustrates trend characteristics of analyte concentration readings as a function of time for a normal target analyte concentration range and a pregnancy-specific target analyte concentration range, according to certain embodiments disclosed herein.

[0019] Figure 11 Illustrates a UI view including an option to disable the pregnancy assistant, according to certain embodiments disclosed herein.

[0020] Figure 12 and Figure 13 Is a flowchart illustrating an example operation for generating a user interface view associated with sensor data representing glucose concentration levels in one or more users, according to certain embodiments disclosed herein. DETAILED DESCRIPTION

[0021] Hormonal changes experienced during pregnancy can have a significant impact on glucose levels, insulin resistance, and / or overall diabetes management. Additionally, poor glycemic control in women with diabetes during pregnancy can lead to health complications for both the mother and the baby. Thus, pregnant patients with diabetes are typically required to track various metrics (e.g., fasting glucose, postprandial glucose, etc.) and report such metrics to their healthcare provider (HCP).

[0022] Tracking of key metrics typically has to be performed manually multiple times per day (e.g., using a paper or digital log). Due to this tracking being both cumbersome and time-consuming, and due to the additional stress and burden experienced during pregnancy, pregnant patients may forget to track key metrics and / or may forget to bring their logs to appointments with HCPs. Thus, improved techniques for tracking and reporting pregnancy-related information are needed.

[0023] Various embodiments of the present disclosure include techniques for tracking, reporting, and visualizing pregnancy-related information such as pregnancy-specific analyte data and educational information. Aspects include generating a user interface (UI) view (e.g., a report) based on analyte data (e.g., continuous glucose monitoring (CGM) data and / or information entered by the user). The report may include the analyte concentration levels of the user over one or more time ranges (e.g., one or more days or one or more weeks).

[0024] In various embodiments, an option to enable a pregnancy assistant is provided to the user. Selecting the pregnancy assistant causes a guided sequence to be displayed to the user, enabling the user to enter the due date of the pregnancy. Then, when the pregnancy assistant is enabled, one or more user interface (UI) elements are automatically modified to reflect pregnancy-specific information such as pregnancy-specific target analyte ranges. For example, enabling the pregnancy assistant may cause the target glucose concentration range displayed in one or more widgets of the UI view to be automatically modified to reflect the pregnancy-specific target glucose concentration range. A pregnancy report (e.g., a weekly report) may then be generated based on the pregnancy-specific target glucose concentration range and shared (e.g., automatically) with the user and / or HCP. Additionally, useful information specific to the current gestational age (e.g., pregnancy-specific educational materials) may be provided to the user.

[0025] Once the pregnancy has ended, the user may disable the pregnancy assistant, causing one or more UI elements to be automatically modified to reflect the normal (non-pregnancy-specific) state. For example, when the pregnancy assistant is disabled, the UI view implementing the pregnancy-specific target glucose concentration range may be automatically modified to reflect the normal non-pregnancy target glucose concentration range. In various embodiments, the pregnancy assistant may be automatically disabled at the due date, within a predetermined period after the due date has passed, or when it is detected that the user has given birth (e.g., based on detecting a change in one or more analyte values of the user).

[0026] The above techniques for tracking, reporting, and visualizing pregnancy-related analyte data are described in more detail below in conjunction with Figures 1 to 12 It should be noted that although some embodiments herein are described in terms of the management of diabetes, glucose sensor systems, and the transmission of glucose measurements between devices, the protocols and techniques described herein are similarly applicable to any type of analyte sensor (e.g., lactate sensor, ketone sensor, O 2any type of health management system such as sensors, etc.

[0027] Exemplary analyte sensor system

[0028] Figure 1 FIG. 7 depicts a health management system 100 (″System 100″) that can be used in conjunction with certain embodiments of the present disclosure, such as a diabetes management system. Certain embodiments relate to using the health management system 100 to transmit analyte data. The health management system 100 depicts aspects of an analyte sensor system 8 (hereinafter referred to as ″SS 8″) that is communicatively coupled to display devices 110, 120, 130, and 140 and / or communicatively coupled to a server system 134.

[0029] In certain embodiments, SS 8 is provided for measuring an analyte in a recipient or user. As an overview and example, SS 8 can be implemented as an encapsulated microcontroller that performs sensor measurements, generates analyte data (e.g., by calculating values of continuous glucose monitoring data), and participates in wireless communication (e.g., via Bluetooth and / or other wireless protocols) to send such data to remote devices such as display devices 110, 120, 130, and 140 and / or server system 134. U.S. Application No. 2019 / 0336053, which is incorporated herein by reference in its entirety, further describes a skin sensor assembly that can be used in conjunction with SS 8 in certain embodiments.

[0030] In certain embodiments, SS 8 includes sensor electronics circuitry 12 and an analyte sensor 10 associated with the sensor electronics circuitry 12. In certain embodiments, the sensor electronics circuitry 12 (also referred to herein as ″analyte sensor electronics circuitry″) includes electronic circuitry associated with measuring and processing analyte sensor data or information, the electronic circuitry including algorithms associated with the processing and / or calibration of analyte sensor data / information. The sensor electronics circuitry 12 can be physically / mechanically connected to the analyte sensor 10 and can be integrated with (e.g., non - releasably attached to) or releasably attached to the analyte sensor.

[0031] The sensor electronics circuitry 12 is also operatively coupled to the analyte sensor 10 such that the components can be electromechanically coupled to each other (e.g., (a) before insertion into a patient's body, or (b) during insertion into a patient's body). The sensor electronics circuitry 12 can include hardware, firmware, and / or software that enable measurement and / or estimation of analyte levels in a recipient / user's body via the analyte sensor 10 (e.g., which can be / include a glucose sensor). For example, the sensor electronics circuitry 12 can include one or more potentiostats, a power source for powering the analyte sensor 10, other components for signal processing and data storage, and a telemetry module for transmitting data from the sensor electronics circuitry to one or more display devices. For example, the SS 8 can wirelessly transmit 20 data to the display devices 110, 120, 130, 140, and the display devices 110, 120, 130, 140 can wirelessly transmit 30 data to the SS 8. The electronics can be attached to a printed circuit board (PCB) within the SS 8, or a platform, etc., and can take various forms. For example, the electronics can take the form of an integrated circuit (IC), such as an application specific integrated circuit (ASIC), a microcontroller, a processor, and / or a state machine.

[0032] The sensor electronics circuitry 12 can include sensor electronics configured to process sensor information (such as sensor data) and generate transformed sensor data and displayable sensor information. Examples of systems and methods for processing sensor analyte data are described in more detail herein and in U.S. Patent No. 7,310,544, U.S. Patent No. 6,931,327, and U.S. Patent Publications 2005 / 0043598, 2007 / 0032706, 2007 / 0016381, 2008 / 0033254, 2005 / 0203360, 2005 / 0154271, 2005 / 0192557, 2006 / 0222566, 2007 / 0203966, and 2007 / 0208245, all of which are incorporated herein by reference in their entirety.

[0033] The analyte sensor 10 is configured to measure the concentration or level of an analyte in a subject. The term analyte is further defined in U.S. Application No. 2019 / 0336053. In some embodiments, the analyte sensor 10 is a subcutaneous, transdermal (e.g., percutaneous), or intravascular device. The analyte sensor 10 can use any analyte measurement method, including enzymatic, chemical, physical, electrochemical, spectrophotometric, polarimetric, calorimetric, iontophoretic, radiometric, immunochemical, etc. Additional details related to continuous glucose sensors are provided in paragraphs

[0072] -

[0076] of U.S. Application No. 13 / 827,577. Paragraphs

[0072] -

[0076] of U.S. Application No. 13 / 827,577 are incorporated herein by reference. In certain embodiments, the analyte sensor 10 is a glucose sensor. However, any other analyte sensor (such as a potassium sensor, a lactate sensor, an ammonia sensor, a creatinine sensor, etc.) is within the scope of the present disclosure. In some embodiments, the analyte sensor 10 can be a multi-analyte sensor configured to sense multiple analytes (e.g., glucose, potassium, lactate, and / or others).

[0034] Reference Figure 1 , the display devices 110, 120, 130, and / or 140 can be configured to display (and / or alarm) displayable sensor information (e.g., in a custom data packet transmitted to the display device based on their respective preferences) that can be transmitted by the sensor electronics circuitry 12. Each of the display devices 110, 120, 130, or 140 can respectively include a display, such as touchscreen displays 112, 122, 132, and / or 142 for displaying sensor information and / or analyte data to the user and / or receiving input from the user. For example, a graphical user interface (GUI) can be presented to the user for such purposes. In certain embodiments, the display device can include other types of user interfaces, such as a voice user interface for transmitting sensor information to the display device and / or receiving user input in place of or in addition to the touchscreen display. In certain embodiments, one, some, or all of the mobile devices of the display devices 110, 120, 130, 140 can be configured to display or otherwise transmit the sensor information (e.g., in a data packet transmitted to the corresponding display device) without calibration and / or any additional expected processing required for real-time display of the sensor data when the sensor information is transmitted from the sensor electronics circuitry 12.

[0035] Figure 1The multiple display devices 110, 120, 130, 140 depicted may include custom or proprietary display devices (e.g., analyte display devices) that are specifically designed to display certain types of displayable sensor information (e.g., numerical values and / or arrows in some embodiments) associated with analyte data received from the sensor electronics circuitry 12. In some embodiments, one of the multiple display devices 110, 120, 130, 140 includes a smart phone (such as display device 150) based on Android, iOS, or another operating system that is configured to display a graphical representation of continuous sensor data (e.g., including current data and / or historical data). In some embodiments, the health management system 100 further includes a medical delivery device (e.g., an insulin pump or pen). The sensor electronics circuitry 12 may be configured to transmit sensor information and / or analyte data to the medical delivery device. The medical delivery device (not shown) may be configured to administer a specific dose of insulin or another drug to the user based on the sensor information and / or analyte data received from the sensor electronics circuitry 12 (e.g., which may include a recommended insulin dose).

[0036] Figure 2 Illustrated is a more detailed view of the health management system 100 including the display device 150 communicatively coupled to the SS 8. In some embodiments, the display device 150 may be any one of the display devices 110, 120, 130, and 140 Figure 1 The communication path between the SS 8 and the display device 150 is shown as the wireless communication path 180. In some embodiments, the SS 8 and the display device 150 are configured to communicate wirelessly via the wireless communication path 180 using a short-range and / or distance wireless communication protocol.

[0037] Examples of short-range and / or distance wireless communication protocols include the Bluetooth and Bluetooth Low Energy (BLE) protocols. In some embodiments, other short-range wireless communications may include Near Field Communication (NFC), Radio Frequency Identification (RFID) communication, IR (infrared) communication, and optical communication. In some embodiments, wireless communication protocols other than low-range and long-distance wireless communication protocols may be used for the wireless communication path 180, such as WiFi Direct. The display device 150 and / or the SS 8 are also configured to connect to a network 190 (e.g., a local area network (LAN), a wide area network (WAN), the Internet, etc.). For example, the display device 150 may connect to the network 190 via a wired (e.g., Ethernet) or wireless (e.g., WLAN, wireless WAN, cellular, mesh network, personal area network (PAN), etc.) interface.

[0038] Additionally, the health management system 100 can include a server system 134, which in turn includes an analyte processor 135 that is coupled to a repository 136 (e.g., one or more computer storage systems, cloud-based storage systems, and / or services, etc.). In certain embodiments, the server system 134 can be located in or executed in a public or private cloud. In certain embodiments, the server system 134 is pre-positioned (″on-prem″) or executed. As discussed, the server system 134 is configured to receive, collect, and / or monitor information, including analyte data and related information, as well as encryption / authentication information from the SS 8 and / or the display device 150. Such information can include inputs in response to analyte data or inputs received in conjunction with an analyte monitoring or sensor application running on the SS 8 or the display device 150 (e.g., the user's glucose measurement results and other physiological / behavioral information). This information can be stored in the repository 136 and can be processed, for example, by an analysis engine capable of performing an analysis on the information. As further described below, an example of an analyte sensor application that can be executed on the display device 150 is the data retriever 121.

[0039] The display device 150 and the SS 8 are capable of communicating with the server system 134 via the network 190. The communication path between the display device 150 and the server system 134 is shown as the communication path 181 via the network 190. The communication path between the SS 8 and the server system 134 is shown as the communication path 182 via the network 190.

[0040] In some aspects, the analyte processor 135 included in the server system 134 is configured to analyze analyte data (and / or other patient-related data) provided via the network 190. As will be described in further detail later in conjunction with Figure 4 In certain embodiments, the analyte processor 135 is a cloud-based processor that is configured to analyze analyte data associated with a user received via the network 190 from the SS 8 and / or other devices (such as the display devices 110, 120, 130, and / or 140, etc.) and generate reports providing high-level information (such as statistical information) about the analyte measured over a certain time period. In embodiments where the analyte processor 135 is a cloud-based processor, the generated reports can be provided to one or more UIs of the display devices 110, 120, 130, and / or 140 in the form of one or more user interface (UI) views (e.g., Figure 4 the UIs 410A - 410C).

[0041] Although Figure 4Although not shown, in some embodiments, the analyte processor 135 may be implemented by one of the display devices 110, 120, 130, or 140, which are configured to process analyte data received from the SS 8 and / or other devices (such as other display devices). In such embodiments, the analyte processor 135 receives analyte data from the SS 8 (e.g., directly) and generates the UI views, reports, etc. described herein. In still other embodiments, some of the functionality 420A - 420J of the analyte processor 135 may be performed by one or more of the display devices 110, 120, 130, and 140, while the remaining functionality may be performed by a cloud-based server (e.g., the server system 134).

[0042] In some aspects, the analyte processor 135 or a report generator included therein may generate views for display at a user interface and / or for display on one or more widgets at the user interface. The user interface view may include one or more graphical representations, which include a plurality of different graphically distinct elements representing processed analyte data and / or other information.

[0043] In some aspects, the system 100 may dynamically generate performance reports and / or user interface views. For example, the analyte processor 135 may receive a request to generate a report or a user interface view. In response to the request, the analyte processor 135 may then select a report and / or an interface view to provide. In certain embodiments, the selection may be performed based on metadata. The metadata may include information about the request, information about the user or representing the user (e.g., the user's personal information, the user's analyte information provided by the SS 8, etc.), the type of device used to display the report and / or measure the analyte concentration level, rules, etc. The selection may be considered dynamic in the sense that the report and / or user interface view selection varies for each request based on the metadata. A report or a user interface view may then be generated to include at least one selected report and / or user interface view and then provided to the user interface for presentation.

[0044] Figure 2The components of the SS 8 are also illustrated in more detail. As shown, in some embodiments, the SS 8 includes an analyte sensor 10 that is coupled to sensor electronics circuitry 12. The sensor electronics circuitry 12 includes a sensor measurement circuit (SMC) 13 that is coupled to the analyte sensor 10 for processing and managing sensor data. The SMC 13 may also be coupled to a processor 11. In some embodiments, the processor 11 may perform some or all of the functions of the SMC 13 to obtain and process sensor measurements from the analyte sensor 10. The processor 11 may also be coupled to a storage device 14 and a real-time clock (RTC) 17 for storing and tracking sensor data. The processor 11 may also be coupled to one or more input sensors 21 for detecting user input.

[0045] In some embodiments, the acquisition and processing of sensor measurements and / or user input may be managed by an analyte sensor application 18 stored in the storage device 14. For example, as shown, the storage device 14 stores the analyte sensor application 18, which, when executed using the processor 11, causes the processor 11 to receive and process sensor measurements from the analyte sensor 10. In some embodiments, the analyte sensor application 18 is implemented as firmware executed by the processor 11 to provide control of the hardware elements included in the SS 8 (e.g., input sensors 21, connectivity interface 15, RTC 17, SMC 13, etc.). It is contemplated that in some embodiments, the SMC 13 may perform all of the functions of the processor 11, and vice versa.

[0046] The transceiver 16 may be configured with the necessary hardware and wireless communication protocols to enable wireless communication between the SS 8 and other devices such as a display device 150 and / or a server system 134. For example, as described above, the transceiver 16 may be configured with the necessary hardware and communication protocols to establish a Bluetooth or BLE connection with the display device 150. In some embodiments in which the SS 8 is configured to establish an independent communication path with the server system 134, the transceiver 16 may be configured with the necessary hardware and communication protocols (e.g., remote wireless cellular communication protocols such as GSM, CDMA, LTE, VoLTE, 3G, 4G, and 5G communication protocols, WiFi wireless communication protocols such as the 802.11 communication protocol, etc.) for establishing a wireless connection to a network 190 to connect with the server system 134. As discussed elsewhere, other short-range protocols may also be used for communication between the display device 150 and the SS 8, such as NFC, RFID, etc.

[0047] Figure 2Similarly, the components of the display device 150 are shown in more detail. As shown, the display device 150 includes a connectivity interface 128, a processor 126, a memory 127, one or more sensors 163, a display 125 for presenting a graphical user interface (GUI), and a storage device 123. A bus (not shown here) can be used to interconnect the various elements of the display device 150 and transfer data between these elements. The connectivity interface 128 is configured to receive sensor data from the SS 8 and send requests, instructions, and / or data to the SS 8 and the server system 134. The connectivity interface 128 can include multiple transceiver modules that can operate based on different wireless standards. For example, the connectivity interface 128 can be configured with one or more communication protocols, such as a wireless communication protocol for establishing a wireless communication path with the network 190 and / or a short-range wireless communication protocol (e.g., Bluetooth or BLE) for establishing a wireless communication path 180 with the SS 8.

[0048] Additionally, the connectivity interface 128 can in some cases include additional components for controlling radio and / or wired connections, such as a baseband and / or Ethernet modem, an audio / video codec, etc. The sensors 163 can include, but are not limited to, an accelerometer, a gyroscope, a GPS sensor, a heart rate sensor, etc. Note that although the sensors 163 are shown as being integrated with the display device 150, in some embodiments, one or more of the sensors 163 are independent sensors (e.g., separate from the display device 150).

[0049] Processor 126 may include processor sub - modules, including, for example, an application processor that interfaces with and / or controls other elements of display device 150 (such as connectivity interface 128, data retriever 121, co - located applications 124, display 125, RTC 163, memory 127, storage device 123, etc.). Processor 126 may include and / or be coupled to circuits such as logic circuits, memory, battery and power circuits, and other circuit drivers for peripheral and audio components. Processor 126 and any of its sub - processors may include logic circuits for receiving, processing, and / or storing data received and / or input to display device 150. Processor 126 and any of its sub - processors may also include logic circuits for receiving, processing, and / or storing data to be transmitted or relayed by display device 150. As described above, processor 126 may be coupled to display 125, connectivity interface 128, storage device 123, etc. via a bus. Thus, processor 126 may receive and process electrical signals generated by these respective elements and thereby perform various functions. By way of example, processor 126 may access stored content from storage device 123 and memory 127 in the direction of data retriever 121 and process the stored content for display by display 125. Additionally, processor 126 may process the stored content for transmission to SS8 and / or server system 134 via connectivity interface 128. Display device 150 may include other peripheral components not shown in detail in Figure 2 the figure.

[0050] In some embodiments, memory 127 may include volatile memory such as random access memory (RAM) for storing software programs and applications such as data and / or instructions of data retriever 121 and co - located applications 124. Display 125 presents a GUI associated with operating system 162 and / or data retriever 121. In various embodiments, a user may interact with data retriever 121 via the corresponding GUI presented on display 125. By way of example, display 125 may be a touch - screen display that accepts touch input. Data retriever 121 may process and / or present analyte - related data received by display device 150 and present such data via display 125. Additionally, data retriever 121 may be used to obtain, access, display, control analyte data and related messaging and procedures associated with SS8 (e.g., and / or any other medical device communicatively coupled to display device 150 (such as an insulin pump or pen)) and / or interface therewith, as described in further detail herein.

[0051] The storage device 123 can be a non-volatile storage device for storing software programs, instructions, data, etc. For example, the storage device 123 can store a data retriever 121 that, when executed using the processor 126, receives an input (e.g., via conventional hard / soft keys or a touch screen, voice detection, or other input mechanisms), and allows the user to interact with the analyte data and related content via the display 125. Similarly, the storage device 123 can store a co-located application 124 that, when executed using the processor 126, receives an input (e.g., via conventional hard / soft keys or a touch screen, voice detection, or other input mechanisms), and allows the user to interact with other non-analyte-related data and related content via the display 125.

[0052] In various embodiments, the storage device 123 can also store user input data and / or other data collected by the display device 150 (e.g., inputs from other users collected via the data retriever 121). The storage device 123 can further be used to store a large amount of analyte data received from the SS 8 (or any other medical data received from other medical devices such as insulin pumps, pens, etc.) for later retrieval and use, e.g., for determining trends and triggering alerts.

[0053] As described above, in certain embodiments, the SS 8 collects analyte data from the analyte sensor 10 and transmits the same or a modified version of the collected data to the display device 150. Data points regarding analyte values can be collected and transmitted over the lifetime of the analyte sensor 10 (e.g., in the range of 1 day to 30 days or longer). New measurements can be transmitted frequently to adequately monitor the analyte level. As described above, in certain embodiments, the SS 8 and the display device 150 can establish a communication channel between each other periodically and / or cyclically, rather than having the transmission and receiving circuits of each of the SS 8 and the display device 150 communicate continuously.

[0054] Thus, in such embodiments, for example, the SS 8 can communicate with the display device 150 at a predetermined time interval. The duration of the predetermined time interval can be chosen to be long enough such that the SS 8 does not consume too much power by transmitting data more frequently than necessary, but frequent enough to provide the display device 150 with substantially real-time sensor information (e.g., measured glucose value or analyte data) for output (e.g., via the display 125) to the user. Although in some embodiments the predetermined time interval is every five minutes, it should be understood that the time interval can vary to any desired length. In other embodiments, the transceivers can communicate continuously. For example, in certain embodiments, the transceivers can establish a session or connection between them and continue to communicate together until the connection is lost.

[0055] The data retriever 121 can be downloaded, installed, and initially configured / set up on the display device 150. For example, the display device 150 can obtain the data retriever 121 from the server system 134 or from another source (such as an app store, etc.) via a network (e.g., network 190). After installation and setup, the data retriever 121 can be configured to access, process, and / or interface with analyte data (e.g., whether stored on the server system 134, from the local storage device 123, from the SS8, or any other medical device). By way of example, the data retriever 121 can present a menu including various controls or commands that can be executed in conjunction with the operation of the SS8, the display device 150, one or more other display devices (e.g., display devices 110, 130, 140, etc.), and / or one or more other partner devices such as an insulin pump. For example, the data retriever 121 can be used to interface with or control other display devices and / or partner devices, such as to deliver or provide analyte data to them, including, for example, by directly receiving / sending analyte data to / from other display devices and / or partner devices, and / or by sending instructions for the SS8 and other display devices and / or partner devices to be connected, etc.

[0056] After downloading the data retriever 121, as an initial step among the initial steps, the data retriever 121 can guide the user to wirelessly connect the display device 150 to the user's SS8, which the user may have placed on their body. The wireless communication path 180 between the display device 150 and the SS8 allows the SS8 to transmit analyte measurements to the display device 150 and allows the two devices to participate in any of the other interactions described above.

[0057] Figure 3 A perspective view of the housing 310 of the SS8 according to certain embodiments disclosed herein is illustrated. In some embodiments, the housing 310 can include a clamshell design. The SS8 can also include, for example, a power source (e.g., a battery) for providing power to the analyte sensor 10 and the analyte sensor electronics circuitry 12.

[0058] The outer housing 310 may include a hole that is disposed through a portion of the outer housing 210 and is adapted for the analyte sensor 10 and the needle to be inserted through the bottom of the SS 8. In some embodiments, the hole may be a channel or an elongated slot. The SS 8 may further include an adhesive patch 220 that is configured to secure the SS 8 to the skin of the recipient. The adhesive patch 220 may include an adhesive suitable for skin adhesion, such as a pressure-sensitive adhesive (e.g., acrylic, rubber-based, or other suitable type) that is bonded to a carrier substrate (e.g., spunlace polyester, polyurethane film, or other suitable type) for skin attachment, although any suitable type of adhesive may also be implemented.

[0059] Figure 4 is a block diagram conceptually showing an analyte processing system in accordance with some example aspects of the present disclosure. As Figure 4 shown, the processing system 400 may include one or more user interfaces 410A - 410C, such as browsers, applications, widgets, and / or any other type of user interface configured to allow access to and / or interaction with the analyte processor 135 via, for example, the network 190 and the load balancer 412. The analyte processor 135 may be further coupled to a repository 136. The user interfaces 410A - 410C may be associated with or provided as part of the display devices 110, 120, 130, 140, and / or any other display device used by the user to view the user interface views, reports, etc. described herein.

[0060] The processing system 400 may also receive data from source systems, such as healthcare management systems, patient management systems, prescription management systems, electronic medical record systems, personal health record systems, etc. This source system information may provide metadata for dynamic report generation.

[0061] The processing system 400 may be implemented in a variety of configurations, including stand-alone, distributed, and / or cloud-based frameworks. The processing system 400 may be implemented in a cloud-based architecture, such as a software-as-a-service (SaaS) arrangement, where the analyte processor 135 is hosted on computing hardware, such as servers and databases maintained at a location remote from the entity (e.g., remote from end users such as the user, healthcare provider, etc.) and accessed by authorized users via a user interface (such as the user interfaces 410A, 410B, and / or 410C) and / or the data retriever 121 through the network 190.

[0062] Referring again to Figure 4, in some example aspects, the processing system 400 may provide a cloud-based diabetes data management framework that is configured to receive patient-related data from various devices. The various devices may include, but are not limited to, medical devices, glucose meters, continuous glucose monitors, SS 8, display devices 110, 120, 130, and / or 140, source systems, devices that provide food consumption information associated with the food consumed by the user (e.g., such as carbohydrates), drug delivery data, time of day, temperature sensors, and / or exercise / activity sensors. In some example aspects, cloud-based diabetes data management may programmatically receive data with little (or no) intervention on the user side.

[0063] The data received from devices, source systems, etc. can be in multiple formats and can be structured or unstructured. For example, in some example aspects, the processing system 400 may receive raw sensor data that has been minimally processed or analyzed. The received data can then be formatted, processed (e.g., analyzed), and / or stored to enable analyte data visualization. For example, the data retriever 121 may be implemented at one or more devices (such as the display device 150 coupled to the SS 8). In this example, the data retriever 121 may format the sensor data into one or more common formats compatible with the analyte processor 135 and may provide the formatted data to the analyte processor 135 such that the analyte processor 135 can analyze the formatted data.

[0064] Although Figure 4 a single data retriever 121 is depicted, in some example aspects, multiple data retrievers 121 may be used to format data from multiple devices and / or systems. In certain embodiments, the data retriever 121 may execute on or be hosted at any other display device among the display devices (such as display devices 110, 120, 130, and / or 140) that communicate with the SS 8.

[0065] The processing at the analyte processor 135 may also include associating metadata with the data received from the devices and / or sensors. Examples of metadata may include, but are not limited to, patient information, keys for encrypting data, patient accelerometer data, location data (e.g., the location of the patient or the location of the patient's clinic), time of day, date, the type of device that generated the associated sensor data. Patient information may include the patient's age, weight, gender, pregnancy due date, gestational age, home address, and / or any past health-related information, such as whether the patient has been diagnosed with type 1 or type 2 diabetes, hypertension, or has any other health condition.

[0066] In Figure 4In the example of, user interfaces 410A - 410C can be used by one or more entities, such as end users, healthcare providers, clinics, patients, research groups, health systems, medical device manufacturers, etc. These entities can remotely access processing system 400 via user interfaces 410A - 410C (e.g., of display devices 110, 120, 130, and / or 140) to request actions, such as retrieving analyte data, providing analyte data, requesting analysis of analyte data, requesting generation of reports (including modules with descriptive measurements presenting analyte data, views presenting analyte data and reports), etc. Other examples of actions include providing sensor data, such as glucose data, carbohydrate data, insulin pump data, etc., to analyte processor 135, initiating processing of sensor data, initiating analysis of sensor data, and storing data in repository 136. In some example aspects, the computing resources provided by analyte processor 135 can include one or more physical servers that are virtualized to provide the analyte processing services disclosed herein.

[0067] In some example aspects, analyte processor 135 can process the received data by performing one or more of the following: associating metadata with data received from devices, sensors, source systems, and / or data retrievers, determining one or more descriptive measurements, such as statistical data (e.g., median, inner and outer quartile ranges, mean, sum, n, and standard deviation), validating and verifying the integrity of data received from devices, sensors, source systems, and / or data retrievers, processing the received data based on metadata (e.g., to select certain patients, devices, conditions, diabetes types, etc.), and / or associating data received from devices, sensors, source systems, and / or data retrievers such that the data can be compared and combined for processing and analysis.

[0068] In addition, the results of any processing performed by analyte processor 135 can be used to generate views presenting descriptive measurements and / or comparisons of analyte data (e.g., Figures 5 to 11 the user interface views depicted in). Descriptive measurements and / or comparisons can be presented as, for example, graphs, bar charts, static charts, diagrams, badges, tables, figures, maps, drawings, and / or other visualizations.

[0069] In addition, the output generated by processing system 400 can be provided via one or more delivery mechanisms, such as report delivery module 420K. For example, report delivery module 420K can provide the output generated by analyte data processing system 400 via email, secure email, printout, text, presentation for display at a user interface (such as at user interfaces 410A - 410C hosted on a tablet, phone, or other processor), machine - to - machine communication (e.g., via third - party interface 420J), and any other communication mechanism.

[0070] In some examples, views can be dynamically customized for use by entities such as end users, clinicians, healthcare providers, or device manufacturers. Additionally, views can be customized based on the type and / or quantity of sensors and systems providing data to processing system 400 and / or the metadata or its type available to processing system 400. This customization can be performed by the user, programmatically by processing system 400, or a combination of both.

[0071] In some examples, the analyte processor 135 can include: an authenticator / authorizer 420A for authorizing access to the analyte processor 135; a data parser 420B for parsing requests sent to the analyte processor 135; a computing engine 420H for receiving data from sensors and processing the received data into counts for a histogram; a logic component 420C; a data filter 420D; a data formatter 420E; a report generator 420G; a pattern detector 420I; a report delivery module 420K for delivering views in the format of a destination; and a third-party access application programming interface to allow other systems and devices to access and / or interact with the analyte processor 135.

[0072] The analyte processor 135 can receive requests to perform actions (e.g., provide data, store data, analyze / process data, request reports, etc.) from a user interface such as user interfaces 410A - 410C. Before the analyte processor 135 services the request, the analyte processor 135 can process the request to determine if the request is authorized and authenticated. For example, the authenticator and authorizer 420A can determine if the sender of the request is authorized by requiring the user to provide security credentials (e.g., user identifier, password, stored security token, and / or verification identifier provided via text message, phone, or email) at the user interface presented on a computer. If authorized, the authenticator and authorizer 420A can authenticate the sender of the request to check if the security credentials associated with the sender of the request indicate that the sender (e.g., the user at user interface 410A) is indeed permitted to access specific resources at the analyte data processing system 400 to perform actions such as storing (or uploading) data at the repository 136, performing analysis / processing of data, and / or requesting the generation of a user interface view.

[0073] Once authorized and / or authenticated, the request received at the analyte processor 135 is then parsed by the data parser 420B to separate any data from the request, such as sensor data, metadata, etc. In some aspects, the data parser 420B can perform checks on data formatting, device-related error codes, data validity, duplicate data points, and / or other aspects of the data. Additionally, the data parser 420B can associate additional metadata with the separated data. The metadata can include any metadata described herein, including the owner of the data, the key for tracking the data, an encryption key unique to each user, the time of day, date information, one or more locations where the data is (or will be) stored, etc. In some example aspects, the data parsing 420 can provide the data to the compute engine 420H for formatting the data into counts and histograms, as further described below.

[0074] In some example aspects, the request (or the parsed data therein) can be processed by the compute engine 420H. The compute engine 420H can preprocess the data received from the devices, sensors, etc. to form "counts". The counts can represent measured values, such as analyte values measured by a sensor, glucose values measured by a sensor, continuous glucose values measured by a sensor, and / or other diabetes-related information, such as carbohydrates consumed, temperature, level of physical activity, etc., and the frequency at which the measured values occur.

[0075] The compute engine 420H can then use the counts 508 to perform additional processing. The additional processing can include storing the counts in a repository 136, which can include one or more databases for storing the counts. Additionally, the counts can be stored with metadata, such as time / date information of the day. Further, as noted, the counts can be encrypted before being stored in the repository 136.

[0076] The compute engine 420H can also use the counts to update one or more histograms. For example, instead of using the raw sensor data values to track and process a user's analyte levels over a period of time, the compute engine 420H can convert the data values to counts. For a given user, the counts can be added to a histogram. In some example aspects, the compute engine 420H can generate multiple histograms for a given user over multiple given time periods. In some example aspects, the compute engine 420H can also update other histograms representing aggregate count information.

[0077] Although the description of the computing engine 420H refers to histograms, as used herein, a histogram refers to a data structure that includes one or more values associated with one or more time intervals. For example, a histogram can represent one or more values associated with intervals corresponding to one or more time intervals, such as occurrence frequencies. Additionally, the data structure can be stored in a database such that the data structure can be readily read accessed, such as in a row of the database (or, for example, in a column if a columnar database is used).

[0078] In some example aspects, the repository 136 stores histograms of counts in a database. For example, the repository 136 can store data for a user over a certain time range (such as 1 day, 2 days, 7 days, 14 days, 30 days, and / or any other time range). In this example, the days can be subdivided into epochs, each having a corresponding histogram stored in the repository 136. Additionally, each histogram can be stored as a row (or column) in the database at the repository 136 to facilitate rapid data access.

[0079] Figure 4 The logic component 420C of can also process requests to perform actions (such as storing, retrieving, processing, analyzing, reporting data, etc.) at the analyte processor 135. The logic component 420C can also determine one or more descriptive measurements, such as statistical data (e.g., median, inter and outer quartile ranges, mean, sum, standard deviation, etc.), based on counts, histograms, and / or received sensor data. The logic component 420C can provide these descriptive measurements to the report generator 420G for report generation (such as generating views for presentation at the user interfaces 410A-C). For example, the mean can be determined by adding the product of the counts and the interval values and then dividing the sum by the sum of the counts.

[0080] Figure 4 The pattern detector 420I of can perform pattern detection on data (such as sensor data representing blood glucose data, analytes, insulin pump data, carbohydrate consumption data, etc.) processed by the analyte processor 135 and stored in the repository 136. Additionally, the pattern detector 420I can retrospectively detect patterns over a predetermined time period defined by the processing system 400 and / or the user.

[0081] In some example aspects, the pattern detector 420I may receive input data from the repository 136. The input data may include, for example, analyte concentration data from a continuous analyte sensor, other analyte data (such as rate of change, predicted concentration, etc.). In some example aspects, the input data may also include other data, such as temperature data, accelerometer data, insulin pump data, carbohydrate consumption data, food intake data, nutritional intake or breakdown information, time of day, exercise and / or activity data, wake / sleep time intervals, medication information, or other similar data related to user activities that may affect one or more biological parameters of the user.

[0082] In addition, the input data may include historical data obtained over a certain time frame, such as 8 hours, 1 day, 2 days, 7 days, 14 days, 30 days, and / or any other time period. For example, the input data may include "counts" representing monitored analyte detection levels (e.g., glucose concentration levels) received and stored at the processing system 400 over a time period covering a four-week (or longer) time span. As described above, the "counts" may be stored in the repository 136 along with metadata (such as time / date information of the day) for later use as input data. In another example, the input data may include a histogram updated by the user's "counts". The histogram may include an x-axis of analyte concentration values and a y-axis of the number of occurrences of each analyte concentration value. A histogram associated with a given user / patient may be an example of input data used by the pattern detector 420I.

[0083] The pattern detector 420I may analyze patterns in the input data. For example, patterns may be identified based on one or more predefined rules (also referred to as criteria or triggers). In addition, one or more of the predefined rules may be variable and adjustable based on user input. For example, some types of patterns and the rules defining the patterns may be selected, turned on and off, and / or modified by the user, the user's doctor, or the user's guardian, but the processing system 400 may also select, adjust, and / or modify the rules programmatically. In another example aspect, one or more patterns may be based on predefined rules set by factory settings or device settings.

[0084] The pattern detector 420I may detect patterns and generate an output that may be provided to the report generator 420G. In addition, the output may include a retrospective analysis of the input data and any patterns determined by the pattern detector 420I.

[0085] The data filter 420D can be used to check whether the output generated by the analyte processor 135 (such as responses, reports, etc. for certain types of data) violates data rules. For example, the data filter 420D can include data rules to check whether the response includes data to destinations that are not authorized or permitted to receive the response, such as PII (e.g., based on authorization, authentication, and the corresponding role of the user making the request).

[0086] The data formatter 420E can format the data for conveyance based on the type of destination. For example, the data formatter 420E can format a view based on whether the view is being sent to a printer, a user interface, a secure email, another processor, and / or any other similar device or platform.

[0087] The report generator 420G can generate one or more reports and / or user interface views. The report / view can provide descriptive information representing the sensor data received at the analyte processor 135, such as statistical information. Additionally, the report / view can provide a retrospective analysis of the sensor data stored at the repository 136. For example, the report / view can provide statistical information based on sensor data (and / or corresponding histograms including counts) within a certain time range (such as 8 hours, 1 day, 2 days, 7 days, 14 days, 30 days, and / or any other time frame). Further, the report / view can allow a user to view information and identify trends and other health - related issues.

[0088] In some example aspects, the report generator 420G generates reports and / or views based on the data received and / or stored at the processing system 400 (e.g., using sensor data, metadata, counts, histograms, information related to the request for generating the report, etc.). For example, the report generator 420G can select one or more features or modules based on a request for generating a report received by a user to provide as part of the UI to be displayed (e.g., Figures 5 to 11 ) to the user. In certain embodiments, the request can include information such as the identity of the patient, the identity of the requesting device, the type of the requested report, etc. The request can also specify the time range of the report and / or any other information required to authenticate the requesting device or user.

[0089] The report generator 420G can also select one or more features or modules based on metadata including rules, templates, etc. to provide as part of the display (e.g., Figures 5 to 11)Provided as part of the UI to the user. The metadata may describe one or more of the following: the type of available data; the amount of data; the type of device in use; user preferences; the size of the user interface available for presenting the report; patient demographics; patient information, including report preferences, the type and quantity of devices used, and the display size used for presenting the report, as well as other data related to the user, device, etc.; rules, such as whether a module can be used with certain devices (e.g., certain reports may only apply to continuous glucose measurements, not discrete measurements), whether a module can be used with certain patient conditions (e.g., a caregiver can establish rules based on whether a patient is pregnant to require a specific report), whether a module can be used at certain display sizes, whether a module can be used given a certain amount of data or device type; and / or one or more templates. For example, the selection of modules can be performed based on metadata that includes user preferences for certain modules, the type of device used, the display area of the device, and rules that define which modules can be used given the type of device, patient state / condition, and display area of the device. Additionally, the metadata can be stored in a repository such as repository 136, although some metadata can be provided as part of the request received at 710.

[0090] A template can define the placement of one or more modules in a report. The framework that defines the placement of each module can be a template (also referred to as a model or wireframe). Additionally, templates can be defined for certain devices or displays such that when a request is made and / or metadata is obtained, the report generator 420G can dynamically select one or more modules into a predefined template based on the metadata. For example, a certain display device may have a size that allows four modules to be displayed in one way, while another display device may have a size that allows four modules to be displayed in a different way, etc.

[0091] In some example embodiments, the metadata can include multiple predefined templates configured for a specific patient, a specific type of patient (e.g., a pregnant patient), a specific caregiver, a specific healthcare professional, a group of patients (e.g., a cohort), a merchant, etc. Thus, modules can be dynamically selected based on an evaluation of the metadata. Additionally, in some embodiments, using templates can allow for faster execution of the dynamic generation of modules compared to not using templates. In any case, when the report generator 420G selects which modules 710A - 710D to include in the report, the report generator 420G can then obtain the underlying data (e.g., sensor data, demographics, etc.) to be used in the selected modules. Figures 5 to 11 Examples of reports and / or user interface views that include features (also referred to as modules) are depicted.

[0092] According to some aspects, the logic component 420C and the pattern detector 420I can be used to determine one or more descriptive measurements, patterns, or relationships for effective visualization. As previously described, the logic component 420C can determine the median, interquartile and outer quartile ranges, mean, sum, standard deviation, and other statistical measurements based on counts, histograms, and / or received sensor data. The pattern detector 420I can analyze the relationships between data to determine patterns. The relationships in the input data that can lead to the identified patterns can include, for example, analyte levels that exceed the target analyte range (e.g., which can be defined by the user, healthcare provider, processing system 400, based on whether the patient is pregnant, or a combination thereof), analyte levels below the target analyte range, rapid changes in analyte levels from low to high (or vice versa), the time of day when low, high, a certain range, or rapid analyte level events occur, and the number of days when low, high, a certain range, and / or rapid analyte level events occur.

[0093] Other examples of the types of relationships in the input data that can be considered patterns include extremely high and / or extremely low analyte events by time of day. For example, in the aspect where the analyte being measured can be glucose, a pattern can be identified when the user has a low analyte concentration at approximately the same time of day (e.g., a hypoglycemic event). Another type of pattern that can be identified is the "high rebound" situation. For example, high rebound can be defined as a situation where the user overcorrects a hypoglycemic event by excessively increasing glucose intake and thus enters a hyperglycemic event. These events can be detected based on one or more predefined rules. Detectable patterns include hyperglycemic patterns, hypoglycemic patterns, patterns associated with the time of day or week, weighted scores for different patterns based on frequency, order, and severity.

[0094] In some aspects, the pattern can be based on whether the patient is pregnant, the gestational age of the pregnancy, the expected due date of the pregnancy, the user / patient's custom sensitivity, the transition from an extremely low pattern to an extremely high pattern, the amount of time spent in a severe event, and the combination of analyte changes and time information. The detected pattern can also be a pattern of high variability in the analyte data. Additionally, the pattern can be based on a combination of previous pattern data and the currently detected situation, and the combined information generates a predictive alert.

[0095] Figure 5 An example user interface view 500 associated with sensor data representing analyte levels (particularly glucose concentration levels) in a recipient according to some example aspects of the present disclosure is shown. The patterns and statistical data identified by the logic component 420C and the pattern detector 420I can be presented in a performance report. As Figure 5 shown, a weekly report can be provided to the user of the diabetes management application to provide relevant insights into the user's retrospective glucose values, patterns, and trends over time.

[0096] In the time range feature 510 of the user interface view 500, a time range stacked bar chart can be provided to represent the percentage of time the user is within the target glucose range, the very high or high glucose range, and the very low or low glucose range during a specified period (e.g., any consecutive seven-day period). The target glucose range can be defined as different ranges for daytime (e.g., 6:00 AM - 10:00 PM in the shown example) and nighttime (e.g., 10:00 PM - 6:00 AM in the shown example) times. The user's time-range percentages can also be compared to the time-range percentages of the previous week.

[0097] In some examples, different colors can be used to present the stacked bar chart to distinguish the percentage of time the user is within the target glucose range, the very high or high glucose range, and the very low or low glucose range during the specified period. In some examples, blocks of different sizes (stacked in the stacked bar chart) can be used for each range to present the stacked bar chart. The different sizes may be related to the amount of time the user spends within each range. For example, the largest block size in the stacked bar chart can represent the glucose range in which the user spends the most amount of time during the specified period, and the smallest block size in the stacked bar chart can represent the glucose range in which the user spends the least amount of time during the specified period.

[0098] In the analyte statistics feature 520 of the user interface view 500, average glucose and standard deviation statistics (e.g., determined by the logic component 420C) can be presented to the user. The average glucose and standard deviation can be calculated based on a specified period (e.g., any consecutive seven-day period).

[0099] In the user mode feature 530 of the user interface view 500, the patterns of the user's daytime lows / highs and nighttime lows / highs can be reported. A daytime or nighttime low pattern can be identified if the user has a pattern of low glucose concentration levels at approximately similar times each day during a specified period (e.g., any consecutive seven-day period). A daytime or nighttime high pattern can be identified if the user has a pattern of high glucose concentration levels at approximately similar times each day during a specified period (e.g., any consecutive seven-day period).

[0100] In the trend feature 540 of the user interface view 500, a compilation of the user's time - range can be presented as a scatter plot with a best - fit line. The best - fit line expresses the relationship between data points and identifies the time - range trend of the user within a certain time period (e.g., a twelve - hour period, from 12:00 AM to 12:00 AM in the example shown) within a specified time frame (e.g., any consecutive seven - day period). Additionally, target glucose ranges for daytime and nighttime can be provided in the graph. The target glucose ranges can be defined as different ranges for daytime and nighttime. For example, as shown in the fourth feature, the graph can use a sun - shaped graphic to identify the daytime target glucose range (e.g., the daytime range shown in this feature is 80 mg / dL - 180 mg / dL) and can use a moon - shaped graphic to identify the nighttime target glucose range (e.g., the nighttime range shown in this feature is 90 mg / dL - 200 mg / dL). The trend feature 540 can also provide bar graphs of different colors to distinguish the time when the user is within a high or extremely high glucose range, the time when the user is within a low or extremely low glucose range, and the time when the user is within the glucose range during a twelve - hour period within a specified time frame.

[0101] In some examples, the features of the user interface view 500 can be presented to the user in a vertical format (e.g., as Figure 5 shown), such that feature one can be at the top of the page (e.g., for an email) and feature five can be at the bottom of the page. In other examples, any feature of the user interface view 500 can alternatively be presented in a horizontal format (e.g., as Figures 9A to 9D , Figure 10A and Figure 10B shown).

[0102] Tracking, reporting, and visualizing pregnancy-related analyte data

[0103] As discussed above, the various embodiments described herein include techniques for tracking, reporting, and visualizing pregnancy - related information (such as pregnancy - specific analyte data and educational information). In certain embodiments, an option to enable a pregnancy assistant is provided to the user (e.g., Figure 6A ). Selecting the pregnancy assistant results in a guided sequence being displayed to the user, enabling the user to enter the expected due date of the pregnancy (e.g., Figure 6C ), to view and / or modify the target analyte ranges and / or one or more analyte thresholds (e.g., Figure 6D and Figure 6E ), and / or set one or more alerts / warnings to remind the user to record fasting glucose concentration values and / or post - meal glucose concentration values.

[0104] When the pregnancy assistant is enabled, one or more user interface (UI) elements are automatically modified to reflect pregnancy-specific information, such as pregnancy-specific target analyte ranges and / or analyte thresholds, pregnancy-specific widgets, and / or pregnancy-specific educational information (e.g., Figure 7B and Figures 7E to 7G ). For example, one or more features included in the user interface view 500 (e.g., the time range feature 510 and the trend feature 540) can be modified to reflect pregnancy-specific information, such as a pregnancy-specific target glucose range (e.g., Figures 9A to 9C ). Enabling the pregnancy assistant can also result in assisting the user when recording key metrics related to managing diabetes during pregnancy, such as by displaying reminders for recording fasting glucose concentration values and postprandial glucose concentration values (also referred to as postprandial blood glucose concentration values) and / or by calculating fasting glucose concentration values based on the wake-up time selected by the user. In some embodiments, the information provided by the UI (e.g., pregnancy-specific educational materials) is updated based on gestational age during the pregnancy.

[0105] Then, after the due date, the pregnancy assistant is disabled, such as by automatically disabling the pregnancy assistant or providing the user with an option to disable the pregnancy assistant within a predetermined period after the due date has passed (e.g., Figure 7B and Figure 11 ). When the pregnancy assistant is disabled, one or more UI elements are automatically modified to revert to normal target analyte ranges and / or non-pregnancy-specific information (e.g., Figure 5 ). These and other techniques are described in more detail below in connection with Figures 6A to 12 .

[0106] Figures 6A to 6E Illustrates a boot sequence presented to the user when the pregnancy assistant is enabled, according to some example aspects of the present disclosure. As shown, the user selects a UI element 610 included in the connection dashboard 600 ( Figure 6A ), and in response, a boot sequence is presented.

[0107] As part of the boot sequence, information related to the features of the pregnancy assistant is displayed to the user (e.g., Figure 6B ). Additionally, a calendar UI element 620 is automatically displayed to enable the user to enter the due date (e.g., Figure 6C ), and a target range UI element 630 is automatically displayed to enable the user to view and / or modify a pregnancy-specific target analyte range (e.g., a pregnancy-specific glucose concentration range) (e.g., Figure 6D ). When the "More Information" UI element 635 is selected (e.g., Figure 6E ), information 640 related to the pregnancy-specific target range analyte range can also be displayed to the user.

[0108] When the pregnancy assistant is enabled, one or more UI elements are automatically modified to reflect pregnancy-specific target analyte ranges and / or pregnancy-specific information. For example, as Figure 7A shown, the connected dashboard 600 is automatically modified to include pregnancy assistant UI elements 710. In some embodiments, the pregnancy assistant UI elements 710 display information indicating the gestational week (e.g., "Week 26"), the date range associated with the gestational week (e.g., April 22, 2022 to April 29, 2022), and / or the expected due date of the pregnancy.

[0109] As Figure 7B shown, selecting the pregnancy assistant UI element 710 causes the pregnancy assistant dashboard 720 to be displayed. As discussed above, key metrics related to managing diabetes during pregnancy include fasting glucose concentration values and postprandial glucose concentration values. Thus, when the postprandial glucose UI element 730 is selected, the user is presented with options for selecting when a postprandial analyte reading will be taken. For example, as Figure 7C shown, the user can select to record sensor readings associated with postprandial glucose concentration values for a specific postprandial duration such as one hour, two hours, or three hours after each meal. Additionally, as Figure 7D shown, a date / time UI element 770 can be presented to the user to enable the user to select the wake-up time at which a fasting analyte reading (e.g., fasting glucose concentration value) will be recorded.

[0110] In various embodiments, during a boot sequence, the user selects the time they typically wake up and one or more times they typically eat. In such embodiments, fasting glucose readings and postprandial glucose readings can then be automatically obtained (e.g., via SS 8) based on the wake-up time and meal times entered by the user. Additionally or alternatively, one or more reminders for recording the wake-up time and / or meal times can be displayed to the user. In some embodiments, the user wake-up time can be automatically detected, such as based on accelerometer data (e.g., obtained by SS 8 or the display device 150) and / or based on third-party data (e.g., data obtained via an activity tracker worn by the user, etc.). Additionally or alternatively, one or more meal times can be automatically detected, such as based on glucose readings obtained by SS 8 and / or based on third-party data (e.g., data entered into a meal logging application, etc.). Further, in some embodiments, the wake-up time and / or one or more meal times can be automatically detected by one or more algorithms and / or analyte level patterns (such as spike detection algorithms implemented by SS 8 and / or the display device 150). The user can also be provided with the option to manually adjust the wake-up time and / or meal times that have been detected by any of the techniques described herein.

[0111] The Pregnancy Assistant Dashboard 720 also enables a user to view educational resources related to gestational age. For example, upon selection of the Weekly Tip UI element 740, educational information corresponding to the current gestational week of the pregnancy can be presented to the user, such as Figure 7E and Figure 7F shown. Options to select and view educational information corresponding to past and / or future gestational weeks of the pregnancy can also be presented to the user. In some embodiments, pregnancy milestones are automatically displayed to the user based on gestational age (e.g., once a week, once every two weeks, once a month, etc.) to indicate whether the user is maintaining glucose levels within a pregnancy-specific target analyte concentration range, whether immediate attention is required, or whether treatment adjustments are needed.

[0112] Upon selection of the Resources UI element 750, various educational information 790 can be presented to the user, which includes advice on managing diabetes during pregnancy, such as Figure 7G shown. The Pregnancy Assistant Dashboard 720 can also include a UI element 760 that enables the user to disable the Pregnancy Assistant, such as Figure 7B shown.

[0113] As Figure 7H shown, enabling the Pregnancy Assistant can result in the automatic generation and presentation of a Historical Dashboard 780 to the user. The Historical Dashboard 780 enables the user to view pregnancy-specific information, including meal-related data (e.g., meal time, amount of macronutrients, text description of the meal), analyte concentration readings corresponding to the meal (e.g., post-meal glucose readings), fasting glucose readings, physical activities performed by the user (e.g., exercise), medication intake, and / or diseases / stress experienced by the user (e.g., specific diseases, stress events, etc.). Enabling the Pregnancy Assistant can also result in the automatic generation of pregnancy-specific information (and / or reports prepared based on pregnancy-specific information) and transmission to the HCP to help maintain a consistent log of pregnancy-specific information for the pregnant patient, such as meals, post-meal glucose readings, and fasting glucose readings.

[0114] As discussed above, enabling the Pregnancy Assistant results in the automatic modification of one or more target analyte ranges to reflect pregnancy-specific target analyte ranges. In some embodiments, the patterns and statistics identified by the logic component 420C and the pattern detector 420I can be presented in a performance report for achieving pregnancy-specific target analyte ranges. For example, as Figure 8A and Figure 8B shown, upon enabling the Pregnancy Assistant, a UI view 800 that displays analyte concentration readings as a function of time (e.g., over a 3-hour period, 6-hour period, 12-hour, or 24-hour period) changes from displaying a normal target analyte concentration range 810 (e.g., Figure 8AThe 70 mg / dL - 180 mg / dL shown is automatically modified to alternatively reflect a pregnancy - specific target analyte concentration range (e.g., 65 mg / dL to 140 mg / dL, as Figure 8B shown).

[0115] In Figures 9A to 9C In another example, as shown, when the pregnancy assistant is enabled, the UI view 900 that displays the time - range feature 910 and the analyte statistics feature 930 is automatically modified from showing the normal target analyte concentration range (e.g., 70 mg / dL to 180 mg / dL) to alternatively reflect a pregnancy - specific target analyte concentration range (e.g., 65 mg / dL to 140 mg / dL). The UI view 900 may also include a switching UI element 905 that enables a user to switch between the normal target analyte concentration range and the pregnancy - specific target analyte concentration range. In some embodiments, the pregnancy - specific target analyte concentration range implemented in any of the reports, UI views, and widgets described herein may be automatically updated based on the user's due date and / or gestational age of the pregnancy. For example, the pregnancy - specific target analyte concentration range may be automatically modified to reflect a more stringent target analyte concentration range as the gestational age increases.

[0116] In response to the user interacting with the switching UI element 905, one or more widgets (e.g., UI view 900) included in the performance report are updated to reflect the normal target analyte concentration range ( Figure 9D ) or the pregnancy - specific target analyte concentration range ( Figure 9A ). For example, when interacting with the switching UI element 905 to select the pregnancy - specific target analyte concentration range, the stacked bar chart included in the time - range feature 910 is automatically modified to reflect the percentage of time that the user's analyte levels are within the pregnancy - specific target analyte concentration range.

[0117] In addition to modifying the target analyte concentration range, when the pregnancy assistant is enabled, one or more UI views may be automatically modified to present pregnancy - specific information and / or UI elements for tracking pregnancy - specific key metrics, such as by updating the UI view (e.g., UI view 900) to display a post - meal glucose UI element 920 and / or a fasting glucose UI element 940 (e.g., fasting glucose UI element 940 - 1 associated with the current week and fasting glucose UI element 940 - 2 associated with the previous week). In some embodiments, the post - meal glucose UI element 920 displays a stacked bar chart that indicates the frequency with which the user's post - meal glucose concentration values are above or below the upper limit of a pregnancy - specific analyte concentration threshold (e.g., 140 mg / dL). As Figure 9A and Figure 9BAs shown, the fasting glucose UI element 940 displays fasting glucose concentration values for a given time period (e.g., within a previous 7-day time period), and indicates (e.g., using color coding) whether each fasting glucose concentration value is above or below a target fasting glucose concentration value (e.g., 95 mg / dL).

[0118] Additionally, as Figure 9C shown, the post-meal glucose UI element 950 displays post-meal glucose concentration values for different meals consumed at different times on different days, enabling the user to view the text description of the meal, the macronutrient (e.g., carbohydrate) content of each meal, the glucose concentration value immediately after each meal, and whether the post-meal glucose concentration value is above or below the upper limit of a pregnancy-specific target analyte concentration range (e.g., 140 mg / dL at 1 hour post-meal or 120 mg / dL at 2 hours post-meal). In response to the user interacting with the switch UI element 955, the graph 952 that plots the glucose concentration values as a function of time of day is updated to reflect the 1-hour post-meal glucose concentration value (e.g., 140 mg / dL) or the 2-hour post-meal glucose concentration value (e.g., 120 mg / dL).

[0119] Furthermore, one or more existing widgets can be automatically modified to include additional pregnancy-specific information. For example, the existing analyte statistic feature 930 can be automatically modified from displaying an average glucose concentration value to displaying both a fasting glucose concentration value (e.g., average fasting glucose value) and a post-meal glucose concentration value (e.g., at 1 hour and 2 hours post-meal).

[0120] In Figure 10A and Figure 10B another example shown, when the pregnancy assistant is enabled, the UI view 1000 that displays the trend feature 1010 is automatically modified from displaying a normal target analyte concentration range (e.g., 70 mg / dL to 180 mg / dL, as Figure 10A shown) to instead reflect a pregnancy-specific target analyte concentration range (e.g., 65 mg / dL to 140 mg / dL, as Figure 10B shown). Other pregnancy-specific target analyte concentration ranges (e.g., 63 mg / dL to 140 mg / dL, 63 mg / dL to 137 mg / dL, 63 mg / dL to 134 mg / dL, etc.) can be implemented in various embodiments. The trend feature 1010 of the UI view 1000 includes a compilation of the user's time range and can be presented as a scatter plot with a best-fit line that identifies the time range trend of the user over a certain time period (e.g., a 24-hour time period in the example shown) within a specified time frame (e.g., any consecutive 14-day time period in the example shown).

[0121] In various embodiments, the pregnancy assistant is automatically disabled at the due date, within a predetermined time period after the due date has passed, or when it is detected that the user has given birth (e.g., based on a change in one or more analyte values detected for the user). In some embodiments, an option 1100 to disable the pregnancy assistant at the due date or within a predetermined time period after the due date is presented to the user, as Figure 11 shown. Additionally, in some embodiments, the pregnancy assistant is disabled when it is determined that the user does not have gestational diabetes (e.g., automatically or based on presenting a disable option to the user). For example, when the user's glucose level remains within a normal target analyte concentration range for a predetermined time period, the pregnancy assistant may be automatically disabled (or an option to disable the pregnancy assistant may be presented to the user). Further, in some embodiments, in response to detecting an abnormally high glucose concentration value postpartum (e.g., within 6 weeks postpartum), a message indicating that a remedial action should be taken may be automatically displayed to the user (and / or transmitted and displayed to the user's HCP).

[0122] When the pregnancy assistant is disabled, one or more UI elements (e.g., the time range feature 910, the trend feature 1010, etc.) are automatically modified from pregnancy-specific target analyte ranges and / or pregnancy-specific information to reflect normal target analyte ranges and / or non-pregnancy-specific information. Additionally or alternatively, one or more widgets (e.g., the post-meal glucose UI element 920, the fasting glucose UI element 940, etc.) that include pregnancy-specific information and / or key metrics are removed from one or more UI views.

[0123] In some embodiments, pregnancy-specific information may be removed from one or more widgets. For example, information reflecting fasting glucose concentration values and one or more post-meal glucose concentration values may be removed from the analyte statistics feature 930, and the analyte statistics feature 930 may instead be restored to display an average glucose concentration value (e.g., as Figure 5 shown by the analyte statistics feature 520).

[0124] Exemplary operations for tracking, reporting, and visualizing pregnancy-related analyte data

[0125] Figure 12 is a flowchart showing an example operation 1200 for generating a user interface view associated with sensor data representing glucose concentration levels in a recipient, in accordance with some example aspects of the present disclosure. Operation 1200 may be performed by a processing system such as the analyte processor 135. In some examples, operation 1200 may be used to generate one or more reports exemplified in Figures 5 to 11 as described in more detail below.

[0126] Operation 1200 may begin at 1202 by receiving a selection to enable the pregnancy assistant. For example, the user may select Figure 6AThe UI elements 610 included in the connected dashboard 600 shown.

[0127] At 1204, an onboarding sequence is optionally displayed to the user. For example, during the presentation of the onboarding sequence, information related to the features of the pregnancy assistant may be displayed to the user, and / or one or more UI elements may be automatically displayed to enable the user to enter the due date and view and / or modify pregnancy-specific target analyte ranges.

[0128] At 1206, one or more UI elements are automatically modified to reflect pregnancy-specific parameters and / or pregnancy-specific information. For example, one or more UI views including one or more widgets (e.g., the time range feature 510, the trend feature 540, etc.) may be automatically modified from displaying normal target analyte concentration ranges to alternatively reflect pregnancy-specific target analyte concentration ranges, and / or one or more UI views may be automatically modified to add pregnancy-specific widgets (e.g., the postprandial glucose UI element 920 and / or the fasting glucose UI element 940). U.S. Application No. 2022 / 0265224, which is hereby incorporated by reference in its entirety, further describes techniques for generating various types of reports, UI views, and widgets, which in some embodiments may be implemented in conjunction with operation 1200.

[0129] At 1208, pregnancy-related information is optionally automatically displayed to the user, for example, based on gestational age (e.g., Figures 7E to 7G ). Additionally or alternatively, a reminder to record pregnancy-specific key metrics (e.g., fasting glucose level and / or postprandial glucose level) is displayed to the user.

[0130] At 1210, the pregnancy assistant may be disabled, for example, based on the due date. For example, the pregnancy assistant may be automatically disabled at the due date, within a predetermined period after the due date has passed, or when it is detected that the user has given birth.

[0131] If the pregnancy assistant is disabled at 1210, then at 1212, one or more UI elements are automatically modified to reflect normal target analyte ranges and / or non-pregnancy-specific information based on pregnancy-specific target analyte ranges and / or pregnancy-specific information. For example, one or more widgets including pregnancy-specific information may be removed from one or more UI views, and / or one or more widgets may be modified to remove pregnancy-specific information.

[0132] Figure 13 is a flowchart showing an example operation 1300 for generating a user interface view associated with sensor data representing glucose concentration levels in a recipient according to some example aspects of the present disclosure. Operation 1300 may be performed by a processing system such as the analyte processor 135. In some examples, operation 1300 may be used to generate a view in Figures 5 to 11One or more of the reports exemplified in the following, as described in more detail below.

[0133] Operation 1300 may begin at 1302 by accessing sensor data that includes multiple analyte readings of the recipient during multiple time periods. Each analyte reading indicates the analyte level of the recipient at the corresponding time. At 1304, a first UI view (e.g., a first report) including one or more user interface (UI) elements is generated based on the multiple analyte levels of the recipient.

[0134] Next, at 1306, in response to receiving a user selection of a pregnancy mode, at least one UI element included in the one or more UI elements is automatically modified to reflect pregnancy-specific information, such as pregnancy-specific parameters (e.g., pregnancy-specific analyte concentration ranges). At 1308, a second UI view (e.g., a second report) is generated based on the multiple analyte levels of the recipient and the pregnancy-specific parameters.

[0135] Exemplary terms

[0136] Specific implementation examples are described in the following numbered clauses:

[0137] Clause 1: A method for generating a user interface view including sensor data representing an analyte level of a recipient, the method comprising: accessing sensor data that includes multiple analyte readings of the recipient during multiple time periods, wherein each analyte reading indicates the analyte level of the recipient at the corresponding time; generating a first UI view including one or more user interface (UI) elements based on the multiple analyte levels of the recipient; automatically modifying a parameter of at least one UI element included in the one or more UI elements to reflect pregnancy-specific parameters in response to receiving a user selection of a pregnancy mode; and generating a second UI view based on the multiple analyte levels of the recipient and the pregnancy-specific parameters.

[0138] Clause 2: The method according to clause 1, wherein the pregnancy-specific parameters include pregnancy-specific analyte ranges.

[0139] Clause 3: The method according to any one of clauses 1 or 2, wherein the pregnancy-specific analyte range includes a pregnancy-specific glucose concentration range.

[0140] Clause 4: The method according to any one of clauses 1 to 3, the method further comprising automatically restoring the parameter of the at least one UI element from the pregnancy-specific parameter to a non-pregnancy-specific parameter in response to disabling the pregnancy mode.

[0141] Clause 5: The method according to any one of Clauses 1 to 4, the method further comprising, after disabling the pregnancy mode, generating a third UI view based on the plurality of analyte levels of the recipient and the non-pregnancy specific parameters.

[0142] Clause 6: The method according to any one of Clauses 1 to 5, the method further comprising receiving an input corresponding to the recipient's expected due date, wherein based on determining that the recipient's expected due date has passed, automatically performing disabling of the pregnancy mode.

[0143] Clause 7: The method according to any one of Clauses 1 to 6, the method further comprising: receiving an input corresponding to the recipient's expected due date; and causing an option to disable the pregnancy mode to be displayed within a predetermined time period of the recipient's expected due date.

[0144] Clause 8: The method according to any one of Clauses 1 to 7, the method further comprising: receiving an input corresponding to the recipient's expected due date; determining the gestational age based on the recipient's expected due date; and causing a UI element corresponding to the gestational age to be displayed.

[0145] Clause 9: The method according to any one of Clauses 1 to 8, wherein the user selection of the pregnancy mode includes switching a switching UI element from a normal analyte range to the pregnancy specific analyte range.

[0146] Clause 10: The method according to any one of Clauses 1 to 9, wherein automatically modifying the parameter of the at least one UI element includes updating a time range widget to reflect the pregnancy specific analyte range.

[0147] Clause 11: The method according to any one of Clauses 1 to 10, the method further comprising, in response to receiving the user selection of the pregnancy mode, causing at least one of the following to be displayed: (i) a reminder to record a fasting glucose reading, or (ii) a reminder to record a postprandial glucose reading.

[0148] Clause 12: A method for generating a user interface view including sensor data representing an analyte level of a recipient, the method comprising: accessing sensor data including a plurality of analyte readings of the recipient during a plurality of time periods, wherein each analyte reading indicates the analyte level of the recipient at a corresponding time; generating a first UI view including one or more user interface (UI) elements based on the plurality of analyte levels of the recipient; automatically modifying at least one UI element included in the one or more UI elements to reflect pregnancy specific information in response to receiving a user selection of a pregnancy mode; and generating a second UI view based on the plurality of analyte levels of the recipient and the pregnancy specific information.

[0149] Clause 13: The method according to Clause 12, wherein automatically modifying the at least one UI element to reflect the pregnancy-specific information includes causing a UI element corresponding to at least one of a fasting glucose value or a postprandial glucose value to be displayed.

[0150] Clause 14: The method according to any one of Clauses 12 or 13, the method further comprising: receiving an input corresponding to the recipient's due date; and determining a gestational age based on the recipient's due date, wherein automatically modifying the at least one UI element to reflect the pregnancy-specific information includes causing a UI element related to the gestational age to be displayed.

[0151] Clause 15: The method according to any one of Clauses 12 to 14, wherein the UI element related to the gestational age includes educational information corresponding to the gestational age.

[0152] Clause 16: The method according to any one of Clauses 12 to 15, wherein automatically modifying the at least one UI element to reflect the pregnancy-specific information includes causing at least one of the following to be displayed: (i) a reminder to record a fasting glucose reading, or (ii) a reminder to record a postprandial glucose reading.

[0153] Clause 17: The method according to any one of Clauses 12 to 16, wherein automatically modifying the at least one UI element to reflect the pregnancy-specific information includes causing a guidance sequence including a prompt to enter a due date to be displayed.

[0154] Clause 18: The method according to any one of Clauses 12 to 17, the method further comprising automatically removing the pregnancy-specific information associated with the at least one UI element in response to disabling the pregnancy mode.

[0155] Clause 19: The method according to any one of Clauses 12 to 18, the method further comprising receiving an input corresponding to the recipient's due date, wherein based on determining that the recipient's due date has passed, the pregnancy mode is automatically disabled.

[0156] Clause 20: The method according to any one of Clauses 12 to 19, the method further comprising: receiving an input corresponding to the recipient's due date; and causing an option to disable the pregnancy mode to be displayed within a predetermined period of the recipient's due date.

[0157] Other considerations

[0158] Each of these non-limiting examples may exist independently or may be combined with one or more of the other examples in various arrangements or combinations. The foregoing detailed description includes reference to the accompanying drawings, which form a part of the detailed description. The drawings illustrate, by way of example, specific embodiments in which the invention may be practiced. Such embodiments are also referred to herein as "examples". Such examples may include elements other than those shown or described. However, the inventors also contemplate examples that provide only those elements shown or described. In addition, the inventors also contemplate examples of any combination or arrangement of those elements shown or described with respect to a particular example (or one or more aspects thereof) or with respect to one or more other examples shown or described herein (or one or more aspects thereof).

[0159] In the event of any inconsistency in usage between this document and any document incorporated by reference, the usage in this document shall govern.

[0160] In this document, as is common in patent documents, the terms "a" or "an" are used to include one or more than one, independent of any other instances or usages of "at least one" or "one or more". In this document, the term "or" is used to mean non-exclusive or, such that "A or B" includes "A but not B", "B but not A", and "A and B", unless otherwise indicated. In this document, the terms "comprising" and "wherein" are used as shorthand equivalents of the respective terms "including" and "in which". Also, in the appended claims, the terms "comprising" and "including" are open-ended, i.e., a system, apparatus, article, composition, formulation, or process that includes elements other than those listed after such terms in the claims is still considered to fall within the scope of that claim. Further, in the appended claims, the terms "first", "second", "third", etc. are used merely as labels and are not intended to impose numerical requirements on their objects.

[0161] Geometric terms, such as "parallel", "perpendicular", "circular", or "square", are not intended to require absolute mathematical precision, unless the context otherwise indicates. Rather, such geometric terms allow for variations due to manufacturing or equivalent functionality. For example, if an element is described as "circular" or "substantially circular", a component that is not precisely circular (e.g., a component that is slightly oval or a polygon with many sides) is still covered by this description.

[0162] The method examples described herein may be implemented, at least in part, by a machine or a computer. Some examples may include a computer-readable medium or a machine-readable medium encoded with instructions that are operable to configure an electronic device to perform the methods as described in the above examples. The specific implementation of such methods may include code, such as microcode, assembly language code, high-level language code, etc. Such code may include computer-readable instructions for performing various methods. The code may form part of a computer program product. Further, in one example, the code may be tangibly stored on one or more volatile, non-transitory, or non-volatile tangible computer-readable media, such as during execution or at other times. Examples of such tangible computer-readable media may include, but are not limited to, hard disks, removable disks, removable optical disks (e.g., compact disks and digital video disks), magnetic tape cartridges, memory cards or sticks, random access memory (RAM), read only memory (ROM), etc.

[0163] The above description is intended to be illustrative and not restrictive. For example, the above examples (or one or more aspects thereof) may be used in combination with each other. Other implementations may be used by those skilled in the art, such as when reviewing the above description. The abstract is provided to comply with the requirements of 37 C.F.R. § 1.72(b) so that readers can quickly determine the nature of the technical disclosure. The submitted abstract should be understood not to be used to interpret or limit the scope or meaning of the claims. Also, in the above detailed description, various features may be grouped together to simplify the disclosure. This should not be construed as meaning that the disclosed features not claimed are necessary for any claim. Rather, the inventive subject matter may lie in less than all of the features of a particular disclosed implementation. Thus, the appended claims are hereby incorporated as examples or implementations into the detailed description, where each claim stands on its own as a separate implementation, and it is contemplated that these implementations may be combined with each other in various combinations or permutations. The scope of the present invention should be determined with reference to the appended claims and the full scope of equivalents to which those claims are entitled.

Claims

1. A method for generating a user interface view that includes sensor data representing an analyte level of a recipient, the method comprises: accessing sensor data, the sensor data including a plurality of analyte readings of the recipient during a plurality of time periods, wherein each analyte reading indicates the analyte level of the recipient at a corresponding time; generating a first UI view including one or more user interface (UI) elements based on the plurality of analyte levels of the recipient; automatically modifying parameters of at least one UI element included in the one or more UI elements to reflect pregnancy-specific parameters in response to receiving a user selection of a pregnancy mode; and generating a second UI view based on the plurality of analyte levels of the recipient and the pregnancy-specific parameters.

2. The method according to claim 1, wherein the pregnancy-specific parameters include a pregnancy-specific analyte range.

3. The method according to claim 2, wherein the pregnancy-specific analyte range includes a pregnancy-specific glucose concentration range.

4. The method according to claim 1, the method further comprising automatically restoring the parameters of the at least one UI element from the pregnancy-specific parameters to non-pregnancy-specific parameters in response to disabling the pregnancy mode.

5. The method according to claim 4, the method further comprising generating a third UI view based on the plurality of analyte levels of the recipient and the non-pregnancy-specific parameters after disabling the pregnancy mode.

6. The method according to claim 4, the method further comprising receiving an input corresponding to the recipient's due date, wherein based on determining that the recipient's due date has passed, the pregnancy mode is automatically disabled.

7. The method according to claim 4, the method further comprises: receiving an input corresponding to the recipient's due date; and causing an option to disable the pregnancy mode to be displayed within a predetermined time period of the recipient's due date.

8. The method according to claim 1, the method further comprises: receiving an input corresponding to the recipient's due date; determining a gestational age based on the recipient's due date; and causing a UI element corresponding to the gestational age to be displayed.

9. The method according to claim 2, wherein the user selection of the pregnancy mode includes switching a toggle UI element from a normal analyte range to the pregnancy-specific analyte range.

10. The method according to claim 9, wherein automatically modifying the parameters of the at least one UI element includes updating a time range widget to reflect the pregnancy-specific analyte range.

11. The method according to claim 1, the method further comprising causing at least one of the following to be displayed in response to receiving the user selection of the pregnancy mode: (i) a reminder to record a fasting glucose reading, or (ii) a reminder to record a postprandial glucose reading.

12. A method for generating a user interface view that includes sensor data representing an analyte level of a recipient, the method comprises: accessing sensor data, the sensor data including a plurality of analyte readings of the recipient during a plurality of time periods, wherein each analyte reading indicates the analyte level of the recipient at a corresponding time; Generate a first UI view including one or more user interface (UI) elements based on the multiple analyte levels of the recipient; In response to receiving a user selection of a pregnancy mode, automatically modify at least one of the one or more UI elements included to reflect pregnancy-specific information; And Generate a second UI view based on the multiple analyte levels of the recipient and the pregnancy-specific information.

13. The method according to claim 12, wherein automatically modifying the at least one UI element to reflect the pregnancy-specific information includes causing a UI element corresponding to at least one of a fasting glucose value or a postprandial glucose value to be displayed.

14. The method according to claim 12, the method further includes: Receiving an input corresponding to the recipient's due date; And Determining a gestational age based on the recipient's due date, wherein automatically modifying the at least one UI element to reflect the pregnancy-specific information includes causing a UI element related to the gestational age to be displayed.

15. The method according to claim 14, wherein the UI element related to the gestational age includes educational information corresponding to the gestational age.

16. The method according to claim 12, wherein automatically modifying the at least one UI element to reflect the pregnancy-specific information includes causing at least one of the following to be displayed: (i) a reminder to record a fasting glucose reading, or (ii) a reminder to record a postprandial glucose reading.

17. The method according to claim 12, wherein automatically modifying the at least one UI element to reflect the pregnancy-specific information includes causing a guidance sequence including a prompt to enter a due date to be displayed.

18. The method according to claim 12, the method further includes automatically removing the pregnancy-specific information associated with the at least one UI element in response to disabling the pregnancy mode.

19. The method according to claim 18, the method further includes receiving an input corresponding to the recipient's due date, wherein based on determining that the recipient's due date has passed, the pregnancy mode is automatically disabled.

20. The method according to claim 18, the method further includes: Receiving an input corresponding to the recipient's due date; And Causing an option to disable the pregnancy mode to be displayed within a predetermined period of the recipient's due date.

Images