WO2025145062A1 - Improved user interface to enable accurate medication calculations with unconnected devices - Google Patents

Abstract

Disclosed herein are system, method, and computer program product embodiments for calculating accurate doses for medication using improved user interface features that may be implemented as part of an application operating within a continuous glucose monitoring system. The disclosed interface provides an improved user experience when a medication delivery device is disconnected or does not have the ability to query the requisite data.

Description

IMPROVED USER INTERFACE TO ENABLE ACCURATE MEDICATION CALCULATIONS WITH UNCONNECTED DEVICES

CROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of U.S. Provisional Application No.

63/616,285, filed December 29, 2023, which is hereby incorporated by reference in its entirety.

BACKGROUND

[0002] Many diabetics actively manage their diabetes, including monitoring and logging their blood sugar before meals, at bedtime, and at various other points throughout a day. This vigilance facilitates a determination of the appropriate amount of a medication (e.g., insulin) to administer.

[0003] The dose amounts of medications may change over time based on a number of factors including food intake, activity level, analyte (e.g., glucose) measurements, and previous dosing times/amounts. The burdensome responsibility of tracking and managing these multiple factors typically falls on a user. Failure to accurately account for each factor may result in mistakes and unsafe or ineffective dose amounts.

SUMMARY

[0004] Accordingly, a need exists to calculate accurate doses of medication using improved user interface features. These features may be implemented as part of an application operating within a continuous glucose monitoring (“CGM”) system. A display device may display the dosage recommendation even when disconnected from a medication delivery device, providing users with more-informed recommended doses.

[0005] CGM systems allow diabetics to monitor their glucose levels at regular intervals. CGM tools may include a dosage calculator that automates the medication-dosage calculation based on relevant factors (e.g., food intake, activity level, analyte measurements, previous doses, etc.). To compute a dose, a dosage calculator must have information on the most recent dose (i.e., amount, timing, or both). Because a drug imparts its pharmacological action over a specific time window, an accurate dosage calculator must account for actively circulating drug from previously administered doses during that time window when computing a new recommended dose amount.

[0006] Within the context of insulin administration, the amount of active circulating drug from previous administrations is referred to as Insulin-On-Board (“IOB”). Failure to account for IOB may create insulin stacking, causing an excess of circulating insulin that could result in hypoglycemia. To calculate IOB, a dosage calculator must confirm that no doses have been taken within an insulin action time, typically 4 hours. This can be rapidacting or meal-time insulin. This insulin action time will be referred to below as the duration of insulin action (“DIA”).

[0007] While some legacy CGM systems offer a dosage calculator, technical issues persist, especially involving the tracking of previous doses. This is especially true because a dosage calculator may be connected to a medication delivery device that administers doses. However, a medication delivery device may disconnect from the user’s mobile application and/or the information on the medication delivery device may otherwise not be available to the dosage calculator. An example of a medication delivery device is an insulin pump or an insulin pen. Such a medication delivery device typically stores historical dosage information and may, when connected, provide this information to the dosage calculator. However, when the medication delivery device is not connected that information may not be available to the dosage calculator. Some devices may suffer periodic connectivity issues that prevent continuous, accurate, real-time calculations. Additionally, some medication delivery devices lack querying functionality through which the dosage calculator may access the dosage history.

[0008] In legacy tools, in such situations, dosage calculators on a mobile application must be disabled because the dosage calculator has incomplete information or, worse, may provide inaccurate dosage calculations on the basis of the incomplete information. Accordingly, a need exists to calculate accurate doses even when a medication delivery device is disconnected or lacks a query function.

[0009] Some legacy tools may try to solve this problem by immediately prompting the user to confirm the most recent dose prior to providing dose guidance. However, such approaches do not offer an appealing user-interface design because the first screen that the patient sees when engaging the application for dose guidance is a prompt for confirmation. [0010] The disclosed technique thus achieves an additional technical benefit by providing an enhanced landing page in a graphical user interface. For example, an additional technical benefit may be achieved by disabling or “greying-ouf ’ icons to initiate a dose calculation until a user has updated their dosing history. This aims to enhance safety because a user cannot accidentally receive a dose calculation with incomplete information. In one embodiment, the screen for providing dosage information may become available to the user by tapping on the greyed-out dose calculation icon or by tapping on a separate icon. The separate icon to provide new dose information may be labeled as to “input doses” or something similar.

[0011] The approach may integrate with a connected medication delivery device that does not have the requisite ability to query the data. Using information gathered from the user through the enhanced user interface, the dosage calculator may then calculate IOB using a curvilinear decay of active circulating insulin over the DIA. DIA may be defined as the time window during which insulin imparts its pharmacological effects, such as decreasing blood glucose levels. In one embodiment, the DIA may be fixed according to insulin subtype. In another embodiment, DIA may be a user- or clinician-configurable setting to accommodate different patient reactions to the medication.

[0012] In an alternative embodiment, the enhanced user interface may present a dose calculation to the user but indicate that this dose amount is based upon the most recent user-supplied dose information. In this embodiment, the dosage calculator may simultaneously display the most recently user-supplied dose information. At this point, the user may select to add new, previously unaccounted-for doses or confirm the most recent dose. The dose logging feature may also have an option for the user to select the reason for dosing, such as a specific meal or to correct for high glucose. The mobile application may use the additional information to populate a dose logbook for the user and their care provider or to titrate specific mealtime insulin dose amounts. Regarding the latter, time periods with unconfirmed dosing may be excluded from titration calculations to allow titration to be based only off of confirmed periods of dosing.

[0013] Once the user begins the process of updating their dose history, the application may present the most recent user-recorded insulin dose to the user. The application may also ask the user if new doses were administered within the DIA. The application may visually represent DIA in different ways to the user. These may include, but are not limited to:

(a) A question to the user asking if they have administered any insulin within the specified DIA. This may also be represented as asking a question if they have administered any insulin since XX:XX AM/PM, where the time presented is simply computed as the current time less the DIA. Such an approach is discussed in further detail below with reference to FIG. 12B.

(b) Similar to (a), but with a visual representation of the DIA in a clock format where a shaded region represents the DIA since the dose request time and where any previously reported doses within that window are highlighted according to the time when the dose was reported. Such an approach is discussed in further detail below with reference to FIG. 12D.

(c) Similar to (a), but with a visual representation of the DIA in a linear timeline with time of day along the x-axis where the DIA since the dose request time is shaded and where any previously reported doses within that window are highlighted according to the time when the dose was reported. Such an approach is discussed in further detail below with reference to FIG. 12E.

[0014] An additional technical benefit may be achieved by including an option to edit the dose if the user decides to take a dose different from the amount recommended. The user interface may display a message collocated with the next dose recommendation indicating that the current calculation is made assuming the prior dose(s) were actually what was recommended by the system, providing a user-interface means for the patient to correct the amount that was logged for prior doses if needed. In this way, for users that typically take the doses recommended, the user interface is straightforward and simple. But for users that do not take the recommended dosage, the calculations may be easily corrected and considered in subsequent dosage calculations. Example screen displays illustrating this embodiment are discussed in further detail below with reference to FIGS. 13A-D.

[0015] Disclosed herein are system, method, and computer program product embodiments for calculating accurate doses for medication using improved user interface features that may be implemented as part of an application operating within a continuous glucose monitoring system. The disclosed interface provides an improved user experience when a medication delivery device is disconnected or does not have the ability to query the requisite data.

[0016] In many embodiments, a method comprises: responsive to determining that a display device configured to be in data communication with an in vivo analyte sensor is not in data communication with a medication delivery device, preventing, by one or more processors, activation of a display of a dose suggestion icon on a graphical user interface of a mobile application on the display device; and responsive to receiving an updated dosage history via a user input: calculating a dosage of medication to be administered by the medication delivery device; and activating the display of the dose suggestion icon in the graphical user interface, wherein the dose suggestion icon indicates the dosage of medication.

[0017] In many embodiments, a method comprises: responsive to determining that a display device configured to be in data communication with an in vivo analyte sensor is not in data communication with a medication delivery device, preventing, by one or more processors, a display of a dose suggestion icon on a graphical user interface of a mobile application on the display device; and responsive to receiving an updated dosage history via a user input: calculating a dosage of medication to be administered by the medication delivery device; and activating the display of the dose suggestion icon in the graphical user interface, wherein the dose suggestion icon indicates the dosage of medication.

[0018] In some embodiments the method further comprises: providing a confirmation screen to receive the updated dosage history, wherein the confirmation screen comprises a last dose, a time of the last dose, and a duration of insulin action.

[0019] In some embodiments the confirmation screen further comprises a visual representation of the duration of insulin action, wherein the visual representation is a clock having a shaded region representing the duration of insulin action.

[0020] In some embodiments the visual representation further comprises: a previously reported dose indicated on the clock according to a time of the previously reported dose.

[0021] In some embodiments the confirmation screen further comprises a visual representation of the duration of insulin action, wherein the visual representation is a linear timeline having a shaded region representing the duration of insulin action. [0022] In some embodiments the visual representation further comprises: a previously reported dose indicated on the linear timeline according to a time of the previously reported dose.

[0023] In some embodiments, the preventing further comprises at least one of: disabling the dose suggestion icon on the graphical user interface; and greying the dose suggestion icon on the graphical user interface.

[0024] In some embodiments the activating further comprises at least one of: enabling the dose suggestion icon on the graphical user interface; coloring the dose suggestion icon on the graphical user interface; and displaying the dosage of medication within the dose suggestion icon.

[0025] In some embodiments the user input comprises a confirmation of at least one previous dosage of medication administered by the medication delivery device.

[0026] In some embodiments the dose suggestion icon is a meal icon, wherein the meal icon is associated with a meal type, and wherein the dosage of medication is calculated based on the meal type.

[0027] In some embodiments the calculating further comprises: retrieving one or more parameters associated with the meal type, wherein the one or more parameters comprise a glycemic index, a glycemic load, a rate of glucose appearance profile in an averaged person with standard food bioavailability, a macronutrient composition, and/or a fiber content.

[0028] In some embodiments the method further comprises: receiving an adjustment input configured to adjust the dosage of medication; and displaying an adjusted dosage of medication based on the adjustment input in the graphical user interface.

[0029] In many embodiments, a system comprises: a memory; at least one processor coupled to the memory and configured to: responsive to determining that a display device configured to be in data communication with an in vivo analyte sensor is not in data communication with a medication delivery device, prevent activation of a display of a dose suggestion icon on a graphical user interface of a mobile application on the display device; and responsive to receiving an updated dosage history via a user input: calculate a dosage of medication to be administered by the medication delivery device; and activate the display of the dose suggestion icon in the graphical user interface, wherein the dose suggestion icon indicates the dosage of medication. [0030] In many embodiments, a system comprises: a memory; at least one processor coupled to the memory and configured to: responsive to determining that a display device configured to be in data communication with an in vivo analyte sensor is not in data communication with a medication delivery device, prevent a display of a dose suggestion icon on a graphical user interface of a mobile application on the display device; and responsive to receiving an updated dosage history via a user input: calculate a dosage of medication to be administered by the medication delivery device; and activate the display of the dose suggestion icon in the graphical user interface, wherein the dose suggestion icon indicates the dosage of medication.

[0031] In some embodiments, the at least one processor is further configured to: display a confirmation screen to receive the updated dosage history, wherein the confirmation screen comprises a last dose, a time of the last dose, and a duration of insulin action, wherein the confirmation screen comprises a visual representation of the duration of insulin action, wherein the visual representation is a clock, wherein the visual representation further comprises a shaded region representing the duration of insulin action, and wherein a previously reported dose is indicated on the clock according to a time of the previously reported dose.

[0032] In some embodiments, the at least one processor is further configured to: display a confirmation screen to receive the updated dosage history, wherein the confirmation screen comprises a last dose, a time of the last dose, and a duration of insulin action, wherein the confirmation screen comprises a visual representation of the duration of insulin action, wherein the visual representation is a linear timeline, wherein the visual representation further comprises a shaded region representing the duration of insulin action, and wherein a previously reported dose is indicated on the linear timeline according to a time of the previously reported dose.

[0033] In some embodiments, to prevent the at least one processor is further configured to at least one of: disable the dose suggestion icon on the graphical user interface; and grey the dose suggestion icon on the graphical user interface.

[0034] In some embodiments, to activate the at least one processor is further configured to at least one of: enable the dose suggestion icon on the graphical user interface; and color the dose suggestion icon on the graphical user interface. [0035] In some embodiments, the user input comprises a confirmation of at least one previous dosage of medication administered by the medication delivery device.

[0036] In some embodiments, the dose suggestion icon is a meal icon, wherein the meal icon is associated with a meal type, and wherein the dosage of medication is calculated based the meal type.

[0037] In many embodiments, a non-transitory computer-readable device has instructions stored thereon that, when executed by a computing device, causes the computing device to perform operations comprising: responsive to determining that a display device configured to be in data communication with an in vivo analyte sensor is not in data communication with a medication delivery device, preventing activation of a display of a dose suggestion icon on a graphical user interface of a mobile application on the display device; and responsive to receiving an updated dosage history via a user input: calculating a dosage of medication to be administered by the medication delivery device; and activating the display of the dose suggestion icon in the graphical user interface, wherein the dose suggestion icon indicates the dosage of medication.

