Systems, devices and methods for dual analyte sensors

Abstract

Analyte monitoring systems and methods for on-body sensor control devices are capable of sensing two or more analytes in a patient and include a processor and memory with instructions for determining various machine states and outputs based on time-correlated sensor data for each analyte. The states and outputs may include warning conditions, advisory messages, corrections to analyte status estimates, indications of sensor control device failure, insulin delivery device failure, drug dose calculations, or analysis reports for one or more analytes. An example system and method is described for dual analytes including glucose and ketones. Data may be transmitted from the sensor control device to a reader for output to a user.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of priority to U.S. Provisional Patent Application No. 63 / 435,028, filed December 23, 2022, which is incorporated herein by reference in its entirety for all purposes. [Technical Field]

[0002] The subject matter described herein relates generally to systems, devices, and methods for dual analyte sensors. In particular, the embodiments described herein include using data collected by a glucose sensor in conjunction with data collected from a ketone sensor to control a user interface device or dosage management device to improve control of a patient's glucose levels. [Background technology]

[0003] There is a huge and growing market for monitoring the health and condition of humans and other living animals. Information describing the physical or physiological state of humans can be used in countless ways to assist and improve quality of life, to diagnose, and even treat undesirable human conditions.

[0004] Devices typically used to gather such information are physiological sensors, such as biochemical analyte sensors, or devices capable of sensing chemical analytes in biological entities. Biochemical sensors come in many forms and can be used to sense analytes in fluids, tissues, or gases that form part of or are produced by biological entities, such as humans. These analyte sensors can be used on or in the body, such as in the case of transcutaneously implanted analyte sensors, or on biological material already removed from the body. Useful applications of such sensors include blood glucose sensing for health assessment, dosage guidance, and related uses. Summary of the Invention [Problem to be solved by the invention]

[0005] However, blood glucose monitoring alone faces certain limitations. For example, type 1 diabetes patients taking SGLT-2i inhibitors, also known as gliflozin or flozin, are at risk of developing diabetic ketoacidosis (DKA). DKA is an adverse condition for diabetic patients that can lead to hospitalization and even death. It is associated with high ketone levels caused by insufficient glucose uptake by insulin-dependent cells during prolonged periods of high glucose levels. DKA due to insufficient glucose uptake can be caused by a patient's insufficient insulin levels or high levels of insulin resistance, possibly due to illness, in which case glucose levels may be within or below the target range.

[0006] SGLT-2i drugs are diabetes medications that help reduce pre- and post-meal glucose fluctuations and are indicated for use in patients with type 2 diabetes. They also help manage glucose levels in patients with type 1 diabetes. However, concerns remain about their use in type 1 patients because their use can lead to high ketone levels and DKA with normal glucose levels, referred to herein as euglycemic DKA. For patients with type 1 diabetes, sotagliflozin, an SGLT-1 and SGLT-2i inhibitor, is the only SGLT-2i-containing medication approved by the European Medicines Agency. Therefore, continuous ketone monitoring is an important component of type 2 diabetes management with SGLT-2i drugs and may potentially reduce the risk of euglycemic DKA in patients with type 1 diabetes taking SGLT-2i drugs.

[0007] Treatment of euglycemic DKA is primarily insulin administration and offsetting unwanted glucose declines with carbohydrate intake. However, patients may be unsure when to do so and when to seek emergency medical intervention. Specifically, it can be difficult to know what to do when ketones are elevated but not high enough to indicate DKA and glucose levels are below the normal range. Furthermore, the patient's HCP may benefit from contextual information before and after the elevated or high ketone episode to better understand the reasons for this condition and aid in relief when necessary.

[0008] Individual ketone test strips can be used with continuous glucose monitoring (CGM), but may be impractical for timely monitoring of ketones. Because a specific high glucose reading does not necessarily correlate with a specific high ketone reading, determining when to take a ketone test strip can require guesswork. Regardless of how a patient's ketones are measured, interpreting the ketone levels along with the patient's glucose levels and determining appropriate action is too complicated for most patients and requires input from a healthcare provider (HCP). Therefore, ketone sensing and use of ketone data by patients taking SGLT-2i inhibitors is relatively difficult and cumbersome compared to continuous glucose sensing.

[0009] For these and other reasons, there is a need for improved ketone sensing, analysis, and patient guidance for patients prone to euglycemic DKA, such as those taking SGLT-2i inhibitors. [Means for solving the problem]

[0010] Described herein are exemplary embodiments of systems, devices, and methods for dual analyte sensors that use glucose history from a glucose sensor in combination with data from a ketone sensor to control a user interface device, a healthcare provider interface device, or a dose management device to improve control of a patient's glucose levels.

[0011] Analyte monitoring systems and methods for on-body sensor control devices are capable of sensing two or more analytes in a patient, include a processor and memory with instructions for determining various machine conditions, and provide output based on time-correlated sensor data for each analyte. The conditions and outputs may include warning conditions for one or more analytes, advisory messages, corrections to analyte status estimates, indications of sensor control device failures, insulin delivery device failures, drug dose calculations, or analysis reports. An example system and method is described for dual analytes including glucose and ketones. Data may be transmitted from the sensor control device to a reader for output to a user.

[0012] The present disclosure describes mobile app-based systems, devices, and methods for detecting actionable conditions, providing guidance to patients and also providing a means to record and output important context contemporaneous with the situation that can later assist HCPs in advising patients on how to avoid such adverse conditions in the future. In embodiments, the systems, devices, or methods may include features for generating knowledge of a patient's medication status and / or medication information, such as, for example, a type 1 diabetes (DM) patient taking an SGLT-2i inhibitor. Alternatively, or in addition, the systems, devices, or methods may deliver guidance to the patient at a more appropriate time to obtain additional information and context about the patient's condition when the patient can remember and provide the information.

[0013] Additionally or alternatively, an improved system, method, or device may include improving the alerting capabilities of an analyte monitoring sensor (e.g., a glucose sensor) by using context from a ketone sensor and / or medication status estimates and / or knowledge of medication information (e.g., a type 1 diabetes mellitus (T1DM) patient taking an SGLT-2i inhibitor). In comparison, a single analyte sensor system may include, for example, an upper threshold alert and a lower predicted threshold alert. Single analyte alerts may be improved by adjusting alert behavior and timing using data from a ketone sensor. This may include a dual glucose-ketone analyte system, for which threshold alerts are based on each analyte value independently of other analyte values ​​and / or medication-based information. Examples of adjusting alert behavior include the use of lower or upper thresholds. Examples of adjusting timing include varying the time interval between alert issuances if alert conditions remain met. Adjusting timing may improve the clinical relevance of alerts and reduce alert fatigue by minimizing presentations that may be less clinically relevant.

[0014] The systems, devices, and methods disclosed herein incorporate ketone data with blood glucose data to provide patients and HCPs with more reliable guidance than high glucose threshold detection alone. This may provide improved utility for on-demand or continuous glucose monitoring (CGM) systems. For example, on-demand testing systems that include a built-in ketone measurement-compatible strip port may provide increased utility to patients and help HCPs make more accurate recommendations. Overall, the systems, devices, and methods disclosed herein may better protect patients from the risk of DKA. Algorithmic improvements in the systems, methods, and devices, including the use of rich glucose history from on-demand or CGM systems, the opportunistic use of insulin history (e.g., from a built-in bolus calculator), and ongoing ketone measurements (e.g., from a built-in ketone-compatible strip port or in vivo ketone analyte sensor), may improve future DKA risk estimation and further improve DKA risk assessment. Improved risk assessment algorithms may include, for example, comparing estimated ketone time series values ​​to ketone-specific thresholds instead of comparing point glucose levels to conservative point glucose-specific thresholds as is traditionally done.

[0015] According to some embodiments, an analyte monitoring system includes an analyte sensor including at least a portion configured to be inserted into a user's body; a sensor controller including a first processing circuit and a first non-transitory memory and configured to collect first time-correlated data indicative of a glucose level and second time-correlated data indicative of a ketone level; and a reader including a second processing circuit and a second non-transitory memory, wherein at least one of the first or second non-transitory memories includes instructions that, when executed, cause at least one of the first or second processing circuits to determine, based at least in part on the first and second time-correlated data, at least one of a warning condition for one or both of the first and second time-correlated data, an advisory message for output by the reader, a correction of an analyte status estimate, a sensor controller failure, an insulin delivery device failure, a drug dosage calculation, or an analysis report based on the first and second time-correlated data, and output, by the reader, an indication of the results of the determining.

[0016] According to some embodiments, a computer-based method for monitoring and controlling a test substance in a patient includes collecting, with a sensor control device including a test substance sensor at least in part inserted into a user's body, first time-correlated data indicative of a glucose level and second time-correlated data indicative of a ketone level; determining, at least in part based on the first and second time-correlated data, at least one of an alert condition for one or both of the first and second time-correlated data, an advisory message for output by a reading device, a correction of a test substance status estimate, a sensor control device failure, an insulin delivery device failure, a drug dosage calculation, or an analysis report based on the first and second time-correlated data; and outputting, with a user interface device, the results of the determination.

[0017] Other systems, devices, methods, features, and advantages of the subject matter described herein will be or become apparent to one with skill in the art upon examination of the following figures and detailed description. All such additional systems, methods, features, and advantages are intended to be included herein, be within the scope of the subject matter described herein, and be protected by the accompanying claims. Unless features of the example embodiments are expressly recited in the accompanying claims, they should not be construed as limiting the claims in any way.

[0018] Details of the subject matter presented herein, both in structure and operation, will become apparent upon examination of the accompanying drawings, in which like reference numerals indicate like parts. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the subject matter. Moreover, all figures are intended to convey concepts and may depict relative sizes, shapes, and other detailed attributes in a schematic, rather than literal, manner. [Brief explanation of the drawings]

[0019] [Figure 1] FIG. 1 illustrates an exemplary embodiment of an in vivo analyte monitoring system. [Figure 2] FIG. 2 is a block diagram of an exemplary embodiment of a reading device. [Figure 3] FIG. 2 is a block diagram of an exemplary embodiment of a sensor control device. [Figure 4] 10 is a table illustrating the conditional logic for constructing advice messages. [Figure 5] 1 is a flow chart illustrating an exemplary embodiment of a method for analyte monitoring and control. DETAILED DESCRIPTION OF THE INVENTION

[0020] Before describing the present subject matter in detail, it should be understood that the present disclosure is not limited to the particular embodiments described, as such may vary. It should also be understood that the terminology used herein is used merely to describe particular embodiments and is not intended to be limiting. The scope of the present disclosure is limited only by the appended claims.

[0021] The publications discussed herein are provided solely for their disclosure prior to the filing date of the present application. Nothing herein should be construed as an admission that the present disclosure is not entitled to antedate such publications by virtue of their prior disclosure. Further, the dates of publication provided may be different from the actual publication dates, which may need to be independently confirmed.

[0022] Generally, embodiments of the present disclosure relate to systems, devices, and methods for detecting at least one analyte, such as glucose, in bodily fluids (e.g., subcutaneously in interstitial fluid (“ISF”) or blood, dermal fluid in the dermal layer, etc.), along with a feature for ketone analyte sensing that correlates time-series with analyte data from an in vivo glucose sensor. Embodiments may include an in vivo analyte sensor in which at least a portion of the sensor is placed or can be placed within a user's body and is structurally configured to acquire information about bodily glucose and ketone analytes. It should be noted that the embodiments disclosed herein may be used in in vivo analyte monitoring systems that incorporate in vitro capabilities, as well as purely in vitro or ex vivo analyte monitoring systems, including completely noninvasive systems. When used with a single analyte in vivo sensor, ketone test data may be added manually, for example, by using a test strip. Alternatively, embodiments of the present disclosure may be used with dual sensor systems for continuous or near-continuous monitoring of different analytes, e.g., blood glucose and ketone bodies.

