Prediction of physiological parameters

Abstract

Techniques related to predicting a physiological condition of a user are disclosed herein. In some embodiments, the techniques may involve obtaining one or more glucose concentration values measured from a user; applying a first glucose prediction model for a first prediction time domain to the one or more glucose concentration values measured from the user; obtaining a first predicted glucose value of the user based on application of the first glucose prediction model; and predicting a second predicted glucose value of the user for a second predicted time domain less than the first predicted time domain based on the first predicted glucose value and at least one of the one or more glucose concentration values. In some scenarios, the physiological condition may include, for example, hypoglycemia or hyperglycemia.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of priority to U.S. Provisional Application No. 63 / 519,722, filed on August 15, 2023, entitled “PREDICTION OF PHYSIOLOGICAL PARAMETER,” which is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure relates generally to predicting a user's physiological parameters (eg, blood glucose level), and more particularly to using machine learning estimates as a basis for physiological parameter prediction over a prediction time domain. Background Art

[0004] Monitoring a person's blood glucose level can be an important part of managing certain physiological conditions. For example, a diabetic patient or user may use a diabetes management device to monitor blood glucose levels to provide insulin therapy to prevent undesirable outcomes, such as hypoglycemia or hyperglycemia. It would be useful to be able to predict a person's blood glucose level and future resulting conditions to further facilitate management of such conditions. Summary of the invention

[0005] Disclosed herein are techniques related to predicting physiological parameters. These techniques can be practiced in a variety of ways, such as using: a processor-implemented method; a system comprising one or more processors and one or more processor-readable media; and / or one or more (non-transitory) processor-readable media.

[0006] In some aspects of the present disclosure, a processor-implemented method is disclosed. In some embodiments, the techniques of the processor-implemented method may involve: obtaining one or more glucose concentration values ​​measured from a user; applying a first glucose prediction model for a first prediction time domain to the one or more glucose concentration values ​​measured from the user; obtaining a first predicted glucose value for the user based on applying the first glucose prediction model; and predicting a second predicted glucose value for the user for a second prediction time domain that is less than the first prediction time domain based on the first predicted glucose value and at least one of the one or more glucose concentration values.

[0007] In some aspects of the present disclosure, a system is disclosed. In some embodiments, the system may include: one or more processors; and one or more processor-readable media storing instructions that, when executed by the one or more processors, cause the following operations to be performed: obtaining one or more glucose concentration values ​​measured from a user; using the one or more glucose concentration values ​​to estimate a first blood glucose value of the user within a predetermined time length; obtaining a predicted time domain less than a predetermined time length, a first threshold level, and a second threshold level; estimating a second blood glucose value of the user within the predicted time domain based on the first blood glucose value and a first machine learning model trained to determine whether the user's blood glucose level will be lower than the first threshold level within the predicted time domain or based on the first blood glucose value and a second machine learning model trained to determine whether the user's blood glucose level will be higher than the second threshold level within the predicted time domain; and generating a prediction of the user's physiological condition based at least on the estimated second blood glucose value.

[0008] In some aspects of the present invention, one or more non-transitory processor-readable media are disclosed. In some embodiments, the one or more non-transitory processor-readable media may store instructions that, when executed by one or more processors, cause the following operations to be performed: obtaining one or more glucose concentration values ​​measured from a user; applying a first glucose prediction model for a first prediction time domain to the one or more glucose concentration values ​​measured from the user; obtaining a first predicted glucose value for the user based on applying the first glucose prediction model; and predicting a second predicted glucose value for the user for a second prediction time domain that is less than the first prediction time domain based on the first predicted glucose value and at least one of the one or more glucose concentration values.

[0009] In some scenarios, the physiological condition may include, for example, hypoglycemia or hyperglycemia. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The above and other aspects and features of the present disclosure will become more apparent in view of the following detailed description when considered in conjunction with the accompanying drawings, wherein like reference numerals identify like elements.

[0011] Figure 1 is an illustration of an exemplary therapy delivery system according to aspects of the present disclosure.

[0012] Figure 2A and Figure 2B Illustrated are examples of machine learning (ML) models that are trained to predict future physiological parameters over a period of time, according to some embodiments.

[0013] Figure 3 is a diagram of an example of an architecture with a prediction system according to some embodiments.

[0014] Figure 4 is an example of a graph illustrating interpolation for determining potential hypoglycemia indicators.

[0015] FIG. 5A to FIG. 5C An example of the application of a "hold" method for generating a raw high blood glucose indication or a raw low blood glucose indication is illustrated.

[0016] Figure 6 is a flow chart illustrating one example of a method for predicting a user's physiological condition.

[0017] Figure 7 is a flow chart illustrating another example of a method for predicting a user's physiological condition.

[0018] Figure 8 is a flow chart illustrating another example of a method for predicting a user's physiological condition.

[0019] Fig. 9 is a diagram of an example of an insulin delivery device according to aspects of the present disclosure.

[0020] Fig.10 is a block diagram of an example of a computer system that may be utilized in the embodiments described herein. DETAILED DESCRIPTION

[0021] It is important for users (including caregivers) to be aware of changes and anomalies in a patient's physiological parameters, such as the patient's blood glucose level. For example, for a diabetic patient in an insulin therapy scenario, delivering a therapeutic substance (e.g., an insulin bolus dose) at or before, for example, a blood glucose peak can help manage glucose levels in the body. As another example, consuming carbohydrates or a meal can restore a dropped blood glucose level and counteract associated symptoms.

[0022] For reasons such as these, a mechanism that can predict hypoglycemia and hyperglycemia at a future time or some future time can advantageously, for example, warn users and caregivers in advance. One or more machine learning models and / or numerical analysis techniques can be used to estimate physiological parameters (e.g., blood sugar levels) in the prediction time domain (e.g., a certain amount of time into the future). Then the user just can avoid such hypoglycemia and hyperglycemia events, and maintain good blood sugar control by properly intervening before such events occur. Moreover, as a prediction mechanism, it is expected that the user can have flexibility in determining the thresholds or conditions indicating hypoglycemia and hyperglycemia. Different users may wish to be warned based on different thresholds (or different ranges of normal glucose levels) of hypoglycemia or hyperglycemia.

[0023] Furthermore, the predictive alert mechanism should be reliable in its predictions. The predictive alert mechanism should reduce false alarms (false positives) while maintaining appropriate sensitivity to not miss correct positive predictions while reducing false alarms. This can help reduce alarm fatigue (where users become desensitized to alarms, leading to missed or ignored alarms or delayed responses), improve patient experience, and gain user confidence to take action based on predictive alerts to prevent adverse conditions.

[0024] According to certain embodiments and techniques disclosed herein, a machine learning model can be used with a prediction system to predict a patient's future blood glucose level. More specifically, a threshold can be selected to determine whether the patient's predicted blood glucose level indicates a physiological condition, such as hyperglycemia or hypoglycemia, for a future time period (such as a 60-minute prediction time domain). If the patient's blood glucose level is predicted to be below a certain threshold, an indication of hypoglycemia can be generated, and vice versa an indication of hyperglycemia can be generated. In some embodiments, an intermediate time period can be selected, and the corresponding blood glucose level can be determined to provide a more refined result about the patient's blood glucose level or physiological condition prediction. In one method, an analysis technique can be applied to the predicted blood glucose level and the current sensor glucose measurement result of a prediction time domain to estimate the glucose level of different prediction time domains. For example, an interpolation technique can be applied between the blood glucose level and the sensor glucose measurement result to generate a prediction for a second prediction time domain (e.g., 30 minutes), and the prediction can also be compared with a threshold to predict whether the patient will be in hyperglycemia or hypoglycemia within the second prediction time domain. In some embodiments, before generating a final alarm for these predictions, these indications can be further evaluated and qualified to reduce false positives or otherwise provide more accurate predictions. For example, in some implementations, some indications may be "held" until further indications (e.g., two or three consecutive trigger predictions) validate the prediction. In some implementations, contextual information or user settings may also inform the indication before generating a final indication, which may appear as an alarm.

[0025] Discussion utilizing terms such as, for example, “process,” “compute,” “calculate,” “determine,” “establish,” “analyze,” “examine,” and the like may refer to the operations and / or processes of a computer, computing platform, computing system, or other electronic computing device that manipulates data represented as physical (e.g., electronic) quantities within a computer's registers and / or memory and / or transforms such data into other data similarly represented as physical quantities within a computer's registers and / or memory or other non-transitory information storage medium that may store instructions to perform the operations and / or processes by, for example, one or more processors or processor devices (e.g., a system on a chip) or devices associated with such processors.

[0026] Unless explicitly stated, the methods described herein are not limited to a particular order or sequence. In addition, some of the methods or elements of the methods may occur or be performed simultaneously or in parallel.

[0027] Figure 1 An exemplary therapy delivery system 100 for a person 101 is depicted. System 100 may be an insulin delivery system. The depicted therapy delivery system 100 includes a delivery device 102, a monitoring device 104, a computing device 106, and an optional remote or cloud computing system 108. Delivery device 102, monitoring device 104, and computing device 106 may be embodied in various ways, including being disposed in one or more device housings. For example, in some embodiments, all devices in devices 102-106 may be disposed in a single device housing. In some embodiments, each device in devices 102-106 may be disposed in a separate device housing. In some embodiments, two or more devices in devices 102-106 may be disposed in the same device housing, and / or a single device 102, 104, or 106 may have two or more parts disposed in two or more housings. Such embodiments and combinations thereof are contemplated to be within the scope of the present disclosure.

[0028] Figure 1 Communication links 112-118 are also depicted. Communication links 112-118 can each be a wired connection and / or a wireless connection. Where the two devices are located in the same device housing, the communication link can include, for example, wires, cables, and / or a communication bus located on a printed circuit board, etc. Where the two devices are separated from each other in different device housings, the communication link can be a wired connection and / or a wireless connection. A wired connection can include, but is not limited to, an Ethernet connection, a USB connection, and / or another type of physical connection. A wireless connection can include, but is not limited to, a cellular connection, a Wi-Fi connection, A connection, a mesh network connection, and / or another type of connection using a wireless communication protocol. Some embodiments of communication links 112-118 may use a direct connection such as The communication links 112-118 may be connected and / or may use connections routed through one or more networks or network devices (not shown), such as Ethernet networks, Wi-Fi networks, cellular networks, satellite networks, intranets, extranets, the Internet, and / or Internet backbone networks, etc. Various combinations of wired connections and / or wireless connections may be used for the communication links 112-118.

