Adaptive drug management system

Abstract

The present document discloses an adaptive drug management system for personalized diabetes treatment to a person, comprising at least one of a data collection module configured to store person's blood glucose measurement data and insulin dosage information used to treat the person, a bolus calculator configured to determine a bolus insulin, and a learning module comprising a first agent configured to fine-tune a physiological state (PS) value of the person over time. The system may be configured to retrieve, from the data collection module, the blood glucose measurements taken over a predetermined period, retrieve, from the data collection module, the insulin dosage information used over the predetermined period, update, by the learning module using a reinforcement learning algorithm, the PS value based on the retrieved data, and / or use, by the bolus calculator, the updated PS value to determine the appropriate bolus insulin for the person.

Description

P4292PC00 Specs (AOFF) Adaptive drug management system

[0001] This application claims the priority benefit of [Country] Patent Application No. [application number],filed on [date], in the name of [applicant name], the entire disclosure of which is incorporated herein by reference. Description Technical Field

[0002] The present invention relates to systems and methods for adaptive drug management in the field ofdiabetes care. More specifically, it involves the use of advanced algorithms, such as reinforcement learning (RL), to optimize and personalize drug dosing for people with diabetes (PwD). These systems may be applied across various devices and platforms, including continuous glucose monitors (CGM), insulin pumps, insulin pens, long-acting insulin formulations, and blood glucose monitoring devices such as self-monitoring blood glucose (SMBG), flash glucose monitor (FGM) systems or other types of blood glucose monitors (BGM). The invention aims to improve treatment accuracy and glycemic control regardless of the person's type of diabetes. Background

[0003] Diabetes mellitus is a growing global health challenge, increasingly impacting populations worldwide.Achieving optimal glucose control is essential to reduce the risk of complications and improve the quality of life for individuals with diabetes. For those with type 1 diabetes (T1D) and many with insulin-treated type 2 diabetes (T2D), personalized insulin treatment is the core glucose-lowering therapy.

[0004] Treatment decision support solutions have been developed to assist PwD in optimizing their dailyinsulin dosing. However, the effectiveness of these systems is limited, and many do not achieve recommended targets. Various artificial intelligence-based (AI) approaches have been proposed for personalized adjustment of insulin administration for people with T1D, often within closed or hybrid system settings.

[0005] Approaches such as standard bolus calculators and closed / hybrid loop systems, although effective insome contexts, often require continuous monitoring and frequent manual adjustments by users. These systems do not always account for individual physiological variations in real-time, limiting their overall effectiveness.P4292PC00 Specs (AOFF)

[0006] Currently, the most advanced algorithms heavily rely on CGM data, which provides a large amountof minute-by-minute data. This approach allows a microscopic focus on blood glucose (BG) fluctuations, offering very precise adjustments but requiring ongoing management and interpretation of data. This can lead to information overload for PwD and clinicians and does not always adequately address the broader daily glycemic cycles.

[0007] The central challenge is to develop and validate a diabetes management system that is both effectiveand simplified, aligning insulin dose optimization with people’s daily glycemic cycles while minimizing the complexity of daily management. Current state-of-the-art systems, despite their technological advancements, do not address this issue. They primarily focus on minute adjustments based on CGM data, leading to information overload and frequent manual adjustments. These approaches, although successful, do not sufficiently account for individual physiological variations and overall daily glycemic cycles, thereby limiting their effectiveness and practicality for individuals with diabetes.

[0008] Unlike traditional systems that focus on immediate fluctuations in BG levels, the present documentintroduces the possibility of taking long-term variations into account by exploiting a reduced number of data points over extended periods. This approach simplifies the data collection process while providing information on the person's glycemic behavior. By analyzing BG trends at different times of the day, the system can better adapt to changes in the person's condition, improving long-term treatment results and reducing the need for constant manual adjustments. In addition, the system may comprise a self-learning algorithm to improve treatment day by day. These features ensure that the system evolves with the person's needs over time, making it more robust and easier to manage in the long term. Summary

[0009] Unlike traditional approaches that focus on minute-by-minute adjustments, the present documentdiscloses a solution which adopts a macroscopic perspective aligned with PwD daily glycemic cycles and lifestyle. The solution may offer a personalized decision support approach for adjusting basal and bolus insulin for individuals with T1D and T2D. This approach reduces the complexity of daily management by focusing on overall trends rather than instantaneous fluctuations. Furthermore, the solution enables the system to continuously learn and adapt based on collected data, improving the accuracy of the recommended insulin doses. The system may comprise several specialized agents, each optimizing treatment parameters specific to a period.

[0010] In a first aspect the disclosure relates to a system as defined in claim 1. The present disclosure furtherrelates to embodiments of the system as defined in the dependent claims, which provide additional and advantageous features improving the adaptability and safety of insulin therapy management.P4292PC00 Specs (AOFF)

[0011] According to a first aspect, the present document discloses an adaptive drug management systemfor personalized diabetes treatment to a PwD, comprising: ^a data collection module configured to store person's BG measurement data and insulin dosageinformation used to treat the person, ^a bolus calculator configured to determine a bolus insulin, and^ a learning module comprising a first agent configured to fine-tune a physiological state (PS) value ofthe individual with diabetes over time.

[0012] The system may be configured to:^ retrieve, from the data collection module, the BG measurements taken over a predetermined period,^ retrieve, from the data collection module, the insulin dosage information used over thepredetermined period, ^update, by the learning module using a RL algorithm, the PS value based on the retrieved data, and^ use, by the bolus calculator, the updated PS value to determine the appropriate bolus insulin for theindividual with diabetes.

[0013] The RL algorithm may comprise an actor-critic algorithm. For example, the learning module maycomprise an actor component responsible for improving the control policy and a critic component responsible for evaluating the control policy and providing a temporal difference error for policy optimization.

[0014] The learning module may be configured to:^ update the PS value at mealtimes, or at each meal, or upon announcement of a meal by the personor at the person's request, or ^update the PS value using at least two distinct PS agents specific to different times of the day.

[0015] The learning module may comprise a second agent configured to update the insulin-to-carbohydrateratio (ICR) value, and the system may be configured to use, by the bolus calculator, the ICR value to determine the appropriate bolus insulin for the person's meal.

[0016] The bolus calculator may consider the person's carbohydrate (CHO) intake information indetermining the bolus insulin. The bolus calculator may provide insulin dosage recommendations for both meals and correction boluses.

[0017] The system may be configured to be compatible with multiple types of insulin delivery devices,including insulin pumps and pens.P4292PC00 Specs (AOFF)

[0018] The learning module may comprise a third agent configured to update a basal insulin dosage of theperson with diabetes.

[0019] The data collection module may be configured to receive data from a CGM, a SMBG, and / or otherBGM type.

[0020] The predetermined period may be greater than 12 hours or 24 hours. The data collection modulemay collect data over a period greater than 24 hours.

[0021] The system may comprise an initialization module configured to process the collected data toinitialize a policy parameter vector and select algorithm hyper-parameters based on the collected data. The initialization module may filter collected measurement data using a CGM to initialize hyper- parameters. The initialization module may use transfer entropy to initialize the policy parameter vector.

[0022] The bolus calculator may take into account the insulin-on-board (IOB) when determining theappropriate bolus insulin for the person with diabetes. The bolus calculator may consider a correction factor to adjust insulin dosage based on the person's current BG level.

[0023] The control policy may consist of a linear deterministic policy and a supervisory policy. The final policymay be the weighted sum of the linear deterministic policy (LP) and supervisory policy (SP) wherein the weight is to balance the contribution of LP and SP policy to the final policy of the ICR agents. The linear deterministic policy relates the hypo- and hyperglycemic status to the needed percentage change in the basal insulin, ICR, or PS for the next update. The supervisory policy may provide conservative guidance to ICR agents by acting as a safety measure.

[0024] According to a second aspect, the present document discloses an adaptive insulin managementsystem for personalized diabetes treatment to a person with diabetes, the system comprising: ^a data collection module configured to store person's BG measurement data and insulin dosageinformation used to treat the individual with diabetes, ^a bolus calculator configured to determine a bolus insulin, and^ a learning module comprising a first agent configured to update a PS value of the person and a secondagent configured to update an ICR value.

[0025] The system may be configured to:^ retrieve, from the data collection module, the blood glucose measurements taken over a 24-hourperiod, ^retrieve, from the data collection module, the insulin dosage information used over the 24-hourperiod,P4292PC00 Specs (AOFF) ^update, by the learning module using a RL algorithm, the PS value and the ICR value based on theretrieved data, and ^use, by the bolus calculator, the updated PS value and the updated ICR value to determine theappropriate bolus insulin for the person with diabetes.

