FormalPara Key Summary Points

Healthcare providers need to understand automated insulin delivery (AID) systems to help inform shared decision making, discussing available options, implementing them in the clinical setting, and guiding users in special situations.

There are a number of both open source and commercially developed AID systems, all of which have been proven safe and effective, but there are multiple other criteria to assess when evaluating the AID options for each individual user.

The choices and preferences of the person living with diabetes should be at the center of any decision around the ideal automated insulin delivery system or any other diabetes technology.

Healthcare providers will benefit from assessing and better understanding all available AID system options to enable them to best support each individual.

Introduction

As increasing numbers of people with insulin-managed diabetes use automated insulin delivery (AID) systems or seek such technologies, more healthcare providers are faced with a steep learning curve [1,2,3,4]. Healthcare providers need to understand how to support these technologies to help inform shared decision making, discussing the options available, implementing them in the clinical setting, and guiding users in special situations [5]. At the same time, there is a growing diversity of commercial and open source automated insulin delivery systems that are evolving at a rapid pace. How might healthcare providers learn about this technology in a way in which they can support users and caregivers with AID systems? This practical guide seeks to provide a conversational framework for healthcare providers to discuss and jointly assess AID system options with users and caregivers. Using this framework will help HCPs in learning how to evaluate potential new commercial or open source AID systems, while also providing a guide for conversations to help HCPs to assess the readiness and understanding of users for AID systems. This article will focus on the more recent hybrid and fully closed loop AID systems, rather than low-glucose suspend or predictive low-glucose suspend systems.

This framework focuses on providing a stepwise progression for users and carers (and providers) to get familiar with the basics of AID systems (see Fig. 1 for an overview). It provides a way to address issues that might lead to a high technical burden or issues that may lead to burnout or perceived failures or may otherwise cause them to abandon its use, before moving on to more advanced topics [6]. With the mastery of each step in the process, people with diabetes should see a reduction in the burden of diabetes management, allowing them to make further improvements over time in both their quality of life and glycemic levels.

Fig. 1
figure 1

A step-by-step overview for healthcare professionals supporting individuals with insulin-requiring diabetes who are interested in exploring open source and/or commercial automated insulin delivery systems

Full size image

This guide is structured chronologically, representing a logical progression of increasing familiarity with AID systems. It first provides background information on AID systems, and then imparts information relating to how to help people with diabetes or caregivers to choose between different AID systems. It moves on to talk about how to ensure and troubleshoot basic AID system operation. It then finally discusses more advanced topics regarding how to maximize the time spent on AID systems and how to optimize settings and behaviors for the best possible outcomes. Article is based on previously conducted studies and does not contain any new studies with human participants or animals performed by any of the authors.

Background

Automated insulin delivery (AID) systems have been available commercially for years in some places, but not all. Open source AID was developed in order to address the patient need for AID before any commercial solution became available [7]. Despite the increase in some countries of commercially available systems, in other countries, open source solutions are still the only available option for patients; in other cases, open source AID may be one of the more affordable options [1]. Both open source and commercial automated insulin delivery systems represent effective and safe treatment options for people with diabetes of several age groups and genders and other demographic categories [8].

For example, a meta-analysis of 12 randomized control trials (RCT) found better outcomes with AID than with a sensor-augmented pump (SAP) in average glucose levels as well as the low blood glucose index (LBGI), high blood glucose index (HBGI), and standard deviation (SD) of glucose variability [9]. In addition, this meta-analysis found that SAP therapy was associated with more adverse effects, one of the most common being hypoglycemia.

A recent RCT specifically assessed the safety and efficacy of an open source AID, using the OpenAPS algorithm in a modified version of AndroidAPS, and found it to be safe and efficacious for both children and adults, with the percentage of time that the glucose level was in the target range of 3.9–10 mmol/L (70–180 mg/dL) being 14 percentage points higher among those who used the open source AID system (95% confidence interval [CI] 9.2–18.8; P < 0.001) compared to those who used sensor-augmented pump therapy [10]. No severe hypoglycemic or DKA events occurred in either arm.

In addition to the overall safety and efficacy of both commercial and open source AID systems for general populations of all ages of children and adults, additional evidence demonstrates their safety in many subpopulations and use cases, such as in young children [11, 12] and older adults [13], during fasting [14], and during pregnancy [15, 16].

