Integrated state estimation prediction, evaluating the difference between predicted data and corresponding received data

Abstract

Systems and methods are provided for reconciling a subject's untrusted data using trusted data associated with the subject. The systems and methods are directed to assessing discrepancies between predicted data and corresponding received data. The systems and methods estimate a metabolic state from a combination of trusted and untrusted metabolic inputs, optionally using a personalized mathematical model with parameter optimization. The systems and methods provide the metabolic model and its measured impact on the reconciled untrusted inputs. This enables estimation of future metabolic states for decision support and automated insulin administration. Replay of scenarios with estimated or reconciled data is also provided.

Description

[Technical Field]

[0001] INCORPORATION-BY-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Patent Application No. 62 / 935,920, filed November 15, 2019, entitled "JOINT STATE ESTIMATION PREDICTION THAT EVALUATES DIFFERENCES IN PREDICTED VS. CORRESPONDING RECEIVED DATA," which is incorporated herein by reference in its entirety and is hereby expressly made a part of this specification. [Background technology]

[0002] With the widespread adoption of CGM (continuous glucose monitoring) and connected devices, the availability and reliability of glucose time-series data has increased in recent years. However, despite the availability of reliable glucose data, accurate tracking of insulin and meal data and optimized and effective timing of mealtime insulin bolus administration continue to be problems for many people with diabetes, resulting in poor glucose control.

[0003] People without diabetes tightly control their blood glucose (BG) levels despite glucose inputs ranging from fasting to high-carbohydrate (carbohydrate) meals and metabolic demands ranging from sleep to intense exercise. For example, CGM data from adults without diabetes show a mean glucose of 99 mg / dL and blood glucose levels within the 70-140 mg / dL range 97% of the time. This tight control is due to the combined action of glucose-regulating hormones, such as insulin, glucagon, amylin, and GLP-1, and associated messaging between organs like the pancreas, intestine, and liver.

[0004] In contrast, blood glucose control in type 1 diabetes has traditionally relied on a simpler strategy: administering insulin to cover dietary and basic body requirements. An exemplary routine combines daily administration of long-acting insulin with pre-meal administration of rapid-acting insulin based on carbohydrate counting and self-monitored blood glucose measurements. The success of this approach relies on careful vigilance and the assumption that the body will always respond to food and insulin in the same way, despite all the variations in dietary choices, stress, exercise, and so on. As a result, most people are forced to balance avoiding the health risks of chronically high glucose levels with dangerously low glucose episodes.

[0005] Improving glucose control in insulin-dependent diabetes mellitus relies in part on strategies that more closely mimic the operation of the pancreas to adapt to changing metabolic conditions. One example is the artificial pancreas (AP) system.

[0006] However, patient alerts and / or alarms, as well as medication dosing algorithms, often rely on the ability to predict future metabolic states in real time or retrospectively simulate the physiological conditions of life with a chronic illness. Predicting the future, in turn, relies on the ability to estimate a patient's current metabolic state using all available data, including data received directly from the patient (e.g., voluntary confirmation of meal carbohydrates), which can be prone to error (e.g., delayed or complete absence of meal confirmation, resulting in a significant underestimation of carbohydrate counts). Even if an algorithm predicts data that is not currently available, there are typically discrepancies (i.e., discrepancies) when / if that predicted data is received (e.g., from a user at a later time). These discrepancies are not currently used, but if evaluated, can provide valuable information about the data for future use. The systems and methods described herein use and reconcile these discrepancies.

[0007] Combining human and machine inputs into metabolic models presents a dilemma. Because the most reliable inputs are machine-recorded, such as those from insulin pumps or continuous glucose monitors, attempts to ignore or avoid human input are common. The problem is that even fast-acting carbohydrates delay the appearance of glucose in the blood and the CGM signal. Thus, even a poorly announced or described meal initially predicts future glucose values ​​better than the pre-meal CGM trace. As blood glucose responds to a meal, the metabolic model can better explain the observed response. The systems and methods described herein seamlessly combine these two perspectives and reconcile their differences. Summary of the Invention [Means for solving the problem]

[0008] According to some aspects, systems and methods are provided for verifying untrusted data of a subject using trusted data related to the subject. According to some aspects, the systems and methods are directed to evaluating discrepancies of expected data relative to corresponding received data.

[0009] In an implementation, the method includes receiving untrusted data associated with the subject at an input estimator, receiving trusted data associated with the subject at the input estimator, matching the untrusted data with the trusted data using an input matcher, and outputting the matched untrusted data.

[0010] Implementations may include some or all of the following features: The untrusted data includes at least one of insulin timing, insulin amount, meal data, or activity data. The untrusted data is unreliable due to behavioral anomalies or human error in at least one of timing, amount, estimation, or entry. The trusted data includes at least one of CGM data, insulin pump data, computer-generated data, computer-generated models, or personalized models describing the subject's glucose and insulin dynamics. The method further includes predicting the subject's future glucose state based on the collated untrusted data. The untrusted data includes reported carbohydrates, where the reported carbohydrates are unreliable or unavailable. The untrusted data includes a stream of data input. The method further includes receiving additional untrusted data and collating the additional untrusted data with the trusted data. The method further includes receiving additional trusted data and collating the untrusted data with the additional trusted data. The method further includes tuning the AP using the collated untrusted data. The method further includes updating the subject's behavioral model using the collated 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 a local variance of the untrusted data using modeling and comparing the local variance to an overall variance using the untrusted data to determine a comparison amount, where if the comparison amount exceeds a threshold, the untrusted data is determined to be unreliable or unknown. Determining that the untrusted data is unreliable or unknown includes determining a difference between the untrusted data and a model of the trusted data.

[0011] Implementations may also include some or all of the following features: The method further includes determining a trust score of the untrusted data relative to the trusted data. The method further includes generating an alert associated with the subject based on the matched untrusted data. The method further includes determining a behavioral pattern of the subject using the matched untrusted data. The method further includes generating a smart alert associated with the subject based on the behavioral pattern. 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 a user entry. The method further includes comparing the untrusted data with the trusted data to identify a behavioral root cause of the glycemic dysfunction.

[0012] Implementations may also include some or all of the following features: The method further includes identifying behavioral root causes of the glycemic dysfunction using the matched unreliable data. The matching includes receiving the unreliable data at an input matcher, where the unreliable data includes an unreliable metabolic input; receiving reliable data at the input matcher, where the reliable data includes an estimated unreliable metabolic input; and combining the unreliable data and the reliable data using a weighting function to generate a matched unreliable metabolic input. The unreliable data and the reliable data received at the input matcher are in the form of a vector, and the matched unreliable metabolic input is in the form of a vector. The weighting function is based on time association. The weighting function is based on relative certainty of the unreliable data and the reliable data. The unreliable data includes a reported unreliable metabolic input, and combining includes matching a difference between the reported unreliable metabolic input and the estimated unreliable metabolic input. The matching includes matching the reported unreliable metabolic input and the estimated unreliable metabolic input with a behavioral model. The matching includes matching the difference between the amount and timing of the unreliable metabolic input and the estimated unreliable metabolic input with the measured data.

[0013] In an implementation, the method includes receiving, at an input estimator, untrusted data associated with the subject, where the untrusted data includes user-input data including at least one of insulin data, dietary data, or activity data, and matching, using an input verifier, the untrusted data with trusted data associated with the subject, where the trusted data includes computer-generated data.

[0014] Implementations may include some or all of the following features: The untrusted data includes at least one of insulin timing, insulin amount, meal data, or activity data. The untrusted data is unreliable due to behavioral anomalies or human error in at least one of timing, amount, estimation, or entry. The trusted data includes at least one of CGM data, insulin pump data, a computer-generated model, or a personalized model describing the subject's glucose and insulin dynamics. The method further includes predicting the subject's future glucose state based on the collated untrusted data. The untrusted data includes reported carbohydrates, where the reported carbohydrates are unreliable or unavailable. The untrusted data includes a stream of data input. The method further includes receiving additional untrusted data and collating the additional untrusted data with the trusted data. The method further includes receiving additional trusted data and collating the untrusted data with the additional trusted data. The method further includes tuning the AP using the collated untrusted data. The method further includes updating the subject's behavioral model using the collated 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 a local variance of the untrusted data using modeling and comparing the local variance to an overall variance using the untrusted data to determine a comparison amount, where if the comparison amount exceeds a threshold, the untrusted data is determined to be unreliable or unknown. Determining that the untrusted data is unreliable or unknown includes determining a difference between the untrusted data and a model of the trustworthy data. The method further includes determining a trust score of the untrusted data relative to the trustworthy data. The method further includes generating an alert associated with the subject based on the matched untrusted data.The method further includes determining a behavioral pattern of the subject using the collated untrusted data. The method further includes generating a smart alert associated with the subject based on the behavioral pattern.

[0015] Implementations may also 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, the diabetes management data being received from a connected device or a user entry; the method further includes comparing the untrusted data to the trusted data to identify a behavioral root cause of the glycemic dysfunction; the method further includes identifying a behavioral root cause of the glycemic dysfunction using the matched untrusted data; the matching includes receiving the untrusted data at an input matcher, the untrusted data including an untrusted metabolic input; receiving the trusted data at the input matcher, the trusted data including an estimated untrusted metabolic input; and combining the untrusted data and the trusted data using a weight function to generate a matched untrusted metabolic input; the untrusted data and the trusted data received at the input matcher are in the form of a vector, and the matched untrusted metabolic input is in the form of a vector; the weight function is based on time relevance. The weighting function is based on the relative certainty of the unreliable data and the reliable data. The unreliable data includes a reported unreliable metabolic input, and combining includes matching a difference between the reported unreliable metabolic input and the estimated unreliable metabolic input. Matching includes matching the reported unreliable metabolic input and the estimated unreliable metabolic input with a behavioral model. Matching includes matching a difference between the amount and timing of the unreliable metabolic input and the estimated unreliable metabolic input with the measured data. The method further includes performing a replay prediction using the matched unreliable data and the reliable data. The method further includes outputting a simulated metabolic state based on the replay prediction. The method further includes performing a real-time prediction using the matched unreliable data and the reliable data.The method further includes outputting a simulated metabolic state based on the real-time prediction.

[0016] In an implementation, a method includes predicting data for a subject over a period of time, receiving untrusted data directed to diabetes management, simulating multiple predicted data traces over the period of time using a spectrum of possible variances of the untrusted data, comparing the simulated predicted data traces with the predicted data to identify a glycemic effect, and outputting a visualization or recommendation based on the glycemic effect.

[0017] Implementations may include some or all of the following features: The untrusted data includes glucose data and the predicted data trace includes a predicted glucose trace; Predicting the glucose data is based on trusted CGM data and a personalized model of the subject's glucose-insulin dynamics; Predicting the glucose data includes providing a best estimate glucose trace representing the glucose status over time; The untrusted data directed to diabetes management includes at least one of insulin timing, insulin amount, meal data, or activity data; The glycemic effect is related to a difference in at least one of the amount of diabetes management data or the timing of diabetes management data.

[0018] In an implementation, the system includes a processor and a metabolic model, where the processor is configured to receive untrusted user input and match the untrusted user input with trusted input using the metabolic model.

[0019] Implementations may include some or all of the following features: The processor is further configured to optimize the predictive capabilities of the metabolic model to predict future glucose levels. The processor is further configured to enable replay of events and treatment outcomes with alternative treatment protocols. The processor is further configured to provide a real-time prediction of a future metabolic state. 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 directed to at least one replay application. The at least one replay application includes assessment of blood glucose (BG) treatment outcome metrics in the analysis, identification of credible instances of scenarios in the replay analysis, evaluation of data quality, a credibility profile, and credibility of the data as a function of time. The processor is further configured to perform collated projections directed to at least one real-time application. The at least one real-time application includes determining certainty of medical action and the need to wait before providing advice.

[0020] Implementations may also include some or all of the following features: the untrusted user input includes estimated carbohydrates; the untrusted user input includes a time series of uncertain metabolic input; the trusted input includes CGM and insulin pump readings; and the trusted input includes a time series of trusted metabolic input. The processor is further configured to output the estimated metabolic state in the form of a time series, the final collated estimated metabolic state in the form of a time series, and the credibility of the final estimated metabolic state in the form of a time series and the collated estimated input. The processor is included in an integrated state / input estimator, and the metabolic model is a plug-in.