[0023] Additionally, systems and devices capable of performing each of the method embodiments disclosed herein are also encompassed within the scope of the present disclosure. For example, sensor control device embodiments are disclosed, which may include one or more sensors, analyte monitoring circuitry (e.g., analog circuitry), non-transitory memory (e.g., for storing instructions), power sources, communication circuitry, transmitters, receivers, processing circuitry, and / or controllers (e.g., for executing instructions) that may perform or facilitate any and all method steps. These sensor control device embodiments may be used to implement the steps performed by the sensor control device from one or more of the methods described herein.

[0024] Similarly, reader device embodiments are disclosed that include one or more transmitters, receivers, non-transitory memory (e.g., for storing instructions), power sources, processing circuits, and / or controllers (e.g., for executing instructions) that may perform or facilitate the execution of any and all method steps. These reader device embodiments may be used to implement those steps performed by the reader device from one or more of the methods described herein.

[0025] Also disclosed are embodiments of trusted computer systems, which may include one or more processing circuits, controllers, transmitters, receivers, non-transitory memory, databases, servers, and / or networks, and may be discretely located or distributed across multiple geographic locations. These trusted computer system embodiments may be used to perform steps from one or more of the methods described herein, performed by the trusted computer system.

[0026] Various embodiments of systems, devices, and methods for analyte monitoring and control are disclosed. According to some embodiments, these systems, devices, and methods may utilize first data collected by a glucose sensor and second data collected by a ketone sensor.

[0027] Other features and advantages of the disclosed embodiments are further described below.

[0028] However, before describing the embodiments in detail, it is desirable to describe examples of devices that may be placed in an in vivo analyte monitoring system, and examples of their operation, all of which may be used in the embodiments described herein.

[0029] Exemplary Embodiments of an Analyte Monitoring System There are various types of analyte monitoring systems. A "continuous analyte monitoring" system (or "continuous glucose monitoring" system), for example, is an in-vivo system that can transmit data from a sensor controller to a reader device repeatedly or continuously, e.g., automatically, unprompted, on a schedule. As another example, a "flash analyte monitoring" system (or "flash glucose monitoring" system, or simply "flash" system) is an in-vivo system that can transfer data from a sensor controller in response to a scan or request for data by a reader device, such as using near-field communication (NFC) or radio frequency identification (RFID) protocols. In-vivo analyte monitoring systems can operate without the need for fingerstick calibration.

[0030] An in-vivo monitoring system includes a sensor that, when placed in vivo, contacts a user's bodily fluids and senses the level of one or more analytes therein. The sensor is part of a sensor control device located on the user's body and includes electronics and a power source that enable and control analyte sensing. Sensor control devices and variations thereof may also be referred to as, for example, "sensor control units," "on-body electronics" devices or units, "on-body" devices or units (OBUs), or "sensor data communication" devices or units. As used herein, these terms are not limited to devices with analyte sensors but include devices with other types of sensors, whether biometric or non-biometric. The term "on-body" refers to any device located directly on or near the body, such as a wearable device (e.g., eyeglasses, watches, wristbands or bracelets, neckbands or necklaces, etc.).

[0031] In-vivo monitoring systems may also include one or more reader devices that receive sensed analyte data from the sensor control device. These reader devices may process and / or display the sensed analyte or sensor data to a user in any number of forms. These devices and variations thereof may be referred to as "user interface devices," "handheld readers," "readers" (or simply "readers"), "handheld electronic devices" (or handheld devices), "portable data processing" devices or units, "data receivers," "receiver" devices or units (or simply receivers), "relay" devices or units, or "remote" devices or units, to name a few. Other devices, such as personal computers, may also be used with or incorporated into in-vivo and in-vitro monitoring systems.

[0032] In vivo analyte monitoring systems are distinguished from "in vitro" systems that contact a biological sample outside the body (or, rather, "ex vivo"); "in vitro" systems typically include a metering device having a port that receives an analyte test strip carrying a user's bodily fluid, which can be analyzed to determine the user's analyte level. As previously mentioned, the embodiments described herein can be used with in vivo systems, in vitro systems, and combinations thereof.

[0033] 1 illustrates an exemplary embodiment of an in vivo analyte monitoring system 100 having a sensor controller 102 and a reader 120 in communication with each other, which may communicate unidirectionally or bidirectionally over a local communication channel (or link) 140, which may be wired or wireless. In wireless embodiments, communication channel 140 may use a near field communication (NFC) protocol, an RFID protocol, Bluetooth or Bluetooth low energy protocol, Wi-Fi protocol, proprietary protocols, etc., including variations existing as of the filing date of this application or developed thereafter.

[0034] The reading device 120 may communicate with a computer system 170 (e.g., a local or remote computer system) through communication path (or link) 141 and with a network 190, such as the Internet or the cloud, through communication path (or link) 142, either wired, wireless, or a combination thereof. Communication with the network 190 may include communication with a trusted computer system 180 within the network 190 or communication through the network 190 to the computer system 170 via communication link (or channel) 143. Communication paths 141, 142, and 143 may be wireless, wired, or both, unidirectional, or bidirectional, and may be part of a telecommunications network such as a Wi-Fi network, a local area network (LAN), a wide area network (WAN), the Internet, or other data network. In some cases, communication paths 141 and 142 may be the same communication path. All communications over communication paths 140, 141, 142 are encrypted, and sensor control device 102, reader device 120, computer system 170, and trusted computer system 180 may each be configured to encrypt and decrypt their transmitted and received communications.