[0029] Various aspects of the insulin delivery system 100 are described below. Additional aspects and details may be described in the following U.S. Patent Nos.: 4,562,751; 4,685,903; 5,080,653; 5,505,709; 5,097,122; 6,485,465; 6,554,798; 6,558,320; 6,558,351; 6,641,533; 6,659,980; 6,752,787; 6,817,990; 6,932,584; and 7,621,893. The entire contents of each of the foregoing U.S. Patents are hereby incorporated herein by reference.

[0030] Delivery device 102 is configured to deliver a therapeutic substance (e.g., insulin) to person 101. Delivery device 102 may be fixed to person 101 (e.g., fixed to the body or clothing of person 101) or may be implanted on or in the body of person 101. In some embodiments, delivery device 102 may include a reservoir, an actuator, a delivery mechanism, and a cannula (not shown). The reservoir may be configured to store a certain amount of therapeutic substance. In some embodiments, the reservoir may be refillable or replaceable. The actuator may be configured to drive the delivery mechanism. In some examples, the actuator may include a motor, such as an electric motor. The delivery mechanism may be configured to move the therapeutic substance from the reservoir through the cannula. In some examples, the delivery mechanism may include a pump and / or a plunger. The cannula may facilitate fluid connection between the reservoir and the body of person 101. The cannula and / or needle may facilitate delivery of the therapeutic substance to the tissue layer, vein, or body cavity of person 101. During operation, the actuator, in response to a signal (eg, a command signal), may drive the delivery mechanism, thereby moving the therapeutic substance from the reservoir, through the cannula, and into the body of person 101 .

[0031] The components of the delivery device 102 described above are provided as examples only. The delivery device 102 may include other components, such as, but not limited to, a power source, a communication transceiver, computing resources, and / or a user interface, etc. Those skilled in the art will recognize various implementations of the delivery device 102 and components of such implementations. All such implementations and components are contemplated to be within the scope of the present disclosure.

[0032] Continue to refer Figure 1 Monitoring device 104 is configured to detect a physiological condition (e.g., a glucose concentration level) of person 101, and may also be configured to detect other matters. Monitoring device 104 may be secured to the body of person 101 (e.g., secured to the skin of person 101 via an adhesive) and / or may be at least partially implanted in the body of person 101. Depending on the particular location or configuration, monitoring device 104 may come into contact with biological matter (e.g., interstitial fluid and / or blood) of person 101.

[0033] The monitoring device 104 includes one or more sensors (not shown), such as, but not limited to, electrochemical sensors, electrical sensors, and / or optical sensors. As will be appreciated by those skilled in the art, the electrochemical sensor may be configured to respond to the interaction or binding of the biomarker with the substrate by generating an electrical signal based on the potential, conductivity, and / or impedance of the substrate. The substrate may include a material selected to interact with a specific biomarker such as glucose. The potential, conductivity, and / or impedance may be proportional to the concentration of the specific biomarker. In the case of an electrical sensor, and as will be appreciated by those skilled in the art, the electrical sensor may be configured to respond to the electrical biosignal by generating an electrical signal based on the amplitude, frequency, and / or phase of the electrical biosignal. The electrical biosignal may include a change in the current generated by the sum of the potential differences across tissues of the person 101, such as the nervous system. In some embodiments, the electrical biosignal may include a portion of a potential change in an electrocardiogram, such as that recorded as an indication of the glucose level of the person 101, generated by the heart of the person 101 over time. In the case of an optical sensor, as will be appreciated by those skilled in the art, the optical sensor can be configured to respond to the interaction or binding of a biomarker with a substrate by generating an electrical signal based on changes in the brightness of the substrate. For example, the substrate can include a material selected to fluoresce in response to contact with a selected biomarker, such as glucose. The fluorescence can be proportional to the concentration of the selected biomarker.

[0034] In some embodiments, monitoring device 104 may include other types of sensors that may be worn, carried, or coupled to person 101 to measure activities of person 101 that may affect glucose levels or glycemic response of person 101. For example, a sensor may include an accelerometer configured to detect acceleration of person 101 or a portion of person 101, such as a hand or foot of the person. Acceleration (or lack of acceleration) may indicate exercise, sleep, or food / beverage consumption activities of person 101, which may affect glycemic response of person 101. In some embodiments, the sensor may include heart rate and / or body temperature, which may indicate the amount of physical exercise experienced by person 101. In some embodiments, the sensor may include a GPS receiver that detects GPS signals to determine the location of person 101.

[0035] The above sensors are provided as examples only. Other sensors or other types of sensors for monitoring physiological conditions, activities and / or positions, etc. will be recognized by those skilled in the art and are contemplated within the scope of the present disclosure. For any sensor, the signal provided by the sensor shall be referred to as a "sensor signal".

[0036] Monitoring device 104 may include components and / or circuits configured to pre-process sensor signals. Pre-processing may include, but is not limited to, amplification, filtering, attenuation, scaling, isolation, normalization, transformation, sampling, and / or analog-to-digital conversion, etc. Those skilled in the art will recognize various specific implementations of such pre-processing, including but not limited to specific implementations using processors, controllers, ASICs, integrated circuits, hardware, firmware, programmable logic devices, and / or machine executable instructions, etc. The types of pre-processing and their specific implementations are provided only as examples. It is contemplated that other types of pre-processing and specific implementations are within the scope of the present disclosure. In some embodiments, monitoring device 104 may not perform pre-processing.

[0037] As used herein, the term "sensed data" shall mean and include information represented by a sensor signal or by a pre-processed sensor signal. In some embodiments, the sensed data may include glucose levels in the body of person 101, acceleration of a portion of person 101, heart rate of person 101, temperature of person 101, and / or geographic location (e.g., GPS location) of person 101, etc. Monitoring device 104 may transmit the sensed data to delivery device 102 via communication link 112 and / or transmit the sensed data to computing device 106 via communication link 114. Use of the sensed data by delivery device 102 and / or computing device 106 will be described later herein.

[0038] Computing device 106 provides processing capabilities and can be implemented in a variety of ways. In some embodiments, computing device 106 can be a consumer device such as a smartphone, a computerized wearable device (e.g., a smart watch), a tablet computer, a laptop computer, or a desktop computer, or can be a dedicated device (e.g., a portable control device) provided by, for example, a manufacturer of delivery device 102. In some embodiments, computing device 106 can be a "processing circuit" (defined below) integrated with another device such as delivery device 102. In some embodiments, computing device 106 can be secured to person 101 (e.g., secured to the body or clothing of person 101), can be at least partially implanted in the body of person 101, and / or can be held by person 101.

[0039] For each of the embodiments of the computing device 106, the computing device 106 may include various types of logic circuits, including but not limited to microprocessors, controllers, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), central processing units (CPUs), graphics processing units (GPUs), programmable logic devices, memories (e.g., random access memories, volatile memories, non-volatile memories, etc.), or other discrete or integrated logic circuits, and combinations of such components. The term "processing circuit" may generally refer to any of the foregoing logic circuits, alone or in combination with other logic circuits, or any other circuits for performing computations.

[0040] Aspects of delivery device 102, monitoring device 104, and computing device 106 have been described above. One or more of devices 102-106 may include a user interface (not shown) that presents information to person 101 and / or receives information from person 101. The user interface may include a graphical user interface (GUI), a display device, a keyboard, a touch screen, a speaker, a microphone, a vibration motor, a button, a switch, and / or other types of user interfaces. Those skilled in the art will recognize the various types of user interfaces that can be used, and all such user interfaces are conceivable to be within the scope of the present disclosure. For example, in the case where computing device 106 is a consumer device such as a smart phone, a tablet computer, a laptop computer, etc., the user interface will include a display device, a physical and / or virtual keyboard, and / or an audio speaker, etc. provided by such a consumer device. In some embodiments, the user interface may notify person 101 of sensed data (e.g., glucose level) and / or insulin delivery data (e.g., historical, current, or future insulin delivery rate) and may present an alarm to person 101. In some embodiments, the user interface may receive input from person 101, which may include, for example, requested insulin delivery changes and / or meal instructions, etc. The above description and embodiments of user interfaces are provided merely as examples, and other types and other uses of user interfaces are contemplated as being within the scope of the present disclosure.

[0041] The following describes the communication between devices 102-106 and the cooperation between devices 102-106 with respect to insulin delivery. Figure 1As depicted, and as described above, devices 102-106 may communicate with each other via communication links 112-116. In some embodiments, computing device 106 may control the operation of delivery device 102 and / or monitoring device 104. For example, computing device 106 may generate one or more signals (e.g., command signals) that cause delivery device 102 to deliver insulin to person 101, for example, in a basal dose and / or a bolus dose. In some embodiments, computing device 106 may receive data associated with insulin delivery (e.g., insulin delivery data) from delivery device 102 and / or sensed data (e.g., glucose levels) from monitoring device 104, and may perform calculations based on the insulin delivery data, sensed data, and / or other data to control delivery device 102. Insulin delivery data may include, but is not limited to, the type of insulin delivered, historical insulin delivery rate and / or amount, current insulin delivery rate and / or amount, and / or user input that affects insulin delivery. As will be appreciated by those skilled in the art, in a closed-loop mode of operation, computing device 106 may transmit a dosage command to delivery device 102 based on a difference between a current glucose level in the body of person 101 (e.g., received from monitoring device 104) and a target glucose level (e.g., determined by computing device 106). The dosage command may indicate an amount of insulin to be delivered and / or an insulin delivery rate, and may adjust the current glucose level toward the target glucose level. Examples of closed-loop operation for insulin infusion systems are described in the following U.S. Patent Nos.: 6,088,608, 6,119,028, 6,589,229, 6,740,072, 6,827,702, 7,323,142, and 7,402,153, and in U.S. Patent Application Publication Nos. 2014 / 0066887 and 2014 / 0066889. The entire contents of each of the aforementioned patents and publications are hereby incorporated herein by reference.

