Systems and methods for diabetes management

Abstract

Systems, devices, and methods are provided for incorporating a drug delivery device into an integrated management system. The integrated management system may be an integrated diabetes management system and may include a glucose monitor, a connected insulin pen, and software. An integrated management system may generate a plurality of reports, which may include data related to analyte levels (e.g., glucose levels) and delivered drugs (e.g., delivered insulin). The integrated system may also include a mode in which certain types of data are no longer shared and / or stored if the user does not log in the account. The type of data shared and / or stored when the user does not log in the account may be different from the type of data shared and / or stored when the user logs in the account.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Application No. 63 / 536,778 filed on September 6, 2023 and U.S. Provisional Application No. 63 / 406,385 filed on September 14, 2022, both of which are expressly incorporated herein by reference in their entirety for all purposes. This application is also related to U.S. Application Serial No. 17 / 725,063 filed on April 20, 2022 (which claims priority to U.S. Provisional Application No. 63 / 236,910 filed on August 25, 2021) and U.S. Provisional Application No. 63 / 177,706 filed on April 21, 2021, all of which are expressly incorporated herein by reference in their entirety for all purposes. Technical Field

[0003] The subject matter described herein relates generally to systems, devices, and methods related to an integrated system for diabetes management (eg, an integrated platform that connects insulin pens with a common viewing platform so that data can be shared among multiple parties). Background Art

[0004] Detecting and / or monitoring analyte levels (such as glucose, ketones, lactate, oxygen, hemoglobin A1C, etc.) can be critical to the health of a diabetic patient. A diabetic patient may experience complications, including loss of consciousness, cardiovascular disease, retinopathy, neuropathy, and nephropathy. It is often necessary to monitor the glucose levels of a diabetic patient to ensure that they remain within a clinically safe range, and this information can also be used to determine if and / or when insulin is needed to lower the glucose level in their body, or when additional glucose is needed to raise the glucose level in their body.

[0005] There is a growing body of clinical data demonstrating a strong correlation between glucose monitoring frequency and glycemic control. Despite this correlation, many people diagnosed with diabetes do not monitor their glucose levels as frequently as they should due to a combination of factors, including inconvenience, testing discretion, pain associated with glucose testing, and cost.

[0006] For patients who rely on medication (e.g., insulin) for the treatment or management of diabetes, it is desirable to have a system, device, or method that can combine glucose data with insulin administration data and provide more actionable insights for patients, caregivers, and HCPs. Manually recording insulin doses is not only time-consuming, but also often results in inaccurate dosing records. In addition, sharing these manual logs with HCPs is a big hassle for patients and creates workflow issues.

[0007] Treatment management of diabetes often requires the use of multiple medications with different delivery frequencies (i.e., daily, weekly) and routes of administration (oral or injectable). The combination of medication type, delivery frequency, and route of administration can be difficult to manage, placing a significant cognitive burden on the user, which often means poor consistency in dosing regimens. Studies have shown that among insulin-dependent patients with type 1 diabetes, up to 24% miss mealtime rapid-acting insulin boluses and 36% miss once-daily long-acting basal doses, leading to poor glucose control and diabetes management. Existing dosage logs are only as useful as the user wants to use them. Their effectiveness is directly related to the user's willingness to record dosages and reference past records. Connected drug delivery technologies (such as those that support The advent of insulin pens allows doses to be automatically recorded into a companion mobile phone application without user intervention. Although this method is useful in daily management, it has two significant disadvantages: (1) it cannot be directly correlated with blood glucose results; and (2) insulin doses are usually presented in a table format, which is difficult to read and interpret over a long time window.

[0008] For these and other reasons, there is a need for improved systems, methods, and apparatus relating to integrated systems for diabetes management. Summary of the invention

[0009] Provided herein are exemplary embodiments of systems, equipment and methods relevant to diabetes management, including integrated management systems, which include analyte monitoring equipment, drug delivery equipment, reader equipment, monitoring software and reporting software. In many embodiments, analyte monitoring equipment (e.g., continuous or transient glucose monitor) and drug delivery equipment (e.g., insulin pen) are coupled to reader equipment communication, so that analyte data, dosage log and other information can be easily transmitted to a computing device including monitoring and / or reporting software. Integrated systems can include GUI displays, which indicate and assist users in connecting drug delivery equipment to monitoring software such as on reader equipment, so that drug delivery equipment can be transmitted from drug delivery equipment. Administration log and other information. Integrated systems also include reporting software, which can produce one or more reports, and the one or more reports contain data about analyte levels and measurement and drug administration amount and measurement.

[0010] The method can address both of these issues by utilizing glucose data as an indicator of poor dosage consistency and presenting the data in a manner designed to allow trained healthcare professionals to quickly identify situations where poor drug dosage consistency leads to poor glycemic control. In some embodiments, glucose data can be the only indicator of poor dosage consistency.

[0011] Provided are systems, devices and methods for incorporating drug delivery devices into an integrated management system. The integrated management system can be an integrated diabetes management system, and can include a glucose monitor, a connected insulin pen and software. The integrated management system can generate multiple reports, which can include data related to analyte levels (e.g., glucose levels) and the drugs delivered (e.g., the insulin delivered). The integrated system can also include a mode in which, if a user does not log in to an account, certain types of data are no longer shared and / or stored. The data types shared and / or stored when the user does not log in to an account may be different from the data types shared and / or stored when the user logs in to an account.

[0012] Other systems, devices, methods, features, and advantages of the subject matter described herein will be or will become apparent to those skilled in the art upon examination of the following drawings and detailed description. All such additional systems, devices, methods, features, and advantages are included in this specification, are within the scope of the subject matter described herein, and are protected by the appended claims. Features of the exemplary embodiments should in no way be construed as limiting the appended claims without explicit recitation of such features in the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The details of the subject matter described herein, both as to its structure and operation, may be apparent by studying the accompanying drawings, in which like reference numerals refer to like parts. The components in the figures are not necessarily drawn to scale, emphasis instead being placed on illustrating the principles of the subject matter. Furthermore, all illustrations are intended to convey concepts, wherein relative size, shape, and other detailed attributes may be illustrated schematically rather than literally or precisely.

[0014] Figure 1A and Figure 1B is a block diagram of an exemplary implementation of an integrated management system.

[0015] Figure 2A is a schematic diagram depicting an exemplary embodiment of a sensor control device.

[0016] Figure 2B is a block diagram depicting an exemplary implementation of a sensor control device.

[0017] Figure 3A is a schematic diagram depicting an exemplary embodiment of a drug delivery device.

[0018] Figure 3B is a block diagram depicting an exemplary embodiment of a drug delivery device.

[0019] Figure 3C is a schematic diagram depicting an exemplary embodiment of a drug delivery device having a smart button.

[0020] Figure 4A is a schematic diagram depicting an exemplary embodiment of a display device.

[0021] Figure 4B is a block diagram depicting an exemplary embodiment of a display device.

[0022] Figure 5 is a block diagram depicting an exemplary implementation of a user interface device.

[0023] Fig. 6A is a flow diagram of a user experience of an exemplary implementation of an integrated management system.

[0024] Figure 6B is a flow chart of an exemplary method for displaying a message related to report availability.

[0025] Figure 6C is a flow chart of an exemplary method for displaying an error message.

[0026] Fig.6D is a flow chart of an exemplary method for displaying reminders.

[0027] Figure 7 is a flow chart of the user experience of adding a drug delivery device to an integrated management system.

[0028] Fig. 8A is a block diagram depicting an example implementation of snapshot reporting.

[0029] FIG. 8B to FIG. 8C is an exemplary implementation of a snapshot report.

[0030] Fig.9A is a block diagram depicting an example implementation of a weekly summary report.

[0031] FIG. 9B to FIG. 9G is an exemplary implementation of a weekly summary report.

[0032] Fig. 10A is a block diagram depicting an example implementation of a daily log report.

[0033] FIG. 10B to FIG. 10C is an exemplary implementation of a daily log report.

[0034] Fig.11A is a block diagram depicting an exemplary implementation of a daily pattern report.

[0035] FIG. 11B to FIG. 11C is an exemplary implementation of a daily pattern report.

[0036] FIG. 11D to FIG. 11Eis an exemplary embodiment of a daily pattern report GUI that may be displayed on a display device.

[0037] Fig. 12A is a block diagram depicting an exemplary implementation of a meal time pattern report.

[0038] FIG. 12B to FIG. 12C is an exemplary implementation of a meal time pattern report.

[0039] Fig.13A is a block diagram depicting an example implementation of a device detail report.

[0040] Fig. 13B is an exemplary implementation of a device detail report.

[0041] Fig.14 is a block diagram depicting an exemplary implementation of AGP reporting.

[0042] Fig.15A is a block diagram depicting an exemplary implementation of a GUI from a patient dashboard.

[0043] Fig. 15B is an exemplary implementation of a GUI from a patient dashboard.

[0044] Fig.16A is a block diagram depicting an exemplary implementation of a GUI associated with a data source modality with a tethered pen.

[0045] Fig. 16B is an exemplary implementation of a GUI associated with a data source modality with a tethered pen.

[0046] Fig.17A is a block diagram depicting an exemplary implementation of an alert associated with a connected insulin pen.

[0047] Fig. 17B is an exemplary embodiment of an alarm associated with a connected insulin pen.

[0048] FIG. 18A to FIG. 18B is a block diagram depicting an exemplary implementation of a comparative AGP report.

[0049] Fig.18C is an exemplary AGP showing all data.

[0050] Fig.18D is an exemplary AGP showing data excluding missed administered doses.

[0051] Fig.19 is an exemplary implementation of a comparison report.

[0052] FIG. 20A to FIG. 20Dis an exemplary embodiment of a GUI for interfacing a drug delivery device with a monitoring application.

[0053] FIG. 20E to FIG. 20F is an exemplary embodiment of a GUI for managing user-connected drug delivery devices.

[0054] FIG. 21A to FIG. 21B is an exemplary embodiment of a GUI for downloading and viewing medication administration records.

[0055] Fig. 21C is an exemplary embodiment of a GUI for editing medication dosage instructions.

[0056] Fig.21D is an exemplary embodiment of a GUI for prompting a user to learn to connect a drug delivery device.

[0057] FIG. 22A to FIG. 22B is an exemplary embodiment of a GUI for customizing a name for a drug delivery device.

[0058] FIG. 23A to FIG. 23C is an exemplary implementation of a GUI for logs.

[0059] FIG. 24A to FIG. 24C is an exemplary implementation of an insulin summary report GUI.

[0060] Fig.25 is an exemplary method for displaying a missed dose alert or message.

[0061] Fig.26 is an exemplary method for displaying a correction dose alarm or message.

[0062] Fig. 27 is an exemplary method for displaying a congratulatory alert or message.

[0063] FIG. 28A to FIG. 28E is an exemplary implementation of a GUI for a daily review report GUI.

[0064] FIG. 29A to FIG. 29D is an exemplary implementation of a GUI associated with an account or no account mode.

[0065] Fig.29E An exemplary method for establishing an account is provided.

[0066] Figures 30A-1 to 30R-3 is an exemplary embodiment of a GUI displayed in a monitoring application using a tethered pen. DETAILED DESCRIPTION

[0067] Before describing the present subject matter in detail, it should be understood that the present disclosure is not limited to the particular embodiments described herein, as this may of course vary. It should also be understood that the terminology used herein is only for the purpose of describing particular embodiments and is not intended to be limiting, as the scope of the present disclosure will be limited only by the appended claims.

[0068] In general, embodiments of the present disclosure include systems, devices, and methods related to integrated diabetes management. An integrated diabetes management system may include an intelligent delivery system (such as a connected smart insulin pen), a glucose sensor, software that receives and processes data from the glucose sensor and the intelligent delivery system, and a viewing platform that can determine and visualize dosage analysis. The integrated management system (IMS) may also include reports that include insights into the effects of various insulin doses and treatment suggestions, including dosage recommendations.

[0069] Integrated diabetes management can be implemented as software and / or firmware instructions stored in the memory of a computing device for execution by at least one processor or processing circuit thereof. The computing device can be owned by a user or a healthcare professional (HCP), and the user or HCP can interface with the computing device through a user interface. According to some embodiments, the computing device can be a server or a trusted computer system accessible via a network, and the integrated management software can be presented to the user in the form of an interactive web page by a browser executed on a local display device (with a user interface), and the local display device communicates with the server or trusted computing system through a network. In this embodiment and other embodiments, the integrated management software can be executed on multiple devices, or partially executed on the processing circuit of the local display device and partially executed in the processing circuit of the server or trusted computer system. It will be understood by those skilled in the art that when the IMS is described as performing an action, such an action is performed according to instructions stored in a computer memory (including instructions hard-coded in a read-only memory), which when executed by at least one processor of at least one computing device causes the IMS to perform the described action. In all cases, the actions may optionally be performed by hardware (eg, dedicated circuitry) that is hardwired to perform the actions, rather than by instructions stored in a memory.

[0070] In addition, as used herein, a system on which an IMS is implemented may be referred to as an integrated management system. The integrated management system may be configured to provide only integrated management, or may be a multifunctional system in which integrated management is only one aspect. For example, in some embodiments, the integrated management system may also monitor the user's analyte level. In some embodiments, the integrated management system may also deliver medication to the user, such as using an injection or infusion device. In some embodiments, the integrated management system may monitor analytes and deliver medication.

[0071] These embodiments and other embodiments described herein represent advances in the field of computer-based dosimetry, analyte monitoring, and drug delivery systems. Specific features and potential advantages of the disclosed embodiments are discussed further below.

[0072] Before describing the integration management implementation in detail, it is first desirable to describe an example of an integration management system upon or through which an integration management application may be implemented.

[0073] Example Implementation of Integrated System

[0074] Figure 1A is a block diagram depicting an exemplary embodiment of an integrated system 100. In this embodiment, the integrated management system 100 is capable of delivering one or more medications, recording medication dosages, monitoring one or more analytes, and determining and viewing analyte results and providing treatment recommendations. This multifunctional example is used to illustrate the high degree of connectivity and performance that can be achieved with the system 100.

[0075] Here, the system 100 includes a sensor control device (SCD) 102 configured to collect analyte level information from a user, a drug delivery device (MDD) 152 configured to deliver a drug to a user, and a display device 120 configured to present information to a user and receive input or information from a user. The structure and function of each device will be described in detail herein.

[0076] System 100 is configured for highly interconnected and highly flexible communications between devices. Each of the three devices 102, 120, and 152 can communicate with each other directly (without going through an intermediary electronic device) or indirectly (such as through a cloud network 190, or through another device and then through network 190). The two-way communication capability between devices and between devices and network 190 is Figure 1A 102, 120, and 152 may be wireless. (include Low Power) standard, Near Field Communication (NFC) standard, Wi-Fi (802.11x) standard, mobile phone standard or other standards. All communications on each path can be encrypted and Figure 1A Each device can be configured to encrypt and decrypt those communications it sends and receives. In each case, Figure 1AThe communication path can be direct (e.g. or NFC) or indirectly (e.g., Wi-Fi, mobile phone, or other Internet protocols). Implementations of system 100 do not require cross-connection. Figure 1A The ability to communicate across all paths shown in .

[0077] In addition, although Figure 1A A single display device 120, a single SCD 102, and a single MDD 152 are depicted, but those skilled in the art will appreciate that the system 100 may include a plurality of any of the above devices. By way of example only, the system 100 may include a single SCD 102 that communicates with a plurality (e.g., two, three, four, etc.) of display devices 120 and / or a plurality of MDDs 152. Alternatively, the system 100 may include a plurality of SCDs 102 that communicate with a single display device 120 and / or a single MDD 152. Furthermore, each of the plurality of devices may be the same or a different device type. For example, the system 100 may include a plurality of display devices 120, including a smartphone, a handheld receiver, and / or a smartwatch, each of which may communicate with the SCD 102 and / or the MDD 152, as well as with each other.

[0078] Analyte data can be transmitted between each device within the system 100 in an autonomous manner (e.g., automatically transmitted according to a schedule) or in response to a request for analyte data (e.g., sending an analyte data request from a first device to a second device, and then transmitting the analyte data from the second device to the first device). Other data communication technologies can also be used to accommodate more complex systems, such as a cloud network 190.

[0079] Figure 1B1 is a block diagram depicting another exemplary embodiment of an integrated management system 100. Here, the system 100 includes an SCD 102, an MDD 152, a first display device 120-1, a second display device 120-2, a local computer system 170, and a trusted computer system 180 accessible by a cloud network 190. The SCD 102 and the MDD 152 are capable of communicating with each other and with the display device 120-1, which can act as a communication hub for aggregating information from the SCD 102 and the MDD 152, processing and displaying the information as needed, and transmitting some or all of the information to the cloud network 190 and / or the computer system 170. Conversely, the display device 120-1 can receive information from the cloud network 190 and / or the computer system 170 and pass some or all of the received information to the SCD 102, the MDD 152, or both. The computer system 170 can be a personal computer, a server terminal, a laptop computer, a tablet computer, or other suitable data processing device. Computer system 170 may include or represent software for data management and analysis and for communicating with components in system 100. Computer system 170 may be used by a user or medical professional to display and / or analyze analyte data measured by SCD 102. Figure 1B A single SCD 102, a single MDD 152, and two display devices 120-1 and 120-2 are depicted, but those skilled in the art will appreciate that system 100 may include a plurality of any of the aforementioned devices, wherein each of the plurality of devices may include the same or different types of devices.

[0080] Still reference Figure 1B According to some embodiments, the trusted computer system 180 may be physically or virtually owned by a manufacturer or distributor of components of the system 100 via a secure connection, and may be used to perform authentication of devices (e.g., devices 102, 120-n, 152) of the system 100, to securely store a user's data, and / or as a server serving a data analysis program (e.g., accessible via a web browser) to analyze the user's measured analyte data and medication history. The trusted computer system 180 may also act as a data hub for routing and exchanging data between all devices that communicate with the system 180 using the cloud network 190. In other words, all devices in the system 100 that are capable of communicating with the cloud network 190 (e.g., directly via an Internet connection or indirectly via another device) are also capable of communicating directly or indirectly with all other devices in the system 100 that are capable of communicating with the cloud network 190.

[0081] Display device 120-2 is depicted as being in communication with cloud network 190. In this example, device 120-2 may be owned by another user who is granted access to analyte and medication data for a person wearing SCD 102. For example, the person who owns display device 120-2 may be a parent of a child wearing SCD 102, as one example, or a caregiver of an elderly patient wearing SCD 102, as another example. System 100 may be configured to transmit analyte and medication data about the wearer over cloud network 190 (e.g., via trusted computer system 180) to another user who is granted access to the data.

[0082] Exemplary Embodiments of Analyte Monitoring Devices

[0083] The analyte monitoring function of the integrated management system 100 can be implemented by including one or more devices capable of collecting, processing and displaying the user's analyte data. Exemplary embodiments of such devices and methods of use thereof are described in International Publication No. WO 2018 / 152241 and U.S. Patent Publication No. 2011 / 0213225, both of which are incorporated herein by reference in their entirety for all purposes.

[0084] Analyte monitoring can be performed in a variety of different ways. For example, a "continuous analyte monitoring" device (e.g., a "continuous glucose monitoring" device) can continuously or repeatedly transmit data from a sensor control device to a display device with or without prompting (e.g., automatically according to a schedule). As another example, a "flash analyte monitoring" device (e.g., a "transient glucose monitoring" device or simply a "transient" device) can respond to a data request (e.g., scan) initiated by a user of a display device, such as by near field communication (NFC) or radio frequency identification (RFID) protocols, to transmit data from a sensor control device.

[0085] An analyte monitoring device utilizing a sensor configured to be partially or entirely placed within a user's body may be referred to as an in vivo analyte monitoring device. For example, an in vivo sensor may be placed within a user's body so that at least a portion of the sensor is in contact with a body fluid (e.g., an interstitial (ISF) fluid, such as a dermal fluid in the dermis or subcutaneous fluid under the dermis, blood, or other), and the analyte concentration in the body fluid may be measured. In vivo sensors may use various types of sensing techniques (e.g., chemical, electrochemical, or optical). Some systems utilizing in vivo analyte sensors may also operate without the need for fingertip calibration (finger stick calibration).

[0086] "In vitro" devices are those in which the sensor contacts a biological sample outside the body (or more precisely, "ex vivo"). These devices typically include a port for receiving an analyte test strip carrying a user's bodily fluid, which can be analyzed to determine the user's blood glucose level. Other ex vivo devices have been proposed that attempt to non-invasively measure a user's internal analyte levels, such as by using optical techniques that can measure in vivo analyte levels without mechanically penetrating the user's body or skin. In vivo and ex vivo devices typically include in vitro functionality (e.g., an in vivo display device that also includes a test strip port).

[0087] The present subject matter will be described for sensors capable of measuring glucose concentration, however, detection and measurement of concentrations of other analytes are also within the scope of the present disclosure. These other analytes may include, for example, ketones, lactate, oxygen, hemoglobin A1C, acetylcholine, amylase, bilirubin, cholesterol, chorionic gonadotropin, creatine kinase (e.g., CK-MB), creatine, DNA, fructosamine, glutamine, growth hormone, hormones, peroxides, prostate-specific antigen, prothrombin, RNA, thyroid stimulating hormone, troponin, etc. The concentration of drugs such as antibiotics (e.g., gentamicin, vancomycin, etc.), digitoxin, digoxin, drugs of abuse, theophylline, and warfarin may also be monitored. The sensor may be configured to measure two or more different analytes at the same or different times. In some embodiments, a sensor control device may be coupled to two or more sensors, wherein one sensor is configured to measure a first analyte (e.g., glucose), and the other one or more sensors are configured to measure one or more different analytes (e.g., any analyte described herein). In other embodiments, a user may wear two or more sensor control devices, each of which is capable of measuring a different analyte.

[0088] The embodiments described herein may be used with all types of in vivo, in vitro, and ex vivo devices capable of monitoring the analytes noted above and others.

[0089] In many embodiments, the sensor operation can be controlled by SCD 102. The sensor can be mechanically and communicatively coupled to SCD 102, or can be communicatively coupled to SCD 102 using only wireless communication technology. SCD 102 can include electronic devices and power sources that can implement and control the analyte sensing performed by the sensor. In some embodiments, the sensor or SCD 102 can be self-powered, so that no battery is required. SCD 102 can also include a communication circuit for communicating with another device (e.g., a display device) adjacent or not adjacent to the user's body. SCD 102 can reside on the user's body (e.g., attached or otherwise placed on the user's skin, or carried in the user's clothing, etc.). SCD 102 can also be implanted in the user's body together with the sensor. The functions of SCD 102 can be divided into a first component implanted in the body (e.g., a component that controls the sensor) and a second component that resides in the body or outside the body (e.g., a relay component that communicates with the first component and with an external device such as a computer or smart phone). In other embodiments, the SCD 102 may be external to the body and configured to non-invasively measure the user's analyte levels. Depending on the actual implementation or embodiment, the sensor control device may also be referred to as a "sensor control unit," "on-body electronics" device or unit, "on-body" device or unit, "in-vivo electronics" device or unit, "in-vivo" device or unit, or "sensor data communication" device or unit, to name a few.