[0035] Variations of the devices 102, 120 and other components of an in vivo analyte monitoring system suitable for use with the systems, devices, and methods described herein are disclosed in U.S. Patent Application Publication No. 2011 / 0213225 (hereinafter the '225 publication), the disclosure of which is incorporated herein by reference in its entirety for all purposes.

[0036] The sensor control device 102 may include a housing 103 that houses an in-vivo analyte monitoring circuit and a power source. In this embodiment, the in-vivo analyte monitoring circuit is electrically connected to one or more analyte sensors 104, 106 that extend through an adhesive patch 105 and protrude from the housing 103. The sensors may include a blood glucose sensor 104 and a ketone sensor 106. The adhesive patch 105 may include an adhesive layer (not shown) for attachment to the skin surface of a user's body. Other forms of body attachment may be used in addition to or instead of adhesion.

[0037] The glucose sensor 104 and, optionally, the ketone sensor 106 may be adapted for at least partial insertion into a user's body, where they are in fluid contact with the user's bodily fluids (e.g., subcutaneous (subdermal) fluid, skin fluid, or blood) and may be used in conjunction with in-vivo analyte monitoring circuitry to measure data related to the user's analytes. The sensors 104, 106 and any associated sensor control electronics may be applied to the body in any desired manner. For example, an insertion device 150 may be used to position all or a portion of the analyte sensor 104 through the exterior surface of the user's skin and in contact with the user's bodily fluids. In doing so, the insertion device may also position the sensor control device 102 with the adhesive patch 105 on the skin. In other embodiments, the insertion device may first position the sensor 104 and then later couple the associated sensor control electronics to the sensor 104, either manually or with the aid of a mechanical device. Examples of insertion devices are disclosed in U.S. Patent Application Publication Nos. 2008 / 0009692, 2011 / 0319729, 2015 / 0018639, 2015 / 0025345, and 2015 / 0173661, the disclosures of all of which are incorporated by reference in their entirety and for all purposes.

[0038] After collecting raw data from the user's body, the sensor controller 102 may perform analog signal conditioning on the data to convert it into conditioned raw data in a digital format. In some embodiments, the sensor controller 102 may then algorithmically process the digital raw data into a format that represents the user's measured biometric (e.g., analyte level) and / or one or more analyte metrics based thereon. For example, the sensor controller 102 may include processing circuitry to algorithmically perform any of the method steps described herein. The sensor controller 102 may then encode and wirelessly communicate data indicative of glucose levels, ketone levels, a sensor malfunction indication, and / or processed sensor data to the reader 120, which may format or graphically process the received data for digital display to the user. In other embodiments, in addition to or instead of wirelessly communicating the sensor data to another device (e.g., the reader 120), the sensor controller 102 may graphically process the data so that it can be displayed in its final form and display the data on the sensor controller's display. In some embodiments, the biometric data in its final form (before graphical processing) is used by a system (eg, integrated into a diabetes monitoring regimen) without further processing for display to a user.

[0039] In yet other embodiments, the conditioned raw digital data may be encoded for transmission to another device, such as reader 120, and the raw digital data may then be algorithmically processed into a format that represents the user's measured biometric (e.g., a format that may be readily suitable for display to the user) and / or one or more analyte metrics based thereon. Reader 120 may include processing circuitry and may use algorithms to perform any of the method steps described herein, such as, for example, correcting a glucose level measurement, detecting a suspected low glucose condition, or detecting a suspected sensor fault condition, or other action. This algorithmically processed data may then be formatted or graphically processed for digital display to the user.

[0040] In other embodiments, the sensor controller 102 and reader 120 transmit the raw digital data to another computer system for algorithmic processing and display.

[0041] Reading device 120 includes a display 122 for outputting information to a user and / or accepting input from a user, and an optional input 121 (or two or more), such as buttons, actuators, touch-sensitive switches, capacitive switches, pressure-sensitive switches, or a jog wheel, for inputting data, commands, or otherwise controlling the operation of reading device 120. In some embodiments, display 122 and input 121 are integrated into a single component; for example, the display may detect physical contact with the display, such as a touchscreen user interface, and its location. In some embodiments, input 121 of reading device 120 includes a microphone, and reading device 120 may include software configured to analyze voice input received from the microphone, allowing functions and operations of reading device 120 to be controlled by voice commands. In some embodiments, the output of reading device 120 includes a speaker (not shown) for outputting information as an audible signal. A speaker, microphone, and similar audio response components such as software routines for generating, processing, and storing audio signals may be included in the sensor controller 102 .

[0042] The reader 120 may also include one or more data communication ports 123 for wired data communication with external devices, such as the computer system 170 or the sensor control device 102. Exemplary data communication ports include a USB port, a mini-USB port, a USB Type-C port, a USB Micro-A and / or Micro-B port, an RS-232 port, an Ethernet port, a Firewire port, or other similar data communication ports configured to connect to a suitable data cable. The reader 120 may also include an integrated or attachable in vitro glucose meter, which may include an in vitro test strip port (not shown) for accepting in vitro glucose test strips for performing in vitro blood glucose measurements.

[0043] The reader 120 is configured to display the measured biometric data wirelessly received from the sensor control device 102 and also to output alarms, warning notifications, glucose values, etc., which may be visual, audible, tactile, or any combination thereof. Further details and other display embodiments are disclosed, for example, in U.S. Patent Application Publication No. 2011 / 0193704, the disclosure of which is incorporated herein by reference in its entirety and for all purposes.

[0044] The reader 120 may act as a data waveguide, transferring measurement data and / or analyte metrics from the sensor controller 102 to the computer system 170 or the trusted computer system 180. In some embodiments, data received from the sensor controller 102 may be stored (permanently or temporarily) in one or more memories of the reader 120 before being uploaded to the systems 170, 180, or the network 190.

[0045] Computer system 170 may be a personal computer, server terminal, laptop computer, tablet, or other suitable data processing device. Computer system 170 may be (or may include) software for data management and analysis, as well as communication with components of analyte monitoring system 100. Computer system 170 may be used by a user or medical professional to display and / or analyze biometric data measured by sensor control device 102. In some embodiments, sensor control device 102 may communicate biometric data to computer system 170 directly without an intermediary, such as reader 120, or indirectly using an internet connection (and optionally without first transmitting to reader 120). Operation and use of computer system 170 are further disclosed in the incorporated '225 publication, further including method steps for handling ketone data along with blood glucose data. Analyte monitoring system 100 may also be configured to operate using a data processing module (not shown), also disclosed in the incorporated '225 publication.

[0046] The trusted computer system 180 may be physically or virtually owned by the manufacturer or distributor of the sensor control device 102 through a protected network and may be used to authenticate the sensor control device 102 and serve as a secure storage unit for the user's biometric data and / or a server that functions, for example, as a data analysis program (e.g., accessible via a web browser) for analyzing the user's measurement data.

[0047] Exemplary embodiments of a reading device The reader 120 may be a portable communication device such as a dedicated reader (a computer system 170 configured for communication with the sensor control device 102, optionally without cellular communication capabilities) or a mobile phone, including, but not limited to, a Wi-Fi or Internet-enabled smartphone, tablet, or personal digital assistant (PDA). Examples of smartphones include mobile phones based on the Windows® operating system, the Android™ operating system, the iPhone® operating system, the Palm® WebOS™, the Blackberry® operating system, or the Symbian® operating system, and have Internet connectivity and / or data network connectivity for data communication over a local area network (LAN).

[0048] The reading device 120 may also be configured as a portable smart wearable electronics assembly, such as an optical assembly worn on or adjacent to a user's eye (e.g., a smart monocular or smart glasses, such as Google® Glasses, that are portable communication devices). Such an optical assembly may have a transparent display that displays information about the user's analyte level (as described herein) to the user, while allowing the user to see through the display, minimizing obstruction to the user's overall field of view. The optical assembly may be capable of wireless communication, similar to a smartphone. Other examples of wearable electronics include devices worn around or near the user's wrist (e.g., a watch), around or near the neck (e.g., a necklace), around or near the head (e.g., a headband, hat), around or near the chest, etc.

[0049] 2 is a block diagram of an exemplary embodiment of reader 120 configured as a smartphone. Here, reader 120 includes input 121, display 122, and processing circuitry 206, which may include one or more processors, microprocessors, controllers, and / or microcontrollers, each of which may be individual chips or distributed across (or portions of) multiple different chips. Here, processing circuitry 206 includes a communications processor 222 having on-board memory 223 and an application processor 224 having on-board memory 225. Reader 120 further includes RF communications circuitry 228 connected to RF antenna 229, memory 230, multifunction circuitry 232 having one or more associated antennas 234, power supply 226, power management circuitry 238, and a clock (not shown). One or both of the memories 223, 225 may hold program instructions that, when executed by one or more processing units 222, 224, may cause the reading device 120 to perform one or more of the operations of the methods described herein. Figure 2 is a schematic diagram illustrating typical hardware and functionality located in a smartphone, and one skilled in the art will readily recognize that other hardware and functionality (e.g., codecs, drivers, glue logic) may also be included.

[0050] The communications processor 222 interfaces with the RF communications circuitry 228 and may perform analog-to-digital conversion, encoding and decoding, digital signal processing, and other functions to facilitate converting voice, video, and data signals into a format (e.g., in-phase and quadrature) suitable for providing to the RF communications circuitry 228, which may then transmit the signals wirelessly. The communications processor 222 may also interface with the RF communications circuitry 228 and perform the reverse functions necessary to receive wireless communications and convert them into digital data, voice, and video. The RF communications circuitry 228 may include a transmitter and receiver (e.g., integrated as a transceiver) and associated encoder logic.

[0051] The application processor 224 may be adapted to run the operating system and any software applications on the reader 120, process video and graphics, and perform other functions unrelated to processing communications transmitted and received through the RF antenna 229. The smartphone operating system operates in conjunction with numerous applications on the reader 120. Any number of applications (also known as “user interface applications”) may be running on the reader 120 at any one time, which may include one or more applications related to the diabetes monitoring therapies and methods described herein, in addition to other commonly used applications unrelated to such therapies, such as email, calendar, weather, sports, games, etc. For example, data indicative of sensed analyte levels and ex vivo blood analyte measurements received by the reader may be securely communicated to a user interface application resident in the memory 230 of the reader 120. Such communication may be performed securely, for example, through mobile application containerization or wrapping techniques.

[0052] The memory 230 may be shared by one or more of the various functional units within the reader 120, or distributed among two or more of them (e.g., as separate memories in different chips). The memory 230 may also be a separate chip in its own right. The memories 223, 225, 230 may be non-transitory and may further be volatile (e.g., RAM, etc.) and / or non-volatile memory (e.g., ROM, flash memory, F-RAM, etc.).

[0053] The multi-function circuitry 232 may be embodied as one or more chips and / or components (e.g., transmitters, receivers, transceivers, and / or other communication circuitry) that perform, for example, local wireless communication with the sensor controller 102 over an appropriate protocol (e.g., Wi-Fi, Bluetooth, Bluetooth low energy, near field communication (NFC), radio frequency identification (RFID), proprietary protocols, etc.) and other functions, such as determining the geographic location of the reader 120 (e.g., Global Positioning System (GPS) hardware). One or more other antennas 234 may be associated with the functional circuitry 232 as needed to operate with various protocols and circuits.

[0054] The power supply 226 may include one or more batteries, which may be rechargeable or disposable. The power management circuitry 238 may regulate battery charging and power monitoring, boost power, DC conversion, etc.

[0055] The reading device 120 may include or be integrated with a medication (e.g., insulin) delivery device, e.g., sharing a common housing. An example of such a medication delivery device is a medication pump (e.g., a wearable pump for delivering basal and bolus insulin) that is left in the body and has a cannula that allows infusion over hours or days. When combined with a medication pump, the reading device 120 may include a reservoir for storing the medication, a pump connectable to a transfer tube, and an infusion cannula. The pump may push the medication from the reservoir, through the tube, and into the diabetic patient's body through an inserted cannula. Another example of a medication delivery device that may be included in (or integrated with) the reading device 120 includes a portable infusion device (e.g., an insulin pen) that pierces the skin only for each delivery and is then removed. When combined with a portable infusion device, the reading device 120 includes an infusion needle, a cartridge for containing the medication, an interface for controlling the amount of medication to be delivered, and an actuator for causing the infusion. The device may be used repeatedly until the medication is depleted, at which point the combined device may be discarded or the cartridge replaced with a new one, at which point the combined device may be reused repeatedly. The needle may be replaced after each injection.

[0056] The combined device may function as part of a closed-loop system (e.g., an artificial pancreas system that requires no user intervention to operate) or a semi-closed-loop system (e.g., an insulin loop system that requires little user intervention to operate, such as checking for dosage changes). For example, the sensor control device 102 may repeatedly and automatically monitor a diabetic patient's analyte level, then communicate the monitored analyte level to the reader 120 to automatically determine an appropriate medication dosage to control the diabetic patient's analyte level, and then deliver the medication to the diabetic patient. Software instructions controlling the pump and the amount of insulin delivered may be stored in the memory of the reader 120 and executed by the reader's processing circuitry. Furthermore, these instructions may cause the amount and duration of medication delivery (e.g., a bolus infusion and / or a basal infusion profile) to be calculated based on analyte level measurements obtained directly or indirectly from the sensor control device 102. In some embodiments, the sensor control device 102 may determine the medication dosage and communicate it to the reader 120.

[0057] Exemplary Embodiments of a Sensor Control Device FIG. 3 is a block diagram illustrating an exemplary embodiment of a sensor controller 102 having an analyte sensor 104 and sensor electronics 250 (including analyte monitoring circuitry), which may contain most of the processing power suitable for displaying final result data to a user. In FIG. 3, a single semiconductor chip 251 is shown, which may be a custom application-specific integrated circuit (ASIC). Within the ASIC 251, several high-level functional units are shown, including an analog front-end (AFE) 252, a power management (or control) circuit 254, a processing unit 256, and a communications circuit 258 (which may be implemented as a transmitter, a receiver, a transceiver, passive circuitry, or other aspects depending on the communications protocol). In this embodiment, both the AFE 252 and the processing unit 256 are used as analyte monitoring circuitry, although in other embodiments, either circuitry may perform the analyte monitoring function. The processing unit 256 may include one or more processors, microprocessors, controllers, and / or microcontrollers, each of which may be a separate chip or may be distributed across multiple different chips.

[0058] Memory 253 is also included within ASIC 251 and may be shared by various functional units within ASIC 251 or distributed among two or more processors. Memory 253 may also be a separate chip. Memory 253 may be non-transitory, volatile, and / or non-volatile memory. In this embodiment, ASIC 251 is connected to a power source 260, such as a coin battery. AFE 252 interfaces with one or more in-vivo analyte sensors 104, 106 to receive measurement data therefrom and outputs the data in digital form to processor 256, which may then, in some embodiments, process the data in any manner described herein. This data is then provided to communication circuitry 258 for transmission via antenna 261 to reader 120 (not shown), where it requires minimal further processing by a resident software application to display the data. Antenna 261 may be configured as needed for the application and communication protocol. Antenna 261 may be, for example, a printed circuit board (PCB) trace antenna, a ceramic antenna, or a discrete metal antenna. Antenna 261 may be configured as a monopole antenna, a dipole antenna, an F-antenna, a loop, etc.

[0059] Information may be communicated from the sensor controller 102 to a second device (e.g., the reader 120) at the initiative of the sensor controller 102 or the reader 120. For example, information may be communicated by the sensor controller 102 automatically and / or repeatedly (e.g., continuously) when analyte information is available or on a schedule (e.g., about every minute, about every five minutes, about every ten minutes, etc.), where the information may be stored or logged in the sensor controller 102's memory for later communication. Information may be transmitted from the sensor controller 102 in response to receipt of a request by the second device. This request may be an automatic request, e.g., a request transmitted by the second device on a schedule, or a user-initiated request (e.g., an ad hoc or manual request). In some embodiments, a manual request for data is referred to as a "scan" of the sensor controller 102 or an "on-demand" data transfer from the device 102. In some embodiments, the second device may send polling signals or data packets to the sensor control device 102, and the device 102 may treat each poll (or polls occurring at certain time intervals) as a data request and transmit such data to the second device when the data is available. While in many embodiments, communication between the sensor control device 102 and the second device is secure (e.g., encrypted and / or between authenticated devices), in some embodiments, data may be broadcast from the sensor control device 102 in an insecure manner, for example, to all devices within range.

[0060] Different types and / or formats and / or amounts of information may be transmitted as part of each communication, including, but not limited to, one or more of the current sensor measurement value (e.g., most recently acquired test substance level information, corresponding in time to the start time of the reading), the rate of change of the measured metric over a predetermined period of time, the metric rate of change velocity (acceleration of the rate of change), or historical metric information corresponding to metric information acquired prior to the predetermined reading and stored in the memory of the sensor control device 102.

[0061] Some or all of the real-time, historical, rate-of-change, and (acceleration or deceleration) rate-of-change velocity information may be sent to reader 120 in a given communication or transmission. In some embodiments, the type and / or format and / or amount of information sent to reader 120 may be preprogrammed and / or non-alterable (e.g., preset at the time of manufacture), or may not be preprogrammed and / or immutable, but may be selectable and / or alterable one or more times in the field (e.g., by actuation of a switch in the system, etc.). Thus, in some embodiments, reader 120 may output the current (real-time) analyte value from the sensor (e.g., in numeric form), the current analyte rate of change (e.g., in the form of an analyte rate indicator, such as an arrow pointing in the direction indicating the current rate), and historical analyte trend data (e.g., in the form of a graphical trace) based on sensor readings obtained by sensor controller 102 and stored in its memory. Additionally, on-skin or sensor temperature readings or measurements may be collected by optional temperature sensor 257. These readings or measurements may be communicated (individually or as aggregate measurements over time) from sensor control device 102 to other devices (e.g., reader 120). Note that instead of, or in addition to, actually displaying the temperature measurements to the user, the temperature readings or measurements may be used in conjunction with software routines executed by reader 120 to modify or correct the analyte measurements output to the user.

[0062] Further, while FIG. 3 illustrates dual analyte sensors 104, 106 according to numerous embodiments of the present disclosure, the sensor controller 102 may be configured to collect data indicative of multiple physiological measurements, including, but not limited to, glucose levels, lactate levels, ketone levels, or heart rate measurements, to name a few. In some embodiments, for example, the sensor 104 may be a dual analyte sensor configured to sense glucose levels and concentrations of other analytes (e.g., lactate, ketones, etc.). Further details regarding dual analyte sensors are described, for example, in U.S. Patent Application Publication No. 2019 / 0320947, the disclosure of which is incorporated herein by reference for all purposes. In some embodiments, the sensor controller 102 may include multiple individual sensors, each capable of collecting data indicative of any of the above physiological measurements. For example, in some embodiments, the first analyte sensor 104 may be used to sense blood glucose, and the second analyte sensor 106 may be used to sense ketones.

[0063] Embodiments of a system, device and method for using combined blood glucose and ketone data Patients with type 1 diabetes taking SGLT-2i medications are at risk for euglycemic DKA. While individual ketone test strips are available with CGMs, they are impractical for continuous ketone monitoring. With the commercial availability of continuous ketone monitoring approaching, patients will have the ability to detect adverse glucose / ketone conditions in real time. However, how patients interpret these values ​​and determine appropriate action can be complex and unfamiliar to these patients, who may need to contact their HCP for guidance. The present disclosure provides systems, methods, and devices that provide patients with timely guidance on appropriate actions and obtain additional information about their condition at a point in time that the patient remembers. As used herein, "real-time" means without delay other than that necessitated by the technical limitations of the medium used.

[0064] Aspects of the system, method or device may be incorporated into a mobile application-based system that detects an actionable condition, provides guidance to the patient, and provides a means to record important context associated with this condition that may later assist the HCP in advising the patient on how to avoid this condition in the future. The mobile application may be installed in the memory of the reading device and executed by one or more processing units of the reading device.

[0065] The processing and functionality required for this system may be entirely contained in the patient's mobile application, or some or all of it may be contained in the web server that supports the mobile application with processing, communication hub, and reporting functions. In short, the functionality described herein contemplates functionality on the mobile application or on the server, and may be either. References to a mobile application per se include both the application alone and the mobile application in conjunction with a web server.

[0066] The application is configured to retrieve or receive glucose and ketone sensor data acquired by the on-body unit at evenly spaced intervals and provided to the application immediately after each sample acquisition (i.e., "continuous" or "continuously"). The acquired analyte data can be from two separate sensors or from a dual analyte sensor where a single sensor provides data for both analytes. The systems, methods, and devices described herein extend to systems that retrieve intermittent individual glucose and / or ketone measurements, or various combinations of individual and continuous measurements. The technology can also support the use of individual measurements in situations where continuous measurement is not available.

[0067] The mobile application may retrieve or receive and further process analyte sensor data from the on-body unit (OBU) in near real time, such as every minute, 5 minutes, 10 minutes, or 15 minutes, for example, synchronized with the sampling interval of the OBU. The mobile application may process the acquired sensor data in real time (RT) at corresponding intervals. The sampling frequency of the glucose sensor may differ from the sampling frequency of the ketone sensor. In some embodiments, sensor data acquisition and / or real-time processing of the data may occur at different time periods for different times of day. For example, sampling and / or processing frequency may be based on the likelihood of elevated glucose levels to minimize power consumption or communication bandwidth waste. As a further example, real-time processing may be stopped or extended in the early morning hours, since glucose-raising meals typically occur later in the day.

[0068] In embodiments, the mobile application may be configured to detect and respond to glucose + ketone conditions related to managing SGLT-2i use by Type 1 patients or any other use case where high ketones are a problem.

[0069] In exemplary configurations, the systems, methods, and devices may include default, predetermined settings for status thresholds (glucose and ketone) and output reminder notifications, warnings, and recommended actions or treatments in textual, auditory, graphical, or other output formats. The mobile application may include user-configurable settings for thresholds and / or outputs and may further request that the user or HCP confirm the settings. In embodiments, the mobile application may allow adjustment of these settings via a setup menu.

[0070] Suitable default threshold settings are, for example: Moderate ketone threshold = 1.0 mmol / L Upper ketone threshold = 3.0 mmol / L Lower glucose threshold = 70 mg / dL Upper glucose threshold = 180 mg / dL. The table of thresholds may be expanded to any positive integer number of thresholds with explicit text associated with each conditional logic element defined by those thresholds.

[0071] Mobile application settings may include insulin doses associated with different ketone ranges. Settings may be defined by insulin type, insulin units, and / or percent of total daily dose (TDD) and TDD. Alternatively, the relationship between these settings may be defined as an equation with ketone values ​​(and potentially other ketone-based metrics, such as ketone rate of change) as input and insulin dose or percent of TDD as output. The parameters of the equation may be included as part of the mobile application configuration settings. For example, the percent of insulin dose may be a function of ketone values, or the calculated insulin amount may be reduced to a function of ketone values. Alternatively, a different function using ketone ranges rather than a function of ketone values ​​may be used, including using two or more ranges of ketone values ​​as inputs to a function that modifies insulin doses.

[0072] Configurable settings for the mobile application may also include insulin sensitivity parameters that the mobile application can use to determine recommended insulin doses to reduce high glucose levels. Additionally, settings may also include carbohydrate amounts or carbohydrate ratios, defining the amount of insulin to compensate for a specific number of carbohydrates, or conversely, the amount of carbohydrate to compensate for a specific amount of insulin. These parameters, including insulin sensitivity (IS) and carbohydrate ratio (CR), may be defined as parameter ranges, where each element of the range may be associated with a glucose range and / or a ketone range. This may explain, for example, a decrease in the patient's insulin sensitivity in the past day, which indirectly caused a high ketone reading. These associations may be implemented as a function of glucose and / or ketones as inputs and insulin sensitivity and carbohydrate ratio as outputs, and the parameters of the equations may be part of the configuration settings.

[0073] Configuration settings may also include enabling interfacing with remote bolus calculators or dose guidance systems, including automated insulin delivery (AID) systems.

[0074] The mobile application further includes settings that indicate the patient's disease state and medication; these features may be activated if the patient has type 1 diabetes and is using an SGLT-2i. The settings may also enable the mobile application to indicate whether the patient is using an insulin pump or an AID system, or whether the patient is on a carbohydrate-restricted diet. These indications may be used by the mobile application to modify text associated with the condition logic or to modify the condition logic itself.

[0075] Mobile application user interface (UI) logicThe mobile application may be configured to detect in real time when a glucose / ketone condition occurs due to a condition state determined by a predetermined threshold. An example of the condition logic and associated display text is shown below. Upon first recognizing the condition, the mobile application may send a notification to the patient. For example, if it detects that ketones have transitioned from below the high ketone threshold to above the threshold (or alternatively, if the first reading is above the high ketone threshold), the mobile application may notify the UI device: Alert notification: "Your ketones are high!" Suggested notice: "Seek medical attention immediately!" can be output.

[0076] In embodiments, the mobile application UI may include an alert function and an interactive UI object (e.g., a "button") may be provided to the patient to acknowledge the alert and silence the alert. If the alert is ignored, the mobile application may leave the alert activated for a short period of time, e.g., 15 seconds, and then activate it again after a substantially longer period of time (e.g., every 15 minutes) until user input via the UI indicates that the user acknowledges the alert.

[0077] The mobile application may continue to display the reminder notification each time the user accesses the current ketone reading display screen of the UI. Additionally, the mobile application UI may include interactive UI objects (e.g., buttons) to output (e.g., display) recommendations or supplemental information related to the condition for which the reminder notification was output. Alternatively, or in addition, the mobile application may place recommendations or supplemental information on the ketone display screen of the UI. Similar UI actions may be used to indicate all condition states and provide appropriate recommendations or supplemental information predetermined in the mobile application's memory for each condition state. For example, the recommendations or supplemental information may further include recommended insulin and / or carbohydrate amounts to mitigate the above-threshold condition.

[0078] For a further example, if ketones transition from above an upper threshold to below a lower threshold, the mobile application may notify the UI device: Notification: "Ketone levels restored" The mobile application may output a prompt: "Select the discomfort level caused by high ketones from the list below." Additionally, the mobile application may cause the UI device to output a list of discomfort levels to the patient, for example, to select from a list ranging from "no discomfort" and "little discomfort" to "admitted to emergency medical services - moderate symptoms" and "admitted to emergency medical services - severe symptoms." The mobile application may record the patient's selection. Once this information is entered and recorded, the mobile application may stop prompting until it detects the next triggering condition.

[0079] For a further example, after detecting ketones above an upper threshold or below a lower threshold, the mobile application may cause the UI device to output a query, for example, "What caused your high (or possibly low) ketone state? Select all that apply." The mobile application may output selection options through which the user may indicate a response to the query, such as other illness, fasting, vigorous activity, insulin delivery pump failure, or AID insulin delivery cessation. The mobile application may record the patient's selection via the UI. Upon entering and recording this information, the mobile application may pause the prompts until the next condition is entered. If the alert prompt is not answered, the mobile application may re-launch the query at intervals, for example, every hour, until it detects a user's response to the query via the UI.

[0080] In an alternative embodiment, the mobile application may trigger an alert or query only if detected ketones remain above an upper threshold or below a lower threshold for a predetermined period of time, for example, two hours.

[0081] If ketones are moderate (between the upper and lower thresholds) and glucose is above the upper threshold, the mobile application may display a message on the UI device, e.g., Warning notice: "Ketone levels are moderately high and glucose is higher than target." Recommended notice: "If you haven't injected insulin in the last 3 hours, inject insulin to lower your glucose and stay hydrated. Check your ketones and glucose every hour until you are back in the normal ketone range." Prompt: "What caused your moderate ketosis? Select all that apply." may be output. The query response may be handled as previously described herein. As previously described, if the mobile application does not detect a user response to the alert, it may leave the alert activated for a short period of time (e.g., 15 seconds) and then activate it again after a substantially longer period, e.g., every hour, until a response is received or the detected condition changes.

[0082] If ketones transition from above the moderate (but not elevated) threshold to below the lower threshold, the mobile application may display on the UI device: Notification: "Ketone levels restored" The prompt may be output: "Select the level of discomfort caused by moderate ketones from the list below." The response to the query may be treated as previously described herein.

[0083] If ketones are moderate (between the upper and lower thresholds) and glucose is between the lower and upper thresholds, the mobile application will display on the UI device: Alert notification: "Ketone levels are moderately high, glucose is within target" Suggested message: "If you haven't injected insulin in the last 3 hours, eat 15 grams of carbohydrates and inject enough insulin to replace those carbohydrates. Stay hydrated. Check your ketones and glucose every hour until you are back in the normal ketone range." Prompt: "What caused your moderate ketosis? Select all that apply." The mobile application may output a prompt indicating whether the patient is currently receiving a medical alert. The mobile application may record the patient's selections via the UI. Once this information is entered and recorded, the mobile application may stop prompting until the next condition is entered. As previously described, if the mobile application does not detect a user response to the alert, the alert may be activated for a short period of time, e.g., 15 seconds, and then activated again after a substantially longer period of time, e.g., every hour, until a response is received or the detected condition changes.

[0084] If ketones are moderate (between the upper and lower thresholds) and glucose is below the lower threshold, the mobile application will display on the UI device: Caution notice: "Ketone levels are moderately high and glucose is low." Recommendation: "Treat low glucose. Stay hydrated. Check ketones and glucose every 15 minutes until glucose is above 70 mg / dL." Prompt: "What caused your moderate ketosis? Select all that apply." may be output. Responses to the queries may be handled as previously described herein. If the mobile application does not detect a user response to the alert, it may leave the alert activated for a short period of time, e.g., 15 seconds, and then activate it again after a substantially longer period, e.g., every 20 minutes, until a response is received or the detected condition changes.

[0085] Next, an alternative embodiment is shown for when ketones fall from a high ketotic state. If ketones transition from above the upper threshold to below the upper threshold, the mobile application may display on the UI device: Alert notification: "Ketone levels are low" "Time since high ketone levels: X hours, Y minutes" "Time since moderate ketone levels: K hours, L minutes" can be output.

[0086] The mobile application may periodically, e.g., hourly, repeat an appropriate one of the alarm notifications described above until ketones remain below moderate levels for a reset period, e.g., four hours, which may be configurable by the user in the mobile application settings.

[0087] The mobile application may automatically provide any of the ketone alerts or modified versions of the alerts described above to associated users connected via ancillary applications, such as caregiver applications, and may store electronic addresses of one or more linked caregiver applications in the memory of the mobile application.

[0088] Ketone warnings and prompts are not limited to the examples described above. The mobile application may provide other prompts, such as whether the user is ill and, if so, to find out more about the user's illness. This prompt information may be recorded by the mobile application on a connected server and designed to help a physician identify the underlying cause of a high ketosis episode. Alternatively, or additionally, if the mobile application is connected to an insulin delivery or insulin guidance system, the mobile application may automatically determine whether the patient is suffering from some form of insulin resistance, for example, if correction doses are not lowering glucose levels by the expected amount.

[0089] The mobile application may be configured to provide additional notifications when the mobile application communicates with an insulin delivery pump or connected insulin pen. For example, if the mobile application recommends an insulin dose and then, after a suitable waiting period, e.g., 15 minutes, an insulin dose has not been delivered within the last 3 hours and 15 minutes and the previous test substance condition is still detected, then the software may generate and resend a notification, perhaps additionally indicating that this is a repeated notification. This notification may be repeated periodically, e.g., every 15 minutes, until the above conditions are met.

[0090] The default home screen generated by the mobile application for the UI may display or otherwise output glucose data, such as glucose values, rate of change, and glucose plots, and report analyte levels detected by the OBU. The home screen may also show ketone ranges detected by the OBU. In some embodiments, the home screen may omit any display of ketone analyte levels if ketones are within the normal range or near baseline. If ketones detected by the OBU are elevated, such as in the moderate or high range (or perhaps well above baseline), the mobile application may cause the screen to display current ketone values ​​and, optionally, a rate of change calculated using various time periods, e.g., 15 minutes of data, or 30 or 60 minutes of data. Additionally, the mobile application may cause the UI home screen to automatically replace the glucose time plot with a ketone plot. The ketone plot may use a different time range than the glucose plot, e.g., 24 hours instead of 8 hours. Alternatively, glucose and ketone traces may be placed together on one screen, for example, with the glucose axis on the left and the ketone axis on the right, and the time scale may be switched to 24 hours. The screen may have UI means to switch the information focus between glucose and ketone. If ketones are in the moderate or high range, the mobile application may change the default home screen from one focused on glucose to one focused on ketones. The home screen may indicate the ketone range and also indicate whether low glucose is present.

[0091] The logic for controlling the UI interface described so far can be implemented as a state machine in the executable memory of the mobile application.

[0092] The mobile application may further include treatment guidance, including insulin bolus calculations. For patients using a bolus calculator or dose guidance system, the mobile application may provide specific recommendations for dosage and carbohydrate intake via its UI, for example, using alerts as previously described. The bolus calculator or dose guidance system (referred to herein as the "calculator" for simplicity) may be co-located on the mobile application, on a web server supporting the mobile application, or may be located remotely from the mobile application. In the latter case, the remote calculator may provide an application program interface (API) that allows the mobile application to retrieve key parameters from the calculator, such as insulin sensitivity (IS) and carbohydrate ratio (CR). The mobile application may then calculate a recommended insulin dose and carbohydrate intake for the patient based on the blood glucose and ketones detected by the OBU, as well as other factors.

[0093] Table 400 in FIG. 4 illustrates one embodiment of treatment guidance parameters as a function of time-correlated glucose and ketone values ​​from an OBU. Columns 410 each indicate a different measured glucose state: low, normal, or high. Rows 420 each indicate a different measured ketone state: moderate or high. Data at the intersections of the rows and columns each indicate parameters for a treatment advice message and map the condition logic used to form the different advice. Other data structures can also be used to map the condition logic. The mobile application can use this table or other suitable mapping of condition logic to configure the content of the advice message output by the reader or other UI device.

[0094] Instead, the remote calculator may perform these calculations and return insulin dosage and / or carbohydrate intake recommendations to the mobile application. The remote calculator operates with a defined API through which the mobile application requests these outputs, and may also provide glucose and ketone levels (and potentially other derived metrics or time-series level data) and manage other appropriate settings, such as glucose and ketone thresholds, as inputs.

[0095] The condition logic and corresponding user interface described herein can be incorporated into the user interface and logic for a) an insulin pump based on an AID system or b) an insulin decision support system (MDI or pump). For both, the described condition logic executes concurrently with the AID or decision support function on the mobile application, and notifications can be issued asynchronously to the AID or decision support function, or they can be buffered and synchronized for display based on priority rules. Because glucose and ketone condition states can transition at different times, for example, the mobile application may provide a low glucose alert at one time, and several minutes later, the mobile application may provide a moderate ketone and low glucose alert. The mobile application software can be designed to modify the alert actions provided. In the described example, the low alert action after the initial notification can be modified or suppressed in favor of the action after the moderate ketone and low glucose alert notification.