[0042] Continue to refer Figure 1, the remote or cloud computing system 108 can be a proprietary remote / cloud computing system or a commercial cloud computing system including one or more server computing devices. When the computing resources of the client computing device (e.g., computing device 106) are insufficient, the remote / cloud computing system 108 can provide additional computing resources on demand as needed. The computing device 106 and the remote / cloud computing system 108 can communicate with each other via a communication link 118, which can traverse one or more communication networks (not shown). The communication network may include, but is not limited to, an Ethernet network, a Wi-Fi network, a cellular network, a satellite network, an intranet, an extranet, the Internet, and / or an Internet backbone network. Those skilled in the art will recognize the specific implementation of the remote / cloud computing system 108 and how to interact with such a system through various types of networks. For example, the remote / cloud computing system 108 may include a processing circuit array (defined above) and can execute machine-readable instructions. It is conceivable that such specific implementations, interfaces, and networks are within the scope of the present disclosure. In some embodiments, the delivery device 102 and / or the monitoring device 104 can communicate with each other via one or more other communication links ( Figure 1 ) communicates directly with a remote or cloud computing system 108.

[0043] Exemplary therapy delivery systems have been described above. For convenience, the following description may be primarily with reference to an insulin delivery system as an example of a therapy delivery system. However, any aspect, embodiment, or description intended to be relevant to an insulin delivery system should be applicable to a therapy delivery system that delivers a therapy other than insulin.

[0044] Machine Learning Models

[0045] Figure 2A and Figure 2B Illustrated are exemplary machine learning (ML) models 200, 250 according to some embodiments, which are trained to predict future physiological parameters (e.g., blood glucose values) over a period of time. In some embodiments, each of the ML models 200, 250 can be configured to receive the following as input: (i) one or more measured sensor glucose (SG) values, which can be in the form of glucose concentration values, (ii) a prediction horizon, which refers to how far into the future the ML model predicts, represented by a certain amount of time (e.g., 30 minutes), and / or (iii) one or more prediction thresholds. An example of a prediction horizon is 60 minutes, which is a fixed time period. In some specific implementations, the prediction horizon can be changed to a different time period after the ML model has been trained, for example based on the training method mentioned below.

[0046] In some embodiments, each of the ML models 200, 250 can be a classifier configured to generate as an output a discrete prediction (e.g., yes or no, 1 or 0) about whether the user's blood glucose (BG) will cross each of one or more thresholds after a predetermined time period based on the input and parameters of the ML model. Some examples of the ML models 200, 250 can be based on at least, for example, gradient boosting, decision trees, random forests. In some specific implementations, a probability or likelihood associated with the prediction can be generated and output. Such a predetermined time period can be specified by a prediction time domain, which refers to how far the prediction is made. As an example of a BG threshold, if the BG has dropped below a threshold of 70 mg / dL, the patient can be considered to be in hypoglycemia, and if the BG has risen above a threshold of 120 mg / dL, the patient can be considered to be in hyperglycemia. However, these are merely examples to illustrate the difference between hypoglycemia thresholds and hyperglycemia thresholds. A variety of thresholds may be considered and configured as inputs to the ML models 200, 250, such as, for example: using any value between 60 mg / dL and 80 mg / dL (including the boundary values) for a low "bottom line" threshold to determine hypoglycemia, where a BG value (or multiple sustained BG values) crossing the low threshold or being detected as being below the low threshold will indicate hypoglycemia (or at least the basis for such an indication); and using any value between 120 mg / dL and 400 mg / dL (including the boundary values) for a high threshold to determine hyperglycemia, where a BG value (or multiple sustained BG values) crossing the high threshold or being detected as being above the high threshold will indicate hyperglycemia (or at least the basis for such an indication). It should be noted that in some cases low and high thresholds that overlap with the normal blood glucose range (such as 80 mg / dL to 120 mg / dL) may be used, such as using 60 mg / dL to 90 mg / dL for the low threshold and 100 mg / dL to 400 mg / dL for the high threshold. Moreover, in some embodiments, multiple thresholds may be set. BG values ​​crossing some of these thresholds may not indicate hypoglycemia or hyperglycemia. However, the ML model 200, 250 may provide a marker or other additional data when one or more of the multiple thresholds are observed to be crossed, for example to determine a trend. If a classifier as mentioned above is used, the prediction may be a binary determination (yes or no) for each of the one or more thresholds. Therefore, at least one of the ML models 200, 250 may be a binary and multi-class model configured to make a binary determination about multiple classes (e.g., thresholds).

[0047] The parameters of each ML model may be, for example, weights and / or biases determined by training via loss minimization (e.g., gradient descent) after feeding a training data set. In some cases, the ML models may each be population-trained, where the training data set is obtained from a patient population. For example, the training data set may include BG values ​​of numerous patients over time, including at one or more fixed time periods (30 minutes after the prediction time, 60 minutes after the prediction time, etc.), and the training data set may also include annotation data (e.g., whether a given BG value crosses a threshold) and a validation data set (e.g., 20% of the training data). The ML model may be trained with different specific time periods, but the ML model may also be able to make predictions for other time periods, for example, based on training of corresponding data across time periods. In some cases, the ML models may each be patient-specific, where the training data set is obtained from patient information. For example, the training data set may include BG values ​​of a specific patient or user over time, including at one or more fixed time periods, and the training data set may also include annotation data (e.g., whether a given BG value crosses a threshold) and a validation data set (e.g., 20% of the training data). The resulting ML model may be a classifier configured to predict whether a given BG value will cross a given threshold, for example based on a logistic regression model. In some embodiments, a first ML model may be configured to determine only whether a BG value will be below a threshold (hypoglycemia), while a separate second ML model may be trained to determine only whether a BG value will be above a threshold (hyperglycemia). In some implementations, a probability associated with the determination may also be considered, where, for example, a "yes" or "no" output may be generated only if the probability of the BG value is above or below 50% or another probability threshold.

[0048] Thus, each of the ML models 200, 250 may be configured to predict BG values ​​and whether the patient's BG value will cross a particular threshold (or thresholds) within a fixed time period into the future (corresponding to the time range t of the prediction horizon). As an illustrative example, the ML model 200 may be trained to determine a future hypoglycemic condition by determining whether the user's BG will be below a selected baseline (e.g., 70 mg / dL) after a predetermined time period (e.g., a one-hour prediction horizon). More than one threshold may be provided, such as 80 mg / dL, 70 mg / dL, and 60 mg / dL. In some implementations, the threshold may be set by the user. In some implementations, a preset threshold setting may be provided to the user, such as as a default or preconfigured setting. In some implementations, the threshold setting may be provided and limited to, for example, a range of 60 mg / dL to 90 mg / dL, such that the user cannot set the threshold above or below the range. However, in some implementations, other thresholds (such as thresholds that are generally considered non-hypoglycemic or non-hyperglycemic) may be set (e.g., 90 mg / dL).

[0049] By way of example, the ML model 200 may first estimate the user's BG at the end of a predetermined time period (prediction time domain). For example, the ML model 200 may determine that the BG will be 65 mg / dL after one hour. For example, if thresholds of 70 mg / dL and 60 mg / dL have been set, the determined BG will drop below the threshold of 70 mg / dL but not below the threshold of 60 mg / dL. The ML model 200 may therefore generate a prediction that the user's BG will cross the low blood glucose threshold of 70 mg / dL but not the low blood glucose threshold of 60 mg / dL. If the low low blood glucose threshold is set to 70 mg / dL, the ML model 200 may generate a determination and / or an alarm that the threshold has been reached. If the threshold is set to 60 mg / dL, the ML model 200 may generate a determination that the threshold has not yet been reached. In a configuration where an alarm or notification is generated when a BG is detected to cross a threshold, an alarm may not be generated, or an alarm may be generated indicating that the threshold has not yet been reached.

[0050] Similarly, the ML model 250 (e.g., from the ML model 200) may be separately trained to determine future hyperglycemic conditions by determining whether the user's BG will be above a selected upper threshold (e.g., 100 mg / dL) after a predetermined time period (e.g., a one-hour forecast horizon). More than one threshold may be provided. The threshold may be set by the user, or a preset threshold setting may be provided to the user. The threshold setting may be limited to an allowed range, such as 100 mg / dL to 400 mg / dL, such that the user cannot set the threshold above or below the range. The ML model 250 may first estimate the user's BG after a predetermined time period. For example, the ML model 250 may determine that the BG will be 125 mg / dL after one hour. If thresholds of 120 mg / dL and 130 mg / dL have been set, the determined BG will be above the threshold 120 mg / dL but not above the threshold 130 mg / dL. The ML model 250 may therefore generate a prediction that the user's BG will cross the hyperglycemic threshold of 120 mg / dL but not the hyperglycemic threshold of 130 mg / dL.

[0051] As will be discussed further below, the second prediction horizon may be obtained, for example, from a user or a preselected value. In some embodiments, the second prediction horizon may be selected to be an amount of time that is less than the predetermined period of time that the ML model uses to make initial ML-based predictions (the first initial prediction horizon discussed above). In one example, the second prediction horizon may be 30 minutes, which is less than one hour from the example above. In some embodiments, the second prediction horizon may be used, at least in part, to make predictions at the initial prediction horizon.

[0052] Prediction System

[0053] Figure 3 304a and 304b). In some implementations, the prediction system 302 may be implemented on the delivery device 102, the monitoring device 104, or the computing device 106. In some cases, the raw indication may refer to an indication that is generated by the prediction system 302 but is not delivered to the user (unless it meets one or more additional criteria before generating the final indication 320 to the user). However, in some cases, the raw indication may be directly delivered to the user as the final indication 320 without further consideration of the additional criteria.

[0054] In some embodiments, the prediction system 302 may obtain one or more prediction thresholds 306 and one or more prediction time domains 308 as input. The prediction system 302 may obtain one or more prediction thresholds 306a for hyperglycemia and one or more prediction thresholds 306b for hypoglycemia. In some embodiments, the prediction thresholds 306 and the prediction time domain 308 may be provided by a user. However, in some specific implementations, the prediction thresholds 306 and the prediction time domain 308 may be preconfigured by the prediction system 302, which may be default values ​​that may be adjusted by a user in some cases. In some cases, multiple prediction thresholds may be provided or preconfigured.

[0055] In some embodiments, the raw indication generated by the prediction system 302 can be: a raw high blood glucose indication 304a indicating that the user will have a blood glucose level above one or more prediction thresholds 306a within the prediction time domain 308, or a raw low blood glucose indication 304b indicating that the user will have a blood glucose level below a prediction threshold 306b within the prediction time domain 308.