[0026] According to one embodiment, the system is designed to operate in cycles (in relation to the person’sown cycle, for example, a daily cycle or longer, depending on the type of insulin used), where each time period consists of several successive events. Instead of relying on precise time measurements, the system uses a sequence of events to determine which data to use (e.g., postprandial measurement from the previous day's dinner). Time is interpreted as a relative variable, separating events and potentially ordering them in the sequence. For example, before updating an agent (such as basal insulin calculation, ICR, PS, or CF), the system may require a new BG measurement if the last one is considered too old (e.g., 60 minutes) before the triggering event. The system can then adjust treatment parameters by considering temporal proximity and event sequence rather than strictly adhering to chronological measures, which might be irrelevant, especially when an event is skipped (e.g., skipping lunch).

[0027] This description introduces a framework where system decisions are dynamic and based onsuccessive events, thereby improving personalized treatment according to the person's actions.

[0028] Additionally, while this document primarily focuses on the use of insulin as a treatment, othermedications may also be employed to enhance the quality of life for patients. These drugs could be integrated into the system to help regulate BG levels in individuals with diabetes. Brief Description of Drawings

[0029] The present disclosure will be better understood in the light of the following detailed descriptionwhich contains non-limiting examples illustrated by the following figures. Figs.1, 2, 3, and 4 show possible embodiments. Fig.5 illustrates how the data can be used to update the basal insulin. Fig.6 and 7 illustrate how the data can be used to update the ICR, PS and / or CF values. Fig.8 shows an algorithmic description of the update and predict functions. Fig.9 shows an example of workflow before the on-line learning. Fig.10 shows an algorithmic description of the ABBA Pipeline.P4292PC00 Specs (AOFF) List of elements1 System2 Delivery device3 BG device4 Controller5 Person6 Data collecting module7 Bolus calculator8 Learning module9 Carbohydrate11 First agent12 Second agent13 Third agent100 Previous day 101 Day 102 Subsequent day 103 Time period 104 Time window 105 Sleeping 106 First data 107 Second data 108 Other measurements 201 Day one 202 Day two 203 Day three 210 Breakfast 211 Lunch 212 Dinner 213 SnackP4292PC00 Specs (AOFF) 214 BG measurements 215 First set of data 216 Second set of data 217 Third set of data 218 Fourth set of data Detailed description

[0030] The following detailed description includes references to the accompanying drawings, which form apart of the detailed description. The drawings show, by way of illustration, specific embodiments in which the disclosure may be practiced. These embodiments, which are also referred to herein as “examples,” are described in enough detail to enable those skilled in the art to practice the disclosure. The embodiments may be combined, other embodiments may be utilized, or structural, logical and electrical changes may be made without departing from the scope of the present disclosure. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims and their equivalents.

[0031] All scientific and technical terms used herein have meanings commonly used in the art unlessotherwise specified. The definitions provided herein are to facilitate understanding of certain terms used frequently herein and are not meant to limit the scope of the present disclosure.

[0032] As used in this specification and the claims, the singular forms "a", "an", and "the" encompassembodiments having plural referents, unless the content clearly dictates otherwise.

[0033] As used in this specification and the claims, any direction referred to herein, such as "top", "bottom","left", "right", "upper", "lower", and other directions or orientations are described herein for clarity in reference to the figures and are not intended to be limiting of an actual device or system unless the content clearly dictates otherwise. Devices and systems described herein may be used in several directions and orientations.

[0034] As used in this specification and the claims, "have", "having", "include", "including", "comprise","comprising" or the like are used in their open-ended sense, and generally mean "including, but not limited to".

[0035] As used in this specification and the claims, the term "or" is generally employed in its sense including"and / or" unless the content clearly dictates otherwise.

[0036] As used in this specification and the claims, "at least one of A, B, and C", "at least one of A, B or C","selected from the group consisting of A, B, C, and combinations thereof" or the like are used in theirP4292PC00 Specs (AOFF) open ended sense including " only A, or only B, or only C, or any combination of A, B and C" unless the content clearly dictates otherwise.

[0037] As used in this specification and the claims, a “meal” is generally employed in its sense including anyoccasion where food / drink is consumed / taken. It can vary in size and content, ranging from snacks to larger, structured food / drink intakes like breakfast, lunch, or dinner. A meal typically provides nourishment at different times of the day.

[0038] As used in this specification and the claims, a “main meal” is generally employed in its sense includingone of the principal eating events during the day, typically consisting of a more substantial portion of food compared to snacks. Examples include breakfast, lunch, or dinner. Main meals generally contain more diverse and nutrient-dense components, playing a key role in a person’s daily caloric intake.

[0039] As used in this specification and the claims, the terms "patient", "individual with diabetes", "personwith diabetes", "PwD", and more broadly "person", refer to any individual living with diabetes, without carrying any negative or stigmatizing connotation. The term "patient" is intended to signify a person receiving medical care, but is used in a respectful and person-centered context. Additionally, "patient" or "person" may be used for brevity and ease of description in the specification or claims. System description:

[0040] Diabetes is a chronic metabolic disorder caused by either the failure of the body to produce insulin -T1D, or the inability of the body to respond adequately to circulating insulin - T2D. Diabetes management is complex and aims at reducing the risk of both short- (e.g., hypo- and hyperglycemia) and long-term complications (e.g., retinopathy, coronary heart disease, nephropathy) by keeping the blood glucose (BG) concentration in the near normal range (glucose control). Self-monitoring of blood glucose (SMBG), continuous glucose monitoring (CGM) and flash glucose monitoring (FGM) are commonly used by PwD to measure glucose concentrations, while for people with T1D and people with T2D under insulin therapy, insulin delivery devices are needed and specifically pens for the case of multiple daily injections (MDI) or pumps for continuous subcutaneous insulin infusion therapy. In any case, PwD under insulin therapy need to visit their physicians every three to four months to check and review the glucose records and perhaps to adjust a) basal insulin, which maintains glucose concentration at consistent levels during periods of fasting, and b) the insulin-to-carbohydrate ratio (ICR), which is essential for calculating the insulin needed to compensate for the effect of the meal (bolus dose).

[0041] The need for better BG control is crucial for all PwD, including underrepresented populations. Thesystem disclosed by the present document aims to provide a clinically validated, effective, trustworthy, and cost-efficient AI-based solution for personalized diabetes management (T1D and T2D) that is independent of specific glucose monitoring or delivery devices. The system may be configured to offerP4292PC00 Specs (AOFF) daily insulin treatment adjustments to ensure optimal glucose control using (for example) a self-learning approach based on reinforcement learning (RL). This approach is data-driven, may operate in real-time, and is of low computational cost. It enables daily adjustment of insulin and throughout the day, whenever a meal event occurs, on the basis of person’s glucose levels fluctuations. Unlike other AI systems that rely on pre-trained models with fixed weights, this system may use on-line learning, allowing the algorithm to dynamically adjust with each new BG measurement, continually refining the suggested values.

[0042] The system disclosed in the present document is configured to meet the needs of all PwD, i.e., bothpeople with T1D and people with T2D under insulin-treatment. Thus, the system is designed to accommodate different devices most suitable for the type of diabetes the person has.

[0043] According to various embodiments as shown by Fig. 1, the system (1) may comprise at least one of adelivery device (2), a BG measurement device (3), and a controller (4). The delivery device (2) is configured to administer a drug solution to a patient (5) according to a specified dosage for treatment. The delivery device (2) may include pens for MDI or pumps for continuous subcutaneous insulin infusion therapy. The BG measurement device (3) is configured to measure the person’s blood glucose levels and may include SMBG devices, CGM systems, or FGM systems.

[0044] The controller may be a part of the delivery device (2) and / or the BG measurement device (3). Thecontroller may be smart phone or a PDA or another distinct device. The controller (4) may be designed to receive data from the BG device (3) and use this data to determine the drug dosage to be administered by the delivery device (2). The controller (4) may comprise advanced algorithms to calculate at least one of an ICR value, a PS value, a bolus insulin, a basal insulin, and a CF, ensuring personalized and precise drug treatment. The system (1) aims to provide comprehensive diabetes management by integrating these components to optimize glucose control and reduce the risk of complications.

[0045] The controller (4) may comprise a data processor and several key components designed to enhancediabetes management and optimize treatment outcomes. These components may comprise at least one of: ^Data collection module (6): This module may be configured to store the person's BG measurementdata and / or insulin dosage information. It ensures that relevant data, including, but not limited to, historical BG levels, insulin doses, carbohydrate intake, and other pertinent health metrics, are accurately recorded and securely stored. ^Bolus calculator (7): The bolus calculator may be configured to determine the appropriate bolusinsulin dose needed to manage blood glucose variation. It may take into account various factors such as one of the ICR, current blood glucose level, target blood glucose level, CF, and IOB.P4292PC00 Specs (AOFF) ^Learning module (8): The learning module may be configured to fine-tune parameters over time. Thelearning module may be configured to use advanced algorithms, such as machine learning and RL. This module may analyze the collected data to adjust at least one of the ICR, PS, and basal insulin values. By learning from the person's unique response patterns, the learning module ensures personalized and adaptive insulin therapy, improving overall diabetes management. The learning module may comprise the ABBA (Adaptive Basal-Bolus Advisor) algorithm.

[0046] In one embodiment, the learning module may be designed for individuals with T1D and / or individualswith T2D. The learning module may be configured for an individual using either CGM, FGM, or SMBG for glucose monitoring. The learning module may be configured for an individual using either pumps or pens for insulin delivery.

[0047] In one embodiment, the controller is a portable device operated by the person with diabetes.

[0048] In one embodiment, the data collection module may be configured to receive and store time-stamped blood-glucose measurements obtained from one or more monitoring devices. Each measurement may be associated with a precise timestamp representing the acquisition time, thereby enabling the system to reconstruct a chronological sequence of glucose data over extended periods. The inclusion of timestamps allows the learning module to relate variations in glucose concentration to specific events, such as meal intake, insulin administration, or physical activity episodes, and to detect temporal patterns including postprandial responses or nocturnal trends. The time-stamped measurements may be received either automatically from connected glucose-monitoring devices or entered manually by the person through a graphical interface, ensuring consistent data alignment for subsequent analysis.

[0049] In certain embodiments, the system may use these timestamps to synchronize blood-glucose datawith other time-dependent information, such as insulin dosages, meal-related entries (at least carbohydrate content), and physiological parameters collected from wearable sensors. The time alignment between these heterogeneous data sources enables the system to analyze relationships between insulin actions and glucose outcomes, supporting the continuous adaptation of model parameters, including the PS value, ICR, and basal insulin profile.