[0096] In other scenarios, the glucose and ketone review logic may provide a button that displays appropriate mealtime dosage guidance along with other recommendations. Thus, if the recommendation for a patient is, for example, to eat carbohydrates and supplement with insulin, and the current time is around lunchtime, the mobile application may provide a button labeled "Lunch" that, when pressed, displays dosage guidance for lunch.

[0097] When glucose and ketone condition logic is integrated with an AID system, the condition logic can prevent the AID system from completely stopping insulin delivery when glucose is low or predicted to become low.

[0098] Dosage guidance determined by the bolus calculator can be sent via API to the patient's insulin pump or AID system. The mobile application UI can provide the patient with a UI method to initiate their insulin dose and confirm their intent to consume the appropriate amount of carbohydrates, if necessary.

[0099] Conventional insulin bolus calculators estimate the amount of insulin needed to either a) lower a patient's glucose to a desired level and / or b) offset an expected meal. These calculators are generally based on a mathematical model of the patient's glycemic response to insulin and carbohydrates, taking into account current glucose level, desired glucose level, estimated insulin onboard, and estimated expected carbohydrate intake.

[0100] Traditional bolus calculators assume that a patient's glycemic response is constant or varies throughout the day. Glycemic response is typically characterized for a patient by the factors of the individual patient's "basal insulin," "insulin sensitivity," and "carbohydrate ratio." Basal insulin is the amount of long-acting insulin administered during the day (or, for insulin pump users, the amount of rapid-acting insulin delivered continuously). Insulin sensitivity (IS) is an estimate of the insulin required to lower glucose by one unit. Carbohydrate ratio (CR) is the amount of insulin required to offset one unit of carbohydrate intake. Thus, Basis = Constant (units per day) IS = constant (units per mg / dL) CR = constant (per unit CHO).