[0021] In an implementation, the method includes receiving, at an input estimator, untrusted data related to a subject, where the untrusted data includes user input data including at least one of insulin data, dietary data, or activity data; determining, at a trustworthiness assessor, the trustworthiness of the untrusted data; receiving, at the trustworthiness assessor, trusted data; and updating, at the trustworthiness assessor, the trustworthiness of the untrusted data using the trusted data.

[0022] Implementations may include some or all of the following features: determining the trustworthiness of the untrusted data includes determining a first trustworthiness based on at least one of a lack of integrity of the untrusted data or a lack of continuity of the untrusted data, determining a second trustworthiness based on expected behavior indicative of at least one of a lack of integrity of the untrusted data or a lack of continuity of the untrusted data, determining a third trustworthiness based on an estimated input artifact indicative of a systemic unknown factor, and aggregating the first trustworthiness, the second trustworthiness, and the third trustworthiness; determining the first trustworthiness includes using the measurement signal as an input, determining the second trustworthiness includes using the untrusted data and the trusted data as input, and determining the third trustworthiness includes using the untrusted data, the estimated untrusted data, and the matched data as input.

[0023] In an implementation, the method includes receiving, at an input estimator, first untrusted data associated with a subject, the first untrusted data including user input data including at least one of insulin data, meal data, or activity data; determining, at a trust assessor, the trustworthiness of the first untrusted data; receiving, at the input estimator, second untrusted data associated with the subject; determining, at the trust assessor, the trustworthiness of the second untrusted data; updating, at the trust assessor, the trustworthiness of the first untrusted data using the second untrusted data or the trustworthiness of the second untrusted data; receiving, at the trust assessor, trusted data; and updating, at the trust assessor, the trustworthiness of the first untrusted data and the second untrusted data using the trusted data.

[0024] Implementations may include some or all of the following features: determining a first trustworthiness of the untrusted data includes determining the first trustworthiness based on at least one of a lack of integrity of the untrusted data or a lack of continuity of the untrusted data; determining a second trustworthiness based on expected behavior indicative of at least one of a lack of integrity of the untrusted data or a lack of continuity of the untrusted data; determining a third trustworthiness based on an estimated input artifact indicative of a systemic unknown factor; and aggregating the first trustworthiness, the second trustworthiness, and the third trustworthiness; determining the first trustworthiness includes using a measurement signal as an input; determining the second trustworthiness includes using the untrusted data and the trusted data as inputs; and determining the third trustworthiness includes using the untrusted data, the estimated untrusted data, and the matched data as inputs.

[0025] In an implementation, the method includes receiving an estimated metabolic state, a collated estimated untrusted metabolic input, a trustworthy metabolic input, and an alternative metabolic input; performing a replay prediction using the estimated metabolic state, the collated estimated untrustworthy metabolic input, the trustworthy metabolic input, and the alternative metabolic input; and outputting a replay simulated metabolic state based on the replay prediction.

[0026] Implementations may include some or all of the following features: the estimated metabolic state, the collated estimated untrusted metabolic inputs, and the trusted metabolic inputs each comprise a time series, and performing the replay prediction includes estimating metabolic states over periods of the time series for the estimated metabolic state, the collated estimated untrusted metabolic inputs, and the trusted metabolic inputs to generate a replay simulated metabolic state.

[0027] In an implementation, the method includes receiving an alternative metabolic input, a collated estimated unreliable metabolic input, a reliable metabolic input, and a final estimated metabolic input; performing a real-time prediction using the alternative metabolic input, the collated estimated unreliable metabolic input, the reliable metabolic input, and the final estimated metabolic input; and outputting a predicted metabolic state based on the real-time prediction.

[0028] Implementations may include some or all of the following features: performing real-time prediction includes extrapolating a time series for the collated estimated untrusted and trusted metabolic inputs, and estimating a future metabolic state using the extrapolated time series, the alternative metabolic inputs, and the final estimated metabolic state; the method further includes filtering the extrapolated time series to prevent jitter in the predicted metabolic state; the estimated metabolic state is in the form of a time series; the method further includes filtering the estimated metabolic state to generate the predicted metabolic state; estimating the metabolic state uses a behavioral model of the subject; and extrapolating the time series uses historical data weighting based on at least one of time of day, features of the current estimated state, or a database of past metabolic inputs.

[0029] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. [Brief explanation of the drawings]

[0030] The foregoing summary, as well as the following detailed description of exemplary embodiments, will be better understood when read in conjunction with the appended drawings. For the purpose of illustrating the embodiments, there are shown in the drawings example constructions of the embodiments, but the embodiments are not limited to the specific methods and instrumentalities disclosed. The drawings are as follows:

[0031] [Figure 1] FIG. 1 is a diagram of an exemplary environment for assessing and visualizing data differences. [Figure 2] FIG. 1 is a block diagram of an implementation of a diabetes management processing platform. [Figure 3] FIG. 1 is a block diagram of an implementation of a retrospective input compiler. [Figure 4] FIG. 1 is a block diagram of a live input compiler implementation. [Figure 5] FIG. 1 is a block diagram of an implementation of a replay compiler. [Figure 6] FIG. 1 is a block diagram of an implementation of a prediction engine. [Figure 7] FIG. 1 is a block diagram of an implementation of a parameter estimator. [Figure 8] 1 is an operational flow of an implementation of a method for matching data. [Figure 9] 10 is an operational flow of another implementation of a method for matching data. [Figure 10] 1 is an operational flow of an implementation of a method for determining the trustworthiness of data. [Figure 11] 10 is an operational flow of another implementation of a method for determining the trustworthiness of data. [Figure 12] 1 is an operational flow of an implementation of a method for providing a glycemic-based output using untrusted data. [Figure 13] 1 is an operational flow of an implementation of a method for using replay prediction. [Figure 14] 1 is an operational flow of an implementation of a method for using real-time predictions. [Figure 15] 1 illustrates an exemplary computing environment in which exemplary embodiments and aspects may be implemented. DETAILED DESCRIPTION OF THE INVENTION

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

[0033] This description is not to be taken in a limiting sense, but is made merely for the purpose of illustrating the general principles of the invention, since the scope of the invention is best defined by the appended claims.

[0034] This specification describes various inventive features, each of which can be used independently of one another or in combination with other features.

[0035] Unreliable reporting of unmeasurable human behaviors and associated metabolic events (e.g., meals and boluses) is far more influential than the impact of sensor errors on inferences from signal processing of glucose time series data. As a result, unreliable data can be matched with reliable data, and the matched unreliable and reliable data are provided as estimated metabolic data useful for predicting or replaying glucose time series data.

[0036] In some aspects, systems and methods are provided for verifying untrusted data of a subject using trusted data related to the subject. In some aspects, the systems and methods are directed to evaluating the discrepancy of expected data against corresponding received data.

[0037] As further described herein, the retrospective prediction function evaluates whether alternative insulin administration strategies for the same meal would result in better treatment outcomes (e.g., lower glycemic risk). The retrospective prediction function takes the patient's initial (e.g., pre-meal) state, one or more meal events, and an insulin administration strategy as input and maps them to the resulting glucose excursion for that meal / day. In some implementations, the retrospective prediction function (1) maps original data (e.g., meal and insulin) to observations (e.g., CGM) with sufficient (e.g., predetermined) accuracy, (2) maps alternative administration strategies to the resulting glucose excursion in a manner that models the patient's (herein also referred to as the "subject") physiology (e.g., insulin activity and carbohydrate sensitivity), and (3) provides a reliable, interpretable solution to problems such as estimating insulin onboard as a stable, smooth function. To determine this function, the integrated state estimator and meal estimation system and method herein combine known inputs and user-informed meals. The output is that of a function that can replay the alternative insulin strategy with the same input conditions (or the outcome of the alternative insulin strategy itself).

[0038] In implementations, replay functions can be constructed from the same data set using other approaches known to those skilled in the art of metabolic modeling. One example approach is to fit the parameters of a known metabolic model to patient data or clinical studies. Another possible approach is to train a neural network on similar data to predict glucose excursions.

[0039] 1 is a diagram of an exemplary environment 100 for assessing and visualizing data variance. 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.

[0040] One or more of the insulin device 110, glucose monitor 120, processor 130, activity monitor 150, and smartphone 160 can communicate over a network. The network can be a variety of network types, including the public switched telephone network (PSTN), a cellular network, and a packet-switched network (e.g., the Internet). Although only an insulin device 110, one glucose monitor 120, one processor 130, one subject 140, one activity monitor 150, and one smartphone 160 are shown in FIG. 1 , 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.

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

[0042] Glucose monitor 120 can be any type of CGM or SMBG (self-monitoring of blood glucose) device, depending on implementation. Glucose monitor 120 can be a connected device that provides continuous glucose readings or a set of glucose readings when the device is scanned or downloaded. In addition to glucose readings, glucose monitor 120 can record user interactions, such as when and how a user (e.g., subject, patient, caregiver, medical professional, etc.) views the glucose trace and how they respond to alerts and alarms. User interactions can provide insight into the timing and motivation of treatment decisions, including why and when considering the impact of eating or administering insulin.

[0043] The processor 130 collects data from the insulin device 110 and glucose monitor 120 and the subject 140 and performs the methods described herein. To provide a robust system, these calculations can be dynamic and distributed depending on which devices and processors are connected. For example, cloud computing can be used when there is connectivity, a smartphone processor can be used when there is no connectivity, and a transmitter or smartwatch can be used when no smartphone is connected. Complex calculations, such as model optimization, can only be performed if a more powerful processor is available. If a powerful processor is not available, the algorithm can use the latest parameters or simpler approximations.

[0044] The processor 130 (as well as the insulin device 110, glucose monitor 120, activity monitor 150, and / or smartphone 160) can be implemented using a variety of computing devices, such as, for example, a smartphone, a desktop computer, a laptop computer, and a tablet. Other types of computing devices may be supported. A suitable computing device is shown in FIG. 15 as computing device 1500.

[0045] The subject 140 can provide input to the system, including information about diet, activity, and diabetes treatment, using any computing device in communication with the system, such as, for example, the subject's 140 smartphone 160 or other computing device. These inputs can be user-initiated or prompted by the system. These inputs can describe current, previous, and / or future events.

[0046] Activity monitor 150 can be any device that monitors a user's physiological and mental state. An example is a fitness tracker that uses an accelerometer, gyroscope, heart rate, and oxygen sensors to monitor activity, exercise, and sleep. This can also include a smartphone or smart home device (e.g., Amazon Alexa) that can detect location and user activity / interaction. In some implementations, activity monitor 150 includes a device that detects meals.

[0047] The smartphone 160 can be used as an activity and status monitor, a data entry device, data collection (communicating with devices using Bluetooth, NFC, Wi-Fi, etc.), and can run applications (e.g., apps) that estimate nutritional information through manual or automated entry (e.g., photos).

[0048] The systems and methods described herein estimate metabolic state from a combination of trusted and untrusted metabolic inputs, optionally using a personalized mathematical model with parameter optimization. The systems and methods provide the measured impact of a blood glucose signal (using a CGM) consistent with the metabolic model (optional) on the verified untrusted input. Estimation of future metabolic state for decision support and automated insulin administration is enabled using the systems and methods described herein. For example, data reliability does not declare an entire day valid or invalid, but instead provides time-series reliability data in parallel with metabolic state estimates, avoiding the problem of modeling continuous processes such as overnight predictions. Replays of scenarios using estimated or verified data are also provided. All data, including metabolic state (trusted and untrusted verified), are provided from a time-domain perspective, along with corresponding reliability, predictions, and replays. Retrospective predictions, also referred to as replay compilations, and future predictions, also referred to as real-time prediction compilations, are made more reliable and accurate by the verification process implemented herein.

[0049] 2 is a block diagram of an implementation of a diabetes management processing platform 200. Platform 200 uses matching, replay analysis, prediction, and / or confidence determination, along with optional optimization of parameters, to, for example, predict future analyte values ​​or unobserved conditions, inform bolus decisions, assess carbohydrate onboard, assess insulin onboard, enable smart alert functionality, deliver retrospective therapy optimization, and provide feedback on estimates. Diabetes management platform 200 includes module inputs, outputs, and interrelationships, which are further described herein.