[0038] In many embodiments, a non-transitory computer-readable device has instructions stored thereon that, when executed by a computing device, causes the computing device to perform operations comprising: responsive to determining that a display device configured to be in data communication with an in vivo analyte sensor is not in data communication with a medication delivery device, preventing a display of a dose suggestion icon on a graphical user interface of a mobile application on the display device; and responsive to receiving an updated dosage history via a user input: calculating a dosage of medication to be administered by the medication delivery device; and activating the display of the dose suggestion icon in the graphical user interface, wherein the dose suggestion icon indicates the dosage of medication.

[0039] While this disclosure references insulin administration, this concept is generalizable to any drug with a known pharmacodynamic profile.

BRIEF DESCRIPTION OF THE DRAWINGS

[0040] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments of the present disclosure and, together with the description, further serve to explain the principles of the disclosure and to enable a person skilled in the arts to make and use the embodiments.

[0041] FIG. 1 A is a system overview of a sensor applicator, display device, monitoring system, network, and remote system.

[0042] FIG. IB is a diagram illustrating an operating environment of an example analyte monitoring system for use with the techniques described herein.

[0043] FIG. 2A is a block diagram depicting an example embodiment of a display device.

[0044] FIG. 2B is a block diagram illustrating an example display device for communicating with the sensor according to exemplary embodiments of the disclosed subject matter.

[0045] FIGS. 2C and 2D are block diagrams depicting example embodiments of sensor control devices.

[0046] FIG. 2E is a block diagram illustrating an example analyte sensor according to exemplary embodiments of the disclosed subject matter.

[0047] FIG. 3 A is a proximal perspective view depicting an example embodiment of a user preparing a tray for an assembly.

[0048] FIG. 3B is a side view depicting an example embodiment of a user preparing an applicator device for an assembly.

[0049] FIG. 3C is a proximal perspective view depicting an example embodiment of a user inserting an applicator device into a tray during an assembly.

[0050] FIG. 3D is a proximal perspective view depicting an example embodiment of a user removing an applicator device from a tray during an assembly.

[0051] FIG. 3E is a proximal perspective view depicting an example embodiment of a patient applying a sensor using an applicator device.

[0052] FIG. 3F is a proximal perspective view depicting an example embodiment of a patient with an applied sensor and a used applicator device.

[0053] FIG. 4A is a side view depicting an example embodiment of an applicator device coupled with a cap.

[0054] FIG. 4B is a side perspective view depicting an example embodiment of an applicator device and cap decoupled.

[0055] FIG. 4C is a perspective view depicting an example embodiment of a distal end of an applicator device and electronics housing. [0056] FIG. 4D is a top perspective view of an exemplary applicator device in accordance with the disclosed subject matter.

[0057] FIG. 4E is a bottom perspective view of the applicator device of FIG. 4D.

[0058] FIG. 4F is an exploded view of the applicator device of FIG. 4D.

[0059] FIG. 4G is a side cutaway view of the applicator device of FIG. 4D.

[0060] FIG. 5 is a diagram illustrating example operational states of the sensor according to exemplary embodiments of the disclosed subject matter.

[0061] FIG. 6 is a diagram illustrating an example operational and data flow for over-the- air programming of a sensor according to the disclosed subject matter.

[0062] FIG. 7 is a diagram illustrating an example data flow for secure exchange of data between two devices according to the disclosed subject matter.

[0063] FIG. 8A is a schematic diagram depicting an example embodiment of a medication delivery device.

[0064] FIG. 8B is a block diagram depicting an example embodiment of a medication delivery device.

[0065] FIG. 9 is a block diagram of a CGM system that provides a dosage calculator, according to some embodiments.

[0066] FIG. 10 illustrates a method for recommending insulin doses, according to some embodiments.

[0067] FIG. 11 illustrates a method for implementing graphical user interfaces that provide dosage recommendations based on detected connectivity conditions, according to some embodiments.

[0068] FIGS. 12A-F are exemplary graphical user interfaces for receiving user input regarding dosage history, according to some embodiments.

[0069] FIG. 13A-D are exemplary graphical user interfaces for displaying a suggested dose, according to some embodiments.

[0070] FIG. 14 is an example computer system useful for implementing various embodiments.

[0071] In the drawings, like reference numbers generally indicate identical or similar elements. Additionally, generally, the left-most digit(s) of a reference number identifies the drawing in which the reference number first appears. DETAILED DESCRIPTION

[0072] Provided herein are system, apparatus, device, method and/or computer program product embodiments, and/or combinations and sub-combinations thereof, for improving the user interface features in an application that calculates medication doses within a CGM system.

[0073] Several embodiments described herein employ a dose guidance system that includes a display device, a sensor control device, and a medication delivery device. The dose guidance system may include a dose guidance application (e.g., software) that determines and outputs dose guidance (e.g., recommendations regarding dose amounts, corrections, and titrations) to a patient. Furthermore, according to some embodiments, the dose guidance system may learn a patient’s dosing strategy during a learning period in which the dose guidance system estimates key dosing parameters. According to some embodiments, the dose guidance system may also provide guidance for titrations and corrections once the system is configured with a patient’s current dosing strategies. The dose guidance system may also provide guidance for different meal dosing scenarios. For example, in some embodiments, the dose guidance system may provide dose guidance at or before a start of a meal or after a meal has started. The dose guidance system may also provide dose guidance for compounded meals (e.g., dessert) or for “touch up” doses to address high post-prandial glucose levels. Exemplary system and safety features of the dose guidance system are also described.

[0074] Many of the embodiments provided herein comprise improved software features or graphical user interfaces (“GUIs”) for use with analyte monitoring systems that are highly intuitive, user-friendly, and provide for rapid access to physiological information of a user. More specifically, these embodiments allow a user (or an HCP) to rapidly determine an appropriate medication therapy based on information relating to the user’s physiological conditions, historic dosing patterns, and other factors, without requiring the user (or an HCP) to go through the arduous task of examining large volumes of analyte data. Furthermore, some of the GUIs and GUI features, allow for users (and their caregivers) to better understand and improve a user’s dosing patterns and subsequent hypo- and hyper-glycemic episodes. Likewise, many other embodiments provided herein comprise improved software features for dose guidance systems that improve upon dose recommendations provided to users by allowing for safe titration strategies that minimize hypoglycemic episodes, methods for altering doses depending on when the dose is to be administered relative to a meal start time (e.g., before, at the start, or after the start of a meal), consideration of real-world occurrences that effect dosing strategies, post-prandial alarms based on a predicted occurrence probability rather than a threshold, to name only a few. Other improvements and advantages are provided as well. The various configurations of these devices are described in detail by way of the embodiments which are only examples.

[0075] Several embodiments are disclosed herein for achieving the improved user interface for a medication calculator. For example, in one embodiment, the medication calculator may be an independent application visually embedded into the CGM system application user interface with the ability to receive data from the user. In another embodiment, the medication calculator is an independent application that is visually separate from the CGM system application’s user interface. In yet another embodiment, the medication calculator may be a sub-module integrated into the CGM system’s application and visually embedded into the CGM system application’s user-interface flow. In another embodiment, the medication calculator may provide one or more values to a connected wearable to provide feedback to the user.

[0076] Before the present subject matter is described in detail, it is to be understood that this disclosure is not limited to the particular embodiments described, as such may, of course, vary. 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.

[0077] It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting, since the scope of the present disclosure will be limited only by the appended claims. As used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise. [0078] Any publications discussed herein are provided solely for their disclosure prior to the filing date of the present application. Nothing herein is to be construed as an admission that the present disclosure is not entitled to antedate such publication by virtue of prior disclosure. Further, the dates of publication provided may be different from the actual publication dates which may need to be independently confirmed.

[0079] Generally, embodiments of the present disclosure include systems, devices, and methods for the use of analyte sensor insertion applicators for use with in vivo analyte monitoring systems. An applicator may be provided to the user in a sterile package with an electronics housing of the sensor control device contained therein. According to some embodiments, a structure separate from the applicator, such as a container, may also be provided to the user as a sterile package with a sensor module and a sharp module contained therein. The user may couple the sensor module to the electronics housing, and may couple the sharp to the applicator with an assembly process that involves the insertion of the applicator into the container in a specified manner. In other embodiments, the applicator, sensor control device, sensor module, and sharp module may be provided in a single package. The applicator may be used to position the sensor control device on a human body with a sensor in contact with the wearer’s bodily fluid. The embodiments provided herein are improvements to reduce the likelihood that a sensor is improperly inserted or damaged, or elicits an adverse physiological response. Other improvements and advantages are provided as well. The various configurations of these devices are described in detail by way of the embodiments which are only examples.

[0080] Furthermore, many embodiments include in vivo analyte sensors structurally configured so that at least a portion of the sensor is, or may be, positioned in the body of a user to obtain information about at least one analyte of the body. It should be noted, however, that the embodiments disclosed herein may be used with in vivo analyte monitoring systems that incorporate in vitro capability, as well as purely in vitro or ex vivo analyte monitoring systems, including systems that are entirely non-invasive.

[0081] Furthermore, for each and every embodiment of a method disclosed herein, systems and devices capable of performing each of those embodiments are covered within the scope of the present disclosure. For example, embodiments of sensor control devices are disclosed and these devices may have one or more sensors, analyte monitoring circuits (e.g., an analog circuit), memories (e.g., for storing instructions), power sources, communication circuits, transmitters, receivers, processors and/or controllers (e.g., for executing instructions) that may perform any and all method steps or facilitate the execution of any and all method steps. These sensor control device embodiments may be used and may be capable of use to implement those steps performed by a sensor control device from any and all of the methods described herein.

[0082] Furthermore, the systems and methods presented herein may be used for operations of a sensor used in an analyte monitoring system, such as but not limited to wellness, fitness, dietary, research, information or any purposes involving analyte sensing over time. As used herein, “analyte sensor” or “sensor” may refer to any device capable of receiving sensor information from a user, including for purpose of illustration but not limited to, body temperature sensors, blood pressure sensors, pulse or heart-rate sensors, glucose level sensors, analyte sensors, physical activity sensors, body movement sensors, or any other sensors for collecting physical or biological information. Analytes measured by the analyte sensors may include, by way of example and not limitation, glucose, ketones, lactate, oxygen, hemoglobin A1C, albumin, alcohol, alkaline phosphatase, alanine transaminase, aspartate aminotransferase, bilirubin, blood urea nitrogen, calcium, carbon dioxide, chloride, creatinine, hematocrit, lactate, magnesium, oxygen, pH, phosphorus, potassium, sodium, total protein, uric acid, etc.

[0083] As mentioned, a number of embodiments of systems, devices, and methods are described herein that provide for the improved assembly and use of dermal sensor insertion devices for use with in vivo analyte monitoring systems. In particular, several embodiments of the present disclosure may be designed to improve the method of sensor insertion with respect to in vivo analyte monitoring systems and, in particular, to prevent the premature retraction of an insertion sharp during a sensor insertion process. Some embodiments, for example, include a dermal sensor insertion mechanism with an increased firing velocity and a delayed sharp retraction. In other embodiments, the sharp retraction mechanism may be motion-actuated such that the sharp is not retracted until the user pulls the applicator away from the skin. Consequently, these embodiments may reduce the likelihood of prematurely withdrawing an insertion sharp during a sensor insertion process; decrease the likelihood of improper sensor insertion; and decrease the likelihood of damaging a sensor during the sensor insertion process, to name a few advantages. Several embodiments of the present disclosure also provide for improved insertion sharp modules to account for the small scale of dermal sensors and the relatively shallow insertion path present in a subject’s dermal layer. In addition, several embodiments of the present disclosure are designed to prevent undesirable axial and/or rotational movement of applicator components during sensor insertion. Accordingly, these embodiments may reduce the likelihood of instability of a positioned dermal sensor, irritation at the insertion site, damage to surrounding tissue, and breakage of capillary blood vessels resulting in fouling of the dermal fluid with blood, to name a few advantages. In addition, to mitigate inaccurate sensor readings which may be caused by trauma at the insertion site, several embodiments of the present disclosure may reduce the end-depth penetration of the needle relative to the sensor tip during insertion.

[0084] Before describing these aspects of the embodiments in detail, however, it is first desirable to describe examples of devices may be present within, for example, an in vivo analyte monitoring system, as well as examples of their operation, all of which may be used with the embodiments described herein.

[0085] There are various types of in vivo analyte monitoring systems. CGM systems, for example, may transmit data from a sensor control device to a display device continuously without prompting, e.g., automatically according to a schedule. “Flash Analyte Monitoring” systems (or “Flash Glucose Monitoring” systems or simply “Flash” systems), as another example, may transfer data from a sensor control device in response to a scan or request for data by a display device, such as with a Near Field Communication (“NFC”) or Radio Frequency Identification (“RFID”) protocol. In vivo analyte monitoring systems may also operate without the need for finger stick calibration.

[0086] In vivo analyte monitoring systems may be differentiated from in vitro systems that contact a biological sample outside of the body (or ex vivo) and that typically include a meter device that has a port for receiving an analyte test strip carrying bodily fluid of the user, which may be analyzed to determine the user’s blood sugar level.

[0087] In vivo monitoring systems may include a sensor that, while positioned in vivo, makes contact with the bodily fluid of the user and senses the analyte levels contained therein. The sensor may be part of the sensor control device that resides on the body of the user and contains the electronics and power supply that enable and control the analyte sensing. The sensor control device, and variations thereof, may also be referred to as a “sensor control unit,” an “on-body electronics” device or unit, an “on-body” device or unit, or a “sensor data communication” device or unit, to name a few.