As a result, healthcare providers would do well to learn the basics of both commercial and open source automated insulin delivery systems because each type of system (and each system within those categories) offers different benefits and challenges, including component makeup, algorithm sophistication, device interoperability, flexibility, customization, and more.

Open Source AID Systems

Within the open source ecosystem, there are three commonly used AID systems. OpenAPS, the first available open source system, uses a minicomputer instead of a phone to host a customizable and sophisticated open source algorithm alongside a commercially available insulin pump (also known as continuous subcutaneous insulin infusion therapy or CSII) and a continuous glucose monitor (CGM) [17]. AndroidAPS, which also uses the OpenAPS algorithm, is hosted within an Android phone application and works with a radio bridge device to communicate with some commercial insulin pumps, but it also has direct Bluetooth communication capabilities with other Bluetooth-enabled commercial insulin pumps [18]. Loop, which uses a different algorithm, is hosted within an iPhone or iOS device and also uses a radio bridge to translate communications between an iPhone and a commercially available insulin pump [19].

Commercial AID Systems

Among the commercially available systems, access may differ by country. A commercial system sometimes contains the algorithm within an insulin pump (670G, 780G, Control-IQ, Omnipod 5) or separate handheld controller device, whereas in other systems it may be contained in a separate smartphone device (CamAPS-FX and Diabeloop for Android, Medtrum Touchcare Nano for both iOS and Android). Additionally, there may be different setting options, such as glucose targets, that are used by the system [20].

Evolution of Devices

Both categories of open source systems and commercial systems have evolved over time [21]. For example, users of open source AID systems can in some cases choose combinations of settings such as “unannounced meal” and/or “supermicroboluses” (SMB) to eliminate meal boluses and/or meal announcements (e.g., avoid meal interactions completely or choose less precise carb-counting estimates to enter into a system) [22]. Most early studies with unannounced meals, even those with add-on therapies in commercial systems [23], indicated that the early versions may have tradeoffs in overall time in range (TIR) with a lack of user input, although individual evidence from the diabetes community suggests a higher TIR in the real-world use of open source AID [24]. Evolutions of commercial systems from version to version might involve changes to CGM capabilities, target adjustments, or other algorithm or usability adjustments, such as options to do meal announcements without precise carbohydrate counting [25]. Additionally, even if such features are not marketed, people with diabetes may find themselves trialing different approaches to meal announcement, such as less precise carbohydrate counting [26], and find that the systems which adjust successfully are worth the tradeoff between inputting precise carbohydrate counts and achieving the highest possible TIR outcomes. Commercial systems usually change across named versions (e.g., Medtronic’s 670G is followed by the 780G), whereas open source systems change more frequently and therefore may require a more extensive conversation around which version, settings, and targets a patient is using at any given time, as well as an awareness of expanded compatibilities with insulin pumps and CGM options.

Choosing the Right Options—Healthcare Provider Awareness is Key

There are pros and cons to any system, and also in the choice of whether to take advantage of open source systems or commercially available systems (Table 1). But these choices are opportunities, whereas people with diabetes have historically been limited in the availability of tools to choose from in the past. When people with diabetes are newly diagnosed, it is easy for them to feel overwhelmed with everything new they are facing. Healthcare providers may feel similarly overwhelmed in the face of the plethora of new technology available for people with diabetes. But, like the advice to the newly diagnosed to take it one step at a time, this guide will aid healthcare providers in taking it one step—and one question—at a time to build their understanding of automated insulin delivery systems and enable them to assess their patients’ understanding of the choices for automated insulin delivery as well.

Table 1 Pros, cons, and similarities of commercial and open source automated insulin delivery systems
Full size table

Evaluating the Choices of Automated Insulin Delivery Systems

The first step for anyone interested in AID is to determine what their goals are and select an AID system that is most likely to help the person with diabetes to achieve those goals.

