Joint state estimation prediction that evaluates the difference between predicted data and corresponding received data

Abstract

Systems and methods are provided for correcting untrusted data of a subject using trusted data related to the subject. The systems and methods are directed to assessing the difference of predicted data with respect to corresponding received data. The systems and methods estimate metabolic states from a combination of trusted and untrusted metabolic inputs, and optionally using a personalized mathematical model with parameter optimization. The systems and methods provide corrected untrusted inputs with a measured impact on the blood glucose signal that is consistent with the metabolic model. An estimation of future metabolic states is achieved for decision support and automatic insulin dosing. Scenario replays with estimated or corrected data are also provided.

Description

[0001] By invoking and incorporating relevant applications

[0002] This application claims priority to application No. 62 / 935,920, filed November 15, 2019, entitled "Joint State Estimation Prediction That Evaluates Differences in Predicted vs. Corresponding Received Data". The entire contents of the above application are incorporated herein by reference and are hereby expressly incorporated in whole or in part. Background Technology

[0003] With the increasing adoption of CGM (Continuous Glucose Monitoring) and connected devices, the availability and reliability of glucose time-series data have improved in recent years. However, despite the availability of reliable blood glucose data, accurate tracking of insulin and food intake data, as well as the optimization of insulin bolus timing and effective duration, remain challenges for many diabetic patients, leading to poor glycemic control.

[0004] Non-diabetic individuals have strictly controlled blood glucose (BG) levels, even with glucose intake ranging from fasting to high-carbohydrate meals and metabolic demands ranging from sleep to strenuous exercise. For example, in non-diabetic adults, the average CGM (cognitive glucose tolerance test) is 99 mg / dL, and it remains within the 70–140 mg / dL range 97% of the time. This strict control is achieved through the combined action of glucose-regulating hormones such as insulin, glucagon, amyloid, and GLP-1, as well as the transmission of relevant information between organs such as the pancreas, intestines, and liver.

[0005] In contrast, glycemic control in type 1 diabetes has historically relied on a simpler insulin dosing strategy to meet the body's baseline needs for food intake. The example program combines daily doses of long-acting insulin with pre-meal doses of rapid-acting insulin, based on carbohydrate counting and self-monitoring of blood glucose measurements. The success of this approach depends on diligent attention and assumes that the body always responds to food and insulin in the same way, despite differences in food choices, stress, exercise, etc. As a result, most people are forced to balance avoiding the health risks of chronic hyperglycemia with dangerous episodes of hypoglycemia.

[0006] Improving glucose control in insulin-dependent diabetes mellitus depends in part on strategies that more closely mimic the way the pancreas adapts to changing metabolic conditions. An example is the artificial pancreas (AP) system.

[0007] However, patient alerts and / or alarms, as well as drug administration algorithms, often rely on the ability to prospectively predict future metabolic status in real time or retrospectively simulate the physiological environment of living with a chronic disease. In turn, predicting the future depends on the ability to estimate a patient's current metabolic status using all available data, including data received directly from the patient (e.g., voluntary confirmation of carbohydrate intake), which is prone to error (e.g., delayed or complete absence of intake confirmation, resulting in a significant underestimation of carbohydrate counts). Even when an algorithm predicts data that is currently unavailable, discrepancies (i.e., inconsistencies) often exist if / when that predicted data is received (e.g., later from the user). These discrepancies are not currently used, but if estimated, can provide valuable information about the data for future use. The systems and methods described herein utilize and correct for these discrepancies.

[0008] Combining human and machine inputs in metabolic models presents a dilemma. The most reliable inputs are machine-recorded, such as those from insulin pumps or continuous glucose monitors, making it easy to ignore or avoid human input. The problem is that glucose in the blood and CGM signal is delayed, even for rapidly acting carbohydrates. Therefore, even incompletely announced or described eating will initially predict future glucose levels better than pre-meal CGM traces. Once blood glucose has responded to eating, metabolic models can better describe the observed response. The system and method described in this paper seamlessly combine these two perspectives and correct for their discrepancies. Summary of the Invention

[0009] According to several aspects, systems and methods are provided for correcting untrusted data of subjects using trusted data relating to the subjects. According to several aspects, the systems and methods aim to evaluate the discrepancies between predicted data and corresponding received data.

[0010] In one implementation, one method includes receiving untrusted data relating to a subject at an input estimator; receiving trusted data relating to the subject at the input estimator; correcting the untrusted data using the trusted data using an input corrector; and outputting the corrected untrusted data.

[0011] The implementation may include some or all of the following features. The untrusted data includes at least one of insulin timing, insulin volume, food intake data, or activity data. The untrusted data is untrusted due to behavioral abnormalities or human error in at least one of the time, volume, estimation, or input. The trusted data includes at least one of CGM data, insulin pump data, computer-generated data, computer-generated models, or individualized models describing the subject's glucose and insulin dynamics. The method further includes predicting the subject's future glucose status based on the corrected untrusted data. The untrusted data includes reported carbohydrates, wherein the reported carbohydrates are unreliable or unavailable. The untrusted data includes a data input stream. The method further includes receiving additional untrusted data and using the trusted data to correct the additional untrusted data. The method further includes receiving additional trusted data and using the additional trusted data to correct the untrusted data. The method further includes adjusting the AP using the corrected untrusted data. The method further includes updating the subject's behavioral model using the corrected untrusted data. The method further includes determining that the untrusted data is unreliable or unknown. Determining that the untrusted data is unreliable or unknown includes calculating the local variance of the untrusted data using modeling, and comparing the local variance with the population variance using the untrusted data to determine a comparison measure, wherein the untrusted data is determined to be unreliable or unknown when the comparison measure is higher than a threshold. Determining that the untrusted data is unreliable or unknown also includes determining the differences between the untrusted data and a trusted data model.

[0012] The implementation may include some or all of the following features. The method further includes determining a confidence score of the untrusted data relative to trusted data. The method further includes generating alerts related to the subject based on the corrected untrusted data. The method further includes determining the subject's behavioral patterns using the corrected untrusted data. The method further includes generating intelligent alerts related to the subject based on the behavioral patterns. The untrusted data includes diabetes management data. The diabetes management data is estimated diabetes management data. The trusted data includes diabetes management data corresponding to the estimated diabetes management data, wherein the diabetes management data is received from a connected device or user input. The method further includes comparing the untrusted data with the trusted data to identify the behavioral root causes of glycemic dysfunction.

[0013] The implementation may include some or all of the following features. The method further includes using the corrected untrusted data to identify the behavioral roots of glycemic dysfunction. The correction includes: receiving the untrusted data at an input corrector, wherein the untrusted data includes untrusted metabolic inputs; receiving the trusted data at an input corrector, wherein the trusted data includes estimated untrusted metabolic inputs; and combining the untrusted data and the trusted data using a weighting function to generate corrected untrusted metabolic inputs. The untrusted data and the trusted data received at the input corrector are in vector form, and the corrected untrusted metabolic inputs are also in vector form. The weighting function is based on time correlation. The weighting function is based on the relative confidence of the untrusted data and the trusted data. The untrusted data includes reported untrusted metabolic inputs, and the combination includes correcting the difference between the reported untrusted metabolic inputs and the estimated untrusted metabolic inputs. The correction includes aligning the reported untrusted metabolic inputs and the estimated untrusted metabolic inputs with a behavioral model. The correction includes using measurement data to correct for the discrepancy between the untrusted metabolic input and the estimated amount and timing of the untrusted metabolic input.

[0014] In one implementation, one method includes receiving untrusted data relating to a subject at an input estimator, wherein the untrusted data includes user input data, which includes at least one of insulin data, food intake data, or activity data; and using an input corrector to correct the untrusted data using trusted data relating to the subject, wherein the trusted data includes computer-generated data.

[0015] The implementation may include some or all of the following features. The untrusted data includes at least one of insulin timing, insulin volume, food intake data, or activity data. The untrusted data is untrusted due to behavioral abnormalities or human error in at least one of the time, volume, estimation, or input. The trusted data includes at least one of CGM data, insulin pump data, computer-generated models, or individualized models describing the subject's glucose and insulin dynamics. The method further includes predicting the subject's future glucose status based on the corrected untrusted data. The untrusted data includes reported carbohydrates, wherein the reported carbohydrates are unreliable or unavailable. The untrusted data includes a data input stream. The method further includes receiving additional untrusted data and using the trusted data to correct the additional untrusted data. The method further includes receiving additional trusted data and using the additional trusted data to correct the untrusted data. The method further includes adjusting the AP using the corrected untrusted data. The method further includes updating the subject's behavioral model using the corrected untrusted data. The method further includes determining that the untrusted data is unreliable or unknown. Determining that the untrusted data is unreliable or unknown includes calculating the local variance of the untrusted data using modeling, and comparing the local variance with the population variance using the untrusted data to determine a comparison measure, wherein the untrusted data is determined to be unreliable or unknown when the comparison measure is higher than a threshold. Determining that the untrusted data is unreliable or unknown includes determining the difference between the untrusted data and a trusted data model. The method further includes determining a confidence score of the untrusted data relative to the trusted data. The method further includes generating alerts related to the subject based on the corrected untrusted data. The method further includes using the corrected untrusted data to determine the subject's behavioral patterns. The method further includes generating intelligent alerts related to the subject based on the behavioral patterns.

[0016] The implementation may include some or all of the following features. The untrusted data includes diabetes management data. The diabetes management data is estimated diabetes management data. The trusted data includes diabetes management data corresponding to the estimated diabetes management data, wherein the diabetes management data is received from a connected device or user input. The method further includes comparing the untrusted data with the trusted data to identify behavioral roots of glycemic dysfunction. The method further includes using the corrected untrusted data to identify behavioral roots of glycemic dysfunction. The correction includes: receiving the untrusted data at an input corrector, wherein the untrusted data includes untrusted metabolic inputs; receiving the trusted data at an input corrector, wherein the trusted data includes estimated untrusted metabolic inputs; and combining the untrusted data and the trusted data using a weighting function to generate corrected untrusted metabolic inputs. The untrusted data and the trusted data received at the input corrector are in vector form, and the corrected untrusted metabolic inputs are in vector form. The weighting function is based on time correlation. The weighting function is based on the relative confidence of the untrusted data and the trusted data. The untrusted data includes reported untrusted metabolic inputs, and the combination includes correcting for discrepancies between the reported untrusted metabolic inputs and estimated untrusted metabolic inputs. The correction includes aligning the reported untrusted metabolic inputs and estimated untrusted metabolic inputs with a behavioral model. The correction includes correcting for discrepancies in the quantity and timing of the untrusted metabolic inputs and estimated untrusted metabolic inputs using measurement data. The method further includes using the corrected untrusted data and the trusted data to perform replay prediction. The method further includes simulating metabolic states based on the replay prediction output. The method further includes using the corrected untrusted data and the trusted data to perform real-time prediction. The method further includes simulating metabolic states based on the real-time prediction output.

[0017] In one implementation, one method includes predicting data of a subject over a period of time; receiving untrusted data for diabetes management; simulating multiple predicted data trails over the period of time using the possible variance spectrum of the untrusted data; comparing the simulated predicted data trails with the predicted data to identify glycemic effects; and outputting visualizations or recommendations based on the glycemic effects.

[0018] The implementation may include some or all of the following features. The untrusted data includes glucose data, and the predicted data trail includes a predicted glucose trail. The predicted glucose data is based on trusted CGM (Continuous Glucose Monitoring) data and an individualized model of the subject's glucose-insulin kinetics. The predicted glucose data includes a glucose trail that provides the best estimate of glucose status as it changes over time. The untrusted data for diabetes management includes at least one of insulin timing, insulin volume, food intake data, or activity data. The effect on blood glucose is related to differences in at least one of the amount or timing of diabetes management data.

[0019] In one implementation, a system includes a processor and a metabolic model, wherein the processor is configured to receive untrusted user input and use the metabolic model to correct the untrusted user input with trusted input.

[0020] The implementation may include some or all of the following features. The processor is further configured to optimize the predictive power of the metabolic model to predict future glucose levels. The processor is further configured to allow replay of events and outcomes in the event of an alternative treatment procedure. The processor is further configured to provide real-time predictions of future metabolic states. The processor is further configured to determine the credibility of untrusted user input. The processor is further configured to provide a score corresponding to the credibility. The processor is further configured to perform replay analysis for at least one replay application. The at least one replay application includes evaluating blood glucose (BG) outcome metrics in the analysis, identifying credible instances of the scenario in the replay analysis, estimating data quality, credibility profile, and data credibility that vary with time of day. The processor is further configured to perform corrected projections for at least one real-time application. The at least one real-time application includes the confidence level of medical actions and the determination of the time required before providing an opinion.

