**1. Introduction**

Diabetes is a condition that affected approximately a 10% of the population during 2015 [1]. Even though there are many subdivisions of diabetes types, like LADA, new-born diabetes, etc., it is still generally accepted the three general categories of type 1, type 2, and gestational. Type 2 diabetes is the most common of the three, but its managemen<sup>t</sup> is normally only tied to a strict diet combined with exercise. Oral medication is used only when necessary. Only in extreme cases is type 2 treated with insulin. Type 1 diabetes, on the other hand, forces the patient to use insulin as a way to keep the patient's glucose levels in range and reduce the risk of suffering severe short- and long-term complications.

In recent years, we have witnessed, along with new more accurate infusion devices, the appearance of Continuous Glucose Monitoring (CGM), small electronic devices comprised of an electrode, which inserted under the skin, that can measure the glucose levels in tissue fluid. A small transmitter would send the sensor's information to a receiver via radio frequency. Sensors, like the G4 and G5

(Dexcom, San Diego, CA, USA) [2], Enlite (Medtronic, Dublin, Ireland) [3] or Freestyle Libre (Abbott, Chicago, IL, USA) [4], last anywhere from 6 to 15 days and some of them must be calibrated by fingersticks (manual glucose testing) from three to four times per day. Although insulin pumps have been available since the early 60s, their accuracy and functionalities have improved to the point of, for example, being able to dose with precisions of 0.025 units of insulin, integrate data from glucose sensors and glucometers, and keep a history of events for the patient.

Technology has evolved and new possibilities are available for these devices. Developing a closed loop system that reduces the burden faced by people living with diabetes is a priority for medical companies. Most recent devices will not use glucose sensor data to calculate the insulin dosing, even though the pump is receiving this data. Changes to the insulin dosing of a patient could have lethal consequences if mistakes occur. The current systems have no way to cancel the e ffect of insulin that has been infused, besides the patient consuming carbohydrates. In other words, there is no problem reducing the amount of insulin being dosed as the patient or the system can always increase it later, but once insulin has been dosed the system has no way to remove it from the patient's body. This is the main reason why manufacturers are developing these functions by stages; current devices allow what they call as "suspend-on-low": the insulin pump will suspend the infusion when patient's glycaemia is, or is predicted to be, below a certain security threshold. This safety feature is the first step to obtain a closed loop system. Very recently, a new insulin pump was released to the market that is capable of increasing the insulin dosing depending on the glycaemia. Although this is very critical, the system is preconfigured to achieve a less challenging glucose target while being, at the same time, very conservative and safe.

Every patient is di fferent and so are their needs [5]. That is the reason why a very active community of patients (DIY Artificial Pancreas community/Loop [6]/OpenAPS [7]/Nightscout [8]) have developed their own control platforms and have made them configurable so that, with the necessary knowledge, every patient could adjust it to their own needs. These systems were designed to run on commonly available platforms as Raspberry Pi, Intel Edison or smartphones, typically running Linux or high-end operating systems, and are not designed as low-performance battery powered systems. Other works [9,10] address solutions more complex that do not focus on a wearable approach.

What all of these systems have in common is that they use glucose and insulin dosing information to calculate the actions needed to keep the patient in a defined range (configurable or not by the user). Having a good set of parameters for the patient becomes a critical task that is beyond the scope of this paper.

The rest of the paper is organized as follows: System Proposal will describe the concept of a hybrid closed-loop system, along with some of the problems related to this technology. Section 3, Results, will propose a new system, capable of fulfilling the patient needs as well as reducing consumption and its size compared to the rest of DIY solutions and the results from simulating 30 virtual patients (10 adolescents, 10 adults, and 10 children) using a python implementation of the FDA-approved UVa/Padova Simulator [11] and a python implementation of the proposed algorithm are presented. Section 4, Discussion, will make an analysis of a control loop algorithm and all the possible problems that could occur due to incorrectly set parameters.

#### **2. Materials and Methods**

#### *2.1. System Proposal*

Our proposed closed-loop system is composed by four di fferent elements: insulin pump, continuous glucose sensor, controller, and data input device (see Figure 1). Some of these elements (or all of them) could be integrated inside the same device.