[0050] 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 live input compiler 220L. Platform 200 may include more or fewer modules depending on the implementation. In some implementations, for example, parameter estimator 270 is optional.

[0051] Data is provided to the input compiler 220 and may include measured signals, reliable indirectly observed metabolic inputs (i.e., trusted metabolic inputs), unreliable indirectly observed metabolic inputs (i.e., untrusted metabolic inputs), and an estimated initial state describing the patient's condition at the time of the first data point. Examples of measured 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 dietary or physical activity reports from a professional caregiver at a clinical site, with guaranteed accuracy in terms of timing, extent, and content. Examples of untrusted metabolic inputs include on-site dietary or physical activity reports using a pencil / paper (e.g., handwritten) diary, or the logging function of a medical device that does not have a means to enforce accuracy.

[0052] The input compiler 220 processes the retrospective data 210 using a retrospective input compiler 220R and processes the live data 212 using a live input compiler 220L. The retrospective data 210 is provided to the retrospective input compiler 220R and the parameter estimator 270, as further described, e.g., with respect to FIGS. 3 and 9. The live data 212 is provided to the live input compiler 220L. Depending on the implementation, the live data 212 may be real-time, within a particular time window, during a processing cycle, etc. The live data 212 is further described, e.g., with respect to FIGS. 6 and 9.

[0053] In implementations, the input compiler 220 includes a state estimator (e.g., state estimator 340 shown in FIGS. 3 and 6 ), which may use the personalized physiological model to generate outputs such as collated estimated metabolic inputs, an estimated metabolic state of the patient during the period of the input data, a numerical assessment of the reliability of the estimated state, and a numerical assessment of the reliability of the collated estimated metabolic inputs. The collated estimated metabolic inputs are used in conjunction with the assessment of the reliability of the estimated metabolic state and the reliability of the collated estimated metabolic inputs. In addition to use within interrelated modules of the system, collated data, such as collated dietary and insulin history, can be reported to the patient or other user.

[0054] The replay compiler 230 uses the output 225R of the input compiler 220 operating on the retrospective data 210 (i.e., the output 225R of the retrospective input compiler 220R) along with a state estimator using estimated model parameters 275, which may be an individualized physiological model, and the replay user requirements and component models 235 to generate outputs such as a replay prediction function 240 and / or other replay analyses. The replay prediction function 240 can operate on alternative metabolic inputs (different from the collated metabolic inputs) in the form of alternative specific inputs or alternative strategies, and generate replay predictions in the form of simulated metabolic outcome trajectories from the alternative metabolic inputs along with associated prediction confidence. The resulting replay prediction function 240 can be used in a wide variety of applications, including retrospective therapy optimization or retrospective insight into therapy. Assessment of the confidence of the replay prediction is directly linked to the confidence of the collated estimated metabolic inputs, both of which enable further features and functionality described herein. Additional application and replay compiler outputs include, for example, basal titration showing the impact of bolus timing vs. meal timing, validation of the AP algorithm.

[0055] The prediction engine 250 uses the output 225L of the live input compiler 220L, which operates on the live data 212, along with a state estimator using estimated model parameters 275, which may be an individualized physiological model, and prediction user requirements 253 to generate live input-matched predictions 255. The live input-matched predictions 255 operate on candidate current and future metabolic inputs to generate real-time predictions in the form of predicted trajectories of metabolic treatment outcomes for the candidate inputs, along with associated prediction confidence. The live input-matched predictions 255 can be used in a wide variety of applications, including (i) real-time decision-making, including next control step selection in closed-loop diabetes control, predictive bolus advisors, and decision support, and (ii) comparison of alternative actions to generate real-time insights, such as smart alerts. The assessment of the confidence of the live input-matched predictions 255 is directly linked to the confidence of the matched estimated metabolic inputs, both of which enable further features and functionality described herein.

[0056] The parameter estimator 270 uses the patient's biometric and demographic information 273 along with the retrospective data 210 and the output 225R of the retrospective input compiler 220R to determine and output estimated model parameters 275 (e.g., of the state estimator, which may be an individualized physiological model). An individualized physiological model is useful but not required in the implementation. The parameter estimator 270 is useful in the context of an implementation utilizing an individualized model for estimation, but is not a critical requirement.

[0057] 3 is a block diagram of an implementation of the retrospective input compiler 220R. In general, this approach of combining trusted and untrusted metabolic inputs can be applied whenever one wishes to match data inputs with uncertain accuracy or reliability. The retrospective input compiler 220R comprises a metabolic input estimator 320, a trustworthiness assessor 310, an input matcher 330, and a state estimator 340.

[0058] 2, retrospective data 210 is input into retrospective input compiler 220R. Retrospective data may be provided in a variety of formats, including measured signals or inputs, trusted metabolic inputs, untrusted metabolic inputs, and estimated states. Retrospective input compiler 220R classifies inputs as trusted and untrusted, determines various estimates, calculates estimates for untrusted inputs in the form of collated estimates of historical metabolic inputs, and takes unrecognized estimates of carbohydrates, for example, and collates them against the incoming data.

