Design and Clinical Evaluation of the Interoperable Artificial Pancreas System (iAPS) Smartphone App: Interoperable Components with Modular Design for Progressive Artificial Pancreas Research and Development

Abstract

Background: There is an unmet need for a modular artificial pancreas (AP) system for clinical trials within the existing regulatory framework to further AP research projects from both academia and industry. We designed, developed, and tested the interoperable artificial pancreas system (iAPS) smartphone app that can interface wirelessly with leading continuous glucose monitors (CGM), insulin pump devices, and decision-making algorithms while running on an unlocked smartphone.

Methods: After algorithm verification, hazard and mitigation analysis, and complete system verification of iAPS, six adults with type 1 diabetes completed 1 week of sensor-augmented pump (SAP) use followed by 48 h of AP use with the iAPS, a Dexcom G5 CGM, and either a Tandem or Insulet insulin pump in an investigational device exemption study. The AP system was challenged by participants performing extensive walking without exercise announcement to the controller, multiple large meals eaten out at restaurants, two overnight periods, and multiple intentional connectivity interruptions.

Results: Even with these intentional challenges, comparison of the SAP phase with the AP study showed a trend toward improved time in target glucose range 70–180 mg/dL (78.8% vs. 83.1%; P = 0.31), and a statistically significant reduction in time below 70 mg/dL (6.1% vs. 2.2%; P = 0.03). The iAPS system performed reliably and showed robust connectivity with the peripheral devices (99.8% time connected to CGM and 94.3% time in closed loop) while requiring limited user intervention.

Conclusions: The iAPS system was safe and effective in regulating glucose levels under challenging conditions and is suitable for use in unconstrained environments.

Introduction

Artificial pancreas (AP) systems close the loop between a continuous glucose monitor (CGM) and an insulin pump with an algorithm that adjusts insulin dose to control blood glucose (BG) in people with type 1 diabetes (T1D). Recent studies have shown that AP improves outcomes over sensor-augmented pump (SAP) with improvements in time in target glucose range, less hypo- and hyperglycemia, and in longer term studies, improved hemoglobin A_1c (HbA_1c).^1–6

Due to limitations with subcutaneous route of insulin administration and the current rapid acting insulin analogs, the AP systems available today, commonly referred to as hybrid closed-loop systems, still require the user to manually intervene with system functions in a number of ways such as meal announcement. These AP systems are rapidly evolving with many closed-loop platforms being developed for and evaluated in clinical settings.^4,5,7–14

A challenging aspect of diabetes management is tied to the use of diabetes technology and the all-consuming nature of glucose monitoring and control. As AP systems progress from simulator testing, to bench testing, to clinical trials, and then to home use, a better understanding of the challenges of AP development has arisen. In particular, considerations of user-centric design and wearable form factors are necessary to reduce barriers to this technology and enable a system that is suitable for long-term outpatient use. Toward this end, user interface and peripheral device connectivity, fault detection and mitigation, user acceptance and trust in the AP system, and psychosocial impacts of AP technology are all being understood as areas that need improvement and further study.^15–20

In this article, we report on the design and first clinical evaluation of a new smartphone-based application platform called the interoperable artificial pancreas system (iAPS). The design goals were twofold: seamless integration with leading CGM and insulin pump devices, and interface with different decision-making algorithms with an app running on an unlocked smartphone. Thus, the iAPS provides a path forward for testing and clinical evaluation of an interoperable AP with modern peripheral devices and state-of-the-art algorithms. The clinical evaluation of iAPS was performed as a U.S. Food and Drug Administration (FDA) investigational device exemption (IDE) study, thus complying with existing regulatory pathways for AP studies. To the best of our knowledge, this article presents the first in-human evaluation of an artificial pancreas app running on an unlocked smartphone in an FDA-approved IDE clinical study.

Methods

Background

Modular design of AP systems, on both hardware and software levels, allows for accommodation of rapidly changing diabetes device technology and algorithms, and hence streamlines AP use in clinical settings.¹⁰ The various AP systems in development can be broadly grouped as those using dedicated embedded hardware or those relying on a dedicated locked-down smartphone device or some combination of the two.^7,21,22 While the use of dedicated embedded hardware ameliorates issues related to connectivity, it is a less modular system for research purposes. A smartphone-based solution provides modularity and access to software updates, enabling several outpatient studies and moving the AP field forward.