[0021] The implementation may include some or all of the following features: Untrusted user input includes estimated carbohydrates. Untrusted user input includes time series of uncertain metabolic inputs. Trusted input includes CGM and insulin pump readings. Trusted input includes time series of trusted metabolic inputs. The processor is further configured to output an estimated metabolic state in time series form, a final corrected estimated metabolic state in time series form, and the confidence level of the final estimated metabolic state and the corrected estimated input in time series form. The processor is included within a joint state / input estimator, and the metabolic model is a plug-in.

[0022] In one implementation, a method includes receiving untrusted data relating to a subject at an input estimator, wherein the untrusted data includes user input data, which includes at least one of insulin data, food intake data, or activity data; determining the credibility of the untrusted data at a credibility estimator; receiving trusted data at the credibility estimator; and updating the credibility of the untrusted data at the credibility estimator using the trusted data.

[0023] The implementation may include some or all of the following features. Determining the credibility of the untrusted data includes: determining a first credibility based on at least one of the untrusted data lacking completeness or the untrusted data lacking continuity; determining a second credibility based on expected behavior indicating at least one of the untrusted data lacking completeness or the untrusted data lacking continuity; determining a third credibility based on artifacts in the estimated input indicating unknown factors of the system; and summarizing the first credibility, the second credibility, and the third credibility. Determining the first credibility includes using a measurement signal as input, determining the second credibility includes using the untrusted data and the trusted data as input, and determining the third credibility includes using the untrusted data, estimated untrusted data, and corrected data as input.

[0024] In one implementation, a method includes receiving first untrusted data related to a subject at an input estimator, wherein the first untrusted data includes user input data, which includes at least one of insulin data, food intake data, or activity data; determining the credibility of the first untrusted data at a credibility estimator; receiving second untrusted data related to the subject at the input estimator; determining the credibility of the second untrusted data at the credibility estimator; updating the credibility of the first untrusted data at the credibility estimator using the second untrusted data or the credibility of the second untrusted data; receiving trusted data at the credibility estimator; and updating the credibility of the first untrusted data and the second untrusted data at the credibility estimator using the trusted data.

[0025] The implementation may include some or all of the following features. Determining the first confidence level of the untrusted data includes: determining the first confidence level based on at least one of the untrusted data lacking completeness or the untrusted data lacking continuity; determining the second confidence level based on expected behavior indicating at least one of the untrusted data lacking completeness or the untrusted data lacking continuity; determining the third confidence level based on artifacts in the estimated input indicating unknown factors of the system; and summarizing the first confidence level, the second confidence level, and the third confidence level. Determining the first confidence level includes using a measurement signal as input, determining the second confidence level includes using the untrusted data and the trusted data as input, and determining the third confidence level includes using the untrusted data, the estimated untrusted data, and the corrected data as input.

[0026] In one implementation, a method includes receiving an estimated metabolic state, a corrected estimated untrusted metabolic input, a trusted metabolic input, and an alternative metabolic input; performing a replay prediction using the estimated metabolic state, the corrected estimated untrusted metabolic input, the trusted metabolic input, and the alternative metabolic input; and replaying the simulated metabolic state based on the replay prediction output.

[0027] The implementation may include some or all of the following features: The estimated metabolic state, the corrected estimated untrusted metabolic input, and the trusted metabolic input each comprise a time series. Performing the replay prediction involves estimating the metabolic state over the duration of the time series of the estimated metabolic state, the corrected estimated untrusted metabolic input, and the trusted metabolic input to generate the replay simulated metabolic state.

[0028] In one implementation, a method includes receiving an alternative metabolic input, a corrected estimated untrusted metabolic input, a trusted metabolic input, and a final estimated metabolic input; performing a real-time prediction using the alternative metabolic input, the corrected estimated untrusted metabolic input, the trusted metabolic input, and the final estimated metabolic input; and predicting a metabolic state based on the real-time prediction output.

[0029] The implementation may include some or all of the following features. Real-time prediction includes: extrapolating the corrected estimated untrusted metabolic input and the time series of the trusted metabolic input; and using the extrapolated time series, the alternative metabolic input, and the final estimated metabolic state to estimate the metabolic state to the future. The method further includes filtering the extrapolated time series to prevent jitter in the predicted metabolic state. The estimated metabolic state is in time series form. The method further includes filtering the estimated metabolic state to produce a predicted metabolic state. The estimated metabolic state uses a behavioral model of the subject. The extrapolated time series uses a weighted average of historical data based on at least one of the following: time of day, features of the current estimated state, or a database of past metabolic inputs.

[0030] The options provided in this summary to present the invention in a simplified form will be further described in the detailed description below. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Attached Figure Description

[0031] A better understanding of the foregoing summary of the invention and the following detailed description of illustrative embodiments can be achieved by reading in conjunction with the accompanying drawings. Example structures of the embodiments are shown in the drawings to illustrate the embodiments; however, the embodiments are not limited to the specific methods and means disclosed. In the drawings:

[0032] Figure 1 This is a diagram of an exemplary environment used to assess and visualize data discrepancies;

[0033] Figure 2 This is a block diagram illustrating the implementation of a diabetes management and processing platform;

[0034] Figure 3 This is a block diagram illustrating the implementation of a retrospective input compiler;

[0035] Figure 4 This is a block diagram illustrating the implementation of a real-time input compiler;

[0036] Figure 5 This is a block diagram illustrating how the replay compiler is implemented;

[0037] Figure 6 This is a block diagram illustrating how the prediction engine is implemented;

[0038] Figure 7 This is a block diagram illustrating how the parameter estimator is implemented;

[0039] Figure 8 This refers to the operational flow of the implementation method used for correction.

[0040] Figure 9 This refers to the operational flow of another implementation method for data correction.

[0041] Figure 10 It is the operational flow of the implementation method used to determine the credibility of data;

[0042] Figure 11 This is an operational procedure for another implementation of methods to determine data credibility;

[0043] Figure 12 It is the operational procedure for implementing methods that use untrusted data to provide outputs based on the effects of blood glucose;

[0044] Figure 13 It is the operational flow for implementing methods that use replay prediction;

[0045] Figure 14 This refers to the operational flow of implementing methods using real-time prediction; and

[0046] Figure 15 An exemplary computing environment in which example implementations and aspects can be implemented is shown. Detailed Implementation

[0047] The claimed subject matter is described with reference to the accompanying drawings, wherein the same reference numerals are used throughout to refer to the same elements. In the following description, numerous specific details are set forth for illustrative purposes to provide a thorough understanding of the claimed subject matter. However, it will be apparent that the claimed subject matter can be realized without these specific details. In other instances, structures and devices are shown in block diagram form to facilitate the description of the claimed subject matter.

[0048] This description should not be construed as limiting, but is merely intended to illustrate the general principles of the invention, as the scope of the invention is best defined by the appended claims.

[0049] This document describes various inventive features that can be used independently or in combination with other features.

[0050] Unreliable reports of unmeasured human behaviors and related metabolic events (e.g., meals and boluses) have a much greater impact than sensor errors inferred from signal processing of glucose time-series data. Therefore, unreliable data can be corrected with reliable data, providing corrected unreliable and reliable data as estimated metabolic data for predicting or replaying glucose time-series data.

[0051] In some respects, systems and methods are provided for correcting untrusted data of subjects using trusted data relating to the subjects. In some respects, the systems and methods are designed to evaluate the discrepancies between predicted data and corresponding received data.

[0052] As further described herein, retrospective prediction functions assess whether alternative insulin dosing strategies for the same meal would have better outcomes (e.g., lower glycemic risk). A retrospective prediction function takes a patient’s initial (e.g., pre-meal) state, one or more eating events, and an insulin dosing strategy as input, and then maps them to the glucose drift generated by that eating / day. In some implementations, the retrospective prediction function: (1) maps raw data (e.g., eating and insulin) to observations (e.g., CGM) with sufficient (e.g., predetermined) accuracy; (2) maps alternative dosing strategies to the resulting glucose drift in a manner that mimics patient (referred to herein as “subjects”) physiology (e.g., insulin activity and carbohydrate sensitivity); and (3) provides a reliable and interpretable solution to problems such as the estimation of onboard insulin as a stable and smooth function. The joint state estimator and eating estimation system and method described herein solve this function by combining known inputs and user-announced eating. The output is a function that can replay the alternative insulin strategy with the same input state (or the outcome of the alternative insulin strategy itself).

[0053] In implementation, replay functions can be constructed from the same dataset using other methods known to those skilled in the art of metabolic modeling. One example approach is to match the parameters of a known metabolic model with patient data or clinical studies. Another possible approach is to train a neural network with similar data to predict glucose drift.

[0054] Figure 1 This is an illustration of an exemplary environment 100 for assessing and visualizing data discrepancies; the environment includes an insulin device 110, a glucose monitor 120, a processor 130, a subject 140, an activity monitor 150, and a smartphone 160.

[0055] One or more of the insulin device 110, glucose monitor 120, processor 130, activity monitor 150, and smartphone 160 can communicate via a network. The network can be of various types, including the Public Switched Telephone Network (PSTN), cellular telephone networks, and packet-switched networks (e.g., the Internet). Although in Figure 1Only an insulin device 110, a glucose monitor 120, a processor 130, a subject 140, an activity monitor 150, and a smartphone 160 are shown. There is no limit to the number of insulin devices 110, glucose monitors 120, processors 130, subjects 140, activity monitors 150, and smartphones 160 that can be supported.

[0056] The insulin device 110 can be any device for dispensing insulin, such as a syringe, a pump (e.g., external, mechanical, patch, or implantable), and an inhaler, for example. The insulin device 110 may also include a device for dispensing other medications that help control glucose levels, such as glucagon (a dual-hormone artificial pancreas), GLP-1, etc.

[0057] Depending on the implementation, the glucose monitor 120 can be any type of CGM or SMBG (self-monitoring of blood glucose) device. The glucose monitor 120 can be a connected device that continuously provides glucose readings or provides a set of glucose readings as the device is scanned or downloaded. In addition to glucose readings, the glucose monitor 120 can record user interactions, such as when and how users (e.g., subjects, patients, caregivers, healthcare professionals, etc.) view their glucose traces and how they respond to alerts and alarms. User interactions can provide insights into the timing and motivation behind treatment decisions, including why and when they consider the effects of eating or administering insulin.

[0058] Processor 130 collects data from insulin device 110, glucose monitor 120, and subject 140 and runs the methods described herein. For a robust system, these computations can be dynamic and distributed, depending on the connected devices and processors. For example, cloud computing can be used when there are connectivity points, a smartphone processor can be used when there are no connectivity points, and then a transmitter or smartwatch can be used when the smartphone is not connected. Complex computations, such as model optimization, can only be run when a more powerful processor is available. When a powerful processor is unavailable, the algorithm may use state-of-the-art parameters or simpler approximations.

[0059] The processor 130 (along with the insulin device 110, glucose monitor 120, activity monitor 150, and / or smartphone 160) can be implemented using various computing devices, such as smartphones, desktop computers, laptops, and tablets. Other types of computing devices can be supported. Suitable computing devices are available in… Figure 15 The diagram shows a computing device 1500.

[0060] Subject 140 may use any computing device that communicates with the system, such as Subject 140's smartphone 160 or other computing device, to provide input to the system, including information about eating, activity, and diabetes treatment. This input may be initiated by the user or prompted by the system. This input may describe current, past, and / or upcoming events.

[0061] The activity monitor 150 can be any device that monitors a user's physical and mental state. One example is a fitness tracker, which uses accelerometers, gyroscopes, heart rate, and oxygen sensors to monitor activity, exercise, and sleep. This can also include smartphones, as they can detect location and user activity / interaction, or smart home devices (e.g., Amazon Alexa). In some implementations, the activity monitor 150 includes a device to detect eating.

[0062] The smartphone 160 can be used as an activity and context monitor by manual or automatic input (e.g., photos), a data input device, a data collection device (for communicating with devices with Bluetooth, NFC, Wi-Fi, etc.), and an application (e.g., an app) for running estimated nutritional information.

[0063] The systems and methods described in this paper estimate metabolic states based on a combination of trusted and untrusted metabolic inputs, and optionally using personalized mathematical models with parameter optimization. The systems and methods provide corrected untrusted inputs with the measured effects of blood glucose signals (using CGM) consistent with the metabolic model (optionally). The systems and methods described in this paper enable estimations of future metabolic states for decision support and automated insulin dosing. The confidence of the data, for example, instead of declaring an entire day as valid or invalid, provides a time series of confidence data along with the metabolic state estimation, avoiding the problems of modeling continuous processes such as overnight predictions. Scenario replays with estimated or corrected data are also provided. All data, including metabolic states (trusted and untrusted corrected), and the corresponding confidence, predictions, and replays, are provided from a time-domain perspective. This is further enhanced by one or more correction processes, retrospective predictions (also known as replay compilation), and prospective predictions (also known as real-time prediction compilation) implemented in this paper.