[0088] In vivo monitoring systems may also include a device that receives sensed analyte data from the sensor control device and processes and/or displays that sensed analyte data, in any number of forms, to the user. This device, and variations thereof, may be referred to as a “display device,” “handheld reader device,” “reader device” (or simply a “reader”), “handheld electronics” (or simply a “handheld”), a “portable data processing” device or unit, a “data receiver,” a “receiver” device or unit (or simply a “receiver”), or a “remote” device or unit, to name a few. Other devices such as personal computers have also been utilized with or incorporated into in vivo and in vitro monitoring systems.

Exemplary In Vivo Analyte Monitoring System

[0089] FIG. 1 A is a conceptual diagram depicting an example embodiment of dose guidance system 100 that includes sensor applicator 150, sensor control device (SCD) 102, and display device 120. Here, sensor applicator 150 may be used to deliver SCD 102 to a monitoring location on a user’s skin where in vivo analyte sensor 104 is maintained in position for a period of time by adhesive patch 105. SCD 102 is further described in FIGS. 2B and 2C, and may communicate with display device 120 via a communication path 141 using a wired or wireless technique. Example wireless protocols include BLUETOOTH, BLUETOOTH LOW ENERGY (“BLE” or “BTLE”), BLUETOOTH SMART, NFC, and others. Users may monitor applications installed in memory on display device 120 using display 122 and input component 121 and the device battery may be recharged using power port 123. More detail about display device 120 is set forth with respect to FIG. 2A below. Display device 120 may communicate with local computer system 175 via a communication path 141 using a wired or wireless technique. Local computer system 175 may include one or more of a laptop, desktop, tablet, phablet, smartphone, set-top box, video game console, or other computing device and wireless communication may include any of a number of applicable wireless networking protocols including BLUETOOTH, BTLE, WI-FI, or others. Local computer system 175 may communicate via communications path 143 with a network 190 similar to how display device 120 may communicate via a communications path 142 with network 190, by wired or wireless technique as described previously. Network 190 may be any of a number of networks, such as private networks and public networks, local area or wide area networks, and so forth. Trusted computer system 180 may include a server and may provide authentication services and secured data storage and may communicate via communications path 144 with network 190 by wired or wireless technique.

[0090] Dose guidance system 100 also includes medication delivery device (MDD) 152 configured to deliver medication to the user. Dose guidance system 100 may be configured for highly interconnected and highly flexible communication between devices. Each of the three devices SCD 102, display device 120, and MDD 152, may communicate directly with each other (without passing through an intermediate electronic device) or indirectly with each other (such as through 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. 1 A with a doublesided arrow. However, those of skill in the art will appreciate that any of the one or more devices (e.g., MDD 152) may be capable of unidirectional communication such as, for example, broadcasting, multicasting, or advertising communications. In each instance, whether bidirectional or unidirectional, the communication may be wired or wireless. The protocols that govern communication over each path may be the same or different, and may be either proprietary or standardized. For example, wireless communication between devices SCD 102, display device 120, and MDD 152 may be performed according to a BLUETOOTH (including BLUETOOTH LOW ENERGY) standard, a Near Field Communication (NFC) standard, a WI-FI (802.1 lx) standard, a mobile telephony standard, or others. All communications over the various paths may be encrypted, and each device of FIG. 1 A may be configured to encrypt and decrypt those communications sent and received. In each instance the communication pathways of FIG. 1A may be direct (e.g., BLUETOOTH or NFC) or indirect (e.g., WI-FI, mobile telephony, or other internet protocol). Embodiments of dose guidance system 100 do not need to have the capability to communicate across all of the pathways indicated in FIG. 1 A.

[0091] In addition, although FIG. 1 A depicts a single display device 120, a single SCD 102, and a single MDD 152, those of skill in the art will appreciate that dose guidance system 100 may comprise a plurality of any of the aforementioned devices. By way of example only, dose guidance system 100 may comprise a single SCD 102 in communication with multiple (e.g., two, three, four, etc.) display devices 120 and/or multiple MDDs 152. Alternatively, dose guidance system 100 may 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 may be of the same or different device types. For example, dose guidance system 100 may comprise multiple display devices 120, including a smart phone, a handheld receiver, and/or a smart watch, each of which may be in communication with SCD 102 and/or MDD 152, as well in communication with each other.

[0092] Analyte data may be transferred between each device within dose guidance 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 may also be employed to accommodate more complex systems like cloud network 190.

[0093] FIG. IB illustrates an operating environment of dose guidance system 100a capable of embodying the techniques described herein. Dose guidance system 100a may include a system of components designed to provide monitoring of parameters, such as analyte levels, of a human or animal body or may provide for other operations based on the configurations of the various components. As embodied herein, the system may include analyte sensor 110, or simply “sensor” worn by the user or attached to the body for which information is being collected. As embodied herein, analyte sensor 110 may be a sealed, disposable device with a predetermined active use lifetime (e.g., 1 day, 14 days, 30 days, etc.). Analyte sensor 110 may be applied to the skin of the user body and remain adhered over the duration of the sensor lifetime or may be designed to be selectively removed and remain functional when reapplied. Dose guidance system 100a may further include display device 120 or multi-purpose data receiving device 130 configured as described herein to facilitate retrieval and delivery of data, including analyte data, from analyte sensor 110.

[0094] As embodied herein, dose guidance system 100a may include a software or firmware library or application provided, for example via remote application server 155 or application storefront server 160, to a third-party and incorporated into multi-purpose data receiving device 130 such as a mobile phone, tablet, personal computing device, or other similar computing device capable of communicating with analyte sensor 110 over a communication link. Multi-purpose hardware may further include embedded devices, including, but not limited to insulin pumps or insulin pens, having an embedded library configured to communicate with analyte sensor 110. Although the illustrated embodiments of dose guidance system 100a include only one of each of the illustrated devices, this disclosure contemplates dose guidance system 100a incorporating multiples of each component interacting throughout the system. For example and without limitation, as embodied herein, display device 120 and/or multi-purpose data receiving device 130 may include multiples of each. As embodied herein, multi-purpose data receiving device 130 may communicate directly with analyte sensor 110 as described herein. Additionally or alternatively, multi-purpose data receiving device 130 may communicate with multi-purpose data receiving device 130 to provide analyte data, or visualization or analysis of the data, for secondary display to the user or other authorized parties.

[0095] Dose guidance system 100a also includes MDD 152. SCD 102 and MDD 152 may be capable of communication with each other and with display device 120, which may 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 network 190. Conversely, display device 120 may receive information from network 190 and communicate some or all of the received information to SCD 102, MDD 152, or both. User device 140 may be a personal computer, a server terminal, a laptop computer, a tablet, or other suitable data processing device. User device 140 may include or present software for data management and analysis and communication with the components in dose guidance system 100a. User device 140 may be used by the user or a medical professional to display and/or analyze analyte data measured by SCD 102. Furthermore, although FIG. IB depicts a single SCD 102 and a single MDD 152, those of skill in the art will appreciate that dose guidance system 100 may include a plurality of any of the aforementioned devices, wherein each plurality of devices may comprise the same or different types of devices.

Exemplary Display Device

[0096] FIG. 2A is a block diagram depicting an example embodiment of a display device configured as a smartphone. Here, display device 120 may include a display 122, input component 121, and processing core 206 including communications processor 222 coupled with memory 223 and applications processor 224 coupled with memory 225. Also included may be separate memory 230, RF transceiver 228 with antenna 229, and power supply 226 with power management module 238. Further included may be a multifunctional transceiver 232 which may communicate over WI-FI, NFC, BLUETOOTH, BTLE, and GPS with antenna 234. As understood by one of skill in the art, these components are electrically and communicatively coupled in a manner to make a functional device.

Exemplary Display Device Architecture

[0097] For purpose of illustration and not limitation, reference is made to the exemplary embodiment of display device 120 for use with the disclosed subject matter as shown in FIG. 2B. Display device 120 and the related multi-purpose data receiving device 130 may include components germane to the discussion of analyte sensor 110 and its operations and additional components may be included. In particular embodiments, display device 120 and multi-purpose data receiving device 130 may be or include components provided by a third party and are not necessarily restricted to include devices made by the same manufacturer as analyte sensor 110.

[0098] As illustrated in FIG. 2B, display device 120 may include ASIC 4000 having microcontroller 4010, memory 4020, and storage 4030 and communicatively coupled with a communication module 4040. Power for the components of display device 120 may be delivered by power module 4050, which as embodied herein may include a rechargeable battery. Display device 120 may further include display 4070 for facilitating review of analyte data received from analyte sensor 110 or other device (e.g., user device 140 or remote application server 155). Display device 120 may include separate user interface components (e.g., physical keys, light sensors, microphones, etc.).

[0099] Communication module 4040 may include BLE module 4041 and NFC module 4042. Display device 120 may be configured to wirelessly couple with analyte sensor 110 and transmit commands to and receive data from analyte sensor 110. As embodied herein, display device 120 may be configured to operate, with respect to analyte sensor 110 as described herein, as an NFC scanner and a BLE end point via specific modules (e.g., BLE module 4042 or NFC module 4043) of communication module 4040. For example, display device 120 may issue commands (e.g, activation commands for a data broadcast mode of the sensor; pairing commands to identify display device 120) to analyte sensor 110 using a first module of the communication module 4040 and receive data from and transmit data to analyte sensor 110 using a second module of the communication module 4040. Display device 120 may be configured for communication with user device 140 via a Universal Serial Bus (“USB”) module 4045 of the communication module 4040.

[0100] As another example, communication module 4040 may include, for example, cellular radio module 4044. The cellular radio module 4044 may include one or more radio transceivers for communicating using broadband cellular networks, including, but not limited to third generation (“3G”), fourth generation (“4G”), and fifth generation (“5G”) networks. Additionally, communication module 4040 of display device 120 may include WI-FI radio module 4043 for communication using a wireless local area network according to one or more of the IEEE 802.11 standards (e.g., 802.1 la, 802.1 lb, 802.11g, 802.1 In (aka Wi-Fi 4), 802.1 lac (aka WI-FI 5), 802.1 lax (aka WI-FI 6)). Using cellular radio module 4044 or WI-FI radio module 4043, display device 120 may communicate with remote application server 155 to receive analyte data or provide updates or input received from a user (e.g., through one or more user interfaces). Although not illustrated, communication module 5040 of analyte sensor 110 may similarly include a cellular radio module or Wi-Fi radio module.

[0101] As embodied herein, on-board storage 4030 of display device 120 may store analyte data received from analyte sensor 110. Further, display device 120, multi-purpose data receiving device 130, or user device 140 may be configured to communicate with remote application server 155 via a wide area network. As embodied herein, analyte sensor 110 may provide data to display device 120 or multi-purpose data receiving device 130. Display device 120 may transmit the data to user device 140. User device 140 (or multi-purpose data receiving device 130) may in turn transmit that data to remote application server 155 for processing and analysis.

[0102] As embodied herein, display device 120 may further include sensing hardware 4060 similar to, or expanded from, sensing hardware 5060 of analyte sensor 110. In particular embodiments, display device 120 may be configured to operate in coordination with analyte sensor 110 and based on analyte data received from the analyte sensor 110. As an example, where analyte sensor 110 is a glucose sensor, display device 120 may be or include an insulin pump or insulin injection pen. In coordination, multi-purpose data receiving device 130 may adjust an insulin dosage for a user based on glucose values received from the analyte sensor. Exemplary Sensor Control Devices

[0103] FIGS. 2C and 2D are block diagrams depicting example embodiments of SCD 102 having in vivo analyte sensor 104 and sensor electronics 169 (including analyte monitoring circuitry) that may have the majority of the processing capability for rendering end-result data suitable for display to the user. In FIG. 2C, a single semiconductor chip 161 is depicted that may be a custom application specific integrated circuit (“ASIC”). Shown within ASIC 161 are certain high-level functional units, including an analog front end (“AFE”) 162, power management circuitry 164, processor 166, and communication circuitry 168 (which may be implemented as a transmitter, receiver, transceiver, passive circuit, or otherwise according to the communication protocol). In this embodiment, both AFE 162 and processor 166 are used as analyte monitoring circuitry, but in other embodiments either circuit may perform the analyte monitoring function. Processor 166 may include one or more processors, microprocessors, controllers, and/or microcontrollers, each of which may be a discrete chip or distributed amongst (and a portion of) a number of different chips.

[0104] Memory 163 is also included within ASIC 161 and may be shared by the various functional units present within ASIC 161, or may be distributed amongst two or more of them. Memory 163 may also be a separate chip. Memory 163 may be volatile and/or nonvolatile memory. In this embodiment, ASIC 161 is coupled with power source 170, which may be a coin cell battery, or the like. AFE 162 interfaces with in vivo analyte sensor 104 and receives measurement data therefrom and outputs the data to processor 166 in digital form, which in turn processes the data to arrive at the end-result glucose discrete and trend values, etc. This data may then be provided to communication circuitry 168 for sending, by way of antenna 171, to display device 120 (not shown), for example, where minimal further processing is needed by the resident software application to display the data.

[0105] FIG. 2D is similar to FIG. 2C but instead includes two discrete semiconductor chips 162 and 174, which may be packaged together or separately. Here, AFE 162 is resident on ASIC 161. Processor 166 is integrated with power management circuitry 164 and communication circuitry 168 on chip 174. AFE 162 includes memory 163 and chip 174 includes memory 165, which may be isolated or distributed within. In one example embodiment, AFE 162 may be combined with power management circuitry 164 and processor 166 on one chip, while communication circuitry 168 is on a separate chip. In another example embodiment, both AFE 162 and communication circuitry 168 are on one chip, and processor 166 and power management circuitry 164 are on another chip. It should be noted that other chip combinations are possible, including three or more chips, each bearing responsibility for the separate functions described, or sharing one or more functions for fail-safe redundancy.

[0106] For purpose of illustration and not limitation, reference is made to the exemplary embodiment of analyte sensor 110 for use with the disclosed subject matter as shown in FIG. 2E. FIG. 2E illustrates a block diagram of an example analyte sensor 110 according to exemplary embodiments compatible with the security architecture and communication schemes described herein.

[0107] As embodied herein, analyte sensor 110 may include ASIC 5000 communicatively coupled with a communication module 5040. ASIC 5000 may include a microcontroller core 5010, on-board memory 5020, and storage memory 5030. Storage memory 5030 may store data used in an authentication and encryption security architecture. Storage memory 5030 may store programming instructions for analyte sensor 110. As embodied herein, certain communication chipsets may be embedded in the ASIC 5000 (e.g., an NFC transceiver 5025). ASIC 5000 may receive power from a power module 5050, such as an on-board battery or from an NFC pulse. Storage memory 5030 of the ASIC 5000 may be programmed to include information such as an identifier for analyte sensor 110 for identification and tracking purposes. Storage memory 5030 may also be programmed with configuration or calibration parameters for use by analyte sensor 110 and its various components. Storage memory 5030 may include rewritable or one-time programming (“OTP”) memory. The storage memory 5030 may be updated using techniques described herein to extend the usefulness of analyte sensor 110.

[0108] As embodied herein, communication module 5040 of sensor 110 may be or include one or more modules to support analyte sensor 110 communicating with other devices of dose guidance system 100. As an example only and not by way of limitation, example communication modules 5040 may include BLE module 5041 As used throughout this disclosure, BLE refers to a short-range communication protocol optimized to make pairing of BLUETOOTH devices simple for end users. Communication module 5040 may transmit and receive data and commands via interaction with similarly-capable communication modules of display device 120 or user device 140. Communication module 5040 may include additional or alternative chipsets for use with similar short-range communication schemes, such as a personal area network according to IEEE 802.15 protocols, IEEE 802.11 protocols, infrared communications according to the Infrared Data Association standards (IrDA), etc.

[0109] To perform its functionalities, sensor 110 may further include suitable sensing hardware 5060 appropriate to its function. As embodied herein, sensing hardware 5060 may include an analyte sensor transcutaneously or subcutaneously positioned in contact with a bodily fluid of a subject. The analyte sensor may generate sensor data containing values corresponding to levels of one or more analytes within the bodily fluid.

Exemplary Assembly Processes for Sensor Control Devices

[0110] The components of SCD 102 may be acquired by a user in multiple packages requiring final assembly by the user before delivery to an appropriate user location. FIGS. 3A-3D depict an example embodiment of an assembly process for SCD 102 by a user, including preparation of separate components before coupling the components in order to ready the sensor for delivery. FIGS. 3E-3F depict an example embodiment of delivery of SCD 102 to an appropriate user location by selecting the appropriate delivery location.

[OHl] FIG. 3 A is a proximal perspective view depicting an example embodiment of user preparing tray 810, configured here as a tray (although other packages/containers may be used), for an assembly process. The user may accomplish this preparation by removing lid 812 from tray 810 to expose platform 808, for instance by peeling a non-adhered portion of lid 812 away from tray 810 such that adhered portions of lid 812 are removed. Removal of lid 812 may be appropriate in various embodiments so long as platform 808 is adequately exposed within tray 810. Lid 812 may then be placed aside.

[0112] FIG. 3B is a side view depicting an example embodiment of a user preparing an applicator device 150 for assembly. Applicator device 150 may be provided in a sterile package sealed by a cap 708. Preparation of applicator device 150 may include uncoupling housing 702 from cap 708 to expose sheath 704 (FIG. 3C). This may be accomplished by unscrewing (or otherwise uncoupling) cap 708 from housing 702. Cap 708 may then be placed aside.

[0113] FIG. 3C is a proximal perspective view depicting an example embodiment of a user inserting applicator device 150 into tray 810 during an assembly. Initially, the user may insert sheath 704 into platform 808 inside tray 810 after aligning a housing orienting feature (or slot or recess) and tray orienting feature 724 (an abutment or detent). Inserting sheath 704 into platform 808 temporarily unlocks sheath 704 relative to housing 702 and also temporarily unlocks platform 808 relative to tray 810. At this stage, removal of applicator device 150 from tray 810 will result in the same state prior to initial insertion of applicator device 150 into tray 810 (z.e., the process may be reversed or aborted at this point and then repeated without consequence).

[0114] Sheath 704 may maintain position within platform 808 with respect to housing 702 while housing 702 is distally advanced, coupling with platform 808 to distally advance platform 808 with respect to tray 810. This step unlocks and collapses platform 808 within tray 810. Sheath 704 may contact and disengage locking features (not shown) within tray 810 that unlock sheath 704 with respect to housing 702 and prevent sheath 704 from moving (relatively) while housing 702 continues to distally advance platform 808. At the end of advancement of housing 702 and platform 808, sheath 704 is permanently unlocked relative to housing 702. A sharp and sensor (not shown) within tray 810 may be coupled with an electronics housing (not shown) within housing 702 at the end of the distal advancement of housing 702. Operation and interaction of the applicator device 150 and tray 810 are further described below.

[0115] FIG. 3D is a proximal perspective view depicting an example embodiment of a user removing an applicator device 150 from tray 810 during an assembly. A user may remove applicator 150 from tray 810 by proximally advancing housing 702 with respect to tray 810 or other motions having the same end effect of uncoupling applicator 150 and tray 810. The applicator device 150 is removed with SCD 102 (not shown) fully assembled (sharp, sensor, electronics) therein and positioned for delivery.

[0116] FIG. 3E is a proximal perspective view depicting an example embodiment of a patient applying SCD 102 using applicator device 150 to a target area of skin, for instance, on an abdomen or other appropriate location. Advancing housing 702 distally collapses sheath 704 within housing 702 and applies the sensor to the target location such that an adhesive layer on the bottom side of SCD 102 adheres to the skin. The sharp is automatically retracted when housing 702 is fully advanced, while the sensor (not shown) is left in position to measure analyte levels. [0117] FIG. 3F is a proximal perspective view depicting an example embodiment of a patient with SCD 102 in an applied position. The user may then remove applicator 150 from the application site.

[0118] Dose guidance system, 100, described with respect to FIGS. 3A-3F and elsewhere herein, may provide a reduced or eliminated chance of accidental breakage, permanent deformation, or incorrect assembly of applicator components compared to prior art systems. Since housing 702 directly engages platform 808 while sheath 704 unlocks, rather than indirect engagement via sheath 704, relative angularity between sheath 704 and housing 702 will not result in breakage or permanent deformation of the arms or other components. The potential for relatively high forces (such as in conventional devices) during assembly will be reduced, which in turn reduces the chance of unsuccessful user assembly.

Exemplary Sensor Applicator Devices

[0119] FIG. 4A is a side view depicting an example embodiment of an applicator device 150 coupled with screw cap 708. This is an example of how applicator 150 is shipped to and received by a user, prior to assembly by the user with a sensor. FIG. 4B is a side perspective view depicting applicator 150 and cap 708 after being decoupled. FIG. 4C is a perspective view depicting an example embodiment of a distal end of applicator device 150 with electronics housing 706 and adhesive patch 105 removed from the position they would have retained within sensor carrier 710 of sheath 704, when cap 708 is in place.

[0120] Referring to FIG. 4D-G for purpose of illustration and not limitation, applicator device 20150 may be provided to a user as a single integrated assembly. FIGS. 4D and 4E provide perspective top and bottom views, respectively, of the applicator device 20150, FIG. 4F provides an exploded view of applicator device 20150 and FIG. 4G provides a side cut-away view. The perspective views illustrate how applicator 20150 is shipped to and received by a user. The exploded and cut-away views illustrate the components of applicator device 20150. The applicator device 20150 may include a housing 20702, gasket 20701, sheath 20704, sharp carrier 201102, spring 205612, sensor carrier 20710 (also referred to as a “puck carrier”), sharp hub 205014, sensor control device (also referred to as a “puck”) 20102, adhesive patch 20105, desiccant 20502, cap 20708, serial label 20709, and tamper evidence feature 20712. As received by a user, only housing 20702, cap 20708, tamper evidence feature 20712, and label 20709 are visible. The tamper evidence feature 20712 may be, for example, a sticker coupled to each of housing 20702 and cap 20708, and tamper evidence feature 20712 may be damaged, for example, irreparably, by uncoupling housing 20702 and cap 20708, thereby indicating to a user that housing 20702 and cap 20708 have been previously uncoupled. These features are described in greater detail below.

Exemplary Sensor States and Activation

[0121] For purpose of illustration and not limitation, reference is made to the exemplary embodiment of a high-level depiction of a state machine representation 500 of the actions that may be taken by analyte sensor 110 as shown in FIG. 5. After initialization, the sensor enters state 505, which relates to the manufacture of analyte sensor 110. In the manufacture state 505, analyte sensor 110 may be configured for operation, for example, the storage memory 5030 may be written. At various times while in state 505, analyte sensor 110 checks for a received command to go to storage state 515. Upon entry to storage state 515, the sensor performs a software integrity check. While in storage state 515, the sensor may also receive an activation request command before advancing to insertion detection state 525.

[0122] Upon entry to state 525, analyte sensor 110 may store information relating to devices authenticated to communicate with the sensor as set during activation or initialize algorithms related to conducting and interpreting measurements from sensing hardware 5060. Analyte sensor 110 may also initialize a lifecycle timer, responsible for maintaining an active count of the time of operation of analyte sensor 110 and begin communication with authenticated devices to transmit recorded data. While in insertion detection state 525, the sensor may enter state 530, where analyte sensor 110 checks whether the time of operation is equal to a predetermined threshold. This time of operation threshold may correspond to a timeout function for determining whether an insertion has been successful. If the time of operation has reached the threshold, analyte sensor 110 advances to state 535, in which analyte sensor 110 checks whether the average data reading is greater than a threshold amount corresponding to an expected data reading volume for triggering detection of a successful insertion. If the data reading volume is lower than the threshold while in state 535, the sensor advances to state 540, corresponding to a failed insertion. If the data reading volume satisfies the threshold, the sensor advances to active paired state 555. [0123] Active paired state 555 of analyte sensor 110 reflects the state while analyte sensor 110 is operating as normal by recording measurements, processing the measurements, and reporting them as appropriate. While in active paired state 555, analyte sensor 110 sends measurement results or attempts to establish a connection with display device 120. Analyte sensor 110 also increments the time of operation. Once analyte sensor 110 reaches a predetermined threshold time of operation e.g., once the time of operation reaches a predetermined threshold), analyte sensor 110 transitions to active expired state 565. Active expired state 565 of analyte sensor 110 reflects the state while analyte sensor 110 has operated for its maximum predetermined amount of time.