However, a dedicated device may also restrict device functionality and requires the user to carry an extra smartphone, increasing user burden. An AP system designed around an unlocked smartphone offers the most flexibility and modularity, and thus can result in better user acceptance and improved clinical outcomes, with the possibility of the AP system smartphone being the same device as the user's regular smartphone. There has also been increasing patient engagement around DIY projects such as OpenAPS and Loop, underscoring the need for an AP smartphone app.²³ A list of selected current academically developed AP platforms used in regulated clinical studies such as Diabetes Assistant,⁹ Florence,¹² Bionic AP,¹¹ OHSU Bihormonal AP,¹⁴ BiAP,¹³ and artificial pancreas system (APS)¹⁰ is shown in Appendix I (see Supplementary Data available at https://www.liebertpub.com/doi/suppl/10.1089/dia.2018.0278).

Our aim was to design, develop, and test a smartphone app (the iAPS) that can interface wirelessly with leading CGM, insulin pump devices, and decision-making algorithms while running on an unlocked smartphone. The iAPS builds on the previous APS initially built into a laptop computer and then on a tablet.¹⁰ APS has been used by 14 different groups in the United States, Israel, the Netherlands, France, and Italy for both academic and industry clinical trials.^6,8,24–29

The APS system has been rebuilt from the bottom-up in the form of a cross-platform smartphone (client) app, which can be distributed through a private channel on Google Play, and a back-end remote monitoring and management infrastructure. To enable use on an unlocked smartphone, the app and the remote system have built-in cybersecurity controls to protect and safeguard the user and to maintain the confidentiality and integrity of information using communication over a secure channel and strict checks to grant user access to the app. In addition, the app has been designed and tested to be compatible with different configurations of the smartphone operating system, and can be used concurrently with everyday third-party apps without affecting use of the host phone in any meaningful way. While the app is designed to be run on both Android and iOS, the current study utilized a Google Pixel smartphone running Android 7.1.

Features of iAPS

• Device integration: As the current diabetes technology ecosystem is heterogeneous, a major concern in an AP system is interoperability. The iAPS provides wireless integration with Dexcom G5 and G6 CGM (Dexcom, Inc., San Diego, CA), and two different insulin pumps: a modified Tandem t:slim™ insulin pump (the Tandem t:AP pump) (Tandem Diabetes Care, Inc., San Diego, CA) and an OmniPod^® insulin pump with a modified Personal Diabetes Manager (PDM; Insulet Corporation, Billerica, MA). The modifications made to each pump system by the different vendors allow for Bluetooth Low Energy (BLE) communication with a smartphone. The iAPS system components are shown in Figure 1.

• User experience: The iAPS's intuitive user interface allows the user to interact with the devices, request an insulin bolus for a meal or correction, provides the ability to log various activities such as exercise and rescue carbohydrates while prominently displaying the current glycemic status, including the current insulin-on-board (IOB). The main screen of iAPS client app is shown in Figure 1.

• Alarms and safeguards: The iAPS provides alarms for system malfunctions such as loss of peripheral device connectivity and anomalies in smartphone operation. To ensure additional safety, SMS (short message service) notifications are sent to the user's designated followers in case of certain alarm events. The system also uses a temporary basal rate to control the pump, allowing the pump to revert to preprogrammed open-loop settings when communication between devices is interrupted for >30 min.

• Remote monitoring: The iAPS client app securely synchronizes data with a remote server. Not only can remote monitoring be used as a mitigation during early AP studies^30,31 but automatic upload of device data to a remote monitoring website facilitates quick analysis and dissemination of results as well (Appendix II in Supplementary Data).

• Algorithms: The core of an AP system is a closed-loop algorithm that commands insulin delivery. Additional algorithms can be used as part of a safety system to monitor for hypoglycemia. iAPS provides an interface with algorithms as interdependent modules, which can be updated and tailored for a study, described in the ensuing section.

FIG. 1.

Overview of the iAPS system components: smartphone running the client app, Dexcom G5/G6 CGM, and Tandem or Insulet insulin pumps. The app main screen provides access to pump, CGM, bolus, user, event, and activity pages along with graphical display of glucose and insulin history, current CGM and its trend, and IOB values. CGM, continuous glucose monitor; iAPS, interoperable artificial pancreas system; IOB, insulin-on-board.