[0064] Figure 2 This is a block diagram illustrating the implementation of the diabetes management processing platform 200. Platform 200 uses calibration, replay analysis, prediction and / or confidence determination, and optional parameter optimization to predict future analyte values ​​or unobserved states, inform dosing decisions, assess onboard carbohydrates, assess onboard insulin, enable smart alerts, deliver retrospective treatment optimizations, and, for example, provide feedback for estimations. The diabetes management platform 200 includes modules, their inputs, outputs, and interrelationships, which are further described herein.

[0065] Platform 200 includes an input compiler 220, a replay compiler 230, a prediction engine 250, and a parameter estimator 270. Input compiler 220 includes a retrospective input compiler 220R and a real-time input compiler 220L. Depending on the implementation, platform 200 may include more or fewer modules. In some implementations, for example, parameter estimator 270 is optional.

[0066] Data is provided to input compiler 220 and may include measurement signals, indirectly observed trusted metabolic inputs (i.e., trusted metabolic inputs), indirectly observed untrusted metabolic inputs (i.e., untrusted metabolic inputs), and an estimated initial state describing the patient's condition at the first data point. Examples of measurement signals include blood glucose data from a blood glucose monitor (BGM) or continuous glucose monitor, or insulin delivery data from a connected insulin pen or insulin pump. Examples of trusted metabolic inputs include reports of eating or physical activity by professional caregivers in a clinical setting, ensuring accuracy in terms of time, extent, and content. Examples of untrusted metabolic inputs include on-site reporting of eating or physical activity using pencil / paper (e.g., handwritten) diaries or the recording functions of medical devices, but these functions cannot guarantee accuracy.

[0067] The input compiler 220 processes retrospective data 210 using a retrospective input compiler 220R and processes real-time data 212 using a real-time input compiler 220L. The retrospective data 210 is provided to the retrospective input compiler 220R and the parameter estimator 270, and regarding, for example... Figure 3 and Figure 9 Further description. Real-time data 212 is provided to the real-time input compiler 220L. Real-time data 212 may be real-time, within a specific time window, or during a processing cycle, depending on the implementation. Real-time data 212 relates to, for example... Figure 6 and Figure 9 Further description.