[0059] The measured signals are included within the retrospective data 210 and are provided as inputs to the retrospective input compiler 220R, and more specifically to the metabolic input estimator 320. The measured signals are typically measurements of glucose levels, including, for example, real-time CGM readings, confidence readings assigned to CGM values, self-monitored blood glucose readings (blood 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.

[0060] Metabolic inputs are contained within retrospective data 210 and provided as inputs to retrospective input compiler 220R, and more specifically, to metabolic input estimator 320. Metabolic inputs can generally be thought of in terms of what happened when (timing and magnitude). An example might include estimating metabolic state from known metabolic inputs recorded by an insulin pump and uncertain metabolic inputs describing meals recorded by the user.

[0061] A reliable metabolic input is a known metabolic input that can be directly recorded by an electronic / electromechanical device and / or estimated by a machine. Examples include insulin pumps and connected insulin pens that record insulin injection times. These devices directly measure with high accuracy the operation of the pump or syringe that is delivering insulin. Note that obstructions, such as blockages, that cause uncertain infusion rates may still exist. With regard to insulin input, the systems and methods contemplated herein are not tied to a particular model for delivery (e.g., pump vs. pen).

[0062] Unreliable metabolic inputs are uncertain metabolic inputs that may be entered by the user. Unreliable inputs can be thought of in terms of what happened and when (e.g., timing and magnitude). An example is a user input providing the carbohydrate content and meal time of a meal manually entered into a phone app. More broadly, this includes any input to a time series that relies on a user entry that is not confirmed by a connected device, such as insulin administration using an unconnected pen or pump. This might include, for example, carbohydrates estimated by another phone app, such as ByteSnap. In principle, an unreliable metabolic input could also be unreliable insulin action due to variability in infusion pumps and infusion sites. This is the uncertainty of these dynamic inputs to the system, which can be reconciled with retrospective measurements (such as with a CGM). Unreliability can refer to the inaccurate timing or content of event data, such as meal entries. Unreliable metabolic inputs can also include factors that are difficult for the user to quantify, such as exercise or illness. Some unreliable metabolic inputs arise from indirectly measured inputs.

[0063] Meal inputs are defined by time and carbohydrate amount. User inputs (meal announcements) are typically defined as single carbohydrate events. Some exemplary user-input meal data that may be unreliable include the user estimating the carbohydrate amount or other nutritional information for a meal; for example, the user may estimate a burrito but not include the chips and salsa eaten while waiting; meals are simplified to small-medium-large qualifiers; meals are simplified to carbohydrate amount without considering the glycemic index; meal responses also depend on fat and protein content; the user anticipates when they will eat when entering a pre-meal bolus; the user is prompted to recall when they ate after the system detects a meal response; and the system records a single time for a meal that spans a period including an appetizer, main course, and dessert.

[0064] Some examples of untrusted metabolic inputs resulting from indirectly measured inputs include a meal app that estimates carbohydrates using databases, barcodes, restaurant photos, etc., a meal app that classifies your next meal from a library of previous meals, exercise intensity and duration estimated from a fitness tracker (heart rate / accelerometer), and sleep duration estimated from a fitness tracker.

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

[0066] [Table 1]

[0067] The last row of Table 1 is intended to include "unreliable action" of insulin due to infusion pump and infusion site variability. In other words, the pump may reliably register plunger movement, but this insulin may not enter the body due to issues with the infusion site or catheter. As a result, in some implementations, the amount of insulin pumped must be matched with the observed (lack of) insulin action.

[0068] Other inputs may include gut and glucose appearance rates, sensor delays, and could be extended to general metabolites, for example.

[0069] The estimated initial states are data contained within the retrospective data 210 and provided as input to the retrospective input compiler 220R, and more specifically, to the metabolic input estimator 320. The estimated initial states provide the initial state of the glycemic model, including glucose levels (blood and other compartments), insulin levels (blood and other compartments), carbohydrate levels (from previous meals), and metabolic demand (the effect of previous exercise and current activity level). This may be a vector, as it defines these quantities at a point in time (the initial state).

[0070] In some embodiments, one or more model parameters 275 may be provided as input to the retrospective input compiler 220R (eg, input matcher 330).

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

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

[0073] The metabolic input estimator 320 can use individualized mathematical models, which are compartmental models of metabolic processes that produce or consume glucose in the body. For example, the model has terms that describe the postprandial glucose increase, insulin-stimulated glucose uptake into muscle and adipose tissue. The model is individualized to account for insulin action and meal metabolism and differences between subjects in diabetes (e.g., type 1 vs. type 2).

[0074] In one implementation, the systems and methods described herein estimate uncertain metabolic inputs and states for a time series, which may include estimation of unknown / incompletely observed events. In this implementation, metabolic input estimates are based on measured signals, previously estimated metabolic states, and known metabolic inputs, which are extracted to form vectors of measurements, inputs, and corresponding initial states. Uncertain inputs (e.g., reported diet) are not inputs at this stage. Only what was previously known and measured is input. The raw inputs are converted into vectors of an appropriate length depending on the use (e.g., retrospectively, using a 36-hour day to capture a full daily cycle and avoid edge effects / boundary conditions, as opposed to 6 hours in real time). These are the measured signals. The range (duration) of the data varies depending on the application (i.e., implementation) and can range from minutes to hours to days. The data can then be aligned, snapped, interpolated, and smoothed as needed, depending on the implementation. The system then uses a linear dynamic model (e.g., without mapping) to determine the systematic residual, which is the difference between the measured signal and the model-predicted influence of the estimated initial metabolic state and known metabolic inputs. The unknown input that best explains the systematic residual is then calculated based on the fit of the systematic residual and the shape (e.g., regularization) of the estimated unknown input. For example, a set penalty for the fit may emphasize (i) high-confidence samples, (ii) the last sample, (iii) the last rate of change, and (iv) important samples (e.g., hypoglycemia or hyperglycemia). The set regularization penalty to achieve desired characteristics may include (i) smoothness or discreteness of the estimated unknown input, (ii) tolerance / disallowance of bias, and (iii) tolerance / disallowance of high rates of change or acceleration (other set constraints may include non-negativity (e.g., for meals)). This is a type of inverse problem solved by regularized deconvolution. The challenge is to constrain the inversion to physically reasonable and interpretable values ​​that are reasonably consistent with the measurements (CGM traces), initial conditions, and provided inputs.To achieve desirable properties, such constraints can be imposed, including non-negative diets, temporal diet regularization, and slowly time-varying insulin differentials, so that the importance of fitting the data can be dynamically adjusted based on, for example, quality. From these calculations, vectors of both estimated metabolic state trajectories can be extracted, and raw estimated uncertain metabolic inputs can be extracted.

[0075] The trust assessor 310 generates an output (outputs a trust value) of trust 315R, which is derived from the difference between the raw estimate and the reported value of the untrusted input.

[0076] The confidence assessor 310 evaluates multiple inputs, including measured signals, known metabolic inputs, reported uncertain metabolic inputs, raw estimated metabolic states, uncertain metabolic inputs, and collated uncertain metabolic inputs, all of which may be provided in time series.

[0077] Confidence based on the measured signal may assess the continuity (e.g., lack of continuity) or completeness of the time series data and may include one or more of a sensor assessed certainty threshold, calibration events, maximum gap size, float range, periodic range, etc.

[0078] Confidence based on known metabolic inputs and raw estimated metabolic states and uncertain metabolic inputs may assess expected behavior indicative of incomplete data or lack of consistency, and may include one or more of expected correlation between inputs (uncertain or known), expected number of events, floating range / periodic range, etc.

[0079] Confidence based on reported uncertain metabolic inputs, raw estimated metabolic inputs, uncertain metabolic inputs, and collated uncertain metabolic inputs can be assessed for local versus global variance (indicating unannounced or unreported inputs), discrepancy between reported and estimated uncertain inputs, pattern matching, floating / periodic ranges, etc.

[0080] The confidence assessor 310 aggregates one or more of the confidence assessments described above and provides (outputs) a final estimated metabolic state and the confidence of the collated estimated inputs, which may include the confidence as a time series.

[0081] The credibility assessor 310 may determine CGM continuity, quality of match, total carbohydrates, number of carbohydrate events, carbohydrates corresponding to BG artifacts, agreement with user-reported carbohydrates, authenticity of insulin data (especially in MDIs (metered dose inhalers)), etc.

[0082] In some implementations, an aggregate sense of the trustworthiness of data collected at a particular time can be obtained by averaging the trustworthiness scores for that time across multiple days. A low average trustworthiness score for that time may indicate a systematic problem with how the data is collected. For example, if a patient uses an unplugged pen to bolus meals at work, this will show up as high insulin values ​​at that time and high variability over time, which will translate into a low average trustworthiness score for that time. As another example, if a patient consistently approves regular meals at times far removed from the estimated carbohydrate intake, this could result in a low trustworthiness score for both the actual meal and the meal approval.

[0083] The input verifier 330 matches the uncertain and unreliable user inputs with estimated inputs, where the matching is based on one or more of the measurement signals, the reliable metabolic inputs, the unreliable metabolic inputs, and the model parameters. These methods do not necessarily evaluate a penalty for the closeness of the estimate to the reported one, but rather may evaluate a sigmoidal wave of the reported and estimated inputs over time. In some implementations, the method can learn the patient's typical errors over time. The input verifier 330 outputs matched estimates of the metabolic inputs and disorders for use in further processing and / or display.

[0084] The state estimator 340 provides an estimate of what was actually happening in the system. Process disturbances here are allowed to be non-zero (e.g., not zero mean) and not measurement errors. The output of the state estimator is an estimate of the state, which can be multiple vectors / matrices.

[0085] In one implementation, the state estimator receives the initial metabolic state (from past state estimations), the (vector of) known metabolic inputs, and the (vector of) verified uncertain metabolic inputs. After estimating and verifying the input time series, all that needs to be calculated is the associated state trajectory, which is output as the final estimated metabolic input vector.

[0086] One exemplary model captures the interaction of insulin on glucose clearance with two differential equations involving different types of insulin (e.g., fast-acting and long-acting) and different equilibrium compartments (e.g., liver) used in intensive insulin therapy. Other metabolic models can be used in this same framework for prospective and retrospective estimators. The tradeoff is between physiological completeness and stability / observability. For example, simple models can combine physiologically separated details or compartments with several types of mass transfer, while more complex models can resolve differences between patients or differences in glucose-insulin behavior over time. In practice, there is a limit to the complexity of models that can be observed using only CGM data and observational data (e.g., normal diurnal variation). This is because more complex models may require additional measurements, such as multiple tracers, or clinical studies with well-described inputs, such as an OGTT (oral glucose tolerance test) or a meal with known composition (fat / carbohydrate / protein). However, more complex models may be useful in addressing issues with corrupted inputs.

[0087] A credibility determination may be performed here on the estimated metabolic state independently of a credibility determination that may be performed on a matched unreliable metabolic input, including the credibility of the matched estimated metabolic input and the credibility of the estimated metabolic state.

[0088] The output of the retrospective input compiler 220R includes collated estimated metabolic inputs, which are estimated and collated untrusted metabolic inputs. The trusted metabolic inputs may be considered pass-through inputs and, therefore, may be output in their original form in some implementations. Note that these inputs and outputs do not include uncertainty in model parameters such as insulin sensitivity.

[0089] Exemplary output of the retrospective input compiler 220R may include a perturbation signal describing transients in the blood glucose signal due to different influences (signatures in BG fluctuations), as well as transients in the signal that vary from oral carbohydrate and other influences, which can be separated into signals describing the postprandial response of an OC (oral carbohydrate) mixed meal (adjusted to account for previous carbohydrate and insulin delivery), low-frequency fluctuations in blood glucose concentrations consistent with changes in insulin sensitivity, and signals describing aspects of the blood glucose trace that cannot otherwise be interpreted as postprandial response or changes in insulin sensitivity, such as fluctuations due to posture changes, physical activity, or (potentially) meals that do not fit well into the profile of a "mixed" meal.

[0090] The estimated net oral carbohydrate impact can also be determined. A single meal can be divided into several separate carbohydrate signals. There may be additional glucose from endogenous sources such as the liver, which is modeled as net oral carbohydrate.

[0091] Other behaviors or physiology that may be captured include, for example, blood glucose consumption during exercise (which acts like insulin as it increases glucose uptake), changes in insulin sensitivity after exercise, diurnal variation in insulin sensitivity (circadian variation), insulin onboard curve / insulin curve difference, and unlogged boluses.

[0092] The metabolic state estimate 345R includes time series of insulin and glucose levels within the compartments of the model and the CGM signal.

[0093] The final collated meal history includes time and net carbohydrates. The insulin delivered is a pass-through of the retrospective input compiler 220R.

[0094] Thus, in the retrospective input compiler 220R, an estimate of the patient's metabolic state is constructed from a stream of trusted data, and in turn, a stream of untrusted data estimates (associated with its estimated state trajectory for each estimated time period) have a trustworthiness assessment (the confidence that the patient ate something and when). This can be performed historically on the last month's data, but can also be performed on newly received data, such as, for example, the live data 212 described further herein with respect to the live input compiler 220L.

[0095] 4 is a block diagram of an implementation of the live input compiler 220L. The live input compiler 220L includes the same components as the retrospective input compiler 220R, but instead of using retrospective data 210 as input, it uses live data 212 as input. Thus, like the retrospective input compiler 220R, the live input compiler 220L also includes a metabolic input estimator 320, a confidence assessor 310, an input matcher 330, and a state estimator 340.

[0096] The output fields of the live input compiler 220L are the same as those of the retrospective input compiler 220R, except that they are based on live data 212. As such, the output of the live input compiler includes confidence 315L, recorded estimates of metabolic inputs and disorders 335L, and estimated metabolic state 345L. In this way, unreliable portions of the live data 212 are reconciled based on other available data. For example, metabolic inputs such as carbohydrates for the past six hours can be estimated, and the corresponding state for the past six hours and confidence for the past six hours can also be estimated.

[0097] Using the live input compiler 220L, the patient is interacting with the system and method in real time. Patients do not behave as consistently as AP systems and do not always provide accurate data (e.g., incorrectly reported carbohydrates due to counting issues, timing issues, or both). In one exemplary application, it can suggest when and / or how much a meal appears to have been consumed, allowing the patient to confirm, reject, or modify the suggested meal information. This enables meal / exercise detection and plasma glucose prediction. In the glucose prediction example, the systems and methods described herein can use the past six hours of data to predict glucose for the next two hours. Additionally, the reliability of the sensor data can be determined (how close to calibration, whether the signal is high or low, whether the sensor is out of range) and used to measure the overall reliability of carbohydrates and insulin. Similarly, the reliability of insulin data can also be determined (missing basal data, unexplained drops in glucose levels (unconfirmed boluses), etc.). The systems and methods enable intelligent interaction and decision-making, knowing the match between detected data and reported data.

[0098] When dealing with live data, it is important to pay particular attention to the most recent values ​​and their slopes, since we do not benefit from future knowledge. For example, by weighting the most recent data more heavily, we ask the estimator to find a match between the most recent points (the last two). In one implementation, an input matcher vector extracts uncertain metabolic inputs reported for a real-time application, and the resulting vector is such that the last entry corresponds to the current time. The extracted vector is combined with a vector of raw estimated uncertain metabolic inputs and combined in a function based on time association and / or relative certainty, as described below.

[0099] Example 1 (for a live predictor): Weighting is applied based on time relevance, with recently reported inputs weighted most heavily, previously reported inputs weighted lightly, and recent raw estimated inputs (if any) weighted lightly, since future data is needed.

[0100] Example 2 (applied live or retrospectively): Weighting is applied based on the relative certainty of reported and estimated untrusted inputs, where certainty is based on user / system ratings and / or model-based certainty of the estimated inputs.

[0101] In one exemplary application, the system and method estimate carbohydrate intake independent of user input. For patients who treat diabetes using multiple daily injections (without a smart pen), data suggests this is the safest assumption. The system and method considers situations when a patient reports a carbohydrate estimate that does not match the estimated carbohydrates independent of user input. The process of matching is useful because the system and method cannot consider both the estimated carbohydrate estimate and the reported carbohydrate estimate to be true. Upon matching, the system and method represent the result of the match as a new pair of matched estimated input.

[0102] Figure 5 is a block diagram of an 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 dynamic equations 525. The replay compiler 230 performs replays of glucose traces by modifying the inputs to determine the impact of the modified inputs. The replay compiler 230 provides a machine for assessing BG, insulin, dietary, and behavioral treatment outcomes in different domains (individual / population) and with different masks (closed loop, sleep, confidence, etc.). The system and method simulate scenarios with any non-optimal diabetes interventions to determine the optimal intervention and quantify the effect of the optimal intervention as a CGM trace or optimal vs. non-optimal glycemic response.

[0103] The input to the replay compiler 230 is the retrospective compiled input (i.e., output 225R of the retrospective input compiler 220R), including confidence 315R, collated estimates of metabolic inputs and disorders 335R, and metabolic state estimates 345R (e.g., estimated metabolic state, final collated estimated metabolic inputs, known metabolic inputs, and alternative metabolic inputs (specific inputs or strategies during the time series)). In some implementations, the input includes all metabolic inputs (collated estimates of trusted and untrusted) as a time series and confidence.

[0104] The input classifier 510 receives as input the metabolic inputs and collated estimates of disorders and classifies each data point as a modifiable exogenous metabolic input 512 or an invariant exogenous input 515 .

[0105] In some implementations, one trusted data (e.g., insulin) may be modified. In other implementations, one trusted data and one untrusted data (e.g., meal data) may be modified. In other implementations, all inputs may be modified.

[0106] The replay compiler 230 may consider various scenarios: A) all untrusted matched data is corrected by the replay function; B) some, but not all, untrusted matched data is corrected by the replay function; C) some trusted data is corrected by the replay function; or D) a combination of B) and C). Generally, the replay compiler 230 corrects at least some data and runs at least one simulation. For example, this may be one trusted data, such as insulin. In some cases, it may be both one trusted data and one untrusted data, such as both insulin and meals (e.g., replacing the matched bolusable carbohydrates with a meal action from another script, leaving the BG variability signature as the only one not to be corrected). In an exemplary embodiment, all inputs are corrected.

[0107] Replayer core 520 includes input modifier 523 and dynamic equations 525. Input modifier 523 receives modifiable exogenous metabolic inputs 512 and a specification of rules for modifying historical inputs 550 (also referred to as specification of rules 550).

[0108] Thus, input 512 is modified in input modifier 523 using the specification of rules 523, which are "what if" scenarios that are tested to determine treatment outcomes based on the modification of the input. Rules can be selected by the user individually and / or based on pre-defined scenarios. Some rules that can be specified are: conversion of MDI to CSII (continuous subcutaneous insulin infusion) or vice versa, long-acting dosage / timing, basal rate profile, recognition / deletion of hypoglycemic treatments in historical data, revision of historical boluses, revision of bolus delivery parameters, insertion of future hypoglycemic treatments when alternate insulin input creates a new instance of hypoglycemia, replacement of historical meal instances with future models, replacement of historical carbohydrate acceptance with future acceptance models (e.g., accept carbohydrates when close to estimated carbohydrates).