System description

Figure 2 describes system-level hardware and software modules that are part of the iAPS. The app queries the peripheral devices (CGM and pump) and interfaces with the main algorithm modules by providing insulin history (separately as insulin requested by the user and insulin requested as microboluses by the controller), CGM history, capillary fingerstick glucose history, and user profiles over the day for basal rate, carbohydrate ratio, and insulin sensitivity factor. The main algorithm modules in the iAPS are as follows:

• Closed-loop controller (CLC): a module to control BG through active hormone management. In closed-loop operation, this module is invoked with each glucose broadcast (e.g., every 5 min) to determine a recommended infusion for immediate delivery by the paired system pump. In this study, we incorporated the insulin-only Zone-MPC controller, which uses explicit model-based predictions and optimization of a cost function to calculate insulin dose to bring BG into a target range.^32,33 This controller has been extensively evaluated in multiple prior outpatient studies,^1,18,29,34 but was modified for this study to use a target zone of 80–120 mg/dL. Controllers utilizing multiple hormones can also be interfaced in the future.

• Meal-correction controller (MCC): a module to calculate insulin boluses based on meal and BG data. In both open-loop and closed-loop operations, this module is invoked based on user request (e.g., user provides meal information) to calculate a meal/correction bolus for immediate delivery by the system.

• IOB: a module to track residual insulin, delivered through the paired system pump, which is yet to become active in the body using IOB decay curves.³⁵ In both open-loop and closed-loop operations, this module is invoked following insulin delivery and periodically thereafter (e.g., every 6 min).

• Health monitoring system (HMS): a module to monitor BG and provide an alarm for hypoglycemia. In this study, the HMS was independent from the AP control algorithm and advised users to ingest fast-acting carbohydrate to prevent impending hypoglycemia (CGM <65 mg/dL) that could not be prevented by controller action alone.³⁶ In addition to the HMS module, the app has built-in threshold-based alarms for hypoglycemia and hyperglycemia, where the user can specify two levels of thresholds for low BG and high BG.

FIG. 2.

Overview of the main system-level modules in the iAPS. The smartphone client app communicates with the CGM and pump hardware devices, interfaces with algorithm modules CLC, IOB, MCC, and HMS (which can also interface with each other), and securely stores data in a local database and a remote server accessible to clinicians in real time through a monitoring site. CLC, closed-loop-controller; HMS, health monitoring system; MCC, meal-correction-controller.

On start-up, the app performs verification of an active registration record before granting a user access. All communications with the remote server are over a secure channel. By default, the app starts in open loop and on user selecting an operational pump and CGM, user action is required to switch to closed loop. When in closed-loop operation, for each glucose broadcast from the CGM, the app repeatedly attempts to complete a time-triggered control cycle consisting of the following.

• 1.Confirming that the selected pump is operational and idle, and requesting a temporary basal rate of 0 U/h for 30 min.
• 2.Calculating an insulin microbolus by calling the CLC module.
• 3.Requesting immediate delivery of the calculated bolus by the selected pump. The app cancels the control cycle if it determines that the selected pump is busy delivering a bolus (e.g., user requested bolus right before the start of a control cycle).
• 4.Updating IOB value by calling the IOB module.

Apart from these time-triggered tasks, the app performs similar tasks in an event-triggered manner related to the user requests such as meal/correction boluses. Concurrently, for each glucose broadcast from the CGM, for both open-loop and closed-loop operations, the app repeatedly calls the HMS module and notifies the user when a hypoglycemic alarm is active.

The app attempts auto-reconnection with peripheral devices when it detects loss of connection and notifies the user if it fails to reconnect. When in closed-loop operation, the app transitions to open loop when it is unable to deliver requested insulin for three consecutive control cycles or immediately if the CGM or pump becomes inoperable. In either case, the app will repeatedly raise an alarm to notify the user and followers. In case of intermittent missing CGM broadcasts, the app provides a phantom value to the algorithms and stays in closed loop. The user notifications related to app events are classified in order of increasing severity and potential impact as follows.