**Figure 1.** Wearable closed-loop insulin delivery system schema.

Current commercial insulin pumps are designed to work in open loop mode, therefore, they operate in a way that meets the needs for the patients in this situation: insulin pumps allow insulin boluses (equivalent to an insulin injection) and the infusion of basal profiles. A basal profile (commonly named as "basals") defines the di fferent amounts of insulin the patient needs throughout the day to keep his glycaemia stable. As basal needs may change depending on many external factors, pumps typically support more than one basal profile to allow patients to select among them and use the one that best fits their needs in every moment. This basal profile selection is normally done in a type-of-day basis but, if users need to modify their basal infusion for a reduced period of time (from 30 min to some hours) insulin pumps allow "temporary basals." Using a temporary basal the patient can manually increase or decrease the infusion without modifying the programmed basal profile. An insulin pump will be suitable for a closed-loop insulin delivery system if it can be controlled by an external device and supports the change of the infusion configuration: typically setting temporary basals.

The Continuous Glucose Sensor provides the control system with real time information about the patient's glycaemia. The sensor is a module composed by a filament inserted under the patient's skin measuring the glucose concentration and the associated electronics to perform the measurement, and the radio frequency transmission. Current glucose sensors obtain a new reading every 5 min and most of them must be calibrated by the patient in order to ge<sup>t</sup> precise enough results. Since the sensor is not measuring directly the glucose concentration present in the blood stream, there is a variable delay between what the glucose sensor is measuring and the real blood glucose concentration. This delay is typically 10/15 min and is one of the reasons why the sensor calibration must be performed when the patient's glycaemia is stable. If the glycaemia is stable both measurements should match when calibrating.

This type of system usually requires input from the patient and that is why they are called "hybrid" closed-loop systems. The main reason for this information need is the delay present in the measurement process and in the action (as shown in Figure 2).

**Figure 2.** Simplified controller schema with related-to-person behavior and delays.


**Figure 3.** Relative insulin effects versus time.

Although a closed loop system would respond effectively even with these delays inside the loop, they would cause the patient's glycaemia to reach certain levels that are considered dangerous or, at least, not recommended. There are situations in which patients will experience rapid changes in their glycaemia: food intake and exercise. A rich carbohydrate meal will increase rapidly the glycaemia and, by the time the controller is capable to react, the patient could easily reach hyperglycaemia. During exercise, insulin requirements are lower and, if insulin is not reduced soon after, or even before, the exercise the patient could suffer hypoglycaemia. The controller will detect the glycaemia dropping 15 min after the real drop and will reduce the insulin infusion but, as insulin will remain active for many hours (depending on the patient), the effect of the infusion reduction could not be enough. In order to minimize this problem, the controller will receive information from the user to announce meals and exercise before they happen using a device like a smartphone (Figure 4). This way the controller will change the infusion to adapt to the future situation.

**Figure 4.** Simplified controller schema with delays and patient information.

The controller is the module responsible for the information analysis and response calculation. In order to be considered as wearable it should meet these requirements:


#### *2.2. Proposed Wearable System for Insulin Delivery*

Once the needed specifications for a wearable insulin delivery system are established, in this section, a new proposal that fulfils these requirements will be described. It will be composed by an insulin pump, a glucose sensor, and an ad-hoc controller based on a low power consumption system-on-chip.

The proposed system uses a commercial insulin pump with an integrated glucose sensor (Medtronic Paradigm Veo + Enlite sensor) because its communication protocol via radiofrequency has been documented [13,14] and can be controlled to set temporary basal levels, suspend and resume the infusion and/or command boluses.

As important as having a controllable infusion system is having a calibrated system. Enlite glucose sensors [15] require calibration every 12 h (maximum) and they must be calibrated by the patient following a specific set of rules:


This process is necessary to keep the coherency between measurements in the interstitial fluid (provided by the glucose sensor) and in the blood stream (provided by a glucometer during calibration). The calibration of the sensor becomes really important in a closed-loop system: if the sensor is degraded or not calibrated correctly, the use of inaccurate data could cause a hypoglycaemia or hyperglycaemia to the patient.

