Machine learning based system for estimating glucose values

Abstract

A method for estimating a glucose value of a user and an insulin infusion and management system are provided. An insulin infusion and management system may include an insulin infusion device configured to deliver insulin to a user; a glucometer; a source of user activity data; and a processor-based computing device that supports data communication with the insulin infusion device. A processor device of a computing device may execute a method for estimating a glucose value of a user.

Description

[0001] This application is a divisional application of the invention patent application entitled “Machine Learning-Based System for Estimating Glucose Values”, filed on August 6, 2020, with international application number PCT / US2020 / 045293 and national application number 202080055157.8. Technical Field

[0002] The present technology relates generally to insulin delivery systems, and more particularly to machine learning-based systems for estimating glucose values ​​based on, for example, blood glucose measurements and contextual activity data. Background Art

[0003] Portable medical devices are useful for patients who must continuously or frequently monitor their medical conditions. For example, patients with diabetes often need to modify and monitor their daily lifestyle to keep their blood glucose (BG) balanced. Individuals with type 1 diabetes and some individuals with type 2 diabetes use insulin (and other glucose-lowering medications) to control their BG levels. In order to maintain glucose levels within the recommended range, patients with diabetes are advised to routinely maintain a strict schedule that includes timely intake of nutritious meals, exercise, daily monitoring of BG levels, and adjusting and administering insulin dosages accordingly.

[0004] Infusion pump devices and insulin pump systems are relatively well known in the medical field. Infusion pump devices and insulin systems are intended to provide accurate and measured doses of insulin through an infusion set. An infusion set delivers insulin to a patient through a small diameter tube that terminates in a cannula, for example, that is inserted under the patient's skin. The use of infusion pump therapy has been increasing, particularly for delivering insulin to diabetic patients.

[0005] In one type of system, an infusion pump can be programmed to inject insulin on a set schedule. For example, a physician or other healthcare administrator can program an insulin pump according to a set schedule so that it delivers insulin to a patient's blood throughout the day according to that schedule. Alternatively, the patient can simply activate the insulin pump to administer a bolus of insulin as needed, such as in response to a patient's high BG level. One disadvantage of this approach is that the user lacks knowledge of their blood glucose level at any given point, and it is difficult for the patient to determine when insulin may need to be administered outside of a scheduled administration.

[0006] To address this issue, patients may monitor BG levels using a BG meter or measuring device. For example, a patient may use a blood glucose meter to intermittently measure their instantaneous blood glucose level at any given time through a "finger prick test." The information from this measurement may be processed and used to determine if insulin should be administered to regulate the patient's blood glucose level. One problem with this approach is that the user makes the monitoring of blood glucose levels and the administration of insulin ad hoc based on when they think insulin should be administered. This can be problematic in certain situations, such as with patients who are unaware of hypoglycemia, which can occur in situations where the patient is unable to perceive symptoms that may indicate that their blood glucose is low.