• 1.Notice: notifications to inform the user of a situation that may degrade app performance such as when the CGM needs calibration or loss of Internet connection.
• 2.Alert: more severe in nature than notices, requiring prompt action by the user such as when the pump insulin cartridge is low or temporary loss of connection to the pump or the CGM.
• 3.Alarm: notifications requiring immediate action by the users to address their safety such as impending hypoglycemia, loss of BLE connection, or when the pump is unable to deliver a requested bolus. In addition, each user's designated followers are notified by a text message when an alarm occurs.

Each user notification is repeated at a predetermined frequency ranging from every 60 min to every 10 min if the app event is not resolved.

System testing

As part of the IDE application, we performed the following three groups of tasks to verify the extended, continuous operation of iAPS under simulated real-life use: algorithm verification, hazard and mitigation analysis, and complete system verification.

Algorithm verification was performed in silico using the T1D metabolic simulator³⁷ under scenarios of varying meal sizes (from 30 to 120 g) with 0%, 100%, 130%, and 70% accompanying insulin bolus sizes, and in hardware-in-the-loop advisory mode using previous clinical data.^1,6 The Zone-MPC algorithm used in these previous studies was modified to lower the upper target zone limit from 140 mg/dL down to 120 mg/dL. The effect of changing the upper zone in the controller from 140 to 120 mg/dL is discussed in Appendix III (in Supplementary Data).

A thorough hazard and mitigation analysis was conducted to identify usage risks following ISO 14971,³⁸ in particular user harm from underdelivery or overdelivery of insulin. Cybersecurity risk analysis was conducted as per ISO 14971 and NIST 800-30,³⁹ which included development of a threat model and penetration testing for factors related to user interaction, iAPS modules and libraries, BLE communication, and remote monitoring infrastructure. These risks were deemed sufficiently low for safe usage after the implementation of various mitigations, including detailed documentation aimed at end users and clinical personnel.

Verification bench testing was performed to ensure that iAPS operated safely using test cases following the software requirements and design specifications. These included, but were not limited to, tests related to connectivity between the phone and the pump, phone and the CGM, functioning of iAPS modules, and remote management infrastructure. Additional tests included simulating real-life use in unconstrained environments such as continuous operation of iAPS running with third-party apps for streaming media and games (Appendix IV in Supplementary Data), the effect of different Android notification settings on the iAPS, and normal usage interruption events such as cartridge refill and pump and phone battery charging.

Clinical evaluation

We assessed the performance of the iAPS in a 48-h pilot clinical feasibility study of six participants with T1D. The study was conducted at the Sansum Diabetes Research Institute (Santa Barbara, CA) in April 2018. Design of control algorithms and the iAPS was done at the Harvard John A. Paulson School of Engineering of Applied Sciences, Harvard University (Cambridge, MA).

Eligible participants were between 18 and 75 years of age with T1D for at least 1 year, using an insulin pump for at least 6 months, and HbA_1c <10.5%. Key exclusion criteria were pregnancy, one or more episodes of hypoglycemia or hyperglycemia requiring an emergency room visit in the past 6 months, or known unstable cardiac disease. Informed consent was obtained before all study procedures. The protocol was approved by the FDA and Chesapeake Institutional Review Board, and registered at clinicaltrials.gov (NCT03504046).

Before AP use, participants performed a 1-week run-in phase using SAP with a Dexcom G5 CGM to review and optimize each participant's open-loop insulin pump settings throughout the week. The sensor was replaced at least 24 h before the AP session. The 48-h AP session started at ∼17:00 on day 1. The study then included two overnight periods, multiple large meals that were eaten out at restaurants, a late-night ice cream dessert, extensive walking throughout the day with no exercise announcement to the controller, and multiple connectivity tests with the peripheral devices.

Specifically, these tests included (1) device connectivity and ease of re-establishing communication by nonexpert users: leaving the phone out of range of the pump and CGM for 30 min and turning off Bluetooth on peripheral devices for 30 min. In both cases, verifying that the pump returns to preprogrammed basal delivery and that the devices reconnected when back in range; and (2) CGM connectivity: starting a new CGM sensor midsession, verifying that the CGM reconnects and closed loop can be restarted by nonexpert users. This is similar to other evaluations of other new AP systems.⁴⁰ We also tested concurrent operation of iAPS: running third-party apps for streaming media and games, text messages, and phone calls while in closed loop, verifying this did not interfere with functioning of the iAPS.