For any particular system, regardless of whether it is open source or commercially developed, healthcare providers and individuals with diabetes should be able to answer the following questions regarding each system they are evaluating for potential use:

  • How does it generally work to automate insulin delivery? What physical components (e.g., pump, CGM, and/or mobile devices) are required? What components are optional?

  • When does it work? For example, does the system “turn off automation” at any point?

  • What are the baseline targets for the system? When can you change the targets, and to what levels? What does target changing do with regards to how the system makes decisions?

  • What outcomes do people typically get with real-world use from these systems? What overall TIR % is achieved, for what range (e.g., 70–180 mg/dL)? What is the average estimated glucose or A1c that corresponds with those outcomes?

  • Are meal boluses required to get the stated outcomes from the system? Additionally, what type of inputs are required for meals? What level of precision is needed in carb counting to get a reasonable post-meal outcome?

  • How can data be viewed in real time and retrospectively regarding what the system is doing and how it has performed?

  • If a system requires calibrations for a continuous glucose monitor (CGM), how does calibration (or a lack thereof) impact the system’s operation?

  • What settings can be changed within the system? What information is available to aid in determining whether settings could or should be changed?

  • What remote following and/or monitoring capabilities exist with the system?

  • What resources and support exist for the system?

Challenges of Automated Insulin Delivery Systems

There are known pain points or challenges with each type of system.

For example, many individuals with diabetes are frustrated by being restricted from using automated insulin delivery when using one commercial system that requires a certain number of calibrations to the CGM [27, 28]. Other frustrations have been expressed in the diabetes community towards commercial systems with regard to the inability to adjust targets or achieve higher levels of TIR with a lower average glucose, communication errors between devices that compose the system, and a lack of settings options [29].

There are also possible points of frustration with open source systems. In some cases, the perceived effort required to initiate acquiring and building their own system may be high. Typically, there is no company to call if the system breaks; instead, people rely on self-knowledge and/or community support to fix any issues, although there is a growing group of paid services in various countries that may offer additional support. Also, although there is a growing body of evidence regarding the safety and efficacy of open source systems [30,31,32,33,34,35,36,37,38,39], including results demonstrating safety and efficacy from a randomized control trial [10, 40], as well as studies evaluating open source in comparison to commercial systems [41], none are currently regulatory approved, which also may be a sticking point for both patients and providers. For providers, though, there is a newly released international consensus statement [3] that supports the implementation of open source systems in clinical settings and indicates that open source is a safe and effective treatment option and that healthcare providers have a responsibility to learn about all treatment options for people with insulin-requiring diabetes, including these open source systems. Ultimately, it also reminds providers that people with diabetes should have autonomy and a choice of treatment options.

Overall, it is worth being aware of not only the potential opportunities of a particular system but also the potential challenges of each system as well. In some cases, certain challenges may be blockers for individuals to use a particular system; in other cases, due to personal preferences and lifestyle, there may be elements that a particular person does not care about and do not factor in to drive the decision of which system to choose. This may include preferences regarding seeking the highest possible time in range, or preferences regarding limiting user interaction or troubleshooting devices. Not all individuals living with diabetes will have the same preferences, so individualized conversations and assessments are important.

Additionally, it is common when discussing open source or commercial AID to bring up the potential additive risk of automated insulin delivery. While some risk is introduced by automation, and people should certainly be aware of the risk, it is important to contextualize this risk with regards to the already high risk of manual insulin dosing that people with insulin-requiring diabetes face every day, and how that is reduced by the use of automated insulin delivery systems [42]. Automated insulin delivery, both commercial and open source [3, 8, 41], is considered to be safe and effective.

Troubleshooting AID and Ensuring the Basic Operation of AID

Once an AID system is selected and the person begins using it, the next goal is to ensure that they are well equipped to make sure it continues to work for them, and that they do not get frustrated with the system or give up on it.

Whether open source or commercially developed AID is chosen, sometimes diabetes technology will break or will appear to be not working. Just like there is a learning curve in switching from multiple daily injections to an insulin pump with regards to using a bolus calculator, navigating pump menus, and programming basal rates, there is also a learning curve for understanding how to operate a chosen AID system and how to get the desired impact in different situations.

Part of being able to troubleshoot an AID system is understanding the basics of how the system works. For example, all AID systems have an algorithm (potentially hosted within the pump body or a mobile device), an insulin pump, and a continuous glucose monitor (CGM). There also may be optional apps for CGM and/or AID data display, either in real time or for retrospective analysis.

Some aspects of troubleshooting involve ensuring that the basic components are in place: a working insulin pump; a healthy cannula insertion site; a correctly filled insulin reservoir; an active, correctly placed and accurate CGM sensor; and, if the algorithm sits on a mobile device, checking that a working compatible device required for AID operation is carried. Much of the upkeep of an AID system is similar to that of a standalone pump and CGM: good pump site hygiene and best practices for keeping a CGM sensor actively running, such as scheduling sensor swaps to occur at non-meal times when possible, are key for successful AID use [4]. Much of the troubleshooting of problems that arise may be related to device communication within the system, rather than troubleshooting diabetes itself. This can add to the frustration and burden of people with diabetes and carers. Whilst people with diabetes or carers tend to have well-established practices for dealing with issues that arise during manual methods of insulin delivery, they may need to learn new skills or habits to overcome issues that may arise during automated AID system use.