[0101] It is well known that this simple glycemic model is not necessarily accurate, and conditions such as activity level and alcohol intake can cause a patient's actual physiology to deviate from this simple model. Actual glycemic responses are more complex than can be described by these three factors. However, more complex glycemic response models are poorly understood and confusing to patients. A glycemic response model using these three factors is used to represent the current standard of care for patients using insulin.

[0102] The mobile application may include new enhancements to provide an insulin calculator. Specifically, the glycemic response model that defines how the insulin calculator operates may be enhanced with one or more additional analyte measurements or additional information. Other possible analyte measurements that may help make the glycemic response model more accurate may include current ketone levels and current trends in ketone levels, current lactate levels, the lipid content of the user's next expected meal, the user's expected activity after that meal, and the user's activity level before the meal and for the period for which a bolus is calculated.

[0103] Glycemic response is affected by meal components and activity level. The mobile application may include enhancements to the bolus calculator based on additional analyte measurements. For illustrative purposes, two possible bolus calculators are described, one using ketone measurements and the other using lactate measurements.

[0104] With regard to glycemic response, continued elevated ketones may be an indicator of decreased insulin sensitivity, an increased carbohydrate ratio, and the need for more basal insulin. Consequently, when ketones are higher than normal, more insulin is needed to achieve the same effect on glucose. In one embodiment, the model used for the mobile application's bolus calculator may be modified to account for this effect by replacing these constant factors with a function based on ketone levels. In its simplest form, the function may be based on the current ketone reading.

[0105] Basal = constant x f (ketones) (units per day) IS = constant x f (ketones) (units per mg / dL) CR = constant × f (ketone) (per unit CHO) An example of a simple stepwise linear model is: If ketones <1.0 mmol / L, IS = 4 mg / dL / unit (or, in common notation, 1:4) If ketones ≥ 1.0 and ketones < 3.0 mmol / L, IS = 4 + {(ketone-1) / 2} × 4 mmol / L, otherwise, ketones = 8 mmol / L.

[0106] More advanced bolus calculators may use functions based on more than one ketone measurement. As described herein, a continuous sensor may be used to measure ketones at frequent intervals (e.g., every 15 minutes). The advantage of continuous data is that continuous ketone data allows for more accurate glycemic response models that take into account the dynamic effect of ketones on glycemic response.

[0107] Generally, other models incorporating ketone measurements may be contemplated. For example, rather than modeling ketones as parameters in the model, ketones and higher ketone derivatives, along with glucose and higher glucose derivatives, may be modeled as state variables.

[0108] Alternatively, or in addition, the mobile application can be programmed to perform more advanced bolus calculations using model-based fitted parameters and further trained with data from a similar patient population. The mobile application may start by default with a model trained using a population and, over time, apply an adapted model to further train the model using patient data. For example, the mobile application may track previous insulin doses paired with data derived from glucose measurements (e.g., glucose value at a specific time point versus insulin dose, rate of change of glucose value at a specific time point versus insulin dose, area under the curve where glucose is higher than a specific threshold for a specific time versus insulin dose, etc.) and data derived from ketone measurements. The mobile application may incorporate a predetermined model calculated to estimate the effect of pre-insulin data on post-insulin data. Over time, the mobile application, or another heuristic application, may update key parameters of the model using sequential estimation, regression parameter estimation, neural networks, or other heuristic methods. Instead, pre-insulin dose data may be used to construct features that predict certain attributes associated with the user's historical data after insulin administration for each past insulin administration event. The model development algorithm may provide the historical data to one or more machine learning frameworks to develop estimators that can update administration parameters by considering both glucose- and ketone-derived data until each insulin administration decision is made moving forward. The resulting bolus calculator has different sets of formulas for different conditions determined by glucose- and / or ketone-derived data, and the machine learning framework, e.g., random forest, can provide the condition thresholds and formulas that determine the insulin dose.

[0109] An OBE communicating with a mobile application can measure lactate at frequent intervals using a continuous sensor. High lactate is associated with high levels of activity and can be useful as an automated measure of activity. High lactate tends to lower glucose more than normal in response to insulin. Similar to what was described for ketones, lactate measurements can be incorporated into bolus calculator models.

[0110] The mobile application may incorporate modeling for an AID system in which insulin is automatically delivered to the patient. Here, the AID model may include ketone and lactate measurements as inputs. Alternatively, the AID system may include multiple models, and the ketone and lactate measurements may determine which model is used. For example, one model may use lower insulin sensitivity than other models; if ketones are above a certain threshold, then the system may switch to using a model with lower insulin sensitivity.

[0111] The mobile application may include code for using the ketone measurements to detect when a user / patient is ill. If the mobile application detects elevated ketones, it may prompt the user to indicate if they are ill. If the patient indicates they are ill, the mobile application may change parameters in the bolus calculation model or switch to a different model that is more appropriate when the patient is ill.

[0112] Generally, the mobile application may use a bolus calculator based on a model that takes into account any number of additional analyte measurements simultaneously to provide a good representation of the patient's glycemic response.