[0090] In some embodiments, the SCD 102 may include a user interface (e.g., a touch screen) and may be capable of processing analyte data and displaying the resulting calculated analyte level to a user. In such cases, the integrated management embodiments described herein may be implemented in whole or in part directly by the SCD 102. In many embodiments, the physical form factor of the SCD 102 is minimized (e.g., to minimize appearance on the user's body), or the sensor control device may not be accessible to the user (e.g., if fully implanted), or other factors may necessitate a user requiring a display device that can be used to read analyte levels and interact with the sensor control device.

[0091] Figure 2A 1 is a side view of an exemplary embodiment of an SCD 102. The SCD 102 may include a housing or mounting bracket 103 ( Figure 2B), which housing or mounting frame can be electrically coupled to the analyte sensor 101, which is configured as an electrochemical sensor here. According to some embodiments, the sensor 101 can be configured to reside partially within the user's body (e.g., through the outermost surface of the skin), where it can be in fluid contact with the user's bodily fluids and used together with the sensor electronics to measure the user's analyte-related data. A structure 105 for attachment (such as an adhesive patch) can be used to secure the housing 103 to the user's skin. The sensor 101 can extend through the attachment structure 105 and protrude away from the housing 103. Those skilled in the art will understand that other forms of attachment to the body and / or housing 103 can be used in addition to or in place of an adhesive and are fully within the scope of the present disclosure.

[0092] The SCD 102 can be applied to the body in any desired manner. For example, an insertion device (not shown), sometimes referred to as an applicator, can be used to position all or a portion of the analyte sensor 101 through the outer surface of the user's skin and in contact with the user's bodily fluids. By doing so, the insertion device can also position the SCD 102 on the skin. In other embodiments, the insertion device can first position the sensor 101, and then the accompanying electronic device (e.g., wireless transmission circuit and / or data processing circuit, etc.) can be coupled to the sensor 101 manually or with the help of a mechanical device (e.g., inserted into a mounting bracket). Examples of insertion devices are described in U.S. Patent Publications Nos. 2008 / 0009692, 2011 / 0319729, 2015 / 0018639, 2015 / 0025345 and 2015 / 0173661, 2018 / 0235520, all of which are incorporated herein by reference in their entirety for all purposes.

[0093] Figure 2B 1 is a block diagram depicting an exemplary embodiment of an SCD 102 having an analyte sensor 101 and sensor electronics 104. The sensor electronics 104 may be implemented in one or more semiconductor chips (e.g., an application specific integrated circuit (ASIC), a processor or controller, a memory, a programmable gate array, etc.). Figure 1BIn an embodiment, the sensor electronics 104 includes high-level functional units (including: an analog front end (AFE) 110, which is configured to interface with the sensor 101 in an analog manner and convert analog signals to digital form and / or convert from digital form to analog signals (e.g., with an A / D converter)); a power supply 111, which is configured to power components of the SCD 102; processing circuits 112; memory 114; timing circuits 115 (e.g., oscillators and phase-locked loops for providing clocks or other timing to components of the SCD 102); and communication circuits 116, which are designed to communicate with one or more devices external to the SCD 102 (such as a display device 120 and / or MDD 152) in a wired and / or wireless manner.

[0094] SCD 102 can be implemented in a highly interconnected manner, where power source 111 and Figure 2B Each of the components shown in the drawings is coupled, and wherein those components that transmit or receive data, information, or commands (e.g., AFE 110, processing circuitry 112, memory 114, timing circuitry 115, and communication circuitry 116) may be communicatively coupled to each other such component via, for example, one or more communication connections or buses 118.

[0095] Processing circuitry 112 may include one or more processors, microprocessors, controllers, and / or microcontrollers, each of which may be a discrete chip or distributed among multiple different chips (and portions thereof). Processing circuitry 112 may include on-board memory. Processing circuitry 112 may interface with communication circuitry 116 and perform analog-to-digital conversion, encoding and decoding, digital signal processing, and other functions that help convert data signals into a format suitable for wireless or wired transmission (e.g., in-phase and quadrature). Processing circuitry 112 may also interface with communication circuitry 116 to perform the reverse functions required to receive wireless transmissions and convert them into digital data or information.

[0096] The processing circuit 112 can execute instructions stored in the memory 114. These instructions can cause the processing circuit 112 to process the raw analyte data (or pre-processed analyte data) and derive the final calculated analyte level. In some embodiments, the instructions stored in the memory 114 can cause the processing circuit 112 to process the raw analyte data when executed to determine one or more of the following: the calculated analyte level, the average calculated analyte level within a predetermined time window, the calculated rate of change of the analyte level within the predetermined time window, and / or whether the calculated analyte metric exceeds a predetermined threshold condition. These instructions can also cause the processing circuit 112 to read and process received transmissions, adjust the timing of the timing circuit 115, process data or information received from other devices (e.g., calibration information, encryption or authentication information received from the display device 120, etc.), perform tasks to establish and maintain communication with the display device 120, interpret voice commands from the user, and cause the communication circuit 116 to transmit, etc. In embodiments where SCD 102 includes a user interface, the instructions may cause processing circuitry 112 to control the user interface, read user input from the user interface, display information on the user interface, format display data, etc. The functionality described herein and encoded in the instructions may be implemented by SCD 102 using a hardware or firmware design that does not rely on executing stored software instructions to implement the functionality.

[0097] Memory 114 may be shared by one or more of the various functional units present within SCD 102, or may be distributed among two or more of them (e.g., as separate memories present within different chips). Memory 114 may also be its own separate chip. Memory 114 is non-transitory and may be volatile memory (e.g., RAM, etc.) and / or non-volatile memory (e.g., ROM, flash memory, F-RAM, etc.).

[0098] The communication circuit 116 may be implemented as one or more components (e.g., a transmitter, a receiver, a transceiver, a passive circuit, an encoder, a decoder, and / or other communication circuits) that perform the function of communicating via a corresponding communication path or link. The communication circuit 116 may include or be coupled to one or more antennas for wireless communication.

[0099] The power supply 111 may include one or more batteries, which may be rechargeable or disposable batteries for single use. A power management circuit may also be included to regulate battery charging and monitor the use of the power supply 111, boost voltage, perform DC conversion, etc.

[0100] Additionally, on-skin or sensor temperature readings or measurements may be collected by an optional temperature sensor (not shown). These readings or measurements may be transmitted from SCD 102 to another device (e.g., display device 120) (either individually or as aggregated measurements over time). However, the temperature readings or measurements may be used in conjunction with a software routine executed by SCD 102 or display device 120 to correct or compensate for analyte measurements output to a user, rather than or in addition to actually outputting temperature measurements to a user.

[0101] Exemplary Embodiments of Drug Delivery Devices

[0102] The drug delivery function of the integrated management system 100 can be implemented by including one or more drug delivery devices (MDD) 152. MDD 152 can be any device configured to deliver a specific dose of medicine. MDD 152 can also include a device (e.g., a pen cap) that transmits data about the dose to the IMS, even if the device itself may not deliver the drug. MDD 152 can be configured as a portable injection device (PID) that can deliver a single dose per injection (such as a push injection). PID can be a basic manual syringe, in which the drug is either pre-loaded in the syringe or must be sucked into the syringe from a container before injection. However, in most embodiments, PID includes an electronic device for docking with the user and performing drug delivery. PID is commonly referred to as a drug pen, although a pen-like appearance is not required. PIDs with user interface electronics are commonly referred to as smart pens. PIDs can be used to deliver a dose and then discarded, or can be durable and reused to deliver multiple doses in a day, a week, or a month. PIDs are often relied on by users who practice a multiple daily injection (MDI) treatment regimen.

[0103] The MDD may also include a pump and an infusion set. The infusion set includes a tubular cannula that is at least partially located within the recipient's body. The tubular cannula is in fluid communication with the pump, which can deliver the drug through the cannula into the recipient's body in small increments over time. The infusion set can be applied to the recipient's body using an infusion set applicator, and the infusion set is typically implanted for 2 to 3 days or longer. The pump device includes electronics for docking with the user and for controlling the slow infusion of the drug. Both the PID and the pump can store the drug in a drug reservoir.

[0104] The MDD 152 may be used as part of a closed-loop system (e.g., an artificial pancreas system that does not require user intervention to operate), a semi-closed-loop system (e.g., an insulin circuit system that rarely requires user intervention to operate, such as to confirm dose changes), or an open-loop system. For example, analyte levels of a diabetic patient may be monitored by the SCD 102 in a repetitive, automated manner, and this information may be transmitted to an application and incorporated into various analyses and reports.

[0105] In many embodiments, the integrated management system can include data for different types of insulin (e.g., rapid-acting (RA), short-acting insulin, intermediate-acting insulin (e.g., NPH insulin), long-acting (LA), ultra-long-acting insulin, and mixed insulin), and will be the same drug delivered by MDD 152. Types of insulin include human insulin and synthetic insulin analogs. Insulin can also include premixed preparations. However, the integrated management implementations and drug delivery capabilities of MDD 152 described herein can be applied to other non-insulin drugs. Such drugs can include, but are not limited to, exenatide, exenatide extended release, liraglutide, lixisenatide, semaglutide, pramlintide, metformin, SLGT1-i inhibitors, SLGT2-i inhibitors, and DPP4 inhibitors. The integrated management implementation can also include combined therapy. Combined therapy can include, but is not limited to, insulin and glucagon-like peptide-1 receptor agonists (GLP-1RA), insulin, and pramlintide.

[0106] For ease of describing the integrated management implementation herein, MDD 152 will generally be described in the form of a PID (specifically a smart pen). However, those skilled in the art will readily appreciate that MDD 152 may alternatively be configured as a pen cap, a pump, or any other type of drug delivery device.

[0107] In some embodiments, the IMS may include a connected pen cap. After the connected pen cap is attached to the insulin pen and paired with the display device, each time a dose of insulin is delivered, the connected pen cap may be displayed via, for example, Automatically transmits dose data to a display device.

[0108] Figure 3A 1 is a schematic diagram depicting an exemplary embodiment of an MDD 152 configured as a PID (specifically a smart pen). The MDD 152 may include a housing 154 for electronics, an injection motor, and a drug reservoir (see Figure 3B), the drug can be delivered from the reservoir through the needle 156. The housing 154 may include a removable or detachable cover or cover 157, which when attached can shield the needle 156 when not in use, and then be removed for injection. The MDD 152 may also include a user interface 158, which can be implemented as a single component (e.g., a touch screen for outputting information to a user and receiving input from a user) or multiple components (e.g., a touch screen or display combined with one or more buttons, switches, etc.). The MDD 152 may also include an actuator 159, which can be moved, pressed, touched, or otherwise activated to initiate the delivery of the drug from the internal reservoir through the needle 156 into the recipient body. According to some embodiments, the cover 157 and the actuator 159 may also include one or more safety mechanisms to prevent removal and / or actuation, thereby reducing the risk of harmful drug injection. The details of these safety mechanisms and other mechanisms are described in U.S. Patent Publication No. 2019 / 0343385 ('385 Publication), which is incorporated herein in its entirety for all purposes. Figure 3C 1 is a schematic diagram of an MDD 152 and a smart button configured to be mounted on an actuator of a delivery pen. The MDD 152 (which can be a disposable drug delivery pen) can include a display 158 and a dosing selector (such as a rotatable dial) to select a dose. The smart button 2190 can be mounted on the dosing selector and actuator 159 and snapped together with the pen 2180. After the smart button 2190 is paired with a reader device, the smart button 2190 can track the dose, store the dosing data, and transmit it to the reader device. The drug can be delivered by directly pressing the smart button 2190 to inject the dose. The smart button 2190 can also include a display that can display a recommended dose and / or an administered dose.

[0109] Figure 3B is a block diagram depicting an exemplary embodiment of an MDD 152 having electronics 160 coupled to a power source 161 and an electric injection motor 162, which in turn is coupled to the power source 161 and a drug reservoir 163. A needle 156 is shown to be in fluid communication with the reservoir 163, and a valve (not shown) may be present between the reservoir 163 and the needle 156. The reservoir 163 may be permanent, or may be removable and replaceable with another reservoir containing the same or a different drug. The electronics 160 may be implemented in one or more semiconductor chips (e.g., an application specific integrated circuit (ASIC), a processor or controller, a memory, a programmable gate array, etc.). In Figure 3BIn an embodiment, the electronic device 160 may include an advanced functional unit including a processing circuit 164, a memory 165, a communication circuit 166 configured to communicate with one or more devices external to the MDD 152 (such as the display device 120) in a wired and / or wireless manner, and a user interface electronic device 168.

[0110] MDD 152 can be implemented in a highly interconnected manner, where power supply 161 and Figure 3B Each of the components shown in the figure is coupled, and wherein those components that transmit or receive data, information, or commands (e.g., processing circuitry 164, memory 165, and communication circuitry 166) can be communicatively coupled to each other such component via, for example, one or more communication connections or buses 169.

[0111] Processing circuitry 164 may include one or more processors, microprocessors, controllers, and / or microcontrollers, each of which may be a discrete chip or distributed among multiple different chips (and portions thereof). Processing circuitry 164 may include on-board memory. Processing circuitry 164 may interface with communication circuitry 166 and perform analog-to-digital conversion, encoding and decoding, digital signal processing, and other functions that help convert data signals into a format suitable for wireless or wired transmission (e.g., in-phase and quadrature). Processing circuitry 164 may also interface with communication circuitry 166 to perform the reverse functions required to receive wireless transmissions and convert them into digital data or information.

[0112] Processing circuitry 164 may execute software instructions stored in memory 165. These instructions may cause processing circuitry 164 to receive a user selection or provision of a specified dose (e.g., input via user interface 158 or received from another device), process a command to deliver the specified dose (such as a signal from actuator 159), and control motor 162 to cause delivery of the specified dose. These instructions may also cause processing circuitry 164 to read and process received transmissions, process data or information received from other devices (e.g., calibration information, encryption or authentication information received from display device 120, etc.), perform tasks to establish and maintain communications with display device 120, interpret voice commands from a user, cause communication circuitry 166 to perform transmissions, and the like. In embodiments where MDD 152 includes user interface 158, the instructions may cause processing circuitry 164 to control the user interface, read user input from the user interface (e.g., input of a drug dose for administration or input of confirmation of a recommended drug dose), display information on the user interface, format display data, and the like. The functionality described herein as encoded in the instructions may be implemented by MDD 152 using a hardware or firmware design that does not rely on execution of stored software instructions to implement the functionality.

[0113] Memory 165 may be shared by one or more of the various functional units present within MDD 152, or may be distributed among two or more of them (e.g., as separate memories present within different chips). Memory 165 may also be its own separate chip. Memory 165 is non-transitory and may be volatile memory (e.g., RAM, etc.) and / or non-volatile memory (e.g., ROM, flash memory, F-RAM, etc.).

[0114] The communication circuitry 166 may be implemented as one or more components (e.g., a transmitter, a receiver, a transceiver, a passive circuit, an encoder, a decoder, and / or other communication circuitry) that perform the functions of communicating over a corresponding communication path or link. The communication circuitry 166 may include or be coupled to one or more antennas for wireless communication. Details of exemplary antennas may be found in the '385 publication, which is incorporated herein in its entirety for all purposes.

[0115] The power supply 161 may include one or more batteries, which may be rechargeable or disposable batteries for one-time use. A power management circuit may also be included to regulate battery charging and monitor the use of the power supply 161, boost voltage, perform DC conversion, etc.

[0116] MDD 152 may also include an integrated or attachable in vitro glucose meter, including an in vitro test strip port (not shown) to receive an in vitro glucose test strip for performing in vitro blood glucose measurements.

[0117] Exemplary Embodiments of a Display Device

[0118] The display device 120 can be configured to display information related to the system 100 to the user and accept or receive input from the user that is also related to the system 100. The display device 120 can display the most recently measured analyte level to the user in any number of forms. The display device can display the user's historical analyte level and other metrics describing the user's analyte information (e.g., time in range, dynamic glucose profile (AGP), hypoglycemia risk level, etc.). The display device 120 can display drug delivery information, such as historical dosage information and administration time and date. The display device 120 can display alarms, alerts, or other notifications related to analyte levels and / or drug delivery.

[0119] Display device 120 can be dedicated to system 100 (e.g., an electronic device designed and manufactured for the primary purpose of docking with an analyte sensor and / or a drug delivery device), as well as a multifunctional general-purpose computing device, such as a handheld or portable mobile communication device (e.g., a smart phone or tablet), or a laptop, personal computer, or other computing device. Display device 120 can be configured as a mobile intelligent wearable electronic component, such as one or more smart glasses, or a smart watch or wristband. Display devices and variations thereof can be referred to as "reader devices," "readers," "handheld electronic devices" (or handheld devices), "portable data processing" devices or units, "information receivers," "receiver" devices or units (or receivers for short), "relay" devices or units, or "remote" devices or units, to name a few.

[0120] Figure 4A 1 is a schematic diagram depicting an exemplary embodiment of a display device 120. Here, the display device 120 includes a user interface 121 and a housing 124, a display device electronics 130 ( Figure 4B ) is held in the housing. The user interface 121 can be implemented as a single component (e.g., a touch screen capable of input and output) or multiple components (e.g., a display and one or more devices configured to receive user input). In this embodiment, the user interface 121 includes a touch screen display 122 (configured to display information and graphics and accept user input by touch) and input buttons 123, both of which are coupled to the housing 124.

[0121] Software that interacts with SCD 102, MDD 152, and / or a user may be stored on display device 120 (e.g., stored by a manufacturer or downloaded by a user in the form of one or more "applications" or other software packages). Additionally or alternatively, the user interface may be effected by a web page displayed on a browser or other Internet interface software executable on display device 120.

[0122] Figure 4B1 is a block diagram of an exemplary embodiment of a display device 120 having display device electronics 130. Here, the display device 120 includes a user interface 121, which includes a display 122 and input components 123 (e.g., buttons, actuators, touch-sensitive switches, capacitive switches, pressure-sensitive switches, jog wheels, microphones, speakers, etc.), processing circuits 131, memory 125, communication circuits 126 configured to communicate with and / or communicate from one or more other devices external to the display device 120, a power supply 127, and timing circuits 128 (e.g., oscillators and phase-locked loops for providing clocks or other timing to components of the SCD 102). Each of the above components can be implemented as one or more different devices, or can be combined into a multi-function device (e.g., integrating the processing circuit 131, memory 125, and communication circuits 126 on a single semiconductor chip). The display device 120 can be implemented in a highly interconnected manner, wherein the power supply 127 and the communication circuit 128 are connected to each other. Figure 4B Each of the components shown in the drawings is coupled, and wherein those components that transmit or receive data, information, or commands (e.g., user interface 121, processing circuitry 131, memory 125, communication circuitry 126, and timing circuitry 128) can be communicatively coupled to each other such component via, for example, one or more communication connections or buses 129. Figure 4B is an abbreviated representation of typical hardware and functionality residing within a display device, and one of ordinary skill in the art will readily recognize that other hardware and functionality (eg, codecs, drivers, glue logic) may also be included.

[0123] Processing circuitry 131 may include one or more processors, microprocessors, controllers, and / or microcontrollers, each of which may be a discrete chip or distributed among multiple different chips (and portions thereof). Processing circuitry 131 may include on-board memory. Processing circuitry 131 may interface with communication circuitry 126 and perform analog-to-digital conversion, encoding and decoding, digital signal processing, and other functions that help convert data signals into a format suitable for wireless or wired transmission (e.g., in-phase and quadrature). Processing circuitry 131 may also interface with communication circuitry 126 to perform the reverse functions required to receive wireless transmissions and convert them into digital data or information.

[0124] Processing circuit 131 may execute software instructions stored in memory 125. These instructions may cause processing circuit 131 to process raw analyte data (or pre-processed analyte data) and obtain corresponding analyte levels suitable for display to a user. These instructions may cause processing circuit 131 to read, process and / or store dosage instructions from a user and cause dosage instructions to be transmitted to MDD 152. These instructions may cause processing circuit 131 to execute user interface software suitable for presenting a set of interactive graphical user interface screens to a user to configure system parameters (e.g., alarm thresholds, notification settings, display preferences, etc.), present current and historical analyte level information to a user, present current and historical drug delivery information to a user, collect other non-analyte information from a user (e.g., information about meals consumed, activities performed, medications administered, etc.), and present notifications and alarms to a user. The instructions may also cause processing circuitry 131 to cause communication circuitry 126 to make transmissions, may cause processing circuitry 131 to read and process received transmissions, read input from user interface 121 (e.g., to enter a medication dose to be administered or to confirm a recommended medication dose), display data or information on user interface 121, adjust the timing of timing circuitry 128, process data or information received from other devices (e.g., analyte data, calibration information, encryption or authentication information received from SCD 102, etc.), perform tasks to establish and maintain communications with SCD 102, interpret voice commands from a user, etc. The functionality described herein and encoded in the instructions may be implemented by display device 120 using a hardware or firmware design that does not rely on executing stored software instructions to implement the functionality.

[0125] The memory 125 may be shared by one or more of the various functional units present within the display device 120, or may be distributed among two or more of them (e.g., as separate memories present within different chips). The memory 125 may also be its own separate chip. The memory 125 is non-transitory and may be a volatile memory (e.g., RAM, etc.) and / or a non-volatile memory (e.g., ROM, flash memory, F-RAM, etc.).

[0126] The communication circuit 126 may be implemented as one or more components (e.g., a transmitter, a receiver, a transceiver, a passive circuit, an encoder, a decoder, and / or other communication circuits) that perform the function of communicating via a corresponding communication path or link. The communication circuit 126 may include or be coupled to one or more antennas for wireless communication.

[0127] The power supply 127 may include one or more batteries, which may be rechargeable or disposable batteries for single use. A power management circuit may also be included to regulate battery charging and monitor the use of the power supply 127, boost voltage, perform DC conversion, etc.

[0128] Display device 120 may also include one or more data communication ports (not shown) for wired data communications with external devices such as computer system 170, SCD 102, or MDD 152. Display device 120 may also include an integrated or attachable in vitro glucose meter including an in vitro test strip port (not shown) to receive an in vitro glucose test strip for performing in vitro blood glucose measurements.

[0129] The display device 120 can display the measured analyte data received from the SCD 102, and can also be configured to output alarms, alarm notifications, glucose values, etc., which can be visual, auditory, tactile, or any combination thereof. In some embodiments, the SCD 102 and / or the MDD 152 can also be configured to output alarms or alarm notifications in a visible, audible, tactile form, or a combination thereof. Additional details and other display embodiments can be found, for example, in U.S. Patent Publication No. 2011 / 0193704, which is incorporated herein by reference in its entirety for all purposes.

[0130] Exemplary embodiments related to integration management

[0131] The following exemplary embodiments relate to an integrated management system (IMS), which in many embodiments will be implemented as a set of software instructions stored and / or executed on one or more electronic devices. In some embodiments, the IMS is stored, executed, and presented to a user on the same single electronic device. In other embodiments, the IMS may be stored and executed on one device and presented to a user on a different electronic device. For example, the IMS may be stored and executed on a trusted computer system 180 and presented to a user via a web page displayed by an Internet browser executed on a display device 120.

[0132] Thus, there are many different implementations involving the number and type of electronic devices used to store, execute and present the IMS or parts thereof to a user.With regard to presentation to a user, a device configured to implement this functionality will be referred to herein as a User Interface Device (UID) 200 . Figure 5 is a block diagram depicting an exemplary embodiment of a UID 200. In this embodiment, UID 200 includes a housing 201 coupled to a user interface 202. User interface 202 is capable of outputting information to a user and receiving input or information from a user. In some embodiments, user interface 202 is a touch screen. As shown here, user interface 202 includes a display 204 (which can be a touch screen) and an input component 206 (e.g., a button, an actuator, a touch-sensitive switch, a capacitive switch, a pressure-sensitive switch, a jog wheel, a microphone, a touch pad, soft keys, a keyboard, etc.).

[0133] Many of the devices described herein may be implemented as UID 200. For example, in many implementations, display device 120 will be used as UID 200. In some implementations, MDD 152 may be implemented as UID 200. In implementations where SCD 102 includes a user interface, SCD 102 may be implemented as UID 200. Computer system 170 may also be implemented as UID 200.

[0134] Example Implementation of User Experience of Integrated Management System

[0135] like Fig. 6A As seen in the exemplary method 300 of the user experience, in step 302, the user can check the analyte level, such as the glucose level. As previously described, the user can scan the SCD 102, or otherwise transmit the analyte level or data indicating the analyte level to the display device 120. In step 304, the user administers a drug (e.g., insulin) from the connected drug delivery device 152. The drug delivery device 152 can be a smart, connected insulin pen, a connected pen cap, or an automatic insulin delivery (AID) device in a closed-loop system, as previously described. In step 306, the user transmits dosage information from the drug delivery device 152 to the display device 120. The transmission can be achieved by methods known in the art. For example, the display device 120 (e.g., a smart phone) can scan the connected drug delivery device 152, and the information can be transmitted via NFC. In some embodiments, after successfully scanning the insulin pen, the monitoring application can display a confirmation screen. Optionally, the dosage information can be transmitted automatically without any further action by the user. For example, scanning may not be required, and the dosage information can be transmitted via NFC. or other wireless communication protocols. For example, in the case of a connected pen cap, connected insulin pen or AID device, data can be automatically transmitted to the display device after the dosage is detected. The transmission of drug information can be in a variety of ways, including scanning, transmitting, downloading, uploading, exporting, importing, connecting, synchronizing, pairing and other equivalent terms. Data can also be transmitted via such as The data transmitted may include data related to drug (e.g., insulin) injection, emission, event, note, log entry or other equivalent terms. The data may be referred to as insulin data, insulin record, insulin log, insulin dosage or other equivalent terms. After the dosage information is transmitted, optionally, a notification (e.g., lock screen or banner notification) may appear on a display device, including a message that a log or other report or application has been updated, or may also include the amount of drug delivered and the delivery time. In step 308, the user and other people (e.g., caregiver, HCP) may then view the combined history (which may include analyte levels and drug dosage) in various displays and reports to visualize and help the user treat their diabetes.

[0136] If a sufficient amount of data has been received to generate a report or reports, the system may display a notification on the reader or display device 120. In some embodiments, such as Figure 6B As seen in method 820 of FIG. 8 , the system may receive a first type of data including data indicating an analyte level (step 822). The first type of data may be received from the SCD 102. The system may also receive a second type of data including medication administration data (step 824). The second type of data may be received from the MDD 152. The medication administration data may include a dosage and a corresponding administration time of the dosage.

[0137] Then, in step 826, the system can determine whether the received second type of data meets the minimum medication data reporting condition for inclusion in the report. In some embodiments, the minimum medication data reporting condition can be a sufficient amount of the second type of data to generate a weekly report, optionally a daily report. In some embodiments, the minimum medication data reporting condition can be whether the second type of data includes medication data that has been received for at least 1 day, optionally at least 2 days, optionally at least 3 days, optionally at least one week, optionally at least two weeks, optionally at least one month. If the received second type of data does not meet the minimum medication data reporting condition, the method returns to step 824 and the system receives additional second type of data.

[0138] If the received second type of data does meet the minimum dosing data reporting condition, the system generates a report (step 828) that includes at least a portion of the second type of data, a metric based on at least a portion of the second type of data, a recommendation based on at least a portion of the second type of data, or a summary of at least a portion of the second type of data. In some embodiments, the report additionally includes a portion or section based on the first type of data. As described elsewhere in this application, a portion or section based on the first type of data may include current analyte levels, trend arrows, analyte traces, recommendations, patterns, high risk and low risk, and other analyte metrics (including time in range and time out of range).

[0139] In step 827, the system displays a message or notification about the report. In some embodiments, the message may notify the user that the report is available. The message may also provide a link to the report. The message may be displayed in a modal window or as a banner.

[0140] If the user encounters a problem or has trouble transferring data from the drug delivery device 152 to the display or reader device 120, the system can assist the user by displaying helpful tips and / or animations demonstrating how to properly scan the MDD 152. Figure 6C As seen in method 830 of , the system can receive a first type of data including data indicative of an analyte level (step 832). The first type of data can be received from the SCD 102. The system can also receive a second type of data including error data associated with the MDD 152 (step 834). The second type of data can be received from the MDD 152.

[0141] The system may display information associated with the data indicative of the analyte level on the reader or display device 120 (step 836). As described elsewhere herein, the data indicative of the analyte level may include current analyte level, trend arrow, analyte trace, recommendations, patterns, high risk and low risk, and other analyte metrics (including time in range and time out of range).

[0142] The system may also display a message on the reader or display device 120 based on the error data received in step 838. In some embodiments, the error data may include data indicating the number of failed scans of the MDD 152. In some embodiments, if the number of failed scans exceeds a threshold, a message may be displayed. The message may be a prompt related to scanning or how to scan the MDD 152 (e.g., useful information or instructions on how to scan the MDD 152). The message may also optionally be or include an animation depicting how to scan the MDD. The message may be displayed in a modal window or as a banner.

[0143] The system may also remind the user to transfer medication administration data from the MDD 152 to the system if no transfer occurs within a time period greater than a threshold. Fig.6D As seen in method 840 in FIG. 1 , the system may receive a first type of data including data indicating an analyte level (step 842). The system may also receive a second type of data including medication administration data (step 844). The medication administration data may include a dosage and a corresponding administration time of the dosage.

[0144] Then, in step 846, the system may determine whether the time period that has passed since the second type of data was received exceeds a threshold. If the time period that has passed since the second type of data was received does not exceed the threshold, the method returns to step 844 and receives additional second type of data. The threshold may be 6 hours, optionally 12 hours, optionally 24 hours, optionally 48 hours, optionally 72 hours.

[0145] If the time period that has passed since the second type of data was received exceeds the threshold, the system displays a message or notification prompting the user to transmit the second type of data in step 848. The message may be displayed in a modal window or as a banner. In some embodiments, the message may encourage the user to scan the MDD 152 to transmit the medication administration data.

[0146] In order to be able to transfer data from the drug delivery device 152 to the IMS, the drug delivery device 152 must first be added to the IMS. Figure 7 An exemplary method 320 for adding a drug delivery device 152 to an IMS and managing connected drug delivery devices 152 is described. In method 310, a user may select a drug delivery device 152 from a menu such as Figure 30Y-2 To add an insulin pen, select "Insulin Pen" from the drop-down menu (see ). Fig. 20A As seen in the GUI 322 of FIG. 1 , the “Start” screen may include an animated depiction of the drug delivery device 152 in communication with the display device 120 and also list different tasks or capabilities of the IMS after the drug delivery device 152 is connected to the IMS. These include connecting a compatible smart pen to record insulin doses, viewing and learning from past doses, and sharing reports with the user's medical team. After selecting “Start”, as shown in FIG. Fig. 20A As seen in the GUI 324 of FIG. 310 , the insulin pen settings may be opened and, in step 312, the user may be prompted to select the drug delivery device 152 they wish to connect. The drug delivery devices 152 (e.g., insulin pens) may be listed by their brand name. After the user selects the appropriate drug delivery device and selects “Next,” the user may proceed to step 312. Fig. 20BAs seen in the GUI 326 in FIG. 1 , a graphic or animation may be presented illustrating how to scan a drug delivery device 152 (e.g., an insulin pen) with a display device 120 (e.g., a smartphone). In addition, the GUI 326 may also include text indicating that scanning is performed by placing the insulin pen display flat on the back of the phone. The GUI 326 may also provide text indicating that the user may need to slowly move the insulin pen to find the correct position to affect the connection / communication between the insulin pen and the phone. A link to the user manual of the insulin pen may also be provided, which contains more information about how to connect the insulin pen to the phone. In some embodiments, if the user has already added the insulin pen to the monitoring application, the monitoring application may display a modal window or pop-up window notifying the user that the scanned insulin pen is already an added insulin pen when scanning during insulin pen setup. After a successful connection has been made, a message such as Fig. 20B , indicating that a new drug delivery device 152 has been added to the IMS. The name of the newly added drug delivery device may also appear on the GUI 328. After selecting "Next" in step 314, the user may be presented with a prompt to select a pen color for the newly connected drug delivery device 152. Selectable options 332 with different colors may appear on the GUI 330, such as Fig. 20C The color options for the insulin pen can be based on the model of insulin pen scanned during setup. Fig. 20C After selecting "Next" in GUI 334 in step 316, the user may be prompted to select the type of medication contained in the newly connected medication delivery device 152. In the case where medication delivery device 152 is an insulin pen, in step 316, the user may be prompted to select a different type of insulin from list 336, such as rapid-acting insulin, long-acting insulin, or other insulin. After selecting "Next" in step 318, the user may then Fig.20D The user is prompted in the GUI 338 to select a brand of the selected insulin type. A list 340 of available brands may be provided. Different lists of brand names may be provided for different types of insulin. For example, when the user selects rapid-acting insulin, a first list of brand names may be selected. When the user selects long-acting insulin, a second list may be selected. When the user selects "other," a third list of brand names may be displayed. Optionally, the user may add new brands that are not included in the provided lists. Fig.20DAfter selecting "next" in the GUI 342 of the user, the user can see an indication that the setup of the new drug delivery device 152 is complete. The GUI 342 may also include a reminder of the software that scans the connected drug delivery device 152 to transmit the insulin dose to the IMS. The GUI 342 may also include an animation that shows how to scan the drug delivery device 152 (e.g., an insulin pen) with a display device 120 (e.g., a smart phone). In addition, the GUI may also include text indicating that the insulin pen display is placed flat on the back of the phone for scanning. The GUI may also provide text indicating that the user may need to slowly move the insulin pen to find the correct position to affect the connection / communication between the insulin pen and the phone.

[0147] The monitoring app can allow the user to scan the sensor control device at any time during insulin pen setup.

[0148] Additional drug delivery devices may be connected in the same manner as described above. Additional drug delivery devices may be assigned a different color or other distinguishing function or name than previously connected drug delivery devices. For example, a drug delivery device 152 that delivers rapid-acting insulin may be assigned a blue pen color, while a drug delivery device 152 that delivers long-acting insulin may be assigned a different color, such as red, silver, or black. Additional drug delivery devices may be added under the insulin pen menu (see Figure 10) by selecting an option to add another drug delivery device, such as a plus sign labeled "Add another pen." Fig.20E of 356).

[0149] If a new insulin pen is scanned, the monitoring application may prompt the user to add the newly scanned insulin pen as described in detail above, even if the monitoring application does not display a GUI associated with the settings. The monitoring application may only collect and store data for the insulin pens that have been added to the monitoring application. The monitoring application may have the ability to obtain all new insulin pen doses from the added insulin pens. The monitoring application may use a timestamp such as provided by the insulin pen 152 to determine the timestamp of the insulin pen dose.

[0150] Users can select the option to "manage their own insulin pen connections" under the insulin pen menu. Fig.20EAs seen in GUIs 350 and 368 of , the user can see an insulin pen menu GUI 350 that lists the connected medication delivery devices 152, as well as an indication of the name of the added insulin pen, the type and / or brand name 358 of insulin delivered by the medication delivery device 152, a graphic of the insulin pen 352, and details of the last scan 360, which may include a last timestamp associated with the time the insulin pen successfully scanned and / or the amount of medication delivered. The monitoring application may default the insulin pen name to the model of the insulin pen. The monitoring application may have a maximum number of insulin pens that can be added. In some embodiments, the maximum number of insulin pens that can be added may be 8, optionally 9, optionally 10, optionally 12, optionally 15 insulin pens. If no insulin pens have been added, the application may display a summary of the benefits of the insulin pens. As previously described with respect to GUI 326, if the user selects the information i icon, GUIs 364a, 364b may appear, such as Fig.20F , which includes information about how to transmit insulin log and dosage information. GUI 364a, GUI 364b may include an animation of how to scan drug delivery device 152 with a smart phone. Different GUIs may appear to indicate how to scan on IOS system 364a and Android system 364b. In addition, GUI 364a, GUI 364b may also include text indicating that scanning is performed by placing the insulin pen display flat on the back of the phone. GUI 364a, GUI 364b may also provide text indicating that the user may need to slowly move the insulin pen to find the correct position to affect the connection / communication between the insulin pen and the phone. The insulin pen menu GUI 350 may include a list of all added insulin pens, as well as all relevant information for each added insulin pen discussed above.

[0151] In some embodiments, the drug delivery device 152 may be a pen cap, such as It can be through Wirelessly transmit dosage data. The drug delivery device 152 may need to use Instead of NFC pairing with the monitoring application. The monitoring application can remind the user to ensure that the display device 120 is enabled. The monitoring application may display a GUI that prompts the user to enter and / or confirm a code on the drug delivery device 152. The GUI may also include a picture, diagram, or animation to show the location of the code on the drug delivery device 152. After entering the code, the monitoring application may display a GUI containing instructions to press and release a button on the drug delivery device 152 to pair the device with the display device 120. The instructions may include a text description, diagram, picture, or animation to help the user with the pairing. A window may appear on the display device 120 indicating that the drug delivery device 152 wants to be paired with the display device 120. The user may need to select "pair" before the pairing is complete. After the drug delivery device has been paired with the display device 120, a GUI may be displayed that shows confirmation that the pairing and / or setup is complete.

[0152] Once the drug delivery device 152 has been connected to the monitoring software on the display device 120, the dosage information can be downloaded or otherwise transmitted from the drug delivery device 120 (e.g., via NFC or ) to the software. FIG. 21A to FIG. 21C As seen in GUI 390 and GUI 391, the monitoring software may indicate that it can accept downloads from a connected medication delivery device 152 (e.g., there may be a message in, for example, a banner indicating that it is "ready to scan"). After the user has scanned the medication delivery device 152 in step 316, the monitoring application may provide a confirmation summary. In some embodiments, a modal window 394 may open indicating that a new dose has appeared in the log. For example, window 394 in GUI 390 and 391 indicates the number of doses transferred from the medication delivery device to the monitoring software after a successful transfer. The modal window 394 may also indicate which medication delivery device 396 was scanned, the type of insulin administered 398, the brand of insulin administered, and also include a graphical representation or image (including color) of the insulin pen. The monitoring application may also allow the user to change the insulin type and insulin brand from the confirmation summary. The monitoring application may prevent doses from the same insulin pen from being transferred multiple times. In addition, after the first scan of the medication delivery device 152, a message such as Fig.21A , allows the user to select a default selection of insulin type that will be used as the default selection the next time the user scans an insulin pen. After the user selects and saves a new insulin brand for the insulin pen, a pop-up window 403 may appear notifying the user that their insulin type has been updated and that if they need to change it, they can change it in the insulin pen settings.

[0153] like Fig.21BAs seen in FIG. 4 , the home screen 410 may include a button or link 412 for selecting a scanned drug delivery device 152. The home screen 410 may also include an analyte curve, time statistics within a range, the last read analyte level, the average analyte level, an analyte reading graph for a time period (e.g., the day), and an indication of the current sensor life. The home screen 410 may also include an icon (e.g., a syringe icon) 414 along the analyte reading graph, which indicates when various drugs are administered. The icon 414 may be positioned along the analyte reading graph to correspond to / indicate the time of administration. In some embodiments, the user may view and edit the insulin record by clicking on the syringe icon 414 in the home screen 410. If desired, the user may click on the syringe icon to view the dose, and then further click on the pencil icon to edit the entry. In some embodiments, a syringe icon with a notepad may indicate a dose to which additional comments and annotations have been added. In some embodiments, a syringe icon with an apple icon may indicate a dose to which food annotations have been added. In some embodiments, a syringe icon without other annotations may mark a dose automatically transmitted from a connected drug delivery device 152. Icons indicating food (e.g., apple), exercise (e.g., runner), or comments (e.g., notepad) may also be indicated along or above the analyte reading graph, placed along the timeline (x-axis) based on when the food was consumed or when the comment was added.

[0154] like Fig.21B As seen in the log GUI 416, the log GUI 416 can also be accessed from the menu. The log GUI 416 can contain a list of various events recorded and the time when the events occurred, including the drug doses administered. For entries imported from the drug delivery device 152, a syringe icon may appear next to the amount of the drug administered (e.g., in units), as well as a timestamp associated with the insulin pen dose. Instances in which the drug delivery device 152 is pre-filled can also be listed in the log. A pre-fill dose (or "pre-fill") refers to an injection of a drug (e.g., insulin) to clear the air from the needle tip. A pre-fill dose can also be referred to as an air jet, flow check, jet, or other equivalent terms. Manually added notes can also be included in the log.

[0155] The monitoring application can allow the user to edit the notes associated with a particular medication administration event. If the user wants to edit the details about the insulin dose, the user can click on the line entry in the log GUI 416, which links to the log details GUI 430, such as Fig. 21C430,462 may include a description of the administered dose, including the insulin type and insulin brand associated with the insulin pen dose, the name of the insulin pen (as present during the download associated with the pen dose), the dose associated with the insulin pen dose or the prime designation, the insulin dose with a resolution of 0.5 units, and the time associated with the dose. If the user wants to add and / or edit the details of the selected insulin dose, the user can click on the edit (pencil) icon 444, which is linked to the edit note GUI 450, where the user can edit the information associated with each field. The user can include entries about carbohydrates, exercise, or custom notes. The edit note GUI 450 includes a banner that significantly indicates the date and time of the dose and the administration. It may also include various fields, such as the brand of dosage type (administered or primed insulin) 452, insulin, the number of units, the name of the delivery device, food 454, exercise 456, and comments 458. The user can edit the insulin type and / or insulin brand delivered by, for example, clicking on the drop-down bracket and selecting a new insulin type or insulin brand. The user can edit the dose from a therapeutic dose to a flow check (or priming) dose by, for example, clicking on the drop-down caret icon and selecting the priming / flow check option. In some embodiments, after the user indicates that this is a priming dose, a banner at the top of the edit note screen will indicate that this is a priming dose, such as Fig. 21C 460. The log details GUI 462 may also include the dose time and brand. In some embodiments, the monitoring application may not allow the user to edit the dose of the insulin dose (e.g., the dose field may not be editable). In some embodiments, the monitoring application may not allow the user to delete an insulin dose.

[0156] The user can view and edit recent insulin records by tapping the syringe icon on the Home screen. Delivered insulin doses can also be viewed in the Logbook. From the Main Menu, the Logbook can be selected or tapped to view it. The Logbook can contain notes for each insulin dose delivered from the insulin pen, as well as any additional notes added by the user. The user can edit notes by selecting an individual Logbook entry.

[0157] If there is an error, the monitoring application can request the user to confirm the details of the administered dosage. The details can include the dosage, type of medication, and time of delivery. FIG. 23A to FIG. 23CAs seen in , if an error is detected in the delivered dose data, a window 1052 in GUI 1050 or a window 1062 in GUI 1060 may appear, prompting the user to confirm details about the newly delivered dose. Optionally, the error may be recorded in the log GUI 1070 and / or the log details GUIs 1080 and 1081. In some embodiments, the log GUI 1070 and / or the log details GUIs 1080 and 1081 may include error indicators associated with certain doses. The error indicator may be a missing dose 1072 and / or a different syringe icon (e.g., a syringe with an exclamation point or question mark nearby) 1074. The user may edit the dose entry with the error by clicking on the edit (pencil) icon 444, which may link to the edit note GUI 1090 or 1091, as shown in FIG. Fig.23C 1071, the logbook GUI may include a note associated with the dose. The logbook GUI may also include an indication that the dose is a pre-filled dose 1075.

[0158] like Fig.21D As seen in the GUI 470 of FIG. 47A , the monitoring application may also prompt the user to learn more about new features of the monitoring application via a pop-up window 472. The prompt may notify the user of new features available by connecting a medication delivery device 152 (e.g., a smart insulin pen) and having the application track the user's insulin dosage. A similar window may also pop up when an update to the monitoring application is available.

[0159] The monitoring application may also allow the user to customize the name of the connected drug delivery device 152. The custom pen name may have an upper limit of approximately 48 characters. Fig.22A As seen in FIG. 4 , the user can navigate to the insulin settings GUI 480, where the user can click or select the “Name” field 482, which will open a name GUI window 486. The user can click or select the “New Name” field 488 and proceed to type in a newly selected name for the device. Fig.22A , the user enters "Home Pen" as the custom name for the device. After the user selects "Save", the new name will be displayed in the "Current Name" field 490 in the updated GUI 492. After the user changes any details of the insulin pen (including but not limited to the name of the insulin pen, the type of insulin, the brand of insulin, the color of the insulin pen), the monitoring application can retain the previous information associated with the old insulin pen dose after saving the changes.

[0160] like Fig. 22BAs seen in GUI 2250, the user can see a summary of the information related to the insulin pen in GUI 2250. The model name, manufacturer, serial number and software revision or version of the insulin pen can be listed in GUI 2250. GUI 2250 can also include a link to forget this pen 2252, which will cause the insulin pen to be unpaired from the monitoring application. If the user chooses to forget this pen link 2252, a modal window 2262 may appear, as seen in GUI 2260, which notifies the user that the insulin pen will be removed from the user's application, and unless the user reconnects the insulin pen, the user will not be able to transmit the insulin dose. The message in the modal window 2262 can also notify the user that removing their insulin pen will not affect any insulin log in the application. Modal window 2262 can also include link 2264, requiring the user to confirm that they want to forget the insulin pen. If the user chooses to forget the added insulin pen, the monitoring application may still retain the insulin dose transmitted before. The monitoring application can also allow the user to add the insulin pen added before.

[0161] The monitoring application can store and display the daily dose for a period of about 60 days, optionally about 90 days, optionally about 120 days (including the current day). Thus, the monitoring application can support displaying the daily insulin pen dose for a period starting from about 59 days, optionally about 89 days, optionally about 19 days before the current date and ending at the current date. The monitoring application may not store any dose with a dose unit value greater than an upper limit (e.g., about 250 units, optionally about 275 units, optionally about 300 units, optionally about 325 units, optionally about 350 units).

[0162] Insights and Alerts

[0163] Missed Meal Dosage Hints

[0164] If a dose is missed, the monitoring application may display an alarm, prompt, or reminder. In some embodiments, dose data is collected via Automatically transmitted to the monitoring application. For example, based on a rise in glucose levels and no doses recorded within a time period (e.g., 1 hour, optionally 2 hours, optionally 3 hours), the monitoring application may display an alert asking the user "Did you miss a meal dose?" In addition, the alert may indicate that the user's glucose is rising and the last recorded dose was X hours ago. The alert may also suggest that the user synchronize the drug delivery device 152 to update the dosing data. The alert may also suggest that if the user does miss a dose, the user should follow the advice of the HCP. In some embodiments, when the alert involves a specific meal, the alert may ask the user if they missed their [breakfast / lunch / dinner] dose, and then instruct the user to typically administer the dose before X:XX (e.g., the user typically administers the lunch dose before 1:30pm).

[0165] Users can set conditions for missed dose alerts or hints to be given to minimize the number of alerts that pop up on their devices. For each of breakfast, lunch, dinner, and long-acting doses, users can specify that missed dose hints are only displayed after a certain time of day. For example, if no dose is detected during a period of time before the indicated time, the user can set the breakfast dose hint to display after 10:00am, the lunch dose to display after 1:30pm, and the dinner dose to display after 8:00pm.

[0166] like Fig.25 As shown in the exemplary method 1900, starting at step 1902, the system or application can receive analyte data from the sensor control device 102. In step 1904, the system can receive insulin data from the subject (e.g., from the MDD 152). For example, the system or application can automatically receive insulin data wirelessly from a connected pen, connected pen cap, or other drug delivery device 152, for example, via In other embodiments, the system or application can check the latest insulin dosage data by requesting delivery information from different sources (including but not limited to MDD 152, MDD related applications, or interfaces storing the latest insulin delivery information (such as MDD application web servers)), or by checking the memory of various applications to obtain the latest insulin delivery information.

[0167] In step 1906, the system or application can determine whether the meal has been consumed. This determination can be made by analyzing the received analyte data and determining whether the analyte level has risen above a high threshold, or whether the rate of change of the analyte level is greater than a minimum rate of change threshold. Meal dose detection is described in more detail in U.S. Publication No. 2021 / 0030323, U.S. Publication No. 2021 / 0050085, and U.S. Application No. 17 / 591,229, all of which are expressly incorporated herein by reference in their entirety for all purposes. The high threshold analyte level may be 175 mg / dL, optionally 180 mg / dL, optionally 180 mg / dL, optionally 190 mg / dL, optionally 200 mg / dL, optionally 210 mg / dL, optionally 220 mg / dL, optionally 230 mg / dL, optionally 240 mg / dL, optionally 250 mg / dL, optionally 260 mg / dL, optionally 270 mg / dL. The high threshold analyte level may be set by the user. If the system determines that the meal has not been consumed, the system returns to step 1902 and receives additional analyte data.

[0168] If the system or application determines that the meal has been consumed, then in step 1908, the system can analyze the received insulin dosage data to determine whether an insulin dosage has been recorded or received within a time period. The time period can be about 1 hour, optionally about 2 hours, optionally about 3 hours. The time period can be optionally set by the user, rather than the default time set by the system. If an insulin dosage is recorded within the time period, the system determines that no dosage has been missed, and the system returns to step 1904 and receives additional insulin dosage data.

[0169] In some embodiments, the time period of each meal can be set by setting the time when the user should apply the dietary dose. The system can also check whether to record or receive the insulin dose before the set time of each meal. For example, if the breakfast dose is not recorded or received before 10:30am, the system can determine that the user leaks the breakfast dose. Similarly, if the user has applied the lunch dose usually before 2:30pm, the lunch dose may be at 2:30pm. And if the user has applied the dinner dose usually before 7:30pm, the dinner dose may be at 7:30pm. These times can be set by the user to meet their personal dietary habits.

[0170] If the system or application determines that an insulin dose has not been recorded or received within a particular meal period or set time, the system or application may display an alert interface associated with the missed meal dose in step 1910. In some embodiments, the user may customize the text of the alert interface.

[0171] Correction dose hint

[0172] If a period of time has passed since the last insulin dose and their glucose levels are still elevated, the monitoring application can display an alert, hint, or prompt to the user to consider a correction dose. In some embodiments, dose data is provided via Automatically delivered to the monitoring application. Users can set the conditions under which a correction dose alert or cue is given to minimize the number of alerts that pop up on their device. Users can configure alerts to appear only when their glucose level is above a high threshold (e.g., above about 250 mg / dL) and the time period since the last insulin dose is longer than a minimum time threshold (e.g., about 2 hours).

[0173] The user can also customize the message that appears in the cue. For example, the message may indicate that the dose they administered X hours (e.g., 2 hours) ago did not sufficiently lower their glucose, and now is a good time to administer an additional X units of insulin or take a walk in the park. The default message may be to follow their HCP's recommendation for correcting high glucose with therapy or exercise.

[0174] like Fig.26 As shown in the exemplary method 1920, starting at step 1922, the system or application can receive analyte data from the sensor control device 102. In step 1924, the system or application can receive insulin data for the subject (e.g., from the MDD 152). For example, the system or application can automatically receive insulin data from a connected pen, connected pen cap, or other drug delivery device 152 wirelessly (e.g., via ) without requesting the data. In other embodiments, the system or application can check the latest insulin dosage data by requesting delivery information from different sources (including but not limited to MDD 152, MDD related applications, or interfaces storing the latest insulin delivery information (such as MDD application web servers)), or by checking the memory of various applications to obtain the latest insulin delivery information.

[0175] In step 1926, the system or application can determine whether the received analyte level is above a high threshold (which indicates that the user's glucose is outside the target range). The high threshold analyte level can be 175 mg / dL, optionally 180 mg / dL, optionally 180 mg / dL, optionally 190 mg / dL, optionally 200 mg / dL, optionally 210 mg / dL, optionally 220 mg / dL, optionally 230 mg / dL, optionally 240 mg / dL, optionally 250 mg / dL, optionally 260 mg / dL, optionally 270 mg / dL. The high threshold analyte level can be set by the user. If the system determines that the analyte level is not above the high threshold, the system returns to step 1922 and receives additional analyte data.

[0176] If the system or application determines that the analyte level is above the high threshold, then in step 1928, the system or application can analyze the received insulin dosage data to determine whether a time period has passed since the insulin dosage was recorded or received. The time period can be about 2 hours, optionally about 2.5 hours, optionally about 3 hours. The time period can be optionally set by the user, rather than a default time set by the system. If the time period since the last recorded insulin dosage has not passed, the system returns to step 1924 and receives additional insulin dosage data.

[0177] If the system or application determines that a period of time has passed since the last insulin dose, the system or application may display an alert interface associated with the correction dose in step 1930. In some embodiments, the user may customize the text of the alert interface.

[0178] Congratulations message

[0179] The monitoring app can also display a congratulatory alert or message when an insulin dose causes glucose levels to return to the target range within a specified time period. For example, the alert or window might say "You won the glucose! You are back in range 2 hours after your last insulin dose." Users can choose to add a note (by typing or talking to text) detailing things that may have helped them reach their target range.

[0180] The user can set the conditions for displaying an alert or window by setting a maximum glucose level and a time limit to return to the target range. For example, the user can set the target range to less than 180 mg / dL and set the time to reach the target after dosing to 2 hours.

[0181] like Fig. 27As shown in the exemplary method 1940, starting at step 1942, the system or application can receive analyte data from the sensor control device 102. In step 1944, the system can receive insulin data for the subject (e.g., from the MDD 152). For example, the system can automatically receive insulin data from a connected pen, connected pen cap, or other drug delivery device 152 wirelessly (e.g., via ) without requesting the data. In other embodiments, the system or application can check the latest insulin dosage data by requesting delivery information from different sources (including but not limited to MDD 152, MDD related applications, or interfaces storing the latest insulin delivery information (such as MDD application web servers)), or by checking the memory of various applications to obtain the latest insulin delivery information.

[0182] In step 1946, the system or application can determine whether the received analyte level is below a high threshold, which indicates that the user's glucose is within the target range. The high threshold analyte level can be 190 mg / dL, optionally 185 mg / dL, optionally 180 mg / L, optionally 175 mg / dL, optionally 170 mg / dL. The high threshold analyte level can be set by the user. If the system or application determines that the analyte level is not below the high threshold, the system or application can return to step 1942 and receive additional analyte data.

[0183] If the system determines that the analyte level is below the high threshold, then in step 1948, the system can analyze the received insulin dosage data to determine whether a time period has passed since recording or receiving an insulin dose. The time period can be about 2 hours, optionally about 2.5 hours, optionally about 3 hours. The time period can be optionally set by the user, rather than a default time set by the system. If the time period since the last recorded insulin dose has not passed, the system returns to step 1944 and receives additional insulin dosage data.

[0184] If the system determines that a period of time has elapsed since the last insulin dose, the system may display an alert interface associated with the analyte level being within the target range in step 1950. In some embodiments, the user may customize the text of the alert interface.

[0185] Account Control

[0186] In some embodiments, an interface for an analyte monitoring software application is provided to allow for a "no account mode" in which a user does not need to create or log into a cloud-based server to use the monitoring application. In other embodiments, an interface for a monitoring application is provided to allow a user to opt-in or opt-out of sharing the user's sensor readings and / or other product-related data for research purposes.

[0187] like Fig.29A As seen in , GUI 2300 depicts a user account creation interface that allows a user to initiate the process of creating a cloud-based user account. By creating an account, a user can choose to share their data, including analyte data and dosage data, with third parties. These third parties include, but are not limited to, healthcare professionals, guardians, family, and friends. Account users can also access their complete glucose picture online, including dosage data integrated with glucose data. Account users can also back up their data to, for example, a cloud-based server. The data may be available and the user can continue to use the sensor even if the user switches mobile devices. According to one aspect of the embodiment, as Fig.29E As seen in method 2330, if the user does register an account, the cloud-based user account can allow the user to share information with healthcare professionals, family, and friends; utilize a cloud-based reporting platform to view more complex analyte reports; and back up the user's historical dose data and sensor readings to a cloud-based server (step 2334). If the user does not register an account, their data may not be backed up on the server (step 2336). In some embodiments, GUI 2300 may also include a "skip" link 2302 that allows the user to use the analyte monitoring software application in "no account mode" (e.g., without creating or linking to a cloud-based account). After selecting the "skip" link 2302, an information window 2312 in GUI 2310 may be displayed to notify that certain features are not available in "no account mode". Information window 2312 may also prompt the user to return to GUI 2300 or continue without creating an account.

[0188] Fig.29C 23 is a GUI 2330 depicting a menu interface displayed within the monitoring application when the user is in "no account mode." According to one aspect of the embodiment, the GUI 2330 includes a "Login" link 2332 that allows the user to leave the "no account mode" and create a cloud-based user account from within the analyte monitoring software application or log in using an existing cloud-based user account.

[0189] Next reference Fig.29D, GUI 2340 depicts a research consent interface that prompts the user to choose to decline or opt-in (via button 2442) to allow the user's sensor readings and / or other product-related data to be used for research purposes. If the user is in "no account mode", GUI 2340 does not appear to the user. In some embodiments, help screens regarding privacy and consent issues may also not be displayed in "no account mode".

[0190] In some embodiments, a user may log out of their account. A GUI may be displayed with a warning suggesting limited functionality to the user once the user is logged out. Logging out of their account limits the functionality of the application. In some embodiments, the user may no longer be able to share their information with third parties after logging out of the application. The user may also no longer be able to back up their data on the application server. Once the user is logged out, all new data may only be stored locally on their device. The user may log out of their account from the settings menu. In some embodiments, once the user logs back into their account, all data collected while the user was logged out may be automatically shared with authorized third parties and backed up on the server. In other embodiments, once the user logs back into their account, data may not be automatically shared, and the user may need to choose to share and / or store data that was collected while the user was not logged into their account.

[0191] In some embodiments, when a user logs into their account, they can change the options for sharing data with third parties and connected applications through, for example, a settings menu. If a user chooses to stop sharing their data with a third party or connected application, in some embodiments, a notification may be sent to the third party or connected application notifying them that data is no longer being shared. In other embodiments, no notification may be sent to the third party or connected application notifying them that data is no longer being shared. After disconnecting from sharing data, the user may choose to start sharing data again, and if they choose, they may return to the settings menu and enable the appropriate controls to share their data.

[0192] In some embodiments, if the user does create an account, the user can also delete their account at a later time. If the user deletes their account, they can still operate the monitoring application in "no account mode" as described above. In some embodiments, a GUI with a warning can be displayed, which advises the user of the limitations and effects of deleting their account. The user can also be prompted to enter their password to confirm that the user wants to delete the account. Once the user deletes their account, in some embodiments, all data from the user will be deleted from the server and the device that locally stores the data. The user can optionally create a new account using the same email or username, but the historical data may no longer be associated with the email or username. The user may also no longer be able to share their data with third parties. In some embodiments, after deleting the account, the user is still able to obtain sensor readings and dosage data using a dedicated reader device.

[0193] In another embodiment, once a user deletes their account, the user's data can be saved in an encrypted or secure account that can only be accessed with the user's permission, such as through a code. If the user creates a new account, the user can access the data from their previously deleted account and import the data into their new account.

[0194] Report

[0195] The monitoring application can transmit data (including analyte levels from the SCD 102 and dosing data / logs from the drug delivery device 152) to a reporting application. The reporting application can generate a plurality of reports summarizing and highlighting various aspects of the analyte and drug data and history. The reporting application can be run on a display device or on a separate computing device. In some embodiments, the monitoring application can include instructions that, when executed by one or more processors, generate and display a report including insulin data in the monitoring application.

[0196] FIG. 8A to FIG. 8C An exemplary embodiment of an insulin dosage interface 502 is depicted as part of an analyte monitoring system report GUI 500. According to one aspect of the embodiment, the GUI 500 is a snapshot report covering a predetermined time period 504 (e.g., 14 days) and includes multiple report sections on a single report GUI, including: a sensor usage interface section 506; a glucose trend interface 508, which may include an AGP graph 511; a low glucose event graph 513 and other related glucose metrics (e.g., a glucose management indicator 515); a health information interface 510.

[0197] AGP graph 511 can show the 5th, 25th, 50th (median), 75th and 95th percentiles of glucose readings per hour, which are presented in a "typical" day based on all days in the selected time range. AGP graph 511 can also include two horizontal lines indicating the boundaries of the target range defined in the glucose statistics and target section and the time in range section. Report 500 can also include a section 517 that lists metrics and / or statistics related to average glucose. Metrics section 517 can list average glucose, percentage of time above the target range, percentage of time within the target range, and percentage of time below the target range. Low glucose event graph 513 can include an event graph where the subject's glucose level drops below a low threshold (e.g., 72 mg / dL). The graph can show the relationship between glucose concentration (mg / dL) and time, making it easy to see the time of low event onset during the day. Report 500 can also include a section 519 that lists metrics and / or statistics related to low glucose events. Low glucose event metrics section 519 can list the number of low glucose events and the average duration of low glucose events.

[0198] The sensor usage interface 506 may include a percentage time sensor activity graph 521 and a metrics section 523. The metrics section 523 may include a percentage of the time the sensor has been active and an average scan / view metric (e.g., indicating the average sum of the number of scans and views). The percentage time sensor activity graph 521 may include a graph of the percentage of time the sensor has been active versus the time of day (e.g., from 12am to 12am). The axis of the percentage time sensor activity graph 521 may be aligned with the corresponding axis of one or more other graphs (e.g., average glucose trend graph 511, low glucose events graph 513) so that a user can visually associate data between multiple graphs from two or more portions of the reporting GUI by aligning the common units of the axis (e.g., time of day).

[0199] Health information interface 510 may include carbohydrate section 512, insulin dosing section 502, and comments section 514. Carbohydrate section 512 may include information recorded by the user regarding the user's average daily carbohydrate intake, and may include the average total number of carbohydrates consumed by the user during time period 504.

[0200] Insulin administration section 502 can include the list of the drug dosage (for example, insulin dosage) used during time period 504.This list can include the separate entry of quick-acting insulin 516, long-acting insulin 518 and daily insulin total amount 520.Entry can include the icon of indication insulin type and / or the type of insulin (for example, quick-acting, long-acting, basis etc.), and / or the brand name of insulin and / or the average insulin amount used.When connecting a plurality of insulin pens, the drug dosage part of display 502 can include the different icons for different types of insulin pens, for example, different colors and / or icons.For example, quick-acting pen can have light green icon 516, and long-acting insulin pen can have dark green icon 518.

[0201] In some embodiments, insulin dosage can be manually input by the user and / or determined by dosage calculator, rather than directly transmitted from connected drug delivery device 152. Insulin dosage may have been input into monitoring application or report application. In the case of manual input insulin dosage, report 500 can record the amount of rapid-acting insulin 516 and long-acting insulin 518 delivered, but may not list the brand name of insulin. The dosing units / day of each type of insulin and the average daily total insulin (units / day) can also be displayed in insulin dosage interface 502. For rapid-acting insulin dosage 516, dosage can be listed as the total dosage (units / day) used, but can also be broken down into different parts, which can include meal size, correction amount, user changes and manual input.

[0202] The review interface 514 may include additional information about the user's analyte and medication patterns presented in a narrative format. For example, the review section 514 may include an indication of the trend in the number of tests per day compared to the previous reporting period, fluctuations detected during the reporting period, and the ratio of corrected insulin for the average daily dose.

[0203] The report 500 may also include a list of sources 522 of the information provided. The source may include the name of the glucose monitoring device, and may also include the name of the insulin delivery device (e.g., brand name). If the patient is using multiple insulin delivery devices, the source section 525 may list all of the medication delivery devices, or may include the name of the first connected pen and the number (value) of the additional medical device, but may not include the name of any specific insulin pen.

[0204] FIG. 9A to FIG. 9GDepicted is an exemplary embodiment of another analyte monitoring system report GUI 600 that includes information about the insulin dose administered. According to one aspect of the embodiment, GUI 600 is a weekly summary report for a time period 613 including multiple report sections, wherein each report section represents a different day of the week. The time period can be one or more weeks, for example, 7 days, 14 days (e.g., see FIG. 9B to FIG. 9C ), 21 days, 28 days (for example, see FIG. 9D to FIG. 9G ), 32 days, 36 days, etc. Each report section may include a glucose trend graph 601a to 601n for each day in a time period 613, which may include the user's measured glucose level over a twenty-four hour period, and health information interfaces 606, 608, 610, 612. For each day of the time period 613, the health information interface may include information about the user's average daily glucose 606a to 606bb, carbohydrate intake 608a to 608bb, insulin dose 610a to 610bb, and hypoglycemic ("low") events 612a to 612bb.

[0205] In some embodiments, glucose trend graph 601a to 601bb may include sensor usage marks to indicate that scanning, viewing or both have occurred at a specific time during a twenty-four hour period. Glucose trend graph 601a to 601bb may also include color coding to highlight the part that exceeds the target range in the trend graph. For example, trend graph 601a to 601bb may include the area under the curve being colored as a specific color, or the part of the graph being changed to a specific color, or otherwise highlighting the area of ​​the part outside the target range with a corresponding color. The area under the curve of the part above the target range 603 may be colored, for example, yellow or orange, and the area under the bend of the part below the target range 605 may be colored as, for example, red.

[0206] The "Low" event columns 612a to 612bb can list the number of low events detected when the user's analyte level is below a lower threshold (e.g., glucose is 80 mg / dL, optionally 75 mg / dL). Low events can also be highlighted in the glucose trend graph by shading the area under the curve of the low events with a different color (e.g., red).

[0207] Similarly, the total carbohydrate amount 608a to 608bb of daily intake can be listed in the health information interface 604. These carbohydrate entries can be distinguished from the insulin dosage entry by appearing with different colors (e.g., orange) and different icons (e.g., apple). If there is no value for the amount of carbohydrate available, the total carbohydrate entry 608a to 608bb can be blank, dash or multiple dashes. In addition, the amount of carbohydrates taken in can also be included in the glucose trend graph 602a to 602bb. Similar to insulin dosage, the amount of carbohydrates in different meals or snacks can be recorded when taken in or close to taking in, and the amount can be listed in the orange frame. If insulin is applied (carbohydrate intake) during meals or before and after meals, the amount of insulin may be lower than the amount of carbohydrates taken in on the glucose trend graph.

[0208] Insulin dosage column 610a to 610bb interface can include the total amount of insulin applied for each different type of insulin on the day. The total dose of different insulin types can be distinguished by different colors. For example, the total rapid-acting insulin applied can be represented by a light green frame, and the total long-acting insulin applied can be represented by a dark green frame. If there is no available value, the entry of the amount of insulin applied can be displayed as a dash or multiple dashes. The specific dose of different insulins can also be recorded in glucose trend graphs 601a to 601bb. For example, when or near the application dose, a frame containing the dose may appear in the glucose trend graph. These frames can be color-coded, similar to the total insulin amount, so that the user quickly determines which insulin has been applied. For example, the rapid-acting insulin dose applied can be in a light green frame, and the total long-acting insulin dose applied can be in a dark green frame. The long-acting insulin dose can be displayed or may not be displayed on the glucose trend graph. In addition, when the rapid-acting dose is administered simultaneously or almost simultaneously with the long-acting dose, the long-acting dose can appear below the frame entry of the rapid-acting dose on the glucose trend graph. The insulin brand names for the different types of insulin administered may also be displayed in a legend 630 , which may be located at the bottom of the weekly summary report 600 .

[0209] In some embodiments, the administration information can be manually input by the user, rather than being directly transmitted from the connected drug delivery device 152. The insulin dose may have been input into a monitoring application or a report application. In the case of manually inputting the insulin dose, the report 600 can record the amount of the rapid-acting insulin delivered, but the brand name of the insulin may not be listed in the legend 630, but the legend 630 may include an icon corresponding to the specific type of insulin used. In some embodiments, the administration information can be automatically transmitted from the connected delivery device. The data source 632 may include the name of the device providing the analyte data level and the number of additional merged glucose devices, but may not include the name of any specific insulin pen. The administration units / day of each type of insulin and the average daily total insulin (units / day) may also be displayed in the insulin dose interface 610. If the insulin dose used on the glucose trend graph is close in time, it may be displayed below the carbohydrate entry. In other embodiments, the brand name of insulin may be included in the weekly summary report 600, such as in the legend 630.

[0210] The report may also list the source 632 of the data, including the name of the device providing the analyte data level and the name of the primary medication delivery device. When data from multiple connected insulin pens have been included in the weekly summary report, the source 632 may include the name of the first connected pen and the number (value) of additional medical devices.

[0211] FIG. 10A to FIG. 10C Depicted is an exemplary embodiment of another analyte monitoring system report GUI 700 that includes information about multiple types of insulin administered in a daily log report. According to one aspect of the embodiment, GUI 700 is a daily log report that, for each day of a time period 701, may include glucose trend graphs 702a to 702c, scan or view sections 704a to 704c, carbohydrate rows 706a to 706c, administered insulin dose rows 708a to 708c, annotation rows 710a to 710c, and legend 730. The time period may be one or more weeks, e.g., 7 days, 14 days (e.g., see Fig. 10B ), 21 days, 28 days (for example, see Fig. 10B ), 32 days, 36 days, etc. FIG. 10A to FIG. 10CAn example of the first page or screen of report 700 is shown, and the report contains the graph and information of the first 3 days of this time period. Glucose trend graphs 702a to 702c can include the glucose level of the user in the 24-hour period. In some embodiments, glucose trend graphs 702a to 702c can include sensor use marks to indicate that scanning, viewing or both have occurred at a specific time during the 24-hour period. In some embodiments, the glucose level for scanning or viewing can be listed in scanning or viewing sections 704a to 704c when scanning or viewing. Glucose trend graphs 702a to 702c can also include recorded event marks, such as recorded carbohydrate intake marks and recorded insulin dosage marks, and glucose event marks, such as low glucose event marks. Below glucose trend graphs 702a to 702c, report 700 can include having multiple lines of additional information, including rows corresponding to scanning or viewing 704a to 704c, carbohydrates 706a to 706c, insulin 708a to 708c administered and notes 710a to 710c. In the scan or review rows 704a to 704c, glucose levels of note can be listed in the row at a location corresponding to the time at which the glucose level was recorded. For example, peak glucose levels for episodes above the target range can be recorded and color-coded with a first color (e.g., orange), and low glucose levels for episodes of low glucose can be color-coded with a second color (e.g., red). In the carbohydrate rows 706a to 706c, the amount of carbohydrate can be listed in the row in a location corresponding to the time at which the carbohydrate was recorded.

[0212] For insulin administration rows 708a to 708c, the amount of insulin injected may be displayed in a row below each glucose trend graph 702 for each hourly time block. Each drug delivery device may appear in a separate row. For example, Fig. 10B As seen in , insulin doses from a rapid-acting pen may appear in a first row, while insulin doses from an insulin pen containing long-acting insulin may appear in another row, where the long-acting insulin dose row may appear below the rapid-acting insulin dose row. Rapid-acting insulin doses may appear in a white box with a black outline. User corrections or changes may appear before the dose. The long-acting insulin dose may appear in a dark green box. Data source 754 may include the name of the device providing the analyte data level and the name of the first connected insulin pen, as well as multiple additional combined glucose devices.

[0213] In some embodiments, the insulin dose may be manually entered by the user and / or determined by the dose calculator, rather than being transmitted directly from the connected drug delivery device 152. The insulin dose may have been entered into a monitoring application or a reporting application. In the case of manually entering the insulin dose, the daily log report may record the amount of the rapid-acting insulin and long-acting insulin 618 delivered, but may not list the brand name of the insulin next to its corresponding icon. In some embodiments, the dosing information may be automatically transmitted from the connected delivery device. The data source 754 may include the name of the device providing the analyte data level and the number of additional merged glucose devices, but may not include the name of any specific insulin pen. If the dose data of a specific insulin type on a specific date is entered, only the row of the insulin type can be displayed. If there is no data on a specific date, the row of the insulin type may not appear below the glucose trend graph 702. In addition to the glucose trend graphs 702a to 702c, color-coded icons and the brand name or type of insulin may appear next to the insulin dose row. As with other reporting embodiments, different icons and different colors may be used for rapid-acting and long-acting insulin pens. For example, rapid-acting insulin can be depicted with a light green solid line syringe icon. Long-acting insulin can be depicted with a dark green, wider syringe icon. When there is insulin dosage data for the day, only one line appears for that particular day. If the user switches insulin brands in the connected pen during a specific date, the daily log report 700 can also include notes. Notes can appear when the insulin brand changes, and the notes include the new and old insulin brand names. Then, the new insulin brand name can be listed in the text near the glucose trend graph 702. In other embodiments, the brand name of insulin can be included in the daily log report 700, such as in the legend 730.

[0214] Annotation lines 710a to 710c may also be included in the daily log report 700. An annotation may include added text about an event (e.g., a workout). The text may appear in the line at a location corresponding to the time the annotation was recorded.

[0215] FIG. 11A to FIG. 11D 770. The daily pattern report 770 includes a user's dynamic glucose curve 772, sections 774 reflecting the amount of carbohydrates consumed during different time periods of the day, and sections reflecting the dosages of different types of insulin 778a-778b. The daily pattern report 770 displays the daily glucose profile 772 for the user by day period 771 (e.g., 14 days (see Fig. 11B ) or 28 days (see Fig. 11C)) of the time period of 1 day (i.e., 24 hours) of glucose measurements organized by time. Glucose measurements can be displayed as individual points, or can be averaged as a gradient pattern representing the density of measurements within a specific range. Dynamic glucose curve 772 can include a representation of the target glucose range for the user, and a median value that varies over time represented by an average or median line, and lines representing 10%, 25%, 75% and 90%. Daily pattern report 770 can also have an indication of daily average glucose levels 785. Above dynamic glucose curve 772, row 773 can appear, in which the average glucose level for each time period can be listed. Each time period can be about 2 hours, optionally about 3 hours, optionally about 4 hours. Notable glucose levels (e.g., the highest average glucose level) can be highlighted with different colors to help users easily see which time period has the highest glucose level.

[0216] In addition to the measured glucose levels, the daily pattern report 770 may also include other average daily information, such as carbohydrates 790, rapid-acting insulin 802, and long-acting insulin 804. The section 774 reflecting the amount of carbohydrates consumed at different time periods during the day may include a graph of the average daily amount of carbohydrates 790 ingested and time (x axis) and carbohydrate amount (y axis (grams)), which may include icons (e.g., apples) to mark the amount of carbohydrates consumed at different time periods during the day. The total amount of carbohydrates consumed at a specific time period during the day 794 and the number of meals or snacks consumed during that time period (e.g., in parentheses) may be listed at the top of the graph.

[0217] The section reflecting the dosage of different types of insulin 778a-778b of the daily pattern report 770 can include a row for each type of insulin administered by the connected drug delivery device 152, for example, a top row for rapid-acting insulin 778a and a bottom row for long-acting insulin 778b. For each type of insulin (rapid or fast-acting 802 (including "other insulin") and long-acting 804, an icon representing the type of insulin, the average daily dosage 803, 805, the average dosage for each time period per day, and the number of entries for that time period 810 (in parentheses) can be reported in the insulin rows 778a-778b. The brand name of the insulin can also be optionally listed. As with other embodiments discussed herein, a light green syringe icon can be used to represent an insulin pen containing rapid-acting insulin, and a dark green syringe icon can be used to represent an insulin pen containing long-acting insulin. The data source 812 can include the name of the device providing the analyte data level and the name of the first connected insulin pen, as well as multiple additional connected devices (e.g., additional insulin pens).

[0218] In some embodiments, where only a single insulin pen is connected, only one row 778 of insulin doses may appear, along with a corresponding icon (e.g., a light green syringe icon for a rapid-acting insulin pen) and the brand name or type of insulin delivered. Where only a single insulin pen is connected, the data source 812 may include only the name of the device providing the analyte data level and the name of the connected insulin pen, without any digital indication that an additional device is connected.

[0219] In some embodiments, insulin dosage may have been input into monitoring application or report application.In the case of manual input insulin dosage, daily pattern report 770 can record the amount of the quick-acting insulin and the long-acting insulin delivered, but can not list the brand name of insulin beside its corresponding icon.In some embodiments, administration information can be automatically transmitted from the delivery device connected.Data source 812 can include the title of the equipment providing analyte data level and the quantity of the extra merged glucose equipment, but can not include the name of any specific insulin pen.Also can display the administration unit / day of every kind of insulin and average daily total insulin (unit / day).In other embodiments, the brand name of insulin can be included in daily pattern report 770, for example in the legend.

[0220] The daily pattern report GUI 1700 may also be made available on the display device 120 via a monitoring application, a reporting application, or other applications. Fig.11DAs seen in the daily mode report GUI 1700, the daily mode report GUI 1700 can include the user's dynamic glucose curve 772, the day time period or day 771 displayed in the GUI 1700, the insulin summary section 1778 and the alternative time period 1774a to 1774d to be selected and displayed. With respect to other embodiments and reports, the dynamic glucose curve (ambulatory glucose profile) 772 has been described in detail. The dynamic glucose curve 772 can also indicate the days that glucose data is available in the time period 771. The dynamic glucose curve 772 can also include a syringe above or below the figure to indicate the time of administration. Optionally, a dosage diagram can be drawn along the median line of the dynamic glucose curve to indicate the time of administration. The insulin summary section 1778 can include a graphical representation of the amount of insulin administered during the time period 771. In some embodiments, the figure can be a bar graph of the average number of insulin units administered over time (x axis). The figure can include both rapid-acting insulin doses and basal doses. The insulin summary section can also indicate the days that administration data is available in the time period 771. The x-axis (time) of the graph in the insulin summary section 1778 can be aligned with the x-axis (time) of the dynamic glucose curve 772, wherein the average dose of different meals and basal doses is drawn at the average time of administration during the time period 771. Therefore, users can easily see the correlation between their insulin dose and their glucose curves in the time period associated with different doses. GUI 1700 can also include labels 1774a to 1774b with different time periods, and users can select these time periods to display daily mode reports. For example, time period labels 1774a to 1774d can be 1 day, 7 days, 14 days, 30 days or 90 days.

[0221] Alternatively, if Fig.11DAs seen in the GUI 1720 of 1700, the user can select a time period in a drop-down menu 1775. In this case, the GUI 1700 can include a date range 1775, and the user can scroll forward and backward in time by clicking a forward or backward insertion symbol. In some embodiments, when the user selects 1 day as the time period, a daily graph can be displayed, which shows the glucose and insulin data of the selected single date. For the daily graph, the daily graph can show the glucose curve of the day, rather than the dynamic glucose curve, while also highlighting the user's target range. The glucose distribution graph (glucose profile graph) can also include a syringe icon above or below the figure to indicate the administration time of insulin. Alternatively, a dosage graph can be drawn along the median line of the glucose curve to indicate the administration time. The insulin summary section can display a graphical representation of the insulin dosage in one day (contrary to the average dosage number of multiple day periods). In some embodiments, the figure can be a bar graph of the number of insulin units of time (x axis) and administration. The figure can include both rapid-acting insulin dosage and basal dosage. The x-axis (time) of the graph in the insulin summary section can be aligned with the x-axis (time) of the glucose curve, where the doses of different meals and basal doses are plotted against the time of administration during the day. Thus, the bars in the bar graph can simultaneously align with the syringe icon in the glucose profile graph.

[0222] like Fig.11E As seen in FIG. 18, if the user requests more information by, for example, clicking on the "i" icon, a window 1800 may be displayed that includes an explanation 1806, and a daily pattern report showing the user's glucose and insulin patterns over a period of time. Window 1800 may also include a target range, for example, 70 mg / dL to 180 mg / dL. The user may also be able to select the type of insulin data to be displayed - rapid-acting 1802 or long-acting 1804.

[0223] FIG. 28A to FIG. 28D Describes another exemplary embodiment of an analyte system report GUI 2000, which includes information about multiple types of insulin administered in a daily view report GUI 2000. According to one aspect of the embodiment, for each day of a time period 2002, the daily view report GUI 2000 may include a glucose profile 2010a to 2010g, a time range metric 2012a to 2012g, a list of total rapid-acting insulin 2014a to 2014g administered, a list of total long-acting insulin 2016a to 2016g administered, and a list of total carbohydrates consumed 2016a to 2016g. The time period 2002 may be one or more weeks, for example, 7 days, 14 days, 21 days, 28 days, 32 days, 36 days, etc. FIG. 28A to FIG. 28B An example of the first page or screen of a report 2000 is shown, which contains graphs and information for the first 7 days of the time period. The daily view report GUI 2000 may also list the time 2020 that the sensor was active during the time period, the average number of scans or views per day during the time period 2022, a legend 2024 for the symbols used in the report 2000, and the data sources 2026 used in the report 2000.

[0224] Glucose curve 2010a to 2010g can include the glucose level of the user within 24 hours. In some embodiments, glucose curve 2010a to 2010g can optionally include sensor use mark (e.g., circle) 2066 to indicate that scanning, viewing or both have occurred at a specific time during the 24-hour period. In some embodiments, the glucose level for scanning or viewing can be listed in the scanning or viewing section when scanning or viewing. Each daily curve can represent the midnight to midnight period, wherein the date is displayed in the same frame as the curve. In addition to displaying the date, each curve can also indicate the corresponding date of the week. Each curve can also include the indication of the target glucose range (e.g., the shaded area or line indicating the upper and lower boundaries of the target area) to illustrate which parts of each daily curve are in the target range 2056. The part outside the target range 2056 in the figure can also be color-coded, as a further indication of the reading or analyte level outside the target range 2056. Color coding can correspond to the color used in the time graphic representation of the range described in other reports. For example, the "high" level portion of the graph that is above the target range 2056 (e.g., 181 mg / dL to 250 mg / dL) can be color coded with yellow. The "low" level portion of the graph that is below the target range 2056 (e.g., 54 mg / dL to 69 mg / dL) can be color coded with red. The portion of the graph that is below the "very low" level (e.g., <54 mg / dL) can be color coded with dark red or maroon. The color coding can include coloring the area under the curve (e.g., the area between the curve and the high threshold, low threshold, or very low threshold) a particular color, or changing a portion of the graph to a particular color, or otherwise highlighting the area with a corresponding color.

[0225] Glucose graphs 2010a to 2010g may also optionally include recorded event markers, such as recorded exercise events 2064, recorded carbohydrate intake markers, and recorded insulin dosage markers, as well as glucose event markers, such as low glucose event markers. When recording events, the recorded event markers may be listed above or below the glucose graph.

[0226] like FIG. 28B to FIG. 28EAs seen in FIG. 2000 , in some embodiments, instead of including numbers in the glucose curves 2010a to 2010g, the report 2000 may include multiple rows (with additional information below the glucose curves 2010a to 2010g), including rows corresponding to the carbohydrates consumed 2038a to 2038e, the rapid-acting insulins received 2034a to 2034e, and the long-acting insulins received 2036a to 2036e. In the carbohydrate row 2038, the amount of carbohydrates 2058 may be listed in the row 2038 in the position corresponding to the time when the carbohydrates were recorded. Similarly, in the rapid-acting row 2034, the amount of rapid-acting insulin 2060 administered may be listed under the administration time. In the long-acting insulin row 2036, the amount of long-acting insulin administered 2062 may be listed under the administration time. In some embodiments where the administration data is obtained from a connected pen or a connected pen cap, the report 2000 may include the long-acting insulin row 2036. The color coding used for these entries may be the same as the listings for carbohydrates, rapid-acting insulin, and long-acting insulin in the listings for totals 2018 , totals 2014 , and totals 2016 .

[0227] In some embodiments, report 2000 can also or alternatively comprise the row and the annotation of indication scanning or viewing.In scanning or viewing row, the glucose level worthy of attention can be listed in the row corresponding to the time position of recording glucose level.For example, the peak glucose level of the attack higher than target range 2056 can be recorded, and color coding is performed to it with the first color (for example, orange), and the low glucose level of hypoglycemia attack can be color coded with the second color (for example, red).Alternatively, glucose curve 2010a to 2010g can include the glucose level worthy of attention.

[0228] In some embodiments, Fig.28D 2016c, where an insulin pump is used to administer basal insulin, the report may also or alternatively include an insulin delivery graph 2042c located below or above the glucose curve 2010 that shows when and how much insulin was delivered, instead of the long-acting insulin line 2036 showing discrete doses. The insulin delivery graph 2042c may have an x-axis of time and a y-axis of units / hour. The time axis of the insulin delivery graph 2042c and the glucose curve 2010 may be aligned. When an insulin pump is the source of the basal dose information, a list 2016c of the total amount of long-acting insulin administered may include the name of the pump system and the percentage of time the pump was active. Fig.28D Depicts a day's worth of entries from the Daily View Report 2000.

[0229] In some embodiments, Fig.28EAs seen in FIG. 20, in the case where an insulin pump is used to administer insulin, instead of displaying a discrete dose of long-acting insulin row 2036, the report may also or alternatively include an insulin delivery graph 2044c located below or above the glucose curve 2010, which shows how much insulin is delivered and the delivery mode of the insulin pump. In some embodiments, the insulin graph 2044c may have an x-axis of time and a y-axis of units / hour. The insulin graph 2044c may include a track 2052 of the amount of insulin delivered and a time period when the pump is running under automatic delivery 2046, maximum delivery 2048, or automatic pause 2050, or whether the insulin is manually delivered 2054. When an insulin pump is the source of basal dose information, a list 2016c of the total amount of long-acting insulin administered may include the name of the pump system and the percentage of time the pump is active. Fig.28E Depicts a day's worth of entries from the Daily View Report 2000.

[0230] The time-in-range metrics 2012a - 2012g may be the percentage of time spent within the target range 2056 for the day.

[0231] The list 2014a to 2014g of total rapid-acting insulin administered per day can be determined based on data automatically transmitted from a connected drug delivery device 152 (such as a connected pen, a connected pen cap, or an insulin pump). Alternatively, in some embodiments, the list 2014a to 2014g of total rapid-acting insulin administered per day can be determined based on insulin doses manually recorded by the user.

[0232] The list 2016a to 2016g of the total long-acting insulin administered per day can be determined based on data automatically transmitted from a connected drug delivery device 152 (such as a connected pen, a connected pen cap, or an insulin pump). Alternatively, in some embodiments, the list 2016a to 2016g of the total long-acting insulin administered per day can be determined based on insulin doses manually recorded by the user.

[0233] The list of total carbohydrates consumed 2016a to 2016g can be determined from carbohydrates recorded by the user. Alternatively, the list of total carbohydrates consumed 2016a to 2016g can be determined from recorded meals and snacks, wherein the carbohydrate content of the meals and snacks is estimated by the program.

[0234] FIG. 12A to FIG. 12CAn exemplary embodiment of a meal time pattern report GUI 850 is depicted. The meal time pattern report 850 may include a graphical and numerical representation of glucose level information for specific time periods of the day that may be associated with a meal, i.e., morning (breakfast, e.g., 6am to 10am), midday (lunch, e.g., 10am to 4pm), evening (dinner, e.g., 4pm to 10pm), and nighttime (bedtime, e.g., 10pm to 6am). Vertical lines may be displayed to depict the hours before (pre-meal) 852 and after (post-meal) 854 of the corresponding meal. In addition, these representations may include numerical indications of glucose levels before and after specific meal intake times 858a to 858d and 860a to 860d for each day within the meal time pattern time period 856, as well as average pre-meal 859a to 859d and average post-meal glucose levels 861a to 861d listed on the table for each time period. Additionally, the amount of carbohydrates 864a-864d consumed each day during the meal time pattern period may be reported, as well as the average amount of carbohydrates 865a-865d ingested over the entire period.

[0235] The meal time pattern report 850 may also include the amount of insulin administered. The amount of insulin 862a to 862d administered each day during the meal time pattern time period may be displayed, for example, in column 862, while the average amount of insulin administered during the time period 863a to 863d is displayed in a row above the table. An icon corresponding to the type of insulin administered (e.g., a light green syringe icon for rapid-acting insulin) may also be displayed to indicate the type of insulin administered.

[0236] The data source 874 (including the name of the device providing the analyte data level and the name of the primary medication delivery device) may also be displayed if the medication delivery device 152 is connected to the IMS. For the type of insulin administered, the insulin brand name may also be optionally displayed in a legend 876, which may be located at the bottom of the meal time pattern report 850.

[0237] In some embodiments, the insulin dose can be manually input by the user and / or determined by the dosage calculator, rather than being transmitted directly from the connected drug delivery device 152. The insulin dose may have been input into a monitoring application or a reporting application. In the case of manually inputting the insulin dose, the meal time pattern report 850 can record the amount of the delivered rapid-acting insulin 872, but the brand name may not be listed in the report. In some embodiments, the drug administration information can be automatically transmitted from the connected delivery device. The data source 874 may include the name of the device providing the analyte data level and the number of additional merged glucose devices, but may not include the name of any specific insulin pen. For the insulin type administered, the insulin brand name may not be displayed in the legend 876, which may be located at the bottom of the meal time pattern report 850. Instead, the legend 876 lists insulin as, for example, "rapid-acting", without a brand name. In other embodiments, the brand name of insulin may be included in the meal time pattern report 850, such as in the legend 876.

[0238] The meal time pattern report 850 may also include multiple graphs 868a to 868d of glucose levels for each time period of the day, i.e., morning (breakfast, e.g., 6am to 10am), midday (lunch, e.g., 10am to 4pm), evening (dinner, e.g., 4pm to 10pm), and nighttime (bedtime, e.g., 10pm to 6am). Each graph 868a to 868d may include a vertical line depicting the meal start time, and may span a time range of about 1 hour before the start of the meal to about 3 hours after the start of the meal. The graph may also include data points on the vertical lines indicating multiple glucose levels scanned or recorded at the start of the meal or before the start of the meal, which are listed in columns 858a to 858d. The average glucose level of the multiple glucose levels scanned or recorded at the start of the meal or before the start of the meal, indicated at the top of columns 858a to 858d, may be highlighted in each graph. In addition, Figures 868a to 868d may include data points indicating postprandial (e.g., at least about 2 hours after the start of the meal) glucose levels, which are listed in columns 860a to 860d. The average glucose level of multiple glucose levels scanned or recorded after the meal (e.g., at least about 2 hours after the start of the meal) indicated at the top of columns 860a to 860d may also be highlighted in the figure. Figures 858a to 858d may also highlight the target range before the meal, e.g., about 70 mg / dL to about 130 mg / dL, and the target range after the meal (e.g., about 100 mg / dL to about 180 mg / dL), making it easy to see whether the recorded glucose level is within the target range or outside the target range.

[0239] FIG. 13A to FIG. 13BAn exemplary embodiment of a device details report GUI 900 is depicted. The device details report 900 may include glucose settings 910 for a primary glucose device, insulin settings 930 for a first connected insulin pen, and insulin settings 940 for a second (or additional) connected insulin pen. The glucose settings 910 may include a target range (e.g., 70 mg / dL to 180 mg / dL) and alarm settings for low glucose (e.g., 70 mg / dL), high glucose (e.g., 240 mg / L), and signal loss. The target range may include a low threshold and a high threshold, and may be set from a monitoring application or reader. The glucose settings 910 may also optionally include calculator settings and reminders. The device details report 900 may also include detailed information about a primary glucose device 916 that receives data on analyte levels or indicating analyte levels from an SCD 102, including the name of the device (and any icons associated with the device), the current software version on the device, the current operating system version, and the smartphone model running the relevant application. If SCD 102 is used in conjunction with a reader or meter, device details 916 may include the serial number of the reader or meter.

[0240] The device details report 900 may also include detailed information for any connected drug delivery device 152 (e.g., a connected insulin pen). The connected drug delivery device 152 may be listed under the main glucose device. If more than one drug delivery device is connected, each device may be displayed as its own device. For each connected drug delivery device, the insulin pen settings 930, 940 may include the insulin type, the last scan (e.g., the date and time stamp of the last insulin value), and the pen color. The insulin pen settings 930, 940 may also optionally include calculator settings, notes, and / or reminders. The device details report 900 may also include detailed information 935, 945 about the insulin pen near its corresponding settings. The detailed information 935, 945 may include a colored icon or picture of the insulin pen, the brand name of the insulin pen, or the type of insulin and the serial number.

[0241] Fig.14 An exemplary embodiment of an AGP report GUI 950 is depicted. The AGP report 950 may include a glucose statistics and target section 952, a time-in-range section 954, a user's dynamic glucose curve 956, and a daily glucose curve section 958. The AGP report 950 displays various statistics and graphs for a period of days 960 (e.g., 14 days or 28 days). The source 962 of the information may be listed and may include the name of the primary glucose device (e.g., brand name), the first connected pen, and the number of additional devices.

[0242] The glucose statistics and target or glucose metrics 952 section may include any one or more of the following metrics: number of days for which statistics are reported, active time of the sensor (reported as a percentage), amount of time that the detected analyte level is within various ranges (reported as a percentage), average glucose, glucose management index (GMI), and glucose variability. The amount of time within the various ranges may include the amount of time within the target range (e.g., 70 mg / dL to 180 mg / dL), below a low threshold (e.g., below 70 mg / dL), below a lower threshold (e.g., below 54 mg / dL), above a high threshold (e.g., above 180 mg / dL), and above an even higher threshold (e.g., above 250 mg / dL).

[0243] The time in range section 954 may include a time in range (also referred to as time in range and / or time in target) GUI, wherein each GUI includes a plurality of bars or bar portions, wherein each bar or bar portion indicates the amount of time that the user's analyte level is within a predefined analyte range associated with the bar or bar portion. For example, in some embodiments, the amount of time may be expressed as a percentage of the predefined amount of time. The time in range GUI portion 954 may include a single bar containing up to five bar portions, including (from top to bottom): a first bar portion indicating that the user's glucose range is "very high" or above 250 mg / dL for a predefined amount of time; a second bar portion indicating that the user's glucose range is "high" or between 180 mg / dL and 250 mg / dL for a predefined amount of time; a third bar portion indicating that the user's glucose range is within the "target range" or between 70 mg / dL and 180 mg / dL for a predefined amount of time; a fourth bar portion indicating that the user's glucose range is "low" or between 54 mg / dL and 69 mg / dL for a predefined amount of time; and a fifth bar portion indicating that the user's glucose range is "very low" or less than 54 mg / dL for a predefined amount of time. The time in range GUI 954 may display text adjacent to each bar portion indicating the actual amount of time, e.g., in hours and / or minutes.

[0244] according to Fig.14In one aspect of the embodiment shown in, each bar portion of time in range GUI 954 may include different colors. In some embodiments, the bar portion may be separated with a dotted line or dotted line and / or separated with a digital marker liner to indicate the scope reflected by the adjacent bar portion. In some embodiments, the time in the range reflected by the bar portion may be further expressed as percentage, actual time amount (e.g., 4 hours 19 minutes) or both. In addition, those skilled in the art will recognize that the time percentage associated with each bar portion may vary depending on the user's analyte data. In some embodiments of time in range GUI 954, the target range may be configured by the user. In other embodiments, the target range of time in range GUI 954 may not be modified by the user.

[0245] The AGP report 950 may also include an AGP portion 956 similar to the AGP graph 511. The AGP graph may display the 5th, 25th, 50th (median), 75th, and 95th percentiles of glucose readings per hour, presented in a "typical" day based on all days within the selected time range. The AGP graph may also include two horizontal lines indicating the boundaries of the target range defined in the glucose statistics and target portion 952 and the time within range portion 954. For example, the first line may correspond to the lower limit of the target range (e.g., 70 mg / dL), and the second line may correspond to the upper limit of the target range (e.g., 250 mg / dL). The first line and the second line may also be color-coded and correspond to the same color (e.g., green) as the target range bar portion in the time within range portion 308. The data or portion of the AGP within the corresponding concentration range may also be color-coded and correspond to the same color as the target range bar portion in the time within range portion (308). For example, data points or portions where AGP is within the target range may be colored green, data points or portions where AGP is within the high concentration range may be colored orange, data points and portions where AGP is within the high range may be colored orange, data points or portions where AGP is within the low range may be colored red, and data points or portions where AGP is within the very low range may be colored crimson or maroon. Thus, the AGP graph easily illustrates the amount of time spent within the target range (or the amount of readings within the target range).

[0246] The AGP report 950 may also include a daily glucose curve section 958. The daily glucose curve section 958 displays a plurality of daily curves 958-1 to 958-14, each corresponding to each day of the time period 960. Each daily curve may represent a midnight to midnight period, wherein the date is displayed in the same frame as the curve. In addition to displaying the date, each curve may also indicate the corresponding day of the week. Each curve may also include an indication of a target glucose range (e.g., a shaded area or line indicating the upper and lower boundaries of the target area) to illustrate which portions of each daily curve are within the target range. Portions outside the target range in the graph may also be color-coded as a further indication of a reading or analyte level outside the target range. The color coding may correspond to the color used in the portion of time 954 within the range. For example, a "high" level portion (e.g., 181 mg / dL to 250 mg / dL) above the target range in the graph may be color-coded with yellow. A "low" level portion (e.g., 54 mg / dL to 69 mg / dL) below the target range in the graph may be coded with red. Portions of the graph below a "very low" level (e.g., <54 mg / dL) may be color-coded with a dark red or maroon color. Color coding may include coloring the area under the curve (e.g., the area between the curve and the high threshold, low threshold, or very low threshold) a particular color, or changing a portion of the graph to a particular color, or otherwise highlighting the area with a corresponding color.

[0247] Fig.19 Describe the exemplary embodiment of the comparison report GUI 1020.Comparison report 1020 can include two sections 1022a, 1022b showing the metrics for the first time period 1024a and the second time period 1024b.The metrics for the first time period and the second time period can be displayed side by side, so that different time periods can be easily analyzed and compared.Each section of comparison report 1020 can include glucose metric sections 1026a, 1026b, time sections within range 1028a, 1028b, dynamic glucose curve sections 1030a, 1030b and low glucose event sections 1032a, 1032b.Comparison report 1020 shows various statistics and graphs for two time periods (e.g., 14 days per time period).In some embodiments, a banner can also appear in, for example, a title to notify the viewer whether any glucose threshold level has been adjusted.

[0248] The comparison report GUI 1020 may report the days 1024a, 1024b during which the various metrics were reported, as well as the amount of time (reported as a percentage) 1034a, 1034b that the sensor was active.

[0249] The glucose metrics sections 1026a, 1026b may include, for example, average glucose, glucose management index (GMI), and glucose variability.

[0250] The time-in-range segments 1028a, 1028b may include a time-in-range (also referred to as time-in-range and / or time-in-target) graphical representation, wherein each graphical representation includes a plurality of bars or bar portions, wherein each bar or bar portion indicates the amount of time that the user's analyte level is within a predefined analyte range associated with the bar or bar portion. In some embodiments, for example, the amount of time may be represented as a percentage of the predefined amount of time. The time-in-range graphs 1028a, 1028b may each include a single bar including a plurality of bar portions stacked vertically. In some embodiments, the graph may include five bar portions: a first bar portion indicating the amount of time that the user's glucose range was "very high" or above 250 mg / dL for a predefined amount of time; a second bar portion indicating the amount of time that the user's glucose range was "high" or between 180 mg / dL and 250 mg / dL for a predefined amount of time; a third bar portion indicating the amount of time that the user's glucose range was within the "target range" or between 70 mg / dL and 180 mg / dL for a predefined amount of time; a fourth bar portion indicating the amount of time that the user's glucose range was "low" or between 54 mg / dL and 69 mg / dL for a predefined amount of time; and a fifth bar portion indicating the amount of time that the user's glucose range was "very low" or less than 54 mg / dL for a predefined amount of time. The time-in-range graphs 1028a, 1028b may also optionally display text near each bar portion indicating the actual amount of time, e.g., in hours and / or minutes. In some embodiments, the time in range reflected by the bar portion can be further expressed as a percentage, an actual amount of time (e.g., 4 hours 19 minutes), or both. In addition, those skilled in the art will recognize that the time percentage associated with each bar portion can vary depending on the user's analyte data.

[0251] according to Fig.19In one aspect of the embodiment shown in, each bar portion of time diagram 1028a, 1028b within the range may include different colors. In some embodiments, the bar portion may be separated by dashed or dotted lines and / or separated by digital markers to indicate the range reflected by adjacent bar portions. In some embodiments, the "very high" portion may be colored orange, the "high" portion may be colored yellow, the "target range" may be colored green, the "low" portion may be colored red, and the "very low" portion may be colored crimson or maroon. Other portions of the comparison report 1020 (such as dynamic glucose curve segments 1030a, 1030b and low glucose event segments 1032a, 1032b) may also adopt this coloring scheme. For example, the analyte level shown in the figure of dynamic glucose curve segments 1030a, 1030b and low glucose event segments 1032a, 1032b may be color-coded according to the concentration range where the analyte level is located. For example, in a dynamic glucose curve, an analyte level of 156 mg / dL may be colored green, while in a dynamic glucose curve or low glucose event graph, an analyte level of 48 mg / dL may be colored dark red or maroon. In some embodiments of the time-in-range graphs 1028a, 1028b, the target range may be configured by the user. In other embodiments, the target range of the time-in-range graphs 1028a, 1028b may not be modified by the user.

[0252] Each section of the comparison report 1020 may also include an AGP portion 1030a, 1030b similar to the AGP graph 511 shown in Fig. 8. The AGP graph may display the 5th, 25th, 50th (median), 75th, and 95th percentiles per hour of glucose readings, which are presented in a "typical" day based on all days within the selected time range. The AGP graph may also include two horizontal lines indicating the boundaries of the target range defined in the glucose statistics and target portions 1026a, 1026b and the time-in-range graphs 1028a, 1028b. For example, a first line may correspond to the lower limit of the target range (e.g., 70 mg / dL), and a second line may correspond to the upper limit of the target range (e.g., 250 mg / dL). The first line and the second line may also be color-coded and may correspond to the same color (e.g., green) as the target range bar portion in the time-in-range portion 308. The AGP graph can employ the same color coding as in the time-in-range GUIs 1028a, 1028b, such that glucose levels in the "very high" range (e.g., about 250 mg / dL) can be colored orange, glucose levels in the "high" range (e.g., between 180 mg / dL and 250 mg / dL) can be colored yellow, glucose levels in the "target range" (e.g., between 70 mg / dL and 180 mg / dL) can be colored green, glucose levels in the "low" range (e.g., between 54 mg / dL and 70 mg / dL) can be colored red, and glucose levels in the "very low" range (e.g., below 54 mg / dL) can be colored dark red or maroon. Thus, each AGP graph can easily illustrate the amount of time spent within the target range or the number of readings that fell within the target range for each time period 1024a, 1024b.

[0253] Each section of the comparison report 1020 can also include low glucose event sections 1032a, 1032b. Low glucose event sections 1032a, 1032b can each include an event diagram where the glucose level of the subject drops below a low threshold (e.g., 70 mg / dL) and a very low threshold (e.g., 54 mg / dL). Each figure can also include a line showing a low threshold (e.g., 70 mg / dl) and a very low threshold (e.g., 54 mg / dl). The figure can show the relationship between glucose concentration (mg / dL) and time, so that the time of low event onset during a day is obvious. As previously mentioned, the glucose level graph in the low glucose event segment 1032a, 1032b can adopt the same color coding as in the time-in-range GUI 1028a, 1028b, so that the glucose level between the low threshold and the very low threshold (for example, between 54mg / dl and 70mg / dl) can be colored as red, and the glucose level below the very low threshold (for example, below 54mg / dl) can be colored as crimson or maroon. Color coding can include the area under the curve being colored as a specific color, or the part of the figure is changed to a specific color, or otherwise the region is highlighted with a corresponding color. Low glucose event segments 1032a, 1032b can also list the metric and / or statistics related to low glucose events. In some embodiments, low glucose event metric segments 1032a, 1032b can list the quantity of low glucose events and optionally the average duration of low glucose events.

[0254] FIG. 15A to FIG. 15B An exemplary embodiment of a GUI associated with a patient dashboard 970 is depicted. The dashboard 970 can allow a user to display combined insulin data from different sources (e.g., connected pens and manually entered insulin data). The user can select different columns to include in the patient dashboard display, including average rapid-acting insulin administered per day (units), average long-acting insulin administered per day (units), and average total insulin administered per day (units). Other parameters that may be displayed on the patient dashboard include average glucose (mmol / L), average duration of sensor low glucose events (min), percentage below target, percentage within target, percentage above target, low glucose events, standard deviation (mmol / L), estimated A1c % and estimated A1c mmol / mol.

[0255] FIG. 16A to FIG. 16BDescribe an exemplary embodiment of a GUI for a data source modality with a connected pen 980. In modality 980, users can use the show / hide icon 982 to select the connected pen they want to include in the report. By default, it can be set to display any connected pen with data during the reporting period. In modality 980, each connected pen can appear as its own device. The connected device can appear in order according to the date of the last upload 986 (this date is the date of the last insulin timestamp). The list of devices (insulin pens) can include insulin pen brand name, insulin pen serial number and insulin pen image. The pen image can be located above the brand name. Modality 980 can also display estimated device time 988. If unknown, the estimated device time 988 can be blank, or the same as the device time used for uploading when uploading. The days of insulin data captured in the last 90 days after the report end date 990 can be displayed with different colors (e.g., green) to distinguish with glucose-related data. Through this GUI, HCP or other users can determine which data sources are included in any report described in this article.

[0256] FIG. 17A to FIG. 17B Depicted is an exemplary alert 1002 for reporting information about a connected pen, e.g., a toast alert. Alert 1002 may be displayed as an unobtrusive, non-pop-up box for a period of time in a portion of the screen (e.g., the lower right corner). If the report includes insulin pen data, alert 1002 may appear for about 1 minute, or until the user dismisses it. Alert 1002 may display the number of total sources 1004 (including both glucose and insulin sources) and the number of connected pens 1006. If there is only a combined glucose device and no connected insulin delivery device, alert 1002 may not be displayed. Alert 1002 may indicate that data from some devices may not be included in the report. The report may only include insulin data for the connected pen.

[0257] FIG. 24A to FIG. 24CDescribe the exemplary embodiment of insulin summary report GUI 1840.Insulin summary report GUI 1840 can include labels 1842a to 1842d with different time periods, and users can choose to display daily mode reports.For example, time period labels 1842a to 1842d can be 1 day, 7 days, 14 days, 30 days or 90 days.GUI 1840 can also include the graphical representation of the date range 1844 and total daily dose 1848 currently being displayed, and the legend 1846 for graphical representation 1848.Graphical representation 1848 can be a bar graph with time on the x axis and total units of medication on the y axis.Graphical representation can include quick-acting and long-acting doses.If the selected time period is 14 days 1842b, the unit of the x axis can be a single day, wherein a bar graph is provided every day to show the total amount of quick-acting and quick-acting insulin used on that day. In some embodiments, the user can select an entry for a day by clicking on the entry and a window with detailed information for that day (eg, the total number of units of rapid-acting and fast-acting insulin administered that day).

[0258] In some embodiments, the user can access the daily insulin report GUI 1860 by clicking on the detailed information window for the day or selecting Daily Insulin Report through the menu. Fig. 24B 1842a, and can display the date 1854 of the data displayed in the graphical representation 1858. The representation 1858 can be a bar graph with time on the x-axis and total units administered on the y-axis, with each dose plotted when administered. The graphical representation can include both quick-acting and long-acting doses. In the legend 1856, below each quick-acting and long-acting symbol or color, the GUI 1850 can list the total amount of each insulin injected on the date 1854.

[0259] Fig.24C An exemplary embodiment of an insulin usage report GUI 1870 is shown, which summarizes the insulin usage of a selected time period. For example, the time period labels 1842a to 1842d can be 1 day, 7 days, 14 days, 30 days or 90 days. The GUI 1870 can display a date range 1872 of insulin usage being displayed. For the selected date range 1872, when the selected date range exceeds one day, the GUI 1870 can also display an average daily total dose 1874 of use, an average daily quick-acting total dose 1876 of use, and an average daily long-acting total dose 1878 of use.

[0260] 18A to 18DAn exemplary embodiment of a GUI for a comparative profile report is depicted. By utilizing dosing data from a connected drug delivery device and glucose data from a continuous glucose monitor as input, in many embodiments, a GUI or report can include multiple glucose curves over a selected time period. FIG. 18A to FIG. 18B As seen in FIG. 1 , in some embodiments, a GUI or report may include two, optionally two or more, optionally three, optionally three or more versions of glucose curves 1010 , 1012 , 1014 over a selected time period.

[0261] In some embodiments, glucose curves 1010, 1012, 1014 can each be a dynamic glucose curve (AGP) graph or a portion of an AGP. Fig.14 As described, the AGP can display the 5th percentile, 2nd percentile 5, 50th (median) percentile, 75th percentile and 95th percentile of glucose readings per hour, which are presented in a "typical" 24 hours based on all days in the selected time range. Alternatively, the AGP can display other percentiles, such as the 10th percentile, 25th percentile, 50th (median) percentile, 75th percentile and 90th percentile glucose readings per hour in a "typical" day 24 hours based on all days in the selected time range. The AGP diagram can also include two horizontal lines indicating the boundaries of the target range. For example, the first line can correspond to the lower limit of the target range (for example, 70mg / dL), and the second line can correspond to the upper limit of the target range (for example, 180mg / dL). The first line and the second line can also be color-coded. These colors can correspond to the same colors used in other reports described herein, for example, the same color (for example, green) as the target range bar part in the time-in-range portion 308. Therefore, the AGP graph easily illustrates the amount of time spent in the target range (or the amount of readings in the target range). Other exemplary AGP graphs can be found in, for example, U.S. Publication No. 2018 / 0235524, U.S. Publication No. 2014 / 0188400, U.S. Publication No. 2014 / 0350369, and U.S. Publication No. 2018 / 0226150, all of which are expressly incorporated herein by reference in their entirety for all purposes.

[0262] In other embodiments, glucose curve can be drawn as multiple daily tracks in a single figure or graph. In some embodiments, except being drawn as multiple daily tracks in the same figure or graph, glucose curve can also be converted to AGP. In some embodiments, multiple figures can be the representation of any type of glucose data, including modal day superposition or time series graph. These figures can also present data, or based on other data based on time data from other analyte data based on time or associated with the patient, such as insulin administration event or insulin delivery data or meal event data. Although exemplary figures are described based on glucose data, any patient data can also be represented by these exemplary formats.

[0263] The GUI or report may include a time filter that allows the user to define a time period to analyze and display in the plurality of glucose curves 1010, 1012, 1014. The time period may be the past 7 days, optionally the past two weeks, optionally the past month, optionally the past two months, optionally the past three months, optionally the past 6 months, optionally the past 9 months, optionally the past year.

[0264] The first curve 1010 of the plurality of glucose curves may display all glucose level measurements for a selected time period. Fig.18C The first curve 1010 may represent a complete set of glucose level measurements, which may include measurements taken after administration of a glucose level altering medication and after a dose of the glucose level altering medication is missed, or after no dosage information is received by the program or application.

[0265] A second curve 1012 of the plurality of glucose curves may display only specific data for a selected time period associated with the administered glucose-lowering drug. Fig.18D. Specific data may only include glucose level measurements within a period of time or associated with the administration of a glucose level-changing drug. Specific data associated with the administration of a glucose level-changing drug may include glucose data or glucose level measurements collected in a window defined by a fixed time. If the dosage of the glucose level-changing drug is associated with a specific window, glucose data from the window may be included. Even if the window does not appear completely or immediately after the dosage is administered, the window may still be associated with the dosage. In some embodiments, the window may be a fixed time of the day. For example, only when a rapid-acting insulin dose is administered within a fixed time window (e.g., from about 7am to about 12pm), the glucose level of the fixed time window may be included. The length of the fixed time window may be related to the therapeutic window of the type of drug administered. For example, a basal or long-acting insulin dose may have a fixed time window of 24 hours, and a rapid-acting insulin may have a fixed time window of 5 hours. In other embodiments, the window may be a variable time of the day, wherein the first time point in the variable time window is the drug dose timestamp or the most recent glucose value after the recorded dose time, and the variable time window extends to the therapeutic window of the given drug dose. For example, for rapid-acting insulin, the treatment window can be about 5 hours, and for long-acting insulin, the treatment window can be about 24 hours. Administration of a glucose level-altering drug can come from a connected drug delivery device. In other embodiments, the drug delivery device is not connected, and the user can record the dose. The drug administration record can be provided by a connected drug delivery device, or by other means such as manually entering a drug administration event. The specific data for the second glucose curve 1012 may not include glucose level measurements during the time window after the missed administration of the drug, or measurements during the time window associated with the drug administration. Portions or fragments of glucose level measurements after the missed administration of the dose (e.g., glucose level measurements within the time window after the missed administration of the drug, or measurements from a window unrelated to the drug administration) can be excluded from a data set including all glucose level measurements for a selected time period, and the remaining glucose level measurements can be used to generate a second one of the multiple glucose curves 1012. Therefore, when the user remembers to administer the drug, the second one of the multiple glucose curves 1012 can reflect the user's blood sugar level. As will be Fig.18D and Fig.18C When compared, the insulin administration curve in the AGP diagram ( Fig.18D ) is much smaller than the data distribution and variability of the curve in AGP that contains all the data (including the data after drug leakage).

[0266] The third curve 1014 in multiple glucose curves can be when, for example, the user or caregiver does not apply the glucose level change medicine, and only specific data is displayed in the selected time period.Specific data can be displayed in the third of multiple glucose curves 1014, and can only include the glucose level measurement performed during the time window after the missed administration of the medicine.The third curve in multiple glucose curves 1014 can contain data excluded from the complete data set to generate the second of multiple glucose curves.After excluding the missed administration of the dose, the length of the part or fragment of the glucose level measurement may depend on the type and characteristics of the glucose level change medicine.Compared with the second curve and the first curve, the measured glucose level displayed in the third curve 1014 may have a higher glucose level measurement value (e.g., a higher median) and / or a higher variability because there is no medicine in the user's body to help control the glucose level.Therefore, the glucose level associated with the missed administration of the dose may cause high glucose.In addition, when all glucose data are summarized and plotted together, the high glucose level caused by the missed administration of the dose may mask the low glucose event after the administration of the dose. Glucose curves (e.g., 1012) that only display data for the time window after the glucose-lowering drug dose administration more directly highlight the impact of these drugs on blood glucose, thereby helping trained healthcare professionals to potentially titrate the current dosage regimen. Curves (e.g., 1014) that highlight the glucose levels of missed doses can more directly highlight the impact of poor dosage consistency on subject blood glucose.

[0267] Thus, the first curve 1010 showing glucose levels without data removed and the third curve 1014 showing glucose levels measured after a missed dose may show higher glucose level measurements (e.g., a higher median) and / or higher variability compared to the second curve 1012 showing glucose levels measured after administration of a glucose-lowering drug.

[0268] In some embodiments, multiple glucose curves can be displayed side by side (e.g., as Fig.18A , three plots on the same line) or one above the other (e.g. Fig.18B , there are three graphs in the same column), which can enable the HCP to easily and quickly identify differences between traces. In some embodiments, a transparent overlay of one glucose curve on top of the other curves can be displayed to form a single graph. In other embodiments, problematic areas can be highlighted in the glucose curve to demonstrate poor consistency or how the current dosage regimen affects the glucose results. Multiple curves can be presented in any order or spatial arrangement.

[0269] The connected drug delivery device data may also include a dose timestamp. If the connected drug delivery device data does not provide a dose to the program that creates the glucose curve, the program may assume that the user has not applied a regularly scheduled dose, i.e., a missed dose. In the case of a missed dose, a predefined portion or segment glucose data may be removed from a data set containing all glucose level measurements (which may be used to create the first glucose curve 1010), leaving only glucose data that may be associated with the administered drug dose (which may be used to create the second glucose curve 1012). Then, the excluded portion or segment may be used to create the third glucose curve 1014.

[0270] The length of each excluded glucose data part or fragment (or the time window for excluding data) may depend on the pharmacokinetic and pharmacodynamic characteristics of the user's drug. For example, if a person injects basal insulin once a day on Monday, but forgets to inject on Tuesday, the data of the connected drug delivery device may show the dosage timestamp of Monday, but will not show Tuesday. Therefore, the glucose data from Monday can be included in the generation of the second glucose curve 1012, but the glucose data from Tuesday may not be included in the data displayed in the second glucose curve. However, the data on Tuesday can be used to generate the third glucose curve 1014. In this example, the glucose data of one day can be excluded because the pharmacodynamic hypoglycemic action time of long-acting basal insulin is about 24 hours. If the meal time rapid-acting insulin dose is omitted, a smaller part or fragment of glucose data can be excluded from the generation of the second glucose curve and used to generate the third glucose curve. This is because rapid-acting insulin has a pharmacodynamic hypoglycemic action time of about 6 hours.

[0271] In some embodiments, the plurality of graphs may include at least 2 graphs, optionally at least 3 graphs, optionally at least 4 graphs, optionally at least 5 graphs, optionally at least 6 graphs, optionally at least 7 graphs, optionally at least 8 graphs. Each of the plurality of graphs may display a different data set. In some embodiments, in the case where a person's treatment regimen includes a basal insulin dose and a bolus dose, 5 graphs may be generated and / or displayed. The first graph may be a display or presentation of all glucose measurements from a time period, the second graph may include glucose measurements taken during a time window after or associated with the administration of a basal insulin dose, the third graph may include glucose measurements taken during a time window after or associated with the missed administration of a basal insulin dose, the fourth graph may include glucose measurements taken during a time window after or associated with the administration of a single insulin dose, and the fifth graph may include glucose measurements taken during a time window after or associated with the missed administration of a single insulin dose.

[0272] Glucose level changes medicine and can be hypoglycemic drug or glucose-raising drug.Embodiment described herein relates to hypoglycemic drug, such as insulin, but this framework can be extended to glucose-raising drug, such as glucagon.Glucose level reduces medicine and can be a kind of insulin.The type of insulin includes rapid-acting insulin, short-acting insulin, intermediate-acting insulin (for example, NPH insulin), mixed insulin (for example, premixed insulin), long-acting insulin and ultra-long-acting insulin.Although the example given here is insulin administration, this method can be extended to any glucose change medicine with known hypoglycemic time sent from the drug delivery device connected.These can include but not limited to SGLT2 inhibitor, GLP1 receptor agonist, biguanide drug (for example, metformin), alpha-glucosidase inhibitor, thiazolidinedione, DPP4 inhibitor and combination thereof.

[0273] The length or time window from which the portion or segment of data may be excluded may be about 1 day, optionally between about 20 hours and about 28 hours, optionally between about 22 hours and about 40 hours, optionally between about 20 hours and about 38 hours, optionally between about 20 hours and about 36 hours after a missed administration of a once-daily, long-acting or basal insulin dose.

[0274] After leaking the administration of the quick-acting insulin dosage, the length or time window of the part or segment that can exclude data can be about 2 hours of using hypoglycemic drugs, optionally about 2.5 hours, optionally about 3 hours, optionally about 3.5 hours, optionally about 4 hours, optionally about 4.5 hours, optionally about 5.0 hours, optionally about 5.5 hours, optionally about 6.0 hours, optionally about 6.5 hours, optionally about 7.0 hours, optionally about 2.0 hours and about 7.0 hours between, optionally about 3.0 hours and about 7.0 hours between, optionally about 4.0 hours and about 7.0 hours between. In some embodiments, the length or time window of the part or segment that can exclude data therefrom can be defined or determined by medicine (such as the insulin action time by postprandial insulin). In some embodiments, the system can preset or estimate the length or time window of the part or segment that can exclude data. In other embodiments, the length or time window of the part or segment that can exclude data can be manually input.

[0275] The length or time window from which the portion or segment of data may be excluded may be about 12 hours, optionally between about 8 hours and about 16 hours, optionally between about 10 hours and about 14 hours after a missed administration of an intermediate-acting insulin dose.

[0276] The length or time window from which the portion or segment of data may be excluded may be between about 36 hours and about 42 hours, optionally between about 32 hours and about 44 hours, after a missed administration of a dose of Ultra Long Acting insulin.

[0277] In some embodiments, the user can use filtering to customize the GUI or report to display different data sets. This data can be used to illustrate different types of non-compliance. Filtering can include selecting to display specific data in a selected time period when applying a recommended dose of glucose level-changing medicine, applying an insufficient dose of glucose level-changing medicine, and applying an excessive dose of glucose level-changing medicine. When the drug dosage of the glucose level-changing medicine is insufficient (i.e., the amount of the drug used to change the glucose level is less than the recommended amount), a specific data chart in a selected time period, and / or when the drug dosage of the glucose level-changing medicine is too large (i.e., the amount of the drug used to change the glucose level exceeds the recommended amount (compared with displaying a specific data chart in a selected time period when the recommended amount of the glucose level-changing medicine is applied)) displaying a specific data chart in a selected time period can help HCPs convince patients to follow the recommended dosing regimen instead of changing their dosage.

[0278] In some embodiments, filtering can also include selecting to display specific data within a selected time period when a postprandial dose is administered (i.e., a dose administered within a time period after the start of a meal). In some embodiments, filtering can also include selecting to display specific data within a selected time period when an additional dietary dose is administered (i.e., an additional dose is administered during a meal). A graph of specific data within a selected time period when a glucose level-altering drug is administered within a time period after the start of a meal, and / or a graph of specific data within a selected time period when an additional dose of a glucose level-altering drug is administered during a meal, can help the HCP reduce the patient's fear of hypoglycemic episodes.

[0279] In addition to other methods described herein, if a dose is administered outside a preset time period, non-compliance can be determined. For example, if a dose is omitted or a dose is administered outside the time window of the prescribed administration time, the basic dose can be determined to be non-compliant. In some embodiments, the time window can be about 30 minutes, optionally about 1 hour, optionally about 90 minutes after the prescribed administration time. For bolus doses, each meal may have an associated time window. For example, the associated time window for breakfast can be about 6am to about 11am, the associated time window for lunch can be about 11am to about 4pm, and the associated time window for dinner can be about 4pm to about 10pm. The time period associated with overnight stays can be 10pm to about 6am. If the recommended dose is given within the associated time window, it can be determined that the dose is correct. If no administration is performed within the associated time window, it can be determined that the dose is omitted. If an additional dose exceeding a single dose is administered within the associated time period, the dose can be determined as an additional dose. If the dose administered within the time period is different from the recommended dose, the dose can be determined to be non-adherent. In addition, omitted administration and additional doses may also be determined to be non-adherent.

[0280] The meal can be identified or recorded by the subject, and the meal start time can be determined from manual input. Optionally, the meal start time can be estimated by a variety of methods. Exemplary methods are described in U.S. Application Serial No. 16 / 944,736 and U.S. Application Serial No. 17 / 591,229; see also Harvey, RA et al., "Design of the Glucose Rate Increase Detector-A Meal Detection Module for the Health Monitoring System", Journal of Diabetes Science and Technology, March 2014; 8 (2): 307-320, which is expressly incorporated herein by reference in its entirety for all purposes. If it is determined that a dose is administered within a time period after the meal start time (e.g., about 30 minutes, optionally about 45 minutes, optionally about 60 minutes, optionally about 90 minutes after the estimated meal start), a late dose can be determined. In other embodiments, if the glucose level from the CGM is >70 mg / dl and there is a >70 mg / dl increase within two hours, it can be determined that a meal has occurred. In this case, a postprandial bolus dose can be defined when the glucose level from the CGM increases by >50 mg / dl from the baseline before insulin administration. A missed meal bolus dose can be defined when no insulin dose is administered within two hours before the glucose level begins to rise. In some embodiments, a missed meal dose can be defined by an increase of 80 mg / dl glucose in ≤2 hours, rather than an insulin dose within 1 hour.

[0281] In some embodiments, GUI or report can also include at least some analyte metrics associated with each curve of multiple glucose curves.At least some analyte metrics can include but are not limited to the average or median analyte level of the time period, standard deviation (SD), CV ([(glucose SD) / (average glucose)] X 100), time display within the range of the time period, GMI index of the time period, high and / or low offset times or its duration is respectively lower than the count of high threshold and / or low threshold, very high and / or very low offset times or its duration is respectively lower than the count of very high threshold and (or) very low threshold, multiple dosage indicators corresponding to the administered drug dose, as described in other reports and embodiments in this specification.In some embodiments, the pattern analysis of glucose curve can be based on various inclusions or exclusions.For example, it can be determined for the window associated with drug administration "low" mode, but not for the window unrelated to drug delivery.Dosage guidance or delivery can be based on these modes determined only from the window associated with drug administration.In some embodiments, it can be recommended based on the determined or detected pattern type. Further details of pattern analysis are described in WO2021 / 026004, which is expressly incorporated herein by reference in its entirety for all purposes.

[0282] The methods described herein are not limited to metrics or graphs to be displayed, but may also be used for processes such as automatic insulin (or other drug) delivery processes, insulin (or other drug) dosage guidance systems, and treatment guidance systems. In some embodiments, data used as input or feedback in these systems may include or exclude different glucose (or analyte) readings if associated with a missed drug dose as described herein. For example, a treatment guidance system may provide treatment change recommendations based on glucose data that excludes glucose data associated with a missed drug dose. In other embodiments, an automatic insulin delivery system may utilize an adaptive model; adaptive processing may be based on glucose data, excluding glucose data for a missed drug dose.

[0283] In other embodiments, multiple graphs may be presented in a comparative curve report. By utilizing, for example, dosing data from a connected drug delivery device and analyte data from a continuous analyte monitor as input, in many embodiments, a GUI or report may include multiple analyte curves for a selected time period. FIG. 18A to FIG. 18BAs seen in , in some embodiments, the GUI or report can include two, optionally two or more, optionally three, optionally four, optionally five, optionally six, optionally six or more versions of the analyte curve in a selected time period. The analyte can be, but is not limited to, acetylcholine, amylase, bilirubin, cholesterol, chorionic gonadotropin, glycosylated hemoglobin (HbA1c), creatine kinase (e.g., CK-MB), creatine, creatinine, DNA, fructosamine, glucose, glucose derivatives, glutamine, growth hormone, hormone, ketone, ketone body, lactate, peroxide, prostate specific antigen, prothrombin, RNA, thyroid stimulating hormone and troponin. The analyte curve can be any different type of graph described with respect to other embodiments, such as a glucose curve.

[0284] In some embodiments, a plurality of figures may include at least 2 figures, optionally at least 3 figures, optionally at least 4 figures, optionally at least 5 figures, optionally at least 6 figures, optionally at least 7 figures, optionally at least 8 figures. Each of the multiple figures may display different data sets. In some embodiments, when a person applies multiple drugs at one time, the figure may display or present all data in a time period, and two figures may be displayed for each drug applied. For each drug, a first figure may include an analyte measurement performed during a time window after drug administration or in a time window associated with drug administration, and a second figure may include an analyte measurement performed in a time window after drug administration or in a time window associated with drug administration. Therefore, for a person applying n kinds of drugs, a plurality of figures including 2n+1 figures may be presented. As explained above with respect to other embodiments, the time window after drug administration or the time window associated with drug administration may be determined by the duration of action of the given drug.

[0285] Check whether the drug is administered

[0286] It is easy to determine whether the medication was delivered to the patient using a connected medication delivery device. For unconnected medication delivery devices (such as syringes), the system can use another method to determine whether the medication was delivered. The system can provide a UI that the patient can log in each time they take the medication. In addition, the system can include a predefined daily time window when the patient typically administers the medication, and if a medication log is not made within this time window, the system prompts the patient to confirm whether they have administered the medication. For oral medications, a connected medicine box or similar device can be used to determine whether the medication has been administered. The system can provide a combination of a connection device and a UI device, wherein, if the connection device does not indicate that the medication has been administered, the system can prompt the patient to confirm that they have not (or have) administered the medication.

[0287] When the drug administration time is later than a typical or prescribed daily time window, the glucose data associated with that time can be excluded. Similarly, the glucose data associated with the later time of the day for the administration of the dose can also be excluded. The glucose data associated with these day time periods can be included in some form of data analysis; for example, to show the impact of late administration of the dose on the glucose metric. In this case, the glucose during the day time period associated with the late administration of the dose can be included only in the metric calculation and can be compared with the metric calculated using the glucose data from the day time period only when the dose is administered on time.

[0288] Various aspects of the subject matter are set forth below to review and / or supplement the embodiments described so far, with emphasis on the interrelationship and interchangeability of the following embodiments. In other words, it is emphasized that each feature of an embodiment can be combined with each other feature unless otherwise explicitly stated or logically implied. The embodiments described herein are reiterated and expanded in the following paragraphs without explicit reference to the drawings.

[0289] In many embodiments, an analyte monitoring system includes: a reader device including: a display; wireless communication circuitry configured to receive first type data from an on-body unit including an analyte sensor and to receive second type data from a drug delivery device, wherein the first type data includes data indicating an analyte level of a subject and wherein the second type data includes drug delivery device identification data and dosage data; and one or more processors coupled to a memory, the memory storing instructions that, when executed by the one or more processors, cause the one or more processors to: store the first type data and the second type data in the memory; receive an indication that a user is logging into a remote server, and in response, send the first type data and the second type data to the remote server; and receive an indication that a user is logging out of the remote server, and in response, stop sending the first type data and the second type data to the remote server.

[0290] In some embodiments, the analyte monitoring system further comprises a remote server, the remote server comprising: one or more processors of the remote server, a memory coupled to the remote server, the memory storing instructions, which instructions, when executed by the one or more processors, cause the one or more processors to: detect an indication that a user has logged in from the remote server, and in response, share the first type of data and the second type of data with an authorized third party or application; and detect an indication that a user has logged out from the remote server, and in response, stop sharing the first type of data and the second type of data with the authorized third party or application. In some embodiments, the analyte monitoring system further comprises a remote server, the remote server comprising: one or more processors of the remote server, a memory coupled to the remote server, the memory storing instructions, which instructions, when executed by the one or more processors, cause the one or more processors to: detect an indication that a user has logged in to the remote server, and in response, share the first type of data and the second type of data with an authorized third party or application; and detect an indication that a user has logged out from the remote server, and in response, stop sharing the first type of data and the second type of data with the authorized third party or application. In some embodiments, the memory of the remote server stores instructions that, when executed by one or more processors, cause the one or more processors to automatically share the first type of data and the second type of data with an authorized third party or application. In some embodiments, the memory of the remote server also stores instructions that cause the one or more processors of the remote server to share the first type of data and the second type of data with an authorized third party or application after the user authorizes the sharing of the first type of data and the second type of data, or in response to the user's authorization.

[0291] In some embodiments, the memory of the reader device also stores instructions that cause one or more processors of the reader device to: receive an indication that a user has logged back in after logging out for a first time period, and in response, send first type data and second type data stored during the first time period to a remote server; and wherein the memory of the remote server also stores instructions that cause one or more processors of the remote server to: detect an indication that a user has logged back in after logging out for a first time period and the first type data and second type data stored during the first time period, and in response, share the first type data and second type data stored during the first time period with an authorized third party or application.

[0292] In some embodiments, the memory of the remote server further stores instructions that cause one or more processors of the remote server to automatically share the first type of data and the second type of data with an authorized third party or application.

[0293] In some embodiments, the memory of the remote server also stores instructions that cause one or more processors of the remote server to: share the first type of data and the second type of data stored during the first time period with an authorized third party or application after the user authorizes sharing of the first type of data and the second type of data stored during the first time period.

[0294] In some embodiments, the memory of the reader device also stores instructions that cause one or more processors of the reader device to: receive an indication from a remote server that a user has deleted an account associated with the user, and in response, delete the first type of data and the second type of data stored in the memory of the reader device.

[0295] In some embodiments, the memory of the remote server further stores instructions that cause one or more processors of the remote server to: detect an indication by a user to delete an account associated with the user, and in response, delete the first type of data and the second type of data stored on the remote server.

[0296] In some embodiments, the memory of the reader device also stores instructions that cause one or more processors of the reader device to: in response to receiving an indication from a user to delete an account associated with the user, display a graphical user interface to prompt the user to confirm deletion before deleting the first type of data and the second type of data.

[0297] In some implementations, the GUI prompting the user to confirm the deletion includes a request to enter the user's password.

[0298] In some embodiments, the memory of the remote server also stores instructions that cause one or more processors of the remote server to: in response to receiving an indication from a user to delete an account associated with the user, store the first type of data and the second type of data in a secure compartment before deleting the first type of data and the second type of data stored in the memory.

[0299] In some embodiments, the secure compartment requires a password or verification code to access.

[0300] In some embodiments, the analyte sensor is a glucose sensor. In some embodiments, the analyte sensor is a ketone sensor. In some embodiments, the analyte sensor is a lactate sensor.

[0301] In many embodiments, an analyte monitoring system includes: a reader device including: a display; wireless communication circuitry configured to receive a first type of data from an on-body unit including an analyte sensor and to receive a second type of data from a drug delivery device, wherein the first type of data includes data indicating an analyte level of a subject, and wherein the second type of data includes error data associated with the drug delivery device; and one or more processors coupled to a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to: display information associated with the data indicating an analyte level of the subject; and display a message based on the received error data.

[0302] In some implementations, the message is displayed in a modal window.

[0303] In some implementations, the message is displayed in a banner.

[0304] In some embodiments, the error data includes data indicating a number of failed scans of a drug delivery device. In some embodiments, if the number of failed scans exceeds a threshold, a message is displayed. In some embodiments, the message includes prompts related to scanning the drug delivery device. In some embodiments, the message includes an animation depicting how to scan a drug delivery device.

[0305] In many embodiments, a method for managing diabetes includes the steps of receiving a first type of data comprising data indicating an analyte level of a subject and a second type of data comprising error data associated with a drug delivery device; displaying information associated with the data indicating the analyte level of the subject; and displaying a message based on the received error data.

[0306] In some embodiments, the error data includes data indicating a number of failed scans of a drug delivery device. In some embodiments, if the number of failed scans is above a threshold, a message is displayed. In some embodiments, the message includes helpful tips related to scanning a drug delivery device. In some embodiments, the message includes an animation depicting how to scan a drug delivery device.

[0307] In many embodiments, an analyte monitoring system includes: a reader device including: a display; wireless communication circuitry configured to receive a first type of data from an on-body unit including an analyte sensor and to receive a second type of data from a drug delivery device, wherein the first type of data includes data indicating an analyte level of a subject and wherein the second type of data includes drug administration data; and one or more processors coupled to a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to: determine whether the second type of data received from the drug delivery device satisfies a minimum administration data reporting condition for inclusion in a report, wherein the report includes metrics based on the first type of data and administration information based on the second type of data; generate a report if it is determined that the received second type of data is sufficient; and display a message about the report.

[0308] In some embodiments, the minimum dosing data reporting conditions include a sufficient amount of the second type of data to generate a weekly report.

[0309] In some embodiments, the minimum dosing data reporting conditions include a sufficient amount of the second type of data to generate a daily report.

[0310] In some embodiments, if the received second type of data includes at least 1 day of medication data, it is determined that the received second type of data meets the minimum medication data reporting condition.

[0311] In some embodiments, if the received second type of data includes at least 3 days of medication data, it is determined that the received second type of data meets the minimum medication data reporting condition.

[0312] In some embodiments, if the received second type of data includes at least 1 week of medication data, it is determined that the received second type of data meets the minimum medication data reporting condition.

[0313] In some implementations, the message states that a report is available.

[0314] In some implementations, the message includes a link to the report.

[0315] In some embodiments, the analyte sensor is a glucose sensor. In some embodiments, the analyte sensor is a ketone sensor. In some embodiments, the analyte sensor is a lactate sensor.

[0316] In many embodiments, a method for managing diabetes comprises the steps of: receiving first type data including data indicating an analyte level of a subject and second type data including drug administration data; determining whether the second type data received from a drug delivery device meets minimum drug administration data reporting conditions for inclusion in a report, wherein the report includes metrics based on the first type data and drug administration information based on the second type data; generating a report if the received second type data meets the minimum reporting conditions for inclusion in the report; and displaying a message about the report.

[0317] In some embodiments, the method further comprises the step of determining whether the received first type of data satisfies a minimum analyte data reporting condition for inclusion in the report. In some embodiments, the minimum dosing data reporting condition comprises a sufficient amount of the second type of data to generate a weekly report. In some embodiments, the minimum dosing data reporting condition comprises a sufficient amount of the second type of data to generate a daily report.

[0318] In some embodiments, if the received second type of data includes at least 1 day of medication data, the received second type of data satisfies the minimum medication data reporting condition.

[0319] In some embodiments, if the received second type of data includes at least 3 days of medication data, the received second type of data satisfies the minimum medication data reporting condition.

[0320] In some embodiments, if the received second type of data includes at least 1 week of medication data, the received second type of data satisfies the minimum medication data reporting condition.

[0321] In some implementations, the message states that a report is available.

[0322] In some implementations, the message includes a link to the report.

[0323] In some embodiments, the data indicative of analyte levels are data indicative of glucose levels. In some embodiments, the data indicative of analyte levels are data indicative of ketone levels. In some embodiments, the data indicative of analyte levels are data indicative of lactate levels.

[0324] In many embodiments, an analyte monitoring system includes: a reader device including: a display; wireless communication circuitry configured to receive a first type of data from an on-body unit including an analyte sensor and to receive a second type of data from a drug delivery device, wherein the first type of data includes data indicating an analyte level of a subject and wherein the second type of data includes drug administration data; and one or more processors coupled to a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to: determine whether a time period that has elapsed since the drug delivery device received the second type of data exceeds a threshold; and display a message prompting a user to transmit the second type of data.

[0325] In some embodiments, the message includes a reminder to scan the drug delivery device.

[0326] In some embodiments, the threshold is 24 hours.

[0327] In many embodiments, a method for managing diabetes includes the steps of receiving a first type of data including data indicating an analyte level of a subject and a second type of data including medication administration data; determining whether a time period that has elapsed since the second type of data was received exceeds a threshold; and displaying a message prompting a user to transmit the second type of data.

[0328] In some embodiments, the second type of data is received from a medication delivery device, and wherein the message includes a reminder to scan the medication delivery device.

[0329] In some embodiments, the threshold is 24 hours.

[0330] In some embodiments, the analyte sensor is a glucose sensor. In some embodiments, the analyte sensor is a ketone sensor. In some embodiments, the analyte sensor is a lactate sensor.

[0331] Terms

[0332] Exemplary embodiments are set forth in the following numbered clauses:

[0333] Clause 1. An analyte monitoring system comprising:

[0334] Reader device, including:

[0335] monitor;

[0336] wireless communication circuitry configured to receive a first type of data from an on-body unit including an analyte sensor and a second type of data from a drug delivery device,

[0337] wherein the first type of data includes data indicative of an analyte level in the subject, and

[0338] wherein the second type of data includes drug delivery device identification data and dosage data; and

[0339] One or more processors coupled to a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to:

[0340] storing the first type of data and the second type of data in a memory;

[0341] receiving an indication that a user is logged into a remote server, and in response, sending the first type of data and the second type of data to the remote server; and

[0342] An indication of a user logging out of the remote server is received, and in response, the sending of the first type of data and the second type of data to the remote server is stopped.

[0343] Clause 2. The analyte monitoring system of clause 1, further comprising a remote server, the remote server comprising:

[0344] One or more processors of a remote server, coupled to a memory of the remote server, the memory storing instructions that, when executed by the one or more processors, cause the one or more processors to:

[0345] detecting an indication of a user logging in from a remote server, and in response, sharing the first type of data and the second type of data with an authorized third party or application; and

[0346] An indication of a user logging out from the remote server is detected, and in response, sharing of the first type of data and the second type of data with authorized third parties or applications is stopped.

[0347] Clause 3. The analyte monitoring system of any of clauses 1 to 2, wherein the memory of the reader device further stores instructions that cause the one or more processors of the reader device to:

[0348] receiving an indication of a user logging back in after logging out for a first period of time, and in response, sending the first type of data and the second type of data stored during the first period of time to a remote server; and

[0349] The memory of the remote server further stores instructions, which cause one or more processors of the remote server to:

[0350] Detecting an indication of a user logging back in after logging out for a first time period and the first type of data and the second type of data stored during the first time period, and in response, sharing the first type of data and the second type of data stored during the first time period with an authorized third party or application.

[0351] Clause 4. The analyte monitoring system of any of clauses 1 to 3, wherein the memory of the remote server further stores instructions that cause one or more processors of the remote server to:

[0352] The first type of data and the second type of data are automatically shared with authorized third parties or applications.

[0353] Clause 5. The analyte monitoring system of any one of clauses 1 to 4, wherein the memory of the remote server further stores instructions that cause one or more processors of the remote server to:

[0354] After the user authorizes sharing of the first type of data and the second type of data stored during the first time period, the first type of data and the second type of data stored during the first time period are shared with an authorized third party or application.

[0355] Clause 6. The analyte monitoring system of any one of clauses 1 to 5, wherein the memory of the reader device further stores instructions that cause the one or more processors of the reader device to:

[0356] An indication is received from a remote server that a user deletes an account associated with the user, and in response, the first type of data and the second type of data stored in a memory of the reader device are deleted.

[0357] Clause 7. The analyte monitoring system of any one of clauses 1 to 6, wherein the memory of the remote server further stores instructions that cause one or more processors of the remote server to:

[0358] An indication by a user to delete an account associated with the user is detected, and in response, the first type of data and the second type of data stored on the remote server are deleted.

[0359] Clause 8. The analyte monitoring system of any one of clauses 1 to 7, wherein the memory of the reader device further stores instructions that cause the one or more processors of the reader device to:

[0360] In response to receiving an indication from a user to delete an account associated with the user, a graphical user interface is displayed to prompt the user to confirm the deletion before deleting the first type of data and the second type of data.

[0361] Clause 9. The analyte monitoring system of any of Clauses 1 to 8, wherein the GUI prompting the user to confirm the deletion includes a request to enter a password of the user.

[0362] Clause 10. The analyte monitoring system of any one of clauses 1 to 9, wherein the memory of the remote server further stores instructions that cause one or more processors of the remote server to:

[0363] In response to receiving an indication from a user to delete an account associated with the user, the first type of data and the second type of data are stored in the secure compartment before deleting the first type of data and the second type of data stored in the memory.

[0364] Clause 11. The analyte monitoring system of clause 10, wherein the secure compartment requires a password or verification code for access.

[0365] Clause 12. An analyte monitoring system comprising:

[0366] Reader device, including:

[0367] monitor;

[0368] wireless communication circuitry configured to receive a first type of data from an on-body unit including an analyte sensor and a second type of data from a drug delivery device,

[0369] wherein the first type of data includes data indicative of an analyte level in the subject, and

[0370] wherein the second type of data includes error data associated with the drug delivery device; and

[0371] One or more processors coupled to a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to:

[0372] displaying information associated with data indicative of the subject's analyte level; and

[0373] A message is displayed based on the error data received.

[0374] Clause 13. The analyte monitoring system of clause 12, wherein the message is displayed in a modal window.

[0375] Clause 14. The analyte monitoring system of any of Clauses 12 to 13, wherein the message is displayed in a banner.

[0376] Clause 15. The analyte monitoring system of any of Clauses 12 to 14, wherein the error data comprises data indicating a number of failed scans of the drug delivery device.

[0377] Clause 16. The analyte monitoring system of any of Clauses 12 to 15, wherein a message is displayed if the number of failed scans exceeds a threshold.

[0378] Clause 17. The analyte monitoring system of any of Clauses 12 to 16, wherein the message includes a prompt related to scanning the drug delivery device.

[0379] Clause 18. The analyte monitoring system of any of Clauses 12 to 17, wherein the message includes an animation depicting how to scan the drug delivery device.

[0380] Clause 19. A method for managing diabetes comprising the steps of:

[0381] receiving a first type of data including data indicative of an analyte level of a subject and a second type of data including error data associated with a drug delivery device;

[0382] displaying information associated with data indicative of the subject's analyte level; and

[0383] A message is displayed based on the received error data.

[0384] Clause 20. The method of Clause 19, wherein the error data comprises data indicating a number of failed scans of the drug delivery device.

[0385] Clause 21. The method of any one of clauses 19 to 20, wherein if the number of failed scans exceeds a threshold, a message is displayed.

[0386] Clause 22. The method of any of Clauses 19 to 22, wherein the message includes helpful tips related to scanning the drug delivery device.

[0387] Clause 23. The method of any of Clauses 19 to 23, wherein the message includes an animation depicting how to scan the drug delivery device.

[0388] Clause 24. An analyte monitoring system comprising:

[0389] Reader device, including:

[0390] monitor;

[0391] wireless communication circuitry configured to receive a first type of data from an on-body unit including an analyte sensor and a second type of data from a drug delivery device,

[0392] wherein the first type of data includes data indicative of an analyte level in the subject, and

[0393] Wherein, the second type of data includes drug administration data; and

[0394] One or more processors coupled to a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to:

[0395] determining whether second type of data received from the drug delivery device satisfies minimum drug administration data reporting conditions for inclusion in a report, wherein the report includes metrics based on the first type of data and drug administration information based on the second type of data;

[0396] If it is determined that the received second type of data is sufficient, generating a report; and

[0397] Displays messages about the report.

[0398] Clause 25. The system of clause 24, wherein the minimum medication data reporting condition includes a sufficient amount of the second type of data to generate a weekly report.

[0399] Clause 26. The system of any one of Clauses 24 to 25, wherein the minimum medication data reporting condition comprises a sufficient amount of the second type of data to generate a daily report.

[0400] Clause 27. The system of any one of clauses 24 to 26, wherein if the received second type of data includes at least 1 day of medication data, it is determined that the received second type of data meets the minimum medication data reporting condition.

[0401] Clause 28. The system of any one of clauses 24 to 27, wherein if the received second type of data includes at least 3 days of medication data, it is determined that the received second type of data meets the minimum medication data reporting condition.

[0402] Clause 29. A system according to any one of clauses 24 to 28, wherein if the received second type of data includes at least 1 week of medication data, it is determined that the received second type of data meets the minimum medication data reporting condition.

[0403] Clause 30. A system according to any one of clauses 24 to 29, wherein the message states that the report is available.

[0404] Clause 31. The system of any of Clauses 24 to 30, wherein the message includes a link to the report.

[0405] Clause 32. A method for managing diabetes comprising the steps of:

[0406] receiving a first type of data including data indicative of an analyte level of a subject and a second type of data including medication administration data;

[0407] determining whether second type of data received from the drug delivery device satisfies minimum drug administration data reporting conditions for inclusion in a report, wherein the report includes metrics based on the first type of data and drug administration information based on the second type of data;

[0408] generating a report if the received second type of data satisfies minimum reporting conditions for inclusion in the report; and

[0409] Displays messages about the report.

[0410] Clause 33. The method of clause 32, further comprising the step of determining whether the received first type of data satisfies minimum analyte data reporting conditions for inclusion in the report.

[0411] Clause 34. The method of any one of Clauses 32 to 33, wherein the minimum dosing data reporting condition comprises a sufficient amount of the second type of data to generate a weekly report.

[0412] Clause 35. The method of any one of Clauses 32 to 34, wherein the minimum medication data reporting condition comprises a sufficient amount of the second type of data to generate a daily report.

[0413] Clause 36. The method of any one of clauses 32 to 35, wherein the received second type of data satisfies the minimum medication data reporting condition if the received second type of data includes at least 1 day of medication data.

[0414] Clause 37. A method according to any one of clauses 32 to 36, wherein the received second type of data satisfies the minimum medication data reporting condition if the received second type of data includes at least 3 days of medication data.

[0415] Clause 38. A method according to any one of clauses 32 to 37, wherein the received second type of data satisfies the minimum medication data reporting condition if the received second type of data includes at least 1 week of medication data.

[0416] Clause 39. A method according to any one of clauses 32 to 38, wherein the message states that the report is available.

[0417] Clause 40. The method of any one of clauses 32 to 39, wherein the message includes a link to the report.

[0418] Clause 41. An analyte monitoring system comprising:

[0419] Reader device, including:

[0420] monitor;

[0421] wireless communication circuitry configured to receive a first type of data from an on-body unit including an analyte sensor and a second type of data from a drug delivery device,

[0422] wherein the first type of data includes data indicative of an analyte level in the subject, and

[0423] Wherein, the second type of data includes drug administration data; and

[0424] One or more processors coupled to a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to:

[0425] determining whether a period of time that has elapsed since the drug delivery device received the second type of data exceeds a threshold; and

[0426] A message is displayed prompting the user to transmit the second type of data.

[0427] Clause 42. The system of clause 41, wherein the message includes a reminder to scan the medication delivery device.

[0428] Clause 43. A system according to any one of clauses 41 to 42, wherein the threshold is 24 hours.

[0429] Clause 44. A method for managing diabetes comprising the steps of:

[0430] receiving a first type of data including data indicative of an analyte level of a subject and a second type of data including medication administration data;

[0431] determining whether a period of time that has elapsed since receiving the second type of data exceeds a threshold; and

[0432] A message is displayed prompting the user to transmit the second type of data.

[0433] Clause 45. The method of clause 44, wherein the second type of data is received from a medication delivery device, and wherein the message includes a reminder to scan the medication delivery device.

[0434] Clause 46. A method according to any one of clauses 44 to 45, wherein the threshold is 24 hours.

Claims

1. An analyte monitoring system comprising: Reader device, including: monitor; wireless communication circuitry configured to receive a first type of data from an on-body unit including an analyte sensor and a second type of data from a drug delivery device, wherein the first type of data comprises data indicative of an analyte level in the subject, and wherein the second type of data comprises error data associated with the drug delivery device; and One or more processors coupled to a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to: displaying information associated with the data indicative of the analyte level of the subject; and Displays a message based on the error data received.

2. The analyte monitoring system of claim 1, wherein: The message is displayed in a modal window.

3. The analyte monitoring system of claim 1, wherein: The message is displayed in a banner.

4. The analyte monitoring system of claim 1, wherein: The error data includes data indicating a number of failed scans of the drug delivery device.

5. The analyte monitoring system of claim 4, wherein: If the number of failed scans exceeds a threshold, the message is displayed.

6. The analyte monitoring system of claim 5, wherein: The message includes a prompt related to scanning the drug delivery device.

7. The analyte monitoring system of claim 5, wherein: The message includes an animation depicting how to scan the drug delivery device.

8. A method for managing diabetes comprising the steps of: receiving a first type of data including data indicative of an analyte level of a subject and a second type of data including error data associated with the drug delivery device; displaying information associated with the data indicative of the analyte level of the subject; as well as Displays a message based on the error data received.

9. The method according to claim 8, wherein: The error data includes data indicating a number of failed scans of the drug delivery device.

10. The analyte monitoring system of claim 9, wherein: If the number of failed scans is above a threshold, the message is displayed.

11. The analyte monitoring system of claim 10, wherein: The message includes helpful tips related to scanning the drug delivery device.

12. The analyte monitoring system of claim 10, wherein: The message includes an animation depicting how to scan the drug delivery device.

13. An analyte monitoring system comprising: Reader device, including: monitor; wireless communication circuitry configured to receive a first type of data from an on-body unit including an analyte sensor and a second type of data from a drug delivery device, wherein the first type of data comprises data indicative of an analyte level in the subject, and wherein the second type of data includes drug administration data; and One or more processors coupled to a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to: determining whether the second type of data received from the drug delivery device satisfies minimum drug administration data reporting conditions for inclusion in a report, wherein the report includes metrics based on the first type of data and drug administration information based on the second type of data; If it is determined that the received second type of data is sufficient, generating the report; and Displays a message about the report.

14. The system according to claim 13, wherein: The minimum medication administration data reporting conditions include a sufficient amount of the second type of data to generate a weekly report.

15. The system of claim 13, wherein: The minimum medication administration data reporting conditions include a sufficient amount of the second type of data to generate a daily report.

16. The system of claim 13, wherein: If the received second type data includes at least 1 day's worth of medication data, it is determined that the received second type data meets the minimum medication data reporting condition.

17. The system of claim 13, wherein: If the received second type data includes at least 3 days of medication data, it is determined that the received second type data meets the minimum medication data reporting condition.

18. The system of claim 13, wherein: If the received second type data includes at least 1 week of medication data, it is determined that the received second type data meets the minimum medication data reporting condition.

19. The system of claim 13, wherein: The message states that the report is available.

20. The system of claim 13, wherein: The message includes a link to the report.

21. A method for managing diabetes comprising the steps of: receiving a first type of data including data indicative of an analyte level of a subject and a second type of data including medication administration data; determining whether the second type of data received from the drug delivery device satisfies minimum drug administration data reporting conditions for inclusion in a report, wherein the report includes metrics based on the first type of data and drug administration information based on the second type of data; generating the report if the received second type of data satisfies minimum reporting conditions for inclusion in the report; and Displays a message about the report.

22. The method of claim 21 further comprising the step of determining whether the received first type of data satisfies minimum analyte data reporting conditions for inclusion in the report.

23. The method according to claim 21, wherein: The minimum medication administration data reporting conditions include a sufficient amount of the second type of data to generate a weekly report.

24. The method according to claim 21, wherein: The minimum medication administration data reporting conditions include a sufficient amount of the second type of data to generate a daily report.

25. The method according to claim 21, wherein: If the received second type data includes at least 1 day's worth of medication data, the received second type data satisfies the minimum medication data reporting condition.

26. The method according to claim 21, wherein: If the received second type data includes at least 3 days of medication data, the received second type data meets the minimum medication data reporting condition.

27. The method of claim 21, wherein: If the received second type data includes at least 1 week of medication data, the received second type data satisfies the minimum medication data reporting condition.

28. The method of claim 21, wherein: The message states that the report is available.

29. The method according to claim 21, wherein: The message includes a link to the report.

30. An analyte monitoring system comprising: Reader device, including: monitor; wireless communication circuitry configured to receive a first type of data from an on-body unit including an analyte sensor and a second type of data from a drug delivery device, wherein the first type of data comprises data indicative of an analyte level in the subject, and wherein the second type of data includes drug administration data; and One or more processors coupled to a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to: determining whether a period of time that has elapsed since the drug delivery device received the second type of data exceeds a threshold; and A message is displayed prompting the user to transmit the second type of data.

31. The system of claim 30, wherein: The message includes a reminder to scan the medication delivery device.

32. The system of claim 30, wherein: The threshold is 24 hours.

33. A method for managing diabetes comprising the steps of: receiving a first type of data including data indicative of an analyte level of a subject and a second type of data including medication administration data; determining whether a period of time that has elapsed since receiving the second type of data exceeds a threshold; as well as A message is displayed prompting the user to transmit the second type of data.

34. The method of claim 33, wherein: The second type of data is received from a medication delivery device, and wherein the message includes a reminder to scan the medication delivery device.

35. The method of claim 33, wherein: The threshold is 24 hours.

36. An analyte monitoring system comprising: Reader device, including: monitor; wireless communication circuitry configured to receive a first type of data from an on-body unit including an analyte sensor and a second type of data from a drug delivery device, wherein the first type of data comprises data indicative of an analyte level in the subject, and wherein the second type of data includes drug delivery device identification data and dosage data; and One or more processors coupled to a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to: storing the first type of data and the second type of data in the memory; receiving an indication that a user is logged into a remote server, and in response, sending the first type of data and the second type of data to the remote server; and An indication of a user logging out of the remote server is received, and in response, the sending of the first type of data and the second type of data to the remote server is stopped.

37. The analyte monitoring system of claim 36, further comprising the remote server, the remote server comprising: One or more processors of the remote server are coupled to a memory of the remote server, the memory storing instructions that, when executed by the one or more processors, cause the one or more processors to: detecting an indication of a login by the user from the remote server, and in response, sharing the first type of data and the second type of data with an authorized third party or application; as well as An indication of the user logging out of the remote server is detected, and in response, the sharing of the first type of data and the second type of data with authorized third parties or applications is stopped.

38. The analyte monitoring system of claim 36, wherein: The memory of the reader device also stores instructions that cause the one or more processors of the reader device to: receiving an indication of the user logging back in after logging out for a first time period, and in response, sending the first type of data and the second type of data stored during the first time period to the remote server; and The memory of the remote server further stores instructions for causing the one or more processors of the remote server to perform the following operations: Detecting an indication of the user logging back in after logging out of the first time period and the first type of data and the second type of data stored during the first time period, and in response, sharing the first type of data and the second type of data stored during the first time period with the authorized third party or application.

39. The analyte monitoring system of claim 38, wherein: The memory of the remote server also stores instructions that cause the one or more processors of the remote server to: The first type of data and the second type of data are automatically shared with the authorized third party or application.

40. The analyte monitoring system of claim 38, wherein: The memory of the remote server also stores instructions that cause the one or more processors of the remote server to: After the user authorizes sharing of the first type of data and the second type of data stored during the first time period, the first type of data and the second type of data stored during the first time period are shared with the authorized third party or application.

41. The analyte monitoring system of claim 36, wherein: The memory of the reader device also stores instructions that cause the one or more processors of the reader device to: An indication is received from the remote server that the user deletes an account associated with the user, and in response, the first type of data and the second type of data stored in the memory of the reader device are deleted.

42. The analyte monitoring system of claim 41, wherein: The memory of the remote server also stores instructions that cause the one or more processors of the remote server to: The indication by the user to delete the account associated with the user is detected, and in response, the first type of data and the second type of data stored on the remote server are deleted.

43. The analyte monitoring system of claim 36, wherein: The memory of the reader device also stores instructions that cause the one or more processors of the reader device to: In response to receiving an indication from the user to delete an account associated with the user, displaying a graphical user interface to prompt the user to confirm the deletion before deleting the first type of data and the second type of data.

44. The analyte monitoring system of claim 43, wherein: The graphical user interface prompting the user to confirm deletion includes a request to enter a password of the user.

45. The analyte monitoring system of claim 36, wherein: The memory of the remote server also stores instructions that cause the one or more processors of the remote server to: In response to receiving an indication from the user to delete the account associated with the user, the first type of data and the second type of data are stored in a secure compartment before the first type of data and the second type of data stored in the memory are deleted.

46. ​​The analyte monitoring system of claim 45, wherein: The secure compartment requires a password or verification code to access.

Images