[0050] In one embodiment, the data collection module (6), the bolus calculator (7), and the learning module(8) may be arranged in the controller. In this case, all computations are performed by the processor of the controller.

[0051] In another embodiment, the data collection module (6) and / or the bolus calculator (7) may bearranged in the controller while the learning module (8) may be arranged in a separate device, for example a remote server. This configuration can be advantageous when the computation requires a large amount of resources. In this case, the controller may include a first communication device, and theP4292PC00 Specs (AOFF) remote server may include a second communication device, allowing them to communicate with each other.

[0052] For example, the first communication device may be configured to send the data required for thecomputation to the remote server containing the learning module, and the second communication device may be configured to receive the data from the controller and send back the result of the computation. The first communication device may be also configured to receive the result of the computation.

[0053] In another embodiment, the bolus calculator (7) and the learning module (8) may both be arrangedin a separate device, for example a remote server, as disclosed above. In this case, the data collection module (6) may be configured to gather all data required for the bolus calculator and the learning module and the controller send these data to the remote controller via the first communication device.

[0054] In one embodiment shown in Fig. 2, the system (1) is configured to adapt the insulin managementsystem for personalized diabetes treatment to the individual with diabetes (5). The BG measurement device (3) takes measurements of the person's blood glucose. These measurements may be stored in the data collection module of the controller (4). The data collection module may further store at least one of the dosage / delivery information used by the delivery device (2) to administer the insulin (basal insulin or bolus insulin) and the carbohydrate (9) intake by the person. The controller (4) is configured to gather these data to fine-tune at least one agent of the learning module (also referred to as ABBA).

[0055] According to an embodiment, the system may be configured to personalize at least one of the bolusinsulin and the basal insulin. The past and current BG measurements and carbohydrates (CHO) intake information may be needed to compute the bolus insulin. For the calculation, it uses the bolus calculator (^^^^^^^^) formula and adapts the ICR and the current PS of the subject as follows:

[0056] The PS is subject to large intra- and inter-individual variation, and since there is no researchsupporting quantification of the proportion, the patient is left to a trial-and-error approach. Differently, the system may be configured to adapt the PS factor based on the glycaemia profile of the subject. Finally, if insulin from previously administered boluses is still active, IOB may be subtracted.

[0057] In one embodiment, the learning module may comprise only one agent or two or more agents. Asshown in Fig.3, the learning module (8) of the controller (4) may comprise at least one of the following: ^a first agent (11) may be configured to fine-tune the PS value of the person over time. This agent maybe configured to adapt the final bolus insulin dose in response to changes in the glucose profile. ^a second agent (12) may be configured to fine-tune the ICR value of the person over time, andP4292PC00 Specs (AOFF) ^a third agent (13) may be configured to fine-tune the basal insulin value.

[0058] The first and second agents may also be referred to as bolus agents, while the third agent may bereferred to as the basal agent.

[0059] In one possible embodiment, the learning module may further comprise a fourth agent configuredto fine-tune a correction factor of the person over time.

[0060] In one embodiment, the learning module may further comprise one or more fifth agents configuredto estimate and update insulin recommendations in view of at least one physiological or behavioral parameter. These fifth agents, also referred to as context-adaptation agents, are designed to capture transient or longer-term variations in insulin sensitivity that are not directly explained by glucose or meal data. Their purpose is to provide compensatory adjustments to insulin recommendations by interpreting additional physiological or behavioral information indicative of the person’s metabolic condition.

[0061] The fifth agents may receive as input a set of physiological and behavioral parameters representativeof the individual’s current or recent physical and emotional state. Such parameters may include, but are not limited to, a physical-activity parameter, an illness-related parameter, a sleep-quality parameter, a stress-level parameter, a heart-rate parameter, a heart-rate-variability parameter, a respiratory-rate parameter, a body- or skin-temperature parameter, a body-weight parameter, a blood-pressure parameter, an oxygen-saturation parameter, or a galvanic-skin-response parameter. These parameters may be measured continuously or intermittently by one or more sensors integrated in a wearable or portable device, such as a smartwatch, activity tracker, chest strap, or connected medical sensor, or may be manually input by the person through a graphical user interface.

[0062] For example, the physical-activity parameter may be derived from accelerometer or gyroscope data,providing information about step count, energy expenditure, or overall movement intensity. The heart- rate and heart-rate-variability parameters may be measured using photoplethysmography (PPG) sensors or electrocardiogram (ECG) modules. Respiratory rate may be obtained from changes in thoracic impedance, chest movement, or indirect estimation from heart-rate variability patterns. Body or skin temperature and oxygen saturation (SpO₂) may be detected through optical or infrared sensors. Sleep- quality and sleep-staging parameters may be estimated using a combination of movement, heart-rate variability, and temperature signals, or derived from connected sleep-tracking devices. Stress-level parameters may be inferred from physiological markers such as increased heart-rate variability or galvanic skin response. Illness-related parameters, such as fever or reduced activity, may be inferred automatically from body temperature deviations or manually declared by the user via the interface.

[0063] Each fifth agent may be configured to associate these physiological and behavioral parameters withvariations in insulin sensitivity or metabolic demand. For instance, increased physical activity typically enhances insulin sensitivity, potentially reducing the need for exogenous insulin, whereas illness,P4292PC00 Specs (AOFF) infection, or stress can cause temporary insulin resistance, requiring a higher insulin dosage to maintain glycaemic control. Sleep quality and circadian timing may also influence the hormonal regulation of glucose, particularly through variations in cortisol and growth hormone secretion during the night. By learning from these contextual signals, the fifth agents enable the system to anticipate short-term fluctuations and adjust insulin recommendations preemptively rather than reactively.

[0064] The fifth agents may operate in real time or in an asynchronous update mode, depending on thesampling frequency and reliability of the contextual data. Their outputs may take the form of an adaptive coefficient or offset applied to the insulin recommendation generated by the first, second, or third agents. In certain embodiments, the contribution of the fifth agents is weighted based on the reliability or importance of the corresponding parameter—for example, assigning greater influence to activity and temperature during the day, and to sleep and stress metrics during the night. Over time, the system learns person-specific correlations between contextual signals and glycaemic outcomes, allowing finer personalization of insulin therapy and improved prevention of hypo- or hyperglycemic events.

[0065] The data collection module (6) may be configured to gather data and send it to one or more agents.

[0066] The bolus calculator module (7) is configured to receive the data sent by the first and / or secondagents (e.g., PS and ICR) to compute the bolus insulin dose. The bolus calculator may further take into account a correction factor and / or IOB value.

[0067] In one embodiment, the bolus calculator may determine the bolus-insulin dose using a formula thatincludes a scaling factor corresponding to the PS value, in combination with an ICR, a CF, and an IOB value. The PS value acts as a dynamic multiplier modulating the calculated insulin requirement based on recent metabolic conditions, while the ICR ratio provides a baseline for meal-related insulin demand. The CF may compensate for deviations from the target glucose level, and the IOB value may account for residual active insulin from previous doses. This combination allows the system to generate insulin recommendations that are both physiologically responsive and temporally consistent, thereby improving dosing accuracy and minimizing glycaemic excursions.

[0068] In one embodiment, the data collection module may be configured to receive, via manual entryand / or automatic import, time-stamped blood-glucose measurements, insulin-therapy information, food-intake and nutrient-composition data, lifestyle signals such as sleep, physical activity, and stress, and person-specific contextual information including age, sex, body-mass index, years since diagnosis, and physician recommendations on insulin therapy. The data may be acquired from glucose sensors (CGM, FGM, or SMBG), insulin-delivery devices, wearable activity monitors, or user input through a graphical interface. The inclusion of both objective sensor data and contextual parameters enables the system to establish temporal and behavioral correlations between glucose variability and influencingP4292PC00 Specs (AOFF) factors. This integrated dataset provides a comprehensive view of the person’s metabolic profile, allowing the learning module to generate more accurate and adaptive insulin recommendations.

[0069] Fig. 4 shows a diagram of one embodiment using an actor-critic for each agent. The learning modulemay comprise at least 2 (e.g., 3) distinct first agents and / or at least 2 (e.g., 3) distinct second agents. Each agent may be specific for time of the day (e.g., Breakfast, Lunch, Dinner, Snack, …).

[0070] In one embodiment, the learning module may comprise a plurality of first agents, each configured toestimate and update a PS value of the person. The distinct first agents may correspond to different times of the day or specific meal events such as breakfast, lunch, or dinner. Each agent may operate on data collected within its respective time window, thereby capturing variations in insulin sensitivity and glucose response linked to circadian and metabolic factors. The separation of agents allows independent adaptation of the PS value for each period while maintaining a coherent RL framework shared across all agents. This structure enables context-specific optimization of the bolus insulin dosage without interference between unrelated time intervals.

[0071] In one embodiment, the learning module may comprise a plurality of second agents, each configuredto estimate and update an ICR specific to a defined meal or time of day. Each second agent may learn from historical glucose responses to carbohydrate intake associated with its corresponding meal period, allowing the system to adapt the ICR independently for breakfast, lunch, dinner, or other recurring eating events. By maintaining separate ICR agents, the system can account for physiological variations, for example in postprandial glucose metabolism while avoiding cross-influence between distinct meal contexts. This structure supports individualized and context-aware optimization of meal-related insulin recommendations.

[0072] The system may be configured to update at least one of the ICR and the PS value for example for,before or after the meal. The algorithm may be configured to update the basal insulin before the injection of the basal insulin by performing a real-time update. In the case of ICR and PS, the system may comprise three different agents for the ICR and three other agents for the PS: one for breakfast, one for lunch, and one for dinner.