[0124] While in active expired state 565, analyte sensor 110 may generally perform operations relating to winding down operation and ensuring that the collected measurements have been securely transmitted to receiving devices as needed. For example, while in active expired state 565, analyte sensor 110 may transmit collected data and, if no connection is available, may increase efforts to discover authenticated devices nearby and establish and connection therewith. While in active expired state 565, analyte sensor 110 may receive a shutdown command at state 570. If no shutdown command is received, analyte sensor 110 may also, at state 575, check if the time of operation has exceeded a final operation threshold. The final operation threshold may be based on the battery life of analyte sensor 110. The normal termination state 580 corresponds to the final operations of analyte sensor 110 and ultimately shutting down analyte sensor 110.

[0125] Before a sensor is activated, ASIC 5000 resides in a low power storage mode state. The activation process may begin, for example, when an incoming RF field (e.g., NFC field) drives the voltage of the power supply to the ASIC 5000 above a reset threshold, which causes analyte sensor 110 to enter a wake-up state. While in the wake-up state, ASIC 5000 enters an activation sequence state. ASIC 5000 then wakes communication module 5040. Communication module 5040 is initialized, triggering a power on self-test. The power on self-test may include ASIC 5000 communicating with communication module 5040 using a prescribed sequence of reading and writing data to verify the memory and one-time programmable memory are not corrupted.

[0126] When ASIC 5000 enters the measurement mode for the first time, an insertion detection sequence is performed to verify that analyte sensor 110 has been properly installed onto the patient’s body before a proper measurement may take place. First, analyte sensor 110 interprets a command to activate the measurement configuration process, causing the ASIC 5000 to enter measurement command mode. Analyte sensor 110 then temporarily enters the measurement lifecycle state to run a number of consecutive measurements to test whether the insertion has been successful. Communication module 5040 or ASIC 5000 evaluates the measurement results to determine insertion success. When insertion is deemed successful, analyte sensor 110 enters a measurement state, in which analyte sensor 110 begins taking regular measurements using sensing hardware 5060. If analyte sensor 110 determines that the insertion was not successful, analyte sensor 110 is triggered into an insertion failure mode, in which ASIC 5000 is commanded back to storage mode while communication module 5040 disables itself.

Exemplary Over- the- Air Updates