[0109] Additional specification of rules can be designed to address and evaluate type 2 treatments, including exercise and / or exercise-centered treatment optimization, treatments involving rescue carbohydrates (e.g., as needed), treatments involving other meal bolus administration strategies (e.g., split, delayed, extended bolus), oral medications, etc.

[0110] Specification of rules may be provided directly by the patient, as will be understood by those skilled in the art, based on invocation of certain pre-programmed functions, based on user interfaces such as reporting and analysis software and / or other interfaces that allow the user to select certain scenarios ("What if I bolus early?"), ask certain questions ("What if I'm on pump therapy?"), and / or modify certain inputs ("What if I take 2 extra units of insulin when I bolus?"). Selections may be real-time or retroactive and may be displayed with various levels of granularity.

[0111] The output of the input modifier 523 is provided as input to the dynamic equations 525 along with the invariant exogenous inputs 515 , the metabolic state estimates, and the model parameters 275 .

[0112] In implementations, the dynamic equations can use individualized mathematical models, which are compartmental models of metabolic processes that produce or consume glucose in the body. For example, the model has terms that describe the postprandial glucose increase, insulin-stimulated glucose uptake into muscle and adipose tissue. The model is individualized to account for differences in insulin action and dietary metabolism and between diabetic subjects.

[0113] The dynamic equations 525 perform a replay on the input. The replay performs model-based estimation using any known model-based approach that takes into account meal and / or insulin parameters. For example, the model can use a standard mixed meal, which is a typical combination of carbohydrates, protein, and fat. However, other meal signatures, such as high-carbohydrate / glycemic meals and / or low-carbohydrate / glycemic meals, or combinations of various types of meals, can be used. In some implementations, long-acting and short-acting meals can be added based on composition, glycemic index, etc. This is performed as part of the matching. If the effect of a meal differs significantly from a standard meal, it can be accounted for in a way that is not physiologically accurate. For example, 30g of carbohydrates from a pizza can be estimated by an initial 30g meal followed by two 10g meals.

[0114] In an implementation, the estimation of the metabolic state is performed during the duration of the input time series, allowing the personalized mathematical model to regenerate until the end of the input time series.

[0115] Model parameters 275 are optional estimates that are useful, but not required, as feedback input to better individualize the parameters for the patient.

[0116] Replay credibility 580 is determined by the replay compiler and output. The replay compiler 230 identifies and outputs credible instances of particular scenarios (samples) in the replay analysis. This can be done by scoring each sample (e.g., each replay analysis result) with a credibility score. For example, identifying credible instances of successfully averting hypoglycemia, failing to avert hypoglycemia, and / or omitting or significantly delaying a meal bolus. The average credibility score of the samples in the replay analysis dataset gives an overall sense of the importance / veracity of the replay results, which can aid in interpreting the results.

[0117] A comparator may be included within the replay compiler 230 to compare various time series from the dynamic equations 525 based on the reliability of the data (less reliable data is ignored or weighted to have a lower weight). In another example, if the BG signature is irregular, the data during that period may be less reliable. Those skilled in the art will appreciate that there are many ways to recognize that patient data is inconsistent with a model.

[0118] In an implementation, BG treatment outcome metrics are assessed on the replayed time series based on one or more of the following: sample mean, sample variance, time in range, episodes of high / low BG, low blood glucose risk, high blood glucose risk, and overall risk. Unlike prior art techniques that weight all samples equally to calculate the average blood glucose, here the credibility score of each sample is used to determine the weight each sample has on average.

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

[0120] In some embodiments, the function output of the replay compiler 230 can be a recreated (simulated) CGM trace that the patient actually experienced. The replay compiler 230 is a function that, when run on a historical CGM, recreates the trace, where the CGM trace is a smoothed version of the CGM trace without sensor inaccuracies, and can include additional information, such as additional correlated data not provided by the patient (e.g., diet).

[0121] In a therapy optimization in a DSS (decision support system) or AP use case, the replay compiler 230 can optimize a therapy, such as total daily basal, where the input is the parameter to be optimized (actual basal insulin) and the output is an optimized version of that input (optimal basal insulin). The replay simulates the optimal prescribed dose / time for a parameter (total daily basal in one example).

[0122] In a patient education use case, dynamic reports (retrospective or real-time) may be generated that allow the patient to highlight or drag through scenarios and see the results of "what if scenarios" returned by the replay compiler 230. For example, a slider bar in the graphical user interface may allow the patient (or other user) to slide things to see the effects resulting from the replay analysis (more carbs, less carbs, higher blood glucose, lower blood glucose, early bolus, late bolus, more insulin, less insulin, etc.).

[0123] In some embodiments, providing an output of an average credibility score for the samples in the dataset in the replay analysis gives an overall sense of the importance / veracity of the replay results.

[0124] In some embodiments, a risk stratification tool for medical professionals may be provided as an output identifying patients by particular category or need, e.g., patients with the lowest pre-meal bolus compliance, and may include potential benefits of treatment adjustment.

[0125] In some embodiments, the output may highlight / prioritize the most impactful potential changes in the reporting interface (e.g., changes to insulin timing vs. bolus amount, or highlighting the best meals).

[0126] In some embodiments, the output may elicit coaching comments and discussion points via coaching calls or chatbot prompts.

[0127] 6 is a block diagram of an implementation of a prediction engine 250. The prediction engine 250 receives as input retrospective compiled inputs 225R and live compiled inputs 225L, along with model parameters 275 and predicted user requirements 253, and outputs real-time predictions 255.

[0128] The initial state of the prediction engine 250 accounts for the amount of insulin and carbohydrates already in the body that are affecting glucose levels. Without additional action, the prediction engine 250 predicts future metabolic states, such as glucose excursions and hypoglycemic events from previous meals. The prediction is an extrapolation of the collation from the input compiler 220. In other words, the prediction is responsive not only to historical data but also to the collated data.

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

[0130] The input extrapolator 610 performs the extrapolation using the predicted user requirements 253, the metabolic inputs and disorders credible and collated estimates from the retrospective compiled input 225R, and the metabolic inputs and disorders credible and collated estimates from the live compiled input 225L. The extrapolated data is provided from the input extrapolator 610 to the input filter 620.

[0131] The input extrapolator 610 extrapolates the input time series to account for (1) additional information about the future available in real time (e.g., expected meals, exercise, etc.) and (2) the signature of BG variability.

[0132] The input extrapolator 610 uses the retrospectively compiled input 225R to make inferences based on historical data, for example, the influence of recent history on BG variability signatures (i.e., disorders) and historical signatures of BG variability, which can be used to interpret the data as it moves further into the prediction range.

[0133] The prediction engine 250 can project disturbances (BG variability signatures) that indicate trends in data inaccuracies due to discrepancies in the collated data. Disturbance signals are the result of the collation process and can be considered as estimated unknown signals. For example, disturbances can arise from circadian rhythms, movement tendencies, etc. The accuracy of the prediction depends on various assumptions about the future based on the nature of the disturbances.

[0134] The input filter 620 filters the extrapolated data with the predicted user requirements 253 and provides its output to the metabolic state estimator 630 .

[0135] Depending on the implementation, input filter 620 is optional but may be useful when no other filtering or smoothing has 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 due to (1) sensor noise and (2) a rapidly evolving understanding of recent unreliable inputs. In some implementations, input filter 620 uses a low-pass filter to minimize jitter in the predicted trajectory over successive updates.

[0136] The initial condition extractor 650 extracts data from the metabolic state estimates of the live compiled input 225L and provides the extracted data to the metabolic state estimator 630.

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

[0138] The metabolic state estimator 630 receives the (optionally filtered) extrapolated inputs, extracted initial conditions, and model parameters to the extent that the estimator uses a personalized physiological model. A variety of estimators may be useful. In one embodiment, the metabolic state estimator 630 performs an open-loop estimation of the metabolic state from a best estimate of the metabolic state vector at the beginning of the time series into the future, and regenerates the personalized physiological model all the way to the end of the prediction horizon.

[0139] In some implementations, the metabolic state estimator 630 can use individual mathematical models that are compartmental models of metabolic processes that produce or consume glucose, such as those that describe the postprandial glucose increase, insulin-stimulated glucose uptake into muscle and adipose tissue.

[0140] The output filter 640 filters the output from the metabolic state estimator 630 along with predicted user requirements 253 and the metabolic inputs and impairments confidence and verified estimates from the live compiled inputs 225L and provides its output as a real-time prediction 255. The output filter 640 can be used to constrain the real-time prediction 255 according to the live compiled inputs 225R.

[0141] Output filter 640 is an output module that presents a predicted output time series (i.e., real-time prediction) and (1) allows dramatic changes in the predicted trajectory only when there is a discernible and significant change in the matched input, and / or (2) filters / smooths or otherwise prevents jitter in the predicted trajectory due to sensor noise.

[0142] The real-time prediction 255 (i.e., live prediction) can be a predicted profile of future BG (e.g., in vector form) and can be used to inform future decision-making. For example, the prediction can indicate an upcoming hypoglycemia, which can then be used to issue an alert and / or have the patient take a fast-acting glucose tablet. Matching and prediction as described herein can enable improved responsiveness to patient behavioral changes, resulting in better prediction of metabolic status.

[0143] In some implementations, the real-time prediction 255 is a vector of predicted metabolic states. The resulting prediction remains stable until there is a marker of an impending state change (e.g., meals and insulin, allowing for a more dynamic output). Patient-provided and detected inputs lead to credible changes when the patient expects them.

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

[0145] The forward-looking BG variability signature is a key differentiator of the prediction engine 250. Additional key benefits that can be used alone or in combination include matched meals, extrapolation of inputs (e.g., setting meals to zero), and time-of-day informed BG variability signatures from retrospective models and daily trends. Typically, real-time predictors are re-run for the past six hours of data starting point.

[0146] The weighting of the BG variability signatures depends on the patient's differential and on the available reported and collated data and their reliability (e.g., time since event).

[0147] The systems and methods described herein have a trade-off in time domain prediction, where more weight is given to inputs matched to the most recent values. Conditional weighting allows these models to be tuned to specific variations.

[0148] In some implementations, confidence is calculated for the predicted condition based on the confidence of the inputs, including raw inputs and matched inputs. Uses of confidence in real-time prediction with matching include: (1) the certainty of the medical action determined via the matched prediction, i.e., if the general confidence score is low (e.g., due to low certainty in recent CGM samples or evidence of unauthorized meals and / or boluses), the matched prediction of the corresponding outcome may not be reliable; and 2) determining whether to wait before providing advice based on the matched prediction, i.e., if the general confidence score is low, the patient may be advised to wait a little longer before providing a recommendation.

[0149] FIG. 7 is a block diagram of an implementation of a parameter estimator 270. The parameter estimator 270 is configured to perform parameter optimization. Parameters are tuned only on collated, reliable data. Parameter optimization is applied to obtain the best settings for metabolic model parameters based on a retrospective dataset. Over time, the predictor can be run retrospectively to improve predictions. The model is optimized to give the best predictive model performance. Parameter estimation is optional and depends on the type of estimation used in the previous block and the type of model used for that estimation.

[0150] The parameter estimator 270 is constructed to make the optional personalized physiological model used by the prediction engine as accurate as possible by optimizing the estimated model parameters 275 provided as output. The goal is to estimate patient physiological parameters, general applications such as insulin sensitivity, absorption repro (drug) absorption rate, any physiological, etc.

[0151] In effect, optimization uses retrospective data, runs a predictor on that data, builds a prediction engine, apples to the retrospective data as if it were live, and tries to see how accurately it generates predictions for the retrospective traces, with parameter tuning based on the accuracy of the simulated predictions.

[0152] Parameter estimator 270 receives as input the data from retrospectively compiled input 225R and retrospective data 210, along with patient biometric and demographic information 273, and outputs model parameters 275.

[0153] The parameter estimator 270 comprises a candidate parameter generator 710, a live predictor instance 720 (including a live input compiler and a prediction engine), and an error assessor 730 based on confidence information.

[0154] The candidate parameter generator 710 generates candidate model parameters 715 .