[0113] The mobile application can be configured to provide guidance to an insulin pump wearer or an AID user. If the mobile application is configured for a pump wearer, recommendations output via the UI can include instructions to check the pump for proper operation to ensure insulin is being delivered. For AID use, the AID system can stop insulin delivery, and the recommendation is to switch the AID system to manual and resume insulin delivery. The mobile application can electronically connect to the AID system and automatically resume insulin delivery while recommending that the patient consume carbohydrates as part of their treatment.

[0114] The mobile application may be configured to provide guidance to individuals on a carbohydrate-restricted diet. For these users / patients, a physician may need to address this by increasing the mobile application's moderate ketone level threshold configuration parameter. Alternatively, the mobile application may automatically adjust this level based on the configuration if a carbohydrate-restricted diet option is selected. The mobile application may periodically process data to determine whether the patient is maintaining moderately high ketones without developing hyperketones and may automatically set a moderate threshold or recommend how to adjust this threshold in a report output to the HCP. Additional information periodically obtained from the patient to assess beta cell function, such as the patient's C-peptide level, may be used to determine the relative risk of ketoacidosis versus dietary ketosis. For example, individuals with reduced beta cell function may be at higher relative risk of ketoacidosis and therefore should select an elevated ketone threshold level.

[0115] The mobile application may be configured to provide guidance for SGLT-2i users to patients taking SGLT-2i or similarly acting agents, particularly to type 1 patients taking SGLT-2i. In this configuration, the mobile application may provide recommendations for moderate or high ketones, including instructions to discontinue SGLT-2i use until directed to resume by an HCP.

[0116] The mobile application may be configured to provide reports to the patient and / or HCP. The mobile application may report ketones using a daily trajectory, similar to the daily glucose trajectory commonly reported today. The mobile application may include ketone trajectories in the same report as glucose trajectories. In embodiments, these trajectories may be annotated using information gathered from prompts displayed by the mobile application, except that a symbol representing the cause of a high ketone episode (or a textual representation of that cause) may be positioned vertically to coincide with the time it was recorded or the time when ketones began to rise. For example, if the cause is indicated as being due to a pump failure, then an icon related to the pump failure may be positioned at the location where the associated ketone increase began. Similarly, a discomfort level information log may annotate the trajectory and be positioned at the beginning, end, or middle of the associated high ketone event.

[0117] Instead, the mobile application may annotate the glucose time trajectory plot with colored bands or other such ketone range indicators, for example, green bands may indicate normal ketone ranges, yellow bands may indicate moderate ketone ranges, and red bands may indicate high ketone ranges.

[0118] The mobile application may report other metrics to provide a medical perspective on the patient's condition, such as the frequency (e.g., number per year) of high ketone events, moderate ketone events, high ketone events with glucose in the normal target range (potentially total glucose and ketone ranges), causes of high ketones, and ketone baseline levels. For high ketone events over the past year, the mobile application may collect and report the frequency and distribution of reasons for discomfort levels reported by the patient. Additionally or alternatively, the mobile application may report the relationship between moderate and high ketone levels, e.g., the frequency of high ketone events occurring when there are moderate ketone events. The mobile application may provide a typical day plot of ketones, showing whether different times of day are prone to high ketones. A typical week plot may serve the same purpose, identifying potentially higher-risk days of the week and helping to identify factors contributing to high ketone episodes for the patient. The report may specifically indicate that SGLT-2i use or a carbohydrate-restricted diet is not recommended for a particular patient based on these metrics, for example, whether the patient has experienced two or more high ketone events in the past year.

[0119] The mobile application may collect, process, and report discomfort levels reported by the patient and further correlate the discomfort levels with treatment actions to indicate the benefits of the treatment. For example, the mobile application may calculate and output metrics configured to indicate whether a high ketotic episode was prevented or whether a high ketotic episode occurred with a low discomfort level if the recommended treatment was followed. For example, the report may provide the frequency of high ketotic events when treatment was followed compared to the frequency when treatment was delayed or not followed, and may further provide a distribution of discomfort levels when high ketotic events occurred, compared to the distribution of discomfort levels when treatment recommendations were followed compared to the distribution of discomfort levels when recommendations were not followed or followed late.

[0120] The mobile application may feed output information from such ketone and treatment analysis back into the ketone threshold determination. For example, the analysis may show that for a particular patient, ketones up to a level of 1.4 do not transition to high ketones, but some ketones above this value do transition to high ketones, which may set a lower ketone threshold at 1.4. This process may be performed periodically by the mobile application and reported to the HCP (for manual adjustment of the threshold) or adjusted automatically by the mobile application.

[0121] The mobile application may include in the output report a time trajectory of each moderate and high ketone event, annotated and aligned with other information, such as a food log, insulin delivery log or record, glucose trajectory, and other possible data, to indicate the effectiveness of treatments to mitigate high ketones. The mobile application may plot continuous ketone levels using a typical daily plot and individual ketone trajectories or percentile trajectories, e.g., the 5th, 25th, 50th, 75th, and 95th percentiles calculated for each hour of the day. The mobile application may generate, chronologically align, and overlay the plots and enter key events into the ketone trajectory, such as the time when ketones began to rise or when ketones crossed a certain threshold.

[0122] The mobile application can be configured to report data that the HCP can use to diagnose the type of diabetes based on markers measuring C-peptide (beta cell function). The mobile application can perform periodic advanced analyses. For example, the mobile application can perform a baseline ketone level assessment for a patient by calculating median ketone levels over one or more time periods, assuming the patient is at baseline levels most of the time. Other known techniques for determining baseline values ​​can also be used.

[0123] The mobile application may use a predictive model based on data inputs and result outputs as described herein to estimate the likelihood of a high ketone event and provide it to the patient. The mobile application may provide this on-demand, perhaps as part of the ketone reading screen, or as a notification when it detects a condition such as a 50% change in a high ketone event. The predictive model used by the mobile application may be developed using standard modeling techniques using data from a patient population that retrieves inputs and outputs as described. The model may be tailored to an individual user / patient given sufficient input / output data retrieved from that patient.

[0124] For example, the mobile application may use a predictive model derived from a patient population when the patient begins wearing the sensor. Over time, if there are parameters that change the predictive model to a known range of variation from the population model, the mobile application, or another modeling application in communication with the mobile application, may estimate and update those parameters over time. With the updated parameters, the predictive model may better estimate the patient's ketone readings in the near future. Methods using standard regression techniques, model-based parameter fitting, supervised machine learning, or unsupervised machine learning may be used. Alternatively, if the predictive model is intended to provide a small, quantized set of value ranges, a classification-based approach may be used.

[0125] The mobile application may incorporate rate of change ("ROC") into the condition logic. The definition of the condition range may further depend on the ketone (or glucose) rate of change (ROC). For example, a moderate range may be defined by ketone > 1 mmol / L, or (ketone > 0.5 mmol / L and ketone ROC > 0.3 mmol / L / hour), where ketone ROC may be estimated in various ways, including simply determining the slope of the most recent 15-minute window of ketone data. The condition logic may also incorporate hysteresis. That is, if the condition is determined to be moderate ketone based on ROC logic, the condition logic may require (ketone < 1.0 mmol / L and ketone ROC < 0 mmol / L / hour) to return to the normal ketone range. This is to prevent erratic state changes due to noisy rate of change estimates.

[0126] If other sensor data, such as activity data, heart rate, or other analyte sensor data that may help predict the occurrence of elevated ketones, is collected by the mobile application, a probabilistic model can be created between these data and the occurrence of elevated ketone levels, and the model can be used to predict when elevated ketones are likely to occur and, for example, send an appropriate warning to the patient, as described further herein.

[0127] In other aspects, the mobile application may automatically titrate the SGLT-2i dosage for the patient. The mobile application may determine the titration based on ketone levels and other analyte levels, such as glucose, or other measurements, such as delivered insulin or carbohydrate intake. In one embodiment, the mobile application may process glucose and ketone levels periodically, such as monthly, to determine whether the SGLT-2i dosage should be increased, decreased, or maintained. The mobile application may output any changes or recommendations to the patient via the mobile application UI. Optionally, the mobile application may send a recommendation to the HCP for permission before outputting it to the patient. Alternatively, the reporting software may provide UI instructions to initiate a report that starts the periodic processing and output the results in the report.

[0128] In embodiments, the mobile application may retrieve glucose and ketone data for a recent period (e.g., two weeks). The mobile application may calculate glucose variability metrics, such as the standard deviation of all glucose data, or glucose time area metrics associated with daytime only or the five hours after each meal. The mobile application may also calculate median ketone levels and establish baseline ketone levels by excluding moderate or high ketone data. For example, the mobile application may output a recommendation to increase SGLT-2i dosage if: a) glucose variability is greater than a predetermined threshold; b) baseline ketones are less than a predetermined threshold; c) no high ketone values ​​have been recorded in the past year; and d) no moderate ketone values ​​associated with concurrent glucose values ​​less than a predetermined threshold have been recorded in the past year. For further example, the mobile application may output a recommendation to decrease SGLT-2i dosage if: a) ketone baseline values ​​exceed a predetermined threshold; or b) high ketone values ​​have been recorded in the past year. Otherwise, no change is recommended. The mobile application typically allows for setting a default dosage equal to the amount prescribed by the physician, provides UI means for configuring these increases, or both. Titration logic criteria may also be configured.

[0129] The mobile application may use data from the ketone sensor to detect OBU glucose sensor failure or vice versa. For systems in which the mobile application is connected to an insulin pump or insulin pen, insulin delivery data may also be useful. High ketones but low or normal glucose levels may indicate euglycemic DKA, or the glucose sensor may be reading falsely low and the patient's glucose level may actually be high. Thus, if any of the above conditions are detected, the mobile application may output recommendations that include instructions to confirm the glucose sensor reading with a blood glucose test strip or other redundant glucose measurement means. If insulin delivery data is available and a recent insulin delivery event has occurred, then this may indicate that the sensor is functioning properly. In embodiments, the mobile application may use a glucose prediction model based on insulin delivery data and / or insulin dosage guidance information, such as information about whether the patient has requested guidance on prandial insulin doses or high glucose correction doses. If the measured glucose differs substantially from the predicted glucose, this may indicate a glucose sensor failure. Similarly, high ketones and low / normal glucose may indicate a ketone sensor failure, and recommendations by the mobile application may include instructions to test ketones redundantly with a blood ketone test strip.

[0130] Alternatively, if the glucose reading is high and the ketone reading is low, this may also indicate a sensor error. A recommendation by the mobile application may be to perform a redundant measurement to confirm sensor functionality. If the mobile application detects that insulin has been delivered recently, this may indicate a glucose sensor failure; otherwise, it may indicate a ketone sensor failure.

[0131] Glucose and ketone sensors may be used to detect pump insulin delivery problems, such as a clogged infusion set, or pen insulin delivery problems. If ketones are high, glucose levels are high, and insulin delivery is recorded, this may indicate a malfunction in insulin delivery, where some or all of the insulin was not delivered to the patient. When the mobile application detects these conditions, it may output recommendations and instructions to check the functionality of the insulin delivery system.

[0132] Another example of an indication of a clogged pump may be when the system detects that ketones are rising faster than glucose. For example, the mobile application may detect that the ketone rate of change has exceeded a predetermined threshold, and then output recommendations and instructions to check the functionality of the insulin delivery system if glucose exceeds a predetermined rate of change threshold.

[0133] High ketones occurring simultaneously with low glucose also indicates abnormal sensor degradation, which can occur when initially wearing the sensor, later in the sensor's life, or if the patient applies pressure to the sensor while lying down while wearing the sensor. In an AID system (or similarly with a manual insulin injection system), if the sensor reads low, insulin delivery may then be low or stopped. Elevated glucose levels may go undetected, while elevated ketone levels may be detected. When the mobile application detects these conditions, it may output a high ketone warning and prompt the patient to check their glucose levels with a blood glucose test strip.