Communication errors between components (such as CGM-to-mobile device, CGM-to-pump, or pump-to-device communications) can be common issues that patients should be familiar with and trained to troubleshoot. In some cases, errors might result from Bluetooth communications between the linked devices (i.e., the CGM transmitter, pump, smartphone, or controller) being blocked by the body or other objects or by interference. In other cases, the transmitter may be transmitting CGM data but Bluetooth connectivity has accidentally been disabled on the device required for the AID system to receive CGM data. There is also variation in Bluetooth connection quality, depending on the model of smartphone. Additionally, as there are more connected platforms for real-time data access and retrospective data review, there will also be other less urgent areas of data transmission to troubleshoot, such as that from the CGM or AID system to a mobile device app, and that from the app to the cloud and any connected platform designed to receive the data. Internet or cellular connectivity on the mobile device, correct login details, and Bluetooth on the mobile device to receive the data can be common issues to resolve in terms of ensuring that data are flowing throughout the systems and to any connected platforms. Low batteries, whether the CGM transmitter battery, the pump battery, or the mobile device battery, could also play a role in impacting component communications. Users of AID systems that rely on smartphones and who spend long durations outside their homes (such as during travel) may want to carry a battery power bank or smartphone charger to ensure uninterrupted AID system use.

There is also the potential issue of missing CGM data; for example, due to the required warm-up time period for a particular sensor, or due to noisy data that is deemed unactionable by the AID system. Without CGM data, the AID system falls back to manual mode because it cannot make real-time adjustments without updated glucose data.

Overall, much of the troubleshooting will be about the components of the system rather than diabetes itself [43] because the AID system, when operational, can help address much of the “noise” of blood glucose variation associated with insulin-requiring diabetes [35]. This change in behavior from managing insulin delivery manually to managing the devices used to automate insulin delivery will require learning and habit formation. Part of the healthcare professional’s role is to identify changes in behavior and reinforce positive habits to ensure continued success.

Optimizing AID Use and “Uptime” of the System

Once users are comfortable with the basic operation and troubleshooting of the AID system, they can begin improving their experience with the system by focusing on ensuring that it remains operational as long as possible, particularly when it’s most important to them to have it working optimally.

One of the frustrations cited with one of the earliest commercial AID systems was insufficient time spent in the automated insulin delivery mode [41, 44]. Increased time in automation is associated with greater outcomes. While later generations of commercial AID systems have improved in this regard, there are also human choices that can further influence the “uptime” of an AID system.

For example, because CGM data is needed for automating insulin delivery, a longer period of time in between active CGM sensor sessions will result in a longer gap in time without automated insulin delivery. A person would instead need to manually adjust insulin delivery during this time. In order to limit the “downtime” between sensor sessions, it’s helpful to be aware of when a sensor session is scheduled to expire or end. In some cases, the sensor app or the pump may keep track of this and have alerts and reminders. It may still be useful for people to consider using their own calendar to plan, when possible, when they will change to a new CGM sensor. This may assist them in making sure they have a replacement sensor ready and at hand when the old sensor session ends, thus ensuring less downtime for AID. This is not always possible, of course: sometimes a CGM sensor may fall out or fail prematurely, and a person may be without access to their supplies. But, when possible, planning ahead can help reduce the time in between CGM sensor sessions, ensuring less of a gap in AID.

It’s also ideal to consider planning the end of a sensor session as it relates to meals. One of the biggest benefits of AID is the ability of it to adjust in response to food, so having a sensor session end just after a large meal means that the system won’t be able to help adjust insulin delivery in response to any postmeal glycemic excursions. Choosing to change a sensor when the warming up of the sensor does not correspond with a mealtime may further assist people in optimizing their amount of time on AID. The same idea applies when traveling across time zones and looking ahead to see if the sensor should be changed a few hours early in a new time zone in order to avoid the scenario where a CGM sensor session ends overnight or at another inopportune time in the new time zone.