[0127] FIG. IB further illustrates an example operating environment for providing over- the-air (“OTA”) updates for use with the techniques described herein. An operator of dose guidance system 100 may bundle updates for display device 120 or analyte sensor 110 into updates for an application executing on multi-purpose data receiving device 130. Using available communication channels between display device 120, multi-purpose data receiving device 130, and analyte sensor 110, multi-purpose data receiving device 130 may receive regular updates for display device 120 or analyte sensor 110 and initiate installation of the updates on display device 120 or analyte sensor 110. Multi-purpose data receiving device 130 acts as an installation or update platform for display device 120 or analyte sensor 110 because the application that enables the multi-purpose data receiving device 130 to communicate with analyte sensor 110, display device 120 and/or remote application server 155 may update software or firmware on display device 120 or analyte sensor 110 without wide-area networking capabilities.

[0128] As embodied herein, remote application server 155 operated by the manufacturer of analyte sensor 110 and/or the operator of dose guidance system 100 may provide software and firmware updates to the devices of dose guidance system 100. In particular embodiments, remote application server 155 may provide the updated software and firmware to user device 140 or directly to a multi-purpose data receiving device. As embodied herein, remote application server 155 may also provide application software updates to application storefront server 160 using interfaces provided by the application storefront. Multi-purpose data receiving device 130 may contact the application storefront server 160 periodically to download and install the updates.

[0129] After multi-purpose data receiving device 130 downloads an application update including a firmware or software update for display device 120 or analyte sensor 110, display device 120 or analyte sensor 110 and multi-purpose data receiving device 130 establish a connection. Multi-purpose data receiving device 130 determines that a firmware or software update is available for display device 120 or analyte sensor 110. Multi-purpose data receiving device 130 may prepare the software or firmware update for delivery to display device 120 or analyte sensor 110. As an example, multi-purpose data receiving device 130 may compress or segment the data associated with the software or firmware update, encrypt or decrypt the firmware or software update, or perform an integrity check of the firmware or software update. Multi-purpose data receiving device 130 sends the data for the firmware or software update to display device 120 or analyte sensor 110. Multi-purpose data receiving device 130 may also send a command to display device 120 or analyte sensor 110 to initiate the update. Additionally or alternatively, multi-purpose data receiving device 130 may provide a notification to the user of multipurpose data receiving device 130 and include instructions for facilitating the update, such as instructions to keep display device 120 and multi-purpose data receiving device 130 connected to a power source and in close proximity until the update is complete.

[0130] Display device 120 or analyte sensor 110 receives the data for the update and the command to initiate the update from multi-purpose data receiving device 130. Display device 120 may then install the firmware or software update. To install the update, display device 120 or analyte sensor 110 may place or restart itself in a so-called “safe” mode with limited operational capabilities. Once the update is completed, display device 120 or analyte sensor 110 re-enters or resets into a standard operational mode. Display device 120 or analyte sensor 110 may perform one or more self-tests to determine that the firmware or software update was installed successfully. Multi-purpose data receiving device 130 may receive the notification of the successful update. Multi-purpose data receiving device 130 may then report a confirmation of the successful update to remote application server 155.

[0131] In particular embodiments, storage memory 5030 of analyte sensor 110 includes OTP memory. The term OTP memory may refer to memory that includes access restrictions and security to facilitate writing to particular addresses or segments in the memory a predetermined number of times. Memory 5030 may be prearranged into multiple pre-allocated memory blocks or containers. The containers are pre-allocated into a fixed size. If storage memory 5030 is OTP memory, the containers may be considered to be in a non-programmable state. Additional containers which have not yet been written to may be placed into a programmable or writable state. Containerizing storage memory 5030 in this fashion may improve the transportability of code and data to be written to storage memory 5030. Updating the software of a device (e.g., the sensor device described herein) stored in an OTP memory may be performed by superseding only the code in a particular previously-written container or containers with updated code written to a new container or containers, rather than replacing the entire code in the memory. In a second embodiment, the memory is not prearranged. Instead, the space allocated for data is dynamically allocated or determined as needed. Incremental updates may be issued, as containers of varying sizes may be defined where updates are anticipated.

[0132] FIG. 6 is a diagram illustrating an example operational and data flow for over-the- air (“OTA”) programming of storage memory 5030 in dose guidance system 100 as well as use of the memory after the OTA programming in execution of processes by analyte sensor 110 according to the disclosed subject matter. In the example OTA programming 600 illustrated in FIG. 6, a request is sent from an external device (e.g., multi-purpose data receiving device 130) to initiate OTA programming (or re-programming). At 611, communication module 240 of analyte sensor 110 receives an OTA programming command. Communication module 240 sends the OTA programming command to the microcontroller 210 of analyte sensor 110.

[0133] At 631, after receiving the OTA programming command, microcontroller 210 validates the OTA programming command. Microcontroller 210 may determine, for example, whether the OTA programming command is signed with an appropriate digital signature token. Upon determining that the OTA programming command is valid, microcontroller 210 may set the sensor device into an OTA programming mode. At 632, microcontroller 210 may validate the OTA programming data. At 633, microcontroller 210 may reset analyte sensor 110 to re-initialize analyte sensor 110 in a programming state. Once analyte sensor 110 has transitioned into the OTA programming state, microcontroller 210 may begin to write data to the rewriteable memory (e.g., memory 5020) of the sensor device at 634 and write data to OTP memory 550 of the sensor device at 635 (e.g., storage memory 5030). The data written by the microcontroller 210 may be based on the validated OTA programming data. Microcontroller 210 may write data to cause one or more programming blocks or regions of OTP memory 550 to be marked invalid or inaccessible. The data written to the free or unused portion of OTP memory 550 may be used to replace invalidated or inaccessible programming blocks of OTP memory 550. After microcontroller 210 writes the data to the respective memories at 634 and 635, microcontroller 210 may perform one or more software integrity checks to ensure that errors were not introduced into the programming blocks during the writing process. Once microcontroller 210 is able to determine that the data has been written without errors, microcontroller 210 may resume standard operations of the sensor device.

[0134] In execution mode, at 636, microcontroller 210 may retrieve a programming manifest or profile from the rewriteable memory. The programming manifest or profile may include a listing of the valid software programming blocks and may include a guide to program execution for analyte sensor 110. By following the programming manifest or profile, microcontroller 210 may determine which memory blocks of OTP memory 550 are appropriate to execute and avoid execution of out-of-date or invalidated programming blocks or reference to out-of-date data. At 637, microcontroller 210 may selectively retrieve memory blocks from OTP memory 550. At 638, microcontroller 210 may use the retrieved memory blocks, by executing programming code stored or using variable stored in the memory.

Exemplary Security and Other Architecture Features

[0135] As embodied herein a first layer of security for communications between analyte sensor 110 and other devices may be established based on security protocols specified by and integrated in the communication protocols used for the communication. Another layer of security may be based on communication protocols that necessitate close proximity of communicating devices. Furthermore certain packets and/or certain data included within packets may be encrypted while other packets and/or data within packets is otherwise encrypted or not encrypted. Additionally or alternatively, application layer encryption may be used with one or more block ciphers or stream ciphers to establish mutual authentication and communication encryption with other devices in the dose guidance system 100. [0136] ASIC 5000 of analyte sensor 110 may be configured to dynamically generate authentication and encryption keys using data retained within storage memory 5030. Storage memory 5030 may also be pre-programmed with a set of valid authentication and encryption keys to use with particular classes of devices. ASIC 5000 may be further configured to perform authentication procedures with other devices using received data and apply the generated key to sensitive data prior to transmitting the sensitive data. The generated key may be unique to analyte sensor 110, unique to a pair of devices, unique to a communication session between analyte sensor 110 and other device, unique to a message sent during a communication session, or unique to a block of data contained within a message.

[0137] Both analyte sensor 110 and display device 120 may ensure the authorization of the other party in a communication session to, for example, issue a command or receive data. In particular embodiments, identity authentication may be performed through two features. First, the party asserting its identity provides a validated certificate signed by the manufacturer of the device or the operator of dose guidance system 100. Second, authentication may be enforced through the use of public keys and private keys, and shared secrets derived therefrom, established by the devices of dose guidance system 100 or established by the operator of dose guidance system 100. To confirm the identity of the other party, the party may provide proof that the party has control of its private key.

[0138] The manufacturer of analyte sensor 110, display device 120, or provider of the application for multi-purpose data receiving device 130 may provide information and programming necessary for the devices to securely communicate through secured programming and updates. For example, the manufacturer may provide information that may be used to generate encryption keys for each device, including secured root keys for analyte sensor 110 and optionally for display device 120 that may be used in combination with device-specific information and operational data (e.g., entropy -based random values) to generate encryption values unique to the device, session, or data transmission as need.

[0139] Analyte data associated with a user is sensitive data at least in part because this information may be used for a variety of purposes, including for health monitoring and medication dosing decisions. In addition to user data, dose guidance system 100 may enforce security hardening against efforts by outside parties to reverse-engineering. Communication connections may be encrypted using a device-unique or session-unique encryption key. Encrypted communications or unencrypted communications between any two devices may be verified with transmission integrity checks built into the communications. Analyte sensor 110 operations may be protected from tampering by restricting access to read and write functions to the memory 5020 via a communication interface. The sensor may be configured to grant access only to known or “trusted” devices, provided in a “whitelisf ’ or only to devices that may provide a predetermined code associated with the manufacturer or an otherwise authenticated user. A whitelist may represent an exclusive range, meaning that no connection identifiers besides those included in the whitelist will be used, or a preferred range, in which the whitelist is searched first, but other devices may still be used. Analyte sensor 110 may further deny and shut down connection requests if the requestor cannot complete a login procedure over a communication interface within a predetermined period of time (e.g., within four seconds). These characteristics safeguard against specific denial of service attacks, and in particular against denial of service attacks on a BLE interface.

[0140] As embodied herein, dose guidance system 100 may employ periodic key rotation to further reduce the likelihood of key compromise and exploitation. A key rotation strategy employed by dose guidance system 100 may be designed to support backward compatibility of field-deployed or distributed devices. As an example, dose guidance system 100 may employ keys for downstream devices (e.g., devices that are in the field or cannot be feasibly provided updates) that are designed to be compatible with multiple generations of keys used by upstream devices.

[0141] For purpose of illustration and not limitation, reference is made to the exemplary embodiment of a message sequence diagram for use with the disclosed subject matter as shown in FIG. 7 and demonstrating an example exchange of data between a pair of devices, particularly analyte sensor 110 and display device 120. Display device 120 may, as embodied herein, be display device 120 or multi-purpose data receiving device 130. At step 755, display device 120 may transmit a sensor activation command to analyte sensor 110, for example via a short-range communication protocol. Analyte sensor 110 may, prior to step 755 be in a primarily dormant state, preserving its battery until full activation is needed. After activation during step 760, analyte sensor 110 may collect data or perform other operations as appropriate to the sensing hardware 5060 of analyte sensor 110. At step 765, display device 120 may an initiate authentication request command. In response to the authentication request command, both analyte sensor 110 and display device 120 may engage in a mutual authentication process in step 770. Step 770 may involve the transfer of data, including challenge parameters that allow analyte sensor 110 and display device 120 to ensure that the other device is sufficiently capable of adhering to an agreed-upon security framework described herein. Mutual authentication may be based on mechanisms for authentication of two or more entities to each other with or without on-line trusted third parties to verify establishment of a secret key via challengeresponse. Mutual authentication may be performed using two-, three-, four-, or five-pass authentication, or similar versions thereof.

[0142] Following a successful step 770, at step 775 analyte sensor 110 may provide display device 120 with a sensor secret. The sensor secret may contain sensor-unique values and be derived from random values generated during manufacture. The sensor secret may be encrypted prior to or during transmission to prevent third-parties from accessing the secret. The sensor secret may be encrypted via one or more of the keys generated by or in response to the mutual authentication process. At step 780, display device 120 may derive a sensor-unique encryption key from the sensor secret. The sensorunique encryption key may further be session-unique. As such, the sensor-unique encryption key may be determined by each device without being transmitted between analyte sensor 110 or display device 120. At step 785, analyte sensor 110 may encrypt data to be included in payload. At step 790, analyte sensor 110 may transmit the encrypted payload 740 to display device 120 using the communication link established between the appropriate communication models of analyte sensor 110 and display device 120. At step 795, display device 120 may decrypt the payload using the sensor-unique encryption key derived during step 780. Following step 795, analyte sensor 110 may deliver additional (including newly collected) data and display device 120 may process the received data appropriately.

[0143] As discussed herein, analyte sensor 110 may be a device with restricted processing power, battery supply, and storage. The encryption techniques used by analyte sensor 110 (e.g., the cipher algorithm or the choice of implementation of the algorithm) may be selected based at least in part on these restrictions. Display device 120 may be a more powerful device with fewer restrictions of this nature. Therefore, display device 120 may employ more sophisticated, computationally intense encryption techniques, such as cipher algorithms and implementations.

Example Embodiments of Medication Delivery Devices

[0144] The medication delivery functionality of dose guidance system 100 may be realized through inclusion of one or more medication delivery devices (“MDDs”) 152. MDD 152 may be any device configured to deliver a specific dose of medication. MDD 152 may also include devices that transmit data regarding doses to the dose guidance application, e.g., pen caps, even though the device itself may not deliver the medication. MDD 152 may be configured as a portable injection device (“PID”) that may deliver a single dose per one injection, such as a bolus. The PID may 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 may be used to deliver one dose and then disposed of, or may 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 therapy regimen.

[0145] MDD 152 may 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 may deliver medication through the cannula and into the recipient’s body in small increments repeatedly over time. The infusion set may 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 for controlling the slow infusion of the medication. Both a PID and a pump may store the medication in a medication reservoir.