[0056] In some embodiments, the prediction system 302 may obtain input from one or more machine learning (ML) models. In the exemplary architecture 300, the prediction system 302 may obtain input from a hyperglycemia ML model 310a and a hypoglycemia ML model 310b, wherein the hyperglycemia ML model is configured to determine future hyperglycemia conditions based on a fixed time period into the future, and the hypoglycemia ML model is configured to determine future hypoglycemia conditions based on a fixed time period into the future. The fixed time period may be a time domain preselected or predetermined based on the configuration of the hyperglycemia ML model 310a and / or the hypoglycemia ML model 310b. In some cases, the fixed time period of the hyperglycemia ML model 310a may be different from the fixed time period of the hypoglycemia ML model 310b. For example, in some cases, the fixed time period may be 60 minutes for both models; however, in some cases, the fixed time period may be 60 minutes for one model and 45 minutes for another model. The hyperglycemia ML model 310a may be an example of the ML model 250, and the hypoglycemia ML model 310b may be an example of the ML model 200. Thus, in some implementations, each of the ML models 310a, 310b may be described above with respect to Figure 2A and Figure 2B The ML models 310a, 310b may be pre-trained and obtained from a remote or cloud computing system 108, or they may be pre-configured and stored on the delivery device 102, the monitoring device 104, or the computing device 106.

[0057] Each of the ML models 310a, 310b can obtain as input a sensor glucose (SG) reading measured from a monitoring device 312. In some embodiments, the monitoring device 312 may include a continuous glucose monitor (CGM), which may include one or more sensors configured to estimate blood glucose based on the user's interstitial glucose. In some implementations, the monitoring device 312 may be an example of the monitoring device 104. In some embodiments, as described above with respect to Figure 2A and Figure 2B As discussed, the ML models 310a, 310b may include classifiers configured to output a prediction as to whether a user's blood glucose (BG) level will cross a particular threshold (or thresholds) within a fixed time period (eg, 60 minutes) into the future.

[0058] In certain implementations where prediction system 302 is implemented on computing device 106, computing device 106 may receive SG readings and measurements as inputs (e.g., discrete inputs or continuous input streams), where the inputs may be from a CGM (e.g., monitoring device 312). In some cases, inputs may also be received from delivery device 102. Some or all other portions of prediction system component 301 may also be implemented on computing device 106 along with prediction system 302.

[0059] In some embodiments, as part of the secondary prediction output, the ML model 310a or 310b may first predict the user's BG value at the end of the fixed time period according to a selected or predetermined time domain (e.g., 60 minutes). The prediction system 302 may then be configured to use the ML predicted BG value for that time period to determine or estimate the BG value for a different prediction time domain that is less than the fixed time period provided above. The different prediction time domain may be provided as a prediction time domain 308, which may be selectable or provided by a user or patient, or configured as a default value or otherwise determined by the exemplary architecture 300 or prediction system 302. This determination or estimation of the BG value may be based on an analysis technique using the ML predicted BG value and an anchor SG value (obtained via the monitoring device 312). The "anchor" SG value may refer to the SG value at the time of prediction. In some specific implementations, the analysis technique may include interpolation 311a and / or 311b, such as linear interpolation between the ML predicted BG value and the anchor SG value. In other embodiments, alternative types of interpolation may be used, including exponential interpolation, logarithmic interpolation, power interpolation, polynomial interpolation, cubic interpolation, etc.