Once the patient is using a reliable and controllable insulin infusion system along with a glucose sensor, the next step is to obtain a wearable platform that will enable the patient to close the loop: obtain real time glucose data and patient's parameters and act on the insulin infusion.

Other platforms used for DIY closed-loop insulin delivery systems [6,7] use powerful microprocessors running operating systems as Linux, Android, or iOS. These platforms are not oriented to a low power consumption and they must keep the system running, having other processes in the background that could consume power in an undesired way. This is the reason why these platforms cannot be considered as "wearable." In order to keep these systems running on batteries for at least 24 h, the patient must carry relatively big batteries with the system, making it less portable and, maybe, not reliable for a long-term period of time. When the controller runs on a smartphone there are two additional problems: the patient's phone cannot run out of battery. In that case the patient will open the loop. Other intrinsic problem is the security risk of being hacked. Mobile phone security has to be improved in the next generations of OS for mobile phones. These two problems made this work face the controller's problem from an embedded platform point of view.

In the proposed solution, with low power consumption as a goal, a new custom board was designed. This board is divided into four di fferent parts (diagram in Figure 5):


**Figure 5.** Block diagram of the proposed wearable module.

### *2.3. Closed-Loop Control*

The control loop algorithm will be responsible for the data analysis and actions in the form of temporary basals. Its only purpose will be to command temporary basals to the insulin pump so that the measured glycaemia reaches a certain target value. To do so, the control algorithm was divided into several steps, as shown in Figure 6.

**Figure 6.** Control loop state diagram.

The control loop takes the following information as input:


The first thing the control algorithm needs is the updated glycaemia. In step 1 the algorithm will wait until a new glucose value is received from the sensor and, in step 2, the controller will update its history data with the received data.

Once the patient state has been updated, in step 3 the controller will retrieve the pump configuration with some parameters set for and by the patient and, after that, it will calculate some derived parameters needed for the control itself. As every patient needs a different model, it is not feasible to find a universal solution and, therefore, there are some parameters that the patient will need to enter according to his personal characteristics:


• Sensitivities: Sensitivity or Insulin Sensitivity Factor establishes the relation between one unit of insulin and the glucose concentration that it will reduce in the patient. As happens with the basal profile, the sensitivity changes throughout the day and they are normally configured as a profile.

Once the system has obtained all these parameters and previous information, the control loop will start to operate. The controller will receive a new glycaemia value every 5 min; this allows the system to remain asleep for long periods of time and increase battery life.

As the system has 5 min to do all the calculations needed for the closed loop algorithm, low performance platforms can be used improving power consumption and cost. As a first step, the controller calculates three parameters (eventual glycaemia using only the trend, Insulin-On-Board, and eventual glycaemia) based on all the different inputs:

• Eventual glycaemia using only the trend (Equation (1)): using the history of glucose values sent by the sensor (*sgv or sensor glucose value*, 0 being the latest value received) the controller calculates the trend for the last 'M' values and the glucose value that the patient would reach after 15 min (using *TS* and the time in minutes between consecutive glucose values) if the glycaemia continues with that trend. This way, the controller tries to guess the current blood glucose value and reduce the error introduced by the sensor's delay.

$$
egGlycTrend = \begin{array}{c} \frac{\sum\_{n=0}^{M-1} \Delta sgv[n]}{M} \times \frac{15}{T\_S} + sgv[0]. \tag{1}
$$

• IOB or Insulin-On-Board for one bolus or dosing (Equation (2)): every bolus or insulin delivered to the patient will affect blood glucose following a certain "*insulin\_response*" curve. This curve represents the normalized effect of one unit of the chosen insulin from the infusion moment up to a certain number of hours (active insulin time). This way, the integral of the response curve from the moment chosen for the IOB evaluation (*X*, measured in hours) to infinity, multiplied by the number of insulin units delivered (*B*), will be equal to the equivalent amount of insulin that will still have an effect in the patient's body in the future due to that bolus.

$$bIOB(B, X) = B \times \int\_{t=X}^{\infty} In sulin\\_response\_{1\ell I}(t). \tag{2}$$

