Docket No. A0130.0317.WO 14890WOO1 SYSTEMS AND METHODS FOR DIABETES MANAGEMENT CROSS-REFERENCE TO RELATED APPLICATIONS [0001] This application claims priority to U.S. Provisional Application No.63/536,778, filed September 6, 2023, and U.S. Provisional Application No.63/406,385, filed September 14, 2022, both of which are hereby expressly incorporated by reference in its entireties for all purposes. This application is also related to U.S. Application Serial No.17/725,063, filed April 20, 2022, which claims priority to U.S. Provisional Application No.63/236,910, filed August 25, 2021, and U.S. Provisional Application No.63/177,706, filed April 21, 2021, all of which are hereby expressly incorporated herein by reference in their entireties for all purposes. FIELD [0002] The subject matter described herein relates generally to systems, devices, and methods relating to integrated systems for diabetes management such as, for example, an integrated platform that connects insulin pens with a common viewing platform such that data can be shared among many parties. BACKGROUND [0003] The detection and/or monitoring of analyte levels, such as glucose, ketones, lactate, oxygen, hemoglobin A1C, or the like, can be vitally important to the health of an individual having diabetes. Patients suffering from diabetes mellitus can experience complications including loss of consciousness, cardiovascular disease, retinopathy, neuropathy, and nephropathy. Diabetics are generally required to monitor their glucose levels to ensure that they are being maintained within a clinically safe range, and may also use this information to determine if and/or when insulin is needed to reduce glucose levels in their bodies or when additional glucose is needed to raise the level of glucose in their bodies. [0004] Growing clinical data demonstrates a strong correlation between the frequency of glucose monitoring and glycemic control. Despite such correlation, many individuals diagnosed with a diabetic condition do not monitor their glucose levels as frequently as they should due to a combination of factors including inconvenience, testing discretion, pain associated with glucose testing, and cost. [0005] For patients that rely on the administration of medications (e.g., insulin) to treat or manage diabetes, it is desirable to have systems, devices, or methods that can integrate glucose Docket No. A0130.0317.WO 14890WOO1 data with insulin dosing data and provide more actionable insights to both patients, caregivers, and HCPs. Manual logging of insulin doses is not only a huge time commitment but often results in inaccurate dosing logs. Moreover, sharing these manual logs with the HCP is a big hassle for patients and fraught with workflow issues. [0006] Therapeutic management of diabetes often requires the use of multiple drugs that have different delivery frequencies (i.e., daily, weekly) as well as routes of administration (oral or injection). The combination of drug types, delivery frequencies and routes of administration can be difficult to manage, creating significant cognitive burden for a user that often translates to poor dose regimen concordance. Studies have shown that amongst insulin-dependent people with Type 1 diabetes, up to 24% of mealtime rapid acting insulin boluses and 36% of long acting once daily basal doses are missed, leading to poor glucose control and diabetes management. Existing dose logbooks are only as useful as a user wants to make them. Their efficacy is directly correlated to a user’s willingness to log doses and reference past loggings. The dawn of connected dosing technology, such as BLUETOOTH®-enabled insulin pens, has enabled doses to be logged automatically into companion mobile phone applications as they are delivered with no user action required. While useful in day-to-day management, this method suffers from two notable shortcomings: (1) it is not able to correlate directly with glycemic outcomes; and (2) insulin doses are often presented in tabular form that is difficult to read and interpret over a large time window. [0007] For these and other reasons, needs exist for improved systems, methods, and devices relating to integrated systems for diabetes management. SUMMARY [0008] Provided herein are example embodiments of systems, devices and methods relating to management of diabetes, including integrated managements systems that include an analyte monitoring device, a medication delivery device, a reader device, monitoring software, and reporting software. In many embodiments, the analyte monitoring device (e.g., a continuous or flash glucose monitor) and the medication delivery device (e.g., an insulin pen) are communicatively coupled with the reader device to enable an easy transfer of analyte data, dose logs, and other information to computing devices that include monitoring and/or reporting software. The integrated system can include GUI displays that instruct and assist the user in Docket No. A0130.0317.WO 14890WOO1 connecting a medication delivery device to the monitoring software on, e.g., the reader device, such that dosing logs and other information can be transferred from the medication delivery device. The integrated system also includes reporting software that can produce one or more reports that incorporate data regarding analyte levels and metrics and medication dosing amounts and metrics. [0009] This method may address both of those concerns by utilizing glucose data as an indicator of poor dose concordance and presenting the data in a way that aims to allow a trained health care professional to quickly identify situations where poor medication dose concordance results in poor glycemic control. In some embodiments, the glucose data may be the sole indicator of poor dose concordance. [0010] Systems, devices and methods are provided for incorporating a medication 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. The integrated management system may produce a plurality of reports that may include data related to analyte levels (e.g., glucose levels) and medication delivered (e.g., insulin delivered). The integrated system may also include a mode in which certain types of data are no longer shared and/or stored if the user is not signed into an account. The types of data shared and/or stored when the user is not signed into an account may differ from the types of data shared and/or stored when the user is signed into an account. [0011] Other systems, devices, methods, features and advantages of the subject matter described herein will be or will become apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, devices, methods, features and advantages be included within this description, be within the scope of the subject matter described herein, and be protected by the accompanying claims. In no way should the features of the example embodiments be construed as limiting the appended claims, absent express recitation of those features in the claims. BRIEF DESCRIPTION OF THE FIGURES [0012] The details of the subject matter set forth herein, both as to its structure and operation, may be apparent by study of the accompanying figures, in which like reference numerals refer to like parts. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the subject matter. Moreover, all illustrations are Docket No. A0130.0317.WO 14890WOO1 intended to convey concepts, where relative sizes, shapes and other detailed attributes may be illustrated schematically rather than literally or precisely. [0013] FIGS.1A and 1B are block diagrams of example embodiments of a integrated management system. [0014] FIG.2A is a schematic diagram depicting an example embodiment of a sensor control device. [0015] FIG.2B is a block diagram depicting an example embodiment of a sensor control device. [0016] FIG.3A is a schematic diagram depicting an example embodiment of a medication delivery device. [0017] FIG.3B is a block diagram depicting an example embodiment of a medication delivery device. [0018] FIG.3C is a schematic diagram depicting an example embodiment of a medication delivery device with a smart button. [0019] FIG.4A is a schematic diagram depicting an example embodiment of a display device. [0020] FIG.4B is a block diagram depicting an example embodiment of a display device. [0021] FIG.5 is a block diagram depicting an example embodiment of a user interface device. [0022] FIG.6A is a flow diagram of a user experience of an example embodiment of the integrated management system. [0023] FIG.6B is a flow diagram of an exemplary method for displaying a message relating to report availability. [0024] FIG.6C is a flow diagram of an exemplary method for displaying an error message. [0025] FIG.6D is a flow diagram of an exemplary method for displaying a reminder. [0026] FIG.7 is a flow diagram of a user experience of adding a medication delivery device to the integrated management system. [0027] FIG.8A is a block diagram depicting an example embodiment of a Snapshot report. [0028] FIGS.8B-8C are example embodiments of Snapshot reports. [0029] FIG.9A is a block diagram depicting an example embodiment of a Weekly Summary report. Docket No. A0130.0317.WO 14890WOO1 [0030] FIGS.9B-9G are example embodiments of Weekly Summary reports. [0031] FIG.10A is a block diagram depicting an example embodiment of a Daily Log report. [0032] FIGS.10B-10C are example embodiments of Daily Log reports. [0033] FIG.11A is a block diagram depicting an example embodiment of a Daily Pattern report. [0034] FIGS.11B-11C are example embodiments of Daily Pattern reports. [0035] FIGS.11D-11E are exemplary embodiments of Daily Pattern report GUIs that may be displayed on the display device. [0036] FIG.12A is a block diagram depicting an example embodiment of a Mealtime Patterns report. [0037] FIGS.12B-12C are example embodiments of a Mealtime Patterns report. [0038] FIG.13A is a block diagram depicting an example embodiment of a Device Details report. [0039] FIG.13B is an example embodiment of a Device Details report. [0040] FIG.14 is a block diagram depicting an example embodiment of an AGP report. [0041] FIG.15A is a block diagram depicting an example embodiment of a GUI from a Patient Dashboard. [0042] FIG.15B is an example embodiment of a GUI from a Patient Dashboard. [0043] FIG.16A is a block diagram depicting an example embodiment of a GUI related to a Data Sources Modal with Connected Pen. [0044] FIG.16B is an example embodiment of a GUI related to a Data Sources Modal with Connected Pen. [0045] FIG.17A is a block diagram depicting an example embodiment of an alert related to a connected insulin pen. [0046] FIG.17B is an example embodiment of an alert related to a connected insulin pen. [0047] FIGS.18A-18B are block diagrams depicting example embodiments of comparative AGP reports. [0048] FIG.18C is an exemplary AGP illustrating all data. [0049] FIG.18D is an exemplary AGP illustrating data excluding missed doses. [0050] FIG.19 is example embodiment of a Comparison Report. Docket No. A0130.0317.WO 14890WOO1 [0051] FIGS.20A-20D are example embodiments of GUIs for use with connecting a medical delivery device with a monitoring application. [0052] FIGS.20E-20F are example embodiments of GUIs for use with managing the user’s connected medication delivery device. [0053] FIGS.21A-21B are example embodiments of GUIs for use with downloading and reviewing dosing records. [0054] FIG.21C are example embodiments of GUIs for use with editing medication dosage notes. [0055] FIG.21D is an example embodiment of a GUI for use with prompting a user to learn about connecting a medication delivery device. [0056] FIG.22A-22B are example embodiments of GUIs for use with customizing a name for a medication delivery device. [0057] FIGS.23A-23C are example embodiments of GUIs for use concerning a logbook. [0058] FIGS.24A-24C are example embodiments of Insulin Summary Report GUIs. [0059] FIG.25 is an exemplary method for displaying a missed meal dose alert or message. [0060] FIG.26 is an exemplary method for displaying a correction dose alert or message. [0061] FIG.27 is an exemplary method for displaying a congratulatory alert or message. [0062] FIGS.28A-E are exemplary embodiments of GUIs of Daily View Report GUIs. [0063] FIGS.29A-D are example embodiments of GUIs related to accounts or an accountless mode. [0064] FIG.29E is an exemplary method regarding establishing an account. [0065] FIGS.30A-1 - 30R-3 are example embodiments of GUIs displayed in a monitoring application with a connected pen. DETAILED DESCRIPTION [0066] Before the present subject matter is described in detail, it is to be understood that this disclosure is not limited to the particular embodiments described herein, as such may, of course, vary. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting, since the scope of the present disclosure will be limited only by the appended claims. [0067] Generally, embodiments of the present disclosure include systems, devices, and methods related to integrated diabetes management. The integrated diabetes management system Docket No. A0130.0317.WO 14890WOO1 can include smart delivery systems, such as connected, smart insulin pens, glucose sensors, software to receive and process data from the glucose sensors and smart delivery systems, and a viewing platform capable of determining and visualizing dose analytics. The integrated management system (IMS) can further include reports that include insights as to the effects of various inulin doses and treatment advice, including dosing recommendations. [0068] The integrated diabetes management can be implemented as software and/or firmware instructions stored in a memory of a computing device for execution by at least one processor or processing circuitry thereof. The computing device can be in the possession of a user or 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 trusted computer system that is accessible through a network, and the integrated management software can be presented to the user in the form of an interactive web page by way of a browser executed on a local display device (having the user interface) in communication with the server or trusted computer system through the network. In this and other embodiments, the integrated management software can be executed across multiple devices, or executed, in part, on processing circuitry of a local display device and, in part, on processing circuitry of a server or trusted computer system. It will be understood by those of skill in the art that when the IMS is described as performing an action, such action is performed according to instructions stored in a computer memory (including instructions hardcoded in read only memory) that, 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 action can alternatively be performed by hardware that is hardwired to implement the action (e.g., dedicated circuitry) as opposed to performance by way of instructions stored in memory. [0069] Furthermore, as used herein, a system on which the IMS is implemented can be referred to as an integrated management system. The integrated management system can be configured for the sole purpose of providing integrated management or can be a multifunctional system of which integrated management is only one aspect. For example, in some embodiments the integrated management system can also be capable of monitoring analyte levels of a user. In some embodiments the integrated management system can also be capable of delivering medication to the user, such as with an injection or infusion device. In some embodiments, the integrated management system is capable of both monitoring analytes and delivering medication. Docket No. A0130.0317.WO 14890WOO1 [0070] These embodiments and others described herein represent improvements in the field of computer-based dose determination, analyte monitoring, and medication delivery systems. The specific features and potential advantages of the disclosed embodiments are further discussed below. [0071] Before describing the integrated management embodiments in detail, it is first desirable to describe examples of integrated management systems on or through which the integrated management application can be implemented. Example Embodiments of Integrated Systems [0072] FIG.1A is a block diagram depicting an example embodiment of integrated system 100. In this embodiment, integrated management system 100 is capable of delivering one or more medications, logging medication doses, monitoring one or more analytes, and determining and viewing analytics, and providing treatment advice. This multifunctional example is used to illustrate the high degree of interconnectivity and performance obtainable by system 100. [0073] Here, system 100 includes a sensor control device (SCD) 102 configured to collect analyte level information from a user, a medication delivery device (MDD) 152 configured to deliver medication to the user, and a display device 120 configured to present information to the user and receive input or information from the user. The structure and function of each device will be described in detail herein. [0074] System 100 is configured for highly interconnected and highly flexible communication between devices. Each of the three devices 102, 120, and 152, can communicate directly with each other (without passing through an intermediate electronic device) or indirectly with each other (such as through cloud network 190, or through another device and then through network 190). Bidirectional communication capability between devices, as well as between devices and network 190, is shown in FIG.1A with a double-sided arrow. However, those of skill in the art will appreciate that any of the one or more devices (e.g., SCD) can be capable of unidirectional communication such as, for example, broadcasting, multicasting, or advertising communications. In each instance, whether bidirectional or unidirectional, the communication can be wired or wireless. The protocols that govern communication over each path can be the same or different, and can be either proprietary or standardized. For example, wireless communication between devices 102, 120, and 152 can be performed according to a BLUETOOTH® (including BLUETOOTH® Low Energy) standard, a Near Field Docket No. A0130.0317.WO 14890WOO1 Communication (NFC) standard, a Wi-Fi (802.11x) standard, a mobile telephony standard, or others. All communications over the various paths can be encrypted, and each device of FIG.1A can be configured to encrypt and decrypt those communications sent and received. In each instance the communication pathways of FIG.1A can be direct (e.g., BLUETOOTH® or NFC) or indirect (e.g., Wi-Fi, mobile telephony, or other internet protocol). Embodiments of system 100 do not need to have the capability to communicate across all of the pathways indicated in FIG.1A. [0075] In addition, although FIG.1A depicts a single display device 120, a single SCD 102, and a single MDD 152, those of skill in the art will appreciate that system 100 can comprise a plurality of any of the aforementioned devices. By way of example only, system 100 can comprise a single SCD 102 in communication with multiple (e.g., two, three, four, etc.) display devices 120 and/or multiple MDDs 152. Alternatively, system 100 can comprise a plurality of SCDs 102 in communication with a single display device 120 and/or a single MDD 152. Furthermore, each of the plurality of devices can be of the same or different device types. For example, system 100 can comprise multiple display devices 120, including a smart phone, a handheld receiver, and/or a smart watch, each of which can be in communication with SCD 102 and/or MDD 152, as well in communication with each other. [0076] Analyte data can be transferred between each device within system 100 in an autonomous fashion (e.g., transmitting automatically according to a schedule), or in response to a request for analyte data (e.g., sending a request from a first device to a second device for analyte data, followed by transmission of the analyte data from the second device to the first device). Other techniques for communicating data can also be employed to accommodate more complex systems like cloud network 190. [0077] FIG.1B is a block diagram depicting another example embodiment of integrated management system 100. Here, system 100 includes SCD 102, MDD 152, a first display device 120-1, a second display device 120-2, local computer system 170, and trusted computer system 180 that is accessible by cloud network 190. SCD 102 and MDD 152 are capable of communication with each other and with display device 120-1, which can act as a communication hub for aggregating information from SCD 102 and MDD 152, processing and displaying that information where desired, and transferring some or all of the information to cloud network 190 and/or computer system 170. Conversely, display device 120-1 can receive Docket No. A0130.0317.WO 14890WOO1 information from cloud network 190 and/or computer system 170 and communicate some or all of the received information to SCD 102, MDD 152, or both. Computer system 170 may be a personal computer, a server terminal, a laptop computer, a tablet, or other suitable data processing device. Computer system 170 can include or present software for data management and analysis and communication with the components in system 100. Computer system 170 can be used by the user or a medical professional to display and/or analyze analyte data measured by SCD 102. Furthermore, although FIG.1B depicts a single SCD 102, a single MDD 152, and two display devices 120-1 and 120-2, those of skill in the art will appreciate that system 100 can include a plurality of any of the aforementioned devices, wherein each plurality of devices can comprise the same or different types of devices. [0078] Referring still to FIG.1B, according to some embodiments, trusted computer system 180 can be within the possession of a manufacturer or distributor of a component of system 100, either physically or virtually through a secured connection, and can be used to perform authentication of the devices of system 100 (e.g., devices 102, 120-n, 152), for secure storage of the user’s data, and/or as a server that serves a data analytics program (e.g., accessible via a web browser) for performing analysis on the user’s measured analyte data and medication history. Trusted computer system 180 can also act as a data hub for routing and exchanging data between all devices in communication with system 180 through cloud network 190. In other words, all devices of system 100 that are capable of communicating with cloud network 190 (e.g., either directly with an internet connection or indirectly via another device), are also capable of communicating with all of the other devices of system 100 that are capable of communicating with cloud network 190, either directly or indirectly. [0079] Display device 120-2 is depicted in communication with cloud network 190. In this example, device 120-2 can be in the possession of another user that is granted access to the analyte and medication data of the person wearing SCD 102. For example, the person in possession of display device 120-2 can 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 can be configured to communicate analyte and medication data about the wearer through cloud network 190 (e.g., via trusted computer system 180) to another user with granted access to the data. Docket No. A0130.0317.WO 14890WOO1 Example Embodiments of Analyte Monitoring Devices [0080] The analyte monitoring functionality of integrated management system 100 can be realized through inclusion of one or more devices capable of collecting, processing, and displaying analyte data of the user. Example embodiments of such devices and their methods of use are described in Int’l Publ. No. WO 2018/152241 and U.S. Patent Publ. No.2011/0213225, both of which are incorporated by reference herein in their entireties for all purposes. [0081] Analyte monitoring can be performed in numerous different ways. “Continuous Analyte Monitoring” devices (e.g., “Continuous Glucose Monitoring” devices), for example, can transmit data from a sensor control device to a display device continuously or repeatedly with or without prompting, e.g., automatically according to a schedule. “Flash Analyte Monitoring” devices (e.g., “Flash Glucose Monitoring” devices or simply “Flash” devices), as another example, can transfer data from a sensor control device in response to a user-initiated request for data by a display device (e.g., a scan), such as with a Near Field Communication (NFC) or Radio Frequency Identification (RFID) protocol. [0082] Analyte monitoring devices that utilize a sensor configured to be placed partially or wholly within a user’s body can be referred to as in vivo analyte monitoring devices. For example, an in vivo sensor can be placed in the user’s body such that at least a portion of the sensor is in contact with a bodily fluid (e.g., interstitial (ISF) fluid such as dermal fluid in the dermal layer or subcutaneous fluid beneath the dermal layer, blood, or others) and can measure an analyte concentration in that bodily fluid. In vivo sensors can use various types of sensing techniques (e.g., chemical, electrochemical, or optical). Some systems utilizing in vivo analyte sensors can also operate without the need for finger stick calibration. [0083] “In vitro” devices are those where a sensor is brought into contact with a biological sample outside of the body (or rather “ex vivo”). These devices typically include a port for receiving an analyte test strip carrying bodily fluid of the user, which can be analyzed to determine the user’s blood glucose level. Other ex vivo devices have been proposed that attempt to measure the user’s internal analyte level non-invasively, such as by using an optical technique that can measure an internal body analyte level without mechanically penetrating the user’s body or skin. In vivo and ex vivo devices often include in vitro capability (e.g., an in vivo display device that also includes a test strip port). Docket No. A0130.0317.WO 14890WOO1 [0084] The present subject matter will be described with respect to sensors capable of measuring a glucose concentration, although detection and measurement of concentrations of other analytes are within the scope of the present disclosure. These other analytes can include, for example, ketones, lactate, oxygen, hemoglobin A1C, acetyl choline, amylase, bilirubin, cholesterol, chorionic gonadotropin, creatine kinase (e.g., CK-MB), creatine, DNA, fructosamine, glutamine, growth hormones, hormones, peroxide, prostate-specific antigen, prothrombin, RNA, thyroid stimulating hormone, troponin and others. The concentration of drugs, such as, for example, antibiotics (e.g., gentamicin, vancomycin, and the like), digitoxin, digoxin, drugs of abuse, theophylline, and warfarin, may also be monitored. The sensor can be configured to measure two or more different analytes at the same or different times. In some embodiments, the sensor control device can be coupled with two or more sensors, where 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 of those described herein). In other embodiments, a user can wear two or more sensor control devices, each of which is capable of measuring a different analyte. [0085] The embodiments described herein can be used with all types of in vivo, in vitro, and ex vivo devices capable of monitoring the aforementioned analytes and others. [0086] In many embodiments, the sensor operation can be controlled by SCD 102. The sensor can be mechanically and communicatively coupled with SCD 102, or can be just communicatively coupled with SCD 102 using a wireless communication technique. SCD 102 can include the electronics and power supply that enable and control analyte sensing performed by the sensor. In some embodiments the sensor or SCD 102 can be self-powered such that a battery is not required. SCD 102 can also include communication circuitry for communicating with another device that may or may not be local to the user’s body (e.g., a display device). SCD 102 can reside on the body of the user (e.g., attached to or otherwise placed on the user’s skin, or carried in the user’s clothes, etc.). SCD 102 can also be implanted within the body of the user along with the sensor. Functionality of SCD 102 can be divided between a first component implanted within the body (e.g., a component that controls the sensor) and a second component that resides on or otherwise outside the body (e.g., a relay component that communicates with the first component and also with an external device like a computer or smartphone). In other embodiments, SCD 102 can be external to the body and configured to non-invasively measure Docket No. A0130.0317.WO 14890WOO1 the user’s analyte levels. The sensor control device, depending on the actual implementation or embodiment, can also be referred to as a “sensor control unit,” an “on-body electronics” device or unit, an “on-body” device or unit, an “in body electronics” device or unit, an “in-body” device or unit, or a “sensor data communication” device or unit, to name a few. [0087] In some embodiments, SCD 102 may include a user interface (e.g., a touchscreen) and be capable of processing the analyte data and displaying the resultant calculated analyte levels to the user. In such cases, the integrated management embodiments described herein can be implemented directly by SCD 102, in whole or in part. In many embodiments, the physical form factor of SCD 102 is minimized (e.g., to minimize the appearance on the user’s body) or the sensor control device may be inaccessible to the user (e.g., if wholly implanted), or other factors may make it desirable to have a display device usable by the user to read analyte levels and interface with the sensor control device. [0088] FIG.2A is a side view of an example embodiment of SCD 102. SCD 102 can include a housing or mount 103 for sensor electronics (FIG.2B), which can be electrically coupled with an analyte sensor 101, which is configured here as an electrochemical sensor. According to some embodiments, sensor 101 can be configured to reside partially within a user’s body (e.g., through an exterior-most surface of the skin) where it can make fluid contact with a user’s bodily fluid and be used, along with the sensor electronics, to measure analyte-related data of the user. A structure for attachment 105, such as an adhesive patch, can be used to secure housing 103 to a user’s skin. Sensor 101 can extend through attachment structure 105 and project away from housing 103. Those of skill in the art will appreciate that other forms of attachment to the body and/or housing 103 may be used, in addition to or instead of adhesive, and are fully within the scope of the present disclosure. [0089] 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 analyte sensor 101 through an external surface of the user’s skin and into contact with the user’s bodily fluid. In doing so, the insertion device can also position SCD 102 onto the skin. In other embodiments, the insertion device can position sensor 101 first, and then accompanying electronics (e.g., wireless transmission circuitry and/or data processing circuitry, and the like) can be coupled with sensor 101 afterwards (e.g., inserted into a mount), either manually or with the aid of a mechanical device. Examples of insertion devices are described in Docket No. A0130.0317.WO 14890WOO1 U.S. Patent Publication Nos.2008/0009692, 2011/0319729, 2015/0018639, 2015/0025345, and 2015/0173661, 2018/0235520, all which are incorporated by reference herein in their entireties for all purposes. [0090] FIG.2B is a block diagram depicting an example embodiment of SCD 102 having analyte sensor 101 and sensor electronics 104. Sensor electronics 104 can be implemented in one or more semiconductor chips (e.g., an application specific integrated circuit (ASIC), processor or controller, memory, programmable gate array, and others). In the embodiment of FIG.1B, sensor electronics 104 includes high-level functional units, including an analog front end (AFE) 110 configured to interface in an analog manner with sensor 101 and convert analog signals to and/or from digital form (e.g., with an A/D converter), a power supply 111 configured to supply power to the components of SCD 102, processing circuitry 112, memory 114, timing circuitry 115 (e.g., such as an oscillator and phase locked loop for providing a clock or other timing to components of SCD 102), and communication circuitry 116 configured to communicate in wired and/or wireless fashion with one or more devices external to SCD 102, such as display device 120 and/or MDD 152. [0091] SCD 102 can be implemented in a highly interconnected fashion, where power supply 111 is coupled with each component shown in FIG.2B and where those components that communicate or receive data, information, or commands (e.g., AFE 110, processing circuitry 112, memory 114, timing circuitry 115, and communication circuitry 116), can be communicatively coupled with every other such component over, for example, one or more communication connections or buses 118. [0092] Processing circuitry 112 can include one or more processors, microprocessors, controllers, and/or microcontrollers, each of which can be a discrete chip or distributed amongst (and a portion of) a number of different chips. Processing circuitry 112 can include on-board memory. Processing circuitry 112 can interface with communication circuitry 116 and perform analog-to-digital conversions, encoding and decoding, digital signal processing and other functions that facilitate the conversion of data signals into a format (e.g., in-phase and quadrature) suitable for wireless or wired transmission. Processing circuitry 112 can also interface with communication circuitry 116 to perform the reverse functions necessary to receive a wireless transmission and convert it into digital data or information. Docket No. A0130.0317.WO 14890WOO1 [0093] Processing circuitry 112 can execute instructions stored in memory 114. These instructions can cause processing circuitry 112 to process raw analyte data (or pre-processed analyte data) and arrive at a final calculated analyte level. In some embodiments, instructions stored in memory 114, when executed, can cause processing circuitry 112 to process raw analyte data to determine one or more of: a calculated analyte level, an average calculated analyte level within a predetermined time window, a calculated rate-of-change of an analyte level within a predetermined time window, and/or whether a calculated analyte metric exceeds a predetermined threshold condition. These instructions can also cause processing circuitry 112 to read and act on received transmissions, to adjust the timing of timing circuitry 115, to process data or information received from other devices (e.g., calibration information, encryption or authentication information received from display device 120, and others), to perform tasks to establish and maintain communication with display device 120, to interpret voice commands from a user, to cause communication circuitry 116 to transmit, and others. In embodiments where SCD 102 includes a user interface, then the instructions can cause processing circuitry 112 to control the user interface, read user input from the user interface, cause the display of information on the user interface, format data for display, and others. The functions described here that are coded in the instructions can instead be implemented by SCD 102 with the use of a hardware or firmware design that does not rely on the execution of stored software instructions to accomplish the functions. [0094] Memory 114 can be shared by one or more of the various functional units present within SCD 102, or can be distributed amongst two or more of them (e.g., as separate memories present within different chips). Memory 114 can also be a separate chip of its own. Memory 114 is non-transitory, and can be volatile (e.g., RAM, etc.) and/or non-volatile memory (e.g., ROM, flash memory, F-RAM, etc.). [0095] Communication circuitry 116 can be implemented as one or more components (e.g., transmitter, receiver, transceiver, passive circuit, encoder, decoder, and/or other communication circuitry) that perform the functions for communications over the respective communications paths or links. Communication circuitry 116 can include or be coupled to one or more antenna for wireless communication. [0096] Power supply 111 can include one or more batteries, which can be rechargeable or single-use disposable batteries. Power management circuitry can also be included to regulate Docket No. A0130.0317.WO 14890WOO1 battery charging and monitor usage of power supply 111, boost power, perform DC conversions, and the like. [0097] Additionally, an on-skin or sensor temperature reading or measurement can be collected by an optional temperature sensor (not shown). Those readings or measurements can be communicated (either individually or as an aggregated measurement over time) from SCD 102 to another device (e.g., display device 120). The temperature reading or measurement, however, can be used in conjunction with a software routine executed by SCD 102 or display device 120 to correct or compensate the analyte measurement output to the user, instead of or in addition to, actually outputting the temperature measurement to the user. Example Embodiments of Medication Delivery Devices [0098] The medication delivery functionality of integrated management system 100 can be realized through inclusion of one or more medication delivery devices (MDDs) 152. MDD 152 can be any device configured to deliver a specific dose of medication. The MDD 152 can also include devices that transmit data regarding doses to the IMS, e.g., pen caps, even though the device itself may not deliver the medication. The MDD 152 can be configured as a portable injection device (PID) that can deliver a single dose per one injection, such as a bolus. The PID can be a basic manually-operated syringe, where the medication is either preloaded in the syringe or must be drawn into the syringe from a container prior to injection. In most embodiments, however, the PID includes electronics for interfacing with the user and performing the delivery of the medication. PIDs are often referred to as medication pens, although a pen-like appearance is not required. PIDs having user interface electronics are often referred to as smart pens. PIDs can be used to deliver one dose and then disposed of, or can be durable and used repeatedly to deliver many doses over the course of a day, week, or month. PIDs are often relied upon by users that practice a multiple daily injection (MDI) therapy regimen. [0099] The MDD can also comprise a pump and infusion set. The infusion set includes a tubular cannula that resides at least partially within the recipient’s body. The tubular cannula is in fluid communication with a pump, which can deliver medication through the cannula and into the recipient’s body in small increments repeatedly over time. The infusion set can be applied to the recipient’s body using an infusion set applicator, and the infusion set often stays implanted for 2 to 3 days or longer. A pump device includes electronics for interfacing with the user and Docket No. A0130.0317.WO 14890WOO1 for controlling the slow infusion of the medication. Both a PID and a pump can store the medication in a medication reservoir. [00100] MDD 152 can function as part of a closed-loop system (e.g., an artificial pancreas system requiring no user intervention to operate), semi-closed loop system (e.g., an insulin loop system requiring seldom user intervention to operate, such as to confirm changes in dose), or an open loop system. For example, the diabetic’s analyte level can be monitored in a repeated automatic fashion by SCD 102, and that information can be transmitted to the application and incorporated in various analytics and reports. [00101] In many embodiments, the integrated management system may 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 medication delivered by MDD 152. The type of insulin includes human insulin and synthetic insulin analogs. The insulin can also include premixed formulations. However, the integrated management embodiments set forth herein and the medication delivery capabilities of MDD 152 can be applied to other non-insulin medications. Such medications 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 embodiments can also include combination therapies. Combination therapies can include, but are not limited to, insulin and glucagon-like peptide-1 receptor agonists (GLP-1 RA), insulin and pramlintide. [00102] For ease of description of the integrated management embodiments herein, MDD 152 will often be described in the form of a PID, specifically a smart pen. However, those of skill in the art will readily understand that MDD 152 can alternatively be configured as a pen cap, a pump, or any other type of medication delivery device. [00103] In some embodiments, the IMS may include a connected pen cap. After the connected pen cap is attached to an insulin pen and is paired with the display device, every time a dose of insulin is delivered, the connected pen cap may automatically transmit dose data to the display device via e.g., BLUETOOTH®. [00104] FIG.3A is schematic diagram depicting an example embodiment of an MDD 152 configured as a PID, specifically a smart pen. MDD 152 can include a housing 154 for electronics, an injection motor, and a medication reservoir (see FIG.3B), from which medication Docket No. A0130.0317.WO 14890WOO1 can be delivered through needle 156. Housing 154 can include a removable or detachable cap or cover 157 that, when attached, can shield needle 156 when not in use, and then be detached for injection. MDD 152 can also include a user interface 158 which can be implemented as a single component (e.g., a touchscreen for outputting information to the user and receiving input from the user) or as multiple components (e.g., a touchscreen or display in combination with one or more buttons, switches, or the like). MDD 152 can also include an actuator 159 that can be moved, depressed, touched or otherwise activated to initiate delivery of the medication from an internal reservoir through needle 156 and into the recipient’s body. According to some embodiments, cap 157 and actuator 159 can also include one or more safety mechanisms to prevent removal and/or actuation to mitigate risk of a harmful medication injection. Details of these safety mechanisms and others are described in U.S. Patent Publ. No.2019/0343385 (the ’385 publication), which is hereby incorporated in its entirety for all purposes. FIG.3C is a schematic diagram of an MDD 152 and a smart button configured to fit over the actuator of the delivery pen. The MDD 152, which may be a single use medication delivery pen, may include a display 158 and a dosing selector such as a rotatable dial to select the dose. A smart button 2190 may fit over the dosing selector and actuator 159 and snap together with the pen 2180. After smart button 2190 is paired with a reader device, the smart button 2190 may track the dose, store the dosing data, and transmit it to the reader device. Medication may be delivered by pushing straight down on the smart button 2190 to inject the dose. The smart button 2190 may also contain a display that can display the recommended dose and/or the dose administered. [00105] FIG.3B is a block diagram depicting an example embodiment of MDD 152 having electronics 160, coupled with a power supply 161 and an electric injection motor 162, which in turn is coupled with power supply 161 and a medication reservoir 163. Needle 156 is shown in fluid communication with reservoir 163, and a valve (not shown) may be present between reservoir 163 and needle 156. Reservoir 163 can be permanent or can be removable and replaced with another reservoir containing the same or different medication. Electronics 160 can be implemented in one or more semiconductor chips (e.g., an application specific integrated circuit (ASIC), processor or controller, memory, programmable gate array, and others). In the embodiment of FIG.3B, electronics 160 can include high-level functional units, including processing circuitry 164, memory 165, communication circuitry 166 configured to communicate Docket No. A0130.0317.WO 14890WOO1 in wired and/or wireless fashion with one or more devices external to MDD 152 (such as display device 120), and user interface electronics 168. [00106] MDD 152 can be implemented in a highly interconnected fashion, where power supply 161 is coupled with each component shown in FIG.3B and where those components that communicate or receive data, information, or commands (e.g., processing circuitry 164, memory 165, and communication circuitry 166), can be communicatively coupled with every other such component over, for example, one or more communication connections or buses 169. [00107] Processing circuitry 164 can include one or more processors, microprocessors, controllers, and/or microcontrollers, each of which can be a discrete chip or distributed amongst (and a portion of) a number of different chips. Processing circuitry 164 can include on-board memory. Processing circuitry 164 can interface with communication circuitry 166 and perform analog-to-digital conversions, encoding and decoding, digital signal processing and other functions that facilitate the conversion of data signals into a format (e.g., in-phase and quadrature) suitable for wireless or wired transmission. Processing circuitry 164 can also interface with communication circuitry 166 to perform the reverse functions necessary to receive a wireless transmission and convert it into digital data or information. [00108] Processing circuitry 164 can execute software instructions stored in memory 165. These instructions can cause processing circuitry 164 to receive a selection or provision of a specified dose from a user (e.g., entered via user interface 158 or received from another device), process a command to deliver a specified dose (such as a signal from actuator 159), and control motor 162 to cause delivery of the specified dose. These instructions can also cause processing circuitry 164 to read and act on received transmissions, to process data or information received from other devices (e.g., calibration information, encryption or authentication information received from display device 120, and others), to perform tasks to establish and maintain communication with display device 120, to interpret voice commands from a user, to cause communication circuitry 166 to transmit, and others. In embodiments where MDD 152 includes user interface 158, then the instructions can cause processing circuitry 164 to control the user interface, read user input from the user interface (e.g., entry of a medication dose for administration or entry of confirmation of a recommended medication dose), cause the display of information on the user interface, format data for display, and others. The functions described here that are coded in the instructions can instead be implemented by MDD 152 with the use of a Docket No. A0130.0317.WO 14890WOO1 hardware or firmware design that does not rely on the execution of stored software instructions to accomplish the functions. [00109] Memory 165 can be shared by one or more of the various functional units present within MDD 152, or can be distributed amongst two or more of them (e.g., as separate memories present within different chips). Memory 165 can also be a separate chip of its own. Memory 165 is non-transitory, and can be volatile (e.g., RAM, etc.) and/or non-volatile memory (e.g., ROM, flash memory, F-RAM, etc.). [00110] Communication circuitry 166 can be implemented as one or more components (e.g., transmitter, receiver, transceiver, passive circuit, encoder, decoder, and/or other communication circuitry) that perform the functions for communications over the respective communications paths or links. Communication circuitry 166 can include or be coupled to one or more antenna for wireless communication. Details of exemplary antenna can be found in the ’385 publication, which is hereby incorporated in its entirety for all purposes. [00111] Power supply 161 can include one or more batteries, which can be rechargeable or single-use disposable batteries. Power management circuitry can also be included to regulate battery charging and monitor usage of power supply 161, boost power, perform DC conversions, and the like. [00112] 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. Example Embodiments of Display Devices [00113] Display device 120 can be configured to display information pertaining to system 100 to the user and accept or receive input from the user also pertaining to system 100. Display device 120 can display recent measured analyte levels, in any number of forms, to the user. The display device can display historical analyte levels of the user as well as other metrics that describe the user’s analyte information (e.g., time in range, ambulatory glucose profile (AGP), hypoglycemia risk levels, etc.). Display device 120 can display medication delivery information, such as historical dose information and the times and dates of administration. Display device 120 can display alarms, alerts, or other notifications pertaining to analyte levels and/or medication delivery. Docket No. A0130.0317.WO 14890WOO1 [00114] Display device 120 can be dedicated for use with system 100 (e.g., an electronic device designed and manufactured for the primary purpose of interfacing with an analyte sensor and/or a medication delivery device), as well as devices that are multifunctional, general purpose computing devices such as a handheld or portable mobile communication device (e.g., a smartphone or tablet), or a laptop, personal computer, or other computing device. Display device 120 can be configured as a mobile smart wearable electronics assembly, such as a smart glass or smart glasses, or a smart watch or wristband. Display devices, and variations thereof, can be referred to as “reader devices,” “readers,” “handheld electronics” (or handhelds), “portable data processing” devices or units, “information receivers,” “receiver” devices or units (or simply receivers), “relay” devices or units, or “remote” devices or units, to name a few. [00115] FIG.4A is a schematic view depicting an example embodiment of display device 120. Here, display device 120 includes a user interface 121 and a housing 124 in which display device electronics 130 (FIG.4B) are held. User interface 121 can be implemented as a single component (e.g., a touchscreen 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, user interface 121 includes a touchscreen display 122 (configured to display information and graphics and accept user input by touch) and an input button 123, both of which are coupled with housing 124. [00116] Display device 120 can have software stored thereon (e.g., by the manufacturer or downloaded by the user in the form of one or more “apps” or other software packages) that interface with SCD 102, MDD 152, and/or the user. In addition, or alternatively, the user interface can be affected by a web page displayed on a browser or other internet interfacing software executable on display device 120. [00117] FIG.4B is a block diagram of an example embodiment of a display device 120 with display device electronics 130. Here, display device 120 includes user interface 121 including display 122 and an input component 123 (e.g., a button, actuator, touch sensitive switch, capacitive switch, pressure sensitive switch, jog wheel, microphone, speaker, or the like), processing circuitry 131, memory 125, communication circuitry 126 configured to communicate to and/or from one or more other devices external to display device 120), a power supply 127, and timing circuitry 128 (e.g., such as an oscillator and phase locked loop for providing a clock or other timing to components of SCD 102). Each of the aforementioned components can be Docket No. A0130.0317.WO 14890WOO1 implemented as one or more different devices or can be combined into a multifunctional device (e.g., integration of processing circuitry 131, memory 125, and communication circuitry 126 on a single semiconductor chip). Display device 120 can be implemented in a highly interconnected fashion, where power supply 127 is coupled with each component shown in FIG.4B and where those components that communicate 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 with every other such component over, for example, one or more communication connections or buses 129. FIG.4B is an abbreviated representation of the typical hardware and functionality that resides within a display device and those of ordinary skill in the art will readily recognize that other hardware and functionality (e.g., codecs, drivers, glue logic) can also be included. [00118] Processing circuitry 131 can include one or more processors, microprocessors, controllers, and/or microcontrollers, each of which can be a discrete chip or distributed amongst (and a portion of) a number of different chips. Processing circuitry 131 can include on-board memory. Processing circuitry 131 can interface with communication circuitry 126 and perform analog-to-digital conversions, encoding and decoding, digital signal processing and other functions that facilitate the conversion of data signals into a format (e.g., in-phase and quadrature) suitable for wireless or wired transmission. Processing circuitry 131 can also interface with communication circuitry 126 to perform the reverse functions necessary to receive a wireless transmission and convert it into digital data or information. [00119] Processing circuitry 131 can execute software instructions stored in memory 125. These instructions can cause processing circuitry 131 to process raw analyte data (or pre- processed analyte data) and arrive at a corresponding analyte level suitable for display to the user. These instructions can cause processing circuitry 131 to read, process, and/or store a dose instruction from the user, and cause the dose instruction to be communicated to MDD 152. These instructions can cause processing circuitry 131 to execute user interface software adapted to present an interactive group of graphical user interface screens to the user for the purposes of configuring system parameters (e.g., alarm thresholds, notification settings, display preferences, and the like), presenting current and historical analyte level information to the user, presenting current and historical medication delivery information to the user, collecting other non-analyte information from the user (e.g., information about meals consumed, activities performed, Docket No. A0130.0317.WO 14890WOO1 medication administered, and the like), and presenting notifications and alarms to the user. These instructions can also cause processing circuitry 131 to cause communication circuitry 126 to transmit, can cause processing circuitry 131 to read and act on received transmissions, to read input from user interface 121 (e.g., entry of a medication dose to be administered or confirmation of a recommended medication dose), to display data or information on user interface 121, to adjust the timing of timing circuitry 128, to process data or information received from other devices (e.g., analyte data, calibration information, encryption or authentication information received from SCD 102, and others), to perform tasks to establish and maintain communication with SCD 102, to interpret voice commands from a user, and others. The functions described here that are coded in the instructions can instead be implemented by display device 120 with the use of a hardware or firmware design that does not rely on the execution of stored software instructions to accomplish the functions. [00120] Memory 125 can be shared by one or more of the various functional units present within display device 120, or can be distributed amongst two or more of them (e.g., as separate memories present within different chips). Memory 125 can also be a separate chip of its own. Memory 125 is non-transitory, and can be volatile (e.g., RAM, etc.) and/or non-volatile memory (e.g., ROM, flash memory, F-RAM, etc.). [00121] Communication circuitry 126 can be implemented as one or more components (e.g., transmitter, receiver, transceiver, passive circuit, encoder, decoder, and/or other communication circuitry) that perform the functions for communications over the respective communications paths or links. Communication circuitry 126 can include or be coupled to one or more antenna for wireless communication. [00122] Power supply 127 can include one or more batteries, which can be rechargeable or single-use disposable batteries. Power management circuitry can also be included to regulate battery charging and monitor usage of power supply 127, boost power, perform DC conversions, and the like. [00123] Display device 120 can also include one or more data communication ports (not shown) for wired data communication 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. Docket No. A0130.0317.WO 14890WOO1 [00124] Display device 120 can display the measured analyte data received from SCD 102 and can also be configured to output alarms, alert notifications, glucose values, etc., which may be visual, audible, tactile, or any combination thereof. In some embodiments, SCD 102 and/or MDD 152 can also be configured to output alarms, or alert notifications in visible, audible, tactile forms or combination thereof. Further details and other display embodiments can be found in, e.g., U.S. Patent Publ. No.2011/0193704, which is incorporated herein by reference in its entirety for all purposes. Example Embodiments Related to Integrated Management [00125] The following example embodiments relate to an integrated management system (IMS) that will, in many embodiments, 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 the user on the same single electronic device. In other embodiments, the IMS can be stored and executed on one device, and presented to the user on a different electronic device. For example, the IMS can be stored and executed on trusted computer system 180 and presented to the user by way of a webpage displayed through an internet browser executed on display device 120. [00126] Thus, there are many different embodiments pertaining to the number and type of electronic devices that are used in storing, executing, and presenting the IMS or portions thereof to a user. With respect to presentation to the user, the device that is configured to implement this capability will be referred to herein as a user interface device (UID) 200. FIG.5 is a block diagram depicting an example embodiment of UID 200. In this embodiment, UID 200 includes a housing 201 that is coupled with a user interface 202. The user interface 202 is capable of outputting information to the user and receiving input or information from the user. In some embodiments, the user interface 202 is a touchscreen. As shown here, the user interface 202 includes a display 204, that may be a touchscreen, and an input component 206 (e.g., a button, actuator, touch sensitive switch, capacitive switch, pressure sensitive switch, jog wheel, microphone, touch pad, soft keys, keyboard, or the like). [00127] Many of the devices described herein can be implemented as UID 200. For example, display device 120 will, in many embodiments, be used as UID 200. In some embodiments, MDD 152 can be implemented as UID 200. In embodiments where SCD 102 includes a user Docket No. A0130.0317.WO 14890WOO1 interface, then SCD 102 can be implemented as UID 200. Computer system 170 can also be implemented as UID 200. Example Embodiments of the User Experience of the Integrated Management System [00128] As seen in FIG.6A, in an exemplary method 300 of a user experience, a user can check an analyte level, such as a glucose level, in step 302. As described previously, a user may scan an SCD 102, or otherwise effect the transfer of an analyte level or data indicative of an analyte level to the display device 120. In step 304, the user administers the medication (e.g., insulin) from a connected medication delivery device 152. The medication delivery device 152 may be a smart, connected insulin pen, a connected pen cap, or an automated insulin delivery (AID) device in a closed loop system, as described previously. In step 306, the user transfers the dosage information from the medication delivery device 152 to the display device 120. The transfer can be accomplished by methods known in the art. For example, the display device 120 (e.g., a smart phone) may scan the connected medication delivery device 152 and the information may be transferred via NFC. In some embodiments, upon a successful scan of the insulin pen, the monitoring application may display a confirmation screen. Alternatively, the dosage information may be transferred automatically without any further action required from the user. For instance, no scan may be necessary, and the dose information may be transferred automatically via BLUETOOTH® or another wireless communication protocol. For example, in the case of a connected pen cap, a connected insulin pen, or an AID device, the data may automatically transfer to the display device after the detection of an administered dose. The transfer of the medication information can be referred to in many ways, including scanning, transferring, downloading, uploading, exporting, importing, connecting, syncing, pairing, and other equivalent terminology. The data may also be automatically transferred via wireless communication such as BLUETOOTH®. The data being transferred can include data relating to medication (e.g., insulin) injections, shots, events, notes, log entries, or other equivalent terminology. The data may be referred to as insulin data, insulin records, insulin logs, insulin doses, or other equivalent terminology. After the dose information has been transferred, optionally, a notification may appear on the display device, e.g., a lockscreen or banner notification, which includes a message that a logbook or other report or application has been updated and may also include an amount of medication delivered and a delivery time. In step 308, the user and others (e.g., caretakers, HCPs) may then view the combined history, which Docket No. A0130.0317.WO 14890WOO1 may include the analyte levels and medication dosages, in a variety of displays and reports to visualize and assist the user in treating their diabetes. [00129] The system may display a notification on the reader or display device 120 if a sufficient amount of data has been received to generate a report or a plurality of reports. In some embodiments, as seen in method 820 in FIG.6B, the system may receive a first type of data that includes data indicative of an analyte level (step 822). The first type of data may be received from a SCD 102. The system may also receive a second type of data that includes medication dosing data (step 824). The second type of data may be received from the MDD 152. The medication dosing data may include dosage amounts and corresponding administration times of the dosage amounts. [00130] The system may then determine, in step 826, if the second type of data received satisfies a minimum dosing data report condition for inclusion into a report. In some embodiments, the minimum dosing data report condition may be a sufficient amount of second type of data to generate a weekly report, alternatively to generate a daily report. In some embodiments, the minimum dosing data report condition may be if the second type of data includes dosing data for at least 1 day, alternatively at least 2 days, alternatively at least 3 days, alternatively at least one week, alternatively at least two weeks, alternatively at least one month has been received. If the second type of data received does not satisfy the minimum dosing data report condition, then the method returns to step 824 and the system receives additional second type of data. [00131] If the second type of data received does satisfy the minimum dosing data report condition, the system generates the report (step 828), which includes at least a portion of the second type of data, metrics based on at least a portion of the second type of data, recommendations based on at least a portion of the second type of data, or summaries of at least a portion of the second type of data. In some embodiments, the report additionally contains portions or sections based on the first type of data. As described elsewhere in the application, the portions or sections based on the first type of data may include a current analyte level, a trend arrow, an analyte trace, recommendations, patterns, hyper- and hypo-risks, and other analyte metrics (including time in range and time out of range). [00132] In step 827, the system displays a message or notification regarding the report. In some embodiments, the message may inform the user that the report is available. The message Docket No. A0130.0317.WO 14890WOO1 may also provide a link to the report. The message may be displayed in a modal window or as a banner. [00133] If the user runs into an issue or has problems transferring the data from the medication delivery device 152 to the display or reader device 120, the system may assist the user by displaying helpful tips and/or an animation demonstrating how to properly scan the MDD 152. In some embodiments, as seen in method 830 in FIG.6C, the system may receive a first type of data that includes data indicative of an analyte level (step 832). The first type of data may be received from a SCD 102. The system may also receive a second type of data that includes error data associated with an MDD 152 (step 834). The second type of data may be received from the MDD 152. [00134] The system may display information associated with data indicative of the analyte level (step 836) on reader or display device 120. As described elsewhere in the application, the data indicative of the analyte level may include a current analyte level, a trend arrow, an analyte trace, recommendations, patterns, hyper- and hypo-risks, and other analyte metrics (including time in range and time out of range). [00135] The system may also display a message on reader or display device 120 based on the error data received in step 838. In some embodiments, the error data may include data indicative of a number of failed scans of the MDD 152. In some embodiments, the message may be displayed if the number of failed scans exceeds a threshold value. The message may be a tip related to scanning or how to scan the MDD 152 (e.g., helpful 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. [00136] The system may also remind the user to transfer medication dosing data from the MDD 152 to the system if no transfer has been made for a period of time that is greater than a threshold value. In some embodiments, as seen in method 840 in FIG.6D, the system may receive a first type of data that includes data indicative of an analyte level (step 842). The system may also receive a second type of data that includes medication dosing data (step 844). The medication dosing data may include dosage amounts and corresponding administration times of the dosage amounts. Docket No. A0130.0317.WO 14890WOO1 [00137] The system may then determine, in step 846, if a time period elapsed since the second type of data was received exceeds a threshold value. If the time period elapsed since the second type of data was received does not exceed the threshold value, then the method returns to step 844 and receives additional second type of data. The threshold value may be 6 hours, alternatively 12 hours, alternatively 24 hours, alternatively 48 hours, alternatively 72 hours. [00138] If the time period elapsed since the second type of data was received exceeds the threshold value, then in step 848, the system displays a message or notification prompting the user to transfer the second type of data. 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 transfer the medication dosing data. [00139] In order to be able to transfer data from the medication delivery device 152 to the IMS, the medication delivery device 152 must first be added to the IMS. FIG.7 describes an exemplary method 320 for adding a medication delivery device 152 to the IMS and managing the connected medication delivery device 152. In method 310, a user can add an insulin pen by selecting “insulin pens” from a menu, such as a pull down menu seen in FIG.30Y-2. As seen in GUI 322 of FIG.20A, a “Get Started” screen may contain a cartoon depiction of the medication delivery device 152 communicating with a display device 120, and also list different tasks or capabilities of the IMS after the medication delivery device 152 is connected to the IMS. These include connecting a compatible smart pen to record insulin doses, reviewing and learning from past doses, and sharing reports with the user’s healthcare team. After selecting “get started,” as seen in GUI 324 of FIG.20A, the insulin pen settings may be opened, and the user may be prompted to select the medication delivery device 152 that they wish to connect in step 312. The medication delivery device 152, e.g., an insulin pen, may be listed by their brand names. After the user selects the appropriate medication delivery device and selects “next,” as seen in GUI 326 in FIG.20B, a graphic or an animation may be presented that illustrates how to scan the medication delivery device 152 (e.g., insulin pen) with the display device 120 (e.g., smart phone). Additionally, GUI 326 may also contain text that instructs to scan by holding the insulin pen display flat against the back of the phone. The GUI 326 may also provide text that indicates that the user may need to move the insulin pen around slowly to find the correct spot to affect a connection/communication between the insulin pen and the phone. A link may also be provided to a user manual for the insulin pen that contains more information about how to connect the Docket No. A0130.0317.WO 14890WOO1 insulin pen to the phone. In some embodiments, if the user has already added this insulin pen to the monitoring application, the monitoring application may display a modal window or pop-up window informing the user that the scanned insulin pen is already an added insulin pen when scanned during insulin pen setup. After a successful connection has been affected, a GUI 328 as seen in FIG.20B may appear, which indicates that a new medication delivery device 152 has been added to the IMS. The name of the newly added medication 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 medication delivery device 152. Selectable options with different colors 332 may appear on GUI 330, as seen in FIG.20C. The color option of the insulin pens may be based on the model of the insulin pen scanned during setup. After selecting “next,” in GUI 334 in FIG.20C, the user may be prompted to select the type of medication contained in the newly connected medication delivery device 152. Where the medication delivery device 152 is an insulin pen, in step 316, the user may be prompted to select between different types of insulin, e.g., rapid-acting insulin, long-acting insulin, or other, from a list 336. After selecting “next,” in step 318, the user may then be prompted to select the brand of the selected type of inulin in GUI 338 of FIG.20D. A list 340 of available brands may be provided. Different lists of brand names may be provided for different types of insulin. For example, a first list of brand names may be selected when the user selects rapid-acting insulin. A second list may be selected when the user selects long-acting insulin. And a third list of brand names may be displayed when the user selects “other.” Alternatively, the user may be able to add a new brand that is not included in the list provided. After selecting “next,” in GUI 342 of FIG.20D, the user may see an indication that the setup of the new medication delivery device 152 is complete. The GUI 342 may also include a reminder to scan the connected medication delivery device 152 to transfer insulin doses to the software of the IMS. The GUI 342 may also include an animation that illustrates how to scan the medication delivery device 152 (e.g., insulin pen) with the display device 120 (e.g., smart phone). Additionally, the GUI may also contain text that instructs to scan by holding the insulin pen display flat against the back of the phone. The GUI may also provide text that indicates that the user may need to move the insulin pen around slowly to find the correct spot to affect a connection/communication between the insulin pen and the phone. Docket No. A0130.0317.WO 14890WOO1 [00140] The monitoring application may allow a user to scan a sensor control device anytime during the insulin pen setup. [00141] Additional medication delivery devices may be connected in the same manner described above. The additional medication delivery devices may be assigned a different color or other distinguishing feature or name from the previously connected medication delivery devices. For example, a medication delivery device 152 that delivers rapid acting insulin may be assigned a blue pen color, while a medication delivery device 152 that delivers long-acting insulin may be assigned a different color, e.g., red, silver, or black. Additional medication delivery devices may be added under the insulin pens menu, by selecting an option to add another medication delivery device, e.g., a plus symbol labeled “add another pen” (see 356 of FIG.20E). [00142] If a new insulin pen is scanned, even if the monitoring application is not displaying a GUI associated with setup, the monitoring application may prompt the user to add the newly scanned insulin pen as detailed above. The monitoring application may only collect and store data from insulin pens that have been added to the monitoring application. The monitoring application may have the capability to obtain all new insulin pen doses from the added insulin pen. The monitoring application may determine the timestamp of insulin pen doses using the timestamp as provided by the insulin pen 152. [00143] The user may select an option to “manage your own insulin pen connection” under the insulin pens menu. As seen in GUIs 350 and 368 of FIG.20E, the user may be presented with an Insulin Pen menu GUI 350 that lists the connected medication delivery devices 152, along with descriptions indicating the name of the insulin pen added, the type and/or brand name of insulin delivered 358 by the medication delivery device 152, a graphic of the insulin pen 352, and details of the last scan 360, which may include the last timestamp associated with when the insulin pen was 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 may be added. In some embodiments, the maximum number of insulin pens that may be added may be 8, alternatively 9, alternatively 10, alternatively 12, alternatively 15 insulin pens. If no insulin pens are added, the application may display a summary of the benefits of insulin pens. As described previously with respect to GUI 326, if a user selects an information i icon, a GUI 364a, b, as seen Docket No. A0130.0317.WO 14890WOO1 in FIG.20F, may appear that includes information about how to transfer insulin logs and dosing information. The GUI 364a, b may include an animation of how to scan the medication delivery device 152 with the smart phone. Different GUIs may appear for instructing how to scan on an IOS system 364a and an Android system 364b. Additionally, the GUI 364a,b may also contain text that instructs to scan by holding the insulin pen display flat against the back of the phone. The GUI 364a,b may also provide text that indicates that the user may need to move the insulin pen around slowly to find the correct spot to result in a connection/communication between the insulin pen and the phone. The insulin pen menu GUI 350 may contain a list of all added insulin pens, with all of the relevant information for each added insulin pen discussed above. [00144] In some embodiments, the medication delivery device 152 may be a pen cap, such as Dialoq®, that may transfer the dose data wirelessly via BLUETOOTH®. The medication delivery device 152 may need to be paired with the monitoring application using BLUETOOTH® rather than NFC. The monitoring application may remind the user to make sure that BLUETOOTH® is enabled on the display device 120. The monitoring application may display a GUI that prompts the user the enter and/or confirm a code on the medication delivery device 152. The GUI may also include a picture, diagram, or animation to show where the code is located on the medication delivery device 152. After the code is entered, the monitoring application may display a GUI that contains instructions to press and release a button on the medication delivery device 152 to pair the device with the display device 120. The instructions may include a textual description, diagram, picture, or animation to assist the user with the pairing. A window may appear on the display device 120 indicating that the medication delivery device 152 wants to pair with the display device 120. The user may need to select “Pair” before the pairing is completed. After the medication delivery device has been paired with the display device 120, a GUI that displays a confirmation that the pairing and/or setup is complete may be displayed. [00145] Once the medication delivery device 152 has been connected to the monitoring software on the display device 120, the dosing information may be downloaded or otherwise transferred (e.g., via NFC or BLUETOOTH®) from the medication delivery device 120 to the software. As seen in FIGS.21A-21C, in GUIs 390 and 391, the monitoring software may indicate that it can accept a download from a connected medication delivery device 152 (e.g., there may be a message indicating it is “ready to scan” in e.g., a banner). After the user has Docket No. A0130.0317.WO 14890WOO1 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(s) has appeared in a logbook. For example, the window 394 in GUIs 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 was scanned 396, the type of insulin that was administered 398, the brand of the insulin that was administered, and also include a graphical representation or image of the insulin pen (including color). 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. Moreover, after the first time that the medication delivery device 152 is scanned, a GUI 400, as seen in FIG.21A, may appear that allows the user to select a default selection for the insulin type, which will be used as the default the next time the user scans the insulin pen. After the user selects and saves the new insulin brand for the insulin pen, a pop-up window 403 may appear that informs the user that their insulin type has been updated and if they need to change it, then it can be changed in Insulin Pen Settings. [00146] As seen in FIG.21B, a home screen 410 may include a button or link 412 to select to scan a medication delivery device 152. The home screen 410 may also include an analyte profile, a time in range statistic, a last reading analyte level, an average analyte level, a graph of analyte readings for a time period (e.g., the current day), and an indication of the current sensor life. The home screen 410 may also include icons (e.g., syringe icons) 414 along the graph of the analyte readings that indicate when various medications were administered. The icons 414 may be positioned along the graph of analyte readings to correspond with/indicate the time that the medication was administered. In some embodiments, users may view and edit insulin notes by tapping the syringe icon 414 in the home screen 410. The user may tap the syringe icon to view the dose and then further tap a pencil icon to edit the entry, if needed. In some embodiments, a syringe icon with a notepad may indicate a dosage in which additional comments and notes have been added. In some embodiments, a syringe icon with an apple icon may indicate a dosage in which a food note has been added. In some embodiments, icons of syringes with no other annotations may mark a dose that was transferred automatically from a connected medication delivery device 152. Icons indicating food (e.g., an apple), exercise (e.g., a runner), or comments Docket No. A0130.0317.WO 14890WOO1 (e.g., a notepad) may also be indicated along or above the graph of the analyte reading, placed along the timeline (x-axis) according to when the food was consumed or the note was added. [00147] A logbook GUI 416, as seen in FIG.21B, may also be accessed from the menu. The logbook GUI 416 may contain a listing of various events logged along with the time that the event occurred, including doses of medication administered. For the entries imported from the medication delivery device 152, a syringe icon may appear next to the amount of medication administered (e.g., in units) along with the timestamp associated with the insulin pen dose. Instances in which the medication delivery device 152 was primed may also be listed in the logbook. Priming doses (or “prime”) refers to a medication (e.g., insulin) shot to clear air from the needle tip. Priming doses may also be referred to as an airshot, flow check, squirt, or other equivalent term. Notes that have been manually added may also be included in the logbook. [00148] The monitoring application may allow a user to edit the notes that are associated with a particular medication dosing event. If the user wants to edit details about the insulin dose, the user may tap the line entry in the logbook GUI 416, which links to a logbook detail GUI 430, as seen in FIG.21C. The analyte graph on the logbook detail GUI 430 may include a vertical line or other highlight to indicate the dose being viewed. The logbook detail GUI 430, 462 may include a description of the dose administered, including the insulin type and insulin brand associated with the insulin pen dose, the name of the insulin pen (as existed during the download associated with the pen dose), the dose or a prime designation associated with the insulin pend dose, the insulin dose amount with 0.5 units resolution, and the time associated with the dose. If the user wants to add and/or edit the details about the selected insulin dose, the user may tap the edit (pencil) icon 444, which links to the Edit Note GUI 450, in which the user can edit the information associated with various fields. The user may include entries regarding carbohydrates, exercise, or a custom note. The Edit Note GUI 450 includes a banner that prominently indicates the dose amount and the date and time taken. It may also include various fields, such as, the type of dose (insulin administered or prime) 452, brand of insulin, number of units, name of the delivery device, food 454, exercise 456, and comments 458. The user may edit the type of insulin delivered and/or insulin brand by, e.g., tapping a drop-down caret and selecting a new insulin type or insulin brand. The user may edit the dose from a therapy dose to a flow check (or prime) dose by, e.g., tapping the drop-down caret icon to select the prime/flow check option. In some embodiments, after the user indicates that it is a prime dose, the banner at Docket No. A0130.0317.WO 14890WOO1 the top of the Edit Note screen will indicate that it is a prime dose, as seen in GUI 460 of FIG. 21C. The logbook detail GUI 462 may also include the time of the dose and the brand. In some embodiments, the monitoring application may not allow the user to edit the dose amount of the insulin dose (e.g., the dose amount field may not be editable). In some embodiments, the monitoring application may not allow the user to delete an insulin dose. [00149] The user may view and edit recent insulin notes by tapping a syringe icon on a home screen. Transferred insulin doses may also be viewed in the Logbook. From the main menu, the Logbook may be selected or tapped to view. The Logbook may contain notes for each transferred insulin dose from the insulin pen as well as any additional notes that the user has added. The user may edit a note by selecting an individual log entry. [00150] If there is an error, the monitoring application may request that the user confirm details of the dose administered. The details may include the dose amount, the type of medication, and the time it was delivered. As seen in FIGS.23A-23C, window 1052 in GUI 1050 or window 1062 in GUI 1060 may appear to prompt the user to confirm details regarding the newly transferred dose(s) if an error was detected in the transferred dose data. Alternatively, errors may be noted in the Logbook GUI 1070 and/or Logbook Details GUIs 1080 and 1081. In some embodiments the Logbook GUI 1070 and/or Logbook Details GUIs 1080 and 1081 may include an error indicator associated with certain dosages. The error indicator may be a missing dosage amount 1072 and/or a different syringe icon (e.g., a syringe with an exclamation point or a question mark near it) 1074. The user can edit the dose entry with the error by tapping on the edit (pencil) icon 444, which can link to Edit Note GUI 1090 or 1091, as seen in FIG.23C, where individual fields can be edited as needed. The individual fields may include food, amount of insulin (e.g., rapid-acting or long-acting) administered, brand of insulin, whether it is a dose or prime injection, exercise, and comments. As seen in GUI 1071, the Logbook GUI may include notes associated with the doses. The Logbook GUI may also include an indication that the dose was a prime dose 1075. [00151] As seen in GUI 470 of FIG.21D, the monitoring application may also prompt the user to learn more about a new feature of the monitoring application with a pop-up window 472. The prompt may inform the user of a new feature available by connecting a medication delivery device 152 (e.g., a smart insulin pen) and letting the application keep track of the user’s insulin Docket No. A0130.0317.WO 14890WOO1 doses. A similar window may also pop up when an update is available for the monitoring application. [00152] The monitoring application may also allow the user to customize the name of the connected medication delivery device 152. The custom pen name may have an upper limit of about 48 characters. As seen in FIG.22A, the user may navigate to the insulin settings GUI 480, where the user may tap on or select the “name” field 482, which will open up the Name GUI window 486. The user may tap on or select the “new name” field 488 and proceed to type in the new chosen name for the device. In FIG.22A, the user entered “Home Pen” as their custom name for that device. After the user selects “save,” the new name will be displayed in the “current name” field 490 in updated GUI 492. After the user changes any details of an 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 may retain the previous information associated with the older insulin pen doses after the changes have been saved. [00153] As seen in FIG.22B, the user may see a summary of the information relating to an insulin pen that has been added in the About GUI 2250. The About GUI 2250 may list the model name, the manufacturer, the serial number, and the software revision or version of the insulin pen. The About GUI 2250 may also include a link to forget this pen 2252, which would unpair the insulin pen from the monitoring application. If the user selects the forget this pen link 2252, a modal window 2262, as seen in GUI 2260, may appear that informs the user that this insulin pen will be removed from the user’s application and the user will not be able to transfer insulin doses unless they reconnect the insulin pen. The message in the modal window 2262 may also inform the user that removing their insulin pen will not affect any insulin logs in the application. The modal window 2262 may also contain a link 2264 asking for the user to confirm that they want to forget the insulin pen. If the user selects to forget an added insulin pen, the monitoring application may still retain the previously transferred insulin doses. The monitoring application may also allow the user to add an insulin pen that was previously added. [00154] The monitoring application may store and display doses for each day in the period totaling about 60 days, alternatively about 90 days, alternatively about 120 days, inclusive of the current day. Thus, the monitoring application may support showing insulin pen doses for each day in the period beginning about 59 day, alternatively about 89 days, alternatively about 19 days before the current day and ending on the current day. The monitoring application may not Docket No. A0130.0317.WO 14890WOO1 store any doses with a dose unit value greater than an upper limit, e.g., about 250 units, alternatively about 275 units, alternatively about 300 units, alternatively about 325 units, alternatively about 350 units. Insights and Alerts Missed Meal Dose Hints [00155] The monitoring application may display an alert, hint, or prompt if a dose appears to have been missed. In some embodiments, the dose data is automatically transferred via BLUETOOTH® to the monitoring application. For example, based on glucose levels rising and no dose logged within a period of time, e.g., 1 hour, alternatively 2 hours, alternatively 3 hours, the monitoring application may display an alert that asks the user – “Did you miss a meal dose?” Furthermore, the alert may indicate that the user’s glucose is rising and the last logged dose was X hours ago. The alert may also suggest that the user sync the medication delivery device 152 to update the dosing data. The alert may also suggest that, if the user did miss a dose, that the user should follow their HCP’s advice on what to do. In some embodiments, where the alert relates to a specific meal, the alert may ask if the user missed their [breakfast/lunch/dinner] dose and then indicate that the user usually takes this dose before X:XX (e.g., the user usually takes their lunch dose before 1:30 pm). [00156] The user may set the conditions under which the missed meal dose alerts or hints are given in order to minimize the number of alerts popping up on their device. For each of a breakfast, lunch, dinner, and long-acting dose, the user may specify that a missed dose hint should only be displayed after a certain time of day. For example, the user may set the breakfast dose hint to be displayed after 10:00 am, the lunch dose to be displayed after 1:30 pm, and the dinner dose to be displayed after 8:00 pm if no dose was detected during a period of time before the indicated time. [00157] As seen in FIG.25, in exemplary method 1900, beginning with step 1902, the system or application may receive analyte data from a sensor control device 102. In step 1904, the system may receive insulin data of the subject (e.g., from MDD 152). For example, the system or application can automatically receive the insulin data wirelessly, e.g., via BLUETOOTH®, from a connected pen, connected pen cap, or other medication delivery device 152, without requesting the data. In other embodiments, the system or application can check for the latest insulin dose data by requesting delivery information from different sources, including, but not Docket No. A0130.0317.WO 14890WOO1 limited to, the MDD 152, the MDD-associated application, or the interface that stores the latest insulin delivery information (such as the MDD application web server), or by checking the memory of the various applications for the latest insulin delivery information. [00158] In step 1906, the system or application may determine if a meal has been consumed. This determination may be made by analyzing the received analyte data and determining if the analyte levels are rising above a high threshold or if a rate of change of the analyte level is greater than a minimum rate of change threshold. Meal dose detection is described in greater detail in U.S. Publ. No.2021/0030323, U.S. Publ. No.2021/0050085, and U.S. Application Serial No.17/591,229, all of which are hereby expressly incorporated by reference in their entirety for all purposes. The high threshold analyte level may be 175 mg/dL, alternatively 180 mg/dL, alternatively 180 mg/dL, alternatively 190 mg/dL, alternatively 200 mg/dL, alternatively 210 mg/dL, alternatively 220 mg/dL, alternatively 230 mg/dL, alternatively 240 mg/dL, alternatively 250 mg/dL, alternatively 260 mg/dL, alternatively 270 mg/dL. The high threshold analyte level may be set by the user. If the system determines that a meal has not been consumed, then the system returns to step 1902 and receives additional analyte data. [00159] If the system or application determines that a meal has been consumed, in step 1908, the system may analyze the insulin dose data received to determine if an insulin dose has been recorded or received for a period of time. The period of time may be about 1 hour, alternatively about 2 hours, alternatively about 3 hours. The period of time may optionally be set by the user instead of a default time set by the system. If an insulin dose has been recorded in the period of time, then the system determines that there has not been a missed dose and the system returns to step 1904 and receives additional insulin dose data. [00160] In some embodiments, the period of time may be set for each meal by setting a time at which the meal dose should have been taken by the user. The system may also check to see if an insulin dose has been recorded or received before a set time for each meal. For example, if a breakfast dose was not recorded or received by 10:30 am, the system may determine that the user had missed their breakfast dose. Similarly, a lunchtime dose may have a time of 2:30 pm if the user will normally have taken a lunch dose by then. And a dinner dose may have a time of 7:30 pm if the user will normally have taken a dinner dose by that time. These times may be set by the user to align with their personal eating habits. Docket No. A0130.0317.WO 14890WOO1 [00161] If the system or application determines that an insulin dose has not been recorded or received for the time period or by a set time for a particular meal, in step 1910, the system or application may display an alert interface relating to the missed meal dose. In some embodiments, the text of the alert interface may be customizable by the user. Correction Dose Hints [00162] The monitoring application may display an alert, hint, or prompt to the user to consider a correction dose if a period of time has passed since their last insulin dose and their glucose levels are still elevated. In some embodiments, the dose data is automatically transferred via BLUETOOTH® to the monitoring application. The user may set the conditions under which the correction dose alerts or hints are given in order to minimize the number of alerts popping up on their device. The user may configure the alerts to only be displayed when their glucose levels are above a high threshold, e.g., above about 250 mg/dL, and the period of time since the last insulin dose is longer than a minimum time threshold, e.g., about 2 hours. [00163] The user may also customize the message that appears in the hint. For instance, the message may indicate that the dose they took X hours (e.g., 2 hours) ago isn’t bringing down their glucose enough and that now is a good time to take an additional X units of insulin or take a walk around the park. A default message may be to follow their HCP’s recommendations for correcting high glucose with treatment or exercise. [00164] As seen in FIG.26, in exemplary method 1920, beginning with step 1922, the system or application may receive analyte data from a sensor control device 102. In step 1924, the system or application may receive insulin data of the subject (e.g., from MDD 152). For example, the system or application can automatically receive the insulin data wirelessly, e.g., via BLUETOOTH®, from a connected pen, connected pen cap, or other medication delivery device 152, without requesting the data. In other embodiments, the system or application can check for the latest insulin dose data by requesting delivery information from different sources, including, but not limited to, the MDD 152, the MDD-associated application, or the interface that stores the latest insulin delivery information (such as the MDD application web server), or by checking the memory of the various applications for the latest insulin delivery information. [00165] In step 1926, the system or application may determine if a received analyte level is above a high threshold, which may indicate that the user’s glucose is outside of a target range. The high threshold analyte level may be 175 mg/dL, alternatively 180 mg/dL, alternatively 180 Docket No. A0130.0317.WO 14890WOO1 mg/dL, alternatively 190 mg/dL, alternatively 200 mg/dL, alternatively 210 mg/dL, alternatively 220 mg/dL, alternatively 230 mg/dL, alternatively 240 mg/dL, alternatively 250 mg/dL, alternatively 260 mg/dL, alternatively 270 mg/dL. The high threshold analyte level may be set by the user. If the system determines that an analyte level is not above a high threshold, then the system returns to step 1922 and receives additional analyte data. [00166] If the system or application determines that an analyte level is above a high threshold, in step 1928, the system or application may analyze the insulin dose data received to determine if a period of time has passed since an insulin dose has been recorded or received. The period of time may be about 2 hours, alternatively about 2.5 hours, alternatively about 3 hours. The period of time may optionally be set by the user instead of a default time set by the system. If the period of time since the last insulin dose has been recorded has not passed yet, then the system returns to step 1924 and receives additional insulin dose data. [00167] If the system or application determines that the period of time has passed since a last insulin dose, in step 1930, the system or application may display an alert interface relating to a correction dose. In some embodiments, the text of the alert interface may be customizable by the user. Congratulatory Message [00168] The monitoring application may also display congratulatory alerts or messages when an insulin dose resulted in glucose levels going back in a target range within a designated time period. For example, the alert or window may say “You got a glucose win! You got back in range 2 hours after your last insulin dose.” The user may have the option to add a note (either by typing or talk to text) with details about what they did that may have helped them reach their target range. [00169] The user may set the conditions under which the alert or window is displayed by setting a maximum glucose level and a time limit to return to the target range. For example, the user may set the target range as under 180 mg/dL and the time after the dose to get to the target as 2 hours. [00170] As seen in FIG.27, in exemplary method 1940, beginning with step 1942, the system or application may receive analyte data from a sensor control device 102. In step 1944, the system may receive insulin data of the subject (e.g., from MDD 152). For example, the system can automatically receive the insulin data wirelessly, e.g., via BLUETOOTH®, from a connected Docket No. A0130.0317.WO 14890WOO1 pen, connected pen cap, or other medication delivery device 152, without requesting the data. In other embodiments, the system or application can check for the latest insulin dose data by requesting delivery information from different sources, including, but not limited to, the MDD 152, the MDD-associated application, or the interface that stores the latest insulin delivery information (such as the MDD application web server), or by checking the memory of the various applications for the latest insulin delivery information. [00171] In step 1946, the system or application may determine if a received analyte level is below a high threshold, which may indicate that the user’s glucose is inside a target range. The high threshold analyte level may be 190 mg/dL, alternatively 185 mg/dL, alternatively 180 mg/dL, alternatively 175 mg/dL, alternatively 170 mg/dL. The high threshold analyte level may be set by the user. If the system or application determines that an analyte level is not below a high threshold, then the system or application may return to step 1942 and receives additional analyte data. [00172] If the system determines that an analyte level is below a high threshold, in step 1948, the system may analyze the insulin dose data received to determine if a period of time has passed since an insulin dose has been recorded or received. The period of time may be about 2 hours, alternatively about 2.5 hours, alternatively about 3 hours. The period of time may optionally be set by the user instead of a default time set by the system. If the period of time since the last insulin dose has been recorded has not passed yet, then the system returns to step 1944 and receives additional insulin dose data. [00173] If the system determines that the period of time has passed since a last insulin dose, in step 1950, the system may display an alert interface relating to the analyte level being within a target range. In some embodiments, the text of the alert interface may be customizable by the user. Account Controls [00174] In some embodiments, interfaces for an analyte monitoring software application are provided to allow for an “accountless mode,” in which a user need not create or sign into a cloud-based server in order to utilize the monitoring application. In other embodiments, interfaces for the monitoring application are provided to allow a user to opt-in or decline to share the user’s sensor readings and/or other product-related data for research purposes. Docket No. A0130.0317.WO 14890WOO1 [00175] As seen in FIG.29A, GUI 2300 depicts a user account creation interface which allows the user to initiate a process to create a cloud-based user account. By creating an account, the user may have the option to share their data, including analyte data and dose data, with third parties. These third parties include, but are not limited to, healthcare professionals, guardians, family, and friends. An account user may also have access to their complete glucose picture online, including dose data integrated with glucose data. An account user may also have their data backed up to, e.g., a cloud-based server. The data may be available and the user may continue to use a sensor even if the user switches mobile devices. According to one aspect of the embodiments, as seen in FIG.29E, in method 2330, if the user does sign up for an account, a cloud-based user account can allow the user to share information with healthcare professionals, family and friends; utilize a cloud-based reporting platform to review more sophisticated 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 sign up for an account, their data may not be backed up on the server (step 2336). In some embodiments, GUI 2300 can also include a “Skip” link 2302 that allows a user to utilize the analyte monitoring software application in an “accountless mode” (e.g., without creating or linking to a cloud-based account). Upon selecting the “Skip” link 2302, an information window 2312 in GUI 2310 can be displayed to inform that certain features are not available in “accountless mode.” Information window 2312 can further prompt the user to return to GUI 2300 or proceed without account creation. [00176] FIG.29C is GUI 2330 depicting a menu interface displayed within a monitoring application while the user is in “accountless mode.” According to an aspect of the embodiments, GUI 2330 includes a “Sign in” link 2332 that allows the user to leave “accountless mode” and either create a cloud-based user account or sign-in with an existing cloud-based user account from within the analyte monitoring software application. [00177] Referring next to FIG. 29D, GUI 2340 depicts a research consent interface, which prompts the user to choose to either decline or opt in (through buttons 2442) with respect to permitting the user’s sensor readings and/or other product-related data to be used for research purposes. If the user is in “accountless mode,” GUI 2340 may not appear for the user. In some embodiments, a help screen regarding privacy and consent issues may also not be displayed in “accountless mode.” Docket No. A0130.0317.WO 14890WOO1 [00178] In some embodiments, the user may sign out of their account. A GUI with a warning may be displayed that advises the user about the limited functionality once the user signs out. Signing 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 they sign 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 signed out, all new data may only be stored locally on their device. The user may sign out of the account from a settings menu. In some embodiments, once the user signs back into their account, all of the data collected while the user was signed out may be automatically shared to authorized third parties and also backed up on the server. In other embodiments, once the user signs back into their account, the data may not be automatically shared and the user may need to select to share and/or store the data that was collected while the user was not signed into their account. [00179] In some embodiments, the user may change their options for sharing data with third parties and connected applications through, e.g., the settings menu, while they are signed into their account. If the user elects to stop sharing their data with a third party or a connected application, in some embodiments, a notification may be sent to the third party or the connected application to inform them that the data is no longer being shared. In other embodiments, no notification may be sent to the third party or the connected application to inform them that the data is no longer being shared. After discontinuing sharing their data, the user may opt to begin sharing their data again if they so choose by going back to the settings menu and enabling the appropriate control to share their data. [00180] In some embodiments, if the user does create an account, the user may also delete their account at a later time. The user may then still be able to operate the monitoring application in “accountless mode” as described above, if they delete their account. In some embodiments, a GUI with a warning may be displayed that advises the user about the limitations and effects of deleting their account. The user may also be prompted to enter their password as a confirmation that the user wishes 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 in which the data was stored locally. The user may optionally create a new account with 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, Docket No. A0130.0317.WO 14890WOO1 after deleting the account, the user may still be able to obtain sensor readings and dose data using a dedicated reader device. [00181] In another embodiment, once the user deletes their account, the user’s data may be saved in an encrypted or secured account that is only accessible with the user’s permission, e.g., through a code. If the user creates a new account, the user may access their data from their previously deleted account and import the data to their new account. Reports [00182] The monitoring application may transfer data, including analyte levels from the SCD 102 and dosing data/logs from the medication delivery device 152, to a reporting application. The reporting application may be able to generate a plurality of reports that summarize and highlight various aspects of the analyte and medication data and history. The reporting application may be run on the display device or on a separate computing device. In some embodiments, the monitoring application may include instructions that, when executed by one or more processors, generates and display reports that include the insulin data in the monitoring application. [00183] FIGS.8A-8C depict example embodiments of an insulin dosage interface 502, as part of analyte monitoring system report GUI 500. According to one aspect of the embodiments, GUI 500 is a snapshot report covering a predetermined time period 504 (e.g., 14 days), and comprising a plurality of report portions on a single report GUI, including: a sensor usage interface portion 506, a glucose trend interface 508, which can include an AGP graph 511, a low glucose events graph 513, and other related glucose metrics (e.g., Glucose Management Indicator 515); a health information interface 510. [00184] The AGP graph 511 may display the hourly 5 ^th , 25 ^th , 50 ^th (median), 75 ^th , and 95 ^th percentiles of glucose readings, presented over the “typical” day based on all days within the selected timeframe. The AGP graph 511 may also include two horizontal lines, which indicate the boundaries of the target range defined in the glucose statistics and targets portion and the Time-in-Ranges portion. The report 500 may also include a section 517 that lists metrics and/or statistics related to the average glucose. Metrics section 517 may list the average glucose, the percent of time above target range, the percent of time in a target range, and the percent of time below a target range. The low glucose events graph 513 may include a graph of the events in which the subject’s glucose levels dropped below a low threshold, e.g., 72 mg/dL. The graph Docket No. A0130.0317.WO 14890WOO1 may show the glucose concentration (mg/dL) vs. time, such that the times of the low event episodes during the day are readily apparent. The report 500 may also include a section 519 that lists metrics and/or statistics related to the low glucose events. The low glucose events metrics section 519 may list the number of low glucose events and the average duration of the low glucose events. [00185] The sensor usage interface 506 may include a Percentage Time Sensor Active graph 521 and a metrics section 523. The metric section 523 may include a percentage that the time sensor has been active and an Average Scans/Views metric (e.g., indicative of an average sum of a number of scans and a number of views). The Percentage Time Sensor Active graph 521 may include a graph of the percent of time that the sensor is active vs. a time of day (e.g., from 12 am to 12 am). An axis of the Percentage Time Sensor Active graph 521 may be aligned with a corresponding axis of one or more other graphs (e.g., average glucose trend graph 511, low glucose events graph 513), such that the user can visually correlate data between multiple graphs from two or more portions of the report GUI by the common units (e.g., time of day) from the aligned axes. [00186] The health information interface 510 may include a carbohydrates section 512, insulin administered section 502, and a comments section 514. The carbohydrates section 512 may include information logged by the user about the user’s average daily carbohydrate intake and may include the average total number of carbohydrates consumed by the user during the time period 504. [00187] The insulin administered section 502 may include a list of medication dosages (e.g., insulin dosages) that were administered during the time period 504. The list may include separate entries for rapid acting insulin 516, long acting insulin 518, and a total daily amount of insulin 520. The entries may include an icon indicating of the insulin type, and/or the type of insulin (e.g., rapid acting, long acting, basal, etc.), and/or the brand name of the insulin, and/or the average amount of insulin administered. Where multiple insulin pens are connected, the medication dosages portion of the display 502 may include different icons for the different types of insulin pens, e.g., different colors and/or icons. For example, a rapid-acting pen may have a light green icon 516 while a long-acting insulin pen may have a dark green icon 518. [00188] In some embodiments, the insulin dose amounts may have been manually entered by the user and/or determined by a dosage calculator, rather than transferred directly from a Docket No. A0130.0317.WO 14890WOO1 connected medication delivery device 152. The insulin dose amounts may have been entered into either the monitoring application or the reporting application. Where the insulin dose amounts were manually entered, the report 500 may note the amount of rapid-acting insulin 516 and long-acting insulin 518 delivered, but may not list the brand names of the insulins. The units/day that were administered for each type of insulin and the average total daily insulin (units/day) may also be displayed in the insulin dosage interface 502. For the rapid-acting insulin dose 516, the dose may be listed as the total dose (in units/day) that was administered, but may also be broken down into the different components, which may include a meal amount, a correction amount, a user change, and a manual input. [00189] The comments interface 514 may can include additional information about the user’s analyte and medication patterns presented in a narrative format. For example, the comments section 514 may include an indication of the trend of the number of tests per day as compared to a previous reporting period, detected fluctuations in the reporting period, and a ratio of the correction insulin of the average daily dose. [00190] The report 500 may also include a listing of the sources 522 of the information provided. The sources may include the name of the glucose monitoring device, and also include the name of the insulin delivery device (e.g., brand name). If more than one insulin delivery device is being used by the patient, the sources section 525 may list all of the medication delivery devices or may contain the name of the first connected pen and the number (numerical value) of the additional medical device(s), but may not include the names of any specific insulin pens. [00191] FIGS.9A-9G depict example embodiments of another analyte monitoring system report GUI 600 including information regarding insulin doses administered. According to one aspect of the embodiments, GUI 600 is a Weekly Summary report for a time period 613 that includes a plurality of report portions, wherein each report portion is representative of a different day of the week. The time period may be for a single week or a plurality of weeks, e.g., 7 days, 14 days (see, e.g., FIGS.9B-9C), 21 days, 28 days (see, e.g., FIGS.9D-9G), 32 days, 36 days, etc. Each report portion may include a glucose trend graph 601a-601n for each day of the time period 613, which can include the user’s measured glucose levels over a twenty-four hour period, and a health information interface 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 Docket No. A0130.0317.WO 14890WOO1 606a-606bb, carbohydrate intake 608a-608bb, insulin dosages 610a-610bb, and hypoglycemic (“low”) events 612a-612bb. [00192] In some embodiments, the glucose trend graphs 601a-601bb may include sensor usage markers to indicate that a scan, a view, or both had occurred at a particular time during the twenty-four hour period. The glucose trend graphs 601a-601bb may also include color-coding to highlight portions of the trend graph that are outside of the target range. For example, the trend graphs 601a-601bb may include coloring of the area under the curve a certain color or changing the portion of the graph to be a certain color, or otherwise highlighting the region with the corresponding color for the portion outside of the target range. The area under the curve of the portion above the target range 603 may be colored, e.g., yellow or orange, and the area under the curve of the portion below the target range 605 may be colored, e.g., red. [00193] The “low” events column 612a-612bb may list the number of low events that were detected where the user’s analyte levels went below a lower threshold (e.g., 80 mg/dL for glucose, alternatively 75 mg/dL). The low events may also be highlighted in the glucose trend graph by shading an area under the curve of the low event in a different color, e.g., red. [00194] Similarly, the total carbohydrate amount 608a-608bb ingested may be listed for each day in the health information interface 604. These carbohydrate entries may be distinguishable from the insulin dosage entries by appearing in a different color, e.g., orange, with a different icon, e.g., an apple. The total carbohydrate entry 608a-608bb may be blank, a dash, or a plurality of dashes if no value for the amount of carbohydrates is available. Moreover, the amounts of carbohydrates ingested may also be included in the glucose trend graphs 602a-602bb. Similar to the insulin doses, the amount of carbohydrates in different meals or snacks can be noted at or near the time of ingestion, and the amount may be listed in an orange box. If insulin was administered at or around the same time as a meal (ingestion of carbohydrates), the amount of insulin may appear below the amount of carbohydrate ingested on the glucose trend graph. [00195] The insulin dosages column 610a-610bb interface may include the total amount of insulin administered that day for each of the different types of insulin. The total dose amounts for the different insulin types may be differentiated by different colors. For instance, the total rapid-acting insulin administered may be denoted in a light green box and the total long-acting insulin administered may be denoted in a dark green box. The entry for the amount of insulin administered may appear as a dash or a plurality of dashes if no value is available. The specific Docket No. A0130.0317.WO 14890WOO1 doses of the different insulins may also be noted in the glucose trend graph 601a-601bb. For example, a box containing the dosage amount may appear in the glucose trend graph at or near the time at which the dose was administered. The boxes may be color-coded, similar to the total insulin amounts, in order to allow the user to quickly determine which insulin was administered. For example, the rapid-acting insulin doses administered may be in light green boxes and the total long-acting insulin doses administered may be in dark green boxes. The long-acting insulin doses may or may not be displayed on the glucose trend graphs. Moreover, when a rapid-acting dose was administered at or around the same time as a long-acting dose, the long-acting dose may appear below the box entry for 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. [00196] In some embodiments, the dosing information may have been manually entered by the user rather than transferred directly from a connected medication delivery device 152. The insulin dose amounts may have been entered into either the monitoring application or the reporting application. Where the insulin dose amounts were manually entered, the report 600 may note the amount of rapid-acting insulin delivered, but may not list the brand name of the insulin in the legend 630, although the legend 630 may include the icon corresponding to the particular type of insulin administered. In some embodiments, the dosing information may be automatically transferred from the connected delivery device. The sources 632 of the data may include the name of the device providing the analyte data levels and the number of the additional merged glucose devices, but may not include the names of any specific insulin pens. The units/day that were administered for each type of insulin and the average total daily insulin (units/day) may also be displayed in the insulin dosage interface 610. The insulin doses administered on the glucose trend graph may be displayed below a carbohydrate entry if they are close in time. In other embodiments, the brand name of the insulin may be included in the weekly summary report 600, in, e.g., the legend 630. [00197] The report may also list the sources 632 of the data, including the name of the device providing the analyte data levels 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 sources 632 may contain the name of the first connected pen and the number (numerical value) of the additional medical devices. Docket No. A0130.0317.WO 14890WOO1 [00198] FIGS.10A-10C depict example embodiments of another analyte monitoring system report GUI 700 including information regarding multiple types of insulin administered in a daily log report. According to one aspect of the embodiments, GUI 700 is a Daily Log report that, for each day of the time period 701, may include a glucose trend graph 702a-702c, a scans or views section 704a-704c, a carbohydrates row 706a-706c, an insulin doses administered row 708a- 708c, a notes row 710a-710c, and a legend 730. The time period may be for a single week or a plurality of weeks, e.g., 7 days, 14 days (see, e.g., FIG.10B), 21 days, 28 days (see, e.g., FIG. 10B), 32 days, 36 days, etc. FIGS.10A-10C show examples of a first page or screen of the report 700, which contains graphs and information for the first 3 days of the time period. The glucose trend graphs 702a-702c may include the user’s glucose levels over a twenty-four-hour period. In some embodiments, the glucose trend graphs 702a-702c may include sensor usage markers to indicate that a scan, a view, or both had occurred at a particular time during the twenty-four hour period. In some embodiments, the glucose level for the scan or view may be listed at the time of the scan or view in the scans or view section 704a-704c. Glucose trend graphs 702a-702c may also include logged event markers, such as logged carbohydrate intake markers and logged insulin dosage markers, as well as glucose event markers, such as low glucose event markers. Beneath the glucose trend graphs 702a-702c, the report 700 may include a plurality of rows with additional information, including a row corresponding to scans or views 704a-704c, carbohydrates 706a-706c, insulin administered 708a-708c, and notes 710a-710c. In the scans or views row 704a-704c, noteworthy glucose levels may be listed in the row in a position corresponding to the time that the glucose level was recorded. For example, a peak glucose level of an episode above the target range may be noted and color coded a first color, e.g., orange, and a low glucose level of a hypoglycemic episode may be color coded a second color, e.g., red. In the carbohydrates row 706a-706c, an amount of carbohydrates may be listed in the row in a position corresponding to the time that the carbohydrates were logged. [00199] For the insulin administered row 708a-708c, the amounts of insulin injections may be displayed in rows under each glucose trend graph 702 for each hour time block. Each medication delivery device may appear in a separate row. For example, as seen in FIG.10B, 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 doses row may appear below the rapid-acting insulin doses row. The rapid-acting insulin Docket No. A0130.0317.WO 14890WOO1 dose amounts may appear in white boxes with black outlines. User corrections or changes may appear before the dose amount. The long-acting insulin dose amounts may appear in dark green boxes. The sources 754 of the data may include the name of the device providing the analyte data levels and the name of the first connected insulin pen, along with a number of the additional merged glucose devices. [00200] In some embodiments, the insulin dose amounts may have been manually entered by the user and/or determined by a dosage calculator, rather than transferred directly from a connected medication delivery device 152. The insulin dose amounts may have been entered into either the monitoring application or the reporting application. Where the insulin dose amounts were manually entered, the daily log report may note the amount of rapid-acting insulin and long-acting insulin 618 delivered, but may not list the brand name of the insulins next to their respective icons. In some embodiments, the dosing information may be automatically transferred from the connected delivery device. The sources 754 of the data may include the name of the device providing the analyte data levels and the number of the additional merged glucose devices, but may not include the names of any specific insulin pens. A row may only be displayed for a particular insulin type if dosing data for that insulin type was entered for a particular day. If there is no data for a particular day, then a row for that insulin type may not appear below the glucose trend graph 702. Beside the glucose trend graphs 702a-702c, a color- coded icon and the brand name or the type of the insulin may appear next to the insulin dose row. As with other report embodiments, different icons and different colors can be used for the rapid- acting and long-acting insulin pens. For example, the rapid acting insulin may be depicted with a light green solid syringe icon. The long-acting insulin may be depicted with a dark green, wider syringe icon. A row may only appear for a particular day when there is insulin dose data for that day. The daily log report 700 may also include a note if the user switches insulin brands in a connected pen during a particular day. A note may appear when the inulin brand was changed, which includes the old and new insulin brand names. The new insulin brand name may then be listed in the text near the glucose trend graph 702. In other embodiments, the brand name of the insulin may be included in the daily log report 700, in, e.g., the legend 730. [00201] The notes row 710a-710c may also be included in the daily log report 700. The notes may include text that was added regarding events, e.g., exercising. The text may appear in the row in a position corresponding to the time that the notes were logged. Docket No. A0130.0317.WO 14890WOO1 [00202] FIGS.11A-11D depicts example embodiments of a daily patterns report GUI 770. The daily patterns report 770 includes a user’s ambulatory glucose profile 772, a section reflecting the amount of carbohydrates 774 consumed in different time of day periods, and a section reflecting the dosage amounts of different types of insulin 778a-778b. The daily pattern report 770 shows a 1 day, i.e., 24-hour, time period graphical representation of glucose measurement values organized by time of day for a period of days 771—e.g., 14 days (see FIG. 11B) or 28 days (see FIG.11C). The glucose measurement values may be displayed as individual points, or may be averaged into a gradient pattern representative of density of measurement values within particular ranges. The ambulatory glucose profile 772 may include a representation of the target glucose range for the user, as well as a median over time, represented by an average or median line, and lines representing the 10 percentile, 25 percentile, 75 percentile and 90 percentiles. The daily pattern report 770 may also have an indication of the daily average glucose level 785. Above the ambulatory glucose profile 772, a row 773 may appear where the average glucose level for each time period may be listed. Each time period may be about 2 hours, alternatively about 3 hours, alternatively about 4 hours. Noteworthy glucose levels (e.g., the highest average glucose level) may be highlighted with a different color to aid the user in easily seeing which time period had the highest glucose levels. [00203] In addition to measured glucose levels, the daily pattern report 770 may include other average daily information, such as carbohydrates 790, rapid-acting insulin 802, and long-acting insulin 804. The section reflecting the amount of carbohydrates 774 consumed in different time of day periods may include a daily average amount of carbohydrates ingested 790 and a graph of time (x-axis) and amount of carbohydrates (y-axis (grams)), which may include icons (e.g., apples) to mark the amounts of carbohydrates consumed during different time of day periods. The total amount of carbohydrates 794 consumed in a particular time of day period may be listed on top of the graph, along with the number of meals or snacks consumed during the time period (e.g., in parentheses). [00204] The section reflecting the dosage amounts of different types of insulin 778a-778b of the daily patterns report 770 may include a row for each type of insulin administered through a connected medication delivery device 152, e.g., 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, a daily Docket No. A0130.0317.WO 14890WOO1 average administered 803, 805, the average amount administered for each time of day period, and the number of entries (in parentheses) for that time of day period 810 may be reported in the insulin rows 778a-778b. The brand name of the insulin may also optionally be listed. As with other embodiments discussed herein, a light green syringe icon may be used to denote an insulin pen containing a fast-acting insulin and a dark green syringe icon may be used to denote an insulin pen containing a long-acting insulin. The sources 812 of the data may include the name of the device providing the analyte data levels and the name of the first connected insulin pen, along with a number of the additional connected device (e.g., additional insulin pens). [00205] In some embodiments, where only a single insulin pen is connected, only a single row 778 of insulin doses may appear, along with the corresponding icon (e.g., light green syringe icon for rapid-acting insulin pen) and the brand name or type of the insulin delivered. Where only a single insulin pen is connected, the sources 812 of the data may only include the name of the device providing the analyte data levels and the name of the connected insulin pen, without any number indicating additional devices are connected. [00206] In some embodiments, the insulin dose amounts may have been entered into either the monitoring application or the reporting application. Where the insulin dose amounts were manually entered, the daily patterns report 770 may note the amount of rapid-acting insulin and long-acting insulin delivered, but may not list the brand name of the insulins near their respective icons. In some embodiments, the dosing information may be automatically transferred from the connected delivery device. The sources 812 of the data may include the name of the device providing the analyte data levels and the number of the additional merged glucose devices, but may not include the names of any specific insulin pens. The units/day that were administered for each type of insulin and the average total daily insulin (units/day) may also be displayed. In other embodiments, the brand name of the insulin may be included in the daily pattern report 770, in, e.g., a legend. [00207] A daily patterns report GUI 1700 may also be available on the display device 120, through the monitoring application, a reporting application, or other application. As seen in FIG. 11D, the daily patterns report GUI 1700 may include a user’s ambulatory glucose profile 772, the period of days or the number of days 771 that is being displayed in the GUI 1700, an insulin summary section 1778, and alternative time periods 1774a-1774d to select and display. The ambulatory glucose profile 772 has been described in detail with respect to other embodiments Docket No. A0130.0317.WO 14890WOO1 and reports. The ambulatory glucose profile 772 may also indicate how many days of the time period 771 that the glucose data was available. The ambulatory glucose profile 772 may also include syringes above or below the graph to indicate the times at which the doses were administered. Alternatively, the doses may be graphed along the median line of the ambulatory glucose profile to indicate what time they were administered. The insulin summary section 1778 may include a graphical representation of the amounts of insulin dosed during the time period 771. In some embodiments, the graph may be a bar graph of time (x-axis) vs. the average number of insulin units administered. The graph may include both fast-acting insulin doses and basal doses. The insulin summary section may also indicate how many days of the time period 771 that the dosing data was available. The x-axis (time) of the graph in the insulin summary section 1778 may align with the x-axis (time) of the ambulatory glucose profile 772, with the average dose amounts for the different meal and basal doses being graphed at the average time that they were administered during the time period 771. Thus, the user may be easily able to see a correlation between their insulin doses and their glucose profile in the time periods relevant to the different doses. The GUI 1700 may also include tabs 1774a-1774b with different time periods for which the user may select to display the daily patterns report. For example, the time period tabs 1774a-1774d may be 1 day, 7 days, 14 days, 30 days, or 90 days. [00208] Alternatively, as seen in GUI 1720 of FIG.11D, the user may select the time period in a drop down menu 1775. In such a case, the GUI 1700 may include a date range 1775 and the user may scroll forward and backwards in time by tapping on the forward or backward carets. In some embodiments, when a user selects 1 day for the time period, a daily graph may be displayed, which shows the glucose and insulin data for the individual day selected. For the daily graph, instead of an ambulatory glucose profile, the daily graph may display the glucose profile for that day, while also highlighting the target range for the user. The glucose profile graph may also contain syringe icons above or below the graph to indicate the times at which the insulin was administered. Alternatively, the doses may be graphed along the median line of the glucose profile to indicate what time they were administered. The insulin summary section may display graphical representation of the amounts of insulin dosed during the day (as opposed to an average number of doses for a multi-day period). In some embodiments, the graph may be a bar graph of time (x-axis) vs. the number of insulin units administered. The graph may include both fast-acting insulin doses and basal doses. The x-axis (time) of the graph in the insulin summary Docket No. A0130.0317.WO 14890WOO1 section may align with the x-axis (time) of the glucose profile, with the dose amounts for the different meal and basal doses being graphed at the time that they were administered during the day. Thus, the bars in the bar graph may align at the same times with the syringe icons in the glucose profile graph. [00209] As seen in FIG.11E, if the user requests more information by, e.g., tapping on an “i” icon, a window 1800 may be displayed that includes an explanation 1806 that the daily patterns report shows the user’s glucose and insulin patterns over a period of time. The window 1800 may also include the target range, e.g., 70 – 180 mg/dL. The user may also be able to select the type of insulin data to display – either rapid acting 1802 or long acting 1804. [00210] FIGS.28A-D depict example embodiments of another analyte system report GUI 2000 that includes information regarding multiple types of insulin administered in a Daily View Report GUI 2000. According to one aspect of the embodiments, the Daily View Report GUI 2000 may include, for each day of the time period 2002, a glucose profile 2010a-g, a time-in- range metric 2012a-g, a listing of the total rapid-acting insulin administered 2014a-g, a listing of the total long-acting insulin administered 2016a-g, and a listing of the total amount of carbohydrates consumed 2016a-g. The time period 2002 may be for a single week or a plurality of weeks, e.g., 7 days, 14 days, 21 days, 28 days, 32 days, 36 days, etc. FIGS.28A-B show examples of a first page or screen of the report 2000, 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 that a sensor was active 2020 during the time period, the average number of scans or views 2022 per day during the time period, a legend 2024 of the symbols used in the report 2000, and the sources 2026 of the data used in the report 2000. [00211] The glucose profiles 2010a-g may include the user’s glucose levels over a twenty- four-hour period. In some embodiments, the glucose profiles 2010a-g may optionally include sensor usage markers (e.g., a circle) 2066 to indicate that a scan, a view, or both had occurred at a particular time during the twenty-four-hour period. In some embodiments, the glucose level for the scan or view may be listed at the time of the scan or view in the scans or view section. Each daily profile may represent a midnight to midnight period with the date displayed in the same frame as the profile. In addition to the displaying the date, each profile may also indicate the corresponding day of the week. Each profile may also contain an indication of the target glucose range (e.g., a shaded region or lines indicating the upper and lower boundaries of the Docket No. A0130.0317.WO 14890WOO1 targe region) to illustrate which parts of each daily profile were within the target range 2056. Portions of the graph outside of the target range 2056 may also be color-coded as a further indication of readings or analyte levels that were outside of the target range 2056. The color coding may correspond to the colors used in the Time-in-Ranges graphical representations described in other reports. For example, portions of the graph above the target range 2056 in the “high” level (e.g., 181-250 mg/dL) may be color-coded yellow. Portions of the graph below the target range 2056 in the “low” level (e.g., 54-69 mg/dL) may be color-coded red. Portions of the graph below the in the “very low” level (e.g., <54 mg/dL) may be color-coded dark red or maroon. The 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 certain color or changing the portion of the graph to be a certain color, or otherwise highlighting the region with the corresponding color. [00212] Glucose profiles 2010a-g may also optionally include logged event markers, such as logged exercise events 2064, logged carbohydrate intake markers, and logged insulin dosage markers, as well as glucose event markers, such as low glucose event markers. The logged event markers may be listed above or below the glucose graph at the time that the event was logged. [00213] As seen in FIGS.28B-E, in some embodiments, instead of including the numbers in the glucose profile 2010a-g, the report 2000 may include a plurality of rows with additional information beneath the glucose profiles 2010a-g, including a row corresponding to carbohydrates consumed 2038a-e, rapid-acting insulin received 2034a-e, and long-acting insulin received 2036a-e. In the carbohydrates row 2038, an amount of carbohydrates 2058 may be listed in the row 2038 in a position corresponding to the time that the carbohydrates were logged. Similarly, in the rapid-acting row 2034, the amounts of rapid-acting insulin 2060 administered may be listed under the time of administration. In the long-acting insulin rows 2036, the amounts of long-acting insulin administered 2062 may be listed under the time of administration. In some embodiments where the dosing data was obtained from a connected pen or connected pen cap, the report 2000 may include the long-acting insulin row 2036. The color-coding for these entries may be the same as the listing of carbohydrates, rapid-acting insulin, and long- acting insulin in the listing of the total amounts 2018, 2014, and 2016. [00214] In some embodiments, the report 2000 may also or alternatively contain rows that indicate scans or views, and notes. In the scans or views row, noteworthy glucose levels may be Docket No. A0130.0317.WO 14890WOO1 listed in the row in a position corresponding to the time that the glucose level was recorded. For example, a peak glucose level of an episode above the target range 2056 may be noted and color coded a first color, e.g., orange, and a low glucose level of a hypoglycemic episode may be color coded a second color, e.g., red. Optionally, noteworthy glucose levels may be included in the glucose profile 2010a-g. [00215] In some embodiments, as seen in FIG.28D, where the basal insulin was administered using an insulin pump, the report may also or alternatively include an insulin delivery graph 2042c located below or above the glucose profile 2010 that shows when and the amount of the insulin was delivered in lieu of a long-acting insulin row 2036 showing discrete doses. The insulin delivery graph 2042c may have an x-axis of time and a y-axis of units/hr. The time axis of the insulin delivery graph 2042c and the glucose profile 2010 may be aligned. When an insulin pump is the source of basal dose information, the listing of the total long-acting insulin administered 2016c may include a name of the pump system and a percentage of time that the pump was active. FIG.28D depicts a single day’s entry from a Daily View Report 2000. [00216] In some embodiments, as seen in FIG.28E, where the insulin was administered using an insulin pump, the report may also or alternatively include an insulin delivery graph 2044c located below or above the glucose profile 2010 that shows how much insulin was delivered and the delivery mode of the insulin pump in lieu of a long-acting insulin row 2036 showing discrete doses. In some embodiments, the insulin graph 2044c may have an x-axis of time and a y-axis of units/hr. The insulin graph 2044c may include a trace 2052 of the insulin amount delivered and segments of time when the pump was operating on automated delivery 2046, maximum delivery 2048, or automated pause 2050, or if insulin was delivered manually 2054. When an insulin pump is the source of basal dose information, the listing of the total long-acting insulin administered 2016c may include a name of the pump system and a percentage of time that the pump was active. FIG.28E depicts a single day’s entry from a Daily View Report 2000. [00217] The time-in-range metric 2012a-g may be a percentage of time spent in the target range 2056 for that day. [00218] The listing of the total rapid-acting insulin administered 2014a-g for each day may be determined from data that is automatically transferred from a connected medication delivery device 152, such as a connected pen, connected pen cap, or an insulin pump. Alternatively, in Docket No. A0130.0317.WO 14890WOO1 some embodiments, the listing of the total rapid-acting insulin administered 2014a-g for each day may be determined from insulin doses that were manually logged by a user. [00219] The listing of the total long-acting insulin administered 2016a-g for each day may be determined from data that is automatically transferred from a connected medication delivery device 152, such as a connected pen, connected pen cap, or an insulin pump. Alternatively, in some embodiments, the listing of the total long-acting insulin administered 2016a-g for each day may be determined from insulin doses that were manually logged by a user. [00220] The listing of the total amount of carbohydrates consumed 2016a-g may be determined from carbohydrates logged by the user. Alternatively, the listing of the total amount of carbohydrates consumed 2016a-g may be determined from meals and snacks that are logged, where the carbohydrate content of the meals and snacks is estimated by a program. [00221] FIGS.12A-12C depict example embodiments of a Mealtime Patterns report GUI 850. The mealtime patterns report 850 may include graphical and numerical representations of glucose level information with respect to particular times periods of the day that may be associated with meals, i.e., morning (breakfast, e.g., 6am-10am), midday (lunch, e.g., 10am- 4pm), evening (dinner, e.g., 4pm-10pm), and nighttime (bedtime, e.g., 10 pm-6am). A vertical line may be displayed to delineate the hours before (pre-meal) 852 and after (post-meal) 854 the corresponding meal. Further, the representations may include numerical indications of the glucose levels before 858a-858d and after 860a-860d the time of the ingestion of the particular meal for each of the days within the mealtime patterns time period 856, along with the average pre-meal 859a-859d and average post-meal glucose levels 861a-861d listed above the tables for each time period. Additionally, a representation of the amount of carbohydrates 864a-864d consumed for each of the days within the mealtime patterns time period, along with the average amount of carbohydrates 865a-865d ingested for the whole time period may be reported. [00222] The Mealtime Patterns report 850 may also contain the amount of insulin administered. An amount of insulin 862a-862d administered for each of the days within the mealtime patterns time period may be displayed in, e.g., a column 862, along with the average amount of insulin administered 863a-863d for that time-of-day period in a row above the table. An icon corresponding to the type of insulin administered (e.g., light green syringe icon for rapid-acting insulin) may also be displayed to indicate the type of insulin administered. Docket No. A0130.0317.WO 14890WOO1 [00223] The sources 874 of the data, including the name of the device providing the analyte data levels and the name of the primary medication delivery device may also be displayed where the medication delivery device 152 has been connected to the IMS. The insulin brand name for the type of insulin administered may also optionally be displayed in a legend 876, which may be located at the bottom of the mealtime patterns report 850. [00224] In some embodiments, the insulin dose amounts may have been manually entered by the user and/or determined by a dosage calculator, rather than transferred directly from a connected medication delivery device 152. The insulin dose amounts may have been entered into either the monitoring application or the reporting application. Where the insulin dose amounts were manually entered, the mealtime patterns report 850 may note the amount of rapid- acting insulin 872 delivered, but may not list the brand name in the report. In some embodiments, the dosing information may be automatically transferred from the connected delivery device. The sources 874 of the data may include the name of the device providing the analyte data levels and the number of the additional merged glucose devices, but may not include the names of any specific insulin pens. The insulin brand name for the type of insulin administered may not be displayed in the legend 876, which may be located at the bottom of the mealtime patterns report 850. Rather, the legend 876 lists the insulin as, e.g., “rapid-acting” without a brand name. In other embodiments, the brand name of the insulin may be included in the mealtime patterns report 850, in, e.g., the legend 876. [00225] The mealtime patterns report 850 may also contain a plurality of graphs 868a-868d of the glucose levels for each of the times periods of the day, i.e., morning (breakfast, e.g., 6am- 10am), midday (lunch, e.g., 10am-4pm), evening (dinner, e.g., 4pm-10pm), and nighttime (bedtime, e.g., 10 pm-6am). Each graph 868a-868d may include a vertical line depicting a meal start time and may span a time frame of about 1 hour before the meal start to about 3 hours after the meal start. The graph may further include data points on the vertical line indicating the plurality of glucose levels scanned or recorded at the beginning of the meal or just before the start of the meal, which are listed in the columns 858a-858d. The average glucose level of the plurality of glucose levels scanned or recorded at the beginning of the meal or just before the start of the meal indicated at the top of the columns 858a-858d may be highlighted in each graph. Additionally, the graphs 868a-868d may include data points indicating glucose levels after the meal, e.g., at least about 2 hours after the meal start, which are listed in the columns 860a-860d. Docket No. A0130.0317.WO 14890WOO1 The average glucose level of the plurality of glucose levels scanned or recorded after the meal, e.g., at least about 2 hours after the meal start, indicated at the top of the column 860a-860d may also be highlighted in the graphs. The graphs 858a-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, so that it is readily apparent if the recorded glucose levels are in or outside the target range at a glance. [00226] FIGS.13A-13B depict example embodiments of Device Details reports GUI 900. The device details report 900 may include glucose settings 910 for the primary glucose device, insulin settings for a first connected insulin pen 930, and insulin settings for a second (or additional) connected insulin pen 940. The glucose settings 910 may include a target range (e.g., 70 – 180 mg/dL) and the alarm settings for low glucose (e.g., 70 mg/dL), high glucose (e.g., 240 mg/dL), and signal loss. The target range may include a low and a high threshold and be set from a monitoring application or a reader. The glucose settings 910 may optionally also include calculator settings and reminders. The Device Details report 900 may also contain details about the primary glucose device 916 that receives analyte levels or data indicative of analyte levels from the SCD 102, including the name of the device (and any icon associated with the device), the current software version on the device, the current operating system version, and the model of the smartphone on which related applications are being run. If the SCD 102 is being used in conjunction with a reader or meter, the device details 916 may include the seral number of the reader or meter. [00227] The device details report 900 may also include details for any connected medication delivery devices 152 (e.g., connected insulin pens). The connected medication delivery devices 152 may be listed under the primary glucose device. If more than one medication delivery device is connected, then each may be displayed as its own device. For each connected medication delivery device, the insulin pen settings 930, 940 may include the insulin type, last scan (e.g., date and timestamp of last insulin value), and pen color. The insulin pen settings 930, 940 may optionally also include calculator settings, notes, and/or reminders. The device details report 900 may also contain details 935, 945 about the insulin pens near their respective settings. The details 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. Docket No. A0130.0317.WO 14890WOO1 [00228] FIG.14 depict an example embodiment of an AGP report GUI 950. The AGP report 950 may include a glucose statistics and targets section 952, a time in ranges section 954, a user’s ambulatory glucose profile 956, and a daily glucose profiles section 958. The AGP report 950 shows various statistics and graphs for a period of days 960—e.g., 14 days or 28 days. The sources 962 of the information may be listed and may include the names (e.g., brand names) of the primary glucose device, the first connected pen, and the number of additional devices. [00229] The glucose statistics and targets or glucose metrics 952 section may include any one or more of the following metrics: the days in which the statistics are reported, the amount of time the sensor was active (reported as a percentage), the amount of time (reported as percentages) that the detected analyte levels were within various ranges, the average glucose, the glucose management indicator (GMI), and the glucose variability. The amount of time in the various ranges may include the amount of time within a target range (e.g., 70 – 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 a higher threshold (e.g., above 250 mg/dL). [00230] The time in ranges section 954 may include Time-in-Ranges (also referred to as Time-in-Range and/or Time-in-Target) GUIs, each of which comprise a plurality of bars or bar portions, wherein each bar or bar portion indicates an amount of time that a user’s analyte level is within a predefined analyte range correlating with the bar or bar portion. In some embodiments, for example, the amount of time can be expressed as a percentage of a predefined amount of time. Time-in-Ranges GUI portion 954 may include a single bar comprising 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 of a predefined amount of time, a second bar portion indicating that the user’s glucose range is “High” or between 180 and 250 mg/dL of the predefined amount of time, a third bar portion indicating that the user’s glucose range is within a “Target Range” or between 70 and 180 mg/dL of the predefined amount of time, a fourth bar portion indicating that the user’s glucose range is “Low” or between 54 and 69 mg/dL of the predefined amount of time, and a fifth bar portion indicating that the user’s glucose range is “Very Low” or less than 54 mg/dL of the predefined amount of time. Time-in-Ranges GUI 954 may display text adjacent to each bar portion indicating an actual amount of time, e.g., in hours and/or minutes. Docket No. A0130.0317.WO 14890WOO1 [00231] According to one aspect of the embodiment shown in FIG.14, each bar portion of Time-in-Ranges GUI 954 may comprise a different color. In some embodiments, bar portions can be separated by dashed or dotted lines and/or interlineated with numeric markers to indicate the ranges reflected by the adjacent bar portions. In some embodiments, the time in ranges reflected by the bar portions can be further expressed as a percentage, an actual amount of time (e.g., 4 hours and 19 minutes), or both. Furthermore, those of skill in the art will recognize that the percentages of time associated with each bar portion can vary depending on the analyte data of the user. In some embodiments of Time-in-Ranges GUI 954, the Target Range can be configured by the user. In other embodiments, the Target Range of Time-in-Ranges GUI 954 is not modifiable by the user. [00232] The AGP report 950 may also contain an AGP portion 956 similar to the AGP graph 511. The AGP graph may display the hourly 5 ^th , 25 ^th , 50 ^th (median), 75 ^th , and 95 ^th percentiles of glucose readings, presented over the “typical” day based on all days within the selected timeframe. The AGP graph may also include two horizontal lines, which indicate the boundaries of the target range defined in the glucose statistics and targets portion 952 and the Time-in- Ranges portion 954. For example, a first line may correspond to the lower boundary of the target range (e.g., 70 mg/dL) and a second line may correspond to an upper boundary of the target range (e.g., 250 mg/dL). The first and second lines may also be color-coded and correspond to the same color as the target range bar portion in the Time-in-Ranges portion 308 (e.g., green). The data or portions of the AGP within the respective concentration ranges may also be color- coded and correspond to the same color as the target range bar portions in the Time-in-Ranges portion (308). For example, data points or portions of the AGP in the target range may be colored green, data points or portions of the AGP in the high concentration range may be colored orange, data points or portions of the AGP in the high range may be colored orange, data points or portions of the AGP in the low range may be colored red, and data points or portions of the AGP in the very low range may be colored dark red or maroon. Thus, the AGP plot easily illustrates the amount of time spent in (or amount of readings falling within) the target range. [00233] The AGP report 950 may also include a daily glucose profiles section 958. The daily glucose profiles section 958 displays a plurality of daily profiles 958-1 – 958-14, one for each day of the time period 960. Each daily profile may represent a midnight to midnight period with the date displayed in the same frame as the profile. In addition to the displaying the date, each Docket No. A0130.0317.WO 14890WOO1 profile may also indicate the corresponding day of the week. Each profile may also contain an indication of the target glucose range (e.g., a shaded region or lines indicating the upper and lower boundaries of the targe region) to illustrate which parts of each daily profile were within the target range. Portions of the graph outside of the target range may also be color-coded as a further indication of readings or analyte levels that were outside of the target range. The color coding may correspond to the colors used in the Time-in-Ranges 954 portion. For example, portions of the graph above the target range in the “high” level (e.g., 181-250 mg/dL) may be color-coded yellow. Portions of the graph below the target range in the “low” level (e.g., 54-69 mg/dL) may be color-coded red. Portions of the graph below the in the “very low” level (e.g., <54 mg/dL) may be color-coded dark red or maroon. The 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 certain color or changing the portion of the graph to be a certain color, or otherwise highlighting the region with the corresponding color. [00234] FIG.19 depicts an example embodiment of a Comparison report GUI 1020. The Comparison report 1020 may include two sections 1022a, b that display metrics for first and second time periods 1024a, b. The metrics for the first and second time periods may be displayed side-by-side to allow for easy analysis and comparison of the different time periods. Each of the sections of the Comparison report 1020 may include a glucose metrics section 1026a,b, a time in ranges section 1028a, b, an ambulatory glucose profile section 1030a, b, and a low glucose events section 1032a, b. The Comparison report 1020 shows various statistics and graphs for two time periods—e.g., 14 days each. In some embodiments, a banner may also appear, e.g., in the header, to inform the viewer if any glucose threshold levels have been adjusted. [00235] The Comparison report GUI 1020 may report the days in which the various metrics are reported 1024a, b, and the amount of time the sensor was active (reported as a percentage) 1034a, b. [00236] The glucose metrics sections 1026a, b may include, for example, the average glucose, the glucose management indicator (GMI), and the glucose variability. [00237] The time in ranges section 1028a, b may include Time-in-Ranges (also referred to as Time-in-Range and/or Time-in-Target) graphical representations, each of which comprise a plurality of bars or bar portions, wherein each bar or bar portion indicates an amount of time that Docket No. A0130.0317.WO 14890WOO1 a user’s analyte level was within a predefined analyte range correlating with the bar or bar portion. In some embodiments, for example, the amount of time can be expressed as a percentage of a predefined amount of time. Time-in-Ranges graphs 1028a, b may each include a single bar comprising a plurality of bar portions stacked vertically. In some embodiments, the graph may include 5 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 and 250 mg/dL for the predefined amount of time, a third bar portion indicating the amount of time that the user’s glucose range was within a “Target Range” or between 70 and 180 mg/dL for the predefined amount of time, a fourth bar portion indicating the amount of time that the user’s glucose range was “Low” or between 54 and 69 mg/dL for the 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 the predefined amount of time. Time-in-Ranges graphs 1028a, b may optionally also each display text adjacent to each bar portion indicating an actual amount of time, e.g., in hours and/or minutes. In some embodiments, the time in ranges reflected by the bar portions can be further expressed as a percentage, an actual amount of time (e.g., 4 hours and 19 minutes), or both. Furthermore, those of skill in the art will recognize that the percentages of time associated with each bar portion can vary depending on the analyte data of the user. [00238] According to one aspect of the embodiment shown in FIG.19, each bar portion of Time-in-Ranges graph 1028a, b may comprise a different color. In some embodiments, bar portions can be separated by dashed or dotted lines and/or interlineated with numeric markers to indicate the ranges reflected by the 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 dark red or maroon. This color scheme may be followed in other portions of the Comparison report 1020, such as the ambulatory glucose profile section 1030a, b and the low glucose events section 1032a, b. For example, the analyte levels in displayed in the graphs in the ambulatory glucose profile section 1030a, b and a low glucose events section 1032a, b may be color coded according to the concentration range that the analyte level falls within. For example, an analyte level of 156 mg/dL may be colored green in an ambulatory glucose profile while an analyte level of 48 mg/dL may be colored dark red or maroon in an Docket No. A0130.0317.WO 14890WOO1 ambulatory glucose profile or low glucose events graph. In some embodiments of Time-in- Ranges graphs 1028a, b, the Target Range can be configured by the user. In other embodiments, the Target Range of Time-in-Ranges GUI 1028a, b is not modifiable by the user. [00239] Each section of the Comparison report 1020 may also contain an AGP portion 1030a, b similar to the AGP graph 511 displayed in FIG.8. The AGP graph may display the hourly 5 ^th , 25 ^th , 50 ^th (median), 75 ^th , and 95 ^th percentiles of glucose readings, presented over the “typical” day based on all days within the selected timeframe. The AGP graph may also include two horizontal lines, which indicate the boundaries of the target range defined in the glucose statistics and targets portion 1026a.b and the Time-in-Ranges graph 1028a, b. For example, a first line may correspond to the lower boundary of the target range (e.g., 70 mg/dL) and a second line may correspond to an upper boundary of the target range (e.g., 250 mg/dL). The first and second lines may also be color-coded and correspond to the same color as the target range bar portion in the Time-in-Ranges portion 308 (e.g., green). The AGP graphs may adopt the same color coding as in the Time-in-Ranges GUI 1028a, b such that the glucose levels in the “Very High” range (e.g., about 250 mg/dL) may be colored orange, the glucose levels in the “High” range (e.g., between 180 mg/dL and 250 mg/dL) may be colored yellow, the glucose levels in the “Target Range” (e.g., between 70 mg/dL and 180 mg/dL) may be colored green, the glucose levels in the “Low” range (e.g., between 54 mg/dL and 70 mg/dL) may be colored red, and the glucose levels in the “Very Low” range (e.g., below 54 mg/dL) may be colored dark red or maroon. Thus, each AGP plot may easily illustrate the amount of time spent in or, the amount of readings falling within, the target range for each time period 1024a, b. [00240] Each section of the Comparison report 1020 may also include a low glucose events section 1032a, b. The low glucose events sections 1032a, b may each include a graph of the events in which the subject’s glucose levels dropped below a low threshold, e.g., 70 mg/dL and a very low threshold, e.g., 54 mg/dl. Each graph may also include a line illustrating a low threshold (e.g., 70 mg/dl) and a very low threshold (e.g., 54 mg/dl). The graph may show the glucose concentration (mg/dL) vs. time, such that the times of the low event episodes during the day are readily apparent. As mentioned previously, the graph of the glucose levels in the low glucose events section 1032a, b may adopt the same color coding as in the Time-in-Ranges GUI 1028a, b such that the glucose levels in between the low threshold and very low threshold (e.g., between 54 mg/dl and 70 mg/dl) may be colored red, and the glucose levels below the very low Docket No. A0130.0317.WO 14890WOO1 threshold (e.g., below 54 mg/dl) may be colored may be colored dark red or maroon. The color- coding may include coloring the area under the curve a certain color or changing the portion of the graph to be a certain color, or otherwise highlighting the region with the corresponding color. The low glucose events sections 1032a, b may also list metrics and/or statistics related to the low glucose events. In some embodiments, the low glucose events metrics sections 1032a, b may list the number of low glucose events and, optionally, the average duration of the low glucose events. [00241] FIGS.15A-15B depict example embodiments of a GUI associated with a patient dashboard 970. The dashboard 970 may allow a user to display merged insulin data from different sources, e.g., connected pens and manually entered insulin data. The user may select different columns to include in the patient dashboard display, including the average rapid-acting insulin administered per day (units), the average long-acting insulin administered per day (units), and the average total insulin administered per day (units). Other parameters that may be shown on the patient dashboard include average glucose (mmol/L), sensor low glucose events average duration (min), % below target, % in target, % above target, low-glucose events, standard deviation (mmol/L), estimated A1c %, and estimated A1c mmol/mol. [00242] FIGS.16A-16B depicts an exemplary embodiment of a GUI for a data sources modal with connected pens 980. In the modal 980, the user is able to select the connected pen(s) that they want to include in a report using the show/hide icon 982. A default may be set to display any connected pens with data during the reporting period. Each connected pen may appear as its own device in the modal 980. The connected devices may appear in an order according to the date of the last upload 986, which is the date of the last insulin timestamp. The listing of the devices (insulin pens) may include the insulin pen brand name, insulin pen serial number, and insulin pen image. The pen image may be positioned above the brand name. The modal 980 may also display an estimated device time 988. The estimated device time 988 may be blank if it is unknown or the same time as the device used to upload at the time of the upload. Days with insulin data captured in the last 90 days from the report end date 990 may be displayed in a different color, e.g., green, to differentiate from data related to glucose. With this GUI, an HCP or other user may determine which data sources to include in any of the reports described herein. [00243] FIGS.17A-17B depict exemplary alerts 1002, e.g., a toast alert, for reporting information regarding connected pens. The alert 1002 may be displayed as an unobtrusive non- Docket No. A0130.0317.WO 14890WOO1 popup box in a portion of the screen, e.g., the bottom right corner for a period of time. The alert 1002 may appear for about 1 minute, or until the user dismisses it, if the report includes insulin pen data. The alert 1002 may show the number of total sources 1004 (including both glucose and insulin sources) and the number of connected pens 1006. The alert 1002 may not be displayed if there is only merged glucose devices and no connected insulin delivery devices. The alert 1002 may indicate that the data coming in from some devices may not be included in the report. The report may only include insulin data from connected pens. [00244] FIGS.24A-C depict example embodiments of Insulin Summary Report GUIs 1840. Insulin Summary Report GUI 1840 may contain tabs 1842a-1842d with different time periods for which the user may select to display the daily patterns report. For example, the time period tabs 1842a-1842d may be 1 day, 7 days, 14 days, 30 days, or 90 days. The GUI 1840 may also contain the date range 1844 that is currently being displayed and a graphical representation of the total daily dose 1848, along with a legend 1846 for the graphical representation 1848. The graphical representation 1848 may be a bar graph with time on the x-axis and total units administered on the y-axis. The graphical representation may include both rapid-acting and long-acting doses. If the time period selected is 14 days 1842b, then the units of the x-axis may be single days, with each day having a bar showing the total amount of fast-acting and rapid- acting insulin administered that day. In some embodiments, the user may select an entry for a single day by tapping it and a window with details for that day (e.g., the total number of units for fast-acting and rapid-acting insulin administered that day). [00245] In some embodiments, the user may access a daily insulin report GUI 1860 by either tapping on details window for that day or by selecting a daily insulin report through a menu. As seen in FIG.24B, the daily insulin GUI 1850 may have the time period of 1 day 1842a selected and may display the date 1854 of the data being displayed in the graphical representation 1858. The representation 1858 may be a bar graph with time on the x-axis and total units administered on the y-axis, with each dose amount graphed at the time it was administered. The graphical representation may include both rapid-acting and long-acting doses. In the legend 1856, below each of the rapid-acting and long-acting symbols or colors, the GUI 1850 may list the total amount of each type of insulin injected that day 1854. [00246] FIG.24C shows an example embodiment of an insulin usage report GUI 1870, which summarizes insulin usage for a selected time period. For example, the time period tabs 1842a- Docket No. A0130.0317.WO 14890WOO1 1842d may be 1 day, 7 days, 14 days, 30 days, or 90 days. The GUI 1870 may display the date range 1872 for the insulin usage being displayed. For the selected date range 1872, where the date range selected is more than one day, the GUI 1870 may also display the average total daily dose amount administered 1874, the average total rapid-acting amount administered daily 1876, and the average total long-acting amount administered daily 1878 [00247] FIGS.18A – 18D depict exemplary embodiments of a GUI of a comparative profiles report. By leveraging dosing data from connected drug delivery devices and glucose data from continuous glucose monitors as inputs, in many embodiments, a GUI or report may include a plurality of glucose profiles over a selected time period. As seen in FIGS.18A- 18B, in some embodiments, the GUI or report may include two, alternatively two or more, alternatively three, alternatively three or more versions of a glucose profile 1010, 1012, 1014 over a selected time period. [00248] In some embodiments, the glucose profile(s) 1010, 1012, 1014 may each be an ambulatory glucose profile (AGP) graph or portions of an AGP. As described with respect to exemplary FIG.14, the AGP may display the hourly 5 ^th , 25 ^th , 50 ^th (median), 75 ^th , and 95 ^th percentiles of glucose readings, presented over the “typical” 24-hour day based on all days within the selected timeframe. Alternatively, the AGP may display other percentiles, such as the hourly 10 ^th , 25 ^th , 50 ^th (median), 75 ^th , and 90 ^th percentiles of glucose readings, presented over the “typical” 24-hour day based on all days within the selected timeframe. The AGP graph may also include two horizontal lines, which indicate the boundaries of the target range. For example, a first line may correspond to the lower boundary of the target range (e.g., 70 mg/dL) and a second line may correspond to an upper boundary of the target range (e.g., 180 mg/dL). The first and second lines may also be color-coded. The colors may correspond to the same colors used in other reports described herein, e.g., the same colors as the target range bar portion in the Time- in-Ranges portion 308 (e.g., green). Thus, the AGP graph easily illustrates the amount of time spent in (or amount of readings falling within) the target range. Other exemplary AGP graphs can be found in, e.g., U.S. Publ. No.2018/0235524, U.S. Publ. No.2014/0188400, U.S. Publ. No.2014/0350369, and U.S. Publ. No.2018/0226150, all of which are expressly incorporated by reference it their entirety for all purposes. [00249] In other embodiments, the glucose profiles may be plotted as multiple daily traces in a single graph or figure. In some embodiments, the glucose profiles may be converted into an Docket No. A0130.0317.WO 14890WOO1 AGP in addition to being plotted as multiple daily traces in the same graph or figure. In some embodiments, the plurality of graphs may be any type of representation of glucose data, include modal day overlays or time-series plots. These graphs may also present data, or be based on data, from other time-based analyte data or other time-based data associated with the patient, such as insulin dosing events or insulin delivery data or meal event data. Although exemplary graphs are described based on glucose data, any patient data may be represented in these exemplary formats. [00250] The GUI or report may include a time filter that allows the user to define a time period to analyze and to display in the plurality of glucose profiles 1010, 1012, 1014. The time period may be the last 7 days, alternatively the last two weeks, alternatively the last month, alternatively the last two months, alternatively the last three months, alternatively the last 6 months, alternatively the last 9 months, alternatively the last year. [00251] A first profile 1010 of the plurality of glucose profiles may display all of the glucose level measurements for the selected time period. See, e.g., FIG.18C. The first profile 1010 may represent a complete set of glucose level measurements, which may include measurements taken after a glucose level-altering drug was administered and after a dose of a glucose level-altering drug was missed, or the dose information was not received by the program or application. [00252] A second profile 1012 of the plurality of glucose profiles may display only specific data over the selected time period associated with an administered glucose-lowering medication. See, e.g., FIG.18D. The specific data may only include glucose level measurements taken during a window of time following, or associated with, the administration of a glucose level-altering medication. The specific data associated with the administration of a glucose level-altering medication may be include glucose data or glucose level measurements taken in a window determined by a fixed time-of-day definition. The glucose data may be included from a particular window if a dose of a glucose level-altering medication is associated with that window. The window may still be associated with a dose even if the window does not occur exactly or right after the dose was administered. In some embodiments, a window may be a fixed time of day. For example, glucose levels from a fixed time window (e.g., about 7 am to about 12 pm) may be included only if a rapid-acting insulin dose was administered in that fixed time window. The length of the fixed time Docket No. A0130.0317.WO 14890WOO1 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 24-hour fixed time window and a rapid-acting insulin may have a 5-hour fixed time window. In other embodiments, a window may be a variable time of day where a first timepoint in the variable time window is the nearest glucose value following the timestamp of the drug dose or the time of a logged dose, and the variable time window extends for a therapeutic window of the administered drug dose. For example, the therapeutic window may be about 5 hours for a rapid-acting insulin and about 24 hours for a long-acting insulin. The administration of the glucose level-altering medication may be from a connected drug delivery device. In other embodiments, the drug delivery device is not connected and a user may log a dose. The record of the medication administration may be provided by the connected drug delivery device, or by some other means such as manual entry of the medication administration event. The specific data for the second glucose profile 1012 may not include glucose level measurements during the window of time following a missed drug administration, or measurement during the window of time associated with a drug administration. The portion or tranche of glucose level measurements after a missed dose, e.g., the glucose level measurements during the window of time following a missed drug administration or alternatively, measurements from a window that is not associated with administration of a medication, may be excised from the data set including all of the glucose level measurements for the selected time period, and the remaining glucose level measurements may be used to generate the second of the plurality of glucose profiles 1012. Thus, the second of the plurality of glucose profiles 1012 may reflect the user’s glycemia when the user remembers to dose. As seen when comparing FIG.18D to FIG.18C, the spread or variability of the data in the AGP graph for the profile in which the insulin was dosed (FIG.18D) is much smaller than the spread or variability of the data in the AGP for the profile containing all data (including data after missed doses). [00253] A third profile 1014 of the plurality of glucose profiles may be a display of only specific data over the selected time period when a glucose level-altering medication was not administered, e.g., by a user or a care-giver. The specific data may be displayed in the third of the plurality of glucose profiles 1014 and may only include the glucose level measurements taken during a window of time following a missed drug administration. The third profile of the plurality of glucose profiles 1014 may contain the data that was excised Docket No. A0130.0317.WO 14890WOO1 from the complete data set to generate the second of the plurality of glucose profiles. The length of the portion or tranche of glucose level measurements after the missed dose that is excised may depend on the type and identity of the glucose level-altering medication. The measured glucose levels displayed in the third profile1014 may have higher glucose level measurements (e.g., a higher median) and/or higher variability as compared to the second profile and the first profile because there are no medications in the user’s body to help control the glucose levels. Thus, glucose levels associated with a missed dose may result in high glucose. Moreover, the high glucose levels resulting from missed doses may mask low glucose events following administered doses when all glucose data are aggregated and plotted together. A glucose profile that displays only the data from the window of time after glucose-lowering medication doses are administered (e.g., 1012) more directly highlights the effects of those drugs on glycemia, thereby helping a trained health care professional potentially titrate a current dose regimen. A profile that highlights the glucose levels where doses are missed (e.g., 1014) may more directly highlight the effects of poor dose concordance on a subject’s glycemia. [00254] Thus, the first profile 1010, which displays the glucose levels in which no data was removed, and the third profile 1014, which displays the glucose levels measured after missed doses, may display higher glucose level measurements (e.g., a higher median) and/or higher variability as compared to the second profile 1012, which displays the glucose levels measured after the administration of glucose-lowering medication. [00255] In some embodiments, the plurality of glucose profiles may be presented in a conjoined display, either side-by-side (e.g., three graphs on the same row as seen in FIG. 18A) or one on top of the other (e.g., three figures in the same column as seen in FIG.18B), that may enable an HCP to identify differences between the traces easily and quickly. In some embodiments, a transparent overlay of one glucose profile on top of the other(s) to make a single figure may be displayed. In other embodiments, problematic areas may be highlighted in the glucose profiles to demonstrate how poor concordance or current dose regimens are affecting glucose outcomes. The plurality of profiles may be presented in any order or spatial arrangement. [00256] Connected drug delivery device data may also include dose timestamps. If the connected drug delivery device data do not present a dose to the program creating the glucose Docket No. A0130.0317.WO 14890WOO1 profiles, then the program may assume that a regularly scheduled dose was not taken by the user, i.e., a missed dose. In the case of a missed dose, a pre-defined portion or tranche of glucose data may be removed from a data set that contains all of the glucose level measurements (which may be used to create the first glucose profile 1010), leaving only glucose data that may be associated with an administered drug dose (which may be used to create the second glucose profile 1012). This excised portion or tranche may then be used to create the third glucose profile 1014. [00257] The length of each excised glucose data portion or tranche (or the window of time from which the data is excluded) may be dependent on the pharmacokinetic and pharmacodynamic profiles of the user’s medications. For example, if a person doses a once-daily basal insulin injection on a Monday but forgets to dose on Tuesday, data from the connected drug delivery device may show a dose timestamp on Monday, but not for Tuesday. As a result, glucose data from Monday may be included in generating the second glucose profile 1012, but glucose data from Tuesday may not be included in the data displayed in the second glucose profile. The Tuesday data may, however, be used in the generation of the third glucose profile 1014. In this example, a day’s worth of glucose data may be excluded because long-acting basal insulin has a pharmacodynamic glucose-lowering action time of about 24 hours. If instead a mealtime rapid acting insulin dose was missed, a smaller portion or tranche of glucose data may be excised from generation of the second glucose profile and used for generation of the third glucose profile. This is because rapid acting insulin has a pharmacodynamic glucose-lowering action time of about 6 hours. [00258] In some embodiments, the plurality of graphs may include at least 2 graphs, alternatively at least 3 graphs, alternatively at least 4 graphs, alternatively at least 5 graphs, alternatively at least 6 graphs, alternatively at least 7 graphs, alternatively at least 8 graphs. Each of the plurality of graphs may display a different data set. In some embodiments, where a person has a treatment regimen that includes both basal insulin doses and bolus doses, 5 graphs may be generated and/or displayed. A first graph may be a display or presentation of all of the glucose measurements from a time period, a second graph may include glucose measurements taken during a window of time following, or associated with, the administration of basal insulin dose(s), a third graph may include glucose measurements taken during a window of time following, or associated with, missed administration(s) of Docket No. A0130.0317.WO 14890WOO1 basal insulin dose(s), a fourth graph may include glucose measurements taken during a window of time following, or associated with, the administration of bolus insulin dose(s), and a fifth graph may include glucose measurements taken during a window of time following, or associated with, missed administration(s) of bolus insulin dose(s). [00259] The glucose level-altering medication may be a glucose lowering medication or a glucose-raising medication. The embodiments described herein relate to glucose-lowering medication, such as insulin, but the framework may be generalizable to glucose-raising medications, such as glucagon. The glucose level-lowering medication may be a type of insulin. Types of insulin include rapid-acting insulin, short-acting insulin, intermediate-acting insulin (e.g., NPH insulin), mixed insulin (e.g., premixed insulin), long-acting insulin, and ultra long- acting insulin. While the examples presented here are for insulin dosing, this methodology is generalizable to any glucose-altering drug with a known glucose-lowering time delivered from a connected drug delivery device. These may include, but are not limited to, SGLT2 inhibitors, GLP1 receptor agonists, biguanides (e.g., metformin), α-glucosidase inhibitors, thiazolidinediones, DPP4 inhibitors, and combinations thereof. [00260] The length of the portion or tranche or the window of time from which data may be excised after a missed once-daily, long-acting, or basal insulin dose may be about 1 day, alternatively between about 20 hours and about 28 hours, alternatively between about 22 hours and about 40 hours, alternatively between about 20 hours and about 38 hours, alternatively between about 20 hours and about 36 hours. [00261] The length of the portion or tranche or the window of time from which data may be excised after a missed rapid-acting insulin dose may be about 2 hours, alternatively about 2.5 hours, alternatively about 3 hours, alternatively about 3.5 hours, alternatively about 4 hours, alternatively about 4.5 hours, alternatively about 5.0 hours, alternatively about 5.5 hours, alternatively about 6.0 hours, alternatively about 6.5 hours, alternatively about 7.0 hours, alternatively between about 2.0 hours and about 7.0 hours, alternatively between about 3.0 hours and about 7.0 hours, alternatively between about 4.0 hours and about 7.0 hours of administration of the glucose-lowering medication. In some embodiments, the length of the portion or tranche or the window of time from which data may be excised may be defined or determined by the medication, such as by the insulin action time of a prandial insulin. In some embodiments, the length of the portion or tranche or the window of time from which Docket No. A0130.0317.WO 14890WOO1 data may be excised may be preset or estimated by the system. In other embodiments, the length of the portion or tranche or the window of time from which data may be excised may be manually entered. [00262] The length of the portion or tranche or the window of time from which data may be excised after a missed intermediate-acting insulin dose may be about 12 hours, alternatively between about 8 hours and about 16 hours, alternatively between about 10 hours and about 14 hours. [00263] The length of the portion or tranche or the window of time from which data may be excised after a missed ultra-long-acting insulin dose may be about 36 hours to about 42 hours, alternatively between about 32 hours and about 44 hours. [00264] In some embodiments, the user may use a filter to customize a GUI or report to display different sets of data. The data may be used to illustrate different types of nonadherence. The filter may include selections to display specific data over a selected period of time when a recommended dose of a glucose level-altering medication was taken, when an under-bolused dose of a glucose level-altering medication was taken, and when an over-bolused dose of a glucose level-altering medication was taken. A graph of specific data over a selected time period when a glucose level-altering medication was under-bolused, i.e., when less than a recommended amount of the glucose level-altering medication was taken, and/or a graph of specific data over a selected time period when a glucose level-altering medication was over-bolused, i.e., when more than a recommended amount of the glucose level-altering, shown in comparison to a graph showing specific data over a selected time period when a recommended amount of a glucose-level altering medication was taken could assist an HCP in convincing a patient to follow a recommended dosing regimen, rather than altering their dose amounts. [00265] In some embodiments, the filter may also include a selection to display specific data over a selected time period when a late meal dose, i.e., a dose was taken a period of time after a start of a meal, was taken. In some embodiments, the filter may also include a selection to display specific data over a selected time period when an extra meal dose, i.e., an additional dose was taken during the meal, was taken. Graphs of specific data over a selected time period when a glucose level-altering medication was taken a period of time after a meal start, and/or specific data over a selected time period when an additional dose of a glucose Docket No. A0130.0317.WO 14890WOO1 level-altering medication was taken during a meal, may help an HCP reduce a patient’s fear of hypoglycemic episodes. [00266] In addition to the other ways described herein, nonadherence may be determined if a dose is taken outside of a preset time period. For example, nonadherence of a basal dose may be determined if a dose was missed or taken outside of a time window from a prescribed dosing time. In some embodiments, the time window may be about 30 minutes, alternatively about 1 hour, alternatively about 90 minutes after the prescribed dosing time. For bolus doses, each meal may have an associated time window. For example, an associated time window for breakfast may be about 6 am to about 11 am, an associated time window for lunch may be about 11 am to about 4 pm, an associated time window for dinner may be about 4 pm to about 10 pm. A time period associated with overnight may be 10 pm to about 6 am. Doses may be determined to be correct if a recommended dose amount was given in an associated time window. A dose may be determined to be missing if no dose was administered during an associated time window. A dose may be determined to be an extra dose if an additional dose beyond a single dose was taken during an associated time period. A dose may be determined to be non-adherent if the dose amount administered during the time period is different than the recommended dose amount. Additionally, missing and extra doses may also be determined to be non-adherent. [00267] Meals may be identified or logged by a subject and a meal start time may be determined from the manual entry. Alternatively, meal start times may be estimated by many 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, R.A. et al. “Design of the Glucose Rate Increase Detector – A Meal Detection Module for the Health Monitoring System,” J Diabetes Sci Techol.2014 Mar; 8(2): 307-320, which is hereby expressly incorporated by reference in its entirety for all purposes. A late dose may be determined if a dose is determined to be taken a period of time after a meal start time, e.g., about 30 minutes, alternatively about 45 minutes, alternatively about 60 minutes, alternatively about 90 minutes after an estimated meal start. In other embodiments, a meal may be determined to have occurred if glucose levels from a CGM are > 70 mg/dl and there was a > 70 mg/dl rise within two hours. In such a case, a late meal bolus dose may be defined when glucose levels from a CGM increased >50 mg/dl from baseline prior to the insulin dose. A missed meal bolus dose Docket No. A0130.0317.WO 14890WOO1 may be defined when no insulin dose was taken within two hours before the start of the rise in glucose levels. In some embodiments, a missed meal dose may be defined by an 80 mg/dl glucose increase over ≤ 2 hours not preceded within 1 hour by an insulin dose. [00268] In some embodiments, the GUI or report may also include at least some analyte metrics related to each profile of the plurality of glucose profiles. The at least some analyte metrics may include, but are not limited to, an average or median analyte level for the time period, a standard deviation (SD), a CV ([(SD of glucose)/(mean glucose)] X 100), a display of a time-in-range for the time period, a GMI index for the time period, a count of a number of high and/or low excursions or their duration below a high and/or low threshold, respectively, a count of a number of very high and/or very low excursions or their duration below a very high and/or very low threshold, respectively, a plurality of dose indicators corresponding to doses of the medication administered, as described with respect to other reports and embodiments in this specification. In some embodiments, pattern analysis of the glucose profile may be based on various inclusions or exclusions. For example, a “low” pattern may be determined for the windows that are associated with medication administration, but not for windows that are not associated with medication delivery. Dose guidance or delivery may be based on these patterns determine only from windows associated with medication administration. In some embodiments, recommendations may be made based on the types of pattern(s) determined or detected. Further details of pattern analysis are described in WO 2021/026004, which is hereby expressly incorporated by reference in its entirety for all purposes. [00269] The methods described herein are not limited to metrics or plots to be displayed but may also be used in processes, such as automatic insulin (or other medication) delivery processes, insulin (or other medication) dose guidance systems and therapy 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 missed medication doses as described here. For example, a therapy guidance system may provide therapy change recommendations based on glucose data that excludes glucose data associated with missed medication doses. In other embodiments, an automated insulin delivery system may utilize an adaptive model; the adaptive processing may be based on glucose data excluding glucose data where medication doses are missed. Docket No. A0130.0317.WO 14890WOO1 [00270] In other embodiments, a plurality of graphs may be presented in a comparative profiles report. By leveraging dosing data of medications from, e.g., connected drug delivery devices, and analyte data from continuous analyte monitors as inputs, in many embodiments, a GUI or report may include a plurality of analyte profiles over a selected time period. As seen in FIGS.18A-18B, in some embodiments, the GUI or report may include two, alternatively two or more, alternatively three, alternatively four, alternatively five, alternatively six, alternatively six or more versions of analyte profiles over a selected time period. The analytes may be, but are not limited to, acetyl choline, amylase, bilirubin, cholesterol, chorionic gonadotropin, glycosylated hemoglobin (HbA1c), creatine kinase (e.g., CK-MB), creatine, creatinine, DNA, fructosamine, glucose, glucose derivatives, glutamine, growth hormones, hormones, ketones, ketone bodies, lactate, peroxide, prostate-specific antigen, prothrombin, RNA, thyroid stimulating hormone, and troponin. The analyte profiles may be any of the different types of graphs that were described with respect to other embodiments, such as the glucose profiles. [00271] In some embodiments, the plurality of graphs may include at least 2 graphs, alternatively at least 3 graphs, alternatively at least 4 graphs, alternatively at least 5 graphs, alternatively at least 6 graphs, alternatively at least 7 graphs, alternatively at least 8 graphs. Each of the plurality of graphs may display a different data set. In some embodiments, where a person is taking multiple medications at a time, a graph may be a display or presentation of all of the data from a time period, and two graphs may be displayed for each type of medication taken. For each medication, a first graph may include analyte measurements taken during a window of time following, or associated with, the administration of the medicine and a second graph may include analyte measurements taken during a window of time following, or associated with, missed administration(s) of the medicine. Thus, for a person taking n medications, a plurality of graphs that include 2n + 1 graphs may be presented. As explained earlier with respect to other embodiments, the window of time following, or associated with, the administration of the medicine may be determined by the duration of action of the medication(s) being administered. Detecting if Medication is taken or not [00272] Determination of whether a medication is delivered into the patient may be readily determined using a connected medication delivery device. For medication delivery Docket No. A0130.0317.WO 14890WOO1 devices (such as a syringe) that are not connected, the system may use another means of determining if a medication is delivered. The system may provide a UI in which the patient can log whenever they take a medication. In addition, the system may include a predefined time of day window when the patient usually takes the medication, and if a medication log is not made in this time window, then the system may prompt the patient to confirm whether or not they took the medication. For oral medications, connected pill boxes or similar devices may be used to determine if the medication was taken. The system may provide a combination of connected device and UI means, where if the connected device did not indicate that a medication was taken, then the system may prompt the patient to confirm that they did not (or did) take the medication. [00273] When a medication is taken later than the typical or prescribed time of day window, the glucose data associated with that time of day may be excluded. Similarly, glucose data associated with the time of day where the dose is taken late may also be excluded. The glucose data associated with these time-of-day periods may be included in some form of data analysis; for instance, for the purpose of showing the effect on glucose metrics when doses are taken late. In this case, the glucose during time-of-day periods associated with doses taken late may be included in the metric calculation only and may be compared to a metric calculated using glucose data from time-of-day periods only where doses are taken on time. [00274] Various aspects of the present subject matter are set forth below, in review of, and/or in supplementation to, the embodiments described thus far, with the emphasis here being on the interrelation and interchangeability of the following embodiments. In other words, an emphasis is on the fact that each feature of the embodiments can be combined with each and every other feature unless explicitly stated otherwise or logically implausible. The embodiments described herein are restated and expanded upon in the following paragraphs without explicit reference to the figures. [00275] In many embodiments, an analyte monitoring system includes a reader device, comprising: a display; wireless communication circuitry configured to receive, from an on-body unit comprising a glucose sensor, a first type of data, and to receive, from a medication delivery device, a second type of data, wherein the first type of data comprises data indicative of an analyte level of the subject, and wherein the second type of data comprises medication delivery Docket No. A0130.0317.WO 14890WOO1 device identification data and dose 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 of data and the second type of data in the memory; receive an indication of the user signing-in to a remote server, and in response thereto, send the first type of data and the second type of data to the remote server; and receive an indication of the user signing out from the remote server, and in response thereto, stop sending the first type of data and the second type of data to the remote server. [00276] In some embodiments, the analyte monitoring system further includes the remote server, the remote server comprising: one or more processors of the 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: detect the indication of the user signing in from the remote server, and in response thereto, sharing the first type of data and the second type of data with an authorized third party or application; and detect the indication of the user signing out from the remote server, and in response thereto, stop sharing the first type of data and the second type of data with an authorized third party or application. In some embodiments, the analyte monitoring system further includes the remote server, the remote server comprising: one or more processors of the 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: detect the indication of the user signing in to the remote server, and in response thereto, sharing the first type of data and the second type of data with an authorized third party or application; and detect the indication of the user signing out from the remote server, and in response thereto, stop sharing 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 stores instructions that, when executed by the 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 the authorized third party or application. In some embodiments the memory of the remote server further 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 the authorized third party or application after the user authorizes sharing the first type of data and the second type of data, or in response to a user authorization. Docket No. A0130.0317.WO 14890WOO1 [00277] In some embodiments, the memory of the reader device further stores instructions that causes the one or more processors of the reader device to: receive an indication of the user signing back in after signing out for a first period of time, and in response thereto, send the first type of data and the second type of data stored during the first period of time to the remote server; and wherein the memory of the remote server further stores instructions that cause the one or more processors of the remote server to: detect the indication of the user signing back in after signing out for the first period of time and the first type of data and the second type of data stored during the first period of time, and in response thereto, share the first type of data and the second type of data stored during the first period of time with the authorized third party or application. [00278] In some embodiments, wherein the memory of the remote server further stores instructions that cause the one or more processors of the remote server to: automatically share the first type of data and the second type of data with the authorized third party or application. [00279] In some embodiments, wherein the memory of the remote server further 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 stored during the first period of time with the authorized third party or application after the user authorizes sharing the first type of data and the second type of data stored during the first period of time. [00280] In some embodiments, the memory of the reader device further stores instructions that cause the one or more processors of the reader device to: receive an indication of the user deleting an account associated with the user from the remote server, and in response thereto, delete the first type of data and the second type of data stored in the memory of the reader device. [00281] In some embodiments, the memory of the remote server further stores instructions that cause the one or more processors of the remote server to: detect the indication of the user deleting the account associated with the user, and in response thereto, deleting the first type of data and the second type of data stored on the remote server. [00282] In some embodiments, the memory of the reader device further stores instructions that cause the one or more processors of the reader device to: in response to receiving an indication of the user deleting the account associated with the user, display a graphical user Docket No. A0130.0317.WO 14890WOO1 interface to prompt the user to confirm deletion before deleting the first type of data and the second type of data. [00283] In some embodiments, the GUI to prompt the user to confirm deletion includes a request to enter a password of the user. [00284] In some embodiments, the memory of the remote server further stores instructions that cause the one or more processors of the remote server to: in response to receiving an indication of the user deleting the account associated with the user, store the first type of data and the second type of data in a secured compartment before deleting the first type of data and the second type of data stored in the memory. [00285] In some embodiments, the secured compartment requires a password or verification code for access. [00286] 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. [00287] In many embodiments, an analyte monitoring system includes a reader device, comprising: a display; wireless communication circuitry configured to receive, from an on-body unit comprising a glucose sensor, a first type of data, and to receive, from a medication delivery device, a second type of data, wherein the first type of data comprises data indicative of an analyte level of the subject, and wherein the second type of data comprises error data associated with the medication delivery device; 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: display information associated with the data indicative of the analyte level of the subject; and display a message based on the received error data. [00288] In some embodiments, the message is displayed in a modal window. [00289] In some embodiments, the message is displayed in a banner. [00290] In some embodiments, the error data comprises data indicative of a number of failed scans of the medication delivery device. In some embodiments, the message is displayed if the number of failed scans exceeds a threshold value. In some embodiments, the message comprises a tip related to scanning the medication delivery device. In some embodiments, the message comprises an animation depicting how to scan the medication delivery device. Docket No. A0130.0317.WO 14890WOO1 [00291] In many embodiments, a method for managing diabetes includes the steps of: receiving a first type of data comprising data indicative of an analyte level of a subject and a second type of data comprising error data associated with the medication delivery device; display information associated with the data indicative of the analyte level of the subject; and display a message based on the received error data. [00292] In some embodiments, the error data comprises data indicative of a number of failed scans of the medication delivery device. In some embodiments, the message is displayed if the number of failed scans is above a threshold value. In some embodiments, the message comprises a helpful tip related to scanning the medication delivery device. In some embodiments, the message comprises an animation depicting how to scan the medication delivery device. [00293] In many embodiments, an analyte monitoring system includes: a reader device, comprising: a display; wireless communication circuitry configured to receive, from an on-body unit comprising a glucose sensor, a first type of data, and to receive, from a medication delivery device, a second type of data, wherein the first type of data comprises data indicative of an analyte level of the subject, and wherein the second type of data comprises medication dosing 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: determine if the second type of data received from the medication delivery device satisfies a minimum dosing data report condition for inclusion into a report, wherein the report comprises metrics based on the first type of data and dosing information based on the second type of data; generate the report if the received second type of data is determined to be sufficient; and display a message regarding the report. [00294] In some embodiments, the minimum dosing data report condition comprises a sufficient amount of second type of data to generate a weekly report. [00295] In some embodiments, the minimum dosing data report condition comprises a sufficient amount of second type of data to generate a daily report. [00296] In some embodiments, the second type of data received is determined to satisfy the minimum dosing data report condition if the second type of data received comprises dosing data for at least 1 day. Docket No. A0130.0317.WO 14890WOO1 [00297] In some embodiments, the second type of data received is determined to satisfy the minimum dosing data report condition if the second type of data received comprises dosing data for at least 3 days. [00298] In some embodiments, the second type of data received is determined to satisfy the minimum dosing data report condition if the second type of data received comprises dosing data for at least 1 week. [00299] In some embodiments, the message states that the report is available. [00300] In some embodiments, the message comprises a link to the report. [00301] 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. [00302] In many embodiments, a method for managing diabetes includes the steps of: receiving a first type of data comprising data indicative of an analyte level of a subject and a second type of data comprising medication dosing data; determining if the second type of data received from the medication delivery device satisfies a minimum dosing data report condition for inclusion into a report, wherein the report comprises metrics based on the first type of data and dosing information based on the second type of data; generating the report if the received second type of data satisfies a minimum report condition for inclusion into a report; and displaying a message regarding the report. [00303] In some embodiments, the method further includes the step of determining if the first type of data received satisfies a minimum analyte data report condition for inclusion into the report. In some embodiments, the minimum dosing data report condition comprises a sufficient amount of second type of data to generate a weekly report. In some embodiments, the minimum dosing data report condition comprises a sufficient amount of second type of data to generate a daily report. [00304] In some embodiments, the second type of data received satisfies the minimum dosing data report condition if the second type of data received comprises dosing data for at least 1 day. [00305] In some embodiments, the second type of data received satisfies the minimum dosing data report condition if the second type of data received comprises dosing data for at least 3 days. Docket No. A0130.0317.WO 14890WOO1 [00306] In some embodiments, the second type of data received satisfies the minimum dosing data report condition if the second type of data received comprises dosing data for at least 1 week. [00307] In some embodiments, the message states that the report is available. [00308] In some embodiments, the message comprises a link to the report. [00309] In some embodiments, the data indicative of an analyte level is data indicative of a glucose level. In some embodiments, the data indicative of an analyte level is data indicative of a ketone level. In some embodiments, the data indicative of an analyte level is data indicative of a lactate level. [00310] In many embodiments, an analyte monitoring system includes: a reader device, comprising: a display; wireless communication circuitry configured to receive, from an on-body unit comprising a glucose sensor, a first type of data, and to receive, from a medication delivery device, a second type of data, wherein the first type of data comprises data indicative of an analyte level of the subject, and wherein the second type of data comprises medication dosing 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: determine if a time period elapsed since receipt of the second type of data from the medication delivery device exceeds a threshold value; and display a message prompting a user to transfer the second type of data. [00311] In some embodiments, the message comprises a reminder to scan the medication delivery device. [00312] In some embodiments, the threshold value is 24 hours. [00313] In many embodiments, a method for managing diabetes includes the steps of: receiving a first type of data comprising data indicative of an analyte level of a subject and a second type of data comprising medication dosing data; determining if a time period elapsed since receipt of the second type of data exceeds a threshold value; and display a message prompting the user to transfer the second type of data. [00314] In some embodiments, the second type of data is received from a medication delivery device, and wherein the message comprises a reminder to scan the medication delivery device. [00315] In some embodiments, the threshold value is 24 hours. Docket No. A0130.0317.WO 14890WOO1 [00316] 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. Clauses Exemplary embodiments are set out in the following numbered clauses. Clause 1. An analyte monitoring system, comprising: a reader device, comprising: a display; wireless communication circuitry configured to receive, from an on-body unit comprising an analyte sensor, a first type of data, and to receive, from a medication delivery device, a second type of data, wherein the first type of data comprises data indicative of an analyte level of the subject, and wherein the second type of data comprises medication delivery device identification data and dose 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 of data and the second type of data in the memory; receive an indication of the user signing-in to a remote server, and in response thereto, send the first type of data and the second type of data to the remote server; and receive an indication of the user signing out from the remote server, and in response thereto, stop sending the first type of data and the second type of data to the remote server. Clause 2. The analyte monitoring system of clause 1, further comprising the remote server, the remote server comprising: one or more processors of the 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: Docket No. A0130.0317.WO 14890WOO1 detect the indication of the user signing in from the remote server, and in response thereto, sharing the first type of data and the second type of data with an authorized third party or application; and detect the indication of the user signing out from the remote server, and in response thereto, stop sharing the first type of data and the second type of data with an authorized third party or application. Clause 3. The analyte monitoring system of any of clauses 1-2, wherein the memory of the reader device further stores instructions that causes the one or more processors of the reader device to: receive an indication of the user signing back in after signing out for a first period of time, and in response thereto, send the first type of data and the second type of data stored during the first period of time to the remote server; and wherein the memory of the remote server further stores instructions that cause the one or more processors of the remote server to: detect the indication of the user signing back in after signing out for the first period of time and the first type of data and the second type of data stored during the first period of time, and in response thereto, share the first type of data and the second type of data stored during the first period of time with the authorized third party or application. Clause 4. The analyte monitoring system of any of clauses 1-3, wherein the memory of the remote server further stores instructions that cause the one or more processors of the remote server to: automatically share the first type of data and the second type of data with the authorized third party or application. Clause 5. The analyte monitoring system of any of clauses 1-4, wherein the memory of the remote server further 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 stored during the first period of time with the authorized third party or application after the user authorizes Docket No. A0130.0317.WO 14890WOO1 sharing the first type of data and the second type of data stored during the first period of time. Clause 6. The analyte monitoring system of any of clauses 1-5, wherein the memory of the reader device further stores instructions that cause the one or more processors of the reader device to: receive an indication of the user deleting an account associated with the user from the remote server, and in response thereto, delete the first type of data and the second type of data stored in the memory of the reader device. Clause 7. The analyte monitoring system of any of clauses 1-6, wherein the memory of the remote server further stores instructions that cause the one or more processors of the remote server to: detect the indication of the user deleting the account associated with the user, and in response thereto, deleting the first type of data and the second type of data stored on the remote server. Clause 8. The analyte monitoring system of any of clauses 1-7, wherein the memory of the reader device further stores instructions that cause the one or more processors of the reader device to: in response to receiving an indication of the user deleting the 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. Clause 9. The analyte monitoring system of any of clauses 1-8, wherein the GUI to prompt the user to confirm deletion includes a request to enter a password of the user. Clause 10. The analyte monitoring system of any of clauses 1-9, wherein the memory of the remote server further stores instructions that cause the one or more processors of the remote server to: in response to receiving an indication of the user deleting the account associated with the user, store the first type of data and the second type of data in a secured Docket No. A0130.0317.WO 14890WOO1 compartment before deleting the first type of data and the second type of data stored in the memory. Clause 11. The analyte monitoring system of clause 10, wherein the secured compartment requires a password or verification code for access. Clause 12. An analyte monitoring system, comprising: a reader device, comprising: a display; wireless communication circuitry configured to receive, from an on-body unit comprising an analyte sensor, a first type of data, and to receive, from a medication delivery device, a second type of data, wherein the first type of data comprises data indicative of an analyte level of the subject, and wherein the second type of data comprises error data associated with the medication delivery device; 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: display information associated with the data indicative of the analyte level of the subject; and display a message based on the received error data. Clause 13. The analyte monitoring system of clause 12, wherein the message is displayed in a modal window. Clause 14. The analyte monitoring system of any of clauses 12-13, wherein the message is displayed in a banner. Clause 15. The analyte monitoring system of any of clauses 12-14, wherein the error data comprises data indicative of a number of failed scans of the medication delivery device. Clause 16. The analyte monitoring system of any of clauses 12-15, wherein the message is displayed if the number of failed scans exceeds a threshold value. Docket No. A0130.0317.WO 14890WOO1 Clause 17. The analyte monitoring system of any of clauses 12-16, wherein the message comprises a tip related to scanning the medication delivery device. Clause 18. The analyte monitoring system of any of clauses 12-17, wherein the message comprises an animation depicting how to scan the medication delivery device. Clause 19. A method for managing diabetes, comprising the steps of: receiving a first type of data comprising data indicative of an analyte level of a subject and a second type of data comprising error data associated with the medication delivery device; display information associated with the data indicative of the analyte level of the subject; and display a message based on the received error data. Clause 20. The method of clause 19, wherein the error data comprises data indicative of a number of failed scans of the medication delivery device. Clause 21. The method of any of clauses 19-20, wherein the message is displayed if the number of failed scans is above a threshold value. Clause 22. The method of any of clauses 19-22, wherein the message comprises a helpful tip related to scanning the medication delivery device. Clause 23. The method of any of clauses 19-23, wherein the message comprises an animation depicting how to scan the medication delivery device. Clause 24. An analyte monitoring system, comprising: a reader device, comprising: a display; wireless communication circuitry configured to receive, from an on-body unit comprising an analyte sensor, a first type of data, and to receive, from a medication delivery device, a second type of data, wherein the first type of data comprises data indicative of an analyte level of the subject, and wherein the second type of data comprises medication dosing data; and Docket No. A0130.0317.WO 14890WOO1 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: determine if the second type of data received from the medication delivery device satisfies a minimum dosing data report condition for inclusion into a report, wherein the report comprises metrics based on the first type of data and dosing information based on the second type of data; generate the report if the received second type of data is determined to be sufficient; and display a message regarding the report. Clause 25. The system of clause 24, wherein the minimum dosing data report condition comprises a sufficient amount of second type of data to generate a weekly report. Clause 26. The system of any of clauses 24-25, wherein the minimum dosing data report condition comprises a sufficient amount of second type of data to generate a daily report. Clause 27. The system of any of clauses 24-26, wherein the second type of data received is determined to satisfy the minimum dosing data report condition if the second type of data received comprises dosing data for at least 1 day. Clause 28. The system of any of clauses 24-27, wherein the second type of data received is determined to satisfy the minimum dosing data report condition if the second type of data received comprises dosing data for at least 3 days. Clause 29. The system of any of clauses 24-28, wherein the second type of data received is determined to satisfy the minimum dosing data report condition if the second type of data received comprises dosing data for at least 1 week. Clause 30. The system of any of clauses 24-29, wherein the message states that the report is available. Clause 31. The system of any of clauses 24-30, wherein the message comprises a link to the report. Docket No. A0130.0317.WO 14890WOO1 Clause 32. A method for managing diabetes, comprising the steps of: receiving a first type of data comprising data indicative of an analyte level of a subject and a second type of data comprising medication dosing data; determining if the second type of data received from the medication delivery device satisfies a minimum dosing data report condition for inclusion into a report, wherein the report comprises metrics based on the first type of data and dosing information based on the second type of data; generating the report if the received second type of data satisfies a minimum report condition for inclusion into a report; and displaying a message regarding the report. Clause 33. The method of clause 32, further comprising the step of determining if the first type of data received satisfies a minimum analyte data report condition for inclusion into the report. Clause 34. The method of any of clauses 32-33, wherein the minimum dosing data report condition comprises a sufficient amount of second type of data to generate a weekly report. Clause 35. The method of any of clauses 32-34, wherein the minimum dosing data report condition comprises a sufficient amount of second type of data to generate a daily report. Clause 36. The method of any of clauses 32-35, wherein the second type of data received satisfies the minimum dosing data report condition if the second type of data received comprises dosing data for at least 1 day. Clause 37. The method of any of clauses 32-36, wherein the second type of data received satisfies the minimum dosing data report condition if the second type of data received comprises dosing data for at least 3 days. Clause 38. The method of any of clauses 32-37, wherein the second type of data received satisfies the minimum dosing data report condition if the second type of data received comprises dosing data for at least 1 week. Docket No. A0130.0317.WO 14890WOO1 Clause 39. The method of any of clauses 32-38, wherein the message states that the report is available. Clause 40. The method of any of clauses 32-39, wherein the message comprises a link to the report. Clause 41. An analyte monitoring system, comprising: a reader device, comprising: a display; wireless communication circuitry configured to receive, from an on-body unit comprising a glucose sensor, a first type of data, and to receive, from a medication delivery device, a second type of data, wherein the first type of data comprises data indicative of an analyte level of the subject, and wherein the second type of data comprises medication dosing 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: determine if a time period elapsed since receipt of the second type of data from the medication delivery device exceeds a threshold value; and display a message prompting a user to transfer the second type of data. Clause 42. The system of clause 41, wherein the message comprises a reminder to scan the medication delivery device. Clause 43. The system of any of clauses 41-42, wherein the threshold value is 24 hours. Clause 44. A method for managing diabetes, comprising the steps of: receiving a first type of data comprising data indicative of an analyte level of a subject and a second type of data comprising medication dosing data; determining if a time period elapsed since receipt of the second type of data exceeds a threshold value; and display a message prompting the user to transfer the second type of data. Docket No. A0130.0317.WO 14890WOO1 Clause 45. The method of clause 44, wherein the second type of data is received from a medication delivery device, and wherein the message comprises a reminder to scan the medication delivery device. Clause 46. The method of any of clauses 44-45, wherein the threshold value is 24 hours.