[0060] As an example of linear interpolation, a line may be fitted between the two values. If the prediction horizon 308 is less than the fixed time period used to predict BG values ​​(e.g., the prediction horizon 308 is 30 minutes compared to the 60 minute fixed time period for ML-based prediction by the ML model (e.g., 310a or 310b), then an intermediate value may be determined for the 30 minute prediction horizon. The prediction horizon for the intermediate value may be referred to as the "target prediction horizon," which is different from the fixed time period used for ML-based prediction, which may also be referred to as the "anchor prediction horizon" for interpolation purposes.

[0061] Interpolation can be beneficial in situations where the prediction horizon of interest is not well suited for ML-based predicted BG values, or where multiple predictions are needed or predictions need to be made for different or rapidly changing prediction horizons. It can also be useful for reducing the use of computing resources. By way of example, a user may estimate a BG value using an ML model once (or only a few times) given an anchor prediction horizon (e.g., 60 minutes). Based on this BG value, interpolation can be performed quickly and / or in rapid succession based on the current SG reading (e.g., anchor SG value 412) and one or more selected target prediction horizons. In fact, multiple interpolations can be performed substantially at once to provide estimated BG values ​​for multiple target prediction horizons that are less than the anchor prediction horizon (e.g., at 10 minutes, 20 minutes, 30 minutes, 40 minutes, and 50 minutes). In contrast to using interpolation, using an ML model to generate each of these predictions of BG values ​​may be more time-consuming and resource-intensive. If desired, a more refined and accurate estimate of the BG value (e.g., using a target prediction horizon of 31 minutes) can also be made.

[0062] See also Figure 4 To illustrate exemplary graph 400, which illustrates interpolation for determining a potential hypoglycemia indication (e.g., a hypoglycemia alarm), the anchor prediction horizon used by the ML model to predict BG values ​​may be 60 minutes (time 402), as previously described with respect to Figure 2A and Figure 2B The case in the example discussed. The target prediction horizon may be less than the anchor prediction horizon, which in this example is 30 minutes (time 404). The target prediction horizon may be selected from other time ranges (e.g., selected by the user or preconfigured or preselected by the prediction system 302), such as between 1 minute and 59 minutes, or any time period less than the anchor prediction horizon (e.g., if the anchor prediction horizon is 90 or 120 minutes, then a 75 minute target prediction horizon may be selected). These example time periods are with respect to an "anchor time," a current measurement or reference time. This means that the time period between an anchor time (e.g., anchor time 406) and time 402 is 60 minutes, and the time period between the anchor time and time 404 is 30 minutes.

[0063] In this case, the ML predicted BG value 408 based on the anchor prediction horizon, i.e., 54 mg / dL, can be considered as the lowest SG value. Since the anchor SG value 412 (100 mg / dL) at the anchor time 406 is higher than the ML predicted BG value 408 (54 mg / dL), the intermediate value will logically fall between the lowest SG value 54 mg / dL and the anchor value 100 mg / dL. Given the target prediction horizon of 30 minutes as input, the prediction system 302 will predict the final SG value 410 to be 76 mg / dL, which is as follows Figure 4Shown at time 404 is between the ML predicted BG value 408 (at time 402) and the anchor SG value 412 (at anchor time 406). While other longer target or anchor prediction horizons may be used, such as 120 minutes, 180 minutes, etc., longer prediction horizons may be less accurate in certain situations, or they may make it more difficult for the user to act on them or remember to act without assistance (e.g., alarms or reminders) because the farther into the horizon, for example, future situations such as intervention activities (e.g., meals, insulin delivery, snacks, exercise, sleep) or the availability of a caregiver or user may become more difficult to predict. Therefore, when selecting anchor and target prediction horizons, the use scenario, usability, and usefulness of the predictions may be considered.

[0064] In some approaches, by fitting a line between the ML-predicted BG value at time 402 and at least the anchor SG value 412 (at anchor time 406), the prediction system 302 may determine that the final predicted BG value 410 for the target prediction horizon at time 404 is 76 mg / dL, such as Figure 4 As mentioned elsewhere in this document, SG (sensor glucose) can refer to sensor-estimated BG (blood glucose), for example based on interstitial glucose. As shown in exemplary diagram 400, there can be multiple prediction thresholds 407a to 407c, such as 80 mg / dL, 70 mg / dL, and 60 mg / dL. The prediction threshold can be obtained from the user (e.g., via an input device) or be predetermined, below which the prediction system 302 can generate a raw hypoglycemia indication. Thus, for example, if the prediction threshold is selected to be 80 mg / dL, then because the final predicted BG value 410 (76 mg / dL) is below the prediction threshold of 80 mg / dL, the prediction system 302 can generate a raw hypoglycemia indication for a prediction time domain of 30 minutes. In other words, based on Figure 4 , an ML model such as the hypoglycemia ML model 310b may first generate a predicted BG value of 54 mg / dL based on an anchor prediction horizon of 60 minutes (using, for example, Figure 2A407a to 407c), then based on the predicted BG value, the prediction system 302 can generate a final predicted BG value of 76 mg / dL according to the target prediction horizon of 30 minutes (using, for example, analysis techniques such as interpolation 311b), and finally, the prediction system 302 can generate (or not generate) a raw hypoglycemia indication 304b based on whether the final predicted BG value 76 mg / dL is below a prediction threshold 306b (which can be one of the prediction thresholds 407a to 407c). In some cases, the hypoglycemia ML model 310b can determine the probability or likelihood of the accuracy of the ML predicted BG value 408, and only output the final predicted BG value 410 and whether it will cross a given threshold (e.g., 306b, e.g., 407a) if the probability of crossing the given threshold exceeds a probability threshold (e.g., at least 90%, 80%, 50%, etc.). In some cases, such as when the selected prediction horizon 308 is the same as the fixed time period for ML-based prediction based on the anchor prediction horizon, a raw hypoglycemia indication for a 60-minute prediction threshold may be generated. That is, if the anchor prediction horizon is the same as the target prediction horizon, interpolation may not be required.

[0065] On the other hand, if the prediction threshold 306 is selected by the user or otherwise set to 70 mg / dL, 60 mg / dL, or 55 mg / dL, then since the final predicted SG value of 76 mg / dL is above each of these thresholds, the original hypoglycemia indication for the 30-minute target prediction threshold may not be triggered. However, in some cases, since the ML-predicted BG is below the threshold of 55 mg / dL, an original hypoglycemia indication for the anchor (or target) prediction threshold of 60 minutes may be generated. Figure 4 Table 412 shown in depicts thresholds and indications that may be generated based on corresponding prediction horizons.

[0066] In some implementations, the comparison of the interpolated SG value to the threshold may not be as accurate. The final predicted BG value 410 may have a range associated with it, such as uncertainty, probability or error bars, or other indications (e.g., a heat map or probability distribution). If the range associated with the final predicted SG value 410 overlaps the threshold, such that the upper end of the range exceeds the threshold and the lower end of the range is below the threshold, then one of various types of indications or alerts may be generated. For example, a secondary indication or alert may be generated, where it does not indicate to the user that their BG will cross the threshold, but rather indicates the possibility or probability that it will cross the threshold (e.g., the user may see a yellow light instead of an orange light (depending on the probability), or a similar progressive or graded indication or alert). As another example, if the prediction system 302 determines that the final predicted BG value 410 and at least a majority of its range are below the threshold (e.g., after 40 minutes instead of 30 minutes, a majority of the error bars associated with the final predicted BG value 410 are below the threshold), the prediction system 302 may temporarily increase its target prediction horizon (e.g., from 30 minutes to 40 minutes) and provide the original indication. In another approach, the prediction system 302 may use overlap for later consideration. As mentioned above and discussed below, the exemplary architecture 300 may consider one or more additional criteria before generating and providing a final indication 320 to the user. Examples of providing a final indication 320 to the user may include, but are not limited to, providing a visual, tactile, and / or audio alert to the user (e.g., at one or more devices such as the delivery device 102, the monitoring device 104, the computing device 106, and / or a separate display or user interface associated with the user), providing a visual, tactile, and / or audio alert to a caregiver (e.g., on a similar device such as one or more of the aforementioned devices), providing a visual, tactile, and / or audio alert to a remote location (e.g., a server or cloud computing system 108). In some cases, the generated final indication 320 may be stored but not provided (e.g., as an alert). Such situations may occur based on, for example, settings, context information 318, and / or user preferences or settings 319, as will be further described below.

[0067] In some implementations, the error range of the final predicted BG value 410 may be another such additional criterion before generating the final indication 320. As another example, and as will be described below with respect to FIG. 5A to FIG. 5C Further discussed, the overlap may be used as an indication or alarm in a "hold" approach (e.g., if the range overlaps the threshold but the predicted BG value 410 is below the threshold), or a "partial" alarm (e.g., if the range overlaps the threshold but the predicted BG value 410 is above the threshold).

[0068] In other embodiments, corresponding curves may be fitted for other types of interpolation (e.g., exponential curves, logarithmic curves), and may be used as shown in FIG. Figure 4 The linear interpolation shown in generates a raw indication based on a selected threshold.

[0069] A similar approach as described above may be employed to generate the raw hyperglycemia indication 304a. More specifically, the hyperglycemia ML model 310a may predict the user's BG value at the end of a fixed time period based on an anchor prediction horizon. For example, (i) the hyperglycemia ML model 310a may be configured to determine a BG value of 120 mg / dL (with an associated probability or likelihood in some implementations) based on the anchor prediction horizon, (ii) the prediction system 302 may be configured to determine a final predicted BG value based on a target prediction horizon (e.g., using an analysis technique such as interpolation 311a), and (iii) the prediction system 302 may be configured to determine whether the final predicted BG value will cross a given threshold (e.g., at least one of the one or more prediction thresholds for hyperglycemia 306a). Depending on the determination of whether the predicted BG value will cross one or more selected prediction thresholds 306a for the selected prediction horizon 308, the prediction system 302 may output the raw hyperglycemia indication 304a. In some cases, the predicted BG value may have a probability or error range associated with it, which may be used in various ways before generating the final indication 320, as described above.

[0070] In some implementations, the prediction system 302 can "keep" a hyperglycemia prediction (at block 313a) or a hypoglycemia prediction (at block 313b) that would otherwise be output from the prediction system 302 as a raw hyperglycemia indication 304a or a raw hypoglycemia indication 304b. In various approaches, certain conditions may be required before the "kept" prediction is delivered as the raw hyperglycemia or hypoglycemia indication 304a or 304b. Using this approach, the sensitivity of the generated predictions can be maintained or adjusted to an appropriate or desired degree, and false positives can be advantageously reduced depending on the configuration. FIG. 5A to FIG. 5C A specific application of this "hold" approach is illustrated.

[0071] Reference Figure 5A , the two rows shown represent predictions made by the ML model, where if the predictions were not kept for further validation based on the conditions, the predictions would result in (or "trigger") the original hyperglycemia or hypoglycemia indication. In some implementations, these predictions can be generated using the prediction system 302. In some methods, interpolation 311a or 311b as discussed above can be implemented as part of generating the predictions. However, in some implementations, the predictions can be generated by the hyperglycemia ML model 310a or the hypoglycemia ML model 310b as discussed above and provided directly to the box 313a or 313b.

[0072] Figure 5AThe method in the example may be one in which two consecutive trigger predictions are a condition for the prediction system 302 (via blocks 313a or 313b) to generate an original high blood glucose indication 304a or low blood glucose indication 304b. In other words, two preliminary predictions (or "groups") are maintained to deliver the original indication 304a or 304b. Figure 5A As shown, the top row 502 includes two non-triggered predictions 504 (represented by open circles) and a triggered prediction 506 (represented by a solid circle). In a specific implementation where the prediction is not maintained, the triggered prediction 506 may result in a raw hyperglycemia or hypoglycemia indication as expected, as discussed elsewhere herein (e.g., with respect to Figure 3 or Figure 4 ). However, it can be seen in the bottom row 510 that if the prediction is maintained until the condition is met, the original indication may not be triggered by the corresponding prediction 516. Since two consecutive trigger predictions are required to meet the condition, once there are two trigger predictions 506' and the latest of these predictions is eligible for release, the original indication 518 is generated and released from box 313a or 313b. As noted elsewhere herein, the predictions can be generated at intervals such as every 5 minutes. Therefore, at 5 minute intervals, it will take at least 10 minutes to verify the prediction and generate the original indication 518. The original indication 518 is generated on the second trigger prediction, which in some embodiments can be in the form of an alert delivered to the user. It is also noted that this holding method can reduce the sensitivity of the prediction and reduce false positives, which can be adjusted and configured as desired. The following is another method that can further reduce sensitivity and false positives.

[0073] Now go to Figure 5B , illustrates the three-group retention, which is about Figure 5A A variation of the two-group hold discussed above. Here, the condition for generating the original indication may be three consecutive trigger predictions. The top row 512 shows three consecutively occurring trigger predictions 506' output from the prediction system 302 (e.g., via interpolation 311a or 311b) or from the hyperglycemia ML model 310a or the hypoglycemia ML model 310b. Since this meets the criteria established for the method using three-group hold, an original indication 518 is generated from box 313a or 313b on the third trigger prediction. As will be appreciated by those of ordinary skill in the relevant art, other similar conditions may be set, such as four or more consecutive trigger predictions. However, it should also be understood that overly stringent conditions may reduce the efficacy of providing a reliable indication of hypoglycemia or hyperglycemia to the user.

[0074] Figure 5Cis another variation of the hold method in which two trigger predictions within three previous predictions are conditional. Unlike the previous variations, this does not require consecutive trigger predictions. As shown in the top row 522, the trigger prediction 506' occurs first, followed by the non-trigger prediction 506, and then the second trigger prediction 506". Since it satisfies the "2 / 3 group hold" condition, the original indication 518 is generated on the second trigger prediction 506". This method verifies the predictions to a more relaxed degree than the previous method because it requires two trigger predictions within a given boundary (e.g., three predictions). Multiple variations of this method can be understood, such as two trigger predictions out of four previous predictions, three trigger predictions out of four previous predictions, three trigger predictions out of five previous predictions, and so on, depending on the desired sensitivity.

[0075] In some embodiments, maintenance of a prediction as described above may be an optional condition evaluated at blocks 313a and 313b to generate a raw high blood glucose indication 304a or a raw low blood glucose indication 304b, respectively.

[0076] In some scenarios, the exemplary architecture 300 may optionally coordinate (at block 316) raw hyperglycemia indications 304a and raw hypoglycemia indications 304b that are obtained simultaneously or substantially simultaneously (e.g., within a specified time of each other, such as 3 seconds). One or more of various types of rules may be applied for coordination. Depending on the low and high prediction thresholds selected by the user and / or depending on the prediction horizon, there may be situations where the prediction system 302 may predict and trigger both raw hyperglycemia indications 304a and raw hypoglycemia indications 304b simultaneously. For example, simultaneous raw hyperglycemia and hypoglycemia indications may result from prediction thresholds for hyperglycemia and hypoglycemia that are too similar, error ranges that overlap, target prediction horizons that are too short (not allowing for large changes between the anchor SG value 412 and the ML predicted BG value 408), or model errors. To coordinate such results, in some configurations, the preference may be to suppress the raw hyperglycemia indication 304b and allow the raw hypoglycemia indication 304a to continue and pass through as a single raw indication 317. In some configurations, the preference may be to suppress the raw hypoglycemia indication 304a and allow the raw hyperglycemia indication 304b to continue. Preferences may be pre-selected or provided according to the desired sensitivity level. For example, it may be known that the user is susceptible to hypoglycemia, in which case the prediction system 302 may be configured to preferably indicate the original hypoglycemia indication 304a if a simultaneous indication occurs. In some specific implementations, both the original hypoglycemia indication 304a and the original hyperglycemia indication 304b may be suppressed. Since the conflicting original indication may indicate that the original indication may not be reliable or immediately useful (e.g., it may indicate a normal blood sugar condition) for patient monitoring, if both original indications are suppressed, then an alarm may not be generated. However, in some specific implementations, both the original hypoglycemia indication 304a and the original hyperglycemia indication 304b may be allowed. In this case, the user may manually evaluate the two original indications to determine the next action. Alternatively, in some cases, the exemplary architecture 300 may use past historical patterns associated with the raw indications, probabilities or likelihoods associated with the raw indications, user activities (meals, insulin logs, exercise, etc.) in recent time periods to make them less likely to significantly affect the prediction, or other data to determine and / or generate likely outcomes (whether the raw hypoglycemia indication 304a is valid or the raw hyperglycemia indication 304b is valid) at block 316. However, as mentioned above, this coordination is optional and may not be performed (e.g., when no simultaneous raw indications occur).

[0077] In some embodiments, the aforementioned techniques for generating the final indication 320 may be performed at regular intervals (e.g., every 5 minutes according to the prediction threshold 306 and the prediction time horizon 308). In some embodiments, the final indication 320 may be generated on demand (e.g., with a user request for the prediction threshold 306 and the prediction time horizon 308 provided by the user or used according to an existing configuration).

[0078] However, there may be exceptions to the foregoing generation of final indication 320. In some implementations, final indication 320 can be at least temporarily suppressed based on contextual information 318 and / or user preferences or settings 319 (eg, in the form of an alert to the user).

[0079] For example, if contextual information 318 or an event such as a meal or insulin log is identified within a period of time (e.g., 15 minutes of anchor time 406), the final indication 320 (e.g., an alert to the user) may not be triggered for at least one upcoming interval (or indefinitely, e.g., until the next original indication) because the user may intervene to avoid drift and fluctuations in BG, thereby eliminating unnecessary alerts. In some cases, exercise or other physical activity performed by the user or the user's intake of medication or other substances may be detected (e.g., using a physiological monitor or sensor). In this case, the final indication 320 may not be triggered for at least one upcoming interval (or indefinitely) because physiological changes (e.g., higher metabolism or energy expenditure) may affect the user's BG. In some scenarios, if a change in the anchor SG is detected to exceed a certain amount or percentage within the above time period (e.g., 15 minutes), the final indication 320 may not be triggered.

[0080] As another example of an exception, the final indication 320 or other alert may be suppressed depending on one or more settings 319 of the user, such as a pause setting that temporarily or indefinitely (e.g., until enabled again) prevents or disables indications or alerts from being given to the user, or an alert schedule that regularly allows alerts during certain times and / or prevents alerts during certain times. In some implementations, any indication or alert that would have been provided if a pause was in effect may be discarded, or any indication or alert that would have been provided may be saved and provided after the pause setting is disabled or has expired.

[0081] To synthesize and summarize the various methods and techniques described above, in one illustrative example scenario, the prediction system 302 may receive inputs including: one or more prediction thresholds 306, including one or more prediction thresholds 306a for hyperglycemia and one or more prediction thresholds 306b for hypoglycemia, and one or more prediction time horizons 308. Two (or more) ML models (e.g., a hyperglycemia ML model 310a and a hypoglycemia ML model 310b) may receive SG readings from a monitoring device 312 (CGM is one example). Based on the SG readings and the outputs of the two (or more) ML models (e.g., ML predicted BG values ​​at the end of a fixed time period, or a binary prediction of crossing a threshold within a fixed time period), the prediction system 302 may output and provide a prediction as to whether the user's BG level will cross one or more selected prediction thresholds 306 over a selected prediction time horizon 308. If the prediction of the prediction system 302 is a hyperglycemia prediction that BG will exceed the prediction threshold, a raw hyperglycemia indicator 304a may be generated. If the prediction of the prediction system 302 is a hypoglycemia prediction that BG will be below the prediction threshold, a raw hypoglycemia indicator 304b may be generated. The raw indication may be binary (yes or no). In some implementations, a binary raw indication may be generated for each of the one or more prediction thresholds 306. Assuming there are no conflicting predictions to be reconciled (at box 316), no uncertainty overlap, and no exceptions such as contextual information 318 (e.g., meals, insulin logs, activities that may cause excursions) or user settings 319, a final indication 320 may be generated, for example, in the form of an alert or notification to the user.

[0082] In some embodiments, for example, if neither a hyperglycemia nor a hypoglycemia prediction is made, a normoglycemia (normal blood glucose concentration) prediction may be generated and / or provided, although this may be simply assumed in the absence of a hyperglycemia or hypoglycemia prediction, indication, or alert to the user.

[0083] In another illustrative example scenario, the prediction system 302 may receive an anchor prediction horizon and / or a target prediction horizon (among one or more prediction horizons 308). For example, the anchor prediction horizon may be 60 minutes, and the target prediction horizon may be shorter, such as 30 minutes. The prediction system 302 may perform an analysis technique (e.g., interpolation 311a or 311b) such as interpolation (linear interpolation, exponential interpolation, etc. or a combination thereof) based on the anchor prediction horizon to predict the final SG value 410. The raw indication 304a or 304b at the target prediction horizon may depend on whether the final SG value 410 is below or above one or more prediction thresholds 306. In some implementations, a binary raw indication may be generated for each of the one or more prediction thresholds 306. The anchor prediction horizon may be the same as the fixed time period used to generate the BG value for the ML prediction (e.g., 60 minutes). However, the fixed time period, and therefore the anchored prediction horizon, may be changed for future predictions made by the ML models 310a , 310b and / or the prediction system 302 .

[0084] In another illustrative example scenario, before releasing a qualified prediction as an original indication 304a or 304b (e.g., at block 313a or 313b), two or more preliminary predictions may be retained to evaluate whether they meet the conditions (e.g., two or three triggering predictions). In this way, the predictions may require further verification and confirmation before being provided to the user (which may, for example, reduce false positives).

[0085] As mentioned above, the prediction system 302 and / or other portions of the prediction system component 301 may be implemented on various devices, such as the delivery device 102, the monitoring device 104, or the computing device 106. For example, in a specific implementation on the computing device 106, the computing device 106 may be a mobile device (e.g., a smart phone) that may receive inputs such as SG measurements (e.g., from the monitoring device 312 and / or elsewhere) and perform the aforementioned functions, such as (but not limited to) performing analysis techniques (e.g., interpolation 311a or 311b), maintaining predictions (box 313a or 313b), reconciling conflict predictions (box 316), evaluating context information or user settings (box 318 or 319), and generating a final indication (320) and / or providing an alert or notification to the user.

[0086] In some specific implementations, the exemplary architecture 300 can be implemented (e.g., as an App) on a user device (e.g., a smart phone) and can be used for multiple daily injection (MDI) therapy, which involves delivering insulin to a patient multiple times (e.g., three or more times) per day. For example, the user device can receive input from a monitoring device 312 and generate a final indication 320 to warn the patient or caregiver of a prediction of a future high sensor glucose event, so that a bolus of insulin (e.g., rapid-acting or short-acting) can be advantageously administered actively and flexibly throughout the day (e.g., at night, between meals) as needed, rather than strictly in a fixed dose and fixed schedule. Similarly, the user can be warned of a prediction of a future low sensor glucose event to offset carbohydrates.

[0087] Exemplary Methods

[0088] Figure 6 6 is a flow chart of an example of a method 600 for predicting a physiological condition of a user according to one or more embodiments. The method 600 may be performed by one or more devices (e.g., device 102, device 104, device 106, and / or system 108). Each of the one or more devices may include hardware and / or software components, such as, for example, one or more processors (e.g., microcontrollers and / or microprocessors) and / or one or more processor-readable media storing instructions that, when executed by the one or more processors, result in the performance of one or more operations. Fig.10 6 illustrates exemplary components of one or more devices, which will be described in more detail below. It should also be noted that method 600 can be performed in any suitable order, not necessarily in the order in which the method 600 is performed. Figure 6 In addition, method 600 may include Figure 6 More or fewer operations may be performed as described herein.

[0089] At block 610 , method 600 may include obtaining inputs including one or more prediction thresholds and one or more prediction horizons.

[0090] At block 620 , method 600 may include estimating a blood glucose level of the user based on the one or more predicted time domains and based on one or more sensor glucose values ​​determined from an interstitial glucose level measured from the user.

[0091] At block 630, method 600 may include generating a prediction of the user's physiological condition based on the estimated blood glucose level of the user and the one or more prediction thresholds. In some embodiments, an indication of the prediction may be provided to the user, for example, via a display or user interface associated with the user, such as at one or more devices such as delivery device 102, monitoring device 104, and / or computing device 106. In some cases, the alert may be provided elsewhere (e.g., at a location remote from the user, such as a server, remote or cloud computing system 108, or a caregiver's location) or stored for later analysis or provision (e.g., if the alert is paused).