[0146] MDD 152 may 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 may be monitored in a repeated automatic fashion by SCD 102 and that information may be used by the dose guidance embodiments described herein to automatically calculate or otherwise determine the appropriate drug dosage to control the diabetic’s analyte level and subsequently deliver that dose to the diabetic’s body. This calculation may occur within MDD 152 or any other device of dose guidance system 100 and the resulting determined dosage may then be communicated to MDD 152.

[0147] In many embodiments, the dose guidance provided by the embodiments described herein may be for a type 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 may be the same medication delivered by MDD 152. The type of insulin includes human insulin and synthetic insulin analogs. The insulin may also include premixed formulations. However, the dose guidance embodiments set forth herein and the medication delivery capabilities of MDD 152 may be applied to other non-insulin medications. Such medications may include, but are not limited to exenatide, exenatide extended release, liraglutide, lixisenatide, semaglutide, pramlintide, metformin, SLGTl-i inhibitors, SLGT2-i inhibitors, and DPP4 inhibitors. The dose guidance embodiments may also include combination therapies. Combination therapies may include, but are not limited to, insulin and glucagon-like peptide-1 receptor agonists (GLP-1 RA), insulin and pramlintide.

[0148] For ease of description of the dose guidance 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 may alternatively be configured as a pen cap, a pump, or any other type of medication delivery device.

[0149] FIG. 8 A is schematic diagram depicting an example embodiment of MDD 152 configured as a PID, specifically a smart pen. MDD 152 may include a housing 854 for electronics, an injection motor, and a medication reservoir (see FIG. 8B), from which medication may be delivered through needle 856. Housing 854 may include a removable or detachable cap 857 that, when attached, can shield needle 856 when not in use, and then be detached for injection. MDD 152 may also include a user interface 858 which may 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 may also include an actuator 859 that may be moved, depressed, touched or otherwise activated to initiate delivery of the medication from an internal reservoir through needle 856 and into the recipient's body. According to some embodiments, cap 857 and actuator 859 may 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 Publication No. 2019/0343385, which is hereby incorporated in its entirety for all purposes.

[0150] FIG. 8B is a block diagram depicting an example embodiment of MDD 152 having electronics 860, coupled with a power supply 861 and an electric injection motor 862, which in turn is coupled with power supply 861 and a medication reservoir 863. Needle 856 is shown in fluid communication with reservoir 863, and a valve (not shown) may be present between reservoir 863 and needle 856. Reservoir 863 may be permanent or may be removable and replaced with another reservoir containing the same or different medication. Electronics 860 may 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. 8B, electronics 860 may include high-level functional units, including processing circuitry 864, memory 865, communication circuitry 866 configured to communicate in wired and/or wireless fashion with one or more devices external to MDD 152 (such as display device 120) and user interface electronics 868.

[0151] MDD 152 may be implemented in a highly interconnected fashion, where power supply 861 is coupled with each component shown in FIG. 8B and where those components that communicate or receive data, information, or commands (e.g., processing circuitry 864, memory 865, and communication circuitry 866), may be communicatively coupled with every other such component over, for example, one or more communication connections or buses 869.

[0152] Processing circuitry 864 may include one or more processors, microprocessors, controllers, and/or microcontrollers, each of which may be a discrete chip or distributed amongst (and a portion of) a number of different chips. Processing circuitry 864 may include on-board memory. Processing circuitry 864 may interface with communication circuitry 866 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 864 may also interface with communication circuitry 866 to perform the reverse functions necessary to receive a wireless transmission and convert it into digital data or information.

[0153] Processing circuitry 864 may execute software instructions stored in memory 865. These instructions may cause processing circuitry 864 to receive a selection or provision of a specified dose from a user (e.g., entered via user interface 858 or received from another device), process a command to deliver a specified dose (such as a signal from actuator 859), and control motor 862 to cause delivery of the specified dose. These instructions may also cause processing circuitry 864 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 866 to transmit, and others. In embodiments where MDD 152 includes user interface 858, then the instructions may cause processing circuitry 864 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 may instead be implemented by MDD 152 with the use of a hardware or firmware design that does not rely on the execution of stored software instructions to accomplish the functions.

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

[0155] Communication circuitry 866 may 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 866 may include or be coupled to one or more antenna for wireless communication.

[0156] Power supply 861 may include one or more batteries, which may be rechargeable or single-use disposable batteries. Power management circuitry may also be included to regulate battery charging and monitor usage of power supply 861, boost power, perform DC conversions, and the like.

[0157] 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.

Improved User Interface for Dose Calculations

[0158] FIG. 9 is a block diagram of a CGM system having a dosage calculator, according to some embodiments. CGM system 900 may include user 902, display device 120 (and other components disclosed in FIGS. 1A-B), and trusted computer system 180. In this embodiment, trusted computer system 180 may include dosage calculator 921, user interface generator 922, logging module 923, and database 924.

[0159] User 902 may be a human monitoring their glucose levels using a CGM device and administered doses of medication. CGM system 900 may accommodate a wide-array of user types, analyte sensors, and medications. For example, user 902 may be a diabetic having type-1, type-2, or gestational diabetes. User 902 may include users across a diverse user base with different needs and interaction levels. For example, user 902 may be a proactive person with type-1 diabetes on multiple daily doses of insulin that frequently checks their glucose levels, carbohydrate counts, takes post meal correction insulin boluses, and periodically titrates their insulin dosing parameter may have a good sense of how to use CGM data without additional support. However, user 902 may be a person with type-2 diabetes that does not take insulin and may be unsure why their glucose rises differently on certain occasions. User 902 may be a family member or other suitable, authorized agent of a person with diabetes. In some embodiments, user 902 may be a doctor or other medical professional.

[0160] Trusted computer system 180 is described above with reference to FIG. 1. In an embodiment, trusted computer system 180 may include servers, desktops, and other type of electronic device that support CGM system 900 by processing web-based traffic and HTTP request methods. Trusted computer system 180 may store data server-side for retrieval by display device 120. CGM system 900 may return web pages to the users via HTTP for display on display device 120. The returned pages may include images, stylesheets, and scripts, the content and nature of which will be appreciated by those skilled in the relevant art(s). Trusted computer system 180 may cause display device 120 to display user interfaces on display device 120 to receive recommended doses generated by dosage calculator 921, provide additional user inputs, and perform other suitable functions. In an embodiment, trusted computer system 180 may include dosage calculator 921, user interface generator 922, logging module 923, database 924, and other suitable components.

[0161] Dosage calculator 921 may automate the medication-dosage calculation by considering relevant factors (e.g., food intake, activity level, analyte measurements, previous doses, etc.). Dosage calculator 921 may require information on the most recent dose (z.e., amount, timing, or both). Dosage calculator 921 may calculate IOB using a curvilinear decay of active circulating insulin over the DIA. Dosage calculator 921 may analyze a host of additional factors including food intake, activity level, and analyte measurements alongside the IOB to calculate a fully-informed recommended dosage. Dosage calculator 921 may consider a meal type associated with the calculation and calculate the recommended medication dosage based on the meal type. In one embodiment, the meal type may be associated with various parameters used by dosage calculator 921 when calculating the recommended dosage. Such parameters may include glycemic index, glycemic load, rate of glucose appearance profile in an averaged person with standard food bioavailability, macronutrient composition, fiber content, and other suitable parameters that would be understood by one skilled in the relevant arts.

[0162] User interface generator 922 may generate user interfaces for display on display device 120, such as those described below with reference to FIGS. 12A-F and 13A-D. User interface generator 922 may generate appropriate static pages, images, stylesheets, and scripts, and other user-interface components to create the disclosed user interfaces.

[0163] Logging module 923 may allow user 902 to log doses. Logging module 923 may allow user 902 to correct recommended doses. In one embodiment, logging module 923 may store the information in a database, such as database 924 or in other locations such as on MDD 152 if/when connectivity returns between MDD 152 and display device 120 and/or other devices in the system.

[0164] Database 924 may store information about glucose monitoring, past readings, configuration, user information, partner information, and other information relevant to CGM system 900. Database 924 may be a relational database, a NoSQL database or other horizontally scaling database, a digital ledger technology or blockchain, or any other suitable storage mechanism. For instance, database 924 may be a commercially available database management system to store and retrieve data. In an embodiment, database 924 may be retrieved data from a centralized storage area network (“SAN”), network-attached storage (“NAS”), redundant array of independent disks, and/or any other configuration of storage devices to supply sufficient storage capacity to store database tables and supporting structures. Sufficient storage may alternatively exist in any other physically attached magnetic storage, cloud storage, or additional storage medium. In an embodiment, database 924 may deploy a hard-disk interface, such as ATA, SATA, SCSI, SAS, and/or fibre for interfacing with storage mediums housing data.

[0165] With regards to ensuring that dose guidance system 100 is aware of prior insulin doses needed to properly calculate the recommended insulin dose, dose guidance system 100 may be configured to function in two modes; one mode where MDD 152 is a “connected” pen that records the time and amount of insulin delivered and communicates that to display device 120. In a second mode, MDD 152 device does not have connectivity capability. In the first mode, dose guidance system 100 may be configured to detect when MDD 152 has not communicated with display device 120 (e.g., for a predetermined period of time). This can be caused by, for example, MDD 152 no longer working (e.g., out of battery), is lost or otherwise separated from display device 120, or is otherwise no longer in communication with display device 120 or any other device within dose guidance system 100 (e.g., MDD 152 is out of communication range). Dose guidance system 100 may be configured to switch to the second mode, enabling the use of an “unconnected” insulin pen until the connected pen becomes available again (e.g., reestablishes a connection with dose guidance system 100).

[0166] Dose guidance system 100 is configured to switch between modes to enable use of MDDs that are connected to dose guidance system 100 (e.g., MDD 152) and those that are unconnected or otherwise unable to communicate with display device 120. Connected MDDs allow dose guidance system 100 to track medication activity based on information received from MDD 152. In some embodiments, display device 120 in dose guidance system 100 is configured to receive the information from the MDD 152 and further configured to transmit this information to other devices within dose guidance system 100 for further processing or storage. For example, a MDD 152 can broadcast most recent dose information to display device 120 when the dose is made or when a communication connection between MDD 152 and display device 120 is established. In this embodiment, display device 120 determines, prior to calculating and displaying a dose recommendation, if it has most recent dose information. In some embodiments, display device 120 may display a UI prompt which may include a request for user input to confirm that display device 120 has received the most recent dose information. In some embodiments, this determination may be performed automatically at display device 120 based on reviewing and comparing timestamped dose data with a current time. If display device 120 determines that it does not have most recent dose information, display device 120 can provide instructions via another UI prompt to confirm connectivity between display device 120 and MDD 152. In other embodiments, display device 120 may perform this step automatically based on a heartbeat signal or other request signal that is transmitted from display device 120 to MDD 152, that requests MDD 152 to confirm connectivity.

[0167] In some embodiments, MDD 152 provides a means for display device 120 to query MDD 152 for the latest dose. One implementation of this is for MDD 152 to provide a means for display device 120 to “scan” MDD 152 to retrieve the dose history information via a wireless connection, such as via near-field communication (NFC). In another embodiment, another implementation is for MDD 152 to be configured to listen for a RF communication query from display device 120 requesting the dose history information. In response to validating the RF communication query, MDD 152 can be configured to respond with the dose history information via the wireless communication, which could be implemented via NFC, BlueTooth, or BlueTooth Low Energy (“BLE”). In some embodiments, display device 120 could be programmed to automatically send an electronic query to MDD 152 when display device 120 receives a request for dose guidance.

[0168] Display device 120 is configured to automatically toggle between the two modes which enable switching back and forth between a connected (e.g., MDD 152) and an unconnected pen (e.g., e.g., switch between modes without user input). In the first mode, display device 120 may display a prompt requesting confirmation that the most recent dose can be modified when the user cannot confirm the most recent dose. In this embodiment, the instructions to display device 120 will include both instructions for display device 120 to reconnect to MDD 122, or if MDD 122 is not being used, by including an option for display device 120 to receive the necessary dosing information as described further below.

[0169] In a second mode, MDD 152 may be configured to be scanned (e.g., using a camera of display device 120 to scan a physical identifier such as a barcode or QR code) to retrieve the dose history information associated with MDD 152. In response to scanning, display device 120 may display dose guidance screen to provide an option for dose history information to be entered manually, as described below. In some embodiments, MDD 152 can be configured to communicate electronically (e.g., queried via Bluetooth or BLE). Display device 120 can be configured to detect a lack of a response to a query and display a graphical user interface for receiving the dose history information manually.

[0170] Additional details regarding these two modes are discussed with respect to the following figures.

[0171] FIG. 10 illustrates a method 1000 for recommending insulin doses, according to some embodiments. In an embodiment, method 1000 may operate when MDD 152 is connected to display device 120 and/or dosage calculator 921. Method 1000 may be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executing on a processing device), or a combination thereof. It is to be appreciated that not all steps may be needed to perform the disclosure provided herein. Further, some of the steps may be performed simultaneously, or in a different order than shown in FIG. 10, as will be understood by a person of ordinary skill in the art(s).

[0172] In 1001, dosage calculator 921 and/or display device 120 may receive or otherwise access insulin data of user 902 (e.g., from MDD 152). For example, dosage calculator 921 may check for the latest insulin delivery information by requesting delivery information from different sources, including, but not limited to, the MDD 152, an MDD-associated application, or an interface that stores the latest insulin delivery information (such as an MDD application web server), or by checking the memory of the various applications for the latest insulin delivery information.