[0155] The live predictor instance 720 uses the candidate model parameters 715, the retrospective data 210 (treating the retrospective data 210 as if it were live data), and the collated estimates of metabolic inputs and disorders from the retrospective data 225R, and provides its output to a confidence-based error assessor 730.

[0156] The credibility information based error assessor 730 receives the output of the live predictor instance 720 and uses this data along with the credibility of the retrospective data 225R and the measurement signals of the retrospective data 210 to generate an output that is provided to the candidate parameter generator 710 for later use in determining the model parameters 275.

[0157] In implementations, each subject's reference glucose concentration and insulin sensitivity are tuned to an optimized value from a list of possible values. Predictors can be run over 30 days of data (e.g., insulin, CGM, meals, etc.) to determine the best predictor for an hour.

[0158] 8 is an operational flow of an implementation of a method 800 for collating data. The method 800 may be performed, for example, by the platform 200. Aspects of the method 800 may be performed by the input compiler 220 in some implementations.

[0159] At 810, unreliable data associated with a subject is received at an input estimator, such as metabolic input estimator 320 of retrospective input compiler 220R or metabolic input estimator 320 of live input compiler 220L. The unreliable data may be included in retrospective data, such as retrospective data 210, or live data, such as live data 212. The unreliable data includes at least one of insulin timing, insulin amount, meal data, or activity data, where the unreliable data is unreliable due to behavioral anomalies or human error in at least one of the timing, amount, estimation, or entry.

[0160] At 820, trusted data related to the subject is received at the input estimator. The trusted data may be included in retrospective data, such as retrospective data 210, or live data, such as live data 212. The trusted data includes at least one of CGM data, insulin pump data, computer-generated data, computer-generated models, or personalized models that describe the subject's glucose and insulin dynamics.

[0161] At 830, the untrusted data is matched using trusted data. An input matcher can perform matching of the untrusted data using trusted data. In particular, (1) an input estimator uses the trusted inputs in conjunction with a mathematical model to estimate values ​​for the untrusted inputs, and then (2) the untrusted input data is fused with the estimated untrusted inputs to generate a final matched untrusted data set. The untrusted inputs and estimated untrusted inputs can be fused in various ways, depending on the application context and time horizon. In some cases, such as when the estimated untrusted inputs are estimated with low error covariance, when the estimated inputs are proven to accurately predict blood glucose over time, or when the untrusted data source is proven to be completely unreliable, the matched untrusted data can be derived exclusively from the estimated inputs, independent of the untrusted data. In other cases, such as when the mathematical model and / or estimated inputs are unable to predict blood glucose over time, or when the untrusted data source can demonstrate accuracy by independent means, the matched untrusted data can be derived exclusively from the untrusted inputs themselves. In live application situations (non-retrospective applications), or when additional data is needed to determine whether the current estimated untrusted input is more trustworthy than the untrusted input itself, the matched untrusted data can be calculated as a mix of the untrusted input and the estimated untrusted input, with (1) for the recent past, the matched result deferring to the untrusted data (because more data is needed to refute it), (2) for the distant past, the matched result deferring to the estimated untrusted input, and (3) in the transition region between the recent and distant past, the match value is calculated as a weighted average of the untrusted input data and the estimated untrusted input data depending on their proximity to the current time.Alternatives to weighted averaging include (1) probabilistically selecting either untrusted or estimated untrusted inputs based on the perceived reliability of the untrusted or estimated untrusted data, and (2) selecting untrusted or estimated untrusted inputs for classification purposes, e.g., maximizing maximum likelihood or maximum a posteriori probability.

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

[0163] 9 is an operational flow of another implementation of a method 900 for collating data. Method 900 may be performed, for example, by platform 200. Aspects of method 900 may be performed by input compiler 220 in some implementations.

[0164] At 910, untrusted data associated with a subject is received at an input estimator, such as metabolic input estimator 320 of retrospective input compiler 220R or metabolic input estimator 320 of live input compiler 220L. The untrusted data may be included within retrospective data, such as retrospective data 210, or live data, such as live data 212. The untrusted data includes user-input data including at least one of insulin data, dietary data, or activity data.

[0165] At 920, the untrusted data is matched using trusted data associated with the subject. The trusted data may be included within retrospective data, such as retrospective data 210, or live data, such as live data 212. The trusted data may include computer-generated data. Matching may be performed using an input matcher. In particular, (1) an input estimator uses the trusted inputs in conjunction with a mathematical model to estimate values ​​for the untrusted inputs, and then (2) the untrusted input data is fused with the estimated untrusted inputs to generate a final matched untrusted data set. The untrusted inputs and estimated untrusted inputs may be fused in various ways, depending on the context and time horizon of the application. In some cases, such as when the estimated untrusted inputs are estimated with low error covariance, when the estimated inputs are proven to accurately predict blood glucose over time, or when the untrusted data source is proven to be completely unreliable, the matched untrusted data may be derived exclusively from the estimated inputs, independent of the untrusted data. In other cases, such as when the mathematical model and / or estimated inputs cannot predict blood glucose over time or when the untrusted data source can demonstrate accuracy by independent means, the matched untrusted data can be derived exclusively from the untrusted input itself. In live application situations (non-retrospective applications), or when additional data is needed to determine whether the current estimated untrusted input is more trustworthy than the untrusted input itself, the matched untrusted data can be calculated as a mix of the untrusted input and the estimated untrusted input, with (1) for the recent past, the matched result deferring to the untrusted data (because more data is needed to refute it), (2) for the distant past, the matched result deferring to the estimated untrusted input, and (3) in the transition region between the recent and distant past, the match value is calculated as a weighted average of the untrusted input data and the estimated untrusted input data depending on their proximity to the current time.Alternatives to weighted averaging include (1) probabilistically selecting either untrusted or estimated untrusted inputs based on the perceived reliability of the untrusted or estimated untrusted data, and (2) selecting untrusted or estimated untrusted inputs for classification purposes, e.g., maximizing maximum likelihood or maximum a posteriori probability.

[0166] 10 is an operational flow of an implementation of a method 1000 for determining the trustworthiness of data. The method 1000 may be performed, for example, by the platform 200. Aspects of the method 1000 may be performed by the input compiler 220 in some implementations.

[0167] At 1010, untrusted data associated with a subject is received at, for example, an input estimator, such as metabolic input estimator 320 of retrospective input compiler 220R or metabolic input estimator 320 of live input compiler 220L. The untrusted data may be included in retrospective data, such as retrospective data 210, or live data, such as live data 212. The untrusted data includes user-input data including at least one of insulin data, dietary data, or activity data.

[0168] At 1020, the trustworthiness of the untrusted data is determined. The trustworthiness may be determined by a trustworthiness assessor, such as the trustworthiness assessor 310 of the retrospective input compiler 220R or the trustworthiness assessor 310 of the live input compiler 220L. The trustworthiness of the untrusted data is assessed solely from the characteristics of the untrusted data over one or more time scales. In particular, failure to acknowledge meals and / or insulin and / or physical activity over a period of time can be interpreted as incomplete data, representing the entire period as untrustworthy, e.g., a trustworthiness value of zero. Similarly, other data artifacts, such as duplicate entries or abnormally high (or low) insulin doses and / or acknowledged amounts of carbohydrates or physical activity over a period of time, can be interpreted as non-physiologically or behaviorally unlikely, again representing the period as untrustworthy. Similarly, temporary inaccuracies in generally trustworthy input, such as temporary unavailability of sensor readings or temporary out-of-range indications from a sensor, can be treated as temporarily untrustworthy input, again rendering the associated period untrustworthy.

[0169] At 1030, the trusted data is received at the trust assessor. The trusted data may be included within retrospective data, such as retrospective data 210, or live data, such as live data 212.

[0170] At 1040, the trustworthiness of the untrusted data is updated using the trusted data. The update may be performed by a trustworthiness assessor. The trustworthiness of the untrusted data may be assessed based on how well it matches the estimated untrusted input data over one or more time scales. Specifically, if the underlying model is proven to predict blood glucose concentrations over time and the untrusted input for a period differs from the estimated untrusted input, the untrusted data may be assigned a low level of trustworthiness for that period, e.g., a level closer to zero than one. Independently, a trustworthiness value may be assigned to the matched untrusted input based on how the match is achieved. For example, if a model is proven to be highly predictive of blood glucose over time and the estimated untrusted input is highly consistent with the trusted data, and the matched untrusted data is calculated to be the same as or very close to the estimated untrusted data, the matched untrusted data may be assigned a high trustworthiness value, e.g., a value closer to one, even if the corresponding untrusted data is not trustworthy.

[0171] 11 is an operational flow of another implementation of a method 1100 for determining the trustworthiness of data. The method 1100 may be performed, for example, by the platform 200. Aspects of the method 1100 may be performed by the input compiler 220 in some implementations.

[0172] At 1110, first untrusted data associated with a subject is received at, for example, an input estimator, such as metabolic input estimator 320 of retrospective input compiler 220R or metabolic input estimator 320 of live input compiler 220L. The first untrusted data may be included within retrospective data, such as retrospective data 210, or live data, such as live data 212. The untrusted data includes user input data including at least one of insulin data, meal data, or activity data.

[0173] At 1120, the trustworthiness of the first untrusted data is determined in a trustworthiness assessor, such as the trustworthiness assessor 310 of the retrospective input compiler 220R or the trustworthiness assessor 310 of the live input compiler 220L. The trustworthiness of the untrusted data is assessed solely from the characteristics of the untrusted data over one or more time scales. In particular, failure to acknowledge meals and / or insulin and / or physical activity over a period of time can be interpreted as incomplete data, representing the entire period as untrustworthy, e.g., a trustworthiness value of zero. Similarly, other data artifacts, such as duplicate entries or abnormally high (or low) insulin doses and / or acknowledged amounts of carbohydrates or physical activity over a period of time, can be interpreted as non-physiologically or behaviorally unlikely, again representing the period as untrustworthy. Similarly, temporary inaccuracies in generally trustworthy input, such as temporary unavailability of sensor readings or temporary out-of-range indications from a sensor, can be treated as temporarily untrustworthy input, again rendering the associated period untrustworthy.

[0174] At 1130, second untrusted data associated with 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 live input compiler 220L. The second untrusted data may be included within retrospective data, such as retrospective data 210, or live data, such as live data 212.

[0175] At 1140, the trustworthiness of the second untrusted data is determined in a trustworthiness assessor, such as the trustworthiness assessor 310 of the retrospective input compiler 220R or the trustworthiness assessor 310 of the live input compiler 220L.

[0176] At 1150, the trustworthiness of the first untrusted data is updated using the second untrusted data and / or the trustworthiness of the second untrusted data, depending on the implementation. The updating can be performed in the trustworthiness assessor 310.

[0177] At 1160, the trusted data is received at the trust assessor 310. The trusted data may be included within retrospective data, such as retrospective data 210, or live data, such as live data 212.

[0178] At 1170, the trustworthiness of the first untrusted data and the second untrusted data are updated using the trusted data. The updating may be performed by a trustworthiness assessor. The trustworthiness of the untrusted data may be assessed based on how well it matches the estimated untrusted input data over one or more time scales. Specifically, if the underlying model is proven to predict blood glucose concentrations over time and the untrusted input for a period differs from the estimated untrusted input, the untrusted data may be assigned a low level of trustworthiness for that period, e.g., a level closer to zero than one. Independently, a trustworthiness value may be assigned to the matched untrusted input based on how the match is achieved. For example, if a model is proven to highly predict blood glucose over time and the estimated untrusted input highly matches the trusted data, and the matched untrusted data is calculated to be the same as or very close to the estimated untrusted data, the matched untrusted data may be assigned a high trustworthiness value, e.g., a value closer to one, even if the corresponding untrusted data is not trustworthy.

[0179] 12 is an operational flow of an implementation of a method 1200 for providing a glycemic-based output using untrusted data. The method 1200 may be performed by the platform 200, for example.

[0180] At 1210, data over a period of time is predicted for the subject, for example, by prediction engine 250. In some implementations, (1) initial conditions (corresponding to past system states), trusted inputs from that point in time in the past, and collated untrusted inputs from that point in time in the past are used as inputs to an underlying mathematical model that generates an estimate of the patient's current metabolic state; and (2) to account for expected future inputs (e.g., assumed insulin administration, physical activity, and / or eating behavior), the mathematical model is used to predict the patient's future metabolic state, including future blood glucose. Further features and details are described herein, for example, with respect to FIG. 6.