[0068] In the implementation, the input compiler 220 includes a state estimator (e.g., Figure 3 and 6The state estimator 340 shown can use a personalized physiological model to generate outputs such as corrected estimated metabolic inputs, the patient's estimated metabolic state during the input data period, a numerical assessment of the confidence level of the estimated state, and a numerical assessment of the confidence level of the corrected estimated metabolic inputs. The corrected estimated metabolic inputs, along with their correlation to the confidence level assessments of the estimated metabolic state and the confidence level of the corrected estimated metabolic inputs, are used. In addition to being used in interconnected modules of the system, corrected data, such as corrected food intake and insulin history, can be reported to the patient or other users.

[0069] The replay compiler 230 uses the output 225R of the input compiler 220 (i.e., the output 225R of the retrospective input compiler 220R) to operate on the retrospective data 210, and a state estimator using estimated model parameters 275, which may be a personalized physiological model, and the replay user needs and component model 235, to produce outputs such as the replay prediction function 240 and / or other replay analyses. The replay prediction function 240 can operate on alternative metabolic inputs (different from the corrected metabolic inputs) in the form of substitute inputs or substitute strategies, producing replay predictions and associated prediction confidence in the form of simulated metabolic outcome trajectories of the substitute metabolic inputs. The resulting replay prediction function 240 can be used for a variety of applications, including retrospective treatment optimization or retrospective insights about treatment. The evaluation of the replay prediction confidence is directly related to the confidence of the corrected estimated metabolic inputs, both of which implement the further features and functions described herein. For example, other applications and outputs of the replay compiler include basal titration, demonstrating the effect of bolus time versus feeding time, and validation of the AP algorithm.

[0070] The prediction engine 250 uses input 225L of a real-time input compiler 220L that operates on real-time data 212, and a state estimator that estimates model parameters 275, which may be an individualized physiological model, and predicts user needs 253 to produce a real-time input-corrected prediction 255. The real-time input-corrected prediction 255 operates on candidate current and future metabolic inputs to produce a real-time prediction in the form of a predicted trajectory of metabolic outcomes with the candidate inputs, along with the confidence level of the associated prediction. The real-time input-corrected prediction 255 can be used for a variety of applications, including comparisons for (i) real-time decision-making, including selecting the next control step in closed-loop diabetes management, predictive push advisory services, and decision support, and (ii) for generating real-time insights, such as alternative actions for smart alerts. The evaluation of the confidence level of the real-time input-corrected prediction 255 is directly related to the confidence level of the corrected estimated metabolic inputs, both of which enable the further features and functionalities described herein.

[0071] The parameter estimator 270 uses patient biostatistics and demographic information 273, along with retrospective data 210 and the output 225R of the retrospective input compiler 220R, to determine and output estimated model parameters 275 (e.g., state estimator, which may be an individualized physiological model). Individualized physiological models are helpful but not required in the implementation. The parameter estimator 270 is useful in the context of implementations that use individualized models for estimation but are not critical requirements.

[0072] Figure 3 This is a block diagram illustrating the implementation of the retrospective input compiler 220R. Broadly speaking, this approach, combining trusted and untrusted metabolic inputs, can be applied to any temporal data input for which uncertain accuracy and reliability correction are sought. The retrospective input compiler 220R includes a metabolic input estimator 320, a reliability estimator 310, an input corrector 330, and a state estimator 340.

[0073] Such as about Figure 2 As described, retrospective data 210 is input to a retrospective input compiler 220R. The retrospective data may be in various formats, including measured signals or inputs, trusted metabolic inputs, untrusted metabolic inputs, and one or more estimated states. In the retrospective input compiler 220R, inputs are classified as trusted or untrusted, and various estimates are determined. An estimate of the untrusted input is calculated in the form of a corrected estimate of historical metabolic inputs, for example, using an unconfirmed estimate of carbohydrates and corrected against the received data.

[0074] Measurement signals are included in retrospective data 210 and provided as input to retrospective input compiler 220R, and more specifically to metabolic input estimator 320. Measurement signals are typically measurements of glucose levels, including, for example, real-time CGM readings, confidence readings assigned to CGM values, self-monitoring blood glucose readings (glucose meters), and / or retrospectively calibrated or corrected CGM readings, as well as other measurement signals such as insulin measured by an internal insulin sensor.

[0075] Metabolic inputs are included in retrospective data 210 and provided as input to the retrospective input compiler 220R, and more specifically to the metabolic input estimator 320. Metabolic inputs can typically be considered based on both the event and the time (time and magnitude). Examples may include estimating metabolic state based on known metabolic inputs recorded by an insulin pump and uncertain metabolic inputs describing user-recorded food intake.

[0076] Trusted metabolic inputs are known metabolic inputs that can be directly recorded by electronic / electromechanical devices and / or estimated by machines. Examples include insulin pumps and connected insulin pens that record insulin injection times. These devices directly measure the action of the pump or syringe to dispense insulin with high precision. Note that malfunctions such as occlusion can still cause indeterminate infusion rates. Regarding insulin delivery, the systems and methods envisioned in this paper do not depend on a specific delivery model (e.g., pump versus pen).

[0077] Untrusted metabolic inputs are indeterminate metabolic inputs that can be entered by the user. Indeterminate inputs can be considered based on the event and time (e.g., time and magnitude). An example is user input providing the carbohydrate content and time of an ingested food, manually entered on a mobile app. More broadly, it includes any time-series input that relies on user input but is not verified by the connected device, such as insulin administration using an unconnected pen or pump. This might include cases where carbohydrates are estimated by another mobile app (e.g., ByteSnap). In principle, untrusted metabolic inputs can also be due to unreliable insulin action caused by variability in infusion pumps and infusion sites. This is the uncertainty surrounding inputs from these systems that are dynamically adjusted for retrospective measurements (e.g., CGM). Untrusted can refer to inaccurate timing or content of event data, such as meals. Untrusted metabolic inputs can also include factors that are difficult for the user to quantify, such as exercise or disease. There are also some untrusted metabolic inputs arising from inputs measured indirectly.

[0078] Food input is defined based on time and the amount of carbohydrates. User input (food posting) is typically defined as a single carbohydrate event. Some exemplary user inputs that may be untrusted include: users estimating the amount of carbohydrates or other nutritional information about what they are eating; for example, a user might estimate a burrito but not the fries and salsa eaten while waiting; a meal simplified to small-medium-large qualifiers; a meal simplified to the amount of carbohydrates without considering the glycemic index; food responses also depending on fat and protein content; when users enter a pre-meal push, they are anticipating when they will eat; after the system detects a food response, the user is prompted to recall when they ate; and the system records the time of a single meal, including appetizers, main courses, and desserts.

[0079] Some examples of untrusted metabolic inputs derived from indirectly measured inputs include: eating apps that estimate carbohydrates using databases, barcodes, restaurant photos, etc.; eating apps that categorize upcoming meals based on previous meal records; exercise intensity and duration estimated from fitness trackers (heart rate / accelerometers); and sleep duration estimated from fitness trackers.

[0080] Table 1 shows examples of metabolic inputs with known and uncertain inputs.

[0081]

[0082] Table 1

[0083] The last row in Table 1 considers “unreliable insulin action” due to variability in the infusion pump and infusion site. In other words, the pump reliably records plunger movement, but the insulin may not reach the body due to problems with the infusion site or catheter. Therefore, in some implementations, the amount of insulin pumped needs to be corrected for by the observed (missing) insulin action.

[0084] For example, other inputs could include the presence of gut and glucose, sensor hysteresis, and could be extended to general metabolites.

[0085] The estimated initial state is the data included in the retrospective data 210 and is provided as input to the retrospective input compiler 220R, and more specifically to the metabolic input estimator 320. The estimated initial state provides the initial state for the blood glucose model, including glucose levels (blood and other compartments), insulin levels (blood and other compartments), carbohydrate levels (due to previous food intake), and metabolic demands (the effects of previous exercise and current activity levels). This is likely a vector, as it defines these quantities at a certain point in time (the initial state).

[0086] In some implementations, one or more model parameters 275 may be provided as input to the retrospective input compiler 220R (e.g., to the input corrector 330).

[0087] The output of the retrospective input compiler 220R includes (i) corrected estimated metabolic inputs (including trusted and untrusted inputs), (ii) corresponding metabolic state estimates, and (iii) an assessment of the confidence of the input and state estimates.

[0088] More specifically, the metabolic input estimator 320 receives and processes retrospective data 210 and generates (outputs) estimated untrusted metabolic inputs and interference inputs 325.

[0089] The metabolic input estimator 320 can use a personalized mathematical model, which is a compartmental model of the metabolic processes by which glucose is produced or consumed in the body. For example, the terminology of the model describes the increase in glucose after a meal and the absorption of that glucose into muscle and adipose tissue in response to insulin stimulation. The model is personalized to account for differences in insulin action and dietary metabolism, as well as between subjects with diabetes (e.g., type 1 vs. type 2).

[0090] In one implementation, the systems and methods described herein estimate the time series of uncertain metabolic inputs and the state itself, which may include estimating unknown / incompletely observed events. In this implementation, metabolic input estimation is based on measured signals, past estimated metabolic states, and known metabolic inputs, which are extracted to form a vector of measurements, inputs, and corresponding initial states. At this stage, uncertain inputs (e.g., reported eating) are not considered inputs. Only those previously known and measured are input. The raw inputs are transformed into vectors of appropriate length, depending on the use case (e.g., real-time 6 hours versus retrospective use of an extended 36-hour period to obtain a complete daily cycle and avoid edge effects / boundary conditions). These are the measured signals. The data range (time span) depends on the application (i.e., the implementation) and may range from minutes to hours to days. The data can then be aligned, snapped, interpolated, and smoothed as needed for the implementation. Next, the system uses a linear dynamic model (e.g., without mapping) to determine the system residuals, which are the differences between the measured signals and the model-predicted effects of the estimated initial metabolic states and known metabolic inputs. Then, based on the fit to the system residuals and the shape of the estimated unknown inputs (e.g., regularization), the unknown inputs that best explain the system residuals are computed. For example, the fitting setting penalty emphasizes (i) high-confidence samples, (ii) the last sample, (iii) the last rate of change, and (iv) important samples (e.g., hypoglycemia or hyperglycemia), and setting the regularization penalty to achieve the desired properties may include (i) the smoothness or discreteness of the estimated unknown inputs, (ii) allowing / disallowing bias, and (iii) allowing / disallowing high rates of change or acceleration (other setting constraints may include specifying nonnegativity (e.g., eating)). This is a type of inverse problem solved by regularized deconvolution. The challenge is to restrict the inverse to physically reasonable and interpretable values ​​that are reasonably consistent with the measurement results (CGM trace), initial conditions, and provided inputs. Since such constraints can be imposed, including nonnegativity of eating, regularization of episodic eating, and slowly changing insulin differences over time to achieve the desired properties, the importance of the fitted data can be dynamically adjusted based on quality. From these calculations, the vector of the estimated metabolic state trajectory can be extracted, and the original estimated uncertain metabolic input can be extracted.

[0091] The credibility evaluator 310 generates a credibility 315R output (output credibility value). Credibility 315R is derived from the difference between the original estimate and the reported one from untrusted input.

[0092] The reliability evaluator 310 evaluates multiple inputs, including measured signals, known metabolic inputs, reported uncertain metabolic inputs, raw estimated metabolic states, uncertain metabolic inputs, and corrected uncertain metabolic inputs, all of which can be provided in time series.

[0093] The confidence level of the measured signal can be used to assess the continuity (e.g., lack of continuity) or integrity of time series data, and can include confidence thresholds for sensor assessment, calibration events, maximum gap size, fluctuation range, period range, etc.

[0094] Based on known metabolic inputs and raw estimated metabolic states, as well as the confidence level of uncertain metabolic inputs, it is possible to estimate expected behavior that indicates incomplete data or lacks uniformity, and may include one or more of the following: expected correlations between inputs (uncertain or known), expected event counts, fluctuation ranges / cycle ranges, etc.

[0095] The confidence level of reported uncertain metabolic inputs, raw estimated metabolic inputs, uncertain metabolic inputs, and corrected uncertain metabolic inputs can be used to estimate local variance versus population variance (indicating undeclared or unreported inputs), discrepancies between reported and estimated uncertain inputs, pattern matching, fluctuation / cycle range, etc.

[0096] The confidence evaluator 310 summarizes one or more of the above confidence evaluations and provides (outputs) the confidence of the final estimated metabolic state and the corrected estimated inputs, which may include the confidence as a time series.

[0097] The reliability evaluator 310 can determine CGM continuity, fit quality, total carbohydrates, number of carbohydrate events, carbohydrates corresponding to BG artifacts, consistency with user-reported carbohydrates, and accuracy of insulin data (especially in MDIs).

[0098] In some implementations, the aggregate reliability of data collected at a specific time of day can be assessed by averaging reliability scores across multiple days. A low average reliability score at that time may indicate a systematic problem with the data collection method. For example, if a patient uses an unconnected pen to bolus food while at work, this will result in a high insulin level at that time of day, which is highly variable over time, translating to a lower average reliability score at that time of day. As another example, if a patient consistently confirms that their regular meals sometimes deviate significantly from their estimated carbohydrate intake, this could lead to lower reliability scores at both the actual mealtime and the confirmation of mealtime.

[0099] Input corrector 330 corrects uncertain, untrusted user input with estimated input, wherein the correction is based on one or more of a measured signal, trusted metabolic input, untrusted metabolic input, and model parameters. These methods do not necessarily estimate a penalty for the degree of closeness to the reported input; rather, they can estimate an sigmoid waveform of the reported and estimated input over time. In some implementations, these methods can learn patient-typical errors over time. Input corrector 330 outputs corrected estimates of metabolic input and interference for further processing and / or display.

[0100] The state estimator 340 provides an estimate of what is actually happening in the system. The process disturbance here is allowed to be non-zero (e.g., non-zero mean) and is not a measurement error. The output of the state estimator is an estimate of the state, which can be multiple vectors / matrices.

[0101] In one implementation, the state estimator receives an initial metabolic state (from past state estimates), a known metabolic input (vector), and a corrected uncertain metabolic input (vector). After estimating and correcting the input time series, all that remains to be computed is the associated state trajectory, which is output as the final estimated metabolic input vector.

[0102] In one exemplary model, the interaction between insulin and glucose clearance is captured using two differential equations that incorporate different types of insulin (e.g., rapid and long-acting) and different equilibrium compartments (e.g., the liver) used for intensive insulin therapy. Other metabolic models can be used within the same framework for prospective and retrospective estimations. A trade-off is made between physiological integrity and stability / observability. For example, a simple model can incorporate physiologically separated details or compartments with several types of mass transfer, while a more complex model can address inter-patient variability or differences in glucose-insulin behavior over time. In practice, there are limitations to the complexity of models that can be observed using only CGM data and observational data (e.g., normal daily variations), as more complex models may require clinical studies with additional measurements, such as multiple tracers or well-described inputs, such as OGTT (oral glucose tolerance test) or meals containing known components (fat / carbohydrate / protein). However, more complex models can be used to address input-based problems based on corruption.

[0103] Here, the confidence level of one or more estimated metabolic states can be determined independently of the confidence level determination that can be performed on corrected, untrusted metabolic inputs, including the confidence level of corrected estimated metabolic inputs and the confidence level of estimated metabolic states.

[0104] The output of the retrospective input compiler 220R includes corrected estimated metabolic inputs, which are untrusted metabolic inputs that have been estimated and corrected. Trusted metabolic inputs can be considered pass-through inputs and therefore can be output in their raw form in some implementations. It is important to note that these inputs and outputs do not include uncertainties in the model parameters, such as insulin sensitivity.

[0105] Exemplary outputs of the retrospective input compiler 220R may include transients of blood glucose signals caused by different effects (BG variability feature markers) and perturbations describing transients of signals due to changes in oral carbohydrates and other effects, which may be divided as follows: postprandial response to OC (oral carbohydrate) mixed meals (adjusted to account for previous carbohydrate and insulin delivery); signals explaining low-frequency changes in blood glucose concentration consistent with changes in insulin sensitivity; and signals explaining aspects of the blood glucose trail that cannot be interpreted as a postprandial response or changes in insulin sensitivity, such as eating due to posture, physical activity, or (potentially) not well-suited to the characteristics of a “mixed” meal.

[0106] It is also possible to determine the estimated net oral carbohydrate effect. A meal can be broken down into several discrete carbohydrate signals. Glucose can be added from endogenous sources such as the liver to simulate net oral carbohydrates.

[0107] Other behaviors or physiological events that may be captured include, for example: glucose consumption during exercise (which acts similarly to insulin because it increases glucose uptake); changes in insulin sensitivity after exercise; daily variations in insulin sensitivity (diurnal variation); differences between onboard insulin curves and insulin curves; and unrecorded boluses.

[0108] Metabolic state estimation 345R includes time series of insulin and glucose levels in the model compartment, as well as CGM signal.

[0109] The final corrected eating history includes both time and net carbohydrates. Insulin delivery is a pass-through of the retrospective input compiler 220R.

[0110] Therefore, in the retrospective input compiler 220R, the estimation of the patient's metabolic state is based on a confidence assessment (confidence level of what the patient ate and when) from both a trusted data stream and an estimation stream from currently untrusted data (associated with the estimated state trace for each estimated time period). This can be done historically for data from the previous month, but also for newly received data, such as the real-time data 212 further described herein, for example, with respect to the real-time input compiler 220L.

[0111] Figure 4This is a block diagram illustrating the implementation of the real-time input compiler 220L. The real-time input compiler 220L includes the same components as the retrospective input compiler 220R, but uses real-time data 212 as input instead of retrospective data 210. Therefore, like the retrospective input compiler 220R, the real-time input compiler 220L also includes a metabolic input estimator 320, a confidence estimator 310, an input corrector 330, and a state estimator 340.

[0112] The output fields of the real-time input compiler 220L are the same as those of the retrospective input compiler 220R, except that they are based on real-time data 212. Therefore, the output of the real-time input compiler includes confidence 315L, recorded estimates of metabolic inputs and interference 335L, and metabolic state estimates 345L. In this way, untrusted fragments of real-time data 212 are corrected based on other available data. For example, metabolic inputs (such as carbohydrates) from the past 6 hours can be estimated, as can the corresponding states and confidence levels from the past 6 hours.

[0113] Using the Real-Time Input Compiler 220L, patients interact with the system and methods in real time. Patient behavior is not as consistent as with AP systems and does not always provide accurate data (e.g., erroneous carbohydrate reports due to counting problems, timing issues, or both). An example application can suggest when and / or how much food appears to have been consumed, allowing patients to confirm or deny, or modify, the suggested food information. This enables food / exercise detection and plasma glucose prediction. In the example of glucose prediction, the system and methods described herein are able to predict glucose levels for the next two hours using data from the past 6 hours. Furthermore, the reliability of sensor data (how close it is to calibration, whether the signal is unstable, whether the sensor is out of range) can be determined and used for overall carbohydrate and insulin reliability measurements. Similarly, the reliability of insulin data (missing baseline data, unexplained glucose concentration drops (unconfirmed boluses), etc.) can be determined. This system and method allow for intelligent interaction and decision-making that knows the correction between detected and reported data.

[0114] When processing real-time data, it is crucial to pay particular attention to recent values ​​and their slopes, as there is no benefit from future knowledge. For example, the estimator may be required to find consistency between the most recent points (the last two) by weighting the most recent data to a greater extent. In one implementation, the input corrector vector extracts the reported uncertain metabolic input for real-time applications, where the resulting vector makes the last input correspond to the current time. One or more extracted vectors, combined with the original estimated uncertain metabolic input vector, are combined in a function based on time relevance and / or relative confidence, as described below.

[0115] Example 1 (for a real-time predictor): Weights are applied based on time relevance, with the most recently reported inputs having the highest weight, long-term past reports having a lower weight, and the most recent raw estimated input (if any) having a lower weight. This is because it requires future data.

[0116] Example 2 (for real-time or retrospective): Apply weighted averages to the relative confidence of reported and estimated untrusted inputs, where confidence is based on user / system ratings of the estimated inputs and / or model-based confidence.

[0117] In one exemplary application, the system and method estimate carbohydrate intake independently of user input. Data suggests this is the safest assumption for patients treated with multiple daily injections (without using a smart pen). The system and method consider the situation where the carbohydrate estimate reported by the patient is inconsistent with the estimated carbohydrate intake independent of user input. Because the system and method cannot treat both the estimated and reported carbohydrate estimates as true, a correction process is useful. During correction, the system and method represent the corrected result as a new pair of corrected estimated inputs.

[0118] Figure 5 This is a block diagram illustrating the implementation of the replay compiler 230. The replay compiler 230 includes an input classifier 510 and a replayer core 520. The replayer core 520 includes an input modifier 523 and a dynamic equation 525. The replay compiler 230 replays glucose traces by modifying the input to determine the effect of the modified input. The replay compiler 230 provides a machine for evaluating blood glucose (BG), insulin, eating, and behavioral outcomes at different ranges (individuals / groups) with different masks (loop closure, sleep, confidence, etc.). This system and method simulates scenarios for any suboptimal intervention in diabetes to determine the optimal intervention and quantify the effect of the optimal intervention—as optimal vs. suboptimal CGM tracking or glycemic effect.

[0119] The input to the replay compiler 230 is retrospective compilation input (i.e., the output 225R of the retrospective input compiler 220R), which includes confidence level 315R, corrected estimates of metabolic inputs and disturbances 335R, and metabolic state estimates 345R (e.g., estimated metabolic state, final corrected estimated metabolic inputs, known metabolic inputs, and alternative metabolic inputs (specific inputs or strategies for the duration of the time series). In some implementations, the input includes all metabolic inputs (trusted and untrusted corrected estimates) as time series and confidence level.

[0120] The input classifier 510 receives corrected estimates of metabolic input and disturbance as input and classifies each data point as either a modifiable exogenous metabolic input 512 or an invariant exogenous input 515.

[0121] In some implementations, trusted data (e.g., insulin) can be modified. In other implementations, both trusted and untrusted data segments (e.g., food intake data) can be modified. In still other implementations, all inputs can be modified.

[0122] The replay compiler 230 can envision various scenarios: A) all untrusted calibration data is modified in the replay function; B) some, but not all, of the untrusted calibration data is modified in the replay function; C) some trusted data is modified in the replay function; and D) a combination of B) and C). Generally, the replay compiler 230 modifies at least some data and runs at least one simulation. For example, it might be a trusted data segment, such as insulin. Sometimes, it is both a trusted and untrusted data segment, like insulin and eating (e.g., replacing the calibrated injectable carbohydrates with some other scripted eating behavior, leaving the BG variability feature marker as the only unmodified). In an exemplary implementation, all inputs are modified.

[0123] The replayer core 520 includes an input modifier 523 and a dynamic equation 525. The input modifier 523 receives a modifiable exogenous metabolic input 512 and a rule specification 550 (also called rule specification 550) for modifying historical inputs.