[0007] To address this issue, continuous glucose monitoring (CGM) systems are available to help diabetic patients monitor their blood glucose levels on an ongoing basis. Continuous glucose monitoring systems employ continuous glucose sensors to monitor a patient's blood glucose levels in a substantially continuous and autonomous manner. In many cases, continuous glucose monitoring sensors are used in conjunction with an insulin infusion device or insulin pump as part of a digital diabetes management system. A digital diabetes management system can determine the amount of glucose in a patient's blood at any given time so that the appropriate amount of insulin can be automatically administered to help regulate the amount of glucose in the patient's blood. In this way, insulin can be automatically administered based on the patient's specific needs so that their blood glucose levels are not too high or too low at any particular time. In this way, a balance or equilibrium can be achieved between how much glucose enters the body (e.g., the amount of glucose introduced into the patient's bloodstream through a meal) and how much glucose the patient consumes or utilizes.

[0008] While existing continuous glucose monitoring systems that employ continuous glucose sensors work well, such continuous glucose monitoring systems are often too expensive for potential users to afford. In some cases, a patient's insurance does not cover such treatments, or the patient's insurance may deny payment for the patient's use of such solutions if the patient does not fall into a high enough risk category to be covered by such treatments. Additionally, some patients may simply choose not to use a continuous glucose monitoring system for lifestyle reasons. For example, a particular user may choose not to wear a continuous glucose monitor or sensor device because it may be uncomfortable, or they choose not to wear it all the time for other reasons. This may prevent a large number of users from using digital diabetes management solutions.

[0009] Today, a large portion of the diabetes market does not use a CGM-type therapeutic device. A large portion of these users include, for example, users who rely on discrete blood glucose measurements to monitor blood glucose several times a day (e.g., users using a glucometer), or users who wear CGM intermittently under the supervision of a healthcare provider (HCP). Without regular use of a CGM device, these approaches can make it difficult for users to manage blood glucose without actively making meaningful behavioral adjustments to improve their personal management.

[0010] Therefore, it is desirable to provide a digital diabetes management solution that is less expensive and can therefore be an option for users who cannot afford more expensive continuous glucose monitoring systems. It is desirable to provide users with an alternative solution that can achieve the same or similar benefits as a full CGM type treatment solution without requiring the user to wear a CGM device regularly and without requiring the user to incur the costs associated with wearing a CGM device regularly. In addition, other desired features and characteristics will become apparent from the subsequent detailed description and the appended claims in conjunction with the accompanying drawings and the foregoing technical field and background. Summary of the invention

[0011] A method for estimating a user's glucose value and an insulin infusion and management system are provided. The insulin infusion and management system may include an insulin infusion device configured to deliver insulin to a user; a blood glucose meter; a source of user activity data; and a processor-based computing device that supports data communication with the insulin infusion device. The computing device may include a processor device and a non-transitory processor-readable medium operably associated with the processor device. The processor-readable medium includes executable instructions that can be configured to cause the processor device to perform a method for estimating a user's glucose value. In one embodiment, the processor device is implemented at a backend server system, and the estimation model is executed as part of a network application at the backend server system. The backend server system is configured to transmit the result of processing the estimated glucose value to one or more of a client device and an insulin infusion device. In another embodiment, the processor device is implemented at a client device, and the estimation model is executed as part of a mobile application at the client device. In another embodiment, the processor device is implemented at an insulin infusion device. According to the method, a first set of inputs can be received and processed by the estimation model for the user to generate a set of estimated glucose values ​​that track actual glucose values. The first set of inputs may include relevant activity data collected by a source of user activity data. For example, in one embodiment, the activity-related data may include metabolic data about the user and / or physical activity data about the user.

[0012] In one embodiment, the estimation model is an integrated model including one or more machine learning algorithms; and a physiological model. The machine learning algorithm may include one or more of the following: one or more artificial neural networks; one or more regression models; one or more decision tree models; one or more support vector machines; one or more Bayesian networks; one or more probabilistic machine learning models; one or more Gaussian processing models; one or more hidden Markov models; and one or more deep learning networks.

[0013] According to other embodiments, in addition to the first set of inputs, the estimation model may also receive and process other information to generate the set of estimated glucose values. For example, according to another embodiment, the estimation model may also receive and process a second set of inputs, which includes intermittent glucose measurements provided from a blood glucose meter to generate the set of estimated glucose values. In this embodiment, a processor device that executes the estimation model for a user processes the first set of inputs and the second set of user inputs to generate the set of estimated glucose values ​​without using information from a continuous glucose sensor device. According to another embodiment, the estimation model may also receive and process a third set of inputs including nutritional information input by a user and a fourth set of inputs including insulin delivered by an insulin infusion device of the user to generate the set of estimated glucose values. In this embodiment, a processor device that executes the estimation model for a user processes the first set of inputs, the second set of inputs, the third set of inputs, and the fourth set of inputs to generate the set of estimated glucose values.

[0014] In one embodiment, the processing system may periodically determine whether the estimated glucose value is within an acceptable range of accuracy. When the estimated glucose value is not within the acceptable range of accuracy, the processing system may cause a first notification perceptible to a user to be generated. When the estimated glucose value is within the acceptable range of accuracy, the processing system may use the estimated glucose value for diabetes management, including controlling insulin delivery by an insulin infusion device based on the estimated glucose value.

[0015] This summary of the invention is provided to introduce in a simplified form a series of concepts further described in the detailed description below. This summary of the invention is not intended to identify the key features or essential features of the claimed subject matter, and is not intended to be used to assist in determining the scope of the claimed subject matter. The details of one or more aspects of the present disclosure are set forth in the following drawings and descriptions. Other features, objects, and advantages of the technology described in this disclosure will be apparent from the description and drawings, as well as the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 is an exemplary embodiment of an infusion system;

[0017] Figure 2 Is applicable to Figure 1 A plan view of an exemplary embodiment of a fluid infusion device in an infusion system of FIG.

[0018] Figure 3 yes Figure 2 An exploded perspective view of a fluid infusion device;

[0019] Figure 4 When assembled with the reservoir inserted into the infusion set, Figure 3 Line 4-4 in the view Figure 2-3 A cross-sectional view of a fluid infusion device;

[0020] Figure 5 is a block diagram of an exemplary infusion system suitable for use with a fluid infusion device in one or more embodiments;

[0021] Figure 6 In one or more embodiments, it is suitable for Figure 5 A block diagram of an exemplary pump control system for use with an infusion device in an infusion system of;

[0022] Figure 7 In one or more exemplary embodiments, Figure 5-6 A block diagram of a closed-loop control system implemented or otherwise supported by a pump control system in a fluid infusion device;

[0023] Figure 8 is a block diagram of an exemplary patient monitoring system;

[0024] Fig. 9 is suitable for Figure 1 A simplified block diagram representation of an exemplary embodiment of a computer-based or processor-based device deployed in the system shown;

[0025] Fig.10 is a block diagram of a system for estimating glucose values ​​for a particular user or patient according to the disclosed embodiments;

[0026] Fig.11 is a flow chart illustrating a method for generating an estimation model for a particular patient according to the disclosed embodiments;

[0027] Fig.12 is a flow chart of a method according to the disclosed embodiment;

[0028] Fig.13 is a block diagram of a workflow for generating a personalized model optimized for estimating glucose values ​​for a specific user or patient according to the disclosed embodiments;

[0029] Fig.14is a block diagram of a machine learning system for generating an optimized population model to estimate glucose values ​​for a population of users or patients according to a disclosed embodiment;

[0030] Fig.15 is a block diagram of a windowed machine learning system for generating an optimized windowed population model to estimate glucose values ​​for a population of users or patients in accordance with the disclosed embodiments;

[0031] Fig.16 is a block diagram of another windowed machine learning system for generating an optimized windowed population model to estimate glucose values ​​for a population of users or patients in accordance with the disclosed embodiments;

[0032] Fig.17 is a block diagram of another windowed machine learning system for generating an optimized windowed population model to estimate glucose values ​​for a population of users or patients in accordance with the disclosed embodiments;

[0033] Fig.18 is a block diagram of another windowed machine learning system for generating an optimized windowed population model to estimate glucose values ​​for a population of users or patients in accordance with the disclosed embodiments;

[0034] Fig.19 is a block diagram of another windowed machine learning system for generating an optimized windowed population model to estimate glucose values ​​for a population of users or patients in accordance with the disclosed embodiments;

[0035] Fig. 20 is a block diagram of a model interpretability analysis processor for selecting an optimized population model for estimating glucose values ​​for a population of users or patients according to the disclosed embodiments;

[0036] Fig.21 is a block diagram of a calibration optimization processor for selecting an optimized calibration model according to the disclosed embodiments;

[0037] Fig. 22 is a block diagram of a calibration optimization processor for selecting optimal input types to be used for developing an optimized calibration model according to the disclosed embodiments;

[0038] Fig.23 is a block diagram of a machine learning system for generating an optimized personal model for estimating glucose values ​​personalized for a particular user or patient in accordance with the disclosed embodiments;

[0039] Fig.24 is a block diagram of a windowed machine learning system for generating an optimized personal model for estimating glucose values ​​personalized for a particular user or patient in accordance with the disclosed embodiments;

[0040] Fig.25 is a block diagram of another windowed machine learning system for generating an optimized personal model for estimating a glucose value personalized for a particular user or patient in accordance with the disclosed embodiments;

[0041] Fig.26 is a block diagram of another windowed machine learning system for generating an optimized personal model for estimating a glucose value personalized for a particular user or patient in accordance with the disclosed embodiments;

[0042] Fig. 27 is a block diagram of another windowed machine learning system for generating an optimized personal model for estimating a glucose value personalized for a particular user or patient in accordance with the disclosed embodiments;

[0043] Fig.28 is a block diagram illustrating an intermittent CGM system according to the disclosed embodiments; and

[0044] Fig.29 is a block diagram illustrating another intermittent CGM system according to the disclosed embodiments. DETAILED DESCRIPTION

[0045] The following specific embodiments are merely illustrative in nature and are not intended to limit the application and use of the embodiments of the subject matter or the present application or such embodiments. As used herein, the word "exemplary" means "used as an example, instance or illustration". Any embodiment described as exemplary herein is not necessarily to be construed as being superior to or superior to other embodiments. In addition, it is not intended to be bound by any explicit or implicit theory present in the aforementioned technical field, background technology, summary of the invention or the following specific embodiments.

[0046] It should be understood that the various aspects disclosed herein may be combined in combinations different from those specifically presented in the description and drawings. It should also be understood that, depending on the example, certain actions or events in any of the processes or methods described herein may be performed in a different order, may be added, combined, or omitted entirely (e.g., all described actions or events may not be necessary to perform the techniques). In addition, although certain aspects of the present disclosure are described as being performed by a single module or unit for purposes of clarity, it should be understood that the techniques of the present disclosure may be performed by a combination of units or modules associated with, for example, a medical device.

[0047] In one or more examples, the described techniques can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the function can be stored in the form of one or more instructions or codes on a computer-readable medium and can be executed by a hardware-based processing unit. A computer-readable medium may include a non-transitory computer-readable medium, which corresponds to a tangible medium, such as a data storage medium (e.g., RAM, ROM, EEPROM, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and can be accessed by a computer).

[0048] Instructions may be configured to be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuit systems. Thus, the term "processor" as used herein may refer to any of the foregoing structures or any other physical structure suitable for implementation of the described techniques. Moreover, the techniques may be fully implemented in one or more circuits or logic elements.

[0049] Exemplary embodiments of the subject matter described herein are implemented in conjunction with a medical device (e.g., a portable electronic medical device). Although many different applications are possible, the following description focuses on embodiments in which an insulin infusion device (or insulin pump) is incorporated as part of an infusion system deployment. For the sake of brevity, conventional techniques related to infusion system operation, insulin pump and / or infuser operation, and other functional aspects of the system (and the individual operating components of the system) may not be described in detail herein. Examples of infusion pumps may be of, but are not limited to, the types described in the following U.S. Patents: 4,562,751; 4,685,903; 5,080,653; 5,505,709; 5,097,122; 6,485,465; 6,554,798; 6,558,320; 6,558,351; 6,641,533; 6,659,980; 6,752,787; 6,817,990; 6,932,584; and 7,621,893; each of which is incorporated herein by reference.

[0050] In general, the fluid infusion device includes a motor or other actuation arrangement, which is operable to displace the plunger (or stopper) of the fluid reservoir provided in the fluid infusion device to deliver a dose of fluid, such as insulin, to the user's body. The dosage command for controlling the operation of the motor can be automatically generated according to the delivery control scheme associated with the specific operating mode, and the dosage command can be generated in a manner affected by the current (or recent) measurement of the physiological condition of the user's body. For example, in a closed-loop or automatic operating mode, the dosage command can be generated based on the difference between the current (or recent) measurement of the interstitial fluid glucose level in the user's body and the target (or reference) glucose set point value. In this regard, the infusion rate can vary with the difference between the current measurement value and the target measurement value. For the purpose of explanation, the subject matter is described herein in the context of insulin for regulating the glucose level of the user (or patient); however, it should be understood that many other fluids can be administered by infusion, and the subject matter described herein is not necessarily limited to use with insulin.

[0051] In one non-limiting embodiment, a method and system for estimating glucose values ​​based on data from, for example, a BG meter and an activity tracker is provided. In other embodiments, other relevant information, such as food (including carbohydrate and macronutrient intake) can also be used to estimate glucose values ​​(e.g., to reconstruct continuous glucose data). An estimation / prediction model based on machine learning can be developed offline for each patient, or updated online for continuous learning, especially during the retention period when a continuous glucose monitor (CGM) acquires current relevant data. A general estimation / prediction model can be constructed using patterns / instances in data collected from groups similar to the patient, which provides a larger data pool and thus a larger range of patient characterizations. Because each person is different, the estimation / prediction model is uniquely trained for each patient.

[0052] For example, a customized machine learning-based estimation / prediction model can be built for each patient using CGM data during the training process. Then, in addition to other relevant information such as steps, heart rate, exercise, metabolic equivalents, and other parameters collected from activity trackers and insulin and dietary information from insulin pumps (or insulin pens) or user entries, the customized machine learning-based estimation / prediction model can be called at runtime based on the fingertip measurements entered by the user through a blood glucose meter, while also taking into account their medical history and demographic information, so that the prediction is not only personalized based on the individual's diabetes situation and behavior, but also has the ability to explain deviations from the patient's regular program. Therefore, the customized machine learning-based estimation / prediction model can use the fingertip measurements entered by the user through the blood glucose meter to provide continuous current and predicted estimates of glucose levels in real time, including any other relevant information mentioned above. In addition, since the patient's relevant data changes over time, the estimation / prediction model can be updated regularly. In other words, since the patient's condition changes over time, the patient can wear a continuous glucose sensor from time to time (e.g., once or twice a month) to obtain data that can be used to retrain the estimation model, so that it generates a more accurate estimate for that particular patient.

[0053] For example, the functionality can reside in a web-based application and a mobile application. The estimation model can be implemented / deployed on a back-end server that runs the estimation model as part of a web-based application and transmits information back to the user's phone, insulin pump, or other terminal device, and / or can also be implemented as part of a mobile application that runs on the user's phone or other terminal device and transmits information back to the insulin pump or other terminal device. The estimation model can also be implemented / deployed on an insulin pump. Regardless of the implementation method, the application can send push notifications to patients to alert them when an estimated low or high excursion event occurs, can receive user requests and provide accurate and coherent answers, and can also provide a way to enter data, which can be used to track user history and improve predictive estimates.

[0054] The estimation model can be trained using a continuous glucose sensor device, and once it is trained and then personalized / adjusted for a specific user / patient, the continuous glucose sensor does not need to be used regularly. This can allow the user / patient to be less dependent on the continuous glucose sensor. They only need to use the CGM from time to time rather than regularly.

[0055] Instead, a blood glucose meter can be used in conjunction with an activity tracker to generate inputs to an estimation model, which can then generate estimated glucose values ​​that approximate measured glucose values ​​that would be measured by a continuous glucose sensor. In essence, the disclosed embodiments can allow a patient to use an activity tracker and intermittent measurements from a blood glucose meter without having to regularly use a continuous glucose sensor (e.g., a patient can use a continuous glucose sensor for calibration from time to time, but then only use the blood glucose meter and activity tracker and estimation model the rest of the time).

[0056] In some embodiments, the estimation model can process additional types of data, which can improve the accuracy of the estimation. For example, patients can use meal data describing the food that the patient has eaten recently, intermittent blood glucose measurements from a blood glucose meter (which is obtained by the user, for example, by fingertip measurement) and relevant activity data continuously received from an activity tracker or other activity information sources about the patient to estimate their blood glucose values. The other relevant activity data can include data such as physical activity data (for example, heart rate, number of steps or metabolic equivalents, etc.), metabolic data (for example, calories burned), etc. This information can be used by an estimation or prediction module to estimate glucose values ​​in a manner that approximates blood glucose measurements with high accuracy, and the blood glucose measurements will be measured by a continuous glucose sensor without the cost of a continuous glucose sensor or a permanent connection to a continuous glucose sensor. When the estimated glucose values ​​are accurate enough, for example, they can be used to drive an insulin infusion device to administer insulin to the patient, or provide notifications to the patient or a healthcare partner to manually inject insulin boluses based on their estimated glucose values ​​and other information, such as activity data, meal information, etc., or provide information to a healthcare provider to adjust the basal rate settings of the insulin infusion device so that they are suitable for specific patients to meet their needs. It can also be used as a medication titration advisor for individuals taking other types of glucose-lowering medications. When the estimated glucose value is not accurate enough, this condition can be used to trigger a notification, warning, alarm, or reminder, for example, on another device (e.g., an insulin pump, the user's smartphone or other smart device, etc.) to inform the user that they should not trust the system and suggest that the user wear another sensor (e.g., a CGM) to retrain the estimation model.

[0057] Therefore, the proposed method and system can provide a new digital diabetes management solution that is cheaper and more affordable; more likely to be used by users who cannot afford a digital diabetes management system; more likely to be approved by insurance, etc. The proposed method and system can also help users get started with digital diabetes management solutions until they transition to a CGM-based diabetes management system.

[0058] Now go to Figure 1, an exemplary embodiment of an infusion system 100 includes, but is not limited to, a fluid infusion device (or infusion pump) 102, a sensing arrangement 104, a command control device (CCD) 106, and a computer 108. The components of the infusion system 100 may be implemented using different platforms, designs, and configurations, and Figure 1 The embodiments shown in are not exhaustive or limiting. In practice, Figure 1 As shown in , the infusion device 102 and the sensing arrangement 104 are fixed at the desired location on the body of the user (or patient). In this regard, Figure 1 The positions of the infusion device 102 and the sensing arrangement 104 in FIG. 1 are fixed to the user's body only as representative, non-limiting examples. The elements of the infusion system 100 may be similar to those described in U.S. Pat. No. 8,674,288, the subject matter of which is incorporated herein by reference in its entirety.

[0059] exist Figure 1 In the illustrated embodiment, the infusion device 102 is designed as a portable medical device suitable for infusing a fluid, liquid, gel or other medication into the body of a user. In the exemplary embodiment, the infused fluid is insulin, although many other fluids can be administered by infusion, such as but not limited to HIV medications, medications for treating pulmonary hypertension, iron chelation medications, pain medications, anti-cancer treatments, drugs, vitamins, hormones, etc. In some embodiments, the fluid may include nutritional supplements, dyes, tracking media, saline media, hydration media, etc.

[0060] The sensing arrangement 104 generally represents a component of the infusion system 100 configured to sense, detect, measure, or otherwise quantify a condition of a user, and may include sensors, monitors, and the like for providing data indicative of a condition sensed, detected, measured, or otherwise monitored by the sensing arrangement. In this regard, the sensing arrangement 104 may include electronics and enzymes responsive to a biological condition of the user, such as blood glucose level, and provide data indicative of the blood glucose level to the infusion device 102, CCD 106, and / or computer 108. For example, the infusion device 102, CCD 106, and / or computer 108 may include a display for presenting information or data to the user based on sensor data received from the sensing arrangement 104 (e.g., a user's current glucose level, a plot or graph of the user's glucose level over time, a device status indicator, an alarm message, and the like). In other embodiments, the infusion device 102, the CCD 106, and / or the computer 108 may include electronics and software configured to analyze the sensor data and operate the infusion device 102 based on the sensor data and / or a preprogrammed delivery routine to deliver the fluid to the user's body. Thus, in an exemplary embodiment, one or more of the infusion device 102, the sensing arrangement 104, the CCD 106, and / or the computer 108 include a transmitter, a receiver, and / or other transceiver electronics that allow communication with other components of the infusion system 100, such that the sensing arrangement 104 can transmit sensor data or monitor data to one or more of the infusion device 102, the CCD 106, and / or the computer 108.

[0061] Still reference Figure 1 In various embodiments, the sensing arrangement 104 may be affixed to the user's body or embedded in the user's body at a location remote from where the infusion device 102 is affixed to the user's body. In various other embodiments, the sensing arrangement 104 may be incorporated into the infusion device 102. In other embodiments, the sensing arrangement 104 may be separate and isolated from the infusion device 102 and may be, for example, part of the CCD 106. In such embodiments, the sensing arrangement 104 may be configured to receive a biological sample, an analyte, etc. to measure a condition of the user.

[0062] In some embodiments, the CCD 106 and / or the computer 108 may include electronics and other components configured to perform processing, deliver routine storage, and control the infusion device 102 in a manner affected by sensor data measured by the sensing arrangement 104 and / or received from the sensing arrangement. By including the control functions in the CCD 106 and / or the computer 108, the infusion device 102 can be made with more simplified electronics. However, in other embodiments, the infusion device 102 may include all control functions and may operate without the CCD 106 and / or the computer 108. In various embodiments, the CCD 106 may be a portable electronic device. In addition, in various embodiments, the infusion device 102 and / or the sensing arrangement 104 may be configured to transmit data to the CCD 106 and / or the computer 108 to be displayed or processed by the CCD 106 and / or the computer 108.

[0063] In some embodiments, CCD 106 and / or computer 108 can provide information to the user to facilitate the user's subsequent use of infusion device 102. For example, CCD 106 can provide information to the user to allow the user to determine the rate or dosage of the drug to be applied to the user's body. In other embodiments, CCD 106 can provide information to infusion device 102 to autonomously control the rate or dosage of the drug applied to the user's body. In some embodiments, sensing arrangement 104 can be integrated into CCD 106. Such embodiments can allow the user to monitor the condition by providing a sample of, for example, his or her blood to sensing arrangement 104 to assess his or her condition. In some embodiments, sensing arrangement 104 and CCD 106 can be used to determine the glucose level in the user's blood and / or body fluids without using or requiring a wire or cable connection between infusion device 102 and sensing arrangement 104 and / or CCD 106.

[0064] In some embodiments, sensing arrangement 104 and / or infusion device 102 are cooperatively configured to utilize closed loop system to deliver fluid to user. Examples of sensing device and / or infusion pump utilizing closed loop system can be found in the following but are not limited to the following: U.S. Patent Nos. 6,088,608, 6,119,028, 6,589,229, 6,740,072, 6,827,702, 7,323,142 and 7,402,153 or U.S. Patent Application Publication No. 2014 / 0066889, all of which are incorporated herein by reference in their entirety. In such embodiments, sensing arrangement 104 is configured to sense or measure the condition of the user, such as blood sugar level, etc. Infusion device 102 is configured to deliver fluid in response to the condition sensed by sensing arrangement 104. In turn, the sensing arrangement 104 continues to sense or otherwise quantify the user's current condition, thereby allowing the infusion device 102 to continue to deliver fluid indefinitely in response to the condition currently (or most recently) sensed by the sensing arrangement 104. In some embodiments, the sensing arrangement 104 and / or infusion device 102 may be configured to utilize the closed-loop system only during a portion of the day (e.g., only when the user is asleep or awake).

[0065] Figure 2-4 Depicted is a device suitable for use in an infusion system (e.g., as Figure 1 The fluid infusion device 200 (or alternatively, an infusion pump) of the infusion device 102 in the infusion system 100 is an exemplary embodiment of the present invention. The fluid infusion device 200 is a portable medical device designed to be carried or worn by a patient (or user), and the fluid infusion device 200 can utilize any number of conventional features, components, elements, and characteristics of existing fluid infusion devices, such as some of the features, components, elements, and / or characteristics described in U.S. Patent Nos. 6,485,465 and 7,621,893. It should be understood that Figure 2-4 Certain aspects of the infusion device 200 are depicted in a simplified manner; in practice, the infusion device 200 may include additional elements, features, or components not shown or described in detail herein.

[0066] As in Figure 2-3As best shown in , the illustrated embodiment of the fluid infusion device 200 includes a housing 202 adapted to receive a reservoir 205 containing a fluid. An opening 220 in the housing 202 accommodates a fitting 223 (or cap) for the reservoir 205, wherein the fitting 223 is configured to mate or otherwise interface with a tube 221 of an infuser 225 that provides a fluid path to / from the user's body. In this manner, fluid communication is established from the interior of the reservoir 205 to the user through the tube 221. The illustrated fluid infusion device 200 includes a human-machine interface (HMI) 230 (or user interface), which includes elements 232, 234 that can be manipulated by the user to administer a bolus of fluid (e.g., insulin), change therapy settings, change user preferences, select display features, etc. The infusion device also includes a display element 226, such as a liquid crystal display (LCD) or another suitable display element, which can be used to present various types of information or data to the user, such as, but not limited to: the patient's current glucose level; the time; a plot or graph of the patient's glucose level versus time; a device status indicator; and the like.

[0067] The housing 202 is formed of a substantially rigid material having a hollow interior 214 adapted to allow the electronics assembly 204, the sliding member (or slider) 206, the drive system 208, the sensor assembly 210, and the drive system capping member 212 to be disposed therein in addition to the reservoir 205, wherein the contents of the housing 202 are surrounded by a housing capping member 216. The opening 220, the slider 206, and the drive system 208 are coaxially aligned in an axial direction (indicated by arrow 218), whereby the drive system 208 facilitates linear displacement of the slider 206 in the axial direction 218 to dispense fluid from the reservoir 205 (after the reservoir 205 has been inserted into the opening 220), wherein the sensor assembly 210 is configured to measure an axial force (e.g., a force aligned with the axial direction 218) exerted on the sensor assembly 210 in response to operating the drive system 208 to displace the slider 206. In various embodiments, the sensor assembly 210 can be used to detect one or more of the following: a slowdown, blockage, or other degradation in the fluid path of fluid delivery from the reservoir 205 to the user's body; when the reservoir 205 is empty; when the slide 206 is properly seated with the reservoir 205; when fluid has not been delivered; when the infusion device 200 is subjected to shock or vibration; and when the infusion device 200 requires maintenance.

[0068] Depending on the embodiment, the reservoir 205 containing the fluid may be implemented as a syringe, a vial, a cartridge, a bag, etc. In certain embodiments, the infused fluid is insulin, although many other fluids may be administered by infusion, such as, but not limited to, HIV medications, medications for treating pulmonary hypertension, iron chelation medications, pain medications, anti-cancer treatments, drugs, vitamins, hormones, etc. As in Figure 3-4 As best shown in , the reservoir 205 generally includes a reservoir barrel 219 that contains fluid and is concentrically and / or coaxially aligned (e.g., in the axial direction 218) with the slider 206 when the reservoir 205 is inserted into the infusion set 200. The end of the reservoir 205 proximal to the opening 220 may include or otherwise cooperate with a fitting 223 that secures the reservoir 205 in the housing 202 and prevents the reservoir 205 from being displaced relative to the housing 202 in the axial direction 218 after the reservoir 205 is inserted into the housing 202. As described above, the fitting 223 extends from (or through) the opening 220 of the housing 202 and cooperates with the tube 221 to establish fluid communication from the interior of the reservoir 205 (e.g., the reservoir barrel 219) to the user through the tube 221 and the infusion set 225. The opposite end of the reservoir 205 proximal to the slider 206 contains a plunger 217 (or plug) positioned to push fluid from the interior of the barrel 219 of the reservoir 205 to the user along a fluid path through the tube 221. The slider 206 is configured to mechanically couple or otherwise engage with the plunger 217, thereby becoming seated with the plunger 217 and / or the reservoir 205. When the drive system 208 is operated to displace the slider 206 in the axial direction 218 toward the opening 220 in the housing 202, the fluid is forced to exit the reservoir 205 through the tube 221.

[0069] exist Figure 3-4In the illustrated embodiment of , the drive system 208 includes a motor assembly 207 and a drive screw 209. The motor assembly 207 includes a motor coupled to a drive train component of the drive system 208 configured to convert a rotary motor motion into a translational displacement of the slider 206 in an axial direction 218 and thereby engage and displace a plunger 217 of the reservoir 205 in the axial direction 218. In some embodiments, the motor assembly 207 can also be powered to translate the slider 206 in an opposite direction (e.g., opposite to the direction 218) to retract and / or remove from the reservoir 205 to allow replacement of the reservoir 205. In an exemplary embodiment, the motor assembly 207 includes a brushless DC (BLDC) motor having one or more permanent magnets mounted, attached, or otherwise disposed on its rotor. However, the subject matter described herein is not necessarily limited to use with BLDC motors, and in alternative embodiments, the motor may be implemented as a solenoid motor, an AC motor, a stepper motor, a piezoelectric caterpillar drive, a shape memory actuator drive, an electrochemical gas cell, a thermally driven gas cell, a bimetallic actuator, etc. The drive train components may include one or more lead screws, cams, ratchets, jacks, pulleys, pawls, clamps, gears, nuts, slides, bearings, levers, beams, stops, plungers, slides, brackets, guides, bearings, supports, bellows, caps, diaphragms, bags, heaters, etc. In this regard, although the illustrated embodiment of the infusion pump utilizes a coaxially aligned drive train, the motor may be arranged in an offset or other non-coaxial manner relative to the longitudinal axis of the reservoir 205.

[0070] like Figure 4 , the drive screw 209 cooperates with the threads 402 on the interior of the slider 206. When the motor assembly 207 is powered and operated, the drive screw 209 rotates and forces the slider 206 to translate in the axial direction 218. In an exemplary embodiment, the infusion device 200 includes a sleeve 211 to prevent the slider 206 from rotating when the drive screw 209 of the drive system 208 rotates. Therefore, rotation of the drive screw 209 causes the slider 206 to extend or retract relative to the drive motor assembly 207. When the fluid infusion device is assembled and operational, the slider 206 contacts the plunger 217 to engage the reservoir 205 and control the delivery of fluid from the infusion device 200. In an exemplary embodiment, the shoulder portion 215 of the slider 206 contacts or otherwise engages the plunger 217 to displace the plunger 217 in the axial direction 218. In an alternative embodiment, the slider 206 may include a threaded tip 213 that is removably engageable with internal threads 404 on the plunger 217 of the reservoir 205, as described in detail in US Pat. Nos. 6,248,093 and 6,485,465, which are incorporated herein by reference.

[0071] like Figure 3 , the electronics assembly 204 includes control electronics 224 coupled to a display element 226, wherein the housing 202 includes a transparent window portion 228 aligned with the display element 226 to allow the display element 226 to be viewed by a user when the electronics assembly 204 is disposed within the interior 214 of the housing 202. The control electronics 224 generally represents hardware, firmware, processing logic, and / or software (or a combination thereof) configured to control the operation of the motor assembly 207 and / or the drive system 208, as described below in Figure 5 The control electronics 224 are also appropriately configured and designed to support various user interfaces, input / output, and display features of the fluid infusion device 200. Whether this functionality is implemented as hardware, firmware, a state machine, or software depends on the specific application and the design constraints imposed on the embodiment. Personnel familiar with the concepts described herein can implement this functionality in a suitable manner for each specific application, but such implementation decisions should not be interpreted as limiting or restrictive. In an exemplary embodiment, the control electronics 224 includes one or more programmable controllers that can be programmed to control the operation of the infusion device 200.

[0072] The motor assembly 207 includes one or more electrical leads 236 adapted to be electrically coupled to the electronics assembly 204 to establish communication between the control electronics 224 and the motor assembly 207. In response to a command signal from the control electronics 224 for operating a motor driver (e.g., a power converter) to regulate the amount of power supplied to the motor from the power source, the motor actuates the drive train components of the drive system 208 to displace the slider 206 in the axial direction 218 to force the fluid to leave the reservoir 205 along the fluid path (including the tube 221 and the infusion set), thereby administering a dose of the fluid contained in the reservoir 205 to the body of the user. Preferably, the power source is implemented as one or more batteries contained within the housing 202. Alternatively, the power source may be a solar panel, a capacitor, an AC or DC power source provided by a power cord, etc. In some embodiments, control electronics 224 may operate motor assembly 207 and / or the motor of drive system 208 in a step-wise manner (typically, intermittently); to administer discrete, precise doses of fluid to a user according to a programmed delivery profile.

[0073] refer to Figure 2-4As described above, the user interface 230 includes HMI elements, such as buttons 232 and directional pad 234, formed on a graphical keyboard overlay 231 that overlays a keyboard assembly 233, the graphical keyboard overlay including features corresponding to the buttons 232, directional pad 234, or other user interface items indicated by the graphical keyboard overlay 231. When assembled, the keyboard assembly 233 is coupled to the control electronics 224, thereby allowing the HMI elements 232, 234 to be manipulated by the user to interact with the control electronics 224 and control the operation of the infusion device 200, such as to administer insulin boluses, change therapy settings, change user preferences, select display functions, set or disable alarms and reminders, etc. In this regard, the control electronics 224 maintains and / or provides information to the display element 226 regarding program parameters, delivery profiles, pump operation, alarms, warnings, status, etc., which can be adjusted using the HMI elements 232, 234. In various embodiments, the HMI elements 232, 234 may be implemented as physical objects (e.g., buttons, knobs, joysticks, etc.) or virtual objects (e.g., using touch sensing and / or proximity sensing technology). For example, in some embodiments, the display element 226 may be implemented as a touch screen or touch-sensitive display, and in such embodiments, the features and / or functionality of the HMI elements 232, 234 may be integrated into the display element 226 and the HMI 230 may not be present. In some embodiments, the electronic device assembly 204 may also include an alarm generation element that is coupled to the control electronic device 224 and is suitably configured to generate one or more types of feedback, such as, but not limited to: auditory feedback; visual feedback; tactile (physical) feedback; etc.

[0074] refer to Figure 3-4According to one or more embodiments, the sensor assembly 210 includes a back plate structure 250 and a loading element 260. The loading element 260 is disposed between the capping member 212 and a beam structure 270 including one or more beams having sensing elements disposed thereon that are affected by a compressive force applied to the sensor assembly 210 that deflects the one or more beams, as described in more detail in U.S. Pat. No. 8,474,332, which is incorporated herein by reference. In an exemplary embodiment, the back plate structure 250 is attached, adhered, mounted, or otherwise mechanically coupled to the bottom surface 238 of the drive system 208 such that the back plate structure 250 resides between the bottom surface 238 of the drive system 208 and the housing cover member 216. The contour of the drive system capping member 212 is set to accommodate and conform to the bottom of the sensor assembly 210 and the drive system 208. The drive system capping member 212 can be attached to the interior of the housing 202 to prevent the sensor assembly 210 from being displaced in a direction opposite to the direction of the force provided by the drive system 208 (e.g., opposite to the direction 218). Therefore, the sensor assembly 210 is positioned between the motor assembly 207 and fixed by the capping member 212, which prevents the sensor assembly 210 from being displaced in a downward direction opposite to the direction of the arrow representing the axial direction 218, so that the sensor assembly 210 is subjected to a reactive compressive force when the drive system 208 and / or the motor assembly 207 are operated to displace the slider 206 in the axial direction 218 opposite to the fluid pressure in the reservoir 205. Under normal operating conditions, the compressive force applied to the sensor assembly 210 is related to the fluid pressure in the reservoir 205. As shown, the electrical lead 240 is adapted to electrically couple the sensing element of the sensor assembly 210 to the electronics assembly 204 to establish communication with the control electronics 224, wherein the control electronics 224 is configured to measure, receive, or otherwise obtain an electrical signal from the sensing element of the sensor assembly 210 indicating a force applied by the drive system 208 in the axial direction 218.

[0075] Figure 5An exemplary embodiment of an infusion system 500 suitable for use with an infusion device 502 (such as any of the infusion devices 102, 200 described above) is depicted. The control system 500 is capable of controlling or otherwise adjusting a physiological condition in a patient's body 501 to a desired (or target) value, or otherwise maintaining the condition within a range of acceptable values ​​in an automatic or autonomous manner. In one or more exemplary embodiments, the regulated condition is sensed, detected, measured, or otherwise quantified by a sensing arrangement 504 (e.g., a blood glucose sensing arrangement 504) that is communicatively connected to the infusion device 502. However, it should be noted that in alternative embodiments, the condition regulated by the infusion system 500 can be related to a measurement value obtained by the sensing arrangement 504. That is, for the purpose of clarity and explanation, the subject matter may be described herein in the context of a glucose sensing arrangement in which the sensing arrangement 504 is implemented as a glucose sensing arrangement that senses, detects, measures, or otherwise quantifies the patient's glucose level being regulated in the patient's body 501 by the infusion system 500.

[0076] In an exemplary embodiment, the sensing arrangement 504 includes one or more interstitial glucose sensing elements, which generate or otherwise output an electrical signal (alternatively referred to as a measurement signal herein) having a signal characteristic related to, affected by, or otherwise indicating the relative interstitial fluid glucose level in the patient's body 501. The output electrical signal is filtered or otherwise processed to obtain a measurement indicating the interstitial fluid glucose level of the patient. For example, in one embodiment, the sensor of a continuous glucose monitor (CGM) uses, for example, a subcutaneous sensor to indirectly measure glucose through interstitial fluid. Interstitial fluid is a liquid surrounding tissue cells under the patient's skin, and typically glucose first moves from their blood vessels and capillaries, and then enters their interstitial fluid. Therefore, the sensor glucose reading is obtained from the patient's interstitial fluid by the sensing arrangement 504, rather than from their blood, such as fingertip measurement. For the purpose of explanation, the calibrated blood glucose value calculated based on the electrical signal output by the sensing element of the sensing arrangement 504 can be alternatively referred to as a sensor glucose (SG) value, a sensed glucose value, or a variant thereof in this article. There is a physiological lag between the measurement of the interstitial SG value and the blood glucose value. Therefore, in most cases, the sensing arrangement 504 needs to be calibrated using a blood glucose meter 530. To further explain, the blood glucose meter 530 measures blood glucose values ​​directly from the blood flow. Therefore, a blood glucose value may refer to a glucose value measured directly from the patient's blood supply. In this regard, the terms "blood glucose measurement", "measured blood glucose", "blood glucose concentration", "measured blood glucose concentration", etc. may refer to glucose levels, blood glucose levels, blood glucose concentrations, etc. that have been obtained by any type of glucose sensor. In an exemplary embodiment, a blood glucose meter 530 (such as a fingertip device) is used to directly sense, detect, measure, or otherwise quantify blood glucose in the user's body 501. In this regard, the blood glucose meter 530 outputs or otherwise provides a measured blood glucose value that can be used as a reference measurement for calibrating the sensing arrangement 504 and converting a measured value indicating the patient's interstitial fluid glucose level into a corresponding calibrated blood glucose value.

[0077] In an exemplary embodiment, the infusion system 500 also includes one or more additional sensing arrangements 506, 508 configured to sense, detect, measure, or otherwise quantify a characteristic of the patient's body 501 that indicates a condition in the patient's body 501. In this regard, in addition to the glucose sensing arrangement 504, one or more auxiliary sensing arrangements 506 (also referred to herein as activity data sources or "activity trackers") may be worn, carried, or otherwise associated with the patient's body 501 to measure a characteristic or condition of the patient (or the patient's activity) that may affect the patient's glucose level or insulin sensitivity. For example, a heart rate sensing arrangement 506 may be worn on or otherwise associated with the patient's body 501 to sense, detect, measure, or otherwise quantify the patient's heart rate, which in turn may indicate movement (and its intensity) that may affect the patient's glucose level or insulin response in the body 501. In yet another embodiment, another invasive, interstitial or subcutaneous sensing arrangement 506 may be inserted into the patient's body 501 to obtain a measurement of another physiological condition that may indicate movement (and its intensity), such as a lactate sensor, a ketone sensor, etc. Depending on the embodiment, the auxiliary sensing arrangement(s) 506 may be implemented as a separate component worn by the patient, or alternatively, the auxiliary sensing arrangement(s) 506 may be integrated with the infusion device 502 or the glucose sensing arrangement 504.

[0078] The illustrated infusion system 500 also includes an acceleration sensing arrangement 508 (or accelerometer) that may be worn on or otherwise associated with the patient's body 501 to sense, detect, measure, or otherwise quantify acceleration of the patient's body 501, which in turn may indicate motion or some other condition in the body 501 that may affect the patient's insulin response. Figure 5 502, but in alternative embodiments, the acceleration sensing arrangement 508 may be integrated with another sensing arrangement 504, 506 on the patient's body 501, or the acceleration sensing arrangement 508 may be implemented as a separate stand-alone component worn by the patient.

[0079] In the illustrated embodiment, the pump control system 520 generally represents the electronics and other components of the infusion device 502 that control the operation of the fluid infusion device 502 in accordance with a desired infusion delivery program in a manner that is influenced by a sensed glucose value that is indicative of a current glucose level in the patient's body 501. For example, to support a closed-loop operating mode, the pump control system 520 maintains, receives, or otherwise obtains a target or command glucose value, and automatically generates or otherwise determines a dose command for operating an actuation arrangement (such as a motor 532) to displace the plunger 517 and deliver insulin to the patient's body 501 based on a difference between the sensed glucose value and the target glucose value. In other operating modes, the pump control system 520 may generate or otherwise determine a dose command that is configured to maintain the sensed glucose value below an upper glucose limit, above a lower glucose limit, or otherwise within a desired range of glucose values. In practice, the infusion device 502 may store or otherwise maintain the target value, one or more upper and / or lower glucose limits, one or more insulin delivery limits, and / or one or more other glucose thresholds in a data storage element accessible to the pump control system 520. As described in greater detail, in one or more exemplary embodiments, the pump control system 520 automatically adjusts or adapts one or more parameters or other control information used to generate commands to operate the motor 532 in a manner that accounts for possible changes in the patient's glucose level or insulin response due to meals, exercise, or other activities.

[0080] Still refer to Figure 5 The target glucose value and other threshold glucose values ​​utilized by the pump control system 520 may be received from an external component (e.g., the CCD 106 and / or the computing device 108), or input by the patient to a user interface element 540 associated with the infusion device 502. In practice, the one or more user interface elements 540 associated with the infusion device 502 typically include at least one input user interface element, such as a button, a keypad, a keyboard, a knob, a joystick, a mouse, a touch panel, a touch screen, a microphone or another audio input device, and / or the like. In addition, the one or more user interface elements 540 include at least one output user interface element for providing notifications or other information to the patient, such as a display element (e.g., a light emitting diode, etc.), a display device (e.g., a liquid crystal display, etc.), a speaker or another audio output device, a tactile feedback device, etc. It should be noted that although Figure 5The one or more user interface elements 540 are depicted as being separate from the infusion device 502, but in practice, the one or more user interface elements 540 may be integrated with the infusion device 502. Furthermore, in some embodiments, in addition to and / or in lieu of the one or more user interface elements 540 being integrated with the infusion device 502, the one or more user interface elements 540 are integrated with the sensing arrangement 504. The user interface element(s) 540 may be manipulated by the patient to operate the infusion device 502 as desired to deliver a correction bolus, adjust a target value and / or threshold, modify a delivery control scheme or mode of operation, and the like.

[0081] Still refer to Figure 5 In the illustrated embodiment, the infusion device 502 includes a motor control module 512 coupled to a motor 532 (e.g., motor assembly 207) operable to displace a plunger 517 (e.g., plunger 217) into a reservoir (e.g., reservoir 205) and provide a desired amount of fluid to the patient's body 501. In this regard, the displacement of the plunger 517 results in the delivery of a fluid (e.g., insulin) capable of affecting the patient's physiological condition to the patient's body 501 via a fluid delivery path (e.g., via the tube 221 of the infusion set 225). The motor driver module 514 is coupled between the energy source 518 and the motor 532. The motor control module 512 is coupled to the motor driver module 514, and the motor control module 512 generates or otherwise provides a command signal that operates the motor driver module 514 to provide current (or power) from the energy source 518 to the motor 532 to displace the plunger 517 in response to receiving a dose command from the pump control system 520 indicating a desired amount of fluid to be delivered.

[0082] In an exemplary embodiment, the energy source 518 is implemented as a battery housed within the infusion device 502 (e.g., within the housing 202) that provides direct current (DC) power. In this regard, the motor driver module 514 generally represents a combination of circuitry, hardware, and / or other electrical components that are configured to convert or otherwise transform the DC power provided by the energy source 518 into an alternating current signal that is applied to the stator windings of the motor 532, causing current to flow through the corresponding phases of the stator windings, the current generating a stator magnetic field and rotating the rotor of the motor 532. The motor control module 512 is configured to receive or otherwise obtain a commanded dose from the pump control system 520, convert the commanded dose into a commanded translational displacement of the plunger 517, and command, signal, or otherwise operate the motor driver module 514 to rotate the rotor of the motor 532 by an amount that produces the commanded translational displacement of the plunger 517. For example, the motor control module 512 can determine the amount of rotation of the rotor required to produce the translational displacement of the plunger 517 to achieve the commanded dose received from the pump control system 520. Based on the current rotational position (or orientation) of the rotor relative to the stator indicated by the output of the rotor sensing arrangement 516, the motor control module 512 determines the appropriate sequence of AC electrical signals of corresponding phases to be applied to the stator windings that should cause the rotor to rotate a determined amount of rotation from its current position (or orientation). In an embodiment where the motor 532 is implemented as a BLDC motor, the AC electrical signals cause the corresponding phases of the stator windings to switch directions with the appropriate orientation of the rotor poles relative to the stator and in an appropriate sequence to provide a rotating stator magnetic field that rotates the rotor in the desired direction. Thereafter, the motor control module 512 operates the motor driver module 514 to apply the determined AC electrical signals (e.g., command signals) to the stator windings of the motor 532 to achieve the desired fluid delivery to the patient.

[0083] When the motor control module 512 is operating the motor driver module 514, current flows from the energy source 518 through the stator windings of the motor 532 to generate a stator magnetic field that interacts with the rotor magnetic field. In some embodiments, after the motor control module 512 operates the motor driver module 514 and / or the motor 532 to achieve the commanded dose, the motor control module 512 stops operating the motor driver module 514 and / or the motor 532 until a subsequent dose command is received. In this regard, the motor driver module 514 and the motor 532 enter an idle state, during which the motor driver module 514 effectively disconnects or separates the stator windings of the motor 532 from the energy source 518. In other words, current does not flow from the energy source 518 through the stator windings of the motor 532 when the motor 532 is idle, and therefore, the motor 532 does not consume power from the energy source 518 in the idle state, thereby improving efficiency.

[0084] Depending on the embodiment, the motor control module 512 may be implemented or realized with a general purpose processor, microprocessor, controller, microcontroller, state machine, content addressable memory, application specific integrated circuit, field programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. In an exemplary embodiment, the motor control module 512 contains or otherwise has access to a data storage element or memory capable of storing programming instructions executed by the motor control module 512, including any kind of random access memory (RAM), read-only memory (ROM), flash memory, registers, hard disk, removable disk, magnetic or optical mass storage, or any other short-term or long-term storage medium or other non-transitory computer-readable medium. When read and executed by the motor control module 512, the computer executable programming instructions cause the motor control module 512 to perform or otherwise support the tasks, operations, functions, and processes described herein.

[0085] It should be understood that for the purpose of explanation, Figure 5 is a simplified representation of the infusion device 502 and is not intended to limit the subject matter described herein in any way. In this regard, depending on the embodiment, some features and / or functions of the sensing arrangement 504 may be implemented by the pump control system 520 or otherwise integrated into the pump control system or vice versa. Similarly, in practice, features and / or functions of the motor control module 512 may be implemented by the pump control system 520 or otherwise integrated into the pump control system or vice versa. In addition, features and / or functions of the pump control system 520 may be implemented by the control electronics 224 located in the fluid infusion device 502, while in alternative embodiments, the pump control system 520 may be implemented by a remote computing device that is physically different and / or separate from the infusion device 502 (e.g., the CCD 106 or the computing device 108).

[0086] Figure 6 Describes an embodiment of the present invention that is suitable for use as Figure 5 6. An exemplary embodiment of a pump control system 600 of the pump control system 520 in FIG. The pump control system 600 shown includes, but is not limited to, a pump control module 602, a communication interface 604, and a data storage element (or memory) 606. The pump control module 602 is coupled to the communication interface 604 and the memory 606, and the pump control module 602 is suitably configured to support the operations, tasks, and / or processes described herein. In various embodiments, the pump control module 602 is also coupled to one or more user interface elements (e.g., user interface 230, 540) to receive user input (e.g., target glucose value or other glucose threshold) and provide notifications, alarms, or other therapy information to the patient.

[0087] The communication interface 604 generally represents the hardware, circuitry, logic, firmware, and / or other components of the pump control system 600 that are coupled to the pump control module 602 and are configured to support communications between the pump control system 600 and the various sensing arrangements 504, 506, 508. In this regard, the communication interface 604 may include or otherwise be coupled to one or more transceiver modules capable of supporting wireless communications between the pump control system 520, 600 and the sensing arrangements 504, 506, 508. For example, the communication interface 604 may be used to receive sensor measurements or other measurement data from each sensing arrangement 504, 506, 508 in the infusion system 500. In other embodiments, the communication interface 604 may be configured to support wired communications to / from the sensing arrangement(s) 504, 506, 508. In various embodiments, the communication interface 604 may also support communication with another electronic device in the infusion system (e.g., CCD 106 and / or computer 108) (e.g., uploading sensor measurements to a server or other computing device, receiving control information from a server or other computing device, etc.).

[0088] The pump control module 602 generally represents the hardware, circuitry, logic, firmware, and / or other components of the pump control system 600 that are coupled to the communication interface 604 and configured to determine a dosage command for operating the motor 532 to deliver fluid to the body 501 based on the measurement data received from the sensing arrangements 504, 506, 508 and to perform various additional tasks, operations, functions, and / or operations described herein. For example, in an exemplary embodiment, the pump control module 602 implements or otherwise executes a command generation application 610 that supports one or more autonomous operation modes and calculates or otherwise determines a dosage command for operating the motor 532 of the infusion device 502 in the autonomous operation mode based at least in part on current measurements of conditions in the patient's body 501. For example, in a closed-loop operation mode, the command generation application 610 may determine a dosage command for operating the motor 532 to deliver insulin to the patient's body 501 to adjust the patient's blood glucose level to a target reference glucose value based at least in part on the current glucose measurement value most recently received from the sensing arrangement 504. Additionally, the command generation application 610 may generate a dosage command for a bolus that is manually initiated or otherwise indicated by the patient via a user interface element.

[0089] In an exemplary embodiment, the pump control module 602 also implements or otherwise executes a personalization application 608 that is cooperatively configured to interact with the command generation application 610 to support decisions to adjust the dosage command or control information in a manner in which the dosage command is generated in a personalized patient-specific manner. In this regard, in some embodiments, based on correlations between current or recent measurement data and the current operating context relative to historical data associated with the patient, the personalization application 608 may adjust or otherwise modify the values ​​of one or more parameters utilized by the command generation application 610 in determining the dosage command, for example, by modifying parameter values ​​at locations in registers or memory 606 referenced by the command generation application 610. In still other embodiments, the personalization application 608 may predict meals or other events or activities that the patient may engage in, and output or otherwise provide an indication of the predicted patient behavior for confirmation or modification by the patient, which in turn may then be used to adjust in a personalized manner the manner in which the dosage command is generated to adjust glucose in a manner that takes into account the patient's behavior.

[0090] Still refer to Figure 6 Depending on the embodiment, the pump control module 602 may be implemented or realized with at least one general purpose processor device, microprocessor, controller, microcontroller, state machine, content addressable memory, application specific integrated circuit, field programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. In this regard, the steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be directly embodied in hardware, firmware, a software module executed by the pump control module 602, or any practical combination thereof. In an exemplary embodiment, the pump control module 602 contains or otherwise accesses a data storage element or memory 606, which may be implemented using any type of non-transitory computer readable medium capable of storing programming instructions for execution by the pump control module 602. When read and executed by the pump control module 602, the computer executable programming instructions cause the pump control module 602 to implement or otherwise generate the applications 608, 610 and perform the tasks, operations, functions, and processes described herein.

[0091] It should be understood that for the purpose of explanation, Figure 6is a simplified representation of the pump control system 600 and is not intended to limit the subject matter described herein in any way. For example, in some embodiments, the features and / or functionality of the motor control module 512 may be implemented by or otherwise integrated into the pump control system 600 and / or pump control module 602, such as by the command generation application 610 converting dose commands into corresponding motor commands, in which case a separate motor control module 512 may not be present in embodiments of the infusion device 502.

[0092] Figure 7 Depicting an exemplary closed-loop control system 700 that can be implemented by the pump control system 520, 600 to provide a closed-loop operating mode that autonomously regulates the patient's physical condition to a reference (or target) value. In this regard, the control system 700 can be used to regulate the delivery of insulin to the patient during an automatic basal insulin delivery operation. It should be understood that for purposes of explanation, Figure 7 is a simplified representation of control system 700 and is not intended to limit the subject matter described herein in any way.

[0093] In an exemplary embodiment, the control system 700 receives or otherwise obtains a target glucose value at an input 702. In some embodiments, the target glucose value can be stored or otherwise maintained (e.g., in a memory 606) by the infusion device 502, however, in some alternative embodiments, the target value can be received from an external component (e.g., CCD 106 and / or computer 108). In one or more embodiments, the target glucose value can be calculated or otherwise determined before entering the closed-loop operation mode based on one or more patient-specific control parameters. For example, the target blood glucose value can be calculated at least in part based on a patient-specific reference basal rate and a patient-specific daily insulin demand, and the patient-specific reference basal rate and the patient-specific daily insulin demand are determined based on historical delivery information (e.g., the amount of insulin delivered within the first 24 hours) in a previous time interval. The control system 700 also receives or otherwise obtains a current glucose measurement value (e.g., the most recently obtained sensor glucose value) from a sensing arrangement 504 at an input 704. The control system 700 shown implements or otherwise provides a proportional integral derivative (PID) control to determine or otherwise generate a delivery command for operating the motor 532 based at least in part on the difference between the target glucose value and the current glucose measurement. In this regard, the PID control attempts to minimize the difference between the measured value and the target value, and thereby adjusts the measured value to the desired value. The PID control parameters are applied to the difference between the target glucose level at the input 702 and the measured glucose level at the input 704 to generate or otherwise determine the dosage (or delivery) command provided at the output 730. Based on the delivery command, the motor control module 512 operates the motor 532 to deliver insulin to the patient's body to affect the patient's blood glucose level, and thereby reduce the difference between the subsequently measured blood glucose level and the target blood glucose level.

[0094] The illustrated control system 700 includes or otherwise implements a summing block 706 configured to determine the difference between a target value obtained at input 702 and a measured value obtained from the sensing arrangement 504 at input 704, for example, by subtracting the target value from the measured value. The output of the summing block 706 represents the difference between the measured value and the target value, which is then provided to each of the proportional term path, the integral term path, and the derivative term path. The proportional term path includes multiplying the difference by a proportional gain coefficient K P The integral term path includes an integral block 708 that integrates the difference and multiplies the integrated difference by an integral gain coefficient K. I To obtain the integral term gain block 722. The derivative term path includes the derivative block 710 which determines the derivative of the difference and multiplies the derivative of the difference by the derivative gain coefficient K Dto obtain a gain block 724 for the derivative term. The proportional, integral, and derivative terms are then summed or otherwise combined to obtain a delivery command for operating the motor at output 730. Various implementation details related to closed loop PID control and determining gain coefficients are described in more detail in U.S. Pat. No. 7,402,153, which is incorporated by reference.

[0095] In one or more exemplary embodiments, the PID gain factor is patient-specific and is dynamically calculated or otherwise determined before entering the closed-loop operation mode based on historical insulin delivery information (e.g., the amount and / or timing of the previous dose, historical correction bolus information, etc.), historical sensor measurements, historical reference blood glucose measurements, user reports or user-entered events (e.g., meals, exercise, etc.), etc. In this regard, one or more patient-specific control parameters (e.g., insulin sensitivity factor, daily insulin demand, insulin limit, reference basal rate, reference fasting glucose, effective insulin action duration, drug effect time constant, etc.) can be used to compensate, correct or otherwise adjust the PID gain factor to account for the various operating conditions experienced and / or exhibited by the infusion device 502. The PID gain factor can be maintained by a memory 606 accessible to the pump control module 602. In this regard, the memory 606 can include a plurality of registers associated with control parameters for PID control. For example, a first parameter register may store a target glucose value and be accessed by or otherwise coupled to the summing block 706 at input 702, and similarly, a second parameter register accessed by the proportional gain block 720 may store a proportional gain coefficient, a third parameter register accessed by the integral gain block 722 may store an integral gain coefficient, and a fourth parameter register accessed by the derivative gain block 724 may store a derivative gain coefficient.

[0096] In one or more exemplary embodiments, one or more parameters of the closed-loop control system 700 are automatically adjusted or adapted in a personalized manner to account for potential changes in the patient's glucose level or insulin sensitivity due to meals, exercise, or other events or activities. For example, in one or more embodiments, the target glucose value can be reduced before the predicted meal event to achieve an increase in the insulin infusion rate to effectively pre-push the meal, thereby reducing the possibility of postprandial hyperglycemia. Additionally or alternatively, the time constant or gain coefficient associated with one or more paths of the closed-loop control system 700 can be adjusted to adjust the response to the deviation between the measured glucose value and the target glucose value. For example, based on the specific type of meal being consumed or the specific time of the day when the meal is consumed, the time constant associated with the derivative block 710 or the derivative term path can be adjusted to make the closed-loop control more or less active in response to the patient's elevated blood glucose level based on the patient's historical blood glucose response to a specific type of meal.

[0097] Figure 8 An exemplary embodiment of a patient monitoring system 800 is depicted. The patient monitoring system 800 includes a medical device 802 that is communicatively coupled to a sensing element 804 that is inserted into a patient's body or otherwise worn by the patient to obtain measurement data (such as a sensed glucose level) indicative of a physiological condition in the patient's body. The medical device 802 is communicatively coupled to a client device 806 via a communication network 810, wherein the client device 806 is communicatively coupled to a remote device 814 via another communication network 812. In this regard, the client device 806 can act as a means for uploading or otherwise providing measurement data from the medical device 802 to the remote device 814. It should be understood that for purposes of explanation, Figure 8 A simplified representation of patient monitoring system 800 is depicted and is not intended to limit the subject matter described herein in any way.

[0098] In an exemplary embodiment, the client device 806 is implemented as a mobile phone, a smart phone, a tablet computer or other similar mobile electronic device, however, in other embodiments, the client device 806 can be implemented as any type of electronic device that can communicate with the medical device 802 through the network 810, such as a laptop or notebook computer, a desktop computer, etc. In an exemplary embodiment, the network 810 is implemented as a Bluetooth network, a ZigBee network or another suitable personal area network. That is, in other embodiments, the network 810 can be implemented as a wireless ad hoc network, a wireless local area network (WLAN) or a local area network (LAN). The client device 806 includes or is coupled to a display device that can graphically present data and / or information related to the patient's physiological condition, such as a monitor, a screen or another conventional electronic display. The client device 806 also includes a user input device (such as a keyboard, a mouse, a touch screen, etc.) that can receive input data and / or other information from a user of the client device 806 or is associated with the user input device.

[0099] In an exemplary embodiment, a user (e.g., a patient, a patient's doctor, or another healthcare provider, etc.) manipulates a client device 806 to execute a client application 808 that supports communication with a medical device 802 via a network 810. In this regard, the client application 808 supports establishing a communication session with the medical device 802 over the network 810 and receiving data and / or information from the medical device 802 via the communication session. The medical device 802 may similarly execute or otherwise implement a corresponding application or process that supports establishing a communication session with the client application 808. The client application 808 generally represents a software module or another feature generated or otherwise implemented by the client device 806 to support the processes described herein. Therefore, the client device 806 generally includes a processing system and a data storage element (or memory) capable of storing programming instructions executed by the processing system, which, when read and executed, causes the processing system to create, generate, or otherwise facilitate the client application 808 and perform or otherwise support the processes, tasks, operations, and / or functions described herein. Depending on the embodiment, the processing system may be implemented using any suitable processing system and / or device (e.g., one or more processor devices, central processing units (CPUs), controllers, microprocessors, microcontrollers, processing cores, and / or other hardware computing resources) configured to support the operations of the processing system described herein. Similarly, the data storage element or memory may be implemented as a random access memory (RAM), a read-only memory (ROM), flash memory, magnetic or optical mass storage, or any other suitable non-transitory short-term or long-term data storage or other computer-readable medium and / or any suitable combination thereof.

[0100] In one or more embodiments, the client device 806 and the medical device 802 establish an association (or pairing) with each other through the network 810 to support the subsequent establishment of a point-to-point or peer-to-peer communication session between the medical device 802 and the client device 806 through the network 810. For example, according to some embodiments, the network 810 is implemented as a Bluetooth network, wherein the medical device 802 and the client device 806 are paired with each other by performing a discovery procedure or other suitable pairing procedure (e.g., by obtaining and storing each other's network identification information). The pairing information obtained during the discovery procedure allows the medical device 802 or the client device 806 to initiate the establishment of a secure communication session through the network 810.

[0101] In one or more exemplary embodiments, the client application 808 is also configured to store or otherwise maintain the address and / or other identification information of the remote device 814 on the second network 812. In this regard, the second network 812 can be physically and / or logically different from the network 810, such as the Internet, a cellular network, a wide area network (WAN), etc. The remote device 814 generally represents a server or other computing device configured to receive and analyze or otherwise monitor the measurement data, event log data, and potential other information obtained for the patient associated with the medical device 802. In an exemplary embodiment, the remote device 814 is coupled to a database 816 configured to store or otherwise maintain data associated with a separate patient. In practice, the remote device 814 can reside at a physically different and / or separate location from the medical device 802 and the client device 806, such as at a facility owned and / or operated by the manufacturer of the medical device 802 or otherwise affiliated with the manufacturer. For the purpose of explanation but not limitation, the remote device 814 is alternatively referred to as a server in this article.

[0102] Still refer to Figure 8 , sensing element 804 generally represents a component of patient monitoring system 800 that is configured to generate, produce, or otherwise output one or more electrical signals indicative of a physiological condition sensed, measured, or otherwise quantified by sensing element 804. In this regard, the patient's physiological condition affects the characteristics of the electrical signal output by sensing element 804, such that the characteristics of the output signal correspond to or are otherwise related to the physiological condition to which sensing element 804 is sensitive. In an exemplary embodiment, sensing element 804 is implemented as an interstitial glucose sensing element inserted at a location on the patient's body, the interstitial glucose sensing element generating an output electrical signal having a current (or voltage) associated with the interstitial glucose sensing element that is related to the interstitial fluid glucose level sensed or otherwise measured by sensing element 804 in the patient's body.

[0103] The medical device 802 generally represents a component of the patient monitoring system 800 that is communicatively coupled to the output of the sensing element 804 to receive or otherwise obtain measurement data samples (e.g., measured blood glucose and characteristic impedance values) from the sensing element 804, store or otherwise maintain the measurement data samples, and upload or otherwise transmit the measurement data to a remote device 814 or a server via a client device 806. In one or more embodiments, the medical device 802 is implemented as an infusion device 102, 200, 502 configured to deliver a fluid (such as insulin) to a patient's body. That is, in other embodiments, the medical device 802 can be an independent sensing or monitoring device (e.g., a sensing arrangement 104, 504) that is separate and independent from the infusion device. It should be noted that although Figure 8 While medical device 802 and sensing element 804 are depicted as separate components, in practice medical device 802 and sensing element 804 may be integrated or otherwise combined to provide an integral device that may be worn by a patient.

[0104] In an exemplary embodiment, the medical device 802 includes a control module 822, a data storage element 824 (or memory) and a communication interface 826. The control module 822 generally represents the hardware, circuit system, logic, firmware and / or one or more other components of the medical device 802 that are coupled to the sensing element 804 to receive the electrical signal output by the sensing element 804 and perform or otherwise support various other tasks, operations, functions and / or processes described herein. Depending on the embodiment, the control module 822 can be implemented or realized with a general processor device, a microprocessor device, a controller, a microcontroller, a state machine, a content addressable memory, an application specific integrated circuit, a field programmable gate array, any suitable programmable logic device, a discrete gate or transistor logic, a discrete hardware component or any combination thereof designed to perform the functions described herein. In some embodiments, the control module 822 includes an analog-to-digital converter (ADC) or another similar sampling arrangement that samples the output electrical signal received from the sensing element 804 or otherwise converts it into a corresponding digital measurement data value. In other embodiments, the sensing element 804 can be combined with an ADC and output a digital measurement value.

[0105] The communication interface 826 generally represents the hardware, circuitry, logic, firmware, and / or other components of the medical device 802 that are coupled to the control module 822 to output data and / or information from the medical device 802 to / from the client device 806. For example, the communication interface 826 may include or otherwise be coupled to one or more transceiver modules capable of supporting wireless communication between the medical device 802 and the client device 806. In an exemplary embodiment, the communication interface 826 is implemented as a Bluetooth transceiver or adapter configured to support Bluetooth Low Energy (BLE) communications.

[0106] In an exemplary embodiment, the remote device 814 receives measurement data values ​​(e.g., sensor glucose measurements, acceleration measurements, etc.) associated with a particular patient obtained using the sensing element 804 from the client device 806, and the remote device 814 stores or otherwise maintains the historical measurement data in association with the patient in a database 816 (e.g., using one or more unique patient identifiers). In addition, the remote device 814 may also receive meal data or other event log data that may be input or otherwise provided by the patient (e.g., through the client application 808) from the client device 806 or through the client device and store or otherwise maintain the historical meal data and other historical events or activity data associated with the patient in the database 816. In this regard, the meal data includes, for example, a time or timestamp associated with a particular meal event, a meal type, or other information indicating the content or nutritional characteristics of the meal, and an indication of the size associated with the meal. In an exemplary embodiment, the remote device 814 also receives historical fluid delivery data corresponding to a basic dose or a bolus dose of fluid delivered to the patient by the infusion device 102, 200, 502. For example, client application 808 can communicate with infusion device 102,200,502 to obtain the amount of insulin delivery dose and corresponding timestamp from infusion device 102,200,502, and then upload insulin delivery data to remote device 814 for storage associated with specific patient. Remote device 814 can also receive geographic location data and potential other relevant data associated with device 802,806 from client device 806 and / or client application 808, and store or otherwise maintain historical operation background data associated with specific patient. In this regard, one or more of device 802,806 can include a global positioning system (GPS) receiver or similar module, component or circuit system that can output or otherwise provide data that characterizes the geographic location of corresponding device 802,806 in real time.

[0107] The historical patient data can be analyzed by one or more of the remote device 814, the client device 806 and / or the medical device 802 to change or adjust the operation of the infusion device 102, 200, 502 to affect the fluid delivery in a personalized manner. For example, the patient's historical meal data and corresponding measurement data or other relevant data can be analyzed to predict the future time when the patient may consume the next meal, the possibility of future meal events within a specific time period, the possible size or amount of carbohydrates associated with future meals, the possible type or nutritional content of future meals, and / or the like. In addition, the patient's historical measurement data of the post-meal period after the historical meal event can be analyzed to model or otherwise characterize the patient's blood glucose response to the predicted size and type of meals in the current context (e.g., time of day, day of the week, geographic location). Then, one or more aspects of the infusion device 102, 200, 502 that controls or regulates insulin delivery can be modified or adjusted to actively interpret the patient's possible meal activities and blood glucose responses.

[0108] In one or more exemplary embodiments, the remote device 814 utilizes machine learning to determine which combination of historical sensor glucose measurement data, historical delivery data, historical auxiliary measurement data (e.g., historical acceleration measurement data, historical heart rate measurement data, and / or the like), historical event log data, historical geographic location data, and other historical or related data is associated with or predicts the occurrence of a particular event, activity, or metric for a particular patient, and then determines a corresponding equation, function, or model for calculating the value of the parameter of interest based on the set of input variables. Thus, the model is able to characterize or map a particular combination of one or more of the current (or recent) sensor glucose measurement data, auxiliary measurement data, delivery data, geographic location, patient behavior or activity, etc., to a value representing the current probability or likelihood of a particular event or activity or the current value of the parameter of interest. It should be noted that since each patient's physiological response may differ from the rest of the patients in the population, the subset of input variables predicted for or associated with a particular patient may differ from other patients. In addition, based on the different correlations between the particular input variables and the historical data of the particular patient, the relative weighting of the corresponding variables applied to the prediction subset may also differ from other patients who may have the same prediction subset. It should be noted that the remote device 814 can utilize any number of different machine learning techniques to determine which input variables are predictive for the patient currently of interest, such as artificial neural networks, genetic programming, support vector machines, Bayesian networks, probabilistic machine learning models or other combinations of Bayesian techniques, fuzzy logic, heuristic deduction, etc.

[0109] The insulin infusion device may incorporate or utilize control algorithms, processing schemes, and operating methods of the type described in U.S. Patent No. 9,526,834 and International (PCT) Patent Publication No. WO 2014 / 035570 (or appropriately modified, updated, or customized versions thereof); the contents of these publications are incorporated herein by reference.

[0110] Reference above Figure 1-8 Each device or component described may be implemented as a computer-based or processor-based component. Fig. 9 Describes an exemplary embodiment of a computer-based or processor-based device 900 that is suitable for deployment in Figure 1-8 A simplified block diagram representation of an exemplary embodiment of a computer-based or processor-based device 900 in the illustrated system. Fig. 9 The described computer-based or processor-based device 900 may also be used to implement a system 1000 including an estimation model 1040 for estimating glucose values, as will be described below with reference to Figure 10-12 Described.

[0111] The illustrated embodiment of device 900 is intended as a high-level and generalized representation of a suitable platform. In this regard, any of the computer-based or processor-based components of system 100 can utilize the architecture of device 900. The illustrated embodiment of device 900 generally includes, but is not limited to: at least one processor 902; an appropriate amount of memory 904; device-specific hardware, software, firmware and / or features 906; a user interface 908; a communication module 910; and a display element 912. Of course, an implementation of device 900 may include additional elements, components, modules, and functions configured to support various features unrelated to the subject matter described herein. For example, device 900 may include certain features and elements to support conventional functions that may be related to a specific implementation and deployment of device 900. In practice, the elements of device 900 may be coupled together via a bus or any suitable interconnect architecture 914.

[0112] The processor 902 may be implemented or executed using a general purpose processor, a content addressable memory, a digital signal processor, an application specific integrated circuit, a field programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. In addition, the processor 902 may be implemented as a combination of computing devices, for example, a combination of a digital signal processor and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a digital signal processor core, or any other such configuration.

[0113] The memory 904 can be implemented as a RAM memory, a flash memory, an EPROM memory, an EEPROM memory, a register, a hard disk, a removable disk, a CD-ROM or any other form of storage medium known in the art. In this regard, the memory 904 can be coupled to the processor 902 so that the processor 902 can read information from the memory 904 and write information to the memory 904. In an alternative, the memory 904 can be integrated with the processor 902. As an example, the processor 902 and the memory 904 can reside in an ASIC. At least a portion of the memory 904 can be implemented as a computer storage medium, for example, a tangible computer-readable medium having computer executable instructions stored thereon. When read and executed by the processor 902, the computer executable instructions cause the device 900 to perform certain tasks, operations, functions and processes specific to a particular embodiment. In this regard, the memory 904 can represent a suitable implementation of such a computer-readable medium. Alternatively or additionally, device 900 may receive and cooperate with computer-readable media (not separately shown) implemented as a portable or mobile component or platform, such as a portable hard drive, USB flash drive, optical disk, or the like.

[0114] The device-specific hardware, software, firmware, and features 906 may vary from one embodiment of the device 900 to another. For example, the device-specific hardware, software, firmware, and features 906 will support: smartphone functions and features when the device 900 is implemented as a mobile phone; conventional personal computer functions and features if the device 900 is implemented as a laptop or tablet computer; insulin pump operations when the device 900 is implemented as an insulin infusion device, etc. In practice, some parts or aspects of the device-specific hardware, software, firmware, and features 906 may be implemented in different embodiments. Fig. 9 is implemented in one or more other blocks depicted.

[0115] The user interface 908 may include or cooperate with various features to allow a user to interact with the device 900. Thus, the user interface 908 may include various human-machine interfaces, such as keypads, keys, keyboards, buttons, switches, knobs, touch pads, joysticks, pointing devices, virtual tablets, touch screens, microphones, or any device, component, or function that enables a user to select options, input information, or otherwise control the operation of the device 900. The user interface 908 may include one or more graphical user interface (GUI) control elements that enable a user to manipulate or otherwise interact with an application via the display element 912.

[0116] The communication module 910 facilitates data communication between the device 900 and other components as needed during operation of the device 900. In the context of the present specification, the communication module 910 can be used to send or stream control data related to the device, data related to the patient, status or operation data related to the device, blood glucose understanding messages and notifications, etc. It should be understood that the specific configuration and functionality of the communication module 910 can vary depending on the hardware platform and specific implementation of the device 900. In fact, embodiments of the device 900 can use various data communication protocols to support wireless data communication and / or wired data communication. For example, the communication module 910 may support one or more wireless data communication protocols, technologies, or methods, including, but not limited to: RF; IrDA (infrared); Bluetooth; ZigBee (and other variations of the IEEE 802.15 protocol); IEEE 802.11 (any variation); IEEE 802.16 (WiMAX or any other variation); direct sequence spread spectrum; frequency hopping spread spectrum; cellular / wireless / cordless telecommunication protocols; wireless home network communication protocols; paging network protocols; magnetic induction; satellite data communication protocols; wireless hospital or healthcare facility network protocols, such as those operating in the WMTS frequency band; GPRS; and proprietary wireless data communication protocols, such as variations of wireless USB. In addition, the communication module 910 may support one or more wired / cable data communication protocols, including, but not limited to: Ethernet; power line; home network communication protocols; USB; IEEE 1394 (Firewire); hospital network communication protocols; and proprietary data communication protocols.

[0117] Display element 912 is suitably configured to enable device 900 to present and display various screens, understand messages, notifications, GUI, GUI control elements, drop-down menus, auto-fill fields, text input fields and message fields, etc. Of course, as is well known, display element 912 can also be used to display other information during the operation of device 900. It should be noted that the specific configuration, operating characteristics, size, resolution and function of display element 910 can change according to the actual implementation of device 900. For example, if device 900 is a laptop computer, display element 912 can be a relatively large monitor. Alternatively, if device 900 is a cellular phone device, display element 912 can be a relatively small integrated display screen, such as a touch-sensitive screen.

[0118] Fig.10 1 is a block diagram of a system 1000 for estimating a glucose value for a particular user or patient according to the disclosed embodiments; the system 1000 includes an estimation model 1040 configured to receive various inputs 1010, 1020, 1030. The estimation model 1040 can be executed at a processing system. The processing system can be implemented on any device described herein, including the devices described above with reference to FIG. Figure 1-8Those devices shown and described, and more generally at a computer-based or processor-based device 900, such as the one described above with reference to Fig. 9 The apparatus shown and described. For example, the processing system may be implemented as follows: At a backend server system, e.g. Figure 8 The remote device 814, in Figure 8 At a client device 806 (e.g., a patient's smartphone), Figure 8 Medical device 802 (e.g., Figure 5 insulin infusion device 502) or other terminal device, such as auxiliary sensing arrangement 506 (or activity tracking device, ring, necklace, vest, etc.) and Figure 5 Thus, in some embodiments, the processing system may be implemented at a backend server system, such as Figure 8 remote device 814. For example, the estimation model can be executed or run as part of a web application at a back-end server system, which can then transmit the estimated glucose value to a client device (e.g., a patient's smartphone), an insulin infusion device, or other terminal device. In another embodiment, the processing system can be implemented at the client device and the estimation model can be executed as part of a mobile application at the client device. In another embodiment, the processing system can be implemented at the insulin infusion device and the estimation model can be executed as part of an application at the insulin infusion device.

[0119] In one non-limiting embodiment, the inputs include discrete glucose measurements 1010 from a blood glucose meter (BGM), relevant activity data 1020 from an activity tracker or equivalent source of activity data (e.g., a smartphone or other health-related device), and optionally relevant data 1030 from other sources. The relevant activity data 1020 collected from an activity tracker or equivalent source of activity data (e.g., a smartphone or other health-related device) may include, for example, one or more of the following: metabolic data about the patient (e.g., calories burned); physical activity data about the user (e.g., heart rate data of the patient, exercise data of the patient, activity type, duration and intensity data, data about the number of steps taken by the patient over a period of time, metabolic equivalents, and other parameters); data from a fitness or exercise advisor device or application that provides fitness / exercise advice or recommendations to the user; and other raw relevant data, such as accelerometer (x, y, z) data, geolocation data, iBeacon location data, skin temperature data, ambient air temperature data, bioimpedance heart rate data, sweat data (e.g., GSR conductance), blood pressure data, shake detection data, pedometer data, barometer data, gyroscope data, meal log data, orientation (azimuth, pitch, roll (degrees)) data; health kit data (e.g., from Apple® Healthkit, Google® Fit, etc.), medication / prescription information data, user gesture data, UV detector data, magnetometer data, respiration data, muscle activity data, pulse oximeter data, blood+interstitial fluid pH data, metabolic equivalent (METS) data, sleep quality / time data, EMR and laboratory data, etc. Related data 1030 from other sources may include, for example, historical sensor glucose measurement data, historical delivery data, historical auxiliary measurement data such as historical acceleration measurement data, historical heart rate measurement data, skin conductivity, etc., historical event log data, historical geolocation data, and other historical or related data related to or predicting the occurrence of specific events, activities, or indicators for a specific patient. The estimation model 1040 processes at least some of the various inputs to continuously generate an estimated glucose value 1080.

[0120] In one or more exemplary embodiments, Figure 8 The remote device 814 uses machine learning to generate a Figure 5The machine learning model 1060 may be a discrete glucose measurement 1010 of a blood glucose meter 530 (e.g., a blood glucose meter 530) from an auxiliary sensing arrangement 506 (e.g., from an "activity tracker" or equivalent source of activity data) to determine related activity data 1020, and optionally related data 1030 from other sources, to generate a continuous estimated glucose value 1080. According to an embodiment, the machine learning model 1060 may be a corresponding equation, function, or model for calculating the estimated glucose value 1080 based on a set of input variables. Thus, the machine learning model 1060 is capable of characterizing or mapping a particular combination of inputs to a value representing the estimated glucose value 1080.

[0121] Artificial intelligence is a field of computer science that emphasizes the creation of intelligent machines that work and react like humans. Some of the active computers with artificial intelligence are designed to include learning. Examples of artificial intelligence algorithms include but are not limited to critical learning, actor-critic method, reinforcement, deep deterministic policy gradient (DDPG), multi-agent deep deterministic policy gradient (MADDPG), etc. Machine learning refers to the discipline of artificial intelligence that changes with the technological development of human knowledge.

[0122] Machine learning promotes the continuous advancement of computing by exposing to new scenarios, testing and adapting, while employing pattern and trend detection to improve decisions and subsequent (although not identical) situations. Machine learning (ML) algorithms and statistical models can be used by computer systems to efficiently perform specific tasks without the use of explicit instructions, but instead relying on patterns and reasoning. Machine learning algorithms build mathematical models based on sample data (called "training data") to make predictions or decisions without being explicitly programmed to perform tasks. Machine learning algorithms can be used when it is not feasible to develop algorithms for specific instructions to perform a task.

[0123] For example, supervised learning algorithms establish a mathematical model of a set of data containing both input and expected output. The data is called training data and consists of a set of training instances. Each training instance has one or more inputs and expected outputs (also referred to as supervisory signals). In the case of semi-supervised learning algorithms, some training instances in the training instances lack expected outputs. In the mathematical model, each training instance is represented by an array or vector, and the training data is represented by a matrix. Through iterative optimization of the objective function, supervised learning algorithms learn functions that can be used to predict outputs associated with new inputs. The optimization function will allow the algorithm to correctly determine the output of inputs that are not part of the training data. It is said that algorithms that improve the accuracy of their outputs or predictions over time have learned to perform the tasks. Supervised learning algorithms include classification and regression. Classification algorithms are used when the output is limited to a set of finite values, and regression algorithms are used when the output may have any numerical value within a range. Similarity learning belongs to the field of supervised machine learning that is closely related to regression and classification, but the goal is to use a similarity function that measures the similarity or degree of correlation of two objects to learn from instances.

[0124] Reinforcement learning is a field of machine learning that is concerned with some notion of how software agents should act in an environment to maximize cumulative rewards. Due to its generality, the field is studied in many other disciplines, such as game theory, control theory, operations research, information theory, simulation-based optimization, multi-agent systems, swarm intelligence, statistics, and genetic algorithms. In machine learning, the environment is usually represented as a Markov decision process (MDP). Many reinforcement learning algorithms use dynamic programming techniques. Reinforcement learning algorithms do not assume that an exact mathematical model of the MDP is common sense and are used when an exact model is not feasible.

[0125] According to one non-limiting embodiment, the estimation model 1040 can be an integrated model 1050. The integrated model 1050 includes two or more related but different analytical models that are run or executed simultaneously, where the results generated by each can then be synthesized into a single score or spread to improve the accuracy of the predictive analysis. To further explain, in predictive modeling and other types of data analysis, a single model based on one data sample may have biases, high variability, or complete inaccuracies that may affect the reliability of its analytical findings. By combining different models or analyzing multiple samples, the impact of these limitations can be reduced to provide better information. In this way, the integrated method can use multiple machine learning algorithms to obtain better predictive performance than can be obtained from any constituent learning algorithm alone.

[0126] An ensemble is a supervised learning algorithm because it can be trained and then used to make predictions. Thus, a trained ensemble represents a single hypothesis that is not necessarily contained within the hypothesis space of the model built from it. Thus, an ensemble can show greater flexibility in the functions it can represent. An ensemble model can contain a group of individually trained classifiers (such as neural networks or decision trees) whose predictions are combined.

[0127] For example, a common example of integrated modeling is the random forest model, which is an analytical model that utilizes multiple decision trees and is intended to predict results based on different variables and rules. The random forest model integrates decision trees that can analyze different sample data, evaluate different factors, or weight common variables differently. The results of each decision tree are then converted into a simple average or aggregated by further weighting. The emergence of Hadoop and other big data technologies allows for the storage and analysis of larger amounts of data, which allows analytical models to be run on different data samples.

[0128] In some embodiments, the integrated model 1050 may include or be constructed using at least one machine learning model 1060 and a physiological model 1070. The physiological model 1070 may be, for example, a population-based model of one or more equations (e.g., a set of differential equations) that are generally applicable to any patient, but have different variables or parameters weighted according to the individual parameters of a specific patient to simulate the physiological functions of that patient. In other words, because each patient's physiological responses may be different from the rest of the population, the relative weights of the various variables applied to the physiological model 1070 may also be different from other patients. The physiological model 1070 can be combined with the machine learning model 1060 to help constrain the estimates or predictions to a realistic range.

[0129] Depending on the implementation, any number of machine learning models may be combined to optimize the ensemble model 1050. Examples of machine learning algorithms or models that may be implemented at the machine learning model 1060 may include, but are not limited to, regression models such as linear regression, logistic regression, and K-means clustering; one or more decision tree models (e.g., random forest models); one or more support vector machines; one or more artificial neural networks; one or more deep learning networks (e.g., at least one recursive neural network, sequence-to-sequence mapping using deep learning, sequence encoding using deep learning, etc.); models based on fuzzy logic; genetic programming models; Bayesian networks or other Bayesian techniques; probabilistic machine learning models; Gaussian processing models; Hidden Markov models; time series methods such as autoregressive moving average (ARMA) models, autoregressive integrated moving average (ARIMA) models, autoregressive conditional heteroskedasticity (ARCH) models; generalized autoregressive conditional heteroskedasticity (GARCH) models; moving average (MA) models or other models; and combinations of heuristic derivations of any of the above, etc. Types of machine learning algorithms differ in their approach, the type of data they input and output, and the type of task or problem they are intended to solve.

[0130] Hidden Markov Models (HMMs) are statistical Markov models in which the system being modeled is assumed to be a Markov process with unobserved (hidden) states. HMMs can be viewed as the simplest dynamic Bayesian networks. A Bayesian network, belief network, or directed acyclic graph model is a probabilistic graphical model that represents a set of random variables and their conditional independence with a directed acyclic graph (DAG). Bayesian networks that model sequences of variables are called dynamic Bayesian networks. A generalization of Bayesian networks that can represent and solve decision problems under uncertainty is called an influence diagram.

[0131] Support vector machines (SVMs), also known as support vector networks, are a group of related supervised learning methods for classification and regression. Given a set of training examples, each labeled as belonging to one of two categories, the SVM training algorithm builds a model that predicts whether a new example belongs to one category or the other. The SVM training algorithm is a non-probabilistic binary linear classifier. In addition to performing linear classification, SVMs can also perform nonlinear classification efficiently using the so-called kernel trick, implicitly mapping their inputs into a high-dimensional feature space.

[0132] Decision tree learning uses decision trees as predictive models to go from observations of terms (represented in branches) to conclusions about target values ​​for the terms (represented in leaves). Tree models where the target variable can take a set of discrete values ​​are called classification trees; in these tree structures, the leaves represent class labels and the branches represent the combination of features that lead to the class labels. Decision trees where the target variable can take continuous values ​​(usually real numbers) are called regression trees. In decision analysis, decision trees can be used to visually and explicitly represent decisions and decision making.

[0133] A deep learning algorithm may refer to a collection of algorithms used in machine learning, which is used to model high-level abstractions and data using a model architecture consisting of multiple nonlinear transformations. Deep learning is a specific method for building and training neural networks. Deep learning consists of multiple hidden layers in an artificial neural network. Examples of deep learning algorithms may include, for example, twin networks, transfer learning, recursive neural networks (RNNs), long short-term memory (LSTM) networks, convolutional neural networks (CNNs), transformers, etc. For example, deep learning methods may utilize autoregressive recursive neural networks (RNNs), such as long short-term memory (LSTM) and gated recursive units (GRUs). A neural network architecture for time series prediction using RNNs (and variants) is an autoregressive seq2seq neural network architecture, which acts as an autoencoder.

[0134] In some embodiments, the ensemble model 1050 may include one or more deep learning algorithms. It should be noted that any number of different machine learning techniques may also be used. Depending on the implementation, the ensemble model 1050 may be implemented as a bootstrap aggregation ensemble algorithm (also known as a bagging classifier method), an enhanced ensemble algorithm or classifier algorithm, a stacked ensemble algorithm or classifier algorithm, a model bucket ensemble algorithm, a Bayesian optimization classifier algorithm, a Bayesian parameter averaging algorithm, a Bayesian model combination algorithm, etc.

[0135] Bootstrapping (often referred to as bagging) involves making each model in the ensemble vote with equal weight. To improve model variance, bagging trains each model in the ensemble using a randomly drawn subset of the training set. As an example, the random forest algorithm combines random decision trees with bagging to achieve very high classification accuracy. A bagged classifier or ensemble method creates individuals for its ensemble by training each classifier on a random redistribution of the training set. The training set for each classifier can be generated by randomly drawing (with replacement) N instances (where N is the size of the original training set); many of the original instances may be repeated in the resulting training set, while others may be excluded. Each individual classifier in the ensemble is generated with a different random sampling of the training set. Bagging is effective for "unstable" learning algorithms (e.g., neural networks and decision trees) in which small changes in the training set can lead to large changes in predictions.

[0136] In contrast, boosting involves incrementally building an ensemble by training each new model instance to emphasize training instances that were misclassified by the previous model. In some cases, boosting has been shown to produce better accuracy than bagging, but it also tends to be more likely to overfit the training data. A boosted classifier may refer to a family of methods that can be used to produce a series of classifiers. The training set for each member of the series is selected based on the performance of one or more earlier classifiers in the series. In boosting, instances that are incorrectly predicted by previous classifiers in the series are more selected than instances that are correctly predicted. Thus, boosting attempts to produce new classifiers that are better able to predict poorly performing instances of the current ensemble. Although some newer algorithms are reported to achieve better results, a common implementation of boosting is Adaboost.

[0137] Stacking (sometimes referred to as stacked generalization) involves training a learning algorithm to combine the predictions of several other learning algorithms. Stacking works in two stages: using multiple base classifiers to predict the class, and then using new learners to combine their predictions with the goal of reducing generalization error. First, all other algorithms are trained using available data, and then the combiner algorithm is trained to use all the predictions of the other algorithms as additional inputs for the final prediction. If any combiner algorithm is used, then in theory, stacking can represent any of the ensemble techniques described in this article, although in practice, logistic regression models are often used as combiners.

[0138] "Model bucketing" is an ensemble technique in which a model selection algorithm is used to select the best model for each problem. When tested on only one problem, a model bucket may produce results that are no better than those produced by the best model in the set, but when evaluated across many problems, on average, the results it produces are usually better than those produced by any model in the set. A common method for model selection is cross-validation selection (sometimes referred to as a "bake-off contest"). Cross-validation selection can be summarized as trying all models in the training set and then picking the most effective model. Gating is a generalization of cross-validation selection. It involves training another learning model to decide which models in the bucket that are best suited to solve the problem. Typically, perceptrons are used for gating models. It can be used to select the "best" model, or it can be used to give linear weights to predictions from each model in the bucket. When there are many problems using model buckets, it may be desirable to avoid training some models that take a long time to train. Feature point learning is a meta-learning method that seeks to solve this problem. It involves training only the fast (but inaccurate) algorithms in a bucket, and then using the performance of those algorithms to help determine which slow (but accurate) algorithm is most likely to do the best.

[0139] The Bayesian optimization classifier is a classification technique. It is an integration of all hypotheses in the hypothesis space. On average, no other integration can outperform the Bayesian optimization classifier. The naive Bayesian optimization classifier is a version of this Bayesian optimization classifier, which assumes that the data is conditionally independent of the class and makes the calculation more feasible. If the hypothesis is true, each hypothesis is voted, and the vote is proportional to the possibility that the training data set will be sampled from the system. In order to facilitate training data of limited size, the vote of each hypothesis is also multiplied by the prior probability of the hypothesis. However, the hypothesis represented by the Bayesian optimization classifier is an optimized hypothesis in the integration space (the space of all possible integrations).

[0140] Bayesian parameter averaging (BPA) is an ensemble technique that seeks to approximate a Bayesian optimization classifier by sampling hypotheses from the hypothesis space and combining the hypotheses using Bayes' theorem. Unlike the Bayesian optimization classifier, Bayesian model averaging (BMA) can be implemented practically. Hypotheses are usually sampled using Monte Carlo sampling techniques (such as MCMC). For example, Gibbs sampling can be used to derive hypotheses representing distributions. It has been shown that in some cases, when hypotheses are derived in this way and averaged according to Bayes' theorem, the expected error of this technique must be at most twice the expected error of the Bayesian optimization classifier.

[0141] Bayesian model combination (BMC) is an algorithmic correction to Bayesian model averaging (BMA). It does not sample each model in the ensemble individually, but samples from the space of possible ensembles (where model weights are randomly derived from a Dirichlet distribution with uniform parameters). This modification overcomes the tendency of BMA to give all weights to a single model. Although BMC is slightly more expensive than BMA in terms of calculation, it tends to produce significantly better results. It has been shown that the results from BMC are better on average (with statistical significance) than BMA and bagging. Using Bayes' law to calculate model weights requires calculating the probability of the data given to each model. Usually, all models in the ensemble are not exactly the distribution from which the training data is generated, so all models correctly receive a value close to zero for this term. If the ensemble is large enough to sample the entire model space, this will be effective, but this situation is almost impossible. Therefore, each pattern in the training data will shift the ensemble weight toward the model in the ensemble that is closest to the distribution of the training data. It essentially reduces the unnecessary complex methods for model selection. The possible weights of the ensemble can be visualized as depending on the simplex. At each vertex of the simplex, all weights are given to a single model in the ensemble. BMA converges towards the vertex that is closest to the distribution of the training data. In contrast, BMC converges towards the point where this distribution is projected onto the simplex. In other words, instead of selecting one model that is closest to the generating distribution, it looks for a combination of models that is closest to the generating distribution. The results from BMA can usually be estimated by selecting the best model from the model bucket using cross-validation. Similarly, the results from BMC can be estimated by selecting the best ensemble combination from a random sampling of possible weights using cross-validation.

[0142] Fig.11 1 is a flow chart illustrating a method 1100 for generating an estimation model for a particular patient according to the disclosed embodiments. The method 1100 begins at 1110, where a computing system trains a plurality of generic estimation models. Each generic estimation model can model a particular group of users. At 1120, the computing system tests the generic estimation model, and then at 1130, the computing system validates the generic estimation model. For example, in some embodiments, the computing system can train a plurality of population-based models for type 1 and type 2 patients using different combinations of demographic parameters such as age, gender, location, and diabetes history such as diabetes onset, years of insulin therapy, type of therapy using existing BG, insulin, dietary information, activity data from an activity tracker, and CGM data to train, test, and validate the models.

[0143] Once all generic estimation models have been validated, method 1100 proceeds to 1140, where the computing system determines, based on the characteristics of the particular user or patient, an applicable generic estimation model that best fits the particular patient based on the characteristics of the particular patient. The particular generic estimation model applicable to the particular patient varies based on the characteristics of the particular patient.

[0144] At 1150, the computing system may then update the specific generic estimation model deployed at 1140 based on the data collected for the specific patient to generate an estimation model for the specific patient. In other words, based on the data collected for the specific patient, the parameters of the generic estimation model selected and deployed at 1140 may be updated and fine-tuned at 150 to customize the generic estimation model so that it becomes the estimation model for the specific patient.

[0145] After the estimation model for the particular patient is generated at 1150, the model can be executed and updated at any time when new data is received for the patient. For example, in some embodiments, the new data can come from blood glucose meter data (e.g., new blood glucose measurements), new relevant activity data for the patient received from an activity tracker, and / or new relevant activity data for the patient received from other sources. In one implementation, the estimation model for the particular patient can be updated whenever there is new data from the BGM. In another embodiment, the new data can come from a continuous glucose monitor. For example, CGM can be used from time to time to collect CGM data for a particular patient for a particular time period (e.g., two weeks), and then the newly collected CGM data can be used to evaluate the performance of the estimation model and / or update or retrain the estimation model for the particular patient. In addition, CGM data can also be used to train and update the general estimation model described above with reference to step 1110. In addition, in some embodiments, CGM data can also be used at 1140 to select and deploy one of the different general estimation models for a particular patient.

[0146] Thus, at 1160, the computing system periodically determines whether new data has been received, and if so, the method proceeds to 1170, where the estimation model for the particular patient is updated based on the new data to generate an updated estimation model, which can be executed in the processing system (as described below).

[0147] After updating the estimation model for the particular patient based on the new data at 1170, the method loops back to 1160. As the estimation model for the particular patient is updated, it becomes more fine-tuned and can be used to generate a better estimated glucose value for the patient. At any time, the estimation model can be used to estimate the glucose value for the patient. Fig.12 A non-limiting embodiment is described in which an estimation model is used to estimate a patient's glucose value.

[0148] Fig.1212 is a flow chart of method 1200 according to the disclosed embodiment. At 1210, the processing system may receive intermittent glucose measurements from a blood glucose meter. At 1220, the processing system may also receive relevant activity data from an activity tracker. At 1230, the processing system may also optionally receive other relevant data from the other sources mentioned above. In some embodiments, a first set of inputs including a series of intermittent blood glucose measurements is received from a calibrated blood glucose meter, and a second set of user inputs including relevant activity data collected from a user by the activity tracker is received from an activity tracker. Optionally, other relevant data from other sources may include, for example, a third set of inputs from an insulin infusion device including insulin dispensed by the insulin infusion device and / or a fourth set of inputs including user entries describing meal information.

[0149] At 1240, the processing system may execute a machine learning-based estimation model for the patient to process various inputs from steps 1210, 1220, 1230 to generate a series or a set of estimated glucose values ​​for the particular patient. The estimated glucose values ​​are similar to the glucose measurements that can be obtained by the glucose sensor because the estimated glucose values ​​estimate the continuous glucose sensor measurements. However, the processing system can generate the set of estimated glucose values ​​without using information from the continuous glucose sensor arrangement. This can eliminate the need for continuous glucose sensors, which may be relatively expensive components relative to blood glucose meters, thus saving a lot of cost for patients. It can also support intermittent CGM users who take "sensor vacations" for various reasons (which may include access, discomfort, seasonal needs, etc.). In some embodiments, only the first set of inputs and the second set of user inputs are processed via the estimation model to generate an estimated glucose value group. As used herein, "estimated glucose value" and "estimated glucose concentration" and the like may refer to glucose levels that have been estimated by an estimation model based on machine learning. In some embodiments, the estimated glucose value estimates and tracks interstitial or sensor glucose values ​​(eg, generated by a sensing arrangement such as a CGM device that has been calibrated using measured blood glucose values ​​measured by a blood glucose meter).

[0150] Steps 1250-1280 are optional and relate to when and how to use estimated glucose values ​​in the context of an insulin management system for diabetes management. For example, in one embodiment, at 1250, the computing system may monitor an estimated group or sequence of glucose values ​​(e.g., discrete estimates of blood glucose levels) to determine whether the sequence of estimated glucose values ​​is within an acceptable range of accuracy that allows them to be used by an insulin management system. How the computing system determines whether the sequence of estimated glucose values ​​is within an acceptable range of accuracy may vary depending on the implementation. For example, in some embodiments, the computing system may determine whether the sequence of estimated glucose values ​​is within an acceptable range of accuracy by measuring the difference between the estimated glucose value and the intermittent glucose measurement value from a blood glucose meter (or equivalent device), and then comparing the difference with an accuracy threshold. In another embodiment, the computing system may determine whether the sequence of estimated glucose values ​​is within an acceptable range of accuracy by measuring the difference between the estimated glucose value and the occasional measurement made by the CGM device, and then comparing the difference with an accuracy threshold.

[0151] When the estimated glucose values ​​are determined (at 1250) to be not within an acceptable range of accuracy that allows them to be used by the insulin management system, method 1200 proceeds to 1260 where a notification or alert perceptible to the patient or other user who is monitoring the patient may be generated. For example, in some embodiments, when the estimated glucose values ​​are not within an acceptable range of accuracy, a notification or alert may be generated to inform the user that they should not trust the estimated glucose values ​​generated by the estimation model and to suggest that the user wear another sensor (e.g., a CGM) to retrain the estimation model. A number of alerting methods may be employed at step 1260, including but not limited to presenting (via a display device) graphical elements and text associated with notifications and alerts for the glucose control system (see reference numerals 100, Figure 1). In some embodiments, notifications and alarms may be presented by an insulin pump device associated with a computing device and / or via a communicatively coupled personal computing device (e.g., a laptop computer, a tablet computer, a smart phone). Such notifications and alarms may include, but are not limited to: audio alarms (e.g., sound effects, clear voice alarms, warnings), visual alarms (e.g., graphical elements and text presented by a user interface or display of an insulin delivery pump, text effects, flashing or otherwise activated lights, color changes), text alarms (e.g., text-based messages transmitted via a short message service (SMS), email messages transmitted over the Internet), and / or any other type of alarm generated to attract the user's attention. In addition, in some embodiments, when it is determined (at 1250) that the estimated glucose values ​​are not within an acceptable accuracy range (allowing them to be used by an insulin management system), one or more displays may be controlled so that the estimated glucose values ​​are not presented to the user. After 1260, method 1200 may end at 1270.

[0152] When the estimated glucose value is determined (at 1250) to be within an acceptable accuracy range that allows them to be used by the insulin management system, method 1200 proceeds to 1280, where the estimated glucose value can be used for the insulin delivery system, and the estimated value can continue to be generated in near real time. The actions that can be taken on the insulin delivery system based on the estimated glucose value vary depending on the implementation. For example, the actions that can be taken at the insulin delivery system based on the estimated glucose value can include controlling an insulin infusion device based on the estimated glucose value so that it administers insulin to the patient, or generating a notice or alarm that can be perceived by the patient or other users who are monitoring the patient based on the estimated glucose value. As described below, corrective actions and notifications or alarms that can be generated depend on the implementation and vary.

[0153] For example, in one embodiment of step 1280, the computing system operates in coordination with the insulin delivery system and the estimation model based on machine learning to monitor the estimated glucose level of the patient, and identifies the abnormality of the estimated glucose level. For example, the computing system can monitor the estimated glucose value group or sequence (for example, the discrete estimation of blood sugar level) to determine whether the sequence of the estimated glucose value is within a low range, a high range or an acceptable range. For example, hypoglycemia is the lack of glucose in the blood flow of a patient or an insulin delivery pump user. Hypoglycemia is usually related to a glucose value lower than 70 mg / dL (mg / dL), which depends on some patient-specific factors. Hyperglycemia is too much glucose in the blood flow of a patient or an insulin delivery pump user, usually related to a glucose value higher than 180 mg / dL, which depends on some patient-specific factors. Normal, healthy blood sugar levels in each 24-hour cycle are usually in the range between 70 and 160 mg / dL. Abnormalities in a series of blood glucose levels may include blood glucose levels below a predefined hypoglycemia threshold, blood glucose levels above a predefined hyperglycemia threshold, a decreasing blood glucose trend approaching or below a predefined hypoglycemia threshold, an increasing blood glucose trend approaching or above a predefined hyperglycemia threshold, and the like.

[0154] This anomaly indicates that corrective action needs to be taken to maintain blood glucose stability at an appropriate level. The abnormality of blood glucose level requires intervention to bring the patient's blood glucose level into a safe and healthy range. Therefore, when the estimated glucose value is not within an acceptable range, method 1200 can proceed to 1280, where corrective action can be taken at the insulin infusion device to deliver the amount of insulin required for the patient to fully treat the abnormal blood glucose, so that the patient's blood glucose level is within the normal range and / or regulate their blood glucose level. For example, in some embodiments, the estimated glucose value can be used to control and drive the insulin infusion device so that it administers insulin to the patient.

[0155] Exemplary embodiments of corrective actions are disclosed in, for example, U.S. patent application Ser. No. 16 / 129,552, filed on Sep. 12, 2018, entitled “SYSTEMS AND METHODS FOR ALERTING A USER TO DETECTED EFFECTS OF A RECENT THERAPY ADJUSTMENT” and assigned to the assignee of the present invention, the entire contents of which are incorporated herein by reference. Any number of corrective actions or intervention methods may be employed at step 1280, such as administering an insulin bolus (to lower blood glucose levels) or administering an amount of carbohydrates, glucose, or other medications (to increase blood glucose levels). In other words, the corrective action may include administering an insulin bolus (to lower hyperglycemic blood glucose levels) or administering a dose of carbohydrates (to increase hypoglycemic blood glucose levels).

[0156] In addition, in some embodiments, at step 1280, the computing system operates in conjunction with an insulin delivery system (e.g., an insulin pump or a manual insulin injection device, such as an insulin pen) and a machine learning-based estimation model to monitor the patient's estimated glucose level and generate a notification or alarm perceptible to the patient or other user who is monitoring the patient based on the estimated glucose value (e.g., notifying the patient or user of any abnormality detected when the estimated glucose value is in a too low low range or in a too high high range). For example, a notification or alarm can be sent to the user to remind them that the estimated glucose value is abnormal and help promote decision support for drug administration. Exemplary embodiments of alarms are disclosed in, for example, U.S. patent application serial number 16 / 129,552, entitled "SYSTEMS AND METHODS FOR ALERTING A USER TO DETECTED EFFECTS OF A RECENT THERAPY ADJUSTMENT" filed on September 12, 2018 and assigned to the assignee of the present invention, the entire contents of which are incorporated herein by reference. A number of alerting methods may be employed at step 1280, including but not limited to presenting (via a display device) graphical elements and text associated with notifications and alerts of the glucose control system (see reference numerals 100, Figure 1 In some embodiments, notifications and alerts may be presented by an insulin pump device associated with a computing device and / or via a communicatively coupled personal computing device (e.g., a laptop computer, a tablet computer, a smart phone). Such notifications and alerts may include, but are not limited to, audio alerts (e.g., sound effects, clear voice alerts, warnings), visual alerts (e.g., graphical elements and text presented via a user interface or display of an insulin delivery pump, text effects, flashing or otherwise activated lights, color changes), text alerts (e.g., text-based messages transmitted via a short message service (SMS), email messages transmitted over the Internet), and / or any other type of alert generated to attract the user's attention.

[0157] For example, the presentation module can identify appropriate graphical elements for presentation via a display device that identify a current estimated blood glucose level (e.g., various icons, text, and / or graphical elements associated with the patient's estimated blood glucose level), an indication of a change in direction of a sequence of detected blood glucose levels, timing data associated with the indication of a change in direction of a sequence of detected blood glucose levels, an indication that a user should take corrective action, a confirmation of a user input indication that the user has completed a corrective action, and the like.

[0158] For example, a display device may display, present or otherwise communicate on a display device one or more graphical representations or images of an indication of a change in direction of a blood sugar level, a blood sugar trend and / or a notification or alarm associated with a blood sugar level. In some embodiments, an alarm may notify a patient of an abnormal overcorrection or undercorrection. For example, in one embodiment, an alarm may be presented by an insulin delivery pump or a manual insulin injection device (e.g., an insulin pen) to notify the patient that the corrective action implemented did not affect the patient's blood sugar level in a desired manner (e.g., the corrective action has overcorrected or undercorrected the abnormality).

[0159] In some embodiments, in response to detected abnormalities (e.g., too high or too low blood sugar levels), an alarm may be presented to prompt the user to perform corrective actions. For example, when the abnormality includes too high a blood sugar level, the user (patient or healthcare partner) may be prompted to enter a command to allow the insulin delivery pump to administer insulin bolus via the insulin delivery pump to treat high blood sugar levels. Alternatively, the notification may provide information to the healthcare provider to adjust the basal rate settings of the insulin infusion device so that they are suitable for specific patients to meet their needs. In another embodiment, when the abnormality includes too high a blood sugar level, the user (patient or healthcare partner) may be prompted to enter a command to administer insulin at a manual insulin injection device (e.g., an insulin pen). In contrast, when the abnormality includes too low a blood sugar level, the alarm may prompt the user to administer a dose of carbohydrates to treat low blood sugar levels.

[0160] Additionally, the estimated glucose value can be utilized by other downstream systems, such as a fitness or exercise advisor device or application that provides fitness / exercise advice or recommendations to the user. For example, the estimated glucose value can be used in conjunction with the predicted activity level in the short term (using similar exercise patterns over the past few minutes) to tell the patient whether maintaining the current activity level will reduce hyperglycemia or result in hypoglycemia.

[0161] After 1280, method 1280 can loop to the start and then proceed to steps 1210, 1220 and 1230 to wait for and receive new data about blood glucose measurements from the blood glucose meter, relevant activity data from the activity tracker, and / or other relevant data from other sources, and retrain the model.

[0162] Fig.131 is a block diagram of a workflow 1300 for generating a personalized model 1350 optimized for estimating glucose values ​​for a particular user or patient according to the disclosed embodiments. The workflow 1300 begins at 1310, where data for a plurality of users is collected. An example of this data is described in more detail below. At 1320, a population model learning process may be performed to generate a set of one or more population models. In one non-limiting embodiment, a deep learning network may be used to develop a general estimation model that is based on learned features of a population of users. Reference will be made below to Figure 14-22 Non-limiting examples of various processes that may be performed as part of 1320 are described.

[0163] At 1330, at least one population model may be selected, and at 1340, a personalized model learning process may be performed to personalize the selected population model for each specific user. In one non-limiting embodiment, once the population model is developed, the general estimation model may be adjusted or trained based on the learned characteristics of a specific user (e.g., a patient) to generate a personalized estimation model optimized for estimating blood glucose for that specific user. The personalized model learning process 1340 may be performed for any number of users to personalize the population model 1330 selected for each user to generate a personalized model 1350 personalized for each user. Figure 23-29 Non-limiting examples of various processes that may be performed as part of 1330 are described.

[0164] Once a personalized model is generated, it can be used for a variety of purposes, including delivering insulin therapy to a specific user without the need for a glucose sensor, such as a continuous glucose monitor.

[0165] The following will refer to Figure 14-22 Various embodiments of a population model learning process that can be performed are described. In these descriptions, like reference numerals refer to similar elements throughout the figures.

[0166] Fig.14 is a block diagram of a machine learning system 1400 for generating an optimized population model 1470 to estimate glucose values ​​for a population of users or patients in accordance with a disclosed embodiment.

[0167] In this part of the workflow, data from multiple users is collected for processing. In this example, the collected data may include, but is not limited to, discrete glucose measurement data 1410 from a blood glucose meter or other sensor arrangement that provides discrete glucose measurements, relevant data 1420 from user activity data sources (e.g., from an activity tracker, a skin electrode activity sensor, a temperature sensor, an oxygen monitor, etc.), and from other sources such as nutritional information about meals consumed by the user, relevant data 1430 about insulin delivered to the user by the user's insulin infusion device.

[0168] Data for each input can be collected for any number of users over a period of time. In other words, for each user in the group, data can be collected for different input channels. Each different input channel can represent a different variable measured for each user. In some embodiments, the different input channels can include (1) time of day, (2) blood glucose level, (3) blood glucose (BG) measurement from a sensor such as a glucometer, activity data including onboard (4) heart rate (beats per minute), (5) METs and (6) steps, (7) active insulin, (8) carbohydrates, etc. Active insulin refers to bolus insulin that has been delivered to the user's body but has not yet been used. The active insulin setting can be taken into account when determining any active insulin still in the user's body based on the user's previous bolus, which can continue to lower their blood sugar.

[0169] In some embodiments, the discrete glucose measurement data 1410, the relevant data 1420 from the user activity data source, and the relevant data 1430 from other sources may then be processed at the population learning processor 1440 to generate an optimized population model 1470. In this example, as part of the learning process, the population learning processor 1440 may perform various processing tasks on the discrete glucose measurement data 1410 from the blood glucose meter, the relevant data 1420 from the user activity data source, and the relevant data 1430 from other sources to generate the optimized population model 1470. For example, the population learning processor 1440 may apply various machine learning models 1450, such as deep learning models, including but not limited to CNNs and RNNs, including any of the models described herein, to the discrete glucose measurement data 1410 from the blood glucose meter, the relevant data 1420 from the user activity data source, and the relevant data 1430 from other sources. For example, in some embodiments, a deep learning network may perform a deep learning process to process a feature matrix to generate a sequence of estimated blood glucose values.

[0170] The group learning processor 1440 can also perform various parameter optimizations based on discrete glucose measurement data 1410 from a blood glucose meter, relevant data 1420 from a user activity data source, and relevant data 1430 from other sources. For example, one or more machine learning or deep learning models can learn transfer functions or map to glucose measurement values ​​from a glucose sensor from a series of inputs (e.g., discrete glucose measurement data 1410 from a blood glucose meter, relevant data 1420 from a user activity data source, and relevant data 1430 from other sources). The mapping can be performed at any time interval so that the model estimates any position from a single glucose value to a series of glucose values ​​that are continuous in time. Each machine learning or deep learning model may have one or more parameters that need to be identified to specify a mathematical transfer function. Parameter optimization generally includes a minimized objective function. The objective function measures the mathematical consistency between the estimated output of the model and the actual measurement data. Parameters are usually adjusted interactively until the objective function is optimized. Once the consistency level reaches the desired threshold or no longer improves, the optimization process terminates.

[0171] Fig.15 1 is a block diagram of a windowed machine learning system 1500 for generating an optimized population model 1570 to estimate glucose values ​​for a population of users or patients according to a disclosed embodiment. The structure of the windowed machine learning system 1500 is similar to that of the above referenced Fig.14 The structure of the machine learning system 1400 described above. Fig.14 The components or blocks shown in the Fig.15 Describe in detail again.

[0172] As in Fig.14 In the embodiment, data of multiple users are collected for processing, which may include but is not limited to discrete glucose measurement data 1510 from a blood glucose meter, relevant data 1520 from a user activity data source, and relevant data 1530 from other sources. However, in this embodiment, before the data is provided to the group learning processor 1540 for processing, the data is provided to a window filter 1535. The window filter 1535 can divide the data into different time windows. In other words, the collected data can be split or divided into a series of time windows in sequence. The time period of each time window can be less than the total time period for collecting data. Each time window contains data collected for different input channels or variables (for each user in the population).

[0173] In this embodiment, each time window may include discrete glucose measurement data 1510, related data 1520 from a user activity data source, and discrete segments of related data 1530. Each time window may then be processed at a population learning processor 1540 to generate an optimized window population model 1570 corresponding to a particular time window. As part of the learning process, the population learning processor 1540 may perform the above-referenced Fig.14 The various processing tasks described, except that the tasks are performed on data acquired over a specific time window to generate an optimized window population model 1570. Each instance of the optimized window population model 1570 performs reasoning on a discrete specified time period of the input data. For example, in some embodiments, if a two-hour window period is considered, the optimized window population model will be the model that performs best (e.g., lowest error) for the input data segmented into two hours.

[0174] Fig.16 1 is a block diagram of another windowed machine learning system 1600 for generating an optimized population model 1670 to estimate glucose values ​​for a population of users or patients according to the disclosed embodiments. The structure of the windowed machine learning system 1600 is similar to that of the above referenced Fig.14 and Fig.15 The structure of the windowed machine learning system 1400, 1500 described above. Therefore, Fig.14 and 15 The components or blocks shown in the Fig.16 Describe in detail again.

[0175] As in Fig.14 and 15 In the example of FIG. 1 , data from multiple users is collected, which may include, but is not limited to, discrete glucose measurement data 1610 from a blood glucose meter, related data 1620 from a user activity data source, and related data 1630 from other sources. Before the data is provided to a population learning processor 1640 for processing, the data is provided to a window filter 1635, which can divide the data into different time windows. Each time window may include discrete glucose measurement data 1610, related data 1620 from a user activity data source, and discrete segments of related data 1630. The data from each time window can then be processed at the population learning processor 1640 to generate an output corresponding to a particular time window (e.g., an estimated glucose value group), as described above with reference to FIG. Fig.15 As part of the learning process, the group learning processor 1640 may perform the above reference Fig.14 Various processing tasks are described, except that tasks are performed on data acquired over a particular time window to generate an optimized window population model 1570.

[0176] In this embodiment, a window connection processor 1665 is provided, which can connect the estimated glucose value groups corresponding to any number of time windows to generate a set of connected estimated glucose values ​​on any number of time windows. For example, in some embodiments, the blood glucose sequence estimated on each time window can be stored, and then linked together (e.g., assembled / cascaded) in sequence at a later time. For example, in some embodiments, the blood glucose sequence estimated on each time window can be stored, and when building the model, the stored output sequence corresponding to each time window can then be linked together (e.g., assembled / cascaded) to create an estimated model for the user group. For example, in some embodiments, if a two-hour window filter is considered, the output (estimated glucose value) of the group model will be limited to two hours, so in order to generate outputs for a longer period, multiple outputs from multiple windows can be connected. For example, three two-hour outputs can be connected to generate a six-hour model output. In some embodiments, the window connection step uses the output of the estimated glucose response of the previous window to initialize the subsequent window. This can be done by replacing or modifying one of the inputs to include a fragment or all of the personalized learning step of the estimated glucose response output applied to the previous window.

[0177] Fig.17 1 is a block diagram of another windowed machine learning system 1700 for generating an optimized population model 1770 to estimate glucose values ​​for a population of users or patients according to the disclosed embodiments. The structure of the windowed machine learning system 1700 is similar to that of the above referenced Figure 14-16 The structure of the windowed machine learning system 1400, 1500, 1600 described above. Therefore, Figure 14-16 The components or blocks shown in the Fig.17 Describe in detail again.

[0178] As in Figure 14-16 In the example of FIG. 1 , data from multiple users is collected, which may include, but is not limited to, discrete glucose measurement data 1710 from a blood glucose meter, related data 1720 from a user activity data source, and related data 1730 from other sources. Before the data is provided to a population learning processor 1740 for processing, the data is provided to a window filter 1735, which can divide the data into different time windows. Each time window can include discrete glucose measurement data 1710, related data 1720 from a user activity data source, and discrete segments of related data 1730. The data from each time window can then be processed at the population learning processor 1740 to generate an optimized window population model 1570 corresponding to a particular time window, as described above with reference to FIG. Fig.15 As part of the learning process, the group learning processor 1740 may perform the above reference Fig.14The various processing tasks described, in addition to the reference Fig.15 In addition to performing a task on data acquired over a specific time window to generate an output (e.g., a set of estimated glucose values), as described in reference Fig.16 As described, the window connection processor 1765 can connect the estimated glucose value groups corresponding to any number of time windows to generate a set of connected estimated glucose values ​​on any number of time windows. For example, in some embodiments, the blood glucose sequence estimated on each time window can be stored, and then linked together (e.g., assembled / cascaded) in sequence at a later time output. In some embodiments, the window connection step uses the output of the estimated glucose response of the previous window to initialize the subsequent window. This can be done by replacing or modifying one of the inputs to include a fragment or all of the estimated glucose response output personalized learning step applied to the previous window.

[0179] In this non-limiting example, the optimized window population model 1670 (in Fig.16 The calibration optimization processor 1766 can optimize calibration characteristics, such as calibration intervals and calibration errors, by determining which calibration population model will provide the best compromise between low calibration errors and long calibration intervals. In general, the longer the interval, the better, because frequent calibration is not desirable. The calibration intervals of the optimized window population model 1770 can be optimized using the discrete glucose measurement data 1710 to adjust the population model output to produce a more accurate estimated glucose. For example, adjustments can be made at intervals of minutes, hours, weeks, or months. Specific adjustment interval requirements can be determined by testing each calibration interval and selecting the population and calibration interval that provides the most accurate glucose estimate. In some embodiments, the calibration interval processor need not rely entirely on blood glucose meter data, but may instead or additionally include data from other sources. Reference will be made below to Fig.21 and Fig. 22 The processing performed by the calibration optimization processor 1766 is described in more detail.

[0180] Fig.18 1 is a block diagram of another windowed machine learning system 1800 for generating an optimized population model 1870 to estimate glucose values ​​for a population of users or patients according to the disclosed embodiments. The structure of the windowed machine learning system 1800 is similar to that of the above referenced Figure 14-17 The structure of the windowed machine learning system 1400, 1500, 1600, 1700 described above. Therefore, Figure 14-17The components or blocks shown in the Fig.18 Describe in detail again.

[0181] As in Figure 14-17 In the example of FIG. 1 , data from multiple users is collected, which may include, but is not limited to, discrete glucose measurement data 1810 from a blood glucose meter, relevant data 1820 from a user activity data source, and other relevant data 1830 from other sources. Before the data is provided to a group learning processor 1840 for processing, the data may be provided to a window filter 1835, which may divide the data into different time windows. Each time window may include discrete segments of discrete glucose measurement data 1810, relevant data 1820 from a user activity data source, and other relevant data 1830. The data from each time window may then be processed at the group learning processor 1840 to generate an output corresponding to a particular time window (e.g., an estimated glucose value group), as described above with reference to FIG. Fig.15 As part of the learning process, the group learning processor 1840 may perform the above reference Fig.14 The various processing tasks described herein, except that tasks are performed on data acquired over a specific time window to generate an output (e.g., a set of estimated glucose values). Fig.16 As described, the window connection processor 1865 can connect the estimated glucose value groups corresponding to any number of time windows to generate a set of connected estimated glucose values ​​on any number of time windows. For example, in some embodiments, the blood glucose sequence estimated on each time window can be stored and then linked together (e.g., assembled / cascaded) in sequence at a later time. In some embodiments, the window connection step uses the output of the estimated glucose response of the previous window to initialize the subsequent window. This can be done by replacing or modifying one of the inputs to include a fragment or all of the estimated glucose response output personalized learning step applied to the previous window.

[0182] In this embodiment, the optimized window population model 1670 (in Fig.16 ) can be further processed by the calibration optimization processor 1866 using the discrete glucose measurement data 1810 and / or other data 1867 to generate an optimized window population model 1770 ( Fig.17 ), the model has an optimized calibration interval and / or calibration error (e.g., longer intervals between calibrations and / or reduced calibration error).

[0183] In this embodiment, the other data 1867 may include, for example, one or more past blood glucose meter readings, past glucose sensor data, time and blood glucose values ​​with minimal daily, weekly or monthly variation, past data from any model input, etc. The use of the other data 1867 alone or in combination with the discrete glucose measurement data 1810 can improve the accuracy of the calibration interval and / or the accuracy of the calibration interval of the optimized window population model, which is the output of the calibration optimization processor 1866. As described above with respect to the calibration optimization processor 1766, the other data 1867 from other sources can be used in conjunction with or in place of the discrete glucose measurement data 1810. For example, the other data 1867 can provide sufficient information to provide an accurate calibration method without the need for invasive blood glucose meter readings. In another example, in order to reduce the frequency of blood glucose meter readings (extend the intervals), the other data 1867 can be used to help the calibration model maintain satisfactory performance of the population model accuracy. The processing performed by the calibration optimization processor 1866, and the various inputs or data that it can use to replace historical and blood glucose meter data, will be referenced below. Fig.21 and 22 Describe in more detail.

[0184] Fig.19 1 is a block diagram of another windowed machine learning system 1900 for generating an optimized population model 1970 to estimate glucose values ​​for a population of users or patients according to the disclosed embodiments. The structure of the windowed machine learning system 1900 is similar to that of the above referenced Figure 14-18 The structure of the windowed machine learning system 1400, 1500, 1600, 1700, 1800 described above. Therefore, Figure 14-18 The components or blocks shown in the Fig.19 Describe in detail again.

[0185] As in Figure 14-18 In the example of FIG. 1 , data from multiple users is collected, which may include, but is not limited to, discrete glucose measurement data 1910 from a blood glucose meter, related data 1920 from a user activity data source, and related data 1930 from other sources. Before the data is provided to a population learning processor 1940 for processing, the data may be provided to a window filter 1935, which may divide the data into different time windows. Each time window may include discrete glucose measurement data 1910, related data 1920 from a user activity data source, and discrete segments of related data 1930. The data from each time window may then be processed at the population learning processor 1940 to generate an optimized window population model 1570 corresponding to a particular time window, as described above with reference to FIG. Fig.15 As part of the learning process, the group learning processor 1940 may perform the above reference Fig.14The various processing tasks described, in addition to the reference Fig.15 In addition to performing a task on data acquired over a specific time window to generate an output (e.g., a set of estimated glucose values), as described in reference Fig.16 As described, the window connection processor 1965 can connect groups of estimated glucose values ​​corresponding to any number of time windows to generate a set of connected estimated glucose values ​​over any number of time windows. For example, in some embodiments, the blood glucose sequences estimated over each time window can be stored and then sequentially linked together (e.g., assembled / concatenated) at a later time. In some embodiments, the window connection step uses the output of the estimated glucose response of the previous window to initialize the subsequent window. This can be accomplished by replacing or modifying one of the inputs to include a fragment or all of the estimated glucose response output personalized learning step applied to the previous window. As described in reference Fig.17 and 18 The illustrated, optimized window population model 1670 (in Fig.16 ) can be further processed by the calibration optimization processor 1966 using the discrete glucose measurement data 1910 and / or other data 1967 to generate an optimized window population model 1770 ( Fig.17 ), the model has an optimized calibration interval and / or calibration error (e.g., longer intervals between calibrations and / or reduced calibration error).

[0186] In this embodiment, the optimized window population model 1870 ( Fig.18 ) can be further processed by the model interpretability analysis processor 1968 to generate an optimized window population model 1970 that provides a physiologically consistent response to one or more model inputs. For example, a typical physiological response of a person to food intake is an increase in blood glucose levels. Therefore, each candidate population model can be tested to ensure that the response is at least similar in direction to that observed clinically, medically or physiologically, or similar in magnitude. As will be described in more detail below, the model interpretability analysis processor 1968 can modulate or simulate inputs and compare the observed population model output (or response) to a reference or standard. This comparison may indicate the rationality and interpretability of the model response. This process may exclude all models that cannot respond in an understandable manner. The model interpretability analysis processor 1868 can select and output or generate an optimized window population model 1970. Reference will be made below to Fig. 20 The processing performed by the model interpretability analysis processor 1968 is described in more detail.

[0187] Fig. 202000 is a block diagram of a model interpretability analysis processor 2000 for selecting an optimized population model for estimating glucose values ​​for a population of users or patients according to the disclosed embodiments. The model interpretability analysis processor 2000 can select an optimized population model from a pool of candidate population models 2080. The selected optimized population model can then be used as a basis for further training and personalization to generate a personalized model for estimating glucose values ​​for a specific user or patient.

[0188] In this part of the workflow, data from multiple users may be collected for processing. In this example, the collected data may include, but is not limited to, discrete glucose measurement data 2010 from a blood glucose meter, relevant data 2020 from user activity data sources, and relevant data 2030 from other sources.

[0189] Discrete glucose measurement data 2010 from the blood glucose meter, relevant data 2020 from the user activity data source, and relevant data 2030 from other sources can then be processed at the data modulation processor 2040 to generate a modulated form of the data. For example, in some embodiments, the input data can be modulated (modified) or simulated to produce a change in the content of one or more inputs. The modulated data is executed by the population model to generate an estimated glucose output. In the model response test step, the estimated glucose output of the output is compared with a reference or standard representing the typical directionality or amplitude of the human physiological response to similar input data modulation. The reference or standard can be, but is not limited to, those that are recorded or generally known to be typically observed clinically, medically or physiologically. For example, the typical physiological response of a person to insulin is a drop in blood sugar levels. In a physiologically accurate model, adjusting the insulin input by reducing the amplitude of the insulin level should result in a lower estimated glucose output.

[0190] At 2050 to 2060, the model interpretability analysis processor 2000 may then perform processing to evaluate each of the plurality of population models to determine which of those population models should be added to the pool 2080 of candidate population models, and then select (at 2090) an optimized population model from the pool 2080 of candidate population models as an optimized population model (e.g., an optimized window population model, an optimized window population model, etc.). At 2050, the model interpretability analysis processor 2000 selects a population model to be executed and applies the modulated form of the data to the selected population model to generate a response to the modulated form of the data. At 2055, the model interpretability analysis processor 2000 may perform various tests that help evaluate or assess whether the response (generated at 2050) is physiologically reasonable. At 2060, the model interpretability analysis processor 2000 may then analyze or evaluate the test results generated at 2055 to determine whether the response of the selected population model is a reasonable physiological response. When the model interpretability analysis processor 2000 determines (at 2060) that the test results generated at 2055 indicate that the response of the selected population model is not a reasonable physiological response, the model interpretability analysis processor 2000 no longer considers the selected population model.

[0191] In contrast, when the model interpretability analysis processor 2000 determines (at 2060) that the test results generated at 2055 indicate that the response of the selected population model is a reasonable physiological response, the model interpretability analysis processor 2000 adds the selected population model to the pool of candidate population models 2080 at 2070. At 2090, the model interpretability analysis processor 2000 may select an optimized population model from the pool of candidate population models 2080. The selected optimized population model may then be used as a basis for further training and personalization to generate a personalized model for estimating glucose values ​​for a specific user or patient.

[0192] Reference again Figures 17 to 19 The calibration optimization processors 1766, 1866, 1966 can identify the calibration model that provides the best performance and can also identify the best input type for developing the calibration model (e.g., selecting the best calibration method). Fig.21 and 22 The processing performed by the calibration optimization processors 1766, 1866, 1966 is described in more detail.

[0193] Fig.21 is a block diagram of a calibration optimization processor 2100 for selecting an optimized calibration model 2170 according to the disclosed embodiments. The calibration optimization processor 2100 can select an optimized calibration model 2170 to use as a basis for calibrating a population model for estimating glucose values ​​for a population of users.

[0194] During this part of the workflow process, data can be collected from different potential calibration sources 2110, 2120, 2130, 2140 for processing and evaluation. In this example, the collected data may include but are not limited to discrete glucose measurement data 2010 collected from a blood glucose meter, history or sensor glucose trend data 2120, statistics or heuristic calibration point prediction data 2130 and glucose value data 2140 from blood glucose reading stability analysis. History or sensor glucose trend may include but are not limited to glucose values ​​from the past, glucose sensor data of several days, a time point of glucose less or least change in a day. Statistics or heuristic calibration point prediction may include but are not limited to statistical, empirical or rule-based methods for estimating or predicting the glucose value of a given time point, which can be used to calibrate a population model. Glucose values ​​from blood glucose reading stability analysis may include but are not limited to glucose variability analysis per hour, per day, per week or per month. Glucose values ​​that are the most stable, less variable or least variable compared to other time periods can be selected to calibrate a population model. Each data source 2110, 2120, 2130, 2140 or a combination thereof may be applied to a calibration population model processor 2150 to generate a calibration model that is applied to a population model to generate a corresponding calibration population model response. Fig.21 A single arrow between each data source 2110 , 2120 , 2130 , 2140 and each calibration population model processor 2150 is illustrated, but it should be understood that in other embodiments, each data source 2110 , 2120 , 2130 , 2140 may be linked to each calibration population model processor 2150 .

[0195] The error and interval analysis processor 2160 can receive each calibrated other model response. For each calibrated population model response, the error and interval analysis processor 2160 can (1) perform an error analysis and generate an error result that indicates the performance of the calibrated population model response compared to the measured glucose value, and (2) perform an interval analysis to generate an interval result that indicates how often the population model needs to be calibrated using a given input. For each response, the error and interval analysis processor 2160 can then evaluate the corresponding error result and the corresponding interval result.

[0196] At 2170, based on the evaluation of all error result / interval result combinations for each type of calibration model, the calibration optimization processor 2100 can compare the performance of any given population model for each type of calibration model to determine the optimized calibration model for the given population model. For example, an optimized calibration model can be selected to minimize errors, maximize the time between calibrations, and / or reduce the burden on the user or patient. For example, reading a blood glucose meter every few minutes can minimize errors, but will burden the user, so the calibration interval is too frequent. A blood glucose meter is considered an invasive measurement and is therefore a burden on the patient, so one of the other calibration models that is less invasive or non-invasive based on an alternative input source may be preferred. The trade-off between error, calibration interval, and patient burden may be based on target functions, clinical standards, or product, regulatory, or business requirements.

[0197] Fig. 22 22 is a block diagram of a calibration optimization processor 2200 for selecting optimal input types to be used to develop an optimized calibration model in accordance with the disclosed embodiments. When calibrating any given population model for estimating glucose values ​​for a population of users, the calibration optimization processor 2200 may select one or more inputs to use with the optimized calibration model.

[0198] During this part of the workflow process, data can be collected from different potential calibration sources 2210, 2220, 2230, 2240, 2245 for processing and evaluation. In this example, the collected data may include, but is not limited to, discrete glucose measurement data 2010 collected from a blood glucose meter, historical or sensor glucose trend data 2220, statistical or heuristic calibration point prediction data 2230, glucose value data 2240 from blood glucose reading stability analysis, and relevant data 2245 from a user activity data source (e.g., an activity tracker), and / or relevant data 2245 from other sources, such as nutritional information about the meals consumed by the user, insulin delivered to the user by the user's insulin infusion device, etc. Historical or sensor glucose trends may include, but are not limited to, past glucose values, several days of glucose sensor data, and time points in a day when glucose is less or least changing. Statistical or heuristic calibration point predictions may include, but are not limited to, statistical, empirical, or rule-based methods for estimating or predicting glucose values ​​at a given time point, which can be used to calibrate a population model. Glucose values ​​from the blood glucose reading stability analysis may include, but are not limited to, hourly, daily, weekly, or monthly glucose variability analysis. Glucose values ​​that are most stable, less variable, or least variable compared to other time periods may be selected to calibrate the population model. Each data source 2210, 2220, 2230, 2240, 2245, or a combination thereof, may be applied to a calibration population model processor 2250 to generate a calibration model that is applied to a population model, generating a corresponding calibration population model response. In other words, although Fig. 22 A single arrow between each data source 2210 , 2220 , 2230 , 2240 and each calibration population model processor 2250 is illustrated, but it should be understood that in other embodiments, each data source 2210 , 2220 , 2230 , 2240 may be linked to each calibration population model processor 2250 .

[0199] The error and interval analysis processor 2260 can receive each calibrated other model response. For each calibrated population model response, the error and interval analysis processor 2260 can (1) perform an error analysis and generate an error result that indicates the performance of the calibrated population model response compared to the measured glucose value, and (2) perform an interval analysis to generate an interval result that indicates how often the population model needs to be calibrated using a given input. For each response, the error and interval analysis processor 2260 can then evaluate the corresponding error result and the corresponding interval result.

[0200] At 2270, based on the evaluation of all error result / interval result combinations for each type of calibration model, the calibration optimization processor 2200 can compare the performance of any given population model for each type of calibration model to determine the optimized calibration model for the given population model. For example, an optimized calibration model can be selected to minimize errors, maximize the time between calibrations, and / or reduce the burden on the user or patient. For example, reading a blood glucose meter every few minutes can minimize errors, but will burden the user, so the calibration interval is too frequent. A blood glucose meter is considered an invasive measurement and is therefore a burden on the patient, so one of the other calibration models that is less invasive or non-invasive based on an alternative input source may be preferred. The trade-off between error, calibration interval, and patient burden may be based on target functions, clinical standards, or product, regulatory, or business requirements.

[0201] In this embodiment, once the optimized calibration model is determined (at 2270), the calibration optimization processor 2200 may determine or select the optimal type of inputs to use with the optimized calibration model (from 2270) when used to calibrate any given overall model based on an evaluation of all error result / interval result combinations for each type of input at 2280. Thus, once the optimized calibration model is determined (at 2270), the calibration optimization processor 2200 may select (at 2280) one or more types of inputs 2210, 2220, 2230, 2240, 2245 to use with the optimized calibration model.

[0202] As described above, at least one population model may be selected, and a personalized model learning process may be performed to personalize the selected population model for each specific user. Figure 23-29 Various embodiments of a personalized model learning process that can be performed are described. In these descriptions, like reference numerals refer to similar elements throughout the figures.

[0203] Fig.23 23 is a block diagram of a machine learning system 2300 for generating an optimized personal model 2370 for estimating a glucose value personalized for a specific user or patient according to the disclosed embodiments. In this portion of the workflow, data for a specific user is collected for processing. In this example, the collected data may include, but is not limited to, discrete glucose measurement data 2310 from a blood glucose meter or other sensor arrangement that provides discrete glucose measurements from a user, relevant data 2320 about the user from a user activity data source (e.g., an activity tracker), and relevant data 2330 about the user from other sources, such as nutritional information about meals consumed by the user, insulin delivered to the user by the user's insulin infusion device.

[0204] Data for each input may be collected for a particular user over a period of time. In other words, data for a particular user may be collected for different input channels. Each different input channel may represent a different variable measured for that user. In some embodiments, the different input channels may include (1) time of day, (2) blood glucose level, (3) blood glucose (BG) measurement from a sensor such as a CGM device, activity data including onboard (4) heart rate (beats per minute), (5) METs and (6) steps, (7) active insulin, (8) carbohydrates, etc.

[0205] In some embodiments, the discrete glucose measurement data 2310, the relevant data 2320 from the user activity data source, and the relevant data 2330 from other sources can then be processed together with the specific population model 2305 at the personalized learning processor 2340 to train or adjust the specific population model 2305 and thereby produce an optimized personal model 2370 tailored to a specific user or patient. In some embodiments, the specific population model 2305 is used as the machine learning model 2350 and learns based on the inputs 2310, 2320, 2330, so that the specific population model 2305 is converted (e.g., retrained and optimized / personalized for the user) into an optimized personal model 2370 for estimating a glucose value personalized for a specific user or patient. In other embodiments, the specific population model 2305 is one model of an ensemble of machine learning models 2350, and the ensemble of machine learning models 2350 learns based on the inputs 2310, 2320, 2330, so that the ensemble is converted into an optimized personal model 2370 for estimating a glucose value personalized for a specific user or patient. In this example, as part of the personalized learning process, the personalized learning processor 2340 can perform various processing tasks on the discrete glucose measurement data 2310 from the blood glucose meter, the relevant data 2320 from the user activity data source, and the relevant data 2330 from other sources to train or adjust the specific population model 2305 to generate an optimized personal model 2370. For example, the personalized learning processor 2340 can apply various machine learning models 2350 (including the specific population model 2305) to the discrete glucose measurement data 2310, the relevant data 2320 from the user activity data source, and the other relevant data 2330 from other sources to train or adjust the specific population model 2305. In another embodiment, the specific population model 2305 is combined with a separate personalized model to create an integration of population and personalized models that constitute a single optimized personal model. In another embodiment, the specific population model 2305 may be ignored and skipped (e.g., given a zero or near-zero weight), in which case the personalized learning processor 2340 may apply various other machine learning models 2350 to generate an optimized personal model 2370 tailored for the specific user or patient.

[0206] The personalized learning processor 2340 can also perform various parameter optimizations to further train the specific population model 2305 based on discrete glucose measurement data 2310 from the blood glucose meter, relevant data 2320 from the user activity data source, and relevant data 2330 from other sources. For example, one or more machine learning or deep learning models can learn a transfer function or mapping from a series of inputs to glucose measurements from a glucose sensor. The mapping can be performed at any time interval so that the model estimates any position from a single glucose value to a series of glucose values ​​that are continuous in time. Each machine learning or deep learning model may have one or more parameters that need to be identified to specify the mathematical transfer function. Parameter optimization typically includes an objective function that must be minimized. The objective function measures the mathematical consistency between the estimated output of the model and the actual measured glucose value. Parameters are typically adjusted interactively until the objective function is optimized. Once the consistency level reaches the desired threshold or no longer improves, the optimization process terminates.

[0207] Fig.24 FIG. 2 is a block diagram of a windowed machine learning system 2400 for generating an optimized personal model 2470 for estimating a glucose value personalized for a particular user or patient according to the disclosed embodiments. The structure of the windowed machine learning system 2400 is similar to that described above with reference to FIG. Fig.23 The structure of the machine learning system 2300 described above. Fig.23 The components or blocks shown in the Fig.24 Describe in detail again.

[0208] As above reference Fig.23 As described, data of a specific user is collected for processing, which may include, but is not limited to, discrete glucose measurement data 2410 from a blood glucose meter, relevant data 2420 from a user activity data source, and relevant data 2430 from other sources. However, in this embodiment, before the data is provided to the personalized learning processor 2440 for processing, the data is provided to a window filter 2435. The window filter 2435 can divide the data into different time windows. In other words, the collected data can be split or divided into a series of time windows in sequence. The time period of each time window can be less than the total time period for collecting data. Each time window contains data collected for different input channels or variables (for each personalized user).

[0209] In this embodiment, each time window may include discrete segments of discrete glucose measurement data 2410, relevant data from a user activity data source 2420, and relevant data for a specific user 2430. Each time window may then be processed at a personalized learning processor 2440 to generate an optimized personal model 2470 corresponding to the particular time window. As part of the learning process, the personalized learning processor 2440 may perform the above-referenced Fig.23 The various processing tasks described above are performed on data acquired over a specific time window to generate an optimized personal model 2470. Each instance of the optimized personal model 2470 performs reasoning on a discrete specified time period of the input data. For example, in some embodiments, if a two-hour window period is considered, the optimized personalized model can be the model that performs best (e.g., lowest error) for the input data segmented into two hours.

[0210] Fig.25 FIG. 2 is a block diagram of another windowed machine learning system 2500 for generating an optimized personal model 2570 for estimating a glucose value personalized for a particular user or patient according to the disclosed embodiments. The structure of the windowed machine learning system 2500 is similar to that described above with reference to FIG. Fig.23 and Fig.24 The structure of the windowed machine learning system 2400 described above. Fig.23 and 24 The components or blocks shown in the Fig.25 Describe in detail again.

[0211] As in Fig.23 and 24 , data for a particular user is collected, which may include, but is not limited to, discrete glucose measurement data 2510 from a blood glucose meter, related data 2520 from a user activity data source, and related data 2530 from other sources. Before the data is provided to a personalized learning processor 2540 for processing, the data is provided to a window filter 2535, which can divide the data into different time windows. Each time window may include discrete glucose measurement data 2510, related data 2520 from a user activity data source, and discrete segments of related data 2530. The data from each time window can then be processed at the personalized learning processor 2540 to generate an output corresponding to a particular time window (e.g., an estimated set of glucose values), as described above with reference to FIG. Fig.24 As part of the learning process, the personalized learning processor 2540 may perform the above-referenced Fig.23 Various processing tasks are described, except that tasks are performed on data acquired over a specific time window to generate an optimized personal model 2470.

[0212] In this embodiment, a window connection processor 2565 is provided, which can connect the estimated glucose value groups corresponding to any number of time windows to generate a set of connected estimated glucose values ​​on any number of time windows. For example, in some embodiments, the blood glucose sequence estimated on each time window can be stored, and then it can be sequentially linked together (e.g., assembled / cascaded) at a later time. For example, in some embodiments, the blood glucose sequence estimated on each time window can be stored, and then the output sequence of the storage corresponding to each time window can be linked together (e.g., assembled / cascaded). In some embodiments, the window connection step uses the output of the estimated glucose response of the previous window to initialize the subsequent window. This can be completed by replacing or modifying one or more inputs to include a fragment or all of the estimated glucose response output personalized learning step applied to the previous window.

[0213] Fig.26 FIG. 2 is a block diagram of another windowed machine learning system 2600 for generating an optimized personal model 2670 for estimating a glucose value personalized for a particular user or patient according to the disclosed embodiments. The structure of the windowed machine learning system 2600 is similar to that of the above referenced Figure 23-25 The structure of the windowed machine learning system 2500 described above. Therefore, Figure 23-25 The components or blocks shown in the Fig.26 Again, describe in detail unless they are in Fig.26 is performed differently in the embodiments of the present invention.

[0214] As in Figure 23-25 In the process, data for a specific user is collected, which may include, but is not limited to, discrete glucose measurement data 2610 from a blood glucose meter, relevant data 2620 from a user activity data source, and relevant data 2630 from other sources. Before the data is provided to a personalized learning processor 2640 for processing, the data is provided to a window filter 2635, which can divide the data into different time windows. Each time window may include discrete glucose measurement data 2610, relevant data 2620 from a user activity data source, and discrete segments of relevant data 2630. The data from each time window can then be processed at the personalized learning processor 2640 to generate an optimized personal model 2470 corresponding to the specific time window, as described above with reference to Fig.24 As part of the learning process, the personalized learning processor 2640 may perform the above reference Fig.23 The various processing tasks described, in addition to the reference Fig.24 In addition to performing a task on data acquired over a specific time window to generate an output (e.g., a set of estimated glucose values), as described in reference Fig.25As described, the window connection processor 2665 can connect the estimated glucose value groups corresponding to any number of time windows to generate a set of connected estimated glucose values ​​on any number of time windows. For example, in some embodiments, the blood glucose sequence estimated on each time window can be stored and then sequentially linked together (e.g., assembled / cascaded) at a later time. In some embodiments, the window connection step uses the output of the estimated glucose response of the previous window to initialize the subsequent window. This can be done by replacing or modifying one of the inputs to include a fragment or all of the estimated glucose response output personalized learning step applied to the previous window.

[0215] In this embodiment, (in Fig.25 The optimized personal model 2570 (generated in ) can be further processed by the calibration optimization processor 2666 using the discrete glucose measurement data 2610 and / or other data 2667 to generate an optimized personal model 2670 with optimized calibration intervals. The calibration intervals of the optimized personal model 2670 can be optimized by using the discrete glucose measurement data 2610. In some embodiments, Fig.25 The optimized personal model 2570 (generated in the calibration optimization processor 2666) can be further processed by the calibration optimization processor 2666 using the discrete glucose measurement data 2610 to generate the optimized personal model 2670. In other embodiments, the calibration optimization processor 2666 can also process other data, such as other data 2667 with or without the discrete glucose measurement data 2610 to generate the optimized personal model 2670. In some embodiments, the other data 2767 can include one or more of the following, for example, one or more past blood glucose meter readings, past glucose sensor data, time and blood glucose values ​​with minimal daily, weekly or monthly variation, past data from any model input, etc. The use of the other data 2667 in conjunction with the discrete glucose measurement data 2610 can improve the accuracy of the calibration intervals of the optimized personal model, which is the output of the calibration optimization processor 2666. The processing performed by the calibration optimization processor 2666 can be as described above with reference to Fig.21 and 22 Performed as described.

[0216] Fig. 27 is a block diagram of another windowed machine learning system 2700 for generating an optimized personal model 2770 for estimating a glucose value personalized for a particular user or patient according to the disclosed embodiments; the structure of the windowed machine learning system 2700 is similar to that of the above referenced Figure 23-26 The structure of the windowed machine learning system 2600 described above. Figure 23-26 The components or blocks shown in the Fig. 27 Again, describe in detail unless they are in Fig. 27is performed differently in the embodiments of the present invention.

[0217] As in Figure 23-26 In the process, data for a specific user is collected, which may include, but is not limited to, discrete glucose measurement data 2710 from a blood glucose meter, relevant data 2720 from a user activity data source, and relevant data 2730 from other sources. Before the data is provided to a personalized learning processor 2740 for processing, the data may be provided to a window filter 2735, which may divide the data into different time windows. Each time window may include discrete glucose measurement data 2710, relevant data 2720 from a user activity data source, and discrete segments of relevant data 2730. The data from each time window may then be processed at the personalized learning processor 2740 to generate an optimized personal model 2470 ( Fig.24 ), as referenced above Fig.24 As part of the learning process, the personalized learning processor 2740 may perform the above reference Fig.23 The various processing tasks described, in addition to the reference Fig.24 In addition to performing a task on data acquired over a specific time window to generate an output (e.g., a set of estimated glucose values), as described in reference Fig.25 As described, the window connection processor 2765 can connect the estimated glucose value groups corresponding to any number of time windows to generate a set of connected estimated glucose values ​​on any number of time windows. For example, in some embodiments, the blood glucose sequence estimated on each time window can be stored and then linked together (e.g., assembled / cascaded) in sequence at a later time. In some embodiments, the window connection step uses the output of the estimated glucose response of the previous window to initialize the subsequent window. This can be done by replacing or modifying one of the inputs to include a fragment or all of the estimated glucose response output personalized learning step applied to the previous window.

[0218] As reference Fig.26 As explained, in some embodiments, (in Fig.25 The optimized personal model 2570 generated in ( ) can be further processed by the calibration optimization processor 2766 to generate an optimized personal model 2670 ( Fig.26 ).

[0219] In this embodiment, the optimized individual model output by the calibration optimization processor 2766 can then be further processed by the model interpretability analysis processor 2768 to generate an optimized individual model 2770 that provides a physiologically consistent response to one or more model inputs. For example, a typical physiological response of a person to food intake is an increase in blood glucose levels. Therefore, each candidate population model can be tested to ensure that the response is at least similar in direction to that observed clinically, medically, or physiologically, or similar in magnitude. As shown in reference Fig.19 and Fig. 20 As described, the model interpretability analysis processor 2768 can modulate or simulate inputs and compare observed individual model outputs (or responses) to a reference or standard. This comparison may indicate the rationality and interpretability of the model response. This process may exclude all models that cannot respond in an understandable manner. The model interpretability analysis processor 2768 can select and output or generate an optimized window population model 1970.

[0220] Fig.28 28 is a block diagram illustrating an intermittent CGM system 2800 according to the disclosed embodiment. The system 2800 includes a personalized model 2840 and a calibration model 2850. The personalized model 2840 may refer to any type of personalized model, including the optimized and windowed personal models described above. Once the personalized model 2840 and the calibration model 2850 have been properly trained, they can be deployed and used by a specific user or patient. After deployment, input data from a specific user can be continuously received. In this embodiment, the input data may include, but is not limited to, discrete glucose measurement data 2810 from a blood glucose meter of the specific user or patient, relevant data 2820 from a user activity data source of the specific user or patient, and relevant data 2830 from other sources of the specific user or patient. The personalized model 2840 can receive and process the input data to generate a continuous time series of estimated glucose values ​​2870. The estimated glucose values ​​2870 can then be used for a variety of purposes. For example, as a non-limiting example, estimated glucose value 2870 may be used in conjunction with an insulin infusion system to provide CGM-like therapy to a particular user or patient without the need for a glucose sensor. Calibration model 2850 may be used to calibrate personalized model 2840 to help improve the performance of the model and ensure that it performs accurately.

[0221] Fig.29 2 is a block diagram illustrating another intermittent CGM system 2900 according to the disclosed embodiments. The structure of the intermittent CGM system 2900 is similar to that of the above referenced Fig.28 The structure of the intermittent CGM system 2800 is described. Therefore, Fig.28 The components or blocks shown in the Fig.29Again, describe in detail unless they are in Fig.28 In the embodiment of the present invention, the data is provided to a window filter 2935 before being provided to the personalized model 2940 for processing, which can divide the input data into different time windows. Each time window can include discrete glucose measurement data 2910 of the specific user or patient, relevant data 2920 from the user activity data source of the specific user or patient, and discrete fragments of relevant data 2930 of the specific user or patient. The data from each time window can then be processed at the personalized model 2940 to generate an estimated glucose value 2970 corresponding to the time series of the specific time window. In some embodiments, a window connection processor 2965 is provided, which can connect the estimated glucose value 2970 groups corresponding to any number of time windows to generate a set of connected estimated glucose values ​​2970 on any number of time windows. For example, in some embodiments, the blood glucose sequence estimated on each time window can be stored and then linked together (e.g., assembled / cascaded) in sequence at a later time. In some embodiments, the window connection step uses the output of the estimated glucose response of the previous window to initialize the subsequent window. This can be done by replacing or modifying one of the inputs to contain a fragment or all of the estimated glucose response output personalization learning step applied to the previous window.

[0222] Although at least one exemplary embodiment has been presented in the foregoing detailed description, it should be understood that there are a large number of variations. It should also be understood that one or more exemplary embodiments described herein are not intended to limit the scope, applicability, or configuration of the claimed subject matter in any way. More specifically, the foregoing detailed description will provide a convenient guide for implementing one or more of the described embodiments to those skilled in the art. It should be understood that various changes may be made to the function and arrangement of the elements without departing from the scope defined by the claims, and the scope defined by the claims includes known equivalents and foreseeable equivalents at the time of filing this patent application.

Claims

1. A processor-implemented method, comprising: receiving input data associated with a user, the input data comprising discrete blood glucose measurement data associated with the user and related data associated with the user; generating one or more estimated blood glucose values ​​associated with the user in real time using an estimation model and at least a portion of input data associated with the user, wherein the estimation model is trained using discrete blood glucose measurement data and related data to determine a sequence of estimated blood glucose values ​​associated with the user based at least on the related data associated with the user, at least a portion of the sequence of estimated blood glucose values ​​being determined without the discrete blood glucose measurement data associated with the user, and wherein the estimation model is configured to receive the discrete blood glucose measurement data associated with the user less frequently than the frequency of generating the one or more estimated blood glucose values ​​associated with the user; and The insulin infusion device is controlled based on the generated one or more estimated blood glucose values.

2. The processor-implemented method of claim 1 , wherein the estimation model is configured to map (i) discrete blood glucose measurement data associated with a user and related data associated with the user to (ii) a sequence of estimated blood glucose values ​​associated with the user.

3. The processor-implemented method of claim 1 , wherein: Using a continuous blood glucose meter configured to measure glucose levels directly from blood, discrete blood glucose measurement data may be obtained for training the estimation model; and Discrete blood glucose measurement data associated with a user is intermittently received.

4. The processor-implemented method of claim 1 , further comprising receiving input data associated with a plurality of users in a user population, the plurality of users including the user; in: The estimation model comprises a population model configured to estimate blood glucose values ​​of a population of users; and A population model is generated by mapping one or more of (i) discrete blood glucose measurement data associated with a plurality of users or related data associated with the users to (ii) sequences of estimated blood glucose values ​​for the plurality of users.

5. The processor-implemented method of claim 1 , further comprising receiving input data associated with a plurality of users in a user population, the plurality of users including the user; in: The estimation model includes a customized personal model for a user, the customized personal model being configured to estimate a blood glucose value of the user; and A customized personal model is generated by transforming a group model, wherein the group model is configured to estimate blood glucose values ​​of a group of users based on mapping one or more of (i) discrete blood glucose measurement data associated with the users or related data associated with the users to (ii) a sequence of estimated blood glucose values ​​of the users.

6. A system comprising: one or more processors; and One or more processor-readable media storing instructions that, when executed by the one or more processors, result in execution of: receiving input data associated with a user, the input data comprising discrete blood glucose measurement data associated with the user and correlation data associated with the user; generating one or more estimated blood glucose values ​​associated with the user in real time using an estimation model and at least a portion of input data associated with the user, wherein the estimation model is trained using discrete blood glucose measurement data and related data to determine a sequence of estimated blood glucose values ​​associated with the user based at least on the related data associated with the user, at least a portion of the sequence of estimated blood glucose values ​​being determined without the discrete blood glucose measurement data associated with the user, and wherein the estimation model is configured to receive the discrete blood glucose measurement data associated with the user less frequently than the frequency of generating the one or more estimated blood glucose values ​​associated with the user; and The insulin infusion device is controlled based on the generated one or more estimated blood glucose values.

7. The system of claim 6, wherein the estimation model is configured to map (i) discrete blood glucose measurement data associated with the user and related data associated with the user to (ii) a sequence of estimated blood glucose values ​​associated with the user.

8. The system of claim 6, wherein: Using a continuous blood glucose meter configured to measure glucose levels directly from blood, discrete blood glucose measurement data may be obtained for training the estimation model; and Discrete blood glucose measurement data associated with a user is intermittently received.

9. The system of claim 6, wherein: When the instructions are executed by the one or more processors, they result in the execution of: receiving input data associated with a plurality of users in a user population, the plurality of users including the user; The estimation model comprises a population model configured to estimate blood glucose values ​​of a population of users; and A population model is generated by mapping one or more of (i) discrete blood glucose measurement data associated with a plurality of users or related data associated with the users to (ii) sequences of estimated blood glucose values ​​for the plurality of users.

10. The system of claim 6, wherein: When the instructions are executed by the one or more processors, they result in the execution of: receiving input data associated with a plurality of users in a user population, the plurality of users including the user; The estimation model includes a customized personal model for a user, the customized personal model being configured to estimate a blood glucose value of the user; and A customized personal model is generated by transforming a group model, wherein the group model is configured to estimate blood glucose values ​​of a group of users based on mapping one or more of (i) discrete blood glucose measurement data associated with the users or related data associated with the users to (ii) a sequence of estimated blood glucose values ​​of the users.

11. A system comprising: one or more processors; and A computer readable device comprising a storage medium comprising a plurality of instructions configured to, when executed by the one or more processors, cause a system to: receiving, via a window filter, one or more segments of input data associated with a user, the window filter configured to divide the input data into a plurality of segments corresponding to a respective plurality of time windows, the input data comprising discrete glucose measurement data associated with the user, related data associated with the user, or a combination thereof; and One or more estimated glucose values ​​associated with the user corresponding to at least one of the plurality of time windows are generated in real time using the estimation model and at least a portion of the one or more segments of input data associated with the user received via the window filter.

12. The system according to claim 11, wherein: The plurality of instructions are also configured to control an insulin infusion device based on the generated one or more estimated glucose values.

13. A system according to claim 11, wherein generating one or more estimated glucose values ​​associated with the user includes generating multiple estimated glucose values ​​associated with the user, the multiple estimated glucose values ​​including a combination of at least (i) one or more estimated glucose values ​​associated with a first time window among the multiple time windows and (ii) one or more estimated glucose values ​​associated with a second time window among the multiple time windows.

14. A system according to claim 13, wherein generating one or more estimated glucose values ​​associated with the user further includes adding or linking at least (i) one or more estimated glucose values ​​associated with a first time window among the multiple time windows and (ii) one or more estimated glucose values ​​associated with a second time window among the multiple time windows to the generated one or more estimated glucose values.

15. The system of claim 13, wherein the one or more estimated glucose values ​​associated with the second time window are generated based at least on at least a portion of the one or more estimated glucose values ​​associated with the first time window provided as input to the estimation model.

16. A processor-implemented method comprising: receiving a plurality of segments of input data associated with a user, the plurality of segments corresponding to respective plurality of time windows, the input data comprising discrete glucose measurement data associated with the user, related data associated with the user, or a combination thereof; and One or more estimated glucose values ​​associated with the user corresponding to at least one of the plurality of time windows are generated in real time using the estimation model and at least a portion of the plurality of segments of received input data associated with the user.

17. The processor-implemented method of claim 11, further comprising controlling an insulin infusion device based on the generated one or more estimated glucose values.

18. A processor-implemented method according to claim 11, wherein generating one or more estimated glucose values ​​associated with a user includes generating multiple estimated glucose values ​​associated with the user, the multiple estimated glucose values ​​including a combination of at least (i) one or more estimated glucose values ​​associated with a first time window among a plurality of time windows and (ii) one or more estimated glucose values ​​associated with a second time window among the plurality of time windows.

19. The processor-implemented method of claim 18, wherein: Generating one or more estimated glucose values ​​associated with the user also includes adding or linking at least (i) one or more estimated glucose values ​​associated with a first time window among the multiple time windows and (ii) one or more estimated glucose values ​​associated with a second time window among the multiple time windows to the generated one or more estimated glucose values.

20. The processor-implemented method of claim 18, wherein: The one or more estimated glucose values ​​associated with the second time window are generated based on at least a portion of the one or more estimated glucose values ​​associated with the first time window provided as input to the estimation model.

Images