• IOB or Insulin-On-Board (Equation (3)): using all the previously infused insulin (basal and boluses, taking basals as a series of boluses every 5 min), the controller calculates the amount of insulin that has been infused but has not made an effect yet. That insulin is called Insulin-On-Board and has to be considered when calculating the final glycaemia. IOB will be calculated as the sum of every past infusion IOB (bIOB). The arrival of a new glucose sensor value will trigger the calculation process, so it can be assumed that every bolus or basal insulin can be analyzed as separate boluses with the periodicity of the glucose readings (*Ts*, measured in minutes). Every bolus or infusion will have its corresponding amount of insulin (*Bn*). Variable *n* will serve as discrete index in the equation.

$$IOB = \sum\_{n=0}^{\infty} bIOB (B\_{n,n} \times \frac{T\_S}{60}).\tag{3}$$

• Eventual glycaemia (Equation (4)): the IOB has an important role: the eventual glycaemia, understood as the glycaemia to which the patient is heading, is calculated by the controller as the eventual glycaemia using only the trend plus the effect of the IOB. The parameter that relates insulin to modifications in the glycaemia is the insulin sensitivity factor (ISF) and is defined as the glucose concentration that one unit of insulin will reduce. The controller will use the insulin sensitivity factor that corresponds to the current time and will multiply it by the IOB previously calculated. This multiplication will give to the controller the expected modification for the glycaemia. Summing up this value to the eventual glycaemia using only the trend the controller obtains the eventual glycaemia.

$$
\epsilon \text{eGlyc} = \epsilon \text{Glyc} \\
\Gamma \text{rend} - I \text{OB} \times I \text{SF} . \tag{4}
$$

At this point, the controller has all the input information and parameters for the patient and all the derived data from them. The controller operation can be divided into four layers evaluated in a sequential manner:

1. Safety Layer (steps 4 and 11 from Figure 6): in this layer, using the current glycaemia (*sgv*[0]), eventual glycaemia (*eGlyc*), and eventually using only the trend glycaemia (*eGlycTrend*) the controller will suspend the insulin infusion in case any of them are below a certain safety threshold (*thresholdlow*) (see Equation (5)). This same layer will resume the infusion as soon as the hypoglycaemia disappears. In the case of a suspension in this layer, the control loop execution stops until new data is received.

$$
gamma \colon \begin{cases}
 \text{syc}[0] < \text{threshold}\_{\text{low}} \\
 \text{or} \\
 \text{cGlycTrend} < \text{threshold}\_{\text{low}} \\
 \text{or} \\
 \text{cGlyc} < \text{threshold}\_{\text{low}}
\end{cases}
\tag{5}
$$


$$error = eQlyc - target\_{\prime} \tag{6}$$

$$correction = \frac{error}{ISF} \,\,\,\,\,\tag{7}$$

$$tempBasal\_{30min} = basal\_t + correction \times \frac{60}{30}.\tag{8}$$

4. Action Saturation Layer (steps 7 and 8 from Figure 6): in step 7 the controller limits the actions taken by the control layer. The minimum temporary basal allowed is 0 U/h (Units per hour) and the maximum temporary basal is set as another parameter by the user in the insulin pump. That parameter is called "Max basal." Any temporary basal over that limit will be reduced to the maximum basal allowed. After applying the saturation effect to the calculated temporary basal, it is commanded to the pump in step 8.

As explained before, this control loop has been designed to work on a low-power-consumption embedded platform and, having reached this point in the execution, the control loop will sleep the microcontroller to save energy (step 9 from Figure 6). Just before a new glucose value is sent, the microcontroller will wake up and set up the radio frequency channel to be ready for it (step 10 from Figure 6). The control loop algorithm takes approximately 15 s to calculate and command new actions and, if the glucose sensor sends a new glucose value every 5 min, the microcontroller will sleep for more than 90% of the time.

Although the control algorithm would work properly with some degree of error in the parameters entered by the patient, this controller should be configured as accurately as possible in order to have good results. Some of the e ffects that the patient could su ffer from misconfigured parameters are:


As explained before, some degree of error can be tolerated but, if the error is big enough to cause a non-automatically-solvable situation, an alarm will be sent to the smartphone so that the patient is notified and can take care of the problem.