[0124] Input 512 is therefore modified at input modifier 523 using rule specification 523. Rule specification 523 is a "hypothetical" scenario that will be tested to determine the outcome based on the input modification. Rules can be selected by the user individually and / or based on preset scenarios. Some rules that may be specified compare the following: conversion from MDI to CSII (continuous subcutaneous insulin infusion) or vice versa, long-acting dose / time, basal rate curve, identification / removal of hypoglycemic treatment in historical data, modification of historical bolus, modification of bolus dose parameters, insertion of prospective hypoglycemic treatment when alternative insulin infusion produces new hypoglycemic instances, replacement of historical eating scenarios with a prospective model, and replacement of historical carbohydrate confirmation with a prospective confirmation model (e.g., confirmed carbohydrates are sometimes close to estimated carbohydrates).

[0125] Additional rules and regulations can be designed to address and estimate: exercise and / or how to optimize treatment around exercise; treatments including rescue carbohydrates (e.g., the required amount); treatments including other feeding strategies (e.g., split, delayed, and extended feeding); and type 2 treatments, including oral medications, etc.

[0126] Rule specifications can be provided directly by the patient, based on invocation of specific pre-programmed functions, based on user interfaces such as reporting and analysis software and / or other interfaces that allow users to select specific scenarios (“What if I had injected earlier?”), ask specific questions (“What if I had received pump therapy?”) and / or modify specific inputs (“What if I had taken two additional units of insulin at the time of the bolus?”), or similar, as those skilled in the art will understand. Choices can be real-time or retrospective and can be presented at various levels of granularity.

[0127] The output of the input modifier 523, together with the invariant external input 515, metabolic state estimate, and model parameters 275, is provided as input to the dynamic equation 525.

[0128] In its implementation, the dynamic equations can use a separate mathematical model, which is a compartmental model of the metabolic processes by which glucose is produced or consumed in the body. For example, the model's terminology describes the increase in glucose after a meal and the absorption of that glucose into muscle and adipose tissue in response to insulin stimulation. The model is individualized to account for differences in insulin action and dietary metabolism, as well as between subjects with diabetes.

[0129] Dynamic equation 525 replays the input. The replay runs a model-based estimation using any known model-based method that considers eating and / or insulin parameters. For example, the model could use a standard mixed diet, which is typically a combination of carbohydrates, protein, and fat. However, other eating characteristics could be used, such as high-carbohydrate / glycemic diets and / or low-carbohydrate / glycemic diets, or even combinations of various types of diets. Some implementations could add long-acting versus short-acting diets based on components and glycemic index, etc. This would be run as part of a correction. If the eating action differs significantly from a standard diet, it may be interpreted in a way that results in lower physiological accuracy. For example, 30 g of carbohydrates in a pizza would be estimated using an initial 30 g meal followed by two 10 g meals.

[0130] In this implementation, the metabolic state is estimated over the duration of the input time series, and the personalized mathematical model is pushed forward to the end of the input time series.

[0131] Model parameter 275 is an optional estimate, useful but not required, and can be used as feedback input to make the parameters more personalized for patients.

[0132] The replay confidence score (580) is determined by the replay compiler and its output. In the replay analysis, the replay compiler (230) identifies and outputs credible instances of a specific scenario (sample). This is done by assigning a confidence score to each sample (e.g., each replay analysis result). For example, identifying credible instances of successfully avoiding hypoglycemia; failing to avoid hypoglycemia, and / or skipping or significantly delaying food bolus administration. The average confidence score of the samples in the dataset during the replay analysis provides the overall reasonableness of the importance / confidence of the replay results, which may help in interpreting the results.

[0133] A comparator may be included within the replay compiler 230 to compare various time series from dynamic equation 525 based on the credibility of the data (weighting such that untrusted data is ignored or has low weight). Another example is that if the BG variability feature label is unstable, then the data may become unreliable within that time period. Those skilled in the art will understand that there are many ways to identify patient data that are inconsistent with the model.

[0134] In this implementation, the BG outcome metric is evaluated based on one or more of the following replay time series: sample mean, sample variance, time within range, occurrence of high / low BG, risk of hypoglycemia, risk of hyperglycemia, and overall risk. Unlike traditional techniques that calculate average blood glucose by averaging all samples, this paper uses a confidence score for each sample to determine the average weight for each sample.

[0135] The output of dynamic equation 525 includes a replay prediction time series 570. This output (time series 570) can be provided to input modifier 523 for subsequent use and may include replay simulated metabolic states generated from alternative inputs with confidence scores. The output may include simulated time series, results of compared time series (worst / best / actual), recommendations based on the compared time series, and any other data processed by the system (e.g., confidence scores).

[0136] In some implementations, the functional output of the replay compiler 230 may be a reproduced (simulated) CGM trace that the patient actually experienced. The replay compiler 230 is a function that reproduces the trace when run on a historical CGM, in which case the CGM trace will be a smoothed version of the CGM trace without sensor inaccuracies, and includes additional information such as additional relevant data not provided by the patient (e.g., eating).

[0137] In treatment optimization within DSS (Decision Support System) or AP use cases, the replay compiler 230 can optimize treatments such as total daily basal insulin, where the input will be the parameter to be optimized (actual basal insulin), and the output will be an optimized version of that input (optimal basal insulin). The replay simulation parameters are used to optimize the optimal prescription amount / time (in one instance, the total daily basal insulin).

[0138] In patient education use cases, dynamic reports (retrospective or real-time) can be generated, allowing patients to highlight or drag scenarios and view the results of the "hypothetical scenario" returned from the replay compiler 230. For example, a slider in the graphical user interface could allow patients (or other users) to swipe around and then view the effects of the replay analysis (more carbohydrates, less carbohydrates, higher blood sugar, lower blood sugar, earlier bolus, later bolus, more insulin, less insulin, etc.).

[0139] In some implementations, the output of the average confidence score of a sample of the dataset in the replay analysis gives the overall reasonableness of the importance / confidence of the replay results.

[0140] In some implementations, risk stratification tools for healthcare professionals may be provided as outputs that identify patients by specific categories or needs (e.g., patients with minimal pre-meal bolus compliance) and may include the potential benefits of treatment adjustments.

[0141] In some implementations, the output can highlight / prioritize the most impactful potential changes in the reporting interface (e.g., changes in insulin timing and bolus volume or highlighting optimal eating).

[0142] In some implementations, the output can be triggered by coaching follow-ups or chatbot prompts to generate coaching comments and discussion points.

[0143] Figure 6 This is a block diagram 250 illustrating the implementation of the prediction engine. The prediction engine 250 receives retrospective compilation output 225R and real-time compilation input 225L as inputs, along with model parameters 275 and prediction user requirements 253, and outputs real-time predictions 255.

[0144] The initial state of the prediction engine 250 will describe the amount of insulin and carbohydrates already in the body and acting on glucose levels. Without additional action, the prediction engine 250 will predict future metabolic states, such as glucose fluctuations from the previous meal and hypoglycemic events. The predictions are corrected extrapolations from the input compiler 220. In other words, the predictions also respond to historical data as well as corrected data.

[0145] The prediction engine 250 includes an input extrapolator 610, an input filter 620, a metabolic state estimator 630, an output filter 640, and an initial condition extractor 650.

[0146] Input extrapolator 610 uses the predicted user demand 253, confidence and correction estimates of metabolic inputs and interferences from retrospective compilation output 225R, and confidence and correction estimates of metabolic inputs and interferences from real-time compilation input 225L for extrapolation. Extrapolated data is provided from input extrapolator 610 to input filter 620.

[0147] Input extrapolator 610 extrapolates the input time series to take into account (1) additional information about the future that is available in real time (e.g., expected eating, exercise, etc.) and (2) BG variability feature markers.

[0148] The input extrapolator 610 can use the retrospective compilation output 225R to make inferences based on historical data, for example, using the effects of recent past feature labels of BG variability (i.e., disturbances) and historical feature labels of BG variability. The BG variability feature labels can be used to interpret the data as it further enters the prediction range.

[0149] The prediction engine 250 can project disturbances (BG variability feature markers), which show the inaccurate trends in the data caused by differences in the corrected data. The disturbance signal is a result of the correction process and can be considered as an estimated unknown signal. For example, disturbances may be caused by circadian rhythms, motion trends, etc. The accuracy of the prediction depends on different assumptions about the future based on the nature of the disturbance.

[0150] Input filter 620 filters extrapolated data using predicted user demand 253 and provides its output to metabolic state estimator 630.

[0151] Depending on the implementation, input filter 620 is optional, but it can be useful when other filtering or smoothing has not yet been applied to one or more inputs. Input filter 620 filters or smooths the extrapolated input time series to prevent jitter in the predicted trajectory from (1) sensor noise and (2) rapidly evolving understanding of recent untrusted inputs. In some implementations, input filter 620 uses a low-pass filter to minimize jitter in the predicted trajectory during successive updates.

[0152] The initial condition extractor 650 extracts data from the metabolic state estimate of the real-time compiled input 225L and provides the extracted data to the metabolic state estimator 630.

[0153] The metabolic state estimator 630 receives filtered and extracted data as input, along with predicted user demand 253 and model parameters 275. The metabolic state estimator 630 processes these inputs and provides the output to the output filter 640.

[0154] The metabolic state estimator 630 receives (optionally filtered) one or more extrapolated inputs, extracted initial conditions, and model parameters to the extent that the estimator is using a personalized physiological model. Various estimators may be useful. In one implementation, the metabolic state estimator 630 performs an open-loop estimate of future metabolic states based on the best estimate of the metabolic state vector at the start of the time series, pushing the personalized physiological model up to the end of the prediction range.

[0155] In some implementations, the metabolic state estimator 630 may use a personalized mathematical model, which is a compartmental model of the metabolic processes that produce or consume glucose. For example, the terminology of this model describes the increase in glucose after a meal and the absorption of that glucose into muscle and adipose tissue in response to insulin stimulation.

[0156] Output filter 640 filters the output from metabolic state estimator 630, as well as the reliability and correction estimates of the metabolic input and disturbances from real-time compilation input 225L, for user demand 253, and provides its output as real-time prediction 255. Output filter 640 can be used to limit real-time prediction 255 based on the real-time compilation output 225R.

[0157] The output filter 640 is an output module that presents the predicted output time series (i.e., real-time prediction) as (1) allowing drastic changes in the predicted trajectory only if there are identifiable and significant changes in the corrected input and / or (2) filtering / smoothing or otherwise preventing jitter in the predicted trajectory due to sensor noise.

[0158] Real-time predictions (i.e., real-time forecasts) can be a predictive profile of future BG (e.g., in vector form) and can be used to inform future decision-making. For example, a prediction could indicate impending hypoglycemia, and then that prediction could be used to alert and / or prompt the patient to take a fast-acting glucose tablet. The corrections and predictions described herein allow for greater responsiveness to changes in patient behavior and, therefore, better prediction of metabolic status.

[0159] In some implementations, real-time prediction 255 is a vector predicting metabolic state. The stability of the resulting predictions remains stable until a marker of an impending state change appears (e.g., meals and insulin allow for more dynamic output). Patient-provided inputs and detected inputs lead to credible changes in the patient's expected inputs.

[0160] In some implementations, the prediction engine 250 can apply conditional weighting to the data, where historical data can be weighted based on (1) the time of day, (2) the characteristics of the current estimated state, and (3) auxiliary information. In some implementations, conditional weighting is based on the final estimated metabolic state, a database of past metabolic inputs (trusted and untrusted), and auxiliary information.

[0161] The future BG variability feature labeling is a key differentiator in Prediction Engine 250. Additional key advantages, which can be used individually or in combination, include: corrected feeding, input extrapolation (e.g., feeding set to zero); and BG variability feature labeling based on time-of-day notifications from retrospective models and daily trends. Typically, for real-time predictors, this is re-runned in the last 6 hours of the data start point.

[0162] The weights of the BG variability markers depend on patient compliance and on the availability and reliability of the reported and corrected data (e.g., on the time since the event).

[0163] The systems and methods described in this paper offer a trade-off for time-domain prediction, where more weight is given to the correction inputs of the most direct values. Conditional weighting allows these models to be adapted to specific variations.

[0164] In some implementations, the confidence of the predicted state is calculated based on the confidence of the input (including the original input and the corrected input). Using confidence in corrected real-time predictions includes: (1) determining the confidence of the medical action by correcting the prediction, i.e., if the general confidence score is low (e.g., due to low confidence of recent CGM samples, or evidence of unconfirmed eating and / or bolus injections), the corresponding corrected prediction may be unreliable, and (2) determining based on the corrected prediction that waiting is necessary before providing advice, i.e., if the general confidence score is low, the patient may be advised to wait for a period of time before presenting a recommendation.

[0165] Figure 7 This is a block diagram illustrating the implementation of parameter estimator 270. Parameter estimator 270 is configured to perform parameter optimization. Parameters are adjusted only based on calibrated, trusted data. Parameter optimization is applied to obtain the optimal settings for the metabolic model parameters based on a retrospective dataset. Over time, the predictor can be run retrospectively to improve predictions. The model is optimized to provide the best predictive model performance. Parameter estimation is optional and depends on the type of estimation used in the preceding block diagram and the type of model used for that estimation.