[0173] In 1002, dosage calculator 921 and/or display device 120 may determine if display device 120 is connected to MDD 152 and the latest available data has been received. Dosage calculator 921 may determine if it has the latest available data based on different factors. In one embodiment, dosage calculator 921 may examine a time gap in insulin dose data. For example, if user 902 is on full multiple daily injection therapy (basal+3 mealtime boluses), then dosage calculator 921 may communicate with MDD 152 or its associated application at least about every six hours. If there has been no communication in that time (or any other predetermined period of time) or if there is no administered dosage information for a predetermined period of time, dosage calculator 921 may be configured to determine that MDD 152 needs to be connected to dosage calculator 921 before providing dose guidance. In one embodiment, dosage calculator 921 may assume that data associated with the last dose administered was not received if the time gap since the last dose administration was received is longer than an assumed time between meals. For instance, an assumed time between meals may be about 5 hours, alternatively about 6 hours, alternatively about 6.5 hours, alternatively about 7 hours, alternatively about 7.5 hours, alternatively about 8 hours. In another embodiment, dosage calculator 921 may detect whether BLUETOOTH communication is enabled between display device 120, e.g., smartphone, and MDD 152. For example, BLUETOOTH communication may not be enabled on either display device 120, or MDD 152 or both. In another embodiment, dosage calculator 921 may detect whether a power source associated with MDD 152 needs to be replaced. If the devices (e.g., MDD 152) are not connected or the data is otherwise unavailable, then method 1000 may proceed to step 1003. Otherwise, method 1000 may proceed to 1004.

[0174] In 1003, it is determined that devices are unconnected or otherwise unable to communicate with display device 120, dosage calculator 921 and/or display device 120 may proceed to display an interface for receiving additional user input. Such a step is detailed in further detail below with reference to FIG. 11. Exemplary screen displays for facilitating this reception of additional input are discussed below with reference to FIGS. 12A-F.

[0175] In 1004, dosage calculator 921 and/or display device 120 may output a dose guidance to the user interface based on the received glucose analyte data and insulin dose data. For example, dosage calculator 921 may calculate IOB using a curvilinear decay of active circulating insulin over the DIA. Dosage calculator may analyze a host of additional factors including food intake, activity level, and analyte measurements alongside the IOB to calculate a fully-informed recommended dosage. [0176] FIG. 11 illustrates a method 1100 for implementing graphical user interfaces that provide dosage recommendations based on detected connectivity conditions (e.g., MDD 152 unconnected or otherwise unable to communicate with display device 120), according to some embodiments. Method 1100 may be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executing on a processing device), or a combination thereof. It is to be appreciated that not all steps may be needed to perform the disclosure provided herein. Further, some of the steps may be performed simultaneously, or in a different order than shown in FIG. 11, as will be understood by a person of ordinary skill in the art(s).

[0177] In 1102, display device 120 may initiate display of a graphical user interface. In an embodiment, trusted computer system 180 may cause display device 120 to display the graphical user interface through an appropriate command. Or display device 120 may display the graphical user interface when being powered on.

[0178] In 1104, display device 120 may determine if display device 120 is connected to MDD 152 and determine if display device 120 has received the latest available data about medication doses. Dosage calculator 921 may determine if it has the latest available data based on different factors. In one embodiment, dosage calculator 921 may examine a time gap in insulin dose data. For example, if user 902 is on full multiple daily injection therapy (one or more basal injections and +3 mealtime boluses), then dosage calculator 921 may communicate with MDD 152 or its associated application at least about every six hours. If there has been no communication in that time, dosage calculator 921 may be configured to determine that MDD 152 needs to be connected to dosage calculator 921 before providing dose guidance. In one embodiment, dosage calculator 921 may assume that data associated with the last dose administered was not received if the time gap since the last dose administration was received is longer than an assumed time between meals. For instance, an assumed time between meals may be about 5 hours, alternatively about 6 hours, alternatively about 6.5 hours, alternatively about 7 hours, alternatively about 7.5 hours, alternatively about 8 hours. In another embodiment, dosage calculator 921 may detect whether Bluetooth communication is enabled between display device 120, e.g., smartphone, and MDD 152. For example, Bluetooth communication may not be enabled on either display device 120, or MDD 152 or both. In another embodiment, dosage calculator 921 may detect whether a power source associated with MDD 152 needs to be replaced. If yes (the devices are both connected and MDD 152 can be queried), then method 1100 may proceed to 1106. If no, then method 1100 may proceed to 1108.

[0179] In 1106, display device 120 may display a calculated dose suggestion. When display device 120 is connected and MDD 152 includes a query capability, display device 120 may calculate and display the dosage suggestion because sufficient information exists to reliably calculate and display the information. For example, dosage calculator 921 may output a dose guidance to the user interface based on the received glucose analyte data and insulin dose data. For example, dosage calculator 921 may calculate IOB using a curvilinear decay of active circulating insulin over the DIA. Dosage calculator 921 may analyze a host of additional factors including food intake, activity level, and analyte measurements alongside the IOB to calculate a fully-informed recommended dosage.

[0180] In 1108, display device 120 may block the dosage suggestion (e.g., eschew from displaying a dose suggestion). For example, display device 120 may disable or grey-out a dose suggestion icon. An exemplary screen display for such a landing page is discussed below with reference to FIG. 12A. In such an example graphical user interface, display device 120 may eschew displaying of a dose suggestion icon.

[0181] In 1110, display device 120 may receive user history input from the user that confirms or supplements recent dose history. In an embodiment, display device 120 may allow user 902 to confirm that a most recent dose was the most recent time that medication was administered. Display device 120 may also present a graphical user interface that allows user 902 to enter the most recent dose. FIGS. 12D-F display alternative embodiments of such a landing page that disable/hide the dose suggestion icon while soliciting addition input/confirmation from user 902.

[0182] In 1112, display device 120 may display a dose suggestion. FIGS. 12C and 13A display exemplary pages for displaying a dose suggestion. Dosage calculator 921 may calculate the medication dosage based on received glucose analyte data, insulin dose data, and the user confirmation or entered log data. For example, dosage calculator 921 may calculate IOB using a curvilinear decay of active circulating insulin over the DIA. Dosage calculator 921 may analyze a host of additional factors including food intake, activity level, and analyte measurements alongside the IOB to calculate a fully-informed recommended dosage. Display device 120 may enable the dose suggestion icon in the graphic user interface or color in a greyed-out dose suggestion icon. Display device 120 may display the calculated medication dosage within the dose suggestion icon.

[0183] In 1114, display device 120 may optionally receive an adjustment from the user. This is an optional step and occurs where the user administers a different dosage than the suggested amount. FIGS. 13B and 13C display example approaches for reaching such an adjustment.

[0184] In 1116, display device 120 may log the administered dose. In one embodiment, this may involve storing the information in a database, such as database 924 or in other locations such as on MDD 152 if/when connectivity returns.

[0185] FIG. 12A is a screen display 1200A of a dose calculation page. Screen display 1200A includes dose suggestion icon 1201A. In the example provided in screen display 1200A, dose suggestion icon 1201 A is empty and thus, user 902 does not receive the dose suggestion until after they confirm the recent doses. In other embodiments, dose suggestion icon 1201A may be greyed out or disabled. Prompt 1202 asks user 902 to “Confirm recent rapid-acting insulin doses to access meal dose guidance.” Confirm doses button 1203 may allow user to enter/confirm doses. In one embodiment, confirm doses button 1203 may route user 902 to a page such as that exemplified by FIG. 12B.

[0186] FIG. 12B is a screen display 1200B that user 902 may receive after clicking confirm doses button 1203 button in screen display 1200 A. In the example provided in screen display 1200B, dose suggestion icon 1201B is greyed out and disabled. However, dose suggestion icon 1201B may be empty or hidden in other embodiments. Confirmation prompt 1204A displays the amount and time of the last dosage and the DI — z.e., “Have you taken any additional rapid-acting insulin in the last 4 hours?”. Screen display 1200B allows user 902 to select “No” to confirm that no doses are missing. Or user 902 may select “Yes, Log Dose(s)” to be routed to a logging page, such as those provided in further detail below.

[0187] FIG. 12C is a screen display 1200C that user 902 may enter after confirming that no doses have been taken or logging recent doses. Screen display 1200C includes dose suggestion icon 1201C displaying a calculated dose suggestion. Meal selector 1205 allows user 902 to associate the dose suggestion with a particular meal.

[0188] FIG. 12D is a screen display 1200D that user 902 may enter after clicking confirm doses button 1203 button in screen display 1200A. This is an alternative approach to the screen display 1200B. Here, no dose suggestion icon is displayed. Moreover, confirmation prompt 1204B displays a question to the user asking if they have administered any insulin within the specified DIA. Confirmation prompt 1204B further includes a visual representation of the DIA in a clock format with a shaded region representing the DIA since the dose request time. Moreover, previously reported doses within that window are highlighted according to the time of the dose.

[0189] FIG. 12E is a screen display 1200E that user 902 may enter after clicking confirm doses button 1203 button in screen display 1200A. This is an alternative approach to the screen display 1200B and screen display 1200D. Here, no dose suggestion icon is displayed. Moreover, confirmation prompt 1204C displays a question to the user asking if they have administered any insulin within the specified DIA. Confirmation prompt 1204C further includes a visual representation of the DIA in a linear timeline with time of day along the x-axis where the DIA since the dose request time is shaded. Moreover, previously reported doses within that window are highlighted according to the time of the dose.

[0190] FIG. 12F is a screen display 1200F that user 902 may enter after clicking confirm doses button 1203 button in screen display 1200A. This is an alternative approach to the screen display 1200B, screen display 1200D, and screen display 1200E. In this example, user 902 may be prompted to confirm that they have not taken any doses since the last recorded dose in confirmation prompt 1204D. Moreover, screen display 1200F offers the further ability to correct or adjust the recommended dosage.

[0191] FIG. 13A is a screen display 1300A that displays dose suggestion icon 1201D have a medication dose calculated by dosage calculator 921. Screen display 1300A also includes reminder 1301 that reminds the user to log the dose if the user administers an adjusted dose.

[0192] FIG. 13B is a screen display 13006 that displays toggle 1302 that allows user 902 to adjust the suggested dose to log the dose that was actually administered. Screen display 13006 displays toggle 1302 as including plus/minus icons to increase/decrease the dose, but other suitable approaches to receiving the user input may be employed within the context of this disclosure. Log button 1303 allows the user to confirm the updated dose. [0193] FIG. 13C is a screen display 1300C displays the logged dose after an adjustment is made. Screen display 1300C includes reset button 1304. Log button 1303 allows the user to confirm the updated dose.

[0194] FIG. 13D is a screen display 1300D that displays dose suggestion icon 1201E along with logged dose 1305 associated with the lunch meal.

Exemplary Computer System

[0195] Various embodiments may be implemented, for example, using one or more well- known computer systems, such as computer system 1400 shown in FIG. 14. One or more computer systems 1400 may be used, for example, to implement any of the embodiments discussed herein, as well as combinations and sub-combinations thereof.

[0196] Computer system 1400 may include one or more processors (also called central processing units, or CPUs), such as a processor 1404. Processor 1404 may be connected to a communication infrastructure or bus 1406.

[0197] Computer system 1400 may also include user input/output device(s) 1408, such as monitors, keyboards, pointing devices, etc., which may communicate with communication infrastructure 1406 through user input/output interface(s) 1402.

[0198] One or more of processors 1404 may be a graphics processing unit (“GPU”). In an embodiment, a GPU may be a processor that is a specialized electronic circuit designed to process mathematically intensive applications. The GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images, videos, etc.

[0199] Computer system 1400 may also include a main or primary memory 1408, such as random access memory (“RAM”). Main memory 1408 may include one or more levels of cache. Main memory 1408 may have stored therein control logic (z.e., computer software) and/or data.

[0200] Computer system 1400 may also include one or more secondary storage devices or memory 1410. Secondary memory 1410 may include, for example, a hard disk drive 1412 and/or a removable storage device or drive 1414. Removable storage drive 1414 may be a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup device, and/or any other storage device/drive.

[0201] Removable storage drive 1414 may interact with a removable storage unit 1418. Removable storage unit 1418 may include a computer usable or readable storage device having stored thereon computer software (control logic) and/or data. Removable storage unit 1418 may be a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, and/ any other computer data storage device. Removable storage drive 1414 may read from and/or write to removable storage unit 1418.

[0202] Secondary memory 1410 may include other means, devices, components, instrumentalities or other approaches for allowing computer programs and/or other instructions and/or data to be accessed by computer system 1400. Such means, devices, components, instrumentalities or other approaches may include, for example, a removable storage unit 1422 and an interface 1420. Examples of the removable storage unit 1422 and the interface 1420 may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and/or any other removable storage unit and associated interface.

[0203] Computer system 1400 may further include a communication or network interface 1424. Communication interface 1424 may enable computer system 1400 to communicate and interact with any combination of external devices, external networks, external entities, etc. (individually and collectively referenced by reference number 1428). For example, communication interface 1424 may allow computer system 1400 to communicate with external or remote devices 1428 over communications path 1426, which may be wired and/or wireless (or a combination thereof), and which may include any combination of LANs, WANs, the Internet, etc. Control logic and/or data may be transmitted to and from computer system 1400 via communication path 1426.