[0073] In one embodiment, the determination of the appropriate bolus insulin dosage may be triggeredautomatically when the system detects a deviation in BG levels exceeding a predefined glucose threshold, or manually upon receipt of a user-input event. The glucose threshold may correspond to a limit associated with hyperglycemia, hypoglycemia, or a deviation from the person’s defined target range. This configuration allows the system to initiate dosage recalculation only when a significant metabolic variation occurs, improving therapeutic precision and computational efficiency. Furthermore, the option for user-triggered activation provides flexibility for the person or healthcare provider to initiate recalculation in specific situations such as meals, intense physical activity, or intercurrent illness.P4292PC00 Specs (AOFF)

[0074] In one embodiment, the system may apply predefined safety constraints comprising upper and lowerdose limits that are dynamically adjusted based on recent glucose trends and IOB calculations. The upper limit may prevent excessive insulin recommendations in cases of persistent hyperglycaemia or overlapping boluses, while the lower limit may avoid underdosing when residual insulin activity is minimal.

[0075] In one embodiment, the system may comprise actor-critic (AC) algorithm, a type of RL algorithms,which may be characterized by two complementary agent parts: the critic, responsible for evaluating the control policy, and the actor, responsible for improving it. The first agent may comprise an AC algorithm configured to fine-tune the PS value of the person over time, the second agent may comprise an AC algorithm configured to fine-tune the ICR value of the person over time, and the third agent may comprise an AC algorithm configured to fine-tune the basal insulin of the person over time. Nevertheless, in another embodiment, other types of algorithms can be used by the first, second and third agents.

[0076] In one embodiment, the PS value may be a derived parameter representing a dynamic scaling factorused in the bolus insulin dosage determination. The PS value may act as a multiplicative coefficient applied to the computed insulin dose, thereby modulating the output of the bolus calculator in view of transient variations in the person’s insulin sensitivity. These variations may result from factors such as physical activity, stress, illness, hormonal changes, circadian rhythm, or sleep deprivation, which are known to influence the effectiveness of administered insulin. The PS value thus serves as an adaptive correction factor that enables individualized insulin therapy without requiring manual recalibration by the person or healthcare provider.

[0077] The PS value may be determined based on historical and recent blood-glucose data, includingpostprandial readings associated with specific meal events. The learning module may compute an updated PS value after each meal or defined time window using RL techniques that optimize the correspondence between observed glucose outcomes and expected insulin responses. If the measured glucose trajectory indicates reduced insulin effectiveness, the PS value may be gradually increased, while if a heightened sensitivity is detected, the PS value may be decreased accordingly. This mechanism allows the system to progressively align its dosing recommendations with the person’s physiological evolution over time.

[0078] In certain embodiments, the PS value may be expressed as a dimensionless coefficient normalizedwithin a predetermined range, for example between 0.5 and 2.0, where a nominal value of 1.0 corresponds to the baseline condition. The normalization range may be constrained by predefined safety limits that prevent over- or under-compensation. The adaptive nature of this parameter allows it to capture short-term physiological deviations while maintaining coherence with longer-term therapeutic objectives. By integrating the PS value into the bolus calculation, the system may dynamically tailorP4292PC00 Specs (AOFF) insulin delivery to the person’s current physiological condition, contributing to more stable glucose control. Basal Insulin:

[0079] In one embodiment, the system is configured to adjust the basal insulin administration at apredetermined frequency. This frequency may be once per time period which may be comprised between 12 to 24 hours, or extend beyond 24 hours, for example depending on the type of insulin used. The time period is an approximate range and should not be interpreted down to the second, or the minute or the hour. For example, a 24-hour period allows for a flexibility of + / - 1 or 2 hours.

[0080] In one embodiment, the system may be configured to adapt the frequency to the type of insulin tobe injected (via a pump or a pen). For example, it can support short-acting insulin, daily insulin, or ultra- long-acting insulins such as Tresiba® (insulin degludec) and Icodec (both are trademark owned by Novo Nordisk, where a single injection can cover a period of 42 hours or seven days, respectively). The system may be configured to adjust the time period based on the type of insulin, with the user interface (GUI) allowing the selection of either a time period or insulin type.

[0081] The time period may determine when the basal insulin needs to be updated. For instance, if the timeperiod is set to 24 hours, at the end of this 24-hour period, the system may be configured to update the basal insulin either automatically or based on a user-initiated action or event.

[0082] The system may comprise a time window during which the user can manually initiate the updatingof the basal insulin. For example, the user can define a time window between 9:00 PM and 11:00 PM during which the user can request the basal insulin update. Therefore, if the time period is set to 24 hours, every night, the user can request the basal insulin update. In another case if the time period is set to 24 hours and the time window is comprised between 6:00 AM and 10:00 AM, then every morning the user can request the basal insulin update. This time window may be fixed and repeat daily or according to a defined period.

[0083] The system may be configured to open a time window at a determined frequency, during which theperson must or can initiate the basal insulin update. In one embodiment, the system may be configured to select the data used in calculations based on the time period and / or recorded events (meals, fasting periods, sleep, time windows, etc.).

[0084] Fasting can play a significant role in diabetes management, as during this period, the PwD do notneed to compensate for CHO intake (from meals) with rapid-acting insulin (bolus insulin). Additionally, sleep is another key factor, since inactivity means that BG levels are solely influenced by the person's metabolism. The difference between these two measurements can provide valuable insight into theP4292PC00 Specs (AOFF) person's metabolic glucose needs, enabling more precise basal insulin recommendations. The system can be configured to account for these events by retrieving and identifying BG data before and after sleep.

[0085] Fig. 5 shows the time with d-1 (100), d (101), and d+1 (102). In this example, the time period (103) isset to 24 hours, the time window (104) is between 8:00 PM and 10:00 PM, and the person sleeps (105) at varying times. The first data (106) may be the BG measurement taken before sleep (this measurement may be defined as the last one before sleep), the second data (107) may be the BG measurement taken after sleep / wake-up (this measurement may be defined as the first one after sleep / wake-up), and the other measurements (108) are performed throughout the time period.

[0086] In this example, the data collection module may comprise a plurality of BG measurements taken (forexample, at sporadic moments) during the time period. The controller may be configured to identify / define which of these measurements was taken before (e.g., just before) sleep and which one was taken after (e.g., just after) sleep (or wake up).

[0087] The process may comprise at least one of the following steps:^ Collect a plurality of BG measurements taken during the time period,^ Identify, from the plurality of BG measurements, a first data (106) which is the BG measurementtaken before sleep of the time period (or a last measurement before sleep of the time period), ^Identify, from the plurality of BG measurements, a second data (107) is the BG measurement takenafter sleep / wake-up of the time period (or a first measurement before sleep of the time period), and ^Update the basal insulin (which may be used for a next time period), based on the first data (106)and the second data (107), or ^Update the basal insulin (which may be used for the next time period) based on the first data (106)and the second data (107) and other data from the plurality of BG measurements; ^Optionally if the update fails or cannot be computed, retrieve and recommend the last fine-tunedbasal insulin value.

[0088] The controller may be configured to select which measurements need to be taken into account forthe update. The first and second data may be taken into account by the controller in such a way that they are given more weight (higher importance) than the other measurements in the update calculation.

[0089] If the time period comprises several sleep periods, the controller may be configured to determinethe corresponding measurements for each sleep period, namely the last measurement taken before each sleep phase and the first measurement taken after each sleep phase.

[0090] According to one possible embodiment, the system may comprise:P4292PC00 Specs (AOFF) ^a data collection module configured to store at least one of a plurality of data related to person's BGmeasurement and insulin dosage information used to treat the PwD, ^a learning module comprising an agent configured to fine-tune a basal insulin value for a person overtime;