[0166] A parameter estimator 270 is constructed to optimize the estimated model parameters 275 provided as output, making the optional individualized physiological model used by the prediction engine as accurate as possible. The goal is to estimate the patient's physiological parameters, for general applications such as insulin sensitivity, absorption rate of lipro (drug), and any physiological parameters.

[0167] In practice, we optimize the use of retrospective data, run predictors on that data, build a prediction engine, apply retrospective data as if it were real-time data, and see how well it produces retrospective tracking predictions. Parameter tuning is based on the accuracy of simulated predictions.

[0168] The parameter estimator 270 receives retrospective compilation output 225R and retrospective data 210 as input, along with patient biostatistics and demographic information 273, and outputs model parameters 275.

[0169] The parameter estimator 270 includes a candidate parameter generator 710, a real-time predictor instance 720 (which includes a real-time input compiler and a prediction engine), and a confidence notification error estimator 730.

[0170] Candidate parameter generator 710 generates candidate model parameters 715.

[0171] Real-time predictor instance 720 uses candidate model parameters 715, retrospective data 210 (treating retrospective data 210 as real-time data), and a corrected estimate of metabolic inputs and disturbances of retrospective data output 225R, and provides its output to confidence notification error evaluator 730.

[0172] The confidence notification error evaluator 730 receives the output of the real-time predictor instance 720 and uses this data, along with the confidence of the retrospective data output 225R and the measurement signal of the retrospective data 210, to generate an output provided to the candidate parameter generator 710 to determine the model parameters 275.

[0173] In this implementation, each subject's reference glucose concentration and insulin sensitivity are adjusted to optimized values ​​from a list of possible values. The predictor can run on data exceeding 30 days (e.g., insulin, CGM, and food intake) and determine the best predictor beyond 1 hour.

[0174] Figure 8 This is another implementation of the operation flow for method 800 used to correct data. For example, method 800 can be performed by platform 200. In some implementations, aspects of method 800 can be performed by input compiler 220.

[0175] At point 810, untrusted data relating to the subject is received at the input estimator (such as metabolic input estimator 320 of retrospective input compiler 220R or metabolic input estimator 320 of real-time input compiler 220L). The untrusted data may be included in retrospective data (such as retrospective data 210) or real-time data (such as real-time data 212). The untrusted data includes at least one of insulin timing, insulin volume, food intake data, or activity data, wherein the untrusted data is untrusted due to behavioral abnormalities or human error in at least one of the time, volume, estimation, or input.

[0176] At point 820, trusted data relating to the subject is received at the input estimator. The trusted data may include retrospective data (such as retrospective data 210) or real-time data (such as real-time data 212). The trusted data includes at least one of CGM data, insulin pump data, computer-generated data, computer-generated models, or individualized models describing the subject's glucose and insulin dynamics.

[0177] At 830, trusted data is used to correct untrusted data. The input corrector can use trusted data to correct untrusted data. Specifically, (1) after the input estimator uses trusted input, along with the mathematical model, the value of the untrusted input is estimated, and (2) the untrusted input data is fused with the estimated untrusted input to produce the final corrected untrusted dataset. The untrusted input and the estimated untrusted input can be fused in different ways depending on the application context and time range. In some cases, such as when the estimated untrusted input is estimated with low error covariance, or when the estimated input has been proven to accurately predict blood glucose over a period of time, or when the untrusted data source is proven to be completely untrustworthy, the corrected untrusted data can be derived solely from the estimated input, independent of the untrusted data. In other cases, when the mathematical model and / or the estimated input cannot predict blood glucose over time, or when the untrusted data source can be proven to be accurate in an independent manner, the corrected untrusted data can be derived solely from the untrusted input itself. In real-time application contexts (non-retrospective applications), or when additional data is needed to determine whether the currently estimated untrusted input is more reliable than the untrusted input itself, the corrected untrusted data can be computed as a mixture of the untrusted input and the estimated untrusted input, wherein (1) for the most recent past, the correction follows the untrusted data (because more data is needed to refute it), (2) for the distant past, the correction follows the estimated untrusted input, and (3) in the transition region between the recent and distant past, the corrected value is computed as a weighted average of the untrusted input data and the untrusted input data estimated based on its proximity to the current time. Alternatives to the weighted average include (1) probabilistically selecting the untrusted input or the estimated untrusted input based on the perceived reliability of the untrusted or estimated untrusted data, or (2) selecting the untrusted input or the estimated untrusted input to maximize the classification object, such as maximum likelihood or maximum a posteriori probability.

[0178] At 840, the corrected untrusted data is output from the input compiler 220, for example.

[0179] Figure 9 This is another implementation of the operation flow for method 900 used to correct data. For example, method 900 can be performed by platform 200. In some implementations, aspects of method 900 can be performed by input compiler 220.

[0180] At point 910, untrusted data relating to the subject is received at the input estimator (such as metabolic input estimator 320 of retrospective input compiler 220R or metabolic input estimator 320 of real-time input compiler 220L). Untrusted data may be included in retrospective data (such as retrospective data 210) or real-time data (such as real-time data 212). Untrusted data includes user input data, which includes at least one of insulin data, food intake data, or activity data.

[0181] At 920, trusted data relevant to the subject is used to correct untrusted data. Trusted data may include retrospective data (such as retrospective data 210) or real-time data (such as real-time data 212). Trusted data includes computer-generated data. An input corrector may be used to perform the correction. Specifically, (1) after the input estimator uses trusted inputs, along with a mathematical model, the value of the untrusted input is estimated, and (2) the untrusted input data is fused with the estimated untrusted input to produce the final corrected untrusted dataset. The untrusted input and the estimated untrusted input may be fused in different ways depending on the application context and time frame. In some cases, such as when the estimated untrusted input is estimated with low error covariance, or when the estimated input has proven to accurately predict blood glucose over a period of time, or when the untrusted data source has proven to be completely untrustworthy, the corrected untrusted data may be derived solely from the estimated input, independent of the untrusted data. In other cases, when the mathematical model and / or estimated input cannot predict blood glucose over time, or when the untrusted data source can be proven accurate independently, the corrected untrusted data can be derived solely from the untrusted input itself. In the context of real-time applications (non-retrospective applications), or when additional data is needed to determine whether the current estimated untrusted input is more reliable than the untrusted input itself, the corrected untrusted data can be computed as a mixture of the untrusted input and the estimated untrusted input, wherein (1) for the most recent past, the correction follows the untrusted data (because more data is needed to refute it), (2) for the distant past, the correction follows the estimated untrusted input, and (3) in the transition region between the most recent and distant past, the corrected value is computed as a weighted average of the untrusted input data and the untrusted input data estimated based on its proximity to the current time. Alternatives to the weighted average include (1) selecting untrusted inputs or estimating untrusted inputs based on the perceived reliability probability of untrusted or estimated untrusted data, or (2) selecting untrusted inputs or estimating untrusted inputs to maximize the classification object, such as maximum likelihood or maximum posterior probability.

[0182] Figure 10 This is another implementation of the operation flow for method 1000, which determines data credibility. For example, method 1000 can be performed by platform 200. In some implementations, aspects of method 1000 can be performed by input compiler 220.

[0183] At point 1010, untrusted data relating to the subject is received, for example, at an input estimator (such as metabolic input estimator 320 of retrospective input compiler 220R or metabolic input estimator 320 of real-time input compiler 220L). Untrusted data may be included in retrospective data (such as retrospective data 210) or real-time data (such as real-time data 212). Untrusted data includes user input data, which includes at least one of insulin data, food intake data, or activity data.

[0184] At point 1020, the credibility of untrusted data is determined. Credibility can be determined by a credibility evaluator, such as the credibility evaluator 310 of the retrospective input compiler 220R or the credibility evaluator 310 of the real-time input compiler 220L. The credibility of untrusted data is evaluated individually based on the characteristics of the untrusted data at one or more time scales. In particular, failure to confirm meals and / or insulin and / or physical activity over a period of time can be interpreted as incomplete data, making the entire time period untrustworthy, for example, with a credibility value of zero. Similarly, other data artifacts, such as repeated inputs or abnormally large (or small) insulin doses and / or confirmed carbohydrate amounts or physical activity over a period of time, can be interpreted as non-physiologically or behaviorally unlikely, again presenting that time period as untrustworthy. Similarly, transient inaccuracies in generally trusted inputs may cause them to be temporarily considered untrustworthy inputs, for example, a sensor reading being temporarily unavailable or a temporary out-of-range indication from a sensor, again making the relevant time period untrustworthy.

[0185] At 1030, trusted data is received at the trustworthiness evaluator. Trusted data may include retrospective data (such as retrospective data 210) or real-time data (such as real-time data 212).

[0186] At 1040, the confidence level of the untrusted data is updated using trusted data. This update can be performed by a confidence evaluator. The confidence level of the untrusted data can be evaluated based on its consistency with the estimated untrusted input data over one or more time scales. Specifically, when the base model has been shown to predict blood glucose concentrations over time, and when the untrusted input for a period differs from the estimated untrusted input, the untrusted data for that period can be assigned a low confidence level, e.g., closer to zero than 1. Independently, confidence values ​​can be assigned to the corrected untrusted input based on how the correction was implemented. For example, if the model has been shown to be highly predictive of blood glucose over time, and the estimated untrusted input is highly consistent with the trusted data, and the corrected untrusted data is calculated to be equal to or very close to the estimated untrusted data, then the corrected untrusted data can be assigned a high confidence value, e.g., close to 1, even if the corresponding untrusted data is unreliable.

[0187] Figure 11 This is an alternative implementation of method 1100 for determining data credibility; method 1100 can be performed by, for example, platform 200. In some implementations, aspects of method 1100 can be performed by input compiler 220.

[0188] At 1110, first untrusted data relating to the subject is received, for example, at an input estimator (such as metabolic input estimator 320 of retrospective input compiler 220R or metabolic input estimator 320 of real-time input compiler 220L). The first untrusted data may include retrospective data (such as retrospective data 210) or real-time data (such as real-time data 212). Untrusted data includes user input data, which includes at least one of insulin data, food intake data, or activity data.

[0189] At 1120, the credibility of the first untrusted data is determined by a credibility evaluator (e.g., credibility evaluator 310 of the retrospective input compiler 220R or credibility evaluator 310 of the real-time input compiler 220L). The credibility of the untrusted data is evaluated individually based on the characteristics of the untrusted data at one or more time scales. In particular, failure to confirm meals and / or insulin and / or physical activity over a period of time can be interpreted as incomplete data, making the entire time period untrustworthy, for example, with a credibility value of zero. Similarly, other data artifacts, such as repeated inputs or abnormally large (or small) insulin doses and / or confirmed carbohydrate amounts or physical activity over a period of time, can be interpreted as non-physiologically or behaviorally unlikely, again presenting that time period as untrustworthy. Similarly, transient inaccuracies in generally trusted inputs may cause them to be temporarily considered untrustworthy inputs, for example, a sensor reading being temporarily unavailable or a temporary out-of-range indication from a sensor, again making the relevant time period untrustworthy.

[0190] At 1130, second untrusted data relating to the subject is received, for example, at an input estimator (such as metabolic input estimator 320 of retrospective input compiler 220R or metabolic input estimator 320 of real-time input compiler 220L). The second untrusted data may be included in retrospective data (such as retrospective data 210) or real-time data (such as real-time data 212).

[0191] At 1140, the credibility of the second untrusted data is determined at a credibility evaluator (e.g., credibility evaluator 310 of retrospective input compiler 220R or credibility evaluator 310 of real-time input compiler 220L).

[0192] At 1150, depending on the implementation, the credibility of the first untrusted data is updated using the credibility of the second untrusted data and / or the credibility of the second untrusted data. This update can be performed at credibility evaluator 310.

[0193] At 1160, trusted data is received at the trustworthiness evaluator 310. The trusted data may include retrospective data (such as retrospective data 210) or real-time data (such as real-time data 212).

[0194] At 1170, the confidence levels of the first and second untrusted data are updated using trusted data. This update can be performed by a confidence evaluator. The confidence level of untrusted data can be evaluated based on its consistency with the estimated untrusted input data over one or more time scales. Specifically, when the base model has been shown to predict blood glucose concentrations over time, and when the untrusted input for a period differs from the estimated untrusted input, the untrusted data for that period can be assigned a low confidence level, e.g., closer to zero than 1. Independently, confidence values ​​can be assigned to corrected untrusted inputs based on how the correction was implemented. For example, if the model has been shown to be highly predictive of blood glucose over time, and the estimated untrusted input is highly consistent with the trusted data, and the corrected untrusted data is calculated to be equal to or very close to the estimated untrusted data, then the corrected untrusted data can be assigned a high confidence value, e.g., close to 1, even if the corresponding untrusted data is unreliable.