[0092] In some embodiments, the prediction may be a binary output (e.g., yes or no, 1 or 0), and the user's physiological condition may be hyperglycemia or hypoglycemia. In some cases, for example, if neither a hyperglycemia prediction nor a hypoglycemia prediction is made, a normoglycemia prediction may be generated and / or provided, although this may be simply assumed in the absence of a prediction, indication, or alert of hyperglycemia or hypoglycemia for the user.

[0093] As mentioned above about Figures 3 to 5C As discussed, predictions may be generated and / or qualified based on various one or more factors.

[0094] Figure 7 is a flowchart of another example of a method 700 for predicting a physiological condition of a user according to one or more embodiments. The method 700 may be performed by one or more devices (e.g., device 102, device 104, device 106, and / or system 108). Each of the one or more devices may include hardware and / or software components, such as, for example, one or more processors (e.g., microcontrollers and / or microprocessors) and / or one or more processor-readable media storing instructions that, when executed by the one or more processors, result in the performance of one or more operations. Fig.10 , which will be described in more detail below. It should also be noted that method 700 may be performed in any suitable order, not necessarily in the order in which the method 700 is performed. Figure 7 In addition, method 700 may include comparing Figure 7 More or fewer operations may be performed as described herein.

[0095] At block 710, method 700 may include obtaining one or more glucose concentration values ​​measured from a user. In some embodiments, the glucose concentration value may include an interstitial glucose level of the user measured by a sensor. The interstitial glucose level may be the basis for determining the sensor glucose (SG) value referred to herein.

[0096] At box 720, method 700 may include using multiple glucose concentration values ​​to estimate a first blood glucose value of the user within a predetermined length of time. In some embodiments, the predetermined length of time may be relative to when the first blood glucose value is estimated. In some embodiments, the estimation of the first blood glucose value of the user within the predetermined length of time may be performed at a specified interval (e.g., every 5 minutes). In some embodiments, the estimation of the first blood glucose value of the user within the predetermined length of time may include using a first trained machine learning model or a second trained machine learning model to estimate the first blood glucose value of the user; the first trained machine learning model may be trained to predict whether the user's future blood glucose value will be lower than one or more first thresholds in the prediction thresholds within a predetermined length of time; the second trained machine learning model may be trained to predict whether the user's future blood glucose value will exceed one or more second thresholds in the prediction thresholds within a predetermined length of time. In some embodiments, the first and second trained machine learning models may each include a classifier that is trained to at least determine the probability that the user's future blood glucose breaks through one or more first thresholds or one or more second thresholds within a predetermined length of time.

[0097] At block 730, method 700 may include obtaining a forecast horizon less than a predetermined length of time, a first threshold level, and a second threshold level. In some embodiments, the predetermined length of time may be 60 minutes, and the forecast horizon may be less than 60 minutes (or other time period less than the predetermined length of time). It will be appreciated that various other time ranges may be selected, as discussed above.

[0098] At box 740, method 700 may include estimating a second blood glucose value of the user in the prediction time domain based on the first blood glucose value and a first machine learning model trained to determine whether the user's blood glucose level will be below a first threshold level in the prediction time domain or based on the first blood glucose value and a second machine learning model trained to determine whether the user's blood glucose level will be above a second threshold level in the prediction time domain. In some specific implementations, the first ML model may be an example of ML model 200, and the second ML model may be an example of ML model 250. In some specific implementations, the method may also include generating an indication that the second blood glucose value will break through the first threshold level or the second threshold level in the prediction time domain based on the second blood glucose value being below the first threshold level or above the second threshold level. In some specific implementations, the method may also include obtaining the prediction time domain, the first threshold level, and the second threshold level from the user. In some embodiments, the estimation of the second blood glucose value of the user in the prediction time domain may include interpolating using the first glucose value and at least one glucose concentration value of the one or more glucose concentration values. In some specific implementations, the interpolation may include linear interpolation between the first glucose value and the at least one glucose concentration value.