[0091] The system may be configured to (optionally, following the person's initiation action)^ Retrieve, from the data collection module, a plurality of data relating to BG measurements takenover a predetermined period, ^Optionally, retrieve, from the data collection module, the insulin dosage information used over thepredetermined period, ^Identify, from the plurality of data, a first data (106) as a last measurement before sleep of thepredetermined period, ^Identify, from the plurality of data, a second data (107) as a first measurement after sleep of thepredetermined period, and ^Update, by the learning module, the basal insulin value based on the first data and the second data,^ Optionally if the update fails or cannot be computed, retrieve and recommend the last fine-tunedbasal insulin value.

[0092] Optionally, the system may be configured to open a time window at a determined frequency, toallow the person to initiate the basal insulin update.

[0093] In one embodiment, if the user does not initiate the update during the designated time window, orif the system cannot update the basal insulin due to missing data (for example), the system (since it is designed to improve the recommendation over time) may be configured to suggest the previous recommendation. In other words, if an issue occurs for the computation of the basal insulin dose, the system may be configured to recommend or display the most recent basal insulin dose to the user. Bolus Insulin:

[0094] In one embodiment, the system is configured to calculate or recommend the insulin bolus. An insulinbolus can be administered to regulate the person's BG, particularly when the person eats. Typically, a person consumes at least two main meals and possibly one or more snacks. Main meals generally include breakfast, lunch, and / or dinner, while other smaller meals are considered snacks. Since each meal type impacts the person's metabolism differently, insulin requirements may vary based on the type of main meal consumed. Therefore, the bolus calculator of the system may be configured to take into account the ICR and / or the PS of the PwD.P4292PC00 Specs (AOFF)

[0095] In order to adapt the bolus insulin to the person with diabetes and to the meal type, the learningmodule may be configured to finetune at least one of the ICR the PS, and the CF for example at each meal (e.g., at each main meal). In this case, the system may comprise: ^a data collection module configured to store at least one of a plurality of data related to person's BGmeasurement and insulin dosage information used to treat the person, ^a learning module comprising at least one of a first agent configured to fine-tune a PS value for aperson over time, and a second agent configured to fine-tune an ICR value for a person over time.

[0096] The system may be configured to allow the person to initiate the update of ICR and / or the PS. In thiscase, the system may comprise a GUI that enables the person to announce a meal event. For example, the GUI may comprise a screen on which the patient can announce a meal. The GUI may display at least 2 types of meal. The type of meal may comprise at least one of a main meal and a snack. The GUI may display at least two main meals (for example: breakfast, lunch, and / or dinner) and optionally a snack. If a main meal is selected by the person, the system may be configured to initiate the update of the ICR and / or PS. If a snack is selected by the person, the system may be configured to use the last fine-tuned ICR and / or PS to calculate the bolus insulin.

[0097] In one possible embodiment, the system is configured to update at least one of the ICR, PS, and CFat each or depending on the main meals.

[0098] Fig. 6 shows day one (201) and day two (202), the main meals (breakfast (210), lunch (211), anddinner (212)) and snacks (213) consumed by the person, and the BG measurement (214). At lunch (211) of day two (202), the PwD announces the meal (here a lunch (211)). In this example the current meal is lunch on day two.

[0099] The system may be configured to:^ Retrieve, from the data collection module, a plurality of data relating to the BG measurements takenover a predetermined period, ^Optionally, retrieve, from the data collection module, the insulin dosage information used over thepredetermined period, ^Identify, from the plurality of data, a first set of data (215) comprising BG measurement taken aftera determined type of meal, ^Identify, from the plurality of data, a second set of data (216) comprising BG measurement takenbefore the same determined type of meal. ^Update, by the learning module, the ICR and / or the PS value (and / or CF value) based on the first setof data and the second set of data,P4292PC00 Specs (AOFF) ^Optionally if the update fails or cannot be computed, retrieve the last fine-tuned ICR and / or PS value(for example from the last corresponding meal type (here Lunch)).

[0100] The determined type of meal may be similar to the type of current meal.

[0101] The first set of data may comprise (e.g., only) BG measurement (for example at least one) takenbetween two consecutive eating events (for example two consecutive main meals). The BG measurement may be the one closest to the meal, for example, the first measurement taken after the meal.

[0102] The second set of data may comprise (e.g., only) BG measurement (for example at least one) takenbetween two consecutive eating events (for example two consecutive main meals). The BG measurement may be the one closest to the meal, for example, the last measurement taken before the meal.

[0103] If the person announces a snack, the system may be configured to use the last finetuned ICR, PS,and / or CF value to calculate the insulin bolus or the same value(s) use to calculate the last insulin bolus.

[0104] In one embodiment, the system may finetune the values using (e.g., only) data relating to previousmeal(s). In this case, the system may be configured to: ^Retrieve, from the data collection module, a plurality of data relating to the BG measurements takenover a predetermined period, ^Optionally, retrieve, from the data collection module, the insulin dosage information used over thepredetermined period, ^Identify, from the plurality of data, a first set of data (215) comprising BG measurement taken aftera determined type of past meal, ^Identify, from the plurality of data, a second set of data (216) comprising BG measurement takenbefore the same determined type of past meal. ^Update, by the learning module, the ICR and / or the PS value (and / or CF value) based on the first setof data and the second set of data, ^Optionally if the update fails or cannot be computed, retrieve the last fine-tuned ICR, PS value and / orCF value (for example from the last corresponding meal type (here Lunch)).

[0105] The determined type of past meal may be similar to the type of current meal.

[0106] For example, to finetune the ICR, PS, and / or the CF used to calculate the insulin bolus for lunch onday two (202), the first set of data may comprise (e.g., only) BG measurements taken between lunch and dinner on a previous day (e.g., day one) while the second set of data may comprise (e.g., only) BG measurements taken between the breakfast and the lunch on a previous day (e.g., day one). The previous day for the first set of data may be the same (or another) as the previous day for the second set of data.P4292PC00 Specs (AOFF)

[0107] In one embodiment, the system may finetune the values using data relating to previous meal andcurrent meal. In this case, the system may be configured to: ^Retrieve, from the data collection module, a plurality of data relating to the BG measurements takenover a predetermined period, ^Optionally, retrieve, from the data collection module, the insulin dosage information used over thepredetermined period, ^Identify, from the plurality of data, a first set of data (215) comprising postprandial BG measurementtaken after a previous similar meal, for example: a meal on a previous day, where the meal is of the same type as the current meal (for example, lunch on the previous day when the current meal is lunch), ^Identify, from the plurality of data, a second set of data (216) comprising pre-prandial BGmeasurement taken before the current meal (for example the current lunch). ^Update, by the learning module, the ICR, PS value, and / or CF value based on the first set of data andthe second set of data, ^Optionally if the update fails or cannot be computed, retrieve the last fine-tuned ICR and / or PS value(for example from the last corresponding meal type (here Lunch)).

[0108] The first set of data may comprise (e.g., only) the BG measurements taken between two consecutiveeating events (for example two consecutive main meals), where the first eating event (of these two consecutive eating events) is a previous similar meal for example, the meal occurred the previous day and which is similar to the current meal.

[0109] The second set of data may comprise (e.g., only) the BG measurements taken between twoconsecutive eating events (for example two consecutive main meals), where the second eating event (of these two consecutive eating events) is the current meal.

[0110] For example, the first set of data comprises only the BG measurements taken between lunch anddinner on the previous day (day one) while the second set of data comprises only the BG measurements taken between the breakfast (on the current day) and the current lunch (day two).

[0111] In one embodiment, if the person announces a snack, the system may be configured to use the lastfine-tuned ICR, PS value, and / or CF value to calculate the insulin bolus. For example, for the snack (213) taken on day two, the bolus calculator will use the ICR and / or PS values that were updated at lunch on day two.P4292PC00 Specs (AOFF)

[0112] Fig. 7 also shows day three (203). In this example, the current meal is lunch on day three. In thisembodiment, the learning module may take into account the BG measurement taken after a similar type of lunch from the previous day.

[0113] In one embodiment, the system may be configured to:^ Retrieve, from the data collection module, a plurality of data relating to the BG measurements takenover a predetermined period, ^Optionally, retrieve, from the data collection module, the insulin dosage information used over thepredetermined period, ^Identify, from the plurality of data, a first set of data (215) comprising postprandial BG measurementstaken after a previous similar meal, for example: a meal on a previous day, where the meal is of the same type as the current meal (for example, lunch on the previous day when the current meal is lunch), ^Identify, from the plurality of data, a second set of data (216) comprising pre-prandial BGmeasurements taken before the current meal (for example the current lunch). ^Identify, from the plurality of data, a third set of data (217) comprising postprandial BGmeasurements taken after a meal at least two days ago, where the meal is of the same type as the current meal (for example, lunch from two days ago when the current meal is lunch), ^Identify, from the plurality of data, a fourth set of data (218) comprising pre-prandial BGmeasurements taken before a meal on the previous day, where the meal is of the same type as the current meal (for example, lunch on the previous day when the current meal is lunch), ^Update, by the learning module, the ICR and / or the PS value based on the first set of data, the secondset of data, the third set of data, and the fourth set of data, ^Optionally if the update fails or cannot be computed, retrieve the last fine-tuned ICR and / or PS value(for example from the last corresponding meal type (here Lunch)).

[0114] As previously explained, the first set of data may comprise (e.g., only) the BG measurements takenbetween two consecutive eating events (for example two consecutive main meals), where the first eating event (of these two consecutive eating events) is a previous similar meal for example, the meal occurred the previous day and which is similar to the current meal.

[0115] As previously explained, the second set of data may comprise (e.g., only) the BG measurements takenbetween two consecutive eating events (for example two consecutive main meals), where the second eating event (of these two consecutive eating events) is the current meal.P4292PC00 Specs (AOFF)

[0116] The third set of data may comprise (e.g., only) the BG measurements taken between two consecutiveeating events (for example two consecutive main meals), where the first eating event (of these two consecutive events) is a previous similar meal for example, the meal occurred at least two days ago, and which is similar to the current meal.

[0117] The fourth set of data may comprise (e.g., only) the BG measurements taken between twoconsecutive eating events (for example two consecutive main meals), where the second eating event (of these two consecutive eating events) is a previous similar meal for example, the meal occurred the previous day and which is similar to the current meal.

[0118] The difference with the prior art device is fundamental. Here, the system is configured to accountfor events rather than time itself. Each event is categorized and represents a specific step.

[0119] In one embodiment, the data collection module may comprise a first buffer memory to store the firstdata set and a second buffer memory to store the second data set. The data collection may further comprise a third buffer memory to store the third data set and a fourth buffer memory to store the fourth data set.

[0120] In one embodiment, for each main meal, the system may be configured to assign a specific first agentand second agent. In other words, the learning module may include three distinct first agents (one for each main meal) and three distinct second agents (one for each meal). Therefore, the system may be configured to fine-tune each of these agents over time. For example, for lunch, the system may have a lunch first agent and a lunch second agent, both of which are fine-tuned over time by the learning module.

[0121] In one embodiment, if the previous similar meal was skipped, the system may be configured toidentify data from a similar meal before that.

[0122] In one embodiment, if the user does not initiate the update or if the system cannot update the ICRor PS value due to missing data (for example), the system (since it is designed to improve the recommendation over time) may be configured to use the last finetuned ICR or PS value for a similar meal. System State

[0123] The system may be configured to for example daily update over a set of ^^ = |D| days with each dayindexed with k (k ∈ ^^ = {1, ... ,^^}). The basal agent may be updated once per day. On each day k, thesystem may be configured to update the bolus agents ^^^^ = |ℳ| times with each update ^^ ∈ ℳ =Note that the total number of meal updates ^^^^ may vary across days, e.g., skippingbreakfast is allowed. In this work, we fix ^^^^ = 3, one for each meal. Finally, BG measurements recordedfor an update ^^ are indexed as ^^ ∈ ℬ = {^^^^^^ , ^^^^^^ + 1, ... , ^^^^^^} and for an update ^^ as ^^ ∈ ^^ =P4292PC00 Specs (AOFF) {^^^^, ^^^^ + 1, ... ,^^^^}. The number of measurements per update may vary. For example, on one afternoon,the person might document three readings (one after a meal and two additional ones), whereas on another afternoon, only the post-prandial measurement may be recorded. In this manner, the system may be configured to adapt to a variable number of measurements per step.

[0124] Now, define the glucose error ^^∆ with respect to a measurement as:

[0125] with ^^ℎ = 180 ^^^^ / ^^^^ and ^^^^ = 70 ^^^^ / ^^^^ are respectively the hyper- and hypoglycaemia bounds.The building block of the system state and cost is the feature vector ^^ ∈ ℝ2. For the basal agent, ^^^^ iscomputed as:

[0126] meaning that all recorded measurements over a day, including the bolus recordings, are included.For the bolus agents the features ^^^^ are computed as:

[0127] For both cases, ^^ℎ is the number of samples above the hyperglycaemia and ^^^^ below thehypoglycaemia thresholds. Also, the features may be normalized into the range [0, 1].

[0128] Different states may be designed for each group of agents to provide more relevant information andimprove prediction ability. The Basal agent implements the state ^^^^^^^^^^ ∈ ℝ4 as:^^^^^^^^^^^^^^ = [^^k ,^^^^]

[0129] with ^^^^ containing features quantifying the difference in BG between morning and nightmeasurements. More rigorously, ^^^^ ∈ ℝ2 and is defined as:

[0130] Note that the subscript ^^ = ^^^^^^ indicates the first-morning measurement of the current day and^^^^1 = 90 mg / dL. Simply speaking, the components of ^^^^ are different from zero if overnight a hypo- orhyperglycaemic event has occurred. As described above in one embodiment, there may be three ICRs. In this case, the state of the ICR agents with ^^ < ^^^^, i.e., the breakfast and lunch agents, the state is:^^^ ^^^<^^^^^^^^ = ^^tP4292PC00 Specs (AOFF)

[0131] In the case of ^^ = ^^^^, meaning the ICR for the dinner meal, the state is modified as follows:^^^ ^^^^=^^^^^^^ = [^^t , ^^^^]

[0132] The difference between morning and night measurements may be also concatenated. In summary,

[0133] Design of the Cost Function

[0134] ABBA minimizes a modified version of the original cost function. The cost collected after the executedaction is:

[0135] where ^^ = [^^ℎ^^^^^^ ,^^ℎ^^^^^^^^] is a vector containing the weights ^^ℎ^^^^^^ and ^^ℎ^^^^^^^^ used for scaling thehypo- and hyperglycaemia components. Simply speaking, the cost is proportional to the features after the performed action. For people with T1D, the aim may be to minimize the hypoglycemia events. Thus, the weights may be chosen as ^^ℎ^^^^^^^^ = 1 and ^^ℎ^^^^^^ = 10. On the other hand, in the case of peoplewith T2D, the goal may be to reduce the hyperglycemia events. Therefore, the weights may be chosenDesign of the Critic

[0136] The critic agent may be configured to assess the current control policy by estimating the long-termexpected cost. The critic component of the system may be updated as detailed below. It provides temporal difference (TD) error to the actor for policy optimization, expressed as: ^^{^^,^^} = ^^{^^+^^,^^+^^} + ^^ ∙ ^^^^(^^{^^+1,^^+1}) − ^^^^(^^{^^,^^})

[0137] is the value function. ^^^^(^^{^^,^^}) is parametrised= ^^ ∙ ^^{^^,^^} with ^^representing the parameter vector ^^. The critic parameter vector ^^ may be randomly initialized at thebeginning and updated according to:

[0138] where ^^^^^^ denotes the learning rate and ^^{^^,^^} is the eligibility vector updated as follows:

[0139] with ^^ being the eligibility trace decay factor.P4292PC00 Specs (AOFF) Design of the Actor

[0140] The actor agent may be configured to optimize the control policy in order to minimize the long-termcost. The control policy (P) may comprise at least one of the linear deterministic policy (LP) and the supervisory policy (SP). Specifically, the linear deterministic policy may relate the hypo- and hyperglycemic status to the needed percentage change in the Basal, ICR, or PS for the next update. LP is implemented by a linear layer parameterized by ^^:

[0141] The supervisory policy provides conservative guidance to ICR agents by acting as a safety measure.It is described as follows:

[0142] with ^^^^^^ working as a hyper-parameter to balance the influence of the correction.

[0143] Therefore, the final policy may be the weighted sum of the linear deterministic and supervisorypolicy: ^^^^ = ^^^^^^ ∙ ^^^^^^ + (^^ − ^^^^^^) ∙ ^^^^^^

[0144] where ^^^^^^ may be defined as follows:

[0145] In one embodiment, the role of ^^^^^^ is to balance the contribution of LP and SP policy to the finalpolicy of the ICR agents. When the features are in range, the weighting factor αLP is deliberately set to 0, ensuring that the LP policy remains unweighted. Otherwise, equal contributions to both policies areensured when the features overcome this range. In the case of the basal and PS agents, the final policy is equal to the linear policy.

[0146] The actor’s policy parameters θ may be updated by following the policy gradient ^^{^^,^^}, which, havinga linear policy, simply corresponds to:

[0147] is the TD error. We employ the Adam optimiser with learning rate ^^^^^^ to solve theoptimization problem.P4292PC00 Specs (AOFF) Action

[0148] For the ICR and PS agents, the final action prediction may be according to the following formula:^^^^ = ^^^^,^^−1 + ^^ ∙ ^^^^ ∙ ^^^^,^^−1

[0149] For the basal agent, the action may correspond to:^^^^ = ^^^^−1 + ^^ ∙ ^^^^ ∙ ^^^^−1

[0150] where ^^ may be experimentally chosen to be 0.5 for T1D and 1.0 for T2D. In this manner, the systemmay be configured to recommend the basal insulin, ICR, or PS, depending on the specific agent in use. The action space for at is a continuous value inwhere ^^^^^^^^^^ represents the initial valuefrom the simulator or physician in real-life settings. To ensure safety, the basal insulin action may be set to at least 25% of the previous day’s Total Daily Dose (TDD).

[0151] For example, Fig. 8 shows an algorithmic description of the update and predict functions.Adaptive optimizer

[0152] The Adam optimizer may be used during the online learning phase (for example) to update at leastone of the actor’s policy parameters θ, ensuring efficient and adaptive learning. Unlike other algorithm that relied on a static learning rate, Adam introduces dynamic adjustments to the learning rate by leveraging first-order momentum (the running average of gradients) and second-order momentum (the running average of squared gradients). This allows the algorithm to adapt more effectively to the changing landscape of the optimization problem, making it particularly well-suited for complex environments such as actor-critic learning dynamics where the scale of gradients can vary significantly over time. Data collection and initialization workflow before on-line learning

[0153] Fig. 9 shows an example of workflow before the on-line learning and Fig. 10 shows an algorithmicdescription of the ABBA Pipeline.

[0154] Phase 1 - Data Collection: The first phase may be the data collection, which may last for two weeks.In this phase, the person with diabetes employs the standard treatment. The person follows the insulin suggestion from the bolus advisor with the values of ICR, CF, and basal insulin provided by the simulator for T1D or by standard equations for T2D. During this phase, the collected data may be at least one of the CGM measurements and insulin dosage information data.P4292PC00 Specs (AOFF)

[0155] For individuals with diabetes requiring insulin treatment to maintain their blood glucose levels withinthe safe normoglycemic range, it is recommended to administer slow-acting insulin injections once or twice daily to control fasting blood glucose levels, along with fast-acting or bolus insulin injections before meals to mitigate postprandial glucose spikes. For the data collection period, the bolus insulin may be calculated with the formula of standard BC defined as: ^^ − ^^^^C  =  ^^^^^^  +   ^^ ^^^^^^^^ ^^^^   − ^^^^^^

[0156] where CHO (g) is the meal carbohydrate intake, ICR (g / U) and CF (mg / dL / U), respectively are theinsulin-to-carbohydrates ratio and the correction factor, i.e., two therapy parameters may be tuned by clinicians, Gc (mg / dL) is the mealtime BG level, Gt (mg / dL) is the target BG level, and IOB (U) is the insulin on board, indicating the previously injected insulin that is still acting in the organism.

[0157] Phase 2 – Initialization: The second phase may be the initialization, which may be occurred after datacollection and before starting on-line learning. The collected data may be used to 1) initialize the policy parameter vector of the system algorithm and 2) select the algorithm hyper-parameters based on the personalized CGM data.