[0195] Figure 12 This describes the operational flow of a method 1200 for providing blood glucose-based outputs using untrusted data. For example, method 1200 can be implemented by platform 200.

[0196] At 1210, for example, prediction engine 250 predicts data for the subject over a period of time. In some implementations, (1) initial conditions (corresponding to the past state of the system), trusted inputs from that past time, and corrected untrusted inputs from that past time are used as inputs to a mathematical model that generates an estimate of the patient's current metabolic state, and (2) anticipated future inputs (e.g., assumed insulin dose, physical activity, and / or dietary behavior) are considered, which are used to predict the patient's future metabolic state, including future blood glucose levels. Further features and details are described herein with respect to, for example, Figure 6 Describe it.

[0197] At 1220, for example at an input estimator (such as metabolic input estimator 320 of retrospective input compiler 220R or metabolic input estimator 320 of real-time input compiler 220L), untrusted data for diabetes management is received. Untrusted data may be included in retrospective data (such as retrospective data 210) or real-time data (such as real-time data 212).

[0198] At point 1230, multiple predicted data traces are simulated within this time period, for example, by replaying compiler 230. The possible range of variation using untrusted data is considered.

[0199] At 1240, the replay compiler 230 compares the simulated predicted data trace with the predicted data to identify the effects of blood glucose.

[0200] At 1250, the replay compiler generates and outputs visualizations and / or recommendations based on the effects of blood glucose.

[0201] Figure 13 This describes the operational flow for implementing method 1300 using replay prediction. For example, method 1300 can be implemented by platform 200. In some implementations, aspects of method 1300 can be implemented by replay compiler 230.

[0202] At 1310, the replay compiler at 230 receives the estimated metabolic state, the corrected estimated metabolic input, the known metabolic input, and the alternative metabolic input.

[0203] At 1320, and at 230 in the replay compiler, replay prediction uses estimated metabolic state, corrected estimated metabolic inputs, known metabolic inputs, and alternative metabolic inputs. In some implementations, a fundamental mathematical model (e.g., represented by dynamic equations) is used to iteratively predict the metabolic state experienced by the patient due to modifications of inputs over some (or all) of the time period described by the retrospective data, specifying which historical inputs are modifiable (those that are entirely new or dynamically estimated as a function of the newly predicted patient metabolic state) and which inputs are invariant exogenous inputs. The confidence level of the retrospectively predicted patient metabolic state estimate is determined by the confidence level of the corresponding untrusted retrospective data. Further features and details are discussed in this paper regarding, for example... Figure 5 Describe it.

[0204] At 1330, the replay simulation metabolic state based on the replay prediction is output by the replay compiler 230.

[0205] Figure 14 This describes the operational flow for implementing method 1400 using real-time prediction. For example, method 1400 can be performed by platform 200. In some implementations, aspects of method 1400 can be performed by prediction engine 250.

[0206] At 1410, for example at prediction engine 250, alternative metabolic inputs, corrected estimated metabolic inputs, known metabolic inputs, and final estimated metabolic inputs are received.

[0207] At 1420, and at 250 in the prediction engine, real-time prediction is performed using alternative metabolic inputs, corrected estimated metabolic inputs, known metabolic inputs, and final estimated metabolic inputs.

[0208] At 1430, the predicted metabolic state based on real-time prediction is output by the replay engine 250.

[0209] Figure 15 An exemplary computing environment is shown in which example implementations and aspects can be implemented. The computing device environment is merely an example of a suitable computing environment and is not intended to imply any limitation on the scope of use or functionality.

[0210] Many other general-purpose or special-purpose computing device environments or configurations can be used. Examples of well-known computing devices, environments, and / or configurations that may be suitable include, but are not limited to, personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, network personal computers (PCs), minicomputers, mainframe computers, embedded systems in distributed computing environments that include any of the above systems or devices, etc.

[0211] Computer-executable instructions, such as program modules, can be used. Typically, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. When the task is performed by a remote processing device linked via a communication network or other data transmission medium, a distributed computing environment can be used. In a distributed computing environment, program modules and other data can reside on local and remote computer storage media, including storage devices.

[0212] refer to Figure 15 Exemplary systems for implementing the aspects described herein include computing devices, such as computing device 1500. In its most basic configuration, computing device 1500 typically includes at least one processing unit 1502 and memory 1504. Depending on the exact configuration and type of the computing device, memory 1504 may be volatile (such as random access memory (RAM)), non-volatile (e.g., read-only memory (ROM), flash memory, etc.), or a combination of both. This most basic configuration in Figure 15 The middle part is indicated by the dashed line 1506.

[0213] The computing device 1500 may have additional features / functions. For example, the computing device 1500 may include additional memory (removable and / or non-removable), including but not limited to disks, optical discs, or magnetic tapes. This additional memory is provided by removable memory 1508 and non-removable memory 1510. Figure 15 As shown in the image.

[0214] Computing device 1500 typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by device 1500, and includes volatile and non-volatile media, removable and non-removable media.

[0215] Computer storage media include volatile and non-volatile, removable and non-removable media implemented using any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Memory 1504, removable memory 1508, and non-removable memory 1510 are examples of computer storage media. Computer storage media include, but are not limited to, RAM, ROM, electrically erasable program-only memory (EEPROM), flash memory or other storage technologies, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible by computing device 1500. Any such computer storage medium may be part of computing device 1500.

[0216] The computing device 1500 may include a communication connection 1512 that allows the device to communicate with other devices. The computing device 1500 may also have input devices 1514, such as a keyboard, mouse, pen, voice input device, touch input device, etc. Output devices 1516, such as a display screen, speaker, printer, etc., may also be included. All of these devices are well known in the art and do not need to be discussed in detail here.

[0217] In one implementation, one method includes receiving untrusted data relating to a subject at an input estimator; receiving trusted data relating to the subject at the input estimator; correcting the untrusted data using the trusted data using an input corrector; and outputting the corrected untrusted data.

[0218] The implementation may include some or all of the following features. The untrusted data includes at least one of insulin timing, insulin volume, food intake data, or activity data. The untrusted data is untrusted due to behavioral abnormalities or human error in at least one of the time, volume, estimation, or input. The trusted data includes at least one of CGM data, insulin pump data, computer-generated data, computer-generated models, or individualized models describing the subject's glucose and insulin dynamics. The method further includes predicting the subject's future glucose status based on the corrected untrusted data. The untrusted data includes reported carbohydrates, wherein the reported carbohydrates are unreliable or unavailable. The untrusted data includes a data input stream. The method further includes receiving additional untrusted data and using the trusted data to correct the additional untrusted data. The method further includes receiving additional trusted data and using the additional trusted data to correct the untrusted data. The method further includes adjusting the AP using the corrected untrusted data. The method further includes updating the subject's behavioral model using the corrected untrusted data. The method further includes determining that the untrusted data is unreliable or unknown. Determining that the untrusted data is unreliable or unknown includes calculating the local variance of the untrusted data using modeling, and comparing the local variance with the population variance using the untrusted data to determine a comparison measure, wherein the untrusted data is determined to be unreliable or unknown when the comparison measure is higher than a threshold. Determining that the untrusted data is unreliable or unknown also includes determining the differences between the untrusted data and a trusted data model.

[0219] The implementation may include some or all of the following features. The method further includes determining a confidence score of the untrusted data relative to trusted data. The method further includes generating alerts related to the subject based on the corrected untrusted data. The method further includes determining the subject's behavioral patterns using the corrected untrusted data. The method further includes generating intelligent alerts related to the subject based on the behavioral patterns. The untrusted data includes diabetes management data. The diabetes management data is estimated diabetes management data. The trusted data includes diabetes management data corresponding to the estimated diabetes management data, wherein the diabetes management data is received from a connected device or user input. The method further includes comparing the untrusted data with the trusted data to identify the behavioral root causes of glycemic dysfunction.

[0220] The implementation may include some or all of the following features. The method further includes using the corrected untrusted data to identify the behavioral roots of glycemic dysfunction. The correction includes: receiving the untrusted data at an input corrector, wherein the untrusted data includes untrusted metabolic inputs; receiving the trusted data at an input corrector, wherein the trusted data includes estimated untrusted metabolic inputs; and combining the untrusted data and the trusted data using a weighting function to generate corrected untrusted metabolic inputs. The untrusted data and the trusted data received at the input corrector are in vector form, and the corrected untrusted metabolic inputs are also in vector form. The weighting function is based on time correlation. The weighting function is based on the relative confidence of the untrusted data and the trusted data. The untrusted data includes reported untrusted metabolic inputs, and the combination includes correcting the difference between the reported untrusted metabolic inputs and the estimated untrusted metabolic inputs. The correction includes aligning the reported untrusted metabolic inputs and the estimated untrusted metabolic inputs with a behavioral model. The correction includes using measurement data to correct for the discrepancy between the untrusted metabolic input and the estimated amount and timing of the untrusted metabolic input.

[0221] In one implementation, one method includes receiving untrusted data relating to a subject at an input estimator, wherein the untrusted data includes user input data, which includes at least one of insulin data, food intake data, or activity data; and using an input corrector to correct the untrusted data using trusted data relating to the subject, wherein the trusted data includes computer-generated data.

[0222] The implementation may include some or all of the following features. The untrusted data includes at least one of insulin timing, insulin volume, food intake data, or activity data. The untrusted data is untrusted due to behavioral abnormalities or human error in at least one of the time, volume, estimation, or input. The trusted data includes at least one of CGM data, insulin pump data, computer-generated models, or individualized models describing the subject's glucose and insulin dynamics. The method further includes predicting the subject's future glucose status based on the corrected untrusted data. The untrusted data includes reported carbohydrates, wherein the reported carbohydrates are unreliable or unavailable. The untrusted data includes a data input stream. The method further includes receiving additional untrusted data and using the trusted data to correct the additional untrusted data. The method further includes receiving additional trusted data and using the additional trusted data to correct the untrusted data. The method further includes adjusting the AP using the corrected untrusted data. The method further includes updating the subject's behavioral model using the corrected untrusted data. The method further includes determining that the untrusted data is unreliable or unknown. Determining that the untrusted data is unreliable or unknown includes calculating the local variance of the untrusted data using modeling, and comparing the local variance with the population variance using the untrusted data to determine a comparison measure, wherein the untrusted data is determined to be unreliable or unknown when the comparison measure is higher than a threshold. Determining that the untrusted data is unreliable or unknown includes determining the difference between the untrusted data and a trusted data model. The method further includes determining a confidence score of the untrusted data relative to the trusted data. The method further includes generating alerts related to the subject based on the corrected untrusted data. The method further includes determining the subject's behavioral patterns using the corrected untrusted data. The method further includes generating intelligent alerts related to the subject based on the behavioral patterns.

[0223] The implementation may include some or all of the following features: The untrusted data includes diabetes management data. The diabetes management data is estimated diabetes management data. The trusted data includes diabetes management data corresponding to the estimated diabetes management data, wherein the diabetes management data is received from a connected device or user input. The method further includes comparing the untrusted data with the trusted data to identify behavioral roots of glycemic dysfunction. The method further includes using the corrected untrusted data to identify behavioral roots of glycemic dysfunction. The correction includes: receiving the untrusted data at an input corrector, wherein the untrusted data includes untrusted metabolic inputs; receiving the trusted data at an input corrector, wherein the trusted data includes estimated untrusted metabolic inputs; and combining the untrusted data and the trusted data using a weighting function to generate corrected untrusted metabolic inputs. The untrusted data and the trusted data received at the input corrector are in vector form, and the corrected untrusted metabolic inputs are in vector form. The weighting function is based on time correlation. The weighting function is based on the relative confidence of the untrusted data and the trusted data. The untrusted data includes reported untrusted metabolic inputs, and the combination includes correcting for discrepancies between the reported untrusted metabolic inputs and estimated untrusted metabolic inputs. The correction includes aligning the reported untrusted metabolic inputs and estimated untrusted metabolic inputs with a behavioral model. The correction includes correcting for discrepancies in the quantity and timing of the untrusted metabolic inputs and estimated untrusted metabolic inputs using measurement data. The method further includes performing replay prediction using the corrected untrusted data and the trusted data. The method further includes simulating metabolic states based on the replay prediction output. The method further includes performing real-time prediction using the corrected untrusted data and the trusted data. The method further includes simulating metabolic states based on the real-time prediction output.

[0224] In one implementation, one method includes predicting data of a subject over a period of time; receiving untrusted data for diabetes management; simulating multiple predicted data trails over the period of time using the possible variance spectrum of the untrusted data; comparing the simulated predicted data trails with the predicted data to identify glycemic effects; and outputting visualizations or recommendations based on the glycemic effects.