[0181] At 1220, untrusted data directed to diabetes management 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 live input compiler 220L. The untrusted data may be included within retrospective data, such as retrospective data 210, or live data, such as live data 212.

[0182] At 1230, multiple predicted data traces are simulated over the period, for example, by the replay compiler 230. A spectrum of possible distributions of untrusted data is used.

[0183] At 1240, the simulated predicted data traces are compared by the replay compiler 230 to the predicted data to identify glycemic activity.

[0184] At 1250, visualizations and / or recommendations based on glycemic activity are generated and output by a replay compiler.

[0185] 13 is an operational flow of an implementation of a method 1300 for using replay prediction. The method 1300 may be performed, for example, by the platform 200. Aspects of the method 1300 may, in some implementations, be performed by the replay compiler 230.

[0186] At 1310, the estimated metabolic state, the matched estimated metabolic inputs, the known metabolic inputs, and the surrogate metabolic inputs are received at the replay compiler 230.

[0187] At 1320, replay prediction is performed in the replay compiler 230 using the estimated metabolic state, the matched estimated metabolic inputs, the known metabolic inputs, and the surrogate metabolic inputs. In some implementations, after identifying which historical inputs are modifiable (either entirely new or dynamically evaluated as a function of the patient's newly predicted metabolic state) and which inputs are invariant exogenous inputs, an underlying mathematical model (represented by dynamic equations) is used to iteratively predict the metabolic state the patient would have experienced with the modified inputs during some (or all) of the period described by the retrospective data. The reliability of the retrospectively predicted estimates of the patient's metabolic state is determined from the reliability of the corresponding unreliable retrospective data. Further features and details are described herein, for example, with reference to FIG. 5.

[0188] At 1330, a replay simulated metabolic state based on the replay prediction is output by the replay compiler 230.

[0189] 14 is an operational flow of an implementation of a method 1400 for using real-time predictions. The method 1400 may be performed, for example, by the platform 200. Aspects of the method 1400 may, in some implementations, be performed by the prediction engine 250.

[0190] At 1410, the surrogate metabolic inputs, the matched estimated metabolic inputs, the known metabolic inputs, and the final estimated metabolic inputs are received, for example, at prediction engine 250.

[0191] At 1420, in the prediction engine 250, real-time prediction is performed using the surrogate metabolic inputs, the matched estimated metabolic inputs, the known metabolic inputs, and the final estimated metabolic inputs.

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

[0193] 15 illustrates an exemplary computing environment in which exemplary embodiments and aspects may be implemented. The computing device environment is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality.

[0194] 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 for use include, but are not limited to, personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, networked personal computers (PCs), minicomputers, mainframe computers, embedded systems, distributed computing environments that include any of the above systems or devices, etc.

[0195] Computer-executable instructions, such as program modules, may be used that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Distributed computing environments may be used where tasks are performed by remote processing devices that are linked through a communications network or other data transmission medium. In a distributed computing environment, program modules and other data may be located in both local and remote computer storage media, including memory storage devices.

[0196] 15, an exemplary system for implementing aspects described herein includes a computing device, 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 computing device, memory 1504 may be volatile (such as random access memory (RAM)), non-volatile (such as read-only memory (ROM), flash memory), or some combination of the two. This most basic configuration is indicated in FIG. 15 by dashed line 1506.

[0197] Computing device 1500 may have additional features / functionality. For example, computing device 1500 may include additional storage (removable and / or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated in FIG. 15 by removable storage 1508 and non-removable storage 1510.

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

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

[0200] Computing device 1500 may contain communications connections 1512 that allow the device to communicate with other devices. 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, speakers, printer, etc. All of these devices are well known in the art and need not be discussed at length here.

[0201] In an implementation, the method includes receiving untrusted data associated with the subject at an input estimator, receiving trusted data associated with the subject at the input estimator, matching the untrusted data with the trusted data using an input matcher, and outputting the matched untrusted data.

[0202] Implementations may include some or all of the following features: The untrusted data includes at least one of insulin timing, insulin amount, meal data, or activity data. The untrusted data is unreliable due to behavioral anomalies or human error in at least one of timing, amount, estimation, or entry. The trusted data includes at least one of CGM data, insulin pump data, computer-generated data, computer-generated models, or personalized models describing the subject's glucose and insulin dynamics. The method further includes predicting the subject's future glucose state based on the collated untrusted data. The untrusted data includes reported carbohydrates, where the reported carbohydrates are unreliable or unavailable. The untrusted data includes a stream of data input. The method further includes receiving additional untrusted data and collating the additional untrusted data with the trusted data. The method further includes receiving additional trusted data and collating the untrusted data with the additional trusted data. The method further includes tuning the AP using the collated untrusted data. The method further includes updating the subject's behavioral model using the collated 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 a local variance of the untrusted data using modeling and comparing the local variance to an overall variance using the untrusted data to determine a comparison amount, where if the comparison amount exceeds a threshold, the untrusted data is determined to be unreliable or unknown. Determining that the untrusted data is unreliable or unknown includes determining a difference between the untrusted data and a model of the trusted data.

[0203] Implementations may also include some or all of the following features: The method further includes determining a credibility score of the untrusted data relative to the trusted data. The method further includes generating an alert associated with the subject based on the matched untrusted data. The method further includes determining a behavioral pattern of the subject using the matched untrusted data. The method further includes generating a smart alert associated with the subject based on the behavioral pattern. 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 a user entry. The method further includes comparing the untrusted data with the trusted data to identify a behavioral root cause of the glycemic dysfunction.

[0204] Implementations may also include some or all of the following features: The method further includes identifying behavioral root causes of the glycemic dysfunction using the matched unreliable data. The matching includes receiving the unreliable data at an input matcher, where the unreliable data includes an unreliable metabolic input; receiving the reliable data at the input matcher, where the reliable data includes an estimated unreliable metabolic input; and combining the unreliable data and the reliable data using a weighting function to generate the matched unreliable metabolic input. The unreliable data and the reliable data received at the input matcher are in the form of a vector, and the matched unreliable metabolic input is in the form of a vector. The weighting function is based on time association. The weighting function is based on relative certainty of the unreliable data and the reliable data. The unreliable data includes a reported unreliable metabolic input, and combining includes matching a difference between the reported unreliable metabolic input and the estimated unreliable metabolic input. The matching includes matching the reported unreliable metabolic input and the estimated unreliable metabolic input with a behavioral model. The matching includes matching the difference between the amount and timing of the unreliable metabolic input and the estimated unreliable metabolic input with the measured data.

[0205] In an implementation, the method includes receiving, at an input estimator, untrusted data associated with the subject, where the untrusted data includes user-input data including at least one of insulin data, dietary data, or activity data, and matching, using an input verifier, the untrusted data with trusted data associated with the subject, where the trusted data includes computer-generated data.

[0206] Implementations may include some or all of the following features: The untrusted data includes at least one of insulin timing, insulin amount, meal data, or activity data. The untrusted data is unreliable due to behavioral anomalies or human error in at least one of timing, amount, estimation, or entry. The trusted data includes at least one of CGM data, insulin pump data, a computer-generated model, or a personalized model describing the subject's glucose and insulin dynamics. The method further includes predicting the subject's future glucose state based on the collated untrusted data. The untrusted data includes reported carbohydrates, where the reported carbohydrates are unreliable or unavailable. The untrusted data includes a stream of data input. The method further includes receiving additional untrusted data and collating the additional untrusted data with the trusted data. The method further includes receiving additional trusted data and collating the untrusted data with the additional trusted data. The method further includes tuning the AP using the collated untrusted data. The method further includes updating the subject's behavioral model using the collated 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 a local variance of the untrusted data using modeling and comparing the local variance to an overall variance using the untrusted data to determine a comparison amount, where if the comparison amount exceeds a threshold, the untrusted data is determined to be unreliable or unknown. Determining that the untrusted data is unreliable or unknown includes determining a difference between the untrusted data and a model of the trustworthy data. The method further includes determining a trust score of the untrusted data relative to the trustworthy data. The method further includes generating an alert associated with the subject based on the matched untrusted data.The method further includes determining a behavioral pattern of the subject using the collated untrusted data. The method further includes generating a smart alert associated with the subject based on the behavioral pattern.

[0207] Implementations may also 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, the diabetes management data being received from a connected device or a user entry; the method further includes comparing the untrusted data to the trusted data to identify a behavioral root cause of the glycemic dysfunction; the method further includes identifying a behavioral root cause of the glycemic dysfunction using the matched untrusted data; the matching includes receiving the untrusted data at an input matcher, the untrusted data including an untrusted metabolic input; receiving the trusted data at the input matcher, the trusted data including an estimated untrusted metabolic input; and combining the untrusted data and the trusted data using a weight function to generate a matched untrusted metabolic input; the untrusted data and the trusted data received at the input matcher are in the form of a vector, and the matched untrusted metabolic input is in the form of a vector; the weight function is based on time relevance. The weighting function is based on the relative certainty of the unreliable data and the reliable data. The unreliable data includes a reported unreliable metabolic input, and combining includes matching a difference between the reported unreliable metabolic input and the estimated unreliable metabolic input. Matching includes matching the reported unreliable metabolic input and the estimated unreliable metabolic input with a behavioral model. Matching includes matching a difference between the amount and timing of the unreliable metabolic input and the estimated unreliable metabolic input with the measured data. The method further includes performing a replay prediction using the matched unreliable data and the reliable data. The method further includes outputting a simulated metabolic state based on the replay prediction. The method further includes performing a real-time prediction using the matched unreliable data and the reliable data.The method further includes outputting a simulated metabolic state based on the real-time prediction.

[0208] In an implementation, a method includes predicting data for a subject over a period of time, receiving untrusted data directed to diabetes management, simulating multiple predicted data traces for the period of time using a spectrum of possible variances of the untrusted data, comparing the simulated predicted data traces with the predicted data to identify a glycemic effect, and outputting a visualization or recommendation based on the glycemic effect.

[0209] Implementations may include some or all of the following features: the untrusted data includes glucose data and the predicted data trace includes a predicted glucose trace; predicting the glucose data is based on the trusted CGM data and a personalized model of the subject's glucose-insulin dynamics; predicting the glucose data includes providing a best estimate glucose trace representing the glucose status over time; the untrusted data directed to diabetes management includes at least one of insulin timing, insulin amount, meal data, or activity data; the glycemic effect is related to a difference in at least one of the amount of diabetes management data or the timing of diabetes management data.

[0210] In an implementation, the system includes a processor and a metabolic model, where the processor is configured to receive untrusted user input and match the untrusted user input with trusted input using the metabolic model.

[0211] Implementations may include some or all of the following features: The processor is further configured to optimize the predictive capabilities of the metabolic model to predict future glucose levels. The processor is further configured to enable replay of events and treatment outcomes with alternative treatment protocols. The processor is further configured to provide a real-time prediction 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 directed to at least one replay application. The at least one replay application includes assessment of blood glucose (BG) treatment outcome metrics in the analysis, identification of credible instances of scenarios in the replay analysis, evaluation of data quality, a credibility profile, and credibility of the data as a function of time. The processor is further configured to perform collated projections directed to at least one real-time application. The at least one real-time application includes determining certainty of medical action and the need to wait before providing advice.

[0212] Implementations may also include some or all of the following features: the untrusted user input includes estimated carbohydrates; the untrusted user input includes a time series of uncertain metabolic input; the trusted input includes CGM and insulin pump readings; and the trusted input includes a time series of trusted metabolic input. The processor is further configured to output the estimated metabolic state in the form of a time series, a final collated estimated metabolic state in the form of a time series, and the credibility of the final estimated metabolic state in the form of a time series and the collated estimated input. The processor is included in an integrated state / input estimator, and the metabolic model is a plug-in.

[0213] In an implementation, the method includes receiving, at an input estimator, untrusted data related to a subject, where the untrusted data includes user input data including at least one of insulin data, dietary data, or activity data; determining, at a trustworthiness assessor, the trustworthiness of the untrusted data; receiving, at the trustworthiness assessor, trusted data; and updating, at the trustworthiness assessor, the trustworthiness of the untrusted data using the trusted data.

[0214] Implementations may include some or all of the following features: determining the trustworthiness of the untrusted data includes determining a first trustworthiness based on at least one of a lack of integrity of the untrusted data or a lack of continuity of the untrusted data, determining a second trustworthiness based on expected behavior indicative of at least one of a lack of integrity of the untrusted data or a lack of continuity of the untrusted data, determining a third trustworthiness based on an estimated input artifact indicative of a systemic unknown factor, and aggregating the first trustworthiness, the second trustworthiness, and the third trustworthiness; determining the first trustworthiness includes using the measurement signal as an input, determining the second trustworthiness includes using the untrusted data and the trusted data as input, and determining the third trustworthiness includes using the untrusted data, the estimated untrusted data, and the matched data as input.

[0215] In an implementation, the method includes receiving, at an input estimator, first untrusted data related to a subject, where the first untrusted data includes user input data including at least one of insulin data, meal data, or activity data; determining, at a trust assessor, the trustworthiness of the first untrusted data; receiving, at the input estimator, second trusted data related to the subject; determining, at the trust assessor, the trustworthiness of the second untrusted data; updating, at the trust assessor, the trustworthiness of the first untrusted data using the second untrusted data or the trustworthiness of the second untrusted data; receiving, at the trust assessor, trusted data; and updating, at the trust assessor, the trustworthiness of the first untrusted data and the second untrusted data using the trusted data.

[0216] Implementations may include some or all of the following features: determining a first trustworthiness of the untrusted data includes determining the first trustworthiness based on at least one of a lack of integrity of the untrusted data or a lack of continuity of the untrusted data; determining a second trustworthiness based on expected behavior indicative of at least one of a lack of integrity of the untrusted data or a lack of continuity of the untrusted data; determining a third trustworthiness based on an estimated input artifact indicative of a systemic unknown factor; and aggregating the first trustworthiness, the second trustworthiness, and the third trustworthiness; determining the first trustworthiness includes using a measurement signal as an input, determining the second trustworthiness includes using the untrusted data and the trusted data as input, and determining the third trustworthiness includes using the untrusted data, the estimated untrusted data, and the matched data as input.

[0217] In an implementation, the method includes receiving an estimated metabolic state, a collated estimated untrusted metabolic input, a trustworthy metabolic input, and an alternative metabolic input; performing a replay prediction using the estimated metabolic state, the collated estimated untrustworthy metabolic input, the trustworthy metabolic input, and the alternative metabolic input; and outputting a replay simulated metabolic state based on the replay prediction.

[0218] Implementations may include some or all of the following features: the estimated metabolic state, the collated estimated untrusted metabolic inputs, and the trusted metabolic inputs each comprise a time series, and performing the replay prediction includes estimating metabolic states over periods of the time series for the estimated metabolic state, the collated estimated untrusted metabolic inputs, and the trusted metabolic inputs to generate a replay simulated metabolic state.

[0219] In an implementation, the method includes receiving an alternative metabolic input, a collated estimated unreliable metabolic input, a reliable metabolic input, and a final estimated metabolic input; performing a real-time prediction using the alternative metabolic input, the collated estimated unreliable metabolic input, the reliable metabolic input, and the final estimated metabolic input; and outputting a predicted metabolic state based on the real-time prediction.

[0220] Implementations may include some or all of the following features: performing real-time prediction includes extrapolating a time series for the collated estimated untrusted and trusted metabolic inputs, and estimating a future metabolic state using the extrapolated time series, the alternative metabolic inputs, and the final estimated metabolic state; the method further includes filtering the extrapolated time series to prevent jitter in the predicted metabolic state; the estimated metabolic state is in the form of a time series; the method further includes filtering the estimated metabolic state to generate the predicted metabolic state; estimating the metabolic state uses a behavioral model of the subject; and extrapolating the time series uses historical data weighting based on at least one of time of day, features of the current estimated state, or a database of past metabolic inputs.

[0221] It should be understood that the various techniques described herein may be implemented in connection with hardware or software components, or, where appropriate, with a combination of both. Exemplary types of hardware components that may be used include field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems-on-chips (SOCs), complex programmable logic devices (CPLDs), etc. The methods and apparatus of the presently 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, a CD-ROM, a hard drive, or any other machine-readable storage medium such as a computer, where the program code is loaded into and executed by a machine, such as a computer, causing the machine to become an apparatus for practicing the presently disclosed subject matter.

[0222] While example implementations may refer to utilizing aspects of the presently disclosed subject matter in the context of one or more stand-alone computer systems, the subject matter is not so limited and, rather, may be implemented in connection with any computing environment, such as, for example, a network or distributed computing environment. Furthermore, aspects of the presently disclosed subject matter may be implemented within or across multiple processing chips or devices, and storage may similarly be implemented across multiple devices. Such devices may include, for example, personal computers, network servers, and handheld devices.

[0223] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims. [Explanation of symbols]

[0224] 100 Environment 110 Insulin Device 120 Glucose Monitor 130 processors 140 subjects 150 Activity Monitor 160 smartphones

Claims

1. 1. A computer-implemented method comprising: receiving untrusted data associated with a subject, the untrusted data including user-entered data including at least one of insulin data, meal data, or activity data; receiving trusted data related to the subject, the trusted data including at least one of CGM (continuous glucose monitoring) data, insulin pump data, data obtained from a computer-generated model, or a personalized model describing the subject's glucose and insulin dynamics; verifying the untrusted data using the trusted data; receiving the untrusted data, the untrusted data including a reported untrusted metabolic input; receiving the trusted data, the trusted data including estimated untrusted metabolic inputs; combining the unreliable data and the reliable data using a weighting function to generate a reconciled unreliable metabolic input, the weighting function comprising reconciling differences between the reported unreliable metabolic input and the estimated unreliable metabolic input, the weighting function being based on time association such that more recent reported unreliable metabolic inputs are given greater weight; and outputting the verified untrusted metabolic input; predicting a future glucose status of the subject using a mathematical model based on the collated unreliable metabolic inputs; Including, The method, wherein predicting the subject's future glucose status using a mathematical model based on the reconciled untrusted metabolic input comprises reconciling the untrusted metabolic input with the trusted metabolic input by taking the untrusted metabolic input and combining the untrusted data and the trusted data using a weighting function to generate the reconciled untrusted metabolic input.

2. 2. The method of claim 1, wherein the unreliable data includes at least one of diabetes management data that is insulin timing, insulin amount, unreliable or unavailable reported carbohydrates, or estimated diabetes management data, and the unreliable data is unreliable due to behavioral anomalies or human error in at least one of timing, amount, estimation, or entry.

3. The method of claim 2 , wherein the trusted data includes diabetes management data corresponding to the estimated diabetes management data, and the diabetes management data is received from a connected device or a user entry.

4. 10. The method of claim 1, further comprising predicting a future glucose state of the subject using a mathematical model based on the collated untrusted data.

5. 10. The method of claim 1, further comprising receiving at least one of additional untrusted data or additional trusted data, verifying the additional untrusted data using the trusted data, and verifying the untrusted data using the additional trusted data.

6. The method of claim 1 , further comprising: updating a behavioral model of the subject using the collated untrusted data.

7. determining that the untrusted data is untrusted or unknown; determining that the untrusted data is untrustworthy or unknown; (1) using modeling to calculate the local variance of the untrusted data and comparing the local variance to the overall variance using the untrusted data to determine a comparison amount, where if the comparison amount exceeds a threshold, the untrusted data is determined to be unreliable or unknown; or (2) determining differences between the untrusted data and a model of the trusted data; The method of claim 1 , comprising at least one of:

8. The method of claim 1 , further comprising determining a trust score for the untrusted data relative to trustworthy data.

9. The method of claim 1 , further comprising generating an alert related to the subject based on the collated untrusted data.

10. The method of claim 1 , further comprising using the collated untrusted data to determine behavioral patterns of the subject.

11. The method of claim 1 , wherein the received untrusted data and the trusted data are in the form of vectors, and the matched untrusted metabolic input is in the form of a vector.

12. The method of claim 1 , wherein the weighting function is based on at least one of time relevance or relative certainty of the untrusted and trusted data.

13. 2. The method of claim 1, wherein the unreliable data includes reported unreliable metabolic inputs, and the combining includes matching differences between the reported unreliable metabolic inputs and the estimated unreliable metabolic inputs.

14. 14. The method of claim 13, wherein the matching comprises at least one of: (1) matching the reported unreliable metabolic inputs and the estimated unreliable metabolic inputs with a behavioral model; or (2) matching differences between the amount and timing of the unreliable metabolic inputs and the estimated unreliable metabolic inputs with measured data.

15. 1. A computer-implemented method comprising: receiving untrusted data associated with a subject, the untrusted data comprising user-entered data including at least one of insulin data, dietary data, or activity data; matching the untrusted data with trusted data related to the subject, the trusted data comprising computer-generated data; receiving the untrusted data, the untrusted data including a reported untrusted metabolic input; receiving the trusted data, the trusted data including estimated untrusted metabolic inputs; combining the unreliable data and the reliable data using a weighting function to generate a reconciled unreliable metabolic input, the weighting function comprising reconciling differences between the reported unreliable metabolic input and the estimated unreliable metabolic input, the weighting function being based on time association such that more recent reported unreliable metabolic inputs are given greater weight; and outputting the verified untrusted metabolic input; predicting a future glucose status of the subject using a mathematical model based on the collated unreliable metabolic inputs; Including, The method, wherein predicting the subject's future glucose status using a mathematical model based on the reconciled untrusted metabolic input comprises reconciling the untrusted metabolic input with the trusted metabolic input by taking the untrusted metabolic input and combining the untrusted data and the trusted data using a weighting function to generate the reconciled untrusted metabolic input.

16. 16. The method of claim 15, wherein the unreliable data includes at least one of insulin timing, insulin amount, diabetes management data that is estimated diabetes management data, or reported carbohydrates that are unreliable or unavailable, wherein the unreliable data is unreliable due to behavioral anomalies or human error in at least one of timing, amount, estimation, or entry, and the reliable data includes diabetes management data that corresponds to the estimated diabetes management data, and wherein the diabetes management data is received from a connected device or user entry.

17. 16. The method of claim 15, further comprising predicting a future glucose state of the subject using a mathematical model based on the collated untrusted data.

18. 16. The method of claim 15, further comprising at least one of receiving additional untrusted data and verifying the additional untrusted data with the trusted data, or receiving additional trusted data and verifying the untrusted data with the additional trusted data.

19. The method of claim 15 , further comprising updating a behavioral model of the subject using the verified untrusted data.

20. further comprising determining that the untrusted data is untrustworthy or unknown, wherein determining that the untrustworthy data is untrustworthy or unknown comprises: (1) using modeling to calculate the local variance of the untrusted data and comparing the local variance to the overall variance using the untrusted data to determine a comparison amount, where if the comparison amount exceeds a threshold, the untrusted data is determined to be unreliable or unknown; or (2) determining differences between the untrusted data and a model of the trusted data; 16. The method of claim 15, comprising at least one of:

21. The method of claim 15 , further comprising determining a trust score for the untrusted data relative to trustworthy data.

22. 16. The method of claim 15, further comprising at least one of: generating an alert related to the subject based on the collated untrusted data; and determining a behavioral pattern of the subject using the collated untrusted data.

23. 16. The method of claim 15, wherein the received unreliable data and the reliable data are in the form of vectors, the matched unreliable metabolic inputs are in the form of vectors, and the weighting function is based on at least one of time association or relative certainty of the unreliable data and the reliable data.

24. 24. The method of claim 23, wherein the unreliable data includes reported unreliable metabolic inputs, and the combining includes matching differences between the reported unreliable metabolic inputs and the estimated unreliable metabolic inputs.

25. The said comparing (1) matching the reported unreliable metabolic inputs and the estimated unreliable metabolic inputs with a behavioral model; or (2) matching the difference between the amount and timing of the unreliable metabolic input and the estimated unreliable metabolic input with measured data; 25. The method of claim 24, comprising at least one of:

Images