[0099] At block 750, method 700 may include generating a prediction of a physiological condition of the user based at least on the estimated second blood glucose value. For example, in some scenarios, the estimated second blood glucose value may be below a first threshold level, which may indicate, for example, hypoglycemia. In some scenarios, the estimated second blood glucose value may be above a second threshold level, which may indicate, for example, hyperglycemia. In some cases, a binary determination may be generated to indicate a physiological condition (e.g., yes / no for hypoglycemia or yes / no for hyperglycemia).

[0100] In some embodiments, the method may further include providing an alert to the user indicating the generated prediction of the physiological condition. For example, the alert may be provided on a display or user interface associated with the user, such as at one or more devices such as the delivery device 102, the monitoring device 104, and / or the computing device 106. In some cases, the alert may be provided elsewhere (e.g., a location remote from the user, such as a server, a remote or cloud computing system 108, or a caregiver's location) or stored for later analysis or provision (e.g., if the alert is paused). However, in some embodiments, the method may further include generating an alert indicating the generated prediction of the physiological condition; and suppressing the alert to prevent delivery of the alert to the user based on a contextual event, a user setting, or a combination thereof.

[0101] In some embodiments, the generation of a prediction of the user's physiological condition may include: generating a plurality of preliminary predictions based on the estimated second blood glucose value and one or more prediction thresholds, and determining that the plurality of preliminary predictions satisfy a condition. In some implementations, the condition may include that the plurality of preliminary predictions are triggered continuously, or that at least a portion of the plurality of preliminary predictions are triggered such that the original indication of the predictions is "held" at the same time. In some embodiments, the generation of a prediction of the user's physiological condition may include generating a first prediction associated with a first physiological condition and a second prediction associated with a second physiological condition, and coordinating the first prediction and the second prediction based on a rule (e.g., based on block 316).

[0102] In some cases, the physiological condition of the user may be hyperglycemia, while in some other cases, the physiological condition of the user may be hypoglycemia. In some embodiments, the one or more prediction thresholds may include a plurality of prediction thresholds, and generating a prediction of the physiological condition of the user may include generating a corresponding prediction of the physiological condition of the user for each of the plurality of prediction thresholds.

[0103] Figure 88 is a flowchart of another example of a method 800 for predicting a physiological condition of a user according to one or more embodiments. The method 800 may be performed by one or more devices (e.g., device 102, device 104, device 106, and / or system 108). Each of the one or more devices may include hardware and / or software components, such as, for example, one or more processors (e.g., microcontrollers and / or microprocessors) and / or one or more processor-readable media storing instructions that, when executed by the one or more processors, result in the performance of one or more operations. Fig.10 800 illustrates exemplary components of one or more devices, which will be described in more detail below. It should also be noted that method 800 can be performed in any suitable order, not necessarily in the order of Figure 8 In addition, method 800 may include Figure 8 More or fewer operations may be performed as described herein.

[0104] At block 810, method 800 may include obtaining one or more glucose concentration values ​​measured from a user. In some embodiments, the one or more glucose concentration values ​​may be obtained based on an interstitial glucose level of the user measured with a sensor device.

[0105] At block 820 , method 800 may include applying a first glucose prediction model for a first prediction horizon to the one or more glucose concentration values ​​measured from the user.

[0106] At block 830, method 800 may include obtaining a first predicted glucose value for a user based on applying a first glucose prediction model. In some embodiments, the first prediction time domain may be relative to when the first predicted glucose value is obtained. In some embodiments, obtaining the first predicted glucose value for a user may be performed at specified intervals.

[0107] In some embodiments, obtaining the first predicted glucose value of the user may include estimating the first predicted glucose value of the user using the first glucose prediction model and the second glucose prediction model; one of the first glucose prediction model or the second glucose prediction model may be trained to predict whether the future blood glucose value of the user will be lower than one or more first thresholds within the first prediction time domain; and the other of the first glucose prediction model or the second glucose prediction model may be trained to predict whether the future blood glucose value of the user will exceed one or more second thresholds within the first prediction time domain. In some specific implementations, the first glucose prediction model and the second glucose prediction model may each include a classifier that is trained to at least determine the probability that the future blood glucose value of the user will exceed the one or more first thresholds or the one or more second thresholds within the first prediction time domain.

[0108] At box 840, method 800 may include predicting a second predicted glucose value for the user based on the first predicted glucose value and at least one of the one or more glucose concentration values ​​for a second predicted time domain that is less than the first predicted time domain. In some embodiments, the first predicted time domain may be 60 minutes, and the second predicted time domain may be less than 60 minutes. In some embodiments, the prediction of the second glucose value of the user within the predicted time domain may include interpolating using the first predicted glucose value and at least one of the one or more glucose concentration values. In some specific implementations, the interpolation may include linear interpolation between the first predicted glucose value and the at least one glucose concentration value.

[0109] In some embodiments, method 800 may further include generating a notification predicting that the predetermined threshold level is breached within the second prediction time domain based on the second predicted glucose value breaching the predetermined threshold level. In some specific implementations, method 800 may further include suppressing notifications to prevent delivery of notifications to the user based on contextual events, user settings, or a combination thereof.

[0110] In some embodiments, method 800 may also include obtaining a first prediction threshold or a second prediction threshold; and generating a prediction of the user's physiological condition based on the predicted second glucose value and the first prediction threshold or the second prediction threshold. In some specific implementations, the second prediction time domain, the first prediction threshold, and the second prediction threshold may be obtained from the user.

[0111] In some embodiments, method 800 may also include generating a prediction of the user's physiological condition, the generation of the prediction comprising: generating a plurality of preliminary predictions based on the predicted second glucose value and one or more prediction thresholds, and determining that the plurality of preliminary predictions satisfy a condition. In some specific implementations, the condition may include that the plurality of preliminary predictions are triggered continuously, or at least a portion of the plurality of preliminary predictions are triggered.

[0112] In some embodiments, method 800 may also include generating a prediction of the user's physiological condition, wherein the generation of the prediction includes generating a first prediction associated with the first physiological condition and a second prediction associated with the second physiological condition, and coordinating the first prediction and the second prediction based on a rule (e.g., based on box 316).

[0113] Exemplary Devices

[0114] In some embodiments, therapy can be administered based on transmitting a therapy determination result toward a therapy delivery device. Fig. 9 One non-limiting example of such a device is described.

[0115] As described above, the results of the therapy determination can be transmitted toward the insulin delivery device 900 (e.g., from the cloud computing system 108, via the intermediate computing device 106 that is communicatively coupled to the device 90). In such devices, insulin delivery can be performed based on internal communications between a central computing module (e.g., a microcontroller for the entire device 900) and an insulin delivery module (e.g., including the microcontroller, motor, and pump). For example, insulin delivery can be caused by the central computing module transmitting a delivery command in the form of an electrical signal that travels to the insulin delivery module via a communication structure. The central computing module can also be configured to communicate with a remote or cloud computing system (e.g., a microcontroller that is communicatively coupled to the insulin delivery module). Figure 1 108) of the computing device (e.g., Figure 1 106) communication (eg, via a transceiver). According to the techniques described herein, the insulin delivery device 900 can transmit various event data toward a remote or cloud computing system, and the remote or cloud computing system can transmit insulin delivery determination results toward the insulin delivery device 900.

[0116] The insulin delivery device 900 can provide fast-acting insulin through a small tube 910, which is configured to be connected to a cannula inserted subcutaneously. The device 900 can deliver two types of doses: a basic dose, which can be delivered in micro-amounts periodically (e.g., every five minutes) throughout the day and night; and a bolus dose to cover the blood sugar increase caused by a meal and / or to correct high blood sugar levels. The depicted insulin delivery device 900 includes a user interface with a button element 920, which can be manipulated to administer insulin boluses, change therapy settings, change user preferences, and select display features, etc. The insulin delivery device 900 also includes a display device 930 that can be used to present various types of information or data to the user. According to various aspects of the present disclosure, the user of the insulin delivery device 1200 can use the button element 920 to enter certain event data (e.g., event type, event start time, event details, etc.), and can use the display device 930 to confirm the user input. Fig. 9 The depicted insulin delivery device 900 is provided by way of example only, and other types of insulin delivery devices and other technologies than those described above are considered to be within the scope of the present disclosure.

[0117] Fig.10 is a block diagram of an embodiment of a computer system 1000 that may be utilized in embodiments as described herein. It should be noted that Fig.10 It is intended only to provide a generalized illustration of the various components, any or all of which may be utilized as appropriate. Fig.10The components shown may be localized to a single device (eg, delivery device 102, monitoring device 104, computing device 106, or computing system 108) and / or distributed among various networked devices that may be arranged at different geographic locations.

[0118] In some embodiments, the computer system 1000 may include hardware elements that may be electrically coupled via a bus (or may communicate in other ways as appropriate). The hardware elements may include a processor 1010, which may include, but is not limited to, one or more microcontrollers, one or more microprocessors, one or more general-purpose processors, one or more special-purpose processors (such as digital signal processing chips, graphics acceleration processors, etc.), and / or other processing structures that may be configured to perform one or more of the methods or functions described herein.

[0119] In some embodiments, the computer system 1000 may further include one or more input devices 1015, which may include but are not limited to a button element 920, a microphone, a glucose sensor, etc. The computer system 1000 may also include one or more output devices 1020, which may include but are not limited to a display device (e.g., 930), a speaker, a buzzer, etc.

[0120] In some embodiments, the computer system 1000 may also include one or more non-transitory storage devices 1025, which may include, but are not limited to, local and / or network accessible storage devices, and / or may include, but are not limited to, disk drives, drive arrays, optical storage devices, solid-state storage devices such as programmable flash-updatable read-only memory ("RAM") and / or read-only memory ("ROM"), etc. Such storage devices may be configured to implement any suitable data storage, including, but not limited to, various file systems, database structures, etc. Such data storage may include databases and / or other data structures for storing and managing messages and / or other information to be sent to one or more other components or external devices.