Participants used either the Tandem t:AP pump or the modified Insulet PDM and Pod along with a Dexcom G5 CGM. Both the pump and CGM were wirelessly connected to the iAPS running on Google Pixel smartphone. Boluses for all meals under closed loop were given at mealtime based on the personal carbohydrate ratio as previously described,¹ although the iAPS allowed modification of these boluses by each user at his or her discretion. Correction boluses were also modifiable by the users. Participants could select the type and carbohydrate content of their meals and snacks according to their dietary preferences.

In addition to extensive walking around the city of Santa Barbara, participants also performed a 1-h outdoor exercise session (brisk walk) in the late morning on day 2. All meals were eaten out at restaurants, and an ice cream dessert was given late in the evening on day 2. For safety monitoring, capillary fingerstick glucose measurements were performed 30 min before meals, 2 h after meals, at bedtime, when prompted by the HMS³⁶ or as requested by the user. Remote monitoring alerts to clinical personnel for both connectivity and glycemic disturbances were enabled in this pilot clinical trial, as well as automatic uploading of study device data to the remote server. Participants were discharged at ∼17:00 on day 3 of the study.

The main outcome measure was the safety and feasibility of using the iAPS. Secondary outcomes included glycemic metrics as recommended in previous AP outcome consensus statements.⁴¹

Results

Participants

Participant demographics are shown in Table 1. To challenge the AP system, participants varied significantly in their overall insulin needs, ranging from 10.4 to 104.8 U per day total daily dose [0.18–0.97 U/(kg·d)].

Table 1.

Participant Demographics and Baseline Characteristics (n = 6, Mean ± Standard Deviation)

Characteristic
Age (years)	56.5 ± 8.3
Gender (n)
Women	3
Men	3
Weight (kg)	72.1 ± 21.2
BMI (kg/m2)	24.1 ± 5.0
HbA1c (%)	6.8 ± 0.7
TDI (U/day)	35.6 ± 35.9
TDI [U/(kg·d)]	0.44 ± 0.3
Duration of diabetes (years)	27.3 ± 22

BMI, body mass index; HbA_1c, hemoglobin A_1c; TDI, total daily insulin.

Glycemic control

Glycemic metrics comparing the SAP run-in week with the 48-h AP study are shown in Table 2. Participants consumed a significant amount of carbohydrates over the 48-h study (175.8 ± 92.8 g carbohydrate/24 h) as every meal was eaten out at restaurants, along with an ice cream dessert on the evening of study day 2. In addition, long periods of walking during the day and a 1-h brisk walk (all not announced to the controller) had the potential to cause significant glycemic disturbances.

Table 2.

Glycemic Metrics, Using the Complete Continuous Glucose Monitor Data, Comparing the 1-Week Sensor-Augmented Pump Run-in Period with the 48-h Artificial Pancreas Study [Mean (Standard Deviation)]

CGM metric	SAP (n = 6)	Closed loop (n = 6)	P
Mean glucose (mg/dL)	132.3 (18.2)	136.1 (17.9)	0.69
SD glucose (mg/dL)	47.3 (7.8)	37.5 (8.6)	0.09
% Time
<54 mg/dL	1.8 (1.9)	0.1 (0.2)	0.03*
<60 mg/dL	2.9 (2.8)	0.4 (0.5)	0.03*
<70 mg/dL	6.1 (5.7)	2.2 (2.1)	0.03*
70–140 mg/dL	55.6 (10.0)	54.7 (14.8)	ns
70–180 mg/dL	78.8 (5.1)	83.1 (12.4)	0.31
>180 mg/dL	15.1 (7.8)	14.7 (13.5)	0.84
>250 mg/dL	2.6 (2.6)	0.6 (1.3)	0.13
>300 mg/dL	0.8 (1.1)	0.0 (0.0)	0.25

^*Indicates a significant change as assessed by the signed-rank test.

CGM, continuous glucose monitor; ns, not significant; SAP, sensor-augmented pump.