The same philosophy also needs to be applied to cannula changes and site rotations to ensure optimal insulin absorption. AID system algorithms rely on assumptions that insulin will absorb at a designated rate, and calculations are based on the amount of insulin delivery. Any delays or reduction in the absorption of insulin can impact the performance of the AID system. Users need to ensure that they have a routine for cannula changes. Some users may also note a transient period of 1–2 h after a cannula site change where their glucose may have increased unexpectedly. The precise reason for this is unclear, but it may be related to delays in insulin absorption or inflammation around a newly placed cannula.

Additionally, awareness of how the system calculates and displays insulin information is important. Historically, pump bolus calculators use “active insulin” derived from the insulin action time rather than the duration of insulin action, and display a calculation of the remaining manual bolus insulin only (meaning temporary basal rates or suspensions are not incorporated) [45]. Commercial AID systems may still use this concept of active insulin from bolus insulin only, and may not provide an estimate of the total insulin onboard. However, open source AID systems use the “net” insulin delivery and provide a calculation of total insulin delivery based on the duration of insulin action, whether this is from basal or bolus, and whether it is manual or automatically dosed [3]. Therefore, the net insulin activity can be greater than zero and “less than zero.”

Awareness of these numbers and how they are calculated in a chosen AID system is also important when a user is seeking to manually correct or intervene in a situation—such as correcting an ongoing high, or deciding what action, if any, to take prior to exercise. A lack of awareness or knowledge of all the insulin delivered by the system can result in a manual dose in addition to dosing that has already “corrected” for the situation, causing additional hypoglycemia.

Understanding the type of system and how it works—in as much detail as providers and patients are able to get from commercial manufacturers, who historically have not provided extensive detail—can also aid in optimizing the use of AID systems. For example, most open source systems and some commercial AID systems are anchored on and calculate insulin delivery adjustments from a user-entered “profile” with parameters such as basal rates. This is the information used to decide whether to give more or less insulin compared to baseline. These systems adapt in response to changing glucose levels and predictions; however, they are usually not considered to be “learning” systems. The benefit of such a profile-based system is that the system can be directed by changing the baseline basal rates, adjusting targets, and/or (as is used in open source systems) profile switches or preset profiles. These options are useful if changes in insulin sensitivity occur over short periods of time, such as during the menstrual cycle, sporadic or different types of exercise, or anticipated periods of stress. This, however, necessitates a more accurate profile and, in order to proactively manage variations in sensitivity, requires anticipation of the insulin delivery needs in different situations. The alternative is the commercial AID systems that are considered to be learning systems: they learn and adapt based on different input variables (such as weight) or the basal profile, updating the profile based on the learned “need” they perceive. The benefit of learning systems is that they adjust the basal profile on their own. However, they may not be as rapidly responsive to short-term changes in insulin sensitivity, and, depending on the system, parameters such as glucose targets may need to be altered to manage such events, although there are likely to be fewer parameters to provide input. It is also possible that these systems learn something that then no longer applies, and there is also a delayed period before it learns that something has changed again.

Table 2 further summarizes these tips and tricks for optimizing success with AID systems.

Table 2 Tips and tricks for success with automated insulin delivery systems
Full size table

Changing Settings and Behaviors to Get the Best Outcomes with AID

Once an AID system is taking on as much of the routine work of diabetes management as it is capable of, individuals who find themselves relieved of the day-to-day burden of managing diabetes are more likely to be interested in further optimization to improve their outcomes.

It is fairly common for people adopting AID systems to need to change the baseline settings that they were using before with manual insulin dosing methods. This occurs for a number of reasons, including because people with diabetes have been manually adjusting insulin delivery with dozens of decisions a day using vague settings that generally work when the decisions are imprecise and infrequent. However, an automated insulin delivery system can make decisions as frequently as new glucose values are made available to the system (e.g., every 5 min), and is therefore making significantly more decisions throughout the day. Wrong input variables to the equation determining the insulin adjustment needed can therefore influence how effective the system can be at achieving optimal glucose outcomes. For example, an AID system can be hampered by the wrong input settings, which effectively limit the system’s ability to course correct the resulting blood glucose levels and excursions throughout the day. Some commercial systems aim to address this problem by not requiring input settings such as the basal rate or insulin sensitivity factor (ISF), instead relying on weight (iLet, CamAPS-FX [46]) as an initial variable and adjusting over time or learning from the manual mode to determine the appropriate basal rates (Medtronic 780G). In all the AID systems, the insulin to carbohydrate ratio (ICR) needs to be set appropriately, and may need adjustments.