[0121] In some embodiments, the computer system 1000 may also include a communication subsystem 1030 that may implement wireless communication technologies managed and controlled by the wireless communication interface 1033. Additionally or alternatively, the communication subsystem 1030 may implement wired technologies (such as Ethernet, coaxial communications, universal serial bus (USB), etc.). The wireless communication interface 1033 may include one or more wireless transceivers that may send and receive wireless signals (e.g., according to Bluetooth Low Energy (BLE) signals). Therefore, the communication subsystem 1030 may include a modem, a network card (wireless or wired), an infrared communication device, a wireless communication device and / or a chipset, etc., which can enable the computer system 1000 to communicate with related Figure 1 Any device communication discussed, including the delivery device 102, monitoring device 104, computing device 106, and / or cloud computing system 108 as described herein. Thus, the communication subsystem 1030 can be used to receive and send data (eg, SG, BG) as described in the embodiments herein.

[0122] In some embodiments, the computer system 1000 will also include a working memory 1035, which may include a RAM or ROM device, as described above. The software elements shown as being located within the working memory 1035 may include computer-readable and computer-executable instructions 1040; device drivers; executable libraries; and / or other codes, which may include computer programs used in various embodiments and / or may be designed to implement the methods and / or configuration systems according to the embodiments described herein. By way of example only, one or more operations described with respect to the methods or functions discussed above may be implemented as codes and / or instructions that can be executed by a computer (and / or a processor within a computer). Such codes and / or instructions may be used to configure and / or adapt a general-purpose computer (or other device) to perform one or more operations according to the described methods.

[0123] In some embodiments, these instruction sets and / or code sets may be stored on a non-transitory computer-readable storage medium such as the storage device 1025 described above. In some cases, the storage medium may be incorporated into a computer system such as the computer system 1000. In other embodiments, the storage medium may be separate from the computer system (e.g., a removable medium such as an optical disk), and / or provided in a downloadable installation package so that the storage medium can be used to program, configure, and / or adapt a general-purpose computer having the instructions and / or code stored thereon. These instructions may take the form of executable code that can be executed by the computer system 1000, and / or may take the form of source code and / or installable code that takes the form of executable code when compiled (e.g., using any of a variety of commonly available compilers, installers, compression / decompression utilities, etc.) and / or installed on the computer system 1000.

[0124] Each embodiment disclosed herein is an example of the present disclosure and can be embodied in various forms. For example, although some embodiments herein are described as separate embodiments, each of these embodiments herein can be combined with one or more of the other embodiments herein. The specific structural and functional details disclosed herein should not be construed as restrictive, but as the basis of the claims, and as a representative basis for teaching those skilled in the art to use the present disclosure differently with almost any suitable detailed structure. In the entire description of the drawings, similar reference numerals may refer to similar elements.

[0125] Any of the techniques, operations, methods, programs, algorithms or codes described herein may be converted to or expressed in a programming language or computer program embodied on a computer, processor or machine-readable medium. As used herein, the terms "programming language" and "computer program" each include any language for specifying instructions for a computer or processor, and include (but are not limited to) the following languages ​​and their derivatives: assembler, Basic, Batch file, BCPL, C, C+, C++, Delphi, Fortran, Java, JavaScript, machine code, operating system command language, Pascal, Perl, PL1, Python, scripting language, visual Basic, meta-language self-specified programming and all first, second, third, fourth, fifth or higher generation computer languages. Also included are databases and other data models and any other meta-languages. No distinction is made between interpretation, compiled languages ​​or languages ​​that use both compilation and interpretation methods. No distinction is made between compiled and source versions of a program. Therefore, references to programs that can exist in more than one state (such as source, compiled, target or linked) of a programming language are references to any and all such states. References to procedures may cover the actual instructions and / or the intent of those instructions.

[0126] It should be understood that the foregoing description only illustrates the present disclosure. To the extent consistent, any or all aspects described in detail herein may be used in combination with any or all other aspects described in detail herein. Without departing from the present disclosure, those skilled in the art may design various alternatives and modifications. Therefore, the present disclosure is intended to cover all such alternatives, modifications and variations. The embodiments described with reference to the accompanying drawings are presented only to show certain examples of the present disclosure. Other elements, steps, methods and techniques that are not significantly different from those described above and / or in the appended claims are also intended to be included within the scope of the present disclosure.

[0127] Although several embodiments of the present disclosure have been shown in the accompanying drawings, it is not intended to limit the present disclosure thereto, as it is intended that the present disclosure be as broad as the art will allow and the specification should be read in the same manner. Therefore, the above description should not be construed as limiting, but merely as an illustration of a specific embodiment. Those skilled in the art will be able to envision other modifications within the scope and spirit of the claims appended hereto.

Claims

1. A processor-implemented method, the method comprising: obtaining one or more glucose concentration values ​​measured from a user; applying a first glucose prediction model for a first prediction horizon to the one or more glucose concentration values ​​measured from the user; Based on applying the first glucose prediction model, obtaining a first predicted glucose value of the user; as well as A second predicted glucose value of the user is predicted for a second prediction time horizon that is less than the first prediction time horizon based on the first predicted glucose value and at least one of the one or more glucose concentration values. 2 . The method of claim 1 , further comprising generating a notification predicting that the predetermined threshold level will be breached within the second prediction time horizon based on the second predicted glucose value breaching the predetermined threshold level.

3. The method according to claim 2, further comprising: The notification is suppressed to prevent delivery of the notification to the user based on a contextual event, a user setting, or a combination thereof.

4. The method according to claim 1, further comprising: Obtaining a first prediction threshold or a second prediction threshold; as well as A prediction of the user's physiological condition is generated based on the predicted second glucose value and the first prediction threshold or the second prediction threshold. The method according to claim 4 , wherein the second prediction time domain, the first prediction threshold and the second prediction threshold are obtained from the user. The method of claim 1 , wherein the first prediction time domain is relative to when the first predicted glucose value is obtained. The method according to claim 1 , wherein obtaining the first predicted glucose value of the user is performed at regular intervals.

8. The method of claim 1, wherein: The obtaining of the first predicted glucose value of the user comprises estimating the first predicted glucose value of the user using the first glucose prediction model and the second glucose prediction model; One of the first glucose prediction model or the second glucose prediction model is trained to predict whether a future blood glucose value of the user will be below one or more first thresholds within the first prediction horizon; and The other of the first glucose prediction model or the second glucose prediction model is trained to predict whether the future blood glucose value of the user will exceed one or more second thresholds within the first prediction horizon.

9. The method of claim 8, wherein the first glucose prediction model and the second glucose prediction model each comprise a classifier, wherein the classifier is trained to at least determine a probability that the future blood glucose value of the user will exceed the one or more first thresholds or the one or more second thresholds within the first prediction time domain.

10. The method of claim 1, wherein the one or more glucose concentration values ​​are obtained based on interstitial glucose levels of the user measured with a sensor device.

11. The method of claim 1, wherein predicting the second glucose value of the user in the prediction time domain comprises interpolating using the first predicted glucose value and the at least one glucose concentration value of the one or more glucose concentration values.

12. The method of claim 11, wherein the interpolating comprises linear interpolation between the first predicted glucose value and the at least one glucose concentration value.

13. The method of claim 1 , further comprising generating a prediction of the user's physiological condition, the generating of the prediction comprising: A plurality of preliminary predictions are generated based on the predicted second glucose value and one or more prediction thresholds, and a determination is made that the plurality of preliminary predictions satisfy a condition. 14 . The method according to claim 13 , wherein the condition comprises that the plurality of preliminary predictions are triggered consecutively, or at least a part of the plurality of preliminary predictions are triggered.

15. The method of claim 1 further comprising generating a prediction of the user's physiological condition, the generating of the prediction comprising generating a first prediction associated with a first physiological condition and a second prediction associated with a second physiological condition, and coordinating the first prediction and the second prediction based on a rule.

16. The method of claim 1, wherein the first prediction horizon is 60 minutes and the second prediction horizon is less than 60 minutes.

17. A system comprising: one or more processors; as well as One or more processor-readable media storing instructions that, when executed by the one or more processors, cause the following operations to be performed: obtaining one or more glucose concentration values ​​measured from a user; using the one or more glucose concentration values ​​to estimate a first blood glucose value of the user over a predetermined length of time; obtaining a predicted time domain less than the predetermined time length, a first threshold level, and a second threshold level; estimating a second blood glucose value of the user in the prediction time domain based on the first blood glucose value and a first machine learning model trained to determine whether the blood glucose level of the user will be below the first threshold level in the prediction time domain or based on the first blood glucose value and a second machine learning model trained to determine whether the blood glucose level of the user will be above the second threshold level in the prediction time domain; as well as A prediction of the user's physiological condition is generated based at least on the estimated second blood glucose value.

18. The system of claim 17, wherein: The first machine learning model is configured to: outputting a first raw indication of the second blood glucose value of the user based on at least one of the one or more glucose concentration values, the first blood glucose value of the user, the first threshold level, the predicted time horizon, or a combination thereof; and generating the prediction of the physiological condition of the user based on the first raw indication of the second blood glucose value of the user, wherein the physiological condition is hyperglycemia; and The second machine learning model is configured to: outputting a second raw indication of the second blood glucose value of the user based at least on the at least one of the one or more glucose concentration values, the first blood glucose value of the user, the second threshold level, the predicted time horizon, or a combination thereof; and The prediction of the physiological condition of the user is generated based on the second raw indication of the second blood glucose value of the user, wherein the physiological condition is hypoglycemia.

19. The system of claim 18, wherein: The first machine learning model is further configured to generate the first raw indication based at least on an interpolation between the at least one of the one or more glucose concentration values ​​and the first blood glucose value of the user; The second machine learning model is further configured to generate the second raw indication based at least on an interpolation between the at least one of the one or more glucose concentration values ​​and the first blood glucose value of the user; The one or more processor-readable media store instructions that, when executed by the one or more processors, further cause the following operations: providing the prediction of the physiological condition of the user to the user.

20. One or more non-transitory processor-readable storage media storing instructions that, when executed by one or more processors, cause the following operations to be performed: obtaining one or more glucose concentration values ​​measured from a user; applying a first glucose prediction model for a first prediction horizon to the one or more glucose concentration values ​​measured from the user; Based on applying the first glucose prediction model, obtaining a first predicted glucose value of the user; as well as A second predicted glucose value of the user is predicted for a second prediction time horizon that is less than the first prediction time horizon based on the first predicted glucose value and at least one of the one or more glucose concentration values.

Images