[0158] To guarantee safety, the initial values for the ICR, CF, and basal insulin may be specific andappropriate for each person. When implemented in clinical practice, the ICR, CF, and basal insulin of the system are initialized using the individual values of the patient with diabetes as optimized by their physician. To reflect the bias that the healthcare specialist may have when estimating “optimal” values, a uniform uncertainty of ±10% may be randomly applied. The simulator provides the default ICR, CF, and basal insulin for T1D. For T2D, such values may be calculated using the standard equations.

[0159] Policy parameters may be variables that define the behavior of the advisor. The initialization of thepolicy parameter vector θ is based on the transfer entropy (TE) between CGM data and the active insulin. Active insulin (AI) may be estimated as the sum of IOB related to the bolus doses and basal insulin (Basal) infusion collected in the first two weeks: ^^^^  =  IOB + ^^^^^^^^

[0160] Hyper-parameters may be settings that guide how ABBA learns, such as the speed of learning or thecomplexity of the suggested insulin dose. The varied responses to insulin among individuals with diabetes necessitate personalized treatment, as evidenced by discrepancies in the stability of blood glucose profiles. Consequently, those with unstable BG profiles may require more careful management, leading us to adopt more conservative algorithmic updates. Two weeks of BG data from 100 simulated adults diagnosed with T1D may be gathered, and the standard deviation of BG values may be computed. Notably, the CGM profiles display a nearly Gaussian distribution. Individuals with unstable BG patterns are considered those with a z-score > 1 in the standard deviation of the BG profiles. Practically, peopleP4292PC00 Specs (AOFF) with T1D whose BG standard deviation exceeds 57 are classified as unstable. The same approach is repeated for people with T2D, with people with T2D defined as an outlier with a BG standard deviation surpassing 59. Therefore, the AC’s initial learning rates are decreased to support those with unstable BG profiles more effectively. Moreover, if the subject in the first two weeks has BG less than 70 mg / dL for more than 21% of the time for T1D and 42% for T2D overnight, they are considered high-risk. Following this approach, the actor learning rate of the dinner ICR may be adjusted.