[0134] Detection of these abnormal events and sensor errors can be done retrospectively: if elevated ketone levels are detected concurrently with low insulin delivery data, the report generation process can be instructed to exclude from the report calculations glucose data from the time prior to the time the condition was no longer present (e.g., four hours prior).

[0135] In other embodiments, the mobile application may incorporate a pump clog detection subsystem, for example, a method for measuring tubing pressure during insulin delivery. If the pressure exceeds a threshold, then the mobile application may output a notification via its UI to the patient of a possible clog. The mobile application may augment this system with a clog detection method as previously described using glucose and ketone measurements. If glucose and ketone status indicate a possible clog, the mobile application may adjust the parameters of the clog detection system, for example, by lowering the pressure threshold used to detect a clog. The parameters and outputs of both the glucose / ketone clog detector and other (e.g., pressure) clog detectors may be incorporated in any number of ways to provide a reliable clog detection method and output.

[0136] Methods for using BG and ketone data in combination We now describe exemplary embodiments of dual analyte sensing methods that use glucose history from a glucose sensor in combination with data from a ketone sensor to control a user interface device, a healthcare provider interface device, or a dosage management device to improve control of a patient's glucose levels. Prior to this, those skilled in the art will appreciate that any one or more of the steps of the exemplary methods described herein may be stored as software instructions in non-transitory memory of a sensor control device, a reader device, a remote computer, or a trusted computer system, such as those described with respect to FIG. 1 . The stored instructions, when executed, may cause the processing circuitry of the associated device or computing system to perform any one or more of the steps of the exemplary methods described herein. Furthermore, those skilled in the art will appreciate that in many of the embodiments, any one or more of the steps of the methods described herein may be performed using real-time or near-real-time sensor data. In other embodiments, any one or more of the steps of the methods may be performed retrospectively using stored sensor data, including sensor data from previous sensor wears by the same user. In some embodiments, the steps of the methods described herein may be performed periodically according to a predetermined schedule and / or in a batch retrospective process.

[0137] Further, those skilled in the art will appreciate that instructions may be stored in non-transitory memory on a single device (e.g., sensor controller or reader) or, alternatively, distributed across multiple discrete devices at geographically dispersed locations (e.g., a cloud platform). For example, in some embodiments, collection of data indicative of analyte levels (e.g., glucose, ketone) may occur on the sensor controller, while calculation of analyte metrics (e.g., glucose derivatives, ketone derivatives) and comparison of the analyte metrics to predetermined thresholds may occur on the reader, a remote computing system, or a trusted computing system. In some embodiments, collection of analyte data and comparison to predetermined thresholds may occur solely on the sensor controller. Similarly, those skilled in the art will appreciate that computing devices in the embodiments disclosed herein, such as those shown in FIG. 1, are intended to encompass both physical and virtual devices (or “virtual machines”).

[0138] 5 is a flow diagram of an exemplary embodiment of a method 500 for controlling analyte monitoring in a patient. At step 510, first data indicative of a glucose level is collected by an analyte sensor such as those described with respect to FIGS. 1 and 3. Additionally, at step 510, second data indicative of a ketone level is also collected by a ketone sensing unit. According to some embodiments, step 510 is performed by a sensor control unit (SCU, also referred to as an on-body unit) that includes an analyte sensor configured to be inserted into a user's (i.e., patient's) body at an insertion site, which may include a first sensing unit configured to sense a glucose level in a bodily fluid and a second sensing unit configured to sense a ketone level in the bodily fluid at the same insertion site. In other embodiments, step 510 may be performed by a sensor controller including a first analyte sensor and a second analyte sensor, where the first analyte sensor is configured to sense a glucose level in the bodily fluid and the second analyte sensor is configured to sense a ketone level in the bodily fluid, and the first and second analyte sensors may be configured to sense analyte levels at the same local insertion site.

[0139] In step 520, at least one processing unit of the SCU / OBU, a reader communicatively coupled to the SCU, a server communicatively coupled to the SCU and / or reader, or any useful combination described above, makes at least one output decision selected from the outputs shown in boxes 530-580. These separate decisions 530-580 may each be as described in more detail herein. The at least one processing unit may make any one or more of decisions 530-580 in any useful order, including but not limited to the order shown in FIG. 5.

[0140] In step 530, the at least one processing unit determines whether a condition has occurred that triggers the output of an alert. The alert may relate to the time-correlated glucose data, the ketone data, or both. Any of the conditions and alerts described above, as well as similar conditions and alerts, may be used.

[0141] In step 540, at least one processing unit determines the content of an advisory message for output to the user interface of the reading device or other device. The advisory messages and user questions ("queries") described herein, as well as any one of similar messages or questions, may be determined. The disclosure thus far provides numerous non-limiting examples of conditional logic for determining an advisory message or question. Method 500 is not limited to the specific examples described. For example, the state parameters and the content of the message or question may be varied and further developed to improve effectiveness and ease of use.

[0142] In step 550, the at least one processing unit determines a correction to the analyte state, e.g., blood glucose or ketone level estimate, for the current or one or more past time points, or a predicted future analyte level. The at least one processing unit may correct the analyte state estimate using any one or more correction algorithms, such as those described herein.

[0143] Similarly, at least one processor may determine the likelihood that the sensor controller or insulin delivery device (IDD) is malfunctioning based at least in part on the time-correlated glucose and ketone data in step 560. Exemplary logic for such a determination has been described in detail above.

[0144] In step 570, at least one processing unit calculates a medication dosage, e.g., an insulin bolus dosage, based at least in part on the time-correlated glucose and ketone data. Exemplary dosage calculation algorithms based on glucose and ketone data are described above.

[0145] In step 580, the at least one processing unit determines the content of the analysis report based, at least in part, on the time-correlated glucose and ketone data.

[0146] In step 590, the at least one processing unit outputs the output determined in step 520, including any one or more of decisions 530-580. Outputting may include formatting the digital data for output via a display screen driven by a graphical user interface or for audio output, for example. Thus, the systems and devices described herein may perform the method 500 for controlling insulin administration and controlling a user interface device to guide a user toward better insulin control.

[0147] For each and every embodiment of the methods disclosed herein, systems and devices capable of performing each embodiment are also encompassed within the scope of the present disclosure. For example, sensor control device embodiments are disclosed, which may include one or more analyte sensors, analyte monitoring circuitry (e.g., analog circuitry), memory (e.g., for storing instructions), power supplies, communication circuitry, transmitters, receivers, clocks, counters, timers, temperature sensors, and a processor (e.g., for executing instructions) that perform or facilitate any and all method steps. These sensor control device embodiments may be used or be capable of being used to implement any and all methods described herein. Similarly, reader device embodiments are disclosed, which may include one or more memory (e.g., for storing instructions), power supplies, communication circuitry, transmitters, receivers, clocks, counters, timers, and a processor (e.g., for executing instructions) that perform or facilitate any and all method steps. These reader device embodiments may be used or capable of being used to implement the steps performed by the reader device from any and all of the methods described herein. Computer device and server embodiments are disclosed, which may include one or more memories (e.g., for storing instructions), power supplies, communications circuits, transmitters, receivers, clocks, counters, timers, and processors (e.g., for executing instructions) that perform or facilitate the execution of any and all method steps. These computer device and server embodiments may be used or capable of being used to implement the steps performed by the computer device and server from any and all methods described herein.

[0148] Computer program instructions for performing operations according to the subject matter described herein may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, JavaScript, Smalltalk, C++, C#, Transact-SQL, XML, PHP, etc., and conventional procedural programming languages ​​such as the "C" programming language or similar programming languages. The program instructions may execute entirely on the user's computing device, partially on the user's computing device as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In the latter scenario, the remote computing device may be connected to the user's computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., through the Internet using an Internet Service Provider).

[0149] It should be noted that all features, elements, components, functions, and steps described with respect to any embodiment provided herein are intended to be freely combinable and interchangeable with any other embodiment. When a feature, element, component, function, or step is described with respect to only one embodiment, it should be understood that the feature, element, component, function, or step can be used with all other embodiments unless expressly stated otherwise. Therefore, this paragraph serves as a precursor and supporting description for introducing claims that combine features, elements, components, functions, and steps from different embodiments or replace features, elements, components, functions, and steps from one embodiment with those from other embodiments, even if the preceding description does not explicitly state that such combinations and substitutions are possible in a particular case. It is expressly stated that explicitly listing all possible combinations and substitutions would be an excessive burden, especially given that those skilled in the art would readily recognize that such combinations and substitutions are possible. Preferred features are set forth in the dependent claims, and they can be implemented in combination with each aspect recited in the independent claims. Apparatuses containing means for carrying out each method are also provided.

[0150] To the extent that an embodiment disclosed herein includes or operates with memory, storage, and / or computer-readable medium, then that memory, storage, and / or computer-readable medium is non-transitory. Thus, to the extent that memory, storage, and / or computer-readable medium is covered by one or more claims, then the memory, storage, and / or computer-readable medium is only non-transitory.

[0151] As used in this specification and the appended claims, indefinite and definite articles indicating the singular include the plural as well, unless the context clearly indicates otherwise.

[0152] While the embodiments are susceptible to various modifications and alternative forms, specific examples have been shown in the drawings and are described in detail herein. However, it should be understood that these embodiments are not limited to the particular forms disclosed; rather, these embodiments are intended to cover all modifications, equivalents, and alternatives falling within the spirit of the disclosure. Furthermore, any feature, function, step, or element of the embodiments may be recited or added to the claims, and negative limitations may be added to define the scope of the claims by any feature, function, step, or element not included in the scope of the claims.