[0204] Computer system 1400 may also be any of a personal digital assistant (PDA), desktop workstation, laptop or notebook computer, netbook, tablet, smart phone, smart watch or other wearable, appliance, part of the Internet-of-Things, and/or embedded system, to name a few non-limiting examples, or any combination thereof.

[0205] Computer system 1400 may be a client or server, accessing or hosting any applications and/or data through any delivery paradigm, including but not limited to remote or distributed cloud computing solutions; local or on-premises software (“onpremise” cloud-based solutions); “as a service” models (e.g., content as a service (“CaaS”), digital content as a service (“DCaaS”), software as a service (“SaaS”), managed software as a service (“MSaaS”), platform as a service (“PaaS”), desktop as a service (“DaaS”), framework as a service (“FaaS”), backend as a service (“BaaS”), mobile backend as a service (“MBaaS”), infrastructure as a service (“laaS”), etc.); and/or a hybrid model including any combination of the foregoing examples or other services or delivery paradigms.

[0206] Any applicable data structures, file formats, and schemas in computer system 1400 may be derived from standards including but not limited to JavaScript Object Notation (“JSON”), Extensible Markup Language (“XML”), Yet Another Markup Language (“YAML”), Extensible Hypertext Markup Language (“XHTML”), Wireless Markup Language (“WML”), MessagePack, XML User Interface Language (“XUL”), or any other functionally similar representations alone or in combination. Alternatively, proprietary data structures, formats or schemas may be used, either exclusively or in combination with known or open standards.

[0207] In some embodiments, a tangible, non-transitory apparatus or article of manufacture comprising a tangible, non-transitory computer useable or readable medium having control logic (software) stored thereon may also be referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer system 1400, main memory 1408, secondary memory 1410, and removable storage units 1418 and 1422, as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (such as computer system 1400), may cause such data processing devices to operate as described herein.

[0208] Based on the teachings contained in this disclosure, it will be apparent to persons skilled in the relevant art(s) how to make and use embodiments of this disclosure using data processing devices, computer systems and/or computer architectures other than that shown in FIG. 14. In particular, embodiments can operate with software, hardware, and/or operating system implementations other than those described herein.

[0209] While this disclosure describes exemplary embodiments for exemplary fields and applications, it should be understood that the disclosure is not limited thereto. Other embodiments and modifications thereto are possible, and are within the scope and spirit of this disclosure. For example, and without limiting the generality of this paragraph, embodiments are not limited to the software, hardware, firmware, and/or entities illustrated in the figures and/or described herein. Further, embodiments (whether or not explicitly described herein) have significant utility to fields and applications beyond the examples described herein.

[0210] Embodiments have been described herein with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined as long as the specified functions and relationships (or equivalents thereof) are appropriately performed. Also, alternative embodiments can perform functional blocks, steps, operations, methods, etc. using orderings different than those described herein.

[0211] References herein to “one embodiment,” “an embodiment,” “an example embodiment,” or similar phrases, indicate that the embodiment described can include a particular feature, structure, or characteristic, but every embodiment can not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it would be within the knowledge of persons skilled in the relevant art(s) to incorporate such feature, structure, or characteristic into other embodiments whether or not explicitly mentioned or described herein. Additionally, some embodiments can be described using the expression “coupled” and “connected” along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments can be described using the terms “connected” and/or “coupled” to indicate that two or more elements are in direct physical or electrical contact with each other. The term “coupled,” however, can also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.

[0212] The breadth and scope of this disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Clauses

[0213] Exemplary embodiments are set out in the following numbered clauses.

1. A method, comprising: responsive to determining that a display device configured to be in data communication with a glucose sensor is not in data communication with a medication delivery device, preventing, by one or more processors, activation of a display of a dose suggestion icon on a graphical user interface of a mobile application on the display device; and responsive to receiving an updated dosage history via a user input: calculating an insulin dosage to be administered by the medication delivery device; and activating the display of the dose suggestion icon in the graphical user interface, wherein the dose suggestion icon indicates the insulin dosage.

2. The method of clause 1, further comprising: providing a confirmation screen to receive the updated dosage history, wherein the confirmation screen comprises a last dose, a time of the last dose, and a duration of insulin action.

3. The method of clause 2, wherein the confirmation screen further comprises a visual representation of the duration of insulin action, wherein the visual representation is a clock having a shaded region representing the duration of insulin action.

4. The method of clause 3, wherein the visual representation further comprises: a previously reported dose indicated on the clock according to a time of the previously reported dose.

5. The method of clause 2, 3 or 4, wherein the confirmation screen further comprises a visual representation of the duration of insulin action, wherein the visual representation is a linear timeline having a shaded region representing the duration of insulin action.

6. The method of clause 5, wherein the visual representation further comprises: a previously reported dose indicated on the linear timeline according to a time of the previously reported dose.

7. The method of any preceding clause, the preventing further comprising at least one of: disabling the dose suggestion icon on the graphical user interface; and greying the dose suggestion icon on the graphical user interface.

8. The method of any preceding clause, the activating further comprising at least one of enabling the dose suggestion icon on the graphical user interface; coloring the dose suggestion icon on the graphical user interface; and displaying the insulin dosage within the dose suggestion icon.

9. The method of any preceding clause, wherein the user input comprises a confirmation of at least one previous dosage of medication administered by the medication delivery device.

10. The method of any preceding clause, wherein the dose suggestion icon is a meal icon, wherein the meal icon is associated with a meal type, and wherein the insulin dosage is calculated based on the meal type.

11. The method of clause 10, the calculating further comprising: retrieving one or more parameters associated with the meal type, wherein the one or more parameters comprise a glycemic index, a glycemic load, a rate of glucose appearance profile in an averaged person with standard food bioavailability, a macronutrient composition, and/or a fiber content.

12. The method of any preceding clause, further comprising: receiving an adjustment input configured to adjust the insulin dosage; and displaying an adjusted insulin dosage based on the adjustment input in the graphical user interface.

13. A system comprising: a memory; at least one processor coupled to the memory and configured to: responsive to determining that a display device configured to be in data communication with an in vivo analyte sensor is not in data communication with a medication delivery device, eschew displaying of a dose suggestion icon on a graphical user interface of a mobile application on the display device; and responsive to receiving an updated insulin dosage history via a user input: calculate an insulin dosage to be administered by the medication delivery device; and activate the display of the dose suggestion icon in the graphical user interface, wherein the dose suggestion icon indicates the calculated insulin dosage.

14. The system of clause 13, the at least one processor further configured to: display a confirmation screen to receive the updated insulin dosage history, wherein the confirmation screen comprises a last dose, a time of the last dose, and a duration of insulin action, wherein the confirmation screen comprises a visual representation of the duration of insulin action, wherein the visual representation is a clock, wherein the visual representation further comprises a shaded region representing the duration of insulin action, and wherein a previously reported dose is indicated on the clock according to a time of the previously reported dose.

15. The system of clause 13, the at least one processor further configured to: display a confirmation screen to receive the updated insulin dosage history, wherein the confirmation screen comprises a last dose, a time of the last dose, and a duration of insulin action, wherein the confirmation screen comprises a visual representation of the duration of insulin action, wherein the visual representation is a linear timeline, wherein the visual representation further comprises a shaded region representing the duration of insulin action, and wherein a previously reported dose is indicated on the linear timeline according to a time of the previously reported dose.

16. The system of clause 13, 14 or 15, wherein to eschew the at least one processor is further configured to at least one of: disable the dose suggestion icon on the graphical user interface; and grey the dose suggestion icon on the graphical user interface.

17. The system of any one of clauses 13 to 16, wherein to activate the at least one processor is further configured to at least one of: enable the dose suggestion icon on the graphical user interface; and color the dose suggestion icon on the graphical user interface. 18. The system of any one of clauses 13 to 17, wherein the user input comprises a confirmation of at least one previous insulin dosage administered by the medication delivery device.

19. The system of any one of clauses 13 to 18, wherein the dose suggestion icon is a meal icon, wherein the meal icon is associated with a meal type, and wherein the insulin dosage is calculated based the meal type.

20. A non-transitory computer-readable device having instructions stored thereon that, when executed by a computing device, causes the computing device to perform operations comprising: responsive to determining that a display device configured to be in data communication with a glucose sensor is not in data communication with a medication delivery device, preventing activation of a display of an insulin dose suggestion icon on a graphical user interface of a mobile application on the display device; and responsive to receiving an updated insulin dosage history via a user input: calculating an insulin dosage of medication to be administered by the medication delivery device; and activating the display of the insulin dose suggestion icon in the graphical user interface, wherein the insulin dose suggestion icon indicates the calculated insulin dosage.

Claims

WHAT IS CLAIMED IS:

1. A method, comprising: responsive to determining that a display device configured to be in data communication with a glucose sensor is not in data communication with a medication delivery device, preventing, by one or more processors, activation of a display of a dose suggestion icon on a graphical user interface of a mobile application on the display device; and responsive to receiving an updated dosage history via a user input: calculating an insulin dosage to be administered by the medication delivery device; and activating the display of the dose suggestion icon in the graphical user interface, wherein the dose suggestion icon indicates the insulin dosage.

2. The method of claim 1, further comprising: providing a confirmation screen to receive the updated dosage history, wherein the confirmation screen comprises a last dose, a time of the last dose, and a duration of insulin action.

3. The method of claim 2, wherein the confirmation screen further comprises a visual representation of the duration of insulin action, wherein the visual representation is a clock having a shaded region representing the duration of insulin action.

4. The method of claim 3, wherein the visual representation further comprises: a previously reported dose indicated on the clock according to a time of the previously reported dose.

5. The method of claim 2, wherein the confirmation screen further comprises a visual representation of the duration of insulin action, wherein the visual representation is a linear timeline having a shaded region representing the duration of insulin action.

6. The method of claim 5, wherein the visual representation further comprises: a previously reported dose indicated on the linear timeline according to a time of the previously reported dose.

7. The method of claim 1, the preventing further comprising at least one of: disabling the dose suggestion icon on the graphical user interface; and greying the dose suggestion icon on the graphical user interface.

8. The method of claim 2, the activating further comprising at least one of: enabling the dose suggestion icon on the graphical user interface; coloring the dose suggestion icon on the graphical user interface; and displaying the insulin dosage within the dose suggestion icon.

9. The method of claim 1, wherein the user input comprises a confirmation of at least one previous dosage of medication administered by the medication delivery device.

10. The method of claim 1, wherein the dose suggestion icon is a meal icon, wherein the meal icon is associated with a meal type, and wherein the insulin dosage is calculated based on the meal type.

11. The method of claim 10, the calculating further comprising: retrieving one or more parameters associated with the meal type, wherein the one or more parameters comprise a glycemic index, a glycemic load, a rate of glucose appearance profile in an averaged person with standard food bioavailability, a macronutrient composition, and/or a fiber content.

12. The method of claim 1, further comprising: receiving an adjustment input configured to adjust the insulin dosage; and displaying an adjusted insulin dosage based on the adjustment input in the graphical user interface.

13. A system comprising: a memory; at least one processor coupled to the memory and configured to: responsive to determining that a display device configured to be in data communication with an in vivo analyte sensor is not in data communication with a medication delivery device, eschew displaying of a dose suggestion icon on a graphical user interface of a mobile application on the display device; and responsive to receiving an updated insulin dosage history via a user input: calculate an insulin dosage to be administered by the medication delivery device; and activate the display of the dose suggestion icon in the graphical user interface, wherein the dose suggestion icon indicates the calculated insulin dosage.

14. The system of claim 13, the at least one processor further configured to: display a confirmation screen to receive the updated insulin dosage history, wherein the confirmation screen comprises a last dose, a time of the last dose, and a duration of insulin action, wherein the confirmation screen comprises a visual representation of the duration of insulin action, wherein the visual representation is a clock, wherein the visual representation further comprises a shaded region representing the duration of insulin action, and wherein a previously reported dose is indicated on the clock according to a time of the previously reported dose.

15. The system of claim 13, the at least one processor further configured to: display a confirmation screen to receive the updated insulin dosage history, wherein the confirmation screen comprises a last dose, a time of the last dose, and a duration of insulin action, wherein the confirmation screen comprises a visual representation of the duration of insulin action, wherein the visual representation is a linear timeline, wherein the visual representation further comprises a shaded region representing the duration of insulin action, and wherein a previously reported dose is indicated on the linear timeline according to a time of the previously reported dose.

16. The system of claim 13, wherein to eschew the at least one processor is further configured to at least one of: disable the dose suggestion icon on the graphical user interface; and grey the dose suggestion icon on the graphical user interface.

17. The system of claim 13, wherein to activate the at least one processor is further configured to at least one of: enable the dose suggestion icon on the graphical user interface; and color the dose suggestion icon on the graphical user interface.

18. The system of claim 13, wherein the user input comprises a confirmation of at least one previous insulin dosage administered by the medication delivery device.

19. The system of claim 13, wherein the dose suggestion icon is a meal icon, wherein the meal icon is associated with a meal type, and wherein the insulin dosage is calculated based the meal type.

20. A non-transitory computer-readable device having instructions stored thereon that, when executed by a computing device, causes the computing device to perform operations comprising: responsive to determining that a display device configured to be in data communication with a glucose sensor is not in data communication with a medication delivery device, preventing activation of a display of an insulin dose suggestion icon on a graphical user interface of a mobile application on the display device; and responsive to receiving an updated insulin dosage history via a user input: calculating an insulin dosage of medication to be administered by the medication delivery device; and activating the display of the insulin dose suggestion icon in the graphical user interface, wherein the insulin dose suggestion icon indicates the calculated insulin dosage.