Infusion site fault detection
By applying machine learning models to analyze physiological glucose and insulin delivery data in the insulin delivery system, the inaccurate insulin delivery caused by infusion site failure is solved, and more accurate blood sugar control and higher system reliability are achieved.
Patent Information
- Application Number
- CN202380073034.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2022-09-02
- Filing Date
- 2023-08-31
- Publication Date
- 2025-05-27
AI Technical Summary
In existing insulin delivery systems, the infusion site may become less effective and ineffective over time, resulting in inaccurate insulin delivery and affecting blood sugar control in diabetic patients.
Using a machine learning-based approach, predictive data are generated to determine the status of the infusion site by entering physiological glucose data and insulin delivery data into the trained regression model and XGBoost model, and alerts are displayed on the graphical user interface.
Effectively predict the failure status of the infusion site, reduces the health risks caused by patients due to hyperglycemia, and improves the reliability and patient experience of the insulin delivery system.
Smart Images

Figure CN120051830A_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to detecting problems regarding a drug infusion site. Background Art
[0002] It has been demonstrated that subcutaneous insulin replacement therapy is the preferred regimen for controlling diabetes. Insulin is administered via multiple daily injections or an infusion pump, where the dose is informed by capillary glucose measurements performed several times a day with a blood glucose meter. It is known that this traditional method is not perfect because the variability on a daily (and in fact moment-to-moment) basis can be significant. Additionally, this method can be burdensome for patients as it requires repeated finger pricks, strict monitoring of food intake, and vigilant control of insulin delivery. The advent of glucose measurement devices such as continuous glucose monitors has created the possibility for the development of insulin delivery systems such as closed-loop systems that can automatically calculate and adjust the insulin delivery amount in response to the measured glucose level. Summary of the Invention
[0003] An insulin delivery system can deliver a calculated insulin delivery amount using an infusion device coupled to a patient's body at an infusion site. However, over time, the site where the infusion device is located may become less effective and fail. Accordingly, certain embodiments of the present disclosure are directed to systems, methods, and devices for detecting infusion site failures.
[0004] In Example 1, a method for predicting the status of an infusion site includes applying a regression model to physiological glucose data and insulin delivery data to generate prediction data. The method further includes operating a trained machine learning model to process the prediction data, thereby generating an output. The method further includes determining, based on the output, that the infusion site has failed or is likely to have failed.
[0005] In Example 2, the method according to Example 1 further includes: generating an alarm signal indicating that the infusion site has failed, and displaying the alarm on a graphical user interface in response to the alarm signal.
[0006] In Example 3, the method according to any of the preceding examples, wherein the physiological glucose data and insulin delivery data are aggregated over a period starting from the first use of the infusion site.
[0007] In Example 4, the method according to Example 3 further includes: calculating a linear regression based on the aggregated physiological glucose data and insulin delivery data, wherein the prediction data is at least partially based on the linear regression.
[0008] In Example 5, the method according to any of the preceding examples, wherein the output is a value indicating the likelihood of infusion site failure.
[0009] In Example 6, according to the method of any of the foregoing examples, wherein the physiological glucose data and insulin delivery data are updated and aggregated according to a set schedule.
[0010] In Example 7, according to the method of any of the foregoing examples, wherein the prediction data includes p-values of selected metrics.
[0011] In Example 8, according to the method of Example 7, wherein the selected metrics include metrics selected from a metric category including physiological glucose variability and physiological glucose.
[0012] In Example 9, according to the method of Example 7 or 8, wherein the selected metrics include: time above range, hypoglycemia index, total bolus, standard deviation, coefficient of variation, and instability index.
[0013] In Example 10, according to the method of any of the foregoing examples, wherein the trained machine learning model is an XGBoost model.
[0014] In Example 11, according to the method of any of the foregoing examples, wherein the trained machine learning model is customized for the patient by retraining the machine learning model using the patient's previous physiological glucose data and insulin delivery data.
[0015] In Example 12, according to the method of any of the foregoing examples, further comprising: updating a status icon associated with an infusion site on a user interface based on the output.
[0016] In Example 13, a computer program product comprising instructions that cause one or more processors to perform the steps of the method according to Examples 1-12.
[0017] In Example 14, a computer-readable medium having stored thereon the computer program product according to Example 13.
[0018] In Example 15, a computer includes the computer-readable medium according to Example 14.
[0019] In Example 16, a method for predicting the status of an infusion site, comprising applying a regression model to physiological glucose data and insulin delivery data using an electronic controller to generate prediction data. The method further comprises operating a trained machine learning model using the electronic controller to process the prediction data to generate an output. The method further comprises determining by the electronic controller based on the output that the infusion site has failed or is likely to have failed.
[0020] In Example 17, the method according to Example 1 further includes: generating an alarm signal indicating that the infusion site has failed, and displaying an alarm on a graphical user interface in response to the alarm signal.
[0021] In Example 18, the method according to any one of the foregoing examples, wherein the physiological glucose data and insulin delivery data are aggregated over a period starting from the first use of the infusion site.
[0022] In Example 19, the method according to Example 3 further includes: calculating a linear regression based on the aggregated physiological glucose data and insulin delivery data, wherein the predicted data is at least partially based on the linear regression.
[0023] In Example 20, a non-transitory computer-readable medium includes instructions that cause a hardware processor to perform the following operations: (1) applying a regression model to physiological glucose data and insulin delivery data to generate predicted data, (2) operating a trained machine learning model to process the predicted data, thereby generating an output, and (3) determining, based on the output, that the infusion site has failed or is likely to have failed.
[0024] In Example 21, the non-transitory computer-readable medium according to Example 20, wherein the output is a value indicating the likelihood of infusion site failure.
[0025] In Example 22, the non-transitory computer-readable medium according to Example 20, wherein the selected metrics include metrics selected from a class of metrics including physiological glucose variability and physiological glucose.
[0026] In Example 23, the non-transitory computer-readable medium according to Example 20, wherein the trained machine learning model is customized for the patient by retraining the machine learning model using the patient's previous physiological glucose data and insulin delivery data.
[0027] In Example 24, a system includes a controller that includes a processor and a memory. The memory stores instructions that cause the processor to perform the following operations: applying a regression algorithm to physiological glucose data and insulin delivery data to generate predicted data; operating a trained machine learning model to process the predicted data, thereby generating an output; and determining, based on the output, that the infusion site has failed or is likely to have failed.
[0028] In Example 25, the system according to Example 24, wherein the output is a value indicating the likelihood of infusion site failure.
[0029] In Example 26, the system according to Example 25, wherein the instructions further cause the processor to generate an alarm signal that indicates that the infusion site has failed when the likelihood is above a threshold. The system further includes: a user interface arranged to receive the alarm signal and, in response, generate an alarm on the user interface.
[0030] In Example 27, the system according to Example 24, wherein the prediction data includes a p-value of a selected metric.
[0031] In Example 28, the system according to Example 27, wherein the selected metric includes a metric selected from a category of metrics, where the category includes physiological glucose variability and physiological glucose.
[0032] In Example 29, the system according to Example 27, wherein one of the selected metrics is mean glucose.
[0033] In Example 30, the system according to Example 24, wherein the physiological glucose data includes aggregated data based on raw glucose data.
[0034] In Example 31, the system according to Example 24, wherein the trained machine learning model is customized for the patient by retraining the machine learning model using the patient's previous physiological glucose data and previous insulin delivery data.
[0035] In Example 32, the system according to Example 24, wherein the controller further includes a rule-based algorithm.
[0036] In Example 33, the system according to Example 24, wherein the rule-based algorithm is invoked after a predetermined time period.
[0037] In Example 34, the system according to Example 24, further includes: a drug delivery device configured to deliver insulin to a patient and generate insulin delivery data.
[0038] In Example 35, the system according to Example 34, further includes: a glucose measurement device in communication with the controller and configured to generate physiological glucose data.
[0039] In Example 36, a non-transitory computer-readable medium includes instructions that cause a hardware processor to perform the processes described herein. BRIEF DESCRIPTION OF THE DRAWINGS
[0040] Figure 1 A schematic diagram of a system for controlling physiological glucose in accordance with certain embodiments of the present disclosure is shown.
[0041] Figure 2 An infusion device in accordance with certain embodiments of the present disclosure is shown.
[0042] Figure 3 A block diagram of a method for detecting infusion site failures using a model-based method in accordance with certain embodiments of the present disclosure is shown.
[0043] Figure 4 A graph of raw and processed glucose data in accordance with certain embodiments of the present disclosure is shown.
[0044] Figure 5 A block diagram of a method for detecting infusion site failures using a rule-based method in accordance with certain embodiments of the present disclosure is shown.
[0045] Figures 6 - 8 Logic that can be used as part of a rule-based method for detecting infusion site failures in accordance with certain embodiments of the present disclosure is shown.
[0046] Figure 9 A graph showing regions for calculating the area under a curve in accordance with certain embodiments of the present disclosure is shown.
[0047] Figure 10 A block diagram of a method for detecting infusion site failures using both a model-based method and a rule-based method in accordance with certain embodiments of the present disclosure is shown.
[0048] While the present disclosure may be modified to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and are described in detail below. However, the intention is not to limit the present disclosure to the specific embodiments described, but rather to cover all modifications, equivalents, and alternatives falling within the scope of the appended claims. Detailed Description
[0049] An insulin delivery system, such as a closed-loop system, automatically calculates and adjusts the insulin delivery amount in response to measured glucose levels. The system uses an infusion device coupled to the patient's body to deliver the calculated insulin delivery amount. Over time, the site where the infusion device is located may become less effective, resulting in a site failure. For example, the failure may be due to inflammation or other tissue degradation at the site that reduces the effectiveness of the insulin delivered at the site. Other examples of failures may include site leakage, hyperglycemia and ketones in the blood, blood in the tubing, etc. If the infusion site fails and is not addressed (e.g., by replacing the infusion device with a new one and / or using a different infusion site), the patient may experience persistent hyperglycemia. Accordingly, certain embodiments of the present disclosure are directed to systems, methods, and devices for detecting infusion site failures.
[0050] The following description discloses various methods for detecting infusion site failures. These methods include model-based methods, rule-based methods, and methods that combine model-based and rule-based approaches. Before detailing these methods, the description herein outlines an example system into which these methods can be incorporated. The methods described herein can also be utilized in other systems.
[0051] System Hardware
[0052] Figure 1 An exemplary representative block diagram of a system 10 for controlling physiological glucose is depicted. System 10 includes a drug delivery device 12 (such as an infusion pump) that is removably coupled to a patient 14 via an infusion set 18. The drug delivery device 12 includes at least one drug reservoir 16 that contains a drug such as insulin, for example, although system 10 can deliver other suitable drugs. The drug delivery device 12 can deliver the drug to the patient 14 via the infusion set 18, which provides a fluid path from the drug delivery device 12 to the patient 14. In other embodiments, the delivery device 12 can include an infusion catheter that is directly coupled to the patient's subcutaneous tissue at the infusion site without using an infusion set.
[0053] Figure 2 An exemplary infusion set 18 is shown. The infusion set 18 includes a first proximal end 20 and a second distal end 22. The first proximal end 20 is in communication with the ([ Figure 1 of) drug reservoir 16 of the infusion pump to receive the drug, and the second distal end 22 is in communication with the patient 14 to deliver the drug. At the first end 20, the infusion set 18 includes a reservoir connector 24 configured to couple with an insulin reservoir, a tubing assembly tube 26, and a base connector 28 in the shape of a convex buckle portion. At the second end 22, the infusion set 18 includes: an infusion base 30 in the shape of a concave buckle portion configured to receive the base connector 28; an adhesive pad 32 configured to adhere the infusion base 30 to the patient's skin; and an infusion catheter 34 (e.g., a needle or cannula) configured to be inserted into the patient's skin. In use, the drug is directed from the drug delivery device 12, through the tubing assembly tube 26, through the infusion catheter 34, and into the patient's subcutaneous tissue. Figure 2 The infusion set 18 is just one example of the various types of infusion sets that can be used in system 10.
[0054] Referring back to Figure 1, System 10 also includes an analyte sensor, such as glucose measurement device 36. Glucose measurement device 36 can be a stand-alone device or can be a wearable device. An example of a glucose measurement device is a continuous glucose monitor (CGM). In a particular embodiment, glucose measurement device 36 can be a glucose sensor, such as the Dexcom G6 series continuous glucose monitor, although any suitable continuous glucose monitor can be used. Glucose measurement device 36 is illustratively worn by patient 14 and includes one or more sensors that communicate with or monitor a physiological space (e.g., interstitial or subcutaneous space) within patient 14 and are capable of sensing the concentration of an analyte (e.g., glucose) of patient 14. In some embodiments, glucose measurement device 36 reports a value associated with the concentration of glucose in interstitial fluid (e.g., interstitial glucose). Glucose measurement device 36 can transmit a signal representative of the interstitial glucose value to various other components of system 10.
[0055] System 10 includes a user interface device 38 (hereinafter referred to as "UI 38"), which can be used to input user data into system 10, modify values, and receive information, prompts, data, etc. generated by system 10. In certain embodiments, UI 38 is a handheld user device programmed specifically for system 10, or can be implemented via an application or app running on drug delivery device 12 or a personal smart device such as a phone, tablet, watch, etc. UI 38 can include an input device 40 (e.g., buttons, switches, icons) and a display 42 that displays a graphical user interface. The user can interact with input device 40 and display 42 to provide information (e.g., alphanumeric data) to system 10. In certain embodiments, input device 40 is an icon (e.g., a dynamic icon) on display 42 (e.g., a touch screen). In one example, the patient uses UI 38 to announce events such as meals, start of exercise, end of exercise, emergency stop, etc.
[0056] System 10 also includes an electronic controller 44. Although controller 44 is shown as separate from drug delivery device 12 and UI 38, controller 44 can be physically incorporated into drug delivery device 12 or UI 38, or implemented by a remote server. Alternatively, UI 38 and drug delivery device 12 can each include a controller 44, and the control of system 10 can be divided between the two controllers 44. For example, some of the functions and processes described herein can be implemented by a controller that is part of a remote server, while other functions and processes are implemented by a controller that is part of UI 38. Regardless of its physical location within system 10, controller 44 is shown as being directly or indirectly communicatively coupled to drug delivery device 12, glucose measurement device 36, and UI 38.
[0057] The controller 44 may include or be communicatively coupled to one or more interfaces 46 to communicatively couple with the drug delivery device 12, the glucose measurement device 36, and / or the UI 38 via one or more communication links 48. Example interfaces 46 include wired and wireless signal transmitters and receivers. Example communication links 48 include: wired communication links (e.g., serial communication); wireless communication links such as, for example, short-range radio links such as Bluetooth, IEEE 802.11, proprietary wireless protocols, and / or the like. The term "communication link" may refer to the ability to transmit a certain type of information between at least two devices in at least one direction. The communication link 48 may be a continuous communication link, an intermittent communication link, an ad-hoc communication link, and / or the like. Information (e.g., pump data, glucose data, drug delivery data, user data) may be transmitted via the communication link 48. The drug delivery device 12, the glucose measurement device 36, and / or the UI 38 may also include one or more interfaces to communicatively couple to other devices in the system 10, such as a remote server, via one or more communication links 48.
[0058] The controller 44 illustratively includes at least one processor 50 (e.g., a microprocessor) that executes software (e.g., software modules) and / or firmware stored in a memory 52 of the controller 44, and is communicatively coupled to one or more interfaces 46 and to each other. The software / firmware code contains instructions that, when executed by the processor 50, cause the controller 44 to perform functions of the processes and functions described herein. The controller 44 may alternatively or additionally include one or more application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), hardwired logic, or combinations thereof. The memory 52 may include computer-readable storage media in the form of volatile and / or non-volatile memory (e.g., non-transitory computer-readable media), and may be removable, non-removable, or a combination thereof. In an embodiment, the memory 52 stores executable instructions 54 (e.g., computer code, machine usable instructions, and the like) for causing the processor 50 to implement aspects of embodiments of the system components discussed herein and / or to perform aspects of embodiments of the methods and processes discussed herein. The interfaces 46, the processor 50, and the memory 52 may be communicatively coupled via one or more buses. The memory 52 of the controller 44 is any suitable computer-readable medium accessible by the processor. The memory 52 may be a single storage device or multiple storage devices, may be internal or external to the controller 44, and may include both volatile and non-volatile media. Exemplary memories include random access memory (RAM), read only memory (ROM), electrically erasable programmable ROM (EEPROM), flash memory, CD-ROM, digital versatile disk (DVD), or other optical disk storage devices, magnetic storage devices, or any other suitable medium configured to store data and accessible by the controller 44.
[0059] In the illustrated embodiment, controller 44 receives information from a plurality of components of system 10 and feeds information (e.g., pump data, glucose data, drug delivery data, user data) into a control algorithm that determines at least one drug delivery control parameter that can partially manage the operation of drug delivery device 12. In some specific embodiments, controller 44 may receive pump data from drug delivery device 12, glucose data from glucose measurement device 36, and user data from UI 38. The received pump data may include drug delivery data corresponding to the drug dose delivered to patient 14 by drug delivery device 12. The pump data may be supplied by drug delivery device 12 at the time of delivering the dose or according to a predetermined schedule. The glucose data received by controller 44 may include glucose concentration data from glucose measurement device 36. The glucose data may be supplied at a continuous rate, may be supplied occasionally, or may be supplied at predefined intervals (e.g., every 5 or 10 minutes).
[0060] The pump data, glucose data, drug delivery data, and user data may be provided to controller 44 at predefined schedules upon collection, or queued in memory 52 and supplied to controller 44 upon request. The user data may be input into UI 38 in response to user / patient prompts generated by UI 38 and / or declared by patient 14 in accordance with instructions during training. In some embodiments, at least some of the pump data, glucose data, and / or user data may be retrieved from memory 52 associated with controller 44, and some of the data may be retrieved from memory in drug delivery device 12.
[0061] At least one drug delivery parameter determined by controller 44 can be a (one or more) drug dose, which can at least partially manage drug administration to patient 14 via drug delivery device 12. For insulin delivery (e.g., delivery of rapid-acting insulin or ultra-rapid-acting insulin), the drug delivery parameter can be a basal rate (e.g., a basal profile including a predefined time-varying insulin flow rate over the course of 24 hours), a microbolus dose (e.g., a correction dose relative to the basal rate), and / or a meal bolus. Basal delivery is the continuous delivery of insulin at the basal rate required by the patient to maintain the glucose level in the patient's blood at a desired level outside of the post-meal period. Sometimes, due to changes in activity (such as eating or other activities that affect the user's metabolism), the user may require a larger amount of insulin. This larger amount of insulin is referred to herein as a bolus. A meal bolus is a specific amount of insulin typically delivered over a short period of time. The nature of drug delivery device 12 may require delivery of a bolus as a continuous insulin stream over a period of time or as a series of smaller, discrete insulin volumes delivered over a period of time. A meal bolus facilitates maintenance of the glucose level when the digestive system supplies a large amount of glucose to the bloodstream.
[0062] The term "physiological glucose" herein refers to the measured concentration of glucose in the body. In some embodiments, physiological glucose can be the concentration of glucose in the blood, which can also be referred to as blood glucose. In other embodiments, physiological glucose can be the concentration of glucose in the plasma, which can be referred to as plasma glucose. The measured value of plasma glucose is typically higher than that of blood glucose because the blood's blood cells have been removed in the plasma glucose determination. The relationship between plasma glucose and blood glucose depends on the hematocrit and can vary from patient to patient and over time.
[0063] Infusion Site Fault Detection
[0064] As described above, over time, the infusion site may become less effective and fail. This failure results in and is reflected as one or more of leakage, hyperglycemia and ketones, blood in the tubing, inflammation at the infusion site, etc. However, removing the infusion device prematurely can increase the annual cost of the system. In addition to reducing the annual cost, an infusion device that lasts longer also improves the patient experience and improves the overall convenience of using the system. Accordingly, there is a desire and a need to detect infusion site failure.
[0065] The present disclosure describes different methods for detecting infusion site failures. These methods include model-based methods, rule-based methods, and methods that combine model-based and rule-based approaches. In certain embodiments, these methods are used near real-time when a patient is using the infusion pump and / or infusion device being analyzed. In such embodiments, the controller 44 and / or one or more other processing devices may implement one or more of these methods and alert the patient and / or their healthcare provider when the infusion site has failed or is likely to have failed. The controller 44 may be part of the patient's smartphone and / or may be part of a remote server, which operates functions that require more computational resources. In other embodiments, these methods may be used after the infusion device has been removed to help identify the root cause of hyperglycemic events. For example, instead of providing near real-time alerts, the method may be used to generate a report that classifies the root cause and severity level of hyperglycemic events and whether they are due to infusion site failures or other reasons (such as missed meal boluses or low meal boluses).
[0066] Although the present disclosure relates to using an infusion device detection system for detecting infusion site failures, the systems and methods herein may also be used to detect infusion site failures where the infusion catheter of the delivery device is directly coupled to the patient's subcutaneous tissue without using an infusion device.
[0067] Model - Based Method
[0068] A method for detecting infusion site failures is referred to herein as a model-based method. Briefly, the model-based method applies a trained machine learning model that outputs a prediction of whether a failure has occurred based on statistical data derived from physiological glucose data and insulin delivery data. The model is operated such that predictions about the infusion site are generated periodically. In certain embodiments, the model is operated approximately once per hour, although other suitable periods or intervals may be achieved. While longer or shorter time periods may be used, a time period such as one hour may reduce or minimize the power consumed in operating the model while also obtaining predictions for a time period that can help prevent long-term hyperglycemia. Once the likelihood of an infusion site failure has been predicted, an alert message may be sent to the patient and / or their healthcare provider.
[0069] Figure 3An exemplary method 100 for detecting infusion site failures using a model-based approach is outlined. Method 100 can be executed by a processor 50 of a controller 44, for example, based on pump data, glucose data, drug delivery data, and / or user data. In step 102, historical physiological glucose data and / or insulin delivery data of a patient are processed using a regression-based model or regression algorithm. As described above, physiological glucose data can be generated and received by a sensor (e.g., a CGM coupled to the patient), and insulin delivery data can be generated and received by a medical delivery device (e.g., a pump coupled to the patient). The physiological glucose data and / or insulin delivery data are aggregated and processed for each new time period that begins when the infusion device is first used and ends at the latest time when the model is being operated. For example, if a patient has worn the infusion device for 2 days, the historical physiological glucose data and / or insulin delivery data processed by the regression model will be 2 days' worth of data. Then, one hour later (when the model runs again), the data for the past hour will be added to the last historical data set, and the updated historical data set (e.g., 2 days and 1 hour of data) will be processed by the regression model.
[0070] The regression model outputs prediction data based on the aggregated physiological glucose data and insulin delivery data. In some embodiments, processing the data using a regression algorithm includes calculating certain metrics (described herein) within a consecutive one-hour time window and then fitting a linear regression of the obtained sequence of metrics with respect to time and calculating a p-value, which represents the significance of the calculated time linear coefficient.
[0071] Figure 4 Examples of the above metric calculation and linear regression fitting are provided. Figure 4 Graph 120 in shows a graph of raw glucose measurements (e.g., glucose levels measured every 5 or 10 minutes) for two days, and graph 122 shows the mean glucose calculated within consecutive one-hour time windows. Graph 122 also includes a fitted linear regression 124 of the calculated mean glucose.
[0072] In some embodiments, the prediction data includes the p-values of the regression coefficients of selected metrics calculated at specific time intervals (e.g., 1-hour intervals). The selected metrics can include a combination of two or more of the following:
[0073]
[0074]
[0075] Table 1
[0076] To reduce the complexity and computational resources required for operating regression algorithms and machine learning models (discussed further below), a subset of the metrics listed above can be selected. The subset of metrics can be selected based on the degree of independent impact that the given metrics have on the machine learning model. As an example, if two metrics have a high correlation (which indicates redundancy), then only one of the metrics can be selected. As another example, if the contribution (or impact) of a given metric on the output of the machine learning model is low, then that metric will not be selected. As a specific example, if a given metric has a Shaply value less than a predetermined amount (e.g., less than 0.25), then that metric is not selected.
[0077] Additionally, data other than the data generated by the regression algorithm can be selected as features input to the trained machine learning model. For example, the length of time that the current infusion site has been in use can be a selected feature.
[0078] In some embodiments, the selected features - which are a combination of the raw data and the regression algorithm output - are the features listed in the table below:
[0079] Feature Meaning Wear Length Days of Wear at the Infusion Site TARp Value Linear Coefficient p - Value in the Time Regression above the Range LBGIp Value Linear Coefficient p - Value in the Hypoglycemic Index Regression Total Bolus p - Value Linear Coefficient p - Value in the Total Bolus Regression SDp Value Linear Coefficient p - Value in the Standard Deviation Regression CVp Value Linear Coefficient p - Value in the Coefficient of Variation Regression Instability p - Value Linear Coefficient p - Value in the Instability Index Regression
[0080] Table 2
[0081] Predictive data (e.g., p-values) are generated by the regression algorithm. In step 104, the data (e.g., wear length) and the predictive data are input into the trained machine learning model to generate an output, such as a prediction of infusion site failure.
[0082] The machine learning model is trained to receive the data and the predictive data as input, process the input, and then output a prediction of whether the infusion site has failed. The trained machine learning model can include one of several different types of models, such as a neural network (e.g., a deep learning model), and can apply one of several different types of algorithms (e.g., a supervised algorithm, such as random forest or logistic regression). In some embodiments, the trained machine learning model is an XGBoost model.
[0083] In some embodiments, when the model receives patient-specific data, the machine learning model for a given patient is updated over time. For example, when a patient uses their first few infusion devices (e.g., infusion devices for the first 3 months), a baseline machine learning model can be used. However, after an initial number of infusion devices or an initial time period, the machine learning model can be adjusted to account for patient-specific trends. For example, a machine learning model customized for a given patient can be created by: (1) determining which sets of training data (e.g., 50 - 150 sets of training data) are most similar to the patient's actual data over time (e.g., using mean physiological glucose), and (2) retraining the machine learning model based on the determined sets of training data and the patient's actual data collected during the initial time period. Additionally or alternatively, before the patient's actual data is used to retrain the machine learning model, the machine learning model must detect multiple infusion site failures such that the actual data has examples of infusion site failures and data surrounding such detected failures.
[0084] In some embodiments, the output of the trained machine learning model is the likelihood that an infusion site has failed (e.g., a value on a scale of 0 - 100%) (step 106). This output can be used in various ways to alert the patient and / or their healthcare provider. As an example, if the likelihood is above a certain value (e.g., 75%), an alert signal is generated and sent to the user and / or their healthcare provider. The alert signal can cause an alert to be displayed on the UI 38. As another example, the likelihood can be used to periodically update a window or status icon displayed on the UI 38. In this example, the window or status icon shows the current status of the infusion device (e.g., within the past hour or since the last output). This involves displaying the numerical value of the likelihood on the UI 38, displaying a battery indicator-like graphic representing the remaining volume of the infusion device, displaying a traffic light graphic in response to the likelihood value, or simply displaying an icon of a different color indicating the likelihood value. For example, if the likelihood is below 50%, the window or status icon indicates that the infusion device is operating correctly (e.g., by displaying a certain color, phrase, text, number, or icon). If the likelihood is 50% to 75%, the window or status icon indicates that the infusion device may need to be replaced soon. And if the likelihood is greater than 75%, the window or status icon indicates that the infusion device needs to be changed and a separate alert is generated and displayed (e.g., in a pop-up window). The various numerical ranges just discussed above can be modified as needed.
[0085] The above-described model-based method can be implemented on a server (e.g., in the cloud), on the UI 38 (e.g., via an application on a patient's smartphone), on the drug delivery device itself (e.g., via an insulin pump), or by a combination of system components.
[0086] Rule - Based Method
[0087] A second disclosed method for detecting infusion site failure is referred to in this specification as the rule-based method. Briefly, the rule-based method applies a series of rules that are designed to determine whether blood glucose data indicating hyperglycemia is caused by an infusion site failure or by another cause (such as a missed meal bolus or a low meal bolus).
[0088] Figure 5 Method 150 for detecting infusion site failure using the rule-based method is outlined. In step 152, baseline patient statistics are calculated. These baseline statistics can be based on the patient's physiological glucose data and insulin delivery data. For example, the baseline statistics can include mean physiological glucose, TAR (time above range), and the lowest and peak glucose during a baseline period. In certain embodiments, if a new infusion device has been worn for less than 3 days, the baseline period is initially the first 2 days. If a new infusion device has been worn for 3 days or longer, the baseline period can be extended to the first 3 days. In certain embodiments, method 150 is only initiated after the patient has worn a new infusion device for at least 2 days.
[0089] In step 154, the baseline statistics are compared with the patient's most recent physiological glucose data and insulin delivery data. In certain embodiments, the most recent data is data collected within the last 36 hours, even if that time period overlaps with the baseline period.
[0090] In step 156, in certain embodiments, the baseline statistics (1) are first compared with set thresholds to detect whether a chronic infusion site failure has occurred, (2) are then compared with set thresholds to detect whether an acute infusion site failure has occurred, and (3) are then compared with set thresholds to detect whether an abnormal shift has occurred. Various thresholds are set - which are described in further detail herein - to detect the risk of hyperglycemia. Figures 6 - 8 Further detailed description - to detect the risk of hyperglycemia.
[0091] Figures 6 - 8 Additional details of detecting infusion site failure using the rule-based method are shown, as Figure 5 Outlined. Figure 6Method 200 includes inputting physiological glucose data and insulin delivery data to a computing device such as controller 44 (step 202). At step 204, the data is first analyzed to determine if a chronic infusion site failure has occurred. Figure 6 Steps 202 and 204 of method 200 correspond to Figure 5 steps 152 and 154 of method 150. The remaining description in this section provides Figure 5 further examples of step 156 of method 150.
[0092] If the data indicates a chronic infusion site failure, the data is further investigated to distinguish between the infusion site failure and another cause of a chronic hyperglycemic event (step 206). Based on certain criteria described further below, the logic indicates that a chronic infusion site failure has occurred (marked "red" in Figure 6 ), may have occurred (marked "yellow" in Figure 6 ), or should be ignored (marked "green" in Figure 6 ). If the data does not indicate a chronic site failure, then at step 208, the data is analyzed a second time to determine if an acute infusion site failure has occurred. If the data indicates an acute infusion site failure, the data is further investigated to distinguish between the infusion site failure and another cause of an acute hyperglycemic event (step 210). Based on certain criteria described further below, the logic indicates that an acute infusion device failure has occurred, may have occurred, or should be ignored. Finally, if the data does not indicate an acute site failure, then at step 212, the data is analyzed to determine if an abnormal deviation related to an infusion site failure may have occurred. The logic can stipulate that an infusion device failure may have occurred or the deviation should be ignored.
[0093] Chronic infusion site failure involves a situation where insulin delivery at the infusion site has gradually become less effective over time. As such, a threshold for the first comparison with baseline statistics is set to detect if physiological glucose has increased to an extent indicating a hyperglycemic risk. For chronic infusion site failure, step 204 involves determining (1) if the patient's TAR is higher than the threshold (e.g., 25%) and (2) if it has increased by more than the threshold (e.g., 30%) from the baseline TAR. Step 204 can also involve determining (3) if the nadir physiological glucose has increased by more than the threshold (e.g., 70%) compared to the baseline statistics, or if the mean physiological glucose has increased by more than the threshold (e.g., 30%) from the baseline statistics. When these various thresholds have been breached, it indicates a risk of hyperglycemia. However, additional criteria can be applied to determine if the risk of hyperglycemia is due to a temporary increase in physiological glucose or due to a chronic infusion site failure.
[0094] Figure 7 Logic 250 for differentiating between a temporary increase in physiological glucose and a chronic problem is outlined. At 252, the logic involves comparing insulin delivery amounts from a baseline time period and a most recent time period. In some embodiments, this comparison is implemented using a Wilcoxon rank sum test. At 254, if the comparison shows that the most recent time period involves a greater amount of insulin being delivered, the logic dictates that a chronic insulin device failure has been detected.
[0095] At 256, if the comparison shows that the most recent time period involves a similar insulin delivery amount, a second comparison is made at 258. This comparison involves determining (1) whether the peak physiological glucose of the most recent time period is above a threshold (e.g., 250 mg / dL) and (2) whether the peak physiological glucose of the most recent time period has increased by a threshold (e.g., 30%) compared to the baseline statistics. If both criteria of 258 are met, the logic dictates that a chronic insulin device failure has been detected. If not, the logic still dictates that there is some risk (but a smaller risk) of a hyperglycemic chronic infusion site failure.
[0096] At 260, if the comparison shows that the most recent time period involves a lesser amount of insulin being delivered, a second comparison is made at 262. This comparison involves determining whether the peak physiological glucose of the most recent time period is above or below a threshold (e.g., 250 mg / dL). If the peak physiological glucose is above the threshold, the logic dictates that there is some risk (but a smaller risk) of hyperglycemic due to a chronic infusion site failure.
[0097] As described above, after comparing the baseline statistics with a set threshold to detect a potential chronic infusion site failure (as just described in the above paragraphs), the baseline statistics are compared with a set threshold to detect a potential acute infusion site failure. An acute infusion site failure involves a situation where an infusion site failure causes a relatively sharp increase in physiological glucose. For an acute infusion site failure, step 208 involves determining whether physiological glucose has increased by more than a threshold (e.g., 180 mg / dL) from a lower threshold (e.g., 70 mg / dL) over a certain time period (e.g., 7 hours). When such a criterion has been met, it indicates a risk of hyperglycemic. However, additional criteria can be applied to determine whether the risk of hyperglycemic is due to reasons other than an acute insulin site failure. Figure 6 Step 208 involves determining whether physiological glucose has increased by more than a threshold (e.g., 180 mg / dL) from a lower threshold (e.g., 70 mg / dL) over a certain time period (e.g., 7 hours). When such a criterion has been met, it indicates a risk of hyperglycemic. However, additional criteria can be applied to determine whether the risk of hyperglycemic is due to reasons other than an acute insulin site failure.
[0098] Figure 8Logic 300 is outlined for determining whether a sharp increase in physiological glucose is the result of an acute insulin site failure or another cause. Briefly, if the most recent insulin bolus is greater than the insulin boluses delivered during a baseline time period, the acute increase in physiological glucose may be due to an infusion site failure rather than a missed bolus or a low meal bolus. In some embodiments, for acute failure analysis, the baseline time period is shorter (e.g., 12 hours) than the baseline time period for chronic failure analysis.
[0099] At 302, the logic involves determining the start time and end time of the determined acute increase in physiological glucose. At 304, the amount of the past maximum effective bolus is determined. In some embodiments, the past maximum effective bolus is calculated as the maximum bolus taken within a set amount of time (e.g., 6 hours) before the start time and / or end time of the determined acute increase in physiological glucose. Additionally, at 304, the past maximum effective bolus is compared to the median bolus from the baseline period. At 306, the peak physiological glucose of the most recent time period is compared to the peak physiological glucose of the baseline statistics. If this comparison shows that the most recent peak is greater than a threshold (e.g., 30%) compared to the baseline, the logic dictates that an acute insulin device failure is detected. If not, the logic still dictates that there is some risk (but a smaller risk) of hyperglycemia due to an acute infusion site failure. At 308, the peak physiological glucose of the most recent time period is compared to the peak physiological glucose of the baseline statistics. If this comparison shows that the most recent peak is greater than a threshold (e.g., 30%) compared to the baseline, the logic dictates that there is some risk (but a smaller risk) of hyperglycemia due to an acute infusion site failure.
[0100] As described above, after chronic and acute failure analyses, a rule-based method can detect an abnormal excursion. An excursion involves a situation where physiological glucose increases from a nadir to a peak above a threshold (e.g., 180 mg / dL) and then decreases below the threshold until the nadir occurs again. An excursion is abnormal if the physiological glucose and insulin delivery data indicate a decrease in control ability, such as if physiological glucose does not decrease rapidly after an insulin bolus is delivered. In an illustrative embodiment, detecting an abnormal excursion follows a multi-step process: (1) identifying the excursion period, (2) calculating the area under the curve (AUC) of the hyperglycemic region, and (3) analyzing the associated insulin delivery data.
[0101] For the first step, an offset period (e.g., a period that begins with an increase in physiological glucose, peaks, and ends when physiological glucose stops decreasing) is determined by identifying two nadirs and one peak in the physiological glucose data. In some embodiments, to help limit the effects of noise and / or minor local offsets, the physiological glucose data (e.g., via a local polynomial method) is processed to smooth the physiological glucose data. And in either of the following two cases, an offset is considered not completed and combined with the next offset: (1) the ending nadir exceeds 180 mg / dL, (2) the ending nadir is between 70 mg / dL - 180 mg / dL, and glucose remains below 180 mg / dL from the current peak until the next peak for more than 2 hours.
[0102] For each offset period, there will be a region that is above a specific threshold (e.g., 180 mg / dL), and which can be referred to as a hyperglycemic region. The AUC of the hyperglycemic region can be calculated for a baseline time period and a recent time period (e.g., the last 1 day). Figure 9 An example graph showing physiological glucose data and the region defining the AUC of the hyperglycemic region is shown. The AUC is shown as the shaded region in Figure 8 with the calculated area marked by a numerical indicator. If any AUC of the hyperglycemic region during the recent time period is greater than all AUCs in the baseline period, the logic dictates further investigation.
[0103] Further investigation may involve determining an indication of a diminished physiological glucose response to insulin delivery. In some embodiments, a metric is used to measure such an indication - the metric is referred to herein as the insulin effect per unit - which measures the ability to lower physiological glucose using insulin delivery:
[0104]
[0105] where iob(t) is the estimated cumulative on board insulin at time t.
[0106] If the insulin effect per unit is statistically lower than the baseline during any offset, the insulin has a less effective ability to lower physiological glucose. In some embodiments, a threshold is set from a baseline distribution created by a bootstrap sampling method to determine if an abnormal offset is the result of an infusion site failure.
[0107] Combined Model - Based and Rule - Based Method
[0108] In some embodiments, both model-based methods and rule-based methods are used in various ways to complement each other.
[0109] As an example, two methods are performed simultaneously to provide an examination of the other method. For example, these two methods can be implemented periodically (e.g., approximately once per hour), and the results can be compared. If the rule-based method determines that an event has occurred (such as the "red" or "yellow" events shown in the figure and described above), the output of the model-based method can be used to confirm or change the determined event. If the model-based method outputs a prediction with a high confidence level that contradicts the output of the rule-based method, the output of the model-based method can ultimately be used to determine the type of event. For example, if the rule-based method results in a red or yellow event, if the probability of the event is less than a threshold (e.g., 5%), the event is changed to a green event (e.g., no infusion site failure). Conversely, if the rule-based method is a green event, if the probability of the event is greater than a threshold (e.g., 95%), the event is changed to red or yellow (e.g., indicating an infusion site failure).
[0110] As another example, the rule-based method can be used alone until an event has been detected. Once an event has been detected, the model-based method can be used to examine the output of the rule-based method. Using this combination of methods can reduce the overall power consumption of the system because the rule-based method requires fewer computational resources compared to the model-based method.
[0111] As another example, the model-based method can be used exclusively for an initial period of wear (e.g., the first 2 or 3 days) because it is more sensitive to shorter data cycles. After the initial period has expired, the system can switch to the rule-based method, which is more stable over longer data cycles until the infusion device is removed.
[0112] Figure 10 Method 400 for using both a model-based method and a rule-based method is illustrated. Method 400 includes determining the occurrence of a chronic infusion site failure or an acute infusion site failure based at least in part on a comparison of physiological glucose data and insulin delivery data with a threshold (step 402). In certain embodiments, the comparison is made between the threshold and the calculated difference between baseline physiological glucose data and insulin delivery data and the most recent physiological glucose data and insulin delivery data.
[0113] In response to determining the occurrence of a chronic infusion site failure or an acute infusion site failure, a trained machine learning model can be operated to confirm the occurrence of the chronic infusion site failure or the acute infusion site failure (step 404). For example, the trained machine learning model can output a value indicating the likelihood of an infusion site failure. If the value is above and / or below a threshold, the occurrence of the chronic infusion site failure or the acute infusion site failure can be confirmed, and an alert can be generated. In some embodiments, both the rule-based method and the model-based method use the same physiological glucose data and insulin delivery data (or data derived therefrom).
[0114] Additional Aspects of the Present Disclosure
[0115] In some aspects, as described above, a method using a rule-based approach can be applicable to determining the status of an infusion site. The method includes: calculating baseline statistics associated with an initial time period and an infusion site; determining that the difference between the baseline statistics and physiological glucose data from a later time period has exceeded a first threshold; and in response to determining that the difference between the baseline statistics and the physiological glucose data has exceeded the threshold, determining the occurrence of a chronic infusion site failure or an acute infusion site failure.
[0116] Additional aspects of the method include comparing the difference between the baseline statistics and the insulin delivery data and determining that the physiological glucose data is above a second threshold.
[0117] In additional aspects, the method includes determining that an aspect of the insulin delivery data is above the baseline statistics and, in response, determining the occurrence of a chronic infusion site failure.
[0118] In additional aspects, the method includes determining that an aspect of the insulin delivery data is above the baseline statistics and, in response, determining the occurrence of an acute infusion site failure.
[0119] In other aspects, as described above, by combining one or more rule-based methods described herein with one or more model-based methods described herein, a method can be applied to determine the status of an infusion site. The method includes - using a rule-based method - determining the occurrence of a chronic infusion site failure or an acute infusion site failure based at least in part on a comparison of physiological glucose data and insulin delivery data with thresholds. The method further includes - using a model-based method - in response to determining the occurrence of a chronic infusion site failure or an acute infusion site failure, operating a trained machine learning model to confirm the occurrence of the chronic infusion site failure or the acute infusion site failure.
[0120] In additional aspects, the rule-based approach is performed more frequently than the model-based approach. For example, the rule-based approach may be used approximately once an hour, and the model-based approach may be used only after the rule-based approach determines the occurrence of a chronic infusion site failure or an acute infusion site failure.
[0121] In additional aspects, the rule-based approach and the model-based approach are performed simultaneously.
[0122] In additional aspects, the output of the model-based approach confirms or overrules the output of the rule-based approach. For example, if the output of the model-based approach indicates a high probability of chronic infusion site failure or acute infusion site failure (e.g., 90% or higher, 95% or higher), the output of the model-based approach will overrule the output of the rule-based approach.
[0123] In additional aspects, both the rule-based approach and the model-based approach use the same physiological glucose data and insulin delivery data (or the same data derived therefrom).
[0124] Therefore, the present disclosure is intended to cover all such substitutions, modifications and variations. In addition, although several embodiments of the present disclosure have been illustrated in the drawings and / or discussed herein, it is intended that the present disclosure is not limited thereto, as it is intended that the scope of the present disclosure is as broad as the art will allow, and the specification should be construed as such. Therefore, the above description should not be construed as limiting, but merely as an example of a particular embodiment.
Claims
1. A method for predicting the status of an infusion site, the method comprising: applying a regression model to physiological glucose data and insulin delivery data to generate prediction data; operating a trained machine learning model to process the prediction data, thereby generating an output; and based on the output, determining that the infusion site has failed or is likely to have failed.
2. The method according to claim 1, further comprising: generating an alarm signal indicating that the infusion site has failed; and in response to the alarm signal, displaying an alarm on a graphical user interface.
3. The method according to any one of the preceding claims, wherein the physiological glucose data and insulin delivery data are aggregated over a period starting from the first use of the infusion site.
4. The method according to claim 3, further comprising: calculating a linear regression based on the aggregated physiological glucose data and insulin delivery data, wherein the prediction data is at least partially based on the linear regression.
5. The method according to any one of the preceding claims, wherein the physiological glucose data and insulin delivery data are updated and aggregated according to a set schedule.
6. The method according to any one of the preceding claims, wherein the output is a value indicating the likelihood of infusion site failure.
7. The method according to any one of the preceding claims, wherein the prediction data includes p-values of selected metrics.
8. The method according to claim 7, wherein the selected metrics include metrics selected from a category of metrics, wherein the category includes physiological glucose variability and physiological glucose.
9. The method according to claim 7 or 8, wherein the selected metrics comprise: time above range, hypoglycemia index, total bolus, standard deviation, coefficient of variation, and instability index.
10. The method according to any one of the preceding claims, wherein the trained machine learning model is an XGBoost model.
11. The method according to any one of the preceding claims, wherein the trained machine learning model is customized for a patient by retraining the machine learning model using the patient's previous physiological glucose data and insulin delivery data.
12. The method according to any one of the preceding claims, further comprising: based on the output, updating a status icon associated with the infusion site on a user interface.
13. A computer program product comprising instructions for causing one or more processors to perform the steps of the method according to claims 1-12.
14. A computer-readable medium having stored thereon the computer program product according to claim 13.
15. A computer comprising the computer-readable medium according to claim 14.