Despite these challenges, and with only six participants in this initial evaluation of the iAPS, comparison of the SAP run-in phase with the 48-h AP study showed a trend toward improved time in target glucose range 70–180 mg/dL (78.8% vs. 83.1%; P = 0.31) and a statistically significant reduction in time below 70 mg/dL (6.1% vs. 2.2%; P = 0.03) while using the iAPS. Paired comparison of mean glucose and time in 70–180 mg/dL between SAP run-in phase and AP study is shown in Figure 3. Glycemic metrics for each individual subject are shown in Appendix V (in Supplementary Data). Analyzed individually, five of six subjects showed improvement in time in range during the closed-loop AP study, while the incidence of hypoglycemia decreased across all six subjects. Despite large meals, none of the six subjects spent time in the upper hyperglycemic range (>300 mg/dL).

FIG. 3.

Paired comparison of mean glucose (a) and time in 70–180 mg/dL (b) during run-in SAP phase and iAPS closed-loop AP study. The percent time spent below 70 mg/dL is shown by bubble of varying size, while solid lines connect individual participants (n = 6). The dashed red line shows the group mean with annotated value for both subplots. SAP, sensor-augmented pump.

Connectivity metrics and system usability

Device connectivity for both CGM and pump was excellent throughout the study, as shown in Table 3. The system quickly resumed connectivity after intentional interruptions. The iAPS system performed reliably and showed robust connectivity with the peripheral devices (99.8% time connected to CGM and 94.3% time in closed loop). While the Dexcom G5 CGM stayed well paired to the iAPS, there were limited disconnections with the two pumps. On analyzing the connectivity metrics for all participants, for Tandem t:AP participants only and for Insulet OmniPod participants only, the number of app notifications was slightly more with the OmniPod pump than with the Tandem pump.

Table 3.

Connectivity Metrics During the 48-h Artificial Pancreas Study for All Participants, for Tandem t:AP Participants Only and for Insulet OmniPod Participants Only

Metric	All participants (n = 6)	Tandem t:AP (n = 3)	Insulet OmniPod (n = 3)
Device connectivity
% Time CGM connected	99.8 (1.0)	99.7 (1.3)	99.8 (0.9)
% Time valid CGM	95.7 (4.2)	92.7 (3.9)	98.7 (1.2)
% Time in closed loop	94.3 (3.9)	94.7 (4.5)	94.0 (4.2)
No. of pump disconnections	2.2 (1.2)	1.7 (1.5)	2.7 (0.6)
No. of notifications by type
No. of alarm notifications	11.8 (6.0)	9.0 (5.3)	14.7 (6.1)
No. of alert notifications	21.0 (5.3)	16.7 (3.5)	25.3 (0.6)
No. of notice notifications	20.8 (8.3)	19.7 (12.6)	22.0 (3.0)
Total notifications	53.7 (15.4)	45.3 (19.5)	62.0 (2.6)
No. of notifications by source
Pump	23.7 (9.4)	15.7 (5.0)	31.7 (1.2)
CGM	2.5 (0.8)	3.0 (1.0)	2.0 (0.0)
Smartphone	1.8 (1.0)	2.3 (1.2)	1.3 (0.6)
iAPS modules	25.7 (10.6)	24.3 (16.4)	27.0 (1.7)
No. of notifications for select events
Accrued no. of glucose-related notifications	5.5 (4.5)	7.0 (5.6)	4.0 (3.6)
Accrued no. of connectivity-related notifications	21.7 (12.2)	11.7 (8.1)	31.7 (2.1)

The metrics [mean (SD)] are calculated after excluding the time periods of intentional connectivity robustness testing. The CGM metrics are reported as percent time CGM was connected to iAPS and percent time when a valid CGM value was broadcasted. Percent time in closed loop and number of pump disconnections requiring manual intervention are reported. Note that the system stays in closed loop under missing CGM data. The number of notifications is stratified by type, source, and select events. Each iAPS notification is an alarm (notifications that require immediate user attention), alert (notifications that require prompt user attention), or notice (notifications to inform the user). Notifications generated due to state of the pump, CGM, phone, and app are reported. Finally, the number of accrued glucose-related notifications and accrued connectivity-related notifications is noted where it is important to note that a single event can consist of repeated notifications till that event is resolved.

iAPS, interoperable artificial pancreas system.

