*2.4. Safety*

This control algorithm's first goal is to keep the patient safe. Safety features have been implemented in several parts of the system in the form of alarms and action types. As it has been described before, this control platform is based on the fact that the patient is already using a commercial system for glucose sensing and insulin delivery. These systems have their own alarm system being able to report hypoglycemic or hyperglycemic situations directly to the patient. On top of that, our control platform makes use of a third-party software named xDrip [16] to upload data to Nightscout and for data monitoring directly on the phone. xDrip also provides a really powerful alarm system in which the patient can configure the standard alarms (hypo, hyper), rate change alarms or data stalling alarms (for a programmable time period). In the proposed platform, xDrip can also generate alarms coming from the controller. This feature is used to alarm the user from non-mitigatable problems like a precited hypoglycemia that cannot be solved just by reducing the future amount of insulin being delivered, requiring the patient interaction or a persistent hyperglycemia that the system fails to lower, meaning that the patient may need to review the infusion set or the correct state of the insulin.

Safety was also taken into account in the way insulin is controlled. There are two main ways of controlling infusion:


If the control algorithm resides inside the insulin pump any of those methods can be understood as safe but, as we have to rely on the radiofrequency communications that could or could not be operational, micro-bolusing is not a safe option: to be able to use micro-bolusing the patient must disable any basal rate infusion since there would be no other way to reduce the amount of insulin the patient receives below that basal rate (there would be no way to suspend infusion). Disabling the basal rate is potentially dangerous since any problem with the controller or the communications would leave the patient without insulin and that situation could lead the patient to su ffer from DKA (Diabetic Ketoacidosis). Due to this reason, this controller makes use of temporary basal rates to control infusion. The patient has a valid basal rate profile configured and the controller will issue 30 min temporary basal rates to add or reduce insulin. In the case of a controller or communications failure, after those 30 min, the insulin pump will come back to its normal behavior and will infuse the programmed basal rate.

One more problem mitigated with the use of temporary basal rates is that, in the case of an uncontrolled loop execution (execution error event), one temporary basal will directly cancel the previous one while, in the case of micro-boluses, the system could potentially command many boluses in a row stacking their e ffects (and possibly causing a severe hypoglycemic event).

With the use of temporary basal rates the controller has another safety feature: the insulin pump will only accept temporary basal rates that are higher than 0 U/h and lower or equal than a maximum rate that can be configured in the pump, this way constraining the possible actions that can be taken by the controller.