[0161] The hyper-parameters of the ABBA algorithm may be summarized as in Table 1. The hyper-parameters do not differ among the virtual subjects. Symbol → indicates the change of the hyper-parameters when the subject is considered as an outlier, and for hyper-parameters that differ between T1D and T2D, the notation " / " is used to show the specific values for each condition. αSP may be set to 0.1. In addition, if the subject is considered as high risk, the initial actor learning rate for ICR of dinner is set to 0.01 in case for patients with normal BG profile in the first two weeks and to 0.001 in case for unstable BG profile in the first two weeks. Hyper-parameter Symbol ValueDiscount factor γ 0.9Eligibility trace decay factor λ 0.5Critic learning rate for ICR ^^^^^^ 0.1 → 0.05Critic learning rate for PS ^^^^^^ 0.1 → 0.01Critic learning rate for Basal ^^^^^^ 0.1 → 0.01Actor learning rate for ICR ^^^^^^ 0.1 → 0.01Actor learning rate for PS ^^^^^^ 0.1 → 0.01Actor learning rate for Basal ^^^^^^ 0.1 → 0.01Weight of SP ^^^^^^ 0.1Smoothing factor m 0.5 / 1Table 1: Hyper-parameters of the ABBA algorithm:

[0162] Phase 3 - On-line Learning: The third phase may consist of the learning process as described above.The system algorithm may be configured to predict the bolus and basal insulin suggestions. Experimental example

[0163] The objective of this test is to evaluate the performance and efficacy of the system (also called ABBA)algorithm in accurately managing BG levels for individuals with both T1D and T2D. This involves assessingP4292PC00 Specs (AOFF) the algorithm's ability to adjust insulin treatment daily based on real, thereby ensuring optimal glucose control. The test aims to validate the extended version of ABBA, tailored specifically for the FDA-accepted individuals with diabetes under MDI therapy and SMBG measurement. We compared ABBA algorithm against the standard treatment.

[0164] These tests play a pivotal role in the overall development cycle of ABBA. Firstly, they serve as criticalvalidation steps to ensure the algorithm's effectiveness and safety in real-world scenarios. By conducting rigorous testing under various conditions, including disturbances, uncertainties, and variabilities, developers can identify and address any potential shortcomings or limitations of the algorithm. Moreover, the validation of the extended version of ABBA for individuals with T2D represents a significant advancement in diabetes management. Given the rising prevalence of T2D globally, the inclusion of insulin pens and optimization of insulin dosing parameters tailored to this population is of paramount importance. These tests ensure that the algorithm meets the diverse needs of individuals with diabetes, thereby enhancing its clinical utility and impact on improving patient outcomes. Overall, these tests serve as crucial quality assurance measures, guiding the refinement and optimization of the ABBA algorithm to deliver personalized and effective diabetes management solutions for PwD worldwide.

[0165] To test a scenario as close as possible to real-life situations, such as the one that will take place duringthe clinical trial, we include uncertainties and variabilities in meal announcements, insulin injections, blood glucose measurements, and insulin sensitivity. In this experiment, we required a blood glucose measurement before each meal and one before bedtime per day, measured with virtual SMBG devices. One day of simulation included three main meals per day: breakfast, lunch, dinner, and one snack. Both meal timing and CHO content of the meals were extracted from uniform distributions.

[0166] Table 3 reports the minimum and maximum values of the distributions from which the meal timingand CHO amount are drawn. Meal type CHO amount [g] Meal timingBreakfast [42 - 98] [7:00 am – 9:00 am]Lunch [60 - 140] [12:30 am – 1:30 pm]Dinner [54 - 126] [7:00 pm – 8:00 pm]Snack [5 - 21] [10:00 am – 11:00 am] or[3:00 pm – 6:00 pm] or [9:00 pm – 10:30 pm] Table 1: Minimum and Maximum Values of the Possible CHO amount and Time of Consumption for the different meals (Uniform distribution)P4292PC00 Specs (AOFF)

[0167] We fix the duration of the experiment to 90 days to match the duration of the expected clinical trial.The algorithm needs 14 additional days at the beginning for the parameters’ initialization. The main meal lasts 15 to 30 minutes, and the snack 3 to 8 minutes. The bolus injection and the meal announcement take place 5 to 15 minutes before the meal, and the basal insulin injection from 10:00 pm to 12:00 pm. In addition, we consider that the subjects are likely to under or overestimate the carbohydrate content of meals by 70% and 110%, respectively. Also, we add variability of ± 10% to the Physicians’ ICRs / PSs / Basal. Both variabilities and uncertainties follow uniform distributions. The intraday variability of insulin sensitivity was considered as the “dawn phenomenon” for individuals with T1D. This refers to periodic episodes of hyperglycemia occurring in the early morning hours before and after breakfast. In the present study, SI also dropped every day between 04:00 and 08:00 to 50% of its original value, and SI ramped up or down within around 30 minutes. Finally, we assume that there is no meal intake or bolus injection after the basal injection, since we realistically assumed that the basal injection is taken right before bedtime. In addition, we add a rescue meal controller which is activated when the BG goes below 30 mg / dL and gives to the subject a glucose tablet dose of 20 gram, as suggested from the simulator’s documentation. A rescue meal controller in order to avoid extreme hypoglycemic events. During the clinical trial setting this threshold can be adjusted. When the rescue meal controller is activated, ABBA takes into consideration this BG measurement.

[0168] The evaluation of the performance of the experimental scenarios was based on the analyses of theBG levels of the virtual adults. Different metrics were implemented to assess the performance. The most widely used parameter is the percentage of time in different BG ranges: percentage time in glucose target range (% in Target) [70-180] mg / dl; percentage time in hypoglycemia (% in Hypo) < 70 mg / dl, and percentage time in hyperglycemia (% in Hyper) > 180 mg / dl. In addition, the mean number of hypo and hyperglycemic events, BG, maximum and minimum BG and the total daily dose (TDD) in units per day of insulin were extracted. Lastly, to evaluate the statistical significance of the resulting metric distribution, we applied the Wilcoxon test with a significance level equal to 1% to the metric % in Target, % in Hypo, and % in Hyper, which showed a non-Gaussian distribution based on the Lilliefors test.

[0169] Definition of Success and Failure Criteria to Assess the Algorithm's Effectiveness:^ Success Criteria:o Primary Outcome: Percentage time in target range (% in Target) [70-180] mg / dl: The algorithmis considered successful if the virtual adults spend a significant portion of their time within the target glucose range compared to the standard treatment. oImprovement of time in target range for the ABBA algorithm over-time.o Reduce time spent in hypoglycemia for people with T1D and reduce time spent in hyperglycemiafor people with T2D.P4292PC00 Specs (AOFF) ^Failure Criteria:o Percentage time in hypoglycemia (% in Hypo) < 70 mg / dl: Failure occurs if virtual adults spend anexcessive amount of time in hypoglycemic states. oPercentage time in hyperglycemia (% in Hyper) > 180 mg / dl: Failure occurs if virtual adults spendan excessive amount of time in hyperglycemic states.

[0170] Successful performance is determined by achieving statistically significant improvements in thesemetrics compared to baseline algorithm. By rigorously evaluating the ABBA algorithm against these success and failure criteria, its effectiveness in managing blood glucose levels can be objectively assessed, providing valuable insights for clinical implementation and further algorithm refinement.

[0171] ABBA algorithm is validated in the in-silico on 200 simulated adults (100 with T1D and 100 with T2D)of the FDA-accepted simulator with the Experimental Scenario 1. First 4 Weeks Last 4 Weeks% in Target % in Hypo % in Hyper % in Target % in Hypo % in HyperAdults - T1D BBA 70.4 ± 14.1 4.5 ± 4.7 25.2 ± 12.4 71.7 ± 13.9 3.5 ± 4.6 24.9 ± 12.1ABBA 72.7 ± 12.5† 1.0 ± 1.2† 26.3 ± 11.7 84.7 ± 11.9† 0.7 ± 0.9† 14.6 ± 11.6†Adults - T2D BBA 68.4 ± 19.8 7.5 ± 12.1 24.1 ± 21.7 69.5 ± 20.1 7.3 ± 12.5 23.1 ± 21.9ABBA 75.9 ± 17.9† 1.6 ± 2.4† 22.5 ± 18.3† 83.7 ± 16.5† 0.6 ± 1.3† 15.7 ± 16.2†Symbol † indicates staƟsƟcal significance (p ≤ 0.01) with respect to the BBA. Table 4: In-silico results with the full cohort for the first and the last 4 weeks