The number of notifications stratified by type, source, and select events is reported in Table 3. Stratifying the notifications by type, 22% were alarm notifications that required immediate action by the user, 39.1% were alert notifications that required prompt action by the user, and the remaining 38.9% were notices to bring noncritical events to the attention of the user. Stratifying notifications by state of the source, 44.2% were related to pump (such as low cartridge, failed to set temporary basal rate, and loss of connectivity), 5% were related to CGM (such as calibration), 3.6% were related to phone (such as low battery), and 47.1% were related to app (such as state of closed loop). Stratifying for select events, 11.1% of accrued notifications were glucose related triggered by predictive and threshold-based hypoglycemia alarms and 37.1% of accrued notifications were connectivity related triggered by loss of connection with the peripheral devices and subsequently caused events such as failure to set basal rate or deliver bolus.

It is important to emphasize that the app repeatedly generated notifications until an event was resolved with the frequency of notifications determined by the event severity. Thus, a single event can be logged and notified multiple times by the app. For instance, a single hypoglycemic event will involve alarm notifications from both predictive and threshold alarms which are repeated between every 10 to 30 min (depending on the BG value) until predicted BG and current BG, respectively, are in the safe range. For patient safety on this experimental system, we had enabled more notifications than what is ideal for real-life outpatient use. Manual user intervention was required for alarm notifications such as impending hypoglycemia and failure to deliver bolus. In most cases, reconnection of the pump and CGM to the phone (on average once per day) was easily performed by study subjects by bringing devices closer to the phone and simply pressing the connect button on the app in cases where auto-reconnection did not occur, followed by switching back to closed loop.

As part of supervised connectivity testing, the subjects were happy to use the study phones as their own phone, used them to send SMS/MMS (multimedia message service) messages, watch streaming videos, and make phone calls, all while closed loop was active. There were no instances of failures in any of the modules while the app ran along other third-party apps.

Adverse events

There were no adverse events or serious adverse events during the study.

Conclusions

The development of hybrid closed-loop AP systems is rapidly accelerating. Medtronic released the MiniMed 670G for commercial sale in the United States in 2017. The first clinical results of the initial algorithm evaluations for use in Insulet's OmniPod^® Horizon™ hybrid closed-loop system have been published.^8,24 Additional AP systems that are based on a locked smartphone such as the inControl platform from TypeZero Technologies, Inc. (Charlottesville, VA) are also in use in AP trials.⁴² Many other companies and academic groups are also pursuing AP development. While the DIY projects such as OpenAPS and Loop run on a portable platform and have produced excellent glycemic results and high user satisfaction,²³ these systems exist outside of any regulatory framework, require use of older insulin pumps, and are not currently designed to be used for clinical trials.

Many AP systems in development have certain limitations such as restricted peripheral device options (connectivity with only a particular pump and/or CGM), or may lack a modular architecture, and hence may not be suitable for use in early-stage clinical trials. In this article, we present results for the iAPS system used in a pilot FDA-approved IDE clinical study. The system was safe and effective in regulating BG with robust connectivity and no adverse events in the presence of large meals and unannounced exercise. While the app required limited user interventions, the range of notifications was kept broad for patient safety.

The iAPS modular system with its features, such as a client app, which can run on commercial off-the-shelf smartphones, distribution of the app through a private channel on Google Play, wireless connectivity, interoperability with multiple insulin pumps and CGM, interface with algorithms and remote monitoring, makes this closed-loop platform suitable for use in clinical trials within existing regulatory frameworks throughout the world. Short duration of the trial, small sample size, and 24-h clinical supervision and technical support available as part of the approved clinical protocol were limitations of this study. In addition, as this clinical study was a pilot effort to evaluate safety of a new experimental AP platform, system usability questionnaire surveys were not conducted. Future work will focus on further refinement of the system, particularly around user acceptance and its evaluation in real-life unconstrained outpatient environments.

Author Disclosure Statement

J.E.P. has conducted research sponsored by Tandem Diabetes Care, Insulet Corporation, and Bigfoot Biomedical; has received speaker's bureau fees from Tandem Diabetes Care; and has received product support to his institution as principal investigator from Insulet, Animas, LifeScan, Roche, Ascensia, Tandem, and Dexcom. F.J.D. and E.D. have received product support from Insulet, Animas, LifeScan, Roche, Tandem, and Dexcom, and E.D. has received consulting fees from Insulet Corporation. All other authors report no conflict of interest related to this article.