Other commercial systems, as well as the open source AID systems, operate from baseline settings similar to standalone pumping. Many people have not changed their baseline pump settings in a long time, and they may not be very accurate compared to their current physiological reality. Insulin needs to change over time depending on stress and activity levels, the temperature/climate, diet patterns, sleep patterns, hormonal changes, and growth. Therefore, it is common for new users of AID systems to adjust their baseline settings to further optimize their glycemic outcomes. Also, the concept of a basal-to-bolus ratio is something that is less relevant with automated insulin delivery because, depending on the AID, the same amount and timing of insulin delivery may be accomplished by basals or boluses. The resulting ratio of bolus to basal insulin is not an indication of setting “correctness,” but instead an indication of what methods of insulin delivery are used by the person and the automated insulin dosing system in order to achieve the best glycemic outcomes. The basal-to-bolus ratio should not be used to drive setting changes in AID.

While it can be tempting to want to change multiple settings at a time, people may benefit from healthcare provider guidance to change one setting at a time (or occasionally a small number of settings that need adjusting together for safety) when the aim is tweaking and optimizing glycemic outcomes. With automated insulin delivery, it can be easier to observe the correlation resulting from one setting change over the course of the following days, which sets up an effective feedback loop to then aid in further tweaking the same setting or progressing to tweaking additional settings.

Additionally, automated insulin delivery systems may prompt some human behavior adjustments too. People using AID systems may find themselves needing less carbohydrate correction for hypoglycemia in terms of frequency as well as quantity. Because the system can predict decreases in glucose and proactively reduce insulin delivery in an attempt to help bring that predicted low glucose into the target range, any subsequent low glucose level will usually require a smaller correction to normalize glucose levels. This can mean that fewer carbohydrates are needed overall [4]. Over time, as people build the habit of choosing smaller carb correction amounts, this also may assist in reducing the number of “rebound” excursions to hyperglycemia or predicted hyperglycemia that the system has to respond to, further reducing glucose variability and improving overall outcomes—as well as making it easier to assess what is contributing to any remaining glucose variability that may still need addressing outside of those situations.

Current Gaps in Knowledge and Potential Future Directions of AID

If you find yourself reading this piece and realizing that you do not have all the answers to the questions we suggest asking, that is OK: you are not alone in this, nor may it be due to a lack of due diligence on your part. Some of the information that is ideal to seek to assess each AID option may not be available. For example, traditionally the commercial manufacturers do not disclose extensive details regarding how their technology works due to perceived intellectual property protection. However, given the role of the person with diabetes to interact with such technology in an automated insulin delivery system, it is our perspective that this information should become available with regard to how a system works (including more details on algorithms), when it does not work, and more. We, as healthcare providers and patients, need to continue to advocate with regulators—who could mandate this level of detail be provided to providers and users of such medical technology—and with manufacturers to make this information available to enable the most effective and most informed decision making when considering the use of these medical device products.

In the meantime, there may not be enough information available to providers, but providers can do the best that they can to acknowledge to themselves and to patients where they do not have detailed information on how the systems work or perform. Providers should also recognize their own discomfort with one or more options due to a lack of knowledge, and not force technology upon patients or limit the choices presented to patients based on their own comfort level or knowledge of particular devices. The choices and preferences of the person living with diabetes should be at the center of any decision around the ideal automated insulin delivery system or any other diabetes technology, and together healthcare providers and people with diabetes should make the most informed choice possible.

Conclusions

Automated insulin delivery systems are a useful tool for people with insulin-requiring diabetes, and there are now numerous choices with regards to both open source and commercially developed systems. Both open source and commercially developed automated insulin delivery systems have been well studied and proven to be safe and effective. Open source and commercially developed automated insulin delivery systems have also, importantly, been proven to improve the quality of life for people with insulin-requiring diabetes. The choice of an AID system is not as simple as whether the system is open source or commercially developed, and indeed there are multiple criteria to assess when choosing an AID system, ranging from pump, CGM, smartphone connectivity and algorithm capabilities to the flexibility of the system overall, as well as the interoperability with connected platforms for real-time data access. Most importantly, the choices and preferences of the person living with diabetes should be at the center of any decision around the ideal automated insulin delivery system or any other diabetes technology. Healthcare providers will benefit from assessing and better understanding all available AID system options to enable them to best support each individual.