[0225] The implementation may include some or all of the following features. The untrusted data includes glucose data, and the predicted data trail includes a predicted glucose trail. The predicted glucose data is based on trusted CGM (Continuous Glucose Monitoring) data and an individualized model of the subject's glucose-insulin kinetics. The predicted glucose data includes a glucose trail that provides the best estimate of glucose status as it changes over time. The untrusted data for diabetes management includes at least one of insulin timing, insulin volume, food intake data, or activity data. Glucose impact is correlated with differences in at least one of the amount or timing of diabetes management data.

[0226] In one implementation, a system includes a processor and a metabolic model, wherein the processor is configured to receive untrusted user input and use the metabolic model to correct the untrusted user input with trusted input.

[0227] The implementation may include some or all of the following features. The processor is further configured to optimize the predictive power of the metabolic model to predict future glucose levels. The processor is further configured to allow replay of events and outcomes in the event of an alternative treatment procedure. The processor is further configured to provide real-time predictions of future metabolic states. The processor is further configured to determine the credibility of untrusted user input. The processor is further configured to provide a score corresponding to the credibility. The processor is further configured to perform replay analysis for at least one replay application. The at least one replay application includes evaluating blood glucose (BG) outcome metrics in the analysis, identifying credible instances of the scene in the replay analysis, estimating data quality, credibility profile, and data credibility that vary with time of day. The processor is further configured to perform corrected projections for at least one real-time application. The at least one real-time application includes the confidence level of medical actions and the determination of the time required before providing an opinion.

[0228] The implementation may include some or all of the following features: Untrusted user input includes estimated carbohydrates. Untrusted user input includes time series of uncertain metabolic inputs. Trusted input includes CGM and insulin pump readings. Trusted input includes time series of trusted metabolic inputs. The processor is further configured to output an estimated metabolic state in time series form, a final corrected estimated metabolic state in time series form, and the confidence level of the final estimated metabolic state and the corrected estimated input in time series form. The processor is included within a joint state / input estimator, and the metabolic model is a plug-in.

[0229] In one implementation, a method includes receiving untrusted data relating to a subject at an input estimator, wherein the untrusted data includes user input data, which includes at least one of insulin data, food intake data, or activity data; determining the credibility of the untrusted data at a credibility estimator; receiving trusted data at the credibility estimator; and updating the credibility of the untrusted data at the credibility estimator using the trusted data.

[0230] The implementation may include some or all of the following features. Determining the credibility of untrusted data includes: determining a first credibility based on at least one of the untrusted data lacking completeness or the untrusted data lacking continuity; determining a second credibility based on expected behavior indicating at least one of the untrusted data lacking completeness or the untrusted data lacking continuity; determining a third credibility based on artifacts in the estimated input indicating unknown factors of the system; and summarizing the first credibility, the second credibility, and the third credibility. Determining the first credibility includes using a measurement signal as input, determining the second credibility includes using the untrusted data and the trusted data as input, and determining the third credibility includes using the untrusted data, estimated untrusted data, and corrected data as input.

[0231] In one implementation, a method includes receiving first untrusted data related to a subject at an input estimator, wherein the first untrusted data includes user input data, which includes at least one of insulin data, food intake data, or activity data; determining the credibility of the first untrusted data at a credibility estimator; receiving second untrusted data related to the subject at the input estimator; determining the credibility of the second untrusted data at the credibility estimator; updating the credibility of the first untrusted data at the credibility estimator using the second untrusted data or the credibility of the second untrusted data; receiving trusted data at the credibility estimator; and updating the credibility of the first untrusted data and the second untrusted data at the credibility estimator using the trusted data.

[0232] The implementation may include some or all of the following features. Determining the first confidence level of the untrusted data includes: determining the first confidence level based on at least one of the untrusted data lacking completeness or the untrusted data lacking continuity; determining the second confidence level based on expected behavior indicating at least one of the untrusted data lacking completeness or the untrusted data lacking continuity; determining the third confidence level based on artifacts in the estimated input indicating unknown factors of the system; and summarizing the first confidence level, the second confidence level, and the third confidence level. Determining the first confidence level includes using a measurement signal as input, determining the second confidence level includes using the untrusted data and the trusted data as input, and determining the third confidence level includes using the untrusted data, the estimated untrusted data, and the corrected data as input.

[0233] In one implementation, a method includes receiving an estimated metabolic state, a corrected estimated untrusted metabolic input, a trusted metabolic input, and an alternative metabolic input; performing a replay prediction using the estimated metabolic state, the corrected estimated untrusted metabolic input, the trusted metabolic input, and the alternative metabolic input; and replaying the simulated metabolic state based on the replay prediction output.

[0234] The implementation may include some or all of the following features: The estimated metabolic state, the corrected estimated untrusted metabolic input, and the trusted metabolic input each comprise a time series. Performing the replay prediction involves estimating the metabolic state over the duration of the time series of the estimated metabolic state, the corrected estimated untrusted metabolic input, and the trusted metabolic input to generate the replay simulated metabolic state.

[0235] In one implementation, a method includes receiving an alternative metabolic input, a corrected estimated untrusted metabolic input, a trusted metabolic input, and a final estimated metabolic input; performing a real-time prediction using the alternative metabolic input, the corrected estimated untrusted metabolic input, the trusted metabolic input, and the final estimated metabolic input; and predicting a metabolic state based on the real-time prediction output.

[0236] The implementation may include some or all of the following features. Real-time prediction includes: extrapolating the corrected estimated untrusted metabolic input and the time series of the trusted metabolic input; and using the extrapolated time series, the alternative metabolic input, and the final estimated metabolic state to estimate the metabolic state to the future. The method further includes filtering the extrapolated time series to prevent jitter in the predicted metabolic state. The estimated metabolic state is in time series form. The method further includes filtering the estimated metabolic state to produce the predicted metabolic state. The estimated metabolic state uses a behavioral model of the subject. The extrapolated time series uses a weighted average of historical data based on at least one of the following: time of day, features of the current estimated state, or a database of past metabolic inputs.

[0237] It should be understood that the various techniques described herein can be implemented in combination with hardware components or software components, or, where appropriate, in combination of both. Exemplary types of hardware components that can be used include field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and the like. The methods and apparatus of the currently disclosed subject matter, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in a tangible medium, such as a floppy disk, CD-ROM, hard disk, or any other machine-readable storage medium. Wherein, when the program code is loaded into and executed by a machine such as a computer, that machine becomes an apparatus for practicing the currently disclosed subject matter.

[0238] While exemplary implementations may refer to the utilization of aspects of the currently disclosed subject matter within the context of one or more independent computer systems, the subject matter is not limited thereto, but can be implemented in conjunction with any computing environment, such as a networked or distributed computing environment. Furthermore, aspects of the currently disclosed subject matter can be implemented in or across multiple processing chips or devices, and similarly, storage can be implemented across multiple devices. For example, such devices may include personal computers, network servers, and handheld devices.

[0239] Although the subject matter has been described in language specific to structural features and / or methodological behavior, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or behaviors described above. Rather, the specific features and behaviors described above are disclosed as exemplary forms for implementing the claims.

Claims

1. A method comprising: At the input estimator, untrusted data relating to the subject is received, wherein the untrusted data includes user input data, which includes at least one of insulin data, food data, or activity data; The input estimator receives trusted data related to the subject, wherein the trusted data includes at least one of CGM (continuous glucose monitoring) data, insulin pump data, computer-generated data, or computer-generated models; The input corrector is used to correct the untrusted data using the trusted data; The correction includes: The untrusted data is received at the input corrector, wherein the untrusted data includes reported untrusted metabolic inputs; The trusted data is received at the input corrector, wherein the trusted data includes estimated untrusted metabolic inputs; and The untrusted data and the trusted data are combined using a weighting function to generate corrected untrusted metabolic inputs, wherein the metabolic inputs include time-varying inputs of a metabolic model, the time-varying inputs being represented as at least one of eating time or amount of food, insulin delivery time or amount of insulin delivery, or activity effects characterized by time and magnitude, and wherein the combination includes correcting for the difference between the reported untrusted metabolic inputs and the estimated untrusted metabolic inputs, and wherein the weighting function is based on time relevance such that larger weights are used for more recent untrusted metabolic inputs; Output the corrected untrusted metabolic input; and The subject's future glucose status is predicted based on the corrected, untrusted data.

2. The method according to claim 1, wherein, The untrusted data includes at least one of insulin delivery time, insulin delivery volume, food intake data, or activity data.

3. The method according to claim 1 or 2, wherein, The untrusted data is untrusted due to human error in at least one of the following: delivery time, delivery volume, estimate, or input.

4. The method according to claim 3, wherein, The human error mentioned includes abnormal behavior.

5. The method according to claim 1 or 2, wherein, The computer-generated models include individualized models that describe the glucose and insulin dynamics of the subjects.

6. The method according to claim 1 or 2, wherein, The untrusted data includes reported carbohydrates, which are unreliable or unavailable.

7. The method according to claim 1 or 2, wherein, The untrusted data includes data input streams.

8. The method of claim 1 or 2, further comprising receiving additional untrusted data and using the trusted data to correct the additional untrusted data.

9. The method of claim 1 or 2, further comprising receiving additional trusted data and using the additional trusted data to correct the untrusted data.

10. The method of claim 1 or 2, further comprising adjusting the AP (artificial pancreas) using the corrected untrusted data.

11. The method of claim 1 or 2, further comprising determining that the untrusted data is unreliable or unknown.

12. The method according to claim 11, wherein, Determining that the untrusted data is unreliable or unknown includes using modeling to calculate the local variance of the untrusted data, and comparing the local variance with the overall variance using the untrusted data to determine a comparison measure, wherein the untrusted data is determined to be unreliable or unknown when the comparison measure is higher than a threshold.

13. The method according to claim 11, wherein, Determining that the untrusted data is unreliable or unknown includes determining the differences between the untrusted data and the trusted data model.

14. The method of claim 1 or 2, further comprising determining a credibility score of the untrusted data relative to the trusted data.

15. The method of claim 1 or 2, further comprising generating an alert related to the subject based on the corrected untrusted data.

16. The method of claim 1 or 2, further comprising using the corrected untrusted data to determine the subject’s behavioral patterns, wherein the subject’s behavioral patterns include recurring time-related features of at least one of eating time, food intake level, insulin delivery time, insulin delivery amount, or activity effects, the recurring time-related features being identified from corrected metabolic input time series and corresponding confidence scores.

17. The method of claim 16, further comprising generating intelligent alerts related to the subject based on the behavioral pattern.

18. The method according to claim 1 or 2, wherein, The untrusted data includes diabetes management data.

19. The method according to claim 18, wherein, The diabetes management data mentioned are estimated diabetes management data.

20. The method according to claim 19, wherein, The trusted data includes diabetes management data corresponding to the estimated diabetes management data, wherein the diabetes management data is received from the connected device or user input.

21. The method of claim 20, further comprising comparing the untrusted data with the trusted data to identify behavioral roots of glucose dysfunction, the behavioral roots of glucose dysfunction including those selected from the timing or amount of food consumed, the timing or amount of insulin delivery, or the subject’s behavior or negligence under the influence of activity, the behavioral roots of glucose dysfunction explaining the observed glucose drift or variability when compared with predictions from trusted measurements and chance models.

22. The method of claim 1 or 2, further comprising using the corrected untrusted data to identify behavioral roots of glucose dysfunction, said behavioral roots of glucose dysfunction including behaviors or negligence of the subject selected from the time or amount of food consumed, the time or amount of insulin delivery, or the influence of activity, said behavioral roots of glucose dysfunction explaining the observed glucose drift or variability when compared with predictions from trusted measurements and chance models.

23. The method according to claim 1, wherein, The untrusted data and the trusted data received at the input corrector are in vector form, and the corrected untrusted metabolic input is in vector form.

24. The method according to claim 1 or 23, wherein, The weighting function is based on the relative confidence levels of the untrusted data and the trusted data.

25. The method according to claim 1, wherein, The correction includes aligning the reported untrusted metabolic inputs and the estimated untrusted metabolic inputs with the behavioral model.

26. The method of claim 1 or 25, wherein the correction comprises correcting for the difference between the untrusted metabolic input and the estimated amount and time of the untrusted metabolic input using measurement data.

27. The method of claim 1 or 2, further comprising using the corrected untrusted data and the trusted data to perform replay prediction, wherein the replay prediction comprises retrospectively simulating a metabolic state trajectory over a historical time period using a metabolic model and corrected untrusted metabolic input.

28. The method of claim 27, further comprising simulating a metabolic state based on the replay prediction output.

29. The method of claim 1 or 2, further comprising using the corrected untrusted data and the trusted data for real-time prediction.

30. The method of claim 29, further comprising simulating metabolic states based on the real-time prediction output.

Images