[0172] We compare ABBA algorithm versus the basal-bolus advisor (BBA), which consists of the bolus insulinusing the formula above and the basal insulin that is suggested from the simulator. Table 4 presents the results of the in-silico population for both BBA and ABBA algorithms, comparing the performance in the first and the last 4 weeks of the 3-month evaluation. During the first 4 weeks, BBA demonstrated a % in Target of 70.4 ± 14.1 for T1D adults and 68.4 ± 19.8 for T2D adults.

[0173] In the last 4 weeks, BBA expectedly maintained a similar performance, with % in Target values of 71.7± 13.9 for T1D and 69.5±20.1 for T2D. On the other hand, the ABBA algorithm exhibited better performance, especially for the % in the Hypo category, with values as low as 1.0 ± 1.2 for T1D and an impressive 0.7 ± 0.9 during the last 4 weeks. Notably, there is an absolute improvement of roughly 13% in the glycemic control over time using the ABBA algorithm. This suggests that ABBA may offer enhancedP4292PC00 Specs (AOFF) glycemic control, particularly in minimizing hypoglycemic events for T1D, making it a promising candidate for diabetes management. Importantly, the results also highlight the potential of the ABBA algorithm in benefiting individuals with T2D, as evidenced by a substantial improvement in % in Target (83.7 ± 16.5), % in Hypo (0.6 ± 1.3), and % in Hyper (15.7 ± 16.2), during the last 4 weeks. % in Target % in % in Hyper # Hypo # Hyper BG BG BGHbA1c LBGI TDDHypo events events mean max min (U)Adults – T1DBBA 70.6±13.8 4.4±4.8 25.0±12.1 35.1±34.0 199.4±51.3 148±13 259±41 50±17 6.8±0.4 1.28±1.38 44.19ABBA 80.1±10.8† 0.9±0.9† 19.0±10.2† 10.7±10.7 200.3±59.1 148±13 262±39 47±17 6.8±0.3 0.27±0.22 43.35Adults – T2DBBA 68.3±19.7 7.9±12.6 23.8±21.5 52.8±98.2 177.0±95.7 145±37 285±79 73±34 6.7±1.3 2.05±3.30 51.02ABBA 80.1±16.5† 1.0±1.3† 18.9±16.4† 11.4±18.0 190.6±93.9 145±22 284±73 65±28 6.7±0.8 0.34±0.36 56.47Symbol † indicates staƟsƟcal significance (p ≤ 0.01) with respect to the BBA. Table 5: In-silico results with the full cohort in 3-months duraƟon

[0174] Table 5 provides the in-silico result spanning the 3-month duration. In BBA, T1D patients using thecurrent standard treatment exhibited a % in Target of 70.6 ± 13.8, indicating a satisfactory level of glycemic control. However, we also observe notable occurrences of hypoglycemia (% in Hypo: 4.4 ± 4.8) and hyperglycemia (% in Hyper: 25.0 ± 12.1). In contrast, T1D patients under the ABBA algorithm demonstrated an enhanced % in Target (80.1 ± 10.8) with an impressive reduction in hypoglycemic time (% in Hypo: 0.9 ± 0.9). This suggests that the ABBA algorithm offers improved glycemic control, particularly by minimizing the risk of hypoglycemia for T1D. Interestingly, T2D patients following the standard treatment exhibited similar trends, with a % in Target of 68.3 ± 19.7. However, the % in Hypo and Hyper were relatively higher at 7.9 ± 12.6 and 23.8 ± 21.5, respectively. The performance of ABBA for T2D is significantly improved to 80.1 ± 16.5, reducing the hypoglycemic time by approximately 7% and reaching a hyperglycemic time of 18.9 ± 16.4.

Claims

P4292EP00 Specs (AOFF) Claims 1. An adaptive drug management system for personalized diabetes treatment of a person, the system comprising: ^a data collection module configured to store person's blood glucose measurement data and insulindosage information used to treat the person, ^a bolus calculator configured to determine a bolus insulin dosage, and^ a learning module comprising a first agent configured to fine-tune a physiological state (PS) value ofthe person over time; wherein the PS value is a derived parameter representing a dynamic scaling factor used in the bolus insulin dosage determination, the scaling factor reflecting variations in the person physiological condition and insulin sensitivity; and wherein the system is configured to: ^retrieve, from the data collection module, the blood glucose measurements taken over apredetermined period, ^retrieve, from the data collection module, the insulin dosage information used over thepredetermined period, ^update, by the learning module using a reinforcement learning (RL) algorithm, the PS value based onthe retrieved data, and ^use, by the bolus calculator, the updated PS value to determine an appropriate bolus insulin dosagefor the person.

2. The system of claim 1, wherein the RL algorithm comprises an actor-critic algorithm.

3. The system of claim 2, wherein the learning module further comprises: ^an actor component configured to improve the control policy;^ a critic component configured to evaluate the control policy and to provide a temporal differenceerror for policy optimization.

4. The system of claim 1, wherein the learning module is configured to update the PS value at mealtimes, or at each meal, or upon announcement of a meal by the person or at the person request.

5. The system of claim 1, wherein the learning module is configured to update the PS value using at least two distinct PS agents specific to different times of the day.P4292EP00 Specs (AOFF) 6. The system of claim 1, wherein the learning further comprises a second agent configured to update an Insulin-to-Carbohydrate-ratio (ICR) value and wherein the system is configured to use, by the bolus calculator, the ICR value to determine the appropriate bolus insulin dosage for the person meal.

7. The system of claim 1, wherein the bolus calculator is configured to take into account the person's carbohydrate intake information in determining the bolus insulin dosage.

8. The system of claim 1, wherein the bolus calculator is configured to provide insulin dosage recommendations for both meals and correction boluses.

9. The system of claim 1, wherein the system is configured to operate with multiple types of insulin delivery devices, including insulin pumps and pens.

10. The system of claim 1, wherein the learning module comprises a third agent configured to update a basal insulin dosage of the person.

11. The system of claim 1, wherein the data collection module is configured to receive data from a continuous glucose monitor (CGM), a self-monitoring blood-glucose meter (SMBG), flash glucose monitors (FGM) and / or another blood-glucose monitoring device type (BGM).

12. The system of claim 1, wherein the predetermined period is greater than 12 hours or 24 hours.

13. The system of claim 1, wherein the data collection module collects data over a period greater than 24 hours.

14. The system of the claim 1 further comprising an initialization module configured to: ^process the collected data to initialize a policy parameter vector, and^ select algorithm hyper-parameters based on the collected data;15. The system of claim 14, wherein the initialization module filters collected measurement data using data obtained from a continuous glucose monitor (CGM) to initialize the hyper-parameters.

16. The system of any one of claims 14 to 15, wherein the data collection module is configured to receive time-stamped blood-glucose measurements.

17. The system of any one of claims 1 to 17, wherein the learning module comprises a plurality of first agents, each configured to estimate a physiological-state value of the person, distinct first agents being specific to different times of the day or mealtime.

18. The system of any one of claims 6 to 18, wherein the learning module comprises a plurality of second agents, each configured to update an insulin=to-carbohydrate-ratio (ICR).P4292EP00 Specs (AOFF) 19. The system of any one of claims 1 to 18, wherein the learning module comprises one or more fifth agents configured to estimate and update insulin recommendations based on at least one physiological or behavioral parameter.

20. The system of claim 19, wherein the physiological or behavioral parameter is selected from: a physical-activity parameter, an illness-related parameter, a sleep-quality parameter, a stress-level parameter, a heart-rate parameter, a heart-rate-variability parameter, a respiratory-rate parameter, a body- or skin-temperature parameter, a sleep-timing or sleep-staging parameter, a body- weight parameter, a blood-pressure parameter, an oxygen-saturation parameter and / or a galvanic-skin- response parameter.

21. The system of any one of claims 1 to 20, wherein the data collection module is configured to receive, via manual entry and / or automatic import, time-stamped blood-glucose measurements, insulin-therapy information, food-intake and nutrient-composition data, lifestyle signals including at least sleep, physical activity, and stress, and person-specific contextual information including at least age, sex, body-mass index, years since diagnosis, and / or physician recommendations on insulin therapy.

22. The system of any one of claims 1 to 21, wherein the physiological-state value is computed and updated from postprandial blood-glucose measurements obtained at a corresponding mealtime on a previous day.

23. The system of any one of claims 1 to 22, wherein the predetermined period is at least 12 hours, optionally at least 24 hours, and wherein the data collection module is configured to collect data over a period of at least 12 hours or at least 24 hours.

24. The system of any one of claims 1 to 23, wherein the determination of the appropriate bolus insulin dosage is triggered upon detection of a deviation exceeding a predefined glucose threshold or upon receipt of a user-input event.

25. The system of claim 24, wherein the predefined safety constraints comprise upper and lower dose limits dynamically adjusted based on recent glucose trends and insulin-on-board calculations.

26. The system of any one of claims 1 to 25, wherein the bolus calculator determines a bolus-insulin dose using a formula comprising a scaling factor corresponding to the physiological-state value in combination with an insulin-to-carbohydrate ratio, a correction factor, and an insulin-on-board value.

Images