[0153] Exemplary embodiments are listed below: 1. In a test substance monitoring system, a sensor control device including an analyte sensor having at least a portion configured to be inserted into a body of a user, a first processing circuit, and a first non-transitory memory, the sensor control device configured to collect first time-correlated data indicative of a glucose level and second time-correlated data indicative of a ketone level; a reader including a second processing circuit and a second non-transitory memory; Including, At least one of the first or second non-transitory memories includes instructions that, when executed, cause at least one of the first or second processing circuit to: determining, based at least in part on the first and second time-correlated data, at least one of a warning condition for one or both of the first and second time-correlated data, an advisory message for output by the reader, a correction of the analyte status estimate, a sensor control device failure, an insulin delivery device failure, a drug dosage calculation, or an analytical report based on the first and second time-correlated data; outputting, by a reading device, an indication of the result of the determining process; A test substance monitoring system that performs the above. 2. The analyte monitoring system of claim 1, wherein the instructions for determining an alert condition include instructions for setting at least one of an analyte level threshold for an alert condition or a time interval for issuing an alert. 3. The test substance monitoring system of claim 1 or 2, wherein the instructions for determining the advice message include instructions for outputting a query by a reading device. 4. The test substance monitoring system of claim 3, wherein the instructions to output a query include instructions to output at least one question about the patient's comfort level based on second time-correlated data indicating a transition from a value higher than the upper threshold to a lower threshold. 5. The test substance monitoring system of claim 3 or 4, wherein the instructions to output a query include instructions to output at least one question about past patient behavior. 6. An input device operatively coupled to at least one of the reader or the sensor control device configured to receive information defining an insulin dose by a patient wearing the sensor control device; Further including, 6. The analyte monitoring system of any one of claims 1 to 5, wherein the determining instructions include instructions to correct the estimate of the patient's plasma insulin status. 7. An input device operably coupled to at least one of the reader or sensor control device configured to receive a ketone test result; Further including, 7. The test substance monitoring system of any one of paragraphs 1 to 6, wherein the instructions further cause an insulin dosage calculation algorithm to be automatically executed in response to receiving the ketone test results. 8. A test substance monitoring system described in any one of paragraphs 1 to 7, wherein the determining instruction includes an instruction to apply conditional logic defined in the data structure to determine the content of the advice message. 9. A test substance monitoring system according to any one of paragraphs 1 to 8, wherein the drug dosage calculation includes insulin dosage calculation. 10. The test substance monitoring system of claim 9, wherein the determining instructions include instructions for calculating an insulin dose based on current ketone levels. 11. The test substance monitoring system of claim 9 or 10, wherein the determining instructions include insulin dose calculations, including mealtime bolus doses. 12. A test substance monitoring system according to any one of paragraphs 9 to 11, wherein the determining instructions include instructions for calculating an insulin dosage using an adaptive model trained using data from a patient population. 13. A test substance monitoring system as described in any one of paragraphs 9 to 12, wherein the determining instructions include instructions for calculating an insulin dosage further based on sensor data indicating a lactate measurement value. 14. A test substance monitoring system as described in any one of paragraphs 1 to 13, wherein the instructions for determining the advice message include instructions for making a decision further based on whether the patient is taking an SGLT-2i, and for configuring an advice message to discontinue use of the SGLT-2i if ketones are above a threshold. 15. The analyte monitoring system of any one of paragraphs 1 to 14, wherein the instructions are stored in a second non-transitory memory. 16. The analyte monitoring system of any one of paragraphs 1 to 14, wherein the instructions are stored in a first non-transitory memory. 17. The test substance monitoring system of any one of paragraphs 1 to 16, wherein the sensor control device further includes wireless communication circuitry configured to transmit the first and second data to the reader device. 18. The analyte monitoring system of paragraph 16, wherein the wireless communication circuitry is configured to transmit the first and second data via a Bluetooth protocol. 19. A third analyte sensor configured to sense lactate levels in a bodily fluid; 19. The test substance monitoring system of any one of paragraphs 1 to 18, further comprising: 20. A drug delivery device, 20. The test substance monitoring system of any one of paragraphs 1 to 19, further comprising: 21. The analyte monitoring system of paragraph 19, wherein the drug delivery device includes an insulin pump. 22. A computer-based method for monitoring and controlling a test substance in a patient, comprising: collecting, with a sensor control device including an analyte sensor at least a portion of which is inserted into the user's body, first time-correlated data indicative of glucose levels and second time-correlated data indicative of ketone levels; determining, based at least in part on the first and second time-correlated data, at least one of a warning condition for one or both of the first and second time-correlated data, an advisory message for output by the reader, a correction of the analyte status estimate, a sensor control device failure, an insulin delivery device failure, a drug dosage calculation, or an analytical report based on the first and second time-correlated data; outputting the result of the determination by a user interface device; A method comprising: 23. The method of paragraph 22, wherein the determining step further comprises setting at least one of an analyte level threshold for an alert condition or a time interval for issuing an alert. 24. The method of claim 22 or 23, wherein determining the advice message further comprises determining a query for output by a user interface device. 25. The method of claim 24, wherein determining the query includes determining at least one question about the patient's comfort level based on second time-correlated data indicating a transition from a value above the upper threshold to a lower threshold. 26. The method of claim 24 or 25, wherein determining the query includes determining at least one question about past patient behavior. 27. Receiving information defining an insulin dose by a patient wearing the sensor-controlled device; Further including, wherein the determining step comprises correcting an estimate of the patient's plasma insulin status. 27. The method of any one of paragraphs 22 to 26. 28. Automatically executing an insulin dose calculation algorithm in response to receiving a ketone test result; 28. The method of any one of paragraphs 22 to 27, further comprising: 29. The method of any one of clauses 22 to 28, wherein the determining step further includes applying conditional logic defined in the data structure to determine the content of the advice message. 30. The method of any one of paragraphs 22 to 29, wherein the drug dosage calculation includes insulin dosage calculation. 31. The method of paragraph 30, wherein the determining step further comprises the step of performing an insulin dosage calculation based on current ketone levels. 32. The method of claim 30 or 31, wherein the insulin dose calculation includes a mealtime bolus dose calculation. 33. The method of any one of paragraphs 30 to 32, wherein the determining instructions include instructions for calculating an insulin dose using an adaptive model trained using data from a patient population. 34. The method of any one of paragraphs 30 to 33, wherein the determining step further comprises calculating an insulin dose further based on sensor data indicative of a lactate measurement. 35. The method of any one of paragraphs 22 to 34, wherein the step of determining the advice message is further based on whether the patient is taking an SGLT-2i, and further wherein if ketones are above a threshold, the determining step comprises a step of configuring an advice message to discontinue use of the SGLT-2i. 36. The method of any one of clauses 22 to 35, further comprising wirelessly communicating the first and second data to a user interface device. 37. The method of any one of paragraphs 22 to 36, further comprising transmitting a control signal to an automatic insulin delivery device based on the insulin dose determination. 38. In a test substance monitoring system: a sensor control device including an analyte sensor having at least a portion configured to be inserted into a body of a user, the sensor control device configured to collect first time-correlated data indicative of a glucose level and second time-correlated data indicative of a ketone level; A reading device and Including, The system is determining, based at least in part on the first and second time-correlated data, at least one of a warning condition for one or both of the first and second time-correlated data, an advisory message for output by the reader, a correction of the analyte status estimate, a sensor control device failure, an insulin delivery device failure, a drug dosage calculation, or an analytical report based on the first and second time-correlated data; The reader is configured to output an indication of the results of the determining process. 39. The system of claim 38, further comprising means for determining and outputting. 40. The system of claim 39, wherein the means for determining and outputting includes processing circuitry and non-transitory memory. 41. The system of paragraph 40, wherein the sensor control device includes processing circuitry and non-transitory memory. 42. The system of claim 39 or 40, wherein the reader includes a processing circuit and non-transitory memory. [Explanation of symbols]

[0154] 102 Sensor control device 104, 106 Test substance sensor 120 Reading Device

Claims

1. In the test substance monitoring system, a sensor control device including an analyte sensor having at least a portion configured to be inserted into a body of a user, a first processing circuit, and a first non-transitory memory, the sensor control device configured to collect first time-correlated data indicative of a glucose level and second time-correlated data indicative of a ketone level; a reader including a second processing circuit and a second non-transitory memory; Including, At least one of the first or second non-transitory memories includes instructions that, when executed, cause at least one of the first or second processing circuit to: determining, based at least in part on the first and second time correlation data, at least one of an alert condition for one or both of the first and second time correlation data, an advisory message for output by the reader, a correction of an analyte status estimate, a failure of the sensor control device, a failure of an insulin delivery device, a drug dosage calculation, or an analysis report based on the first and second time correlation data; outputting, by the reading device, an indication of the result of the determining process; A test substance monitoring system that performs the above.

2. 2. The analyte monitoring system of claim 1, wherein the instructions for determining the alert condition include instructions for setting at least one of an analyte level threshold for the alert condition or a time interval for issuing an alert.

3. The analyte monitoring system of claim 1 , wherein the instructions for determining the advice message include instructions for outputting a query by the reader.

4. 4. The test substance monitoring system of claim 3, wherein the instructions to output the query include instructions to output at least one question about the patient's comfort level based on the second time-correlated data indicating a transition from above an upper threshold to a lower threshold.

5. The analyte monitoring system of claim 3 , wherein the instructions to output the query include instructions to output at least one question about past patient behavior.

6. an input device operatively coupled to at least one of the reader or the sensor control device, the input device configured to receive information defining an insulin dose to be administered by a patient wearing the sensor control device; Further including, 10. The analyte monitoring system of claim 1, wherein the instructions to determine include instructions to correct an estimate of the patient's plasma insulin status.

7. an input device operably coupled to at least one of the reader device or the sensor control device configured to receive a ketone test result; Further including, 7. The analyte monitoring system of claim 6, wherein the instructions further cause automatic execution of an insulin dosage calculation algorithm in response to receiving the ketone test results.

8. The analyte monitoring system of claim 1 , wherein the instructions for determining include instructions for applying conditional logic defined in a data structure to determine the content of the advice message.

9. The analyte monitoring system of claim 1 , wherein the drug dosage calculation includes an insulin dosage calculation.

10. 10. The analyte monitoring system of claim 9, wherein the determining instructions include instructions for calculating the insulin dosage based on current ketone levels.

11. 10. The analyte monitoring system of claim 9, wherein the determining instructions include the insulin dose calculation including a mealtime bolus dose.

12. 10. The analyte monitoring system of claim 9, wherein the determining instructions include instructions for calculating the insulin dose using an adaptive model trained with data from a patient population.

13. 10. The analyte monitoring system of claim 9, wherein the instructions for determining include instructions for calculating the insulin dosage further based on sensor data indicative of a lactate measurement.

14. 2. The test substance monitoring system of claim 1, wherein the instructions for determining the advice message further base the determination on whether the patient is taking SGLT-2i, and include instructions for configuring the advice message to discontinue use of SGLT-2i if ketones are above a threshold.

15. The analyte monitoring system of claim 1 , wherein the instructions are stored in the second non-transitory memory.

16. The analyte monitoring system of claim 1 , wherein the instructions are stored in the first non-transitory memory.

17. 10. The analyte monitoring system of claim 1, wherein the sensor control device further includes wireless communication circuitry configured to transmit the first and second data to the reader device.

18. 17. The analyte monitoring system of claim 16, wherein the wireless communication circuitry is configured to transmit the first and second data via a Bluetooth protocol.

19. a third analyte sensor configured to sense a lactate level in the bodily fluid; The analyte monitoring system of claim 1 further comprising:

20. A drug delivery device The analyte monitoring system of claim 1 further comprising:

21. 20. The analyte monitoring system of claim 19, wherein the drug delivery device comprises an insulin pump.

22. 1. A computer-based method for monitoring and controlling a test substance in a patient, comprising: collecting, with a sensor control device including an analyte sensor at least a portion of which is inserted into the user's body, first time-correlated data indicative of glucose levels and second time-correlated data indicative of ketone levels; determining, based at least in part on the first and second time correlation data, at least one of an alert condition for one or both of the first and second time correlation data, an advisory message for output by a reader, a correction of an analyte status estimate, a failure of the sensor control device, a failure of an insulin delivery device, a drug dosage calculation, or an analytical report based on the first and second time correlation data; outputting an indication of the results of said determination by a user interface device; A method comprising:

23. 23. The method of claim 22, wherein the determining step further comprises setting at least one of an analyte level threshold for the alert condition or a time interval for issuing an alert.

24. 23. The method of claim 22, wherein determining the advice message further comprises determining a query for output by the user interface device.

25. 25. The method of claim 24, wherein determining the query comprises determining at least one question about the patient's comfort level based on the second time-correlated data indicating a transition from above an upper threshold to a lower threshold.

26. 25. The method of claim 24, wherein determining the query comprises determining at least one question about past patient behavior.

27. receiving information defining an insulin dosage to be administered by a patient wearing the sensor control device; Further including, wherein the determining step comprises correcting an estimate of the patient's plasma insulin status.

23. The method of claim 22.

28. automatically executing an insulin dosage calculation algorithm in response to receiving the ketone test results; 28. The method of claim 27, further comprising:

29. 23. The method of claim 22, wherein the determining step further comprises applying conditional logic defined in a data structure to determine the content of the advice message.

30. 23. The method of claim 22, wherein the medication dosage calculation comprises an insulin dosage calculation.

31. 31. The method of claim 30, wherein the determining step further comprises basing the insulin dosage calculation on current ketone levels.

32. 31. The method of claim 30, wherein the insulin dose calculation comprises a mealtime bolus dose calculation.

33. 31. The method of claim 30, wherein the determining instructions include instructions for calculating the insulin dose using an adaptive model trained with data from a patient population.

34. 31. The method of claim 30, wherein the determining step further comprises basing the insulin dosage calculation further on sensor data indicative of a lactate measurement.

35. 23. The method of claim 22, wherein the determining step is further based on whether the patient is taking an SGLT-2i, and further, if ketones are above a threshold, the determining step comprises configuring the advice message to discontinue use of an SGLT-2i.

36. 23. The method of claim 22, further comprising wirelessly communicating the first and second data to the user interface device.

37. 37. The method of claim 36, further comprising transmitting a control signal to an automatic insulin delivery device based on the insulin dosage determination.

Images