The Diabetes Assistant: A Smartphone-Based System for Real-Time Control of Blood Glucose

Abstract

Type 1 Diabetes Mellitus (T1DM) is an autoimmune disease in which the insulin-producing beta cells of the pancreas are destroyed and insulin must be injected daily to enable the body to metabolize glucose. Standard therapy for T1DM involves self-monitoring of blood glucose (SMBG) several times daily with a blood glucose meter and injecting insulin via a syringe, pen or insulin pump. An “Artificial Pancreas” (AP) is a closed-loop control system that uses a continuous glucose monitor (CGM), an insulin pump and an internal algorithm to automatically manage insulin infusion to keep the subject’s blood glucose within a desired range. Although no fully closed-loop AP systems are currently commercially available there are intense academic and commercial efforts to produce safe and effective AP systems. In this paper we present the Diabetes Assistant (DiAs), an ultraportable AP research platform designed to enable home studies of Closed Loop Control (CLC) of blood glucose in subjects with Type 1 Diabetes Mellitus. DiAs consists of an Android (Google Inc., Mountain View, CA, USA) smartphone equipped with communication, control and user interface software wirelessly connected to a continuous glucose monitor and insulin pump. The software consists of a network of mobile applications with well-defined Application Programming Interfaces (APIs) running atop an enhanced version of Android with non-essential elements removed. CLC and safety applications receive real-time data from the CGM and pump, estimate the patient’s metabolic state and risk of hypo- and hyperglycemia, adjust the insulin infusion rate, raise alarms as needed and transmit de-identified data to a secure remote server. Some applications may be replaced by researchers wishing to conduct outpatient ambulatory studies of novel Closed Loop Control, Safety or User Interface modules. Over the past three years the DiAs platform has been used in a series of AP clinical trials sponsored by the National Institutes of Health, the Juvenile Diabetes Research Foundation, the Helmsley Charitable Trust and the European Union AP@Home project. Results of clinical trials using DiAs indicate that a smartphone with targeted operating system modifications and appropriate system software can be successfully used in outpatient clinical trials of FDA Class III medical devices such as Artificial Pancreas.

1. Introduction

In health, beta cells located within the human pancreas secrete insulin, enabling the body to metabolize glucose and maintain the concentration of blood glucose (BG) at a safe level of approximately 70–120 mg/dL. Type 1 Diabetes Mellitus (T1DM) is an autoimmune disease in which beta cell function is destroyed, resulting in elevated levels of glucose in the bloodstream. Persistent high blood glucose (hyperglycemia) can lead to serious long-term health conditions such as retinopathy, kidney disease, and neuropathy and in some cases may cause ketoacidosis (DKA) with the risk of seizure and even death. In order to be able to metabolize glucose from meal carbohydrates or produced by the liver, type 1 diabetics must treat themselves daily with exogenous insulin either using an insulin pump or via Multiple Daily Injections (MDI). Since insulin has the effect of lowering blood sugar, over-delivery of insulin poses a short-term risk of dangerously low blood glucose (hypoglycemia), which may cause disorientation, confusion, and in certain cases, coma or death. People with T1DM must therefore navigate a complex optimization problem, frequently measuring their blood glucose with a lancet and measurement strip and injecting sufficient insulin to keep their blood glucose within a safe range. The sensitivity of the human metabolic system to insulin varies with the time of day, physical exertion, illness and other factors, further complicating the process of maintaining tight glycemic control.

Standard insulin therapy involves frequent measurement of blood glucose and manual injections of long-acting insulin for baseline needs and rapid-acting insulin at meal times. Insulin pumps, first introduced in the 1960s, support basal delivery through a regular infusion of rapid-acting insulin as well as manually requested boluses at meal times. Most modern pumps infuse insulin into the subcutaneous tissue, resulting in a form of insulin therapy known as Continuous Subcutaneous Insulin Infusion (CSII). In recent years, this therapy has been enhanced with subcutaneous Continuous Glucose Monitors (CGM), which provides frequent estimates of BG (typically every five minutes) by measuring glucose in the subcutaneous interstitial fluid, allowing patients to better adapt their insulin dosage by observing glucose evolution and trends.

Automated closed-loop control of blood glucose, known as the “Artificial Pancreas” (AP), promises to have a tremendous positive impact on the health and lives of people with type 1 diabetes. The AP idea is not new—it can be traced back decades to studies demonstrating the possibility for external BG regulation using intravenous (i.v.) BG measurement and i.v. infusion of insulin and glucose. Systems such as the Biostator™ were introduced and used in the hospital setting to maintain normoglycemia by exerting both positive (via glucose or glucagon) and negative (via insulin) control [1,2,3,4,5]. A detailed description of the major early designs can be found in [6,7,8,9,10,11]. More work followed, spanning a broader range of BG control techniques, powered by physiologic mathematical modeling and computer simulation [12,13,14,15]. A review of methods for i.v. glucose control can be found in [16]. However, i.v. closed-loop control remains cumbersome and unsuited for outpatient use. An alternative to extracorporeal i.v. control has been presented by implantable intra-peritoneal (i.p.) systems employing intravenous sampling and i.p. insulin delivery [17,18]. The implementation of these systems, however, requires considerable surgery. Thus, with the advent of minimally-invasive subcutaneous continuous glucose monitoring, increasing academic and industrial effort has been focused on the development of s.c.-s.c. systems, using CGM coupled with an external insulin infusion pump and a control algorithm [19,20,21,22]. In September 2006, the JDRF initiated the Artificial Pancreas Project and funded a consortium of centers to carry out CLC research [23]. A number of inpatient studies followed, reporting encouraging results [24,25,26,27,28]. During these studies, a regular computer or laptop was used as the main AP platform to run algorithms and communicate with CGM and pump devices. A comprehensive review of past and present progress, as well as ideas for future AP developments, is presented in recent Perspectives in Diabetes [29]. Following the multitude of successful in-clinic trials of CLC, the next logical step was the transition of CLC to ambulatory use. A major obstacle was the lack of a portable AP platform that was:

• Readily available at low-cost;
• Suitable for ambulatory use and computationally capable of running closed-loop control algorithms;
• Wirelessly connectable to CGM devices and insulin pumps; and
• Capable of broadband communication with a central location for data collection, remote monitoring and safety supervision.

A logical host for a portable AP platform is a smartphone—a consumer electronics device that meets all of the requirements listed above. Using a smartphone as the hardware platform has some advantages; most adults carry one and are accustomed to interacting with its touch screen. However using an unmodified smartphone for the purpose of running CLC presents the problem that smartphones include many additional functions, which may conceivably interfere with the primary function as a medical device. Alterations at the operating system level are needed to ensure that a smartphone can sustain the demands associated with high-risk medical applications, such as the Artificial Pancreas. The pathway to the use of consumer electronics to perform medical functions is discussed in recent FDA guidance [30], which defines medical mobile applications and the process of their regulatory approval. The Medtronic 530G insulin pump with a low glucose suspend feature provides some of the safety features of a full artificial pancreas system and several research groups [31,32], have conducted AP clinical trials with smartphone or purpose-built portable systems. A comprehensive discussion of the current status of artificial pancreas systems is presented in [33].

Section 2 of this paper describes the Diabetes Assistant system concept and discusses its software architecture. Section 3 presents results from recent outpatient AP trials that made use of the DiAs platform. In Section 4 we present conclusions and discuss the next steps for portable artificial pancreas systems.

2. The DiAs AP System: A Mobile Medical Network

An Artificial Pancreas is an inherently networked system, including at minimum a CGM, insulin pump and controller, wirelessly connected in a mobile medical network (Figure 1). This configuration permits flexibility in the choice of CGM sensors and pumps and creates the possibility of distributing processing tasks among the networked devices. An insulin pump, for example, could include algorithms to attenuate or halt insulin delivery when the subject is at risk of hypoglycemia, improving the safety of the overall system by keeping the safety algorithm close to the patient. Such a system must provide clear mechanisms for transfer of control authority as well as safe and graceful degradation in the event of link or device failures. An exploration of some of the opportunities and hazards associated with a distributed implementation of the AP may be found in [34].

Figure 1. Artificial Pancreas as a Mobile Medical Network.

Figure 1. Artificial Pancreas as a Mobile Medical Network.

2.1. Graphical User Interface

For Artificial Pancreas home studies to be feasible, the User Interface (UI) must be designed for operation by the patient without requiring interaction with clinical or technical staff. The DiAs UI presents the patient with their most recent glucose measurement, delivered insulin history and estimated risk of hypo- and hyperglycemia and allows them to manually request insulin and control system operation. The initial UI design was influenced by user focus groups [35] and has evolved through several rounds of clinical trials based on feedback from patients, clinicians and researchers. Figure 2 shows the Home Screen of the DiAs Smartphone, from which phone, text messaging and most other smartphone features have been removed. Atop the screen a modified Android status line indicates (from left to right):

• Bluetooth status
• System operating mode (Pump, Closed Loop, Safety, Sensor, Stopped)
• Most recent CGM value and trend
• CGM device status
• Pump device status
• Connectivity with cloud monitoring services
• Network data link status
• Smartphone battery level
• System time

Figure 2. DiAs Smartphone Home Screen.

Figure 2. DiAs Smartphone Home Screen.

The operating mode determines the rules that DiAs follows when infusing insulin and collecting data. Closed Loop mode activates an internal, replaceable algorithm that uses the daily basal insulin delivery pattern as an operating profile around which it may infuse more or less insulin as required to keep blood glucose in the desired range. Safety mode is a one-sided version of Closed Loop in which the system may only reduce the amount of insulin delivered to the subject when a risk of hypoglycemia is detected, but may not increase insulin delivery above the basal profile. In Pump mode the system emulates the operation of an insulin pump, delivering basal insulin as defined by a pre-programmed daily profile regardless of the subject’s metabolic state. These three insulin delivery modes also permit the user to request insulin boluses as desired. Sensor mode indicates that CGM data is being collected and stored but no insulin is being delivered while in Stopped mode all data collection and insulin dosing is halted.

The center of the screen contains the most recent CGM value and trend, the most recently delivered (non-basal) insulin bolus and controls enabling the user to request a bolus, switch operating modes, display historical plots, indicate the beginning or end of an exercise interval, record a hypoglycemia treatment, calibrate the attached CGM sensor (if supported by the CGM device) and immediately stop the system from delivering insulin. Traffic lights marked “Low” and “High” at either side of the display provide a visual indication of the current risk of hypo- and hyperglycemia with the following interpretation:

• Green—No predicted risk of hypo/hyperglycemia, no user action required.
• Yellow—Some risk of hypo/hyperglycemia, DiAs taking action if in Closed Loop or Safety mode, no user action required.
• Red—Immediate risk of hypo/hyperglycemia, immediate user action required.

A hypoglycemia yellow light while DiAs is in Closed Loop or Safety mode indicates that the Safety System is reducing the basal insulin infusion rate in order to avoid a hypoglycemic event, while a yellow hyper light means that the system is increasing the flow of insulin in an effort to reduce the blood glucose level. A hypoglycemia red light means that hypoglycemia may be imminent—the subject should immediately check their blood glucose (via SMBG) and treat themselves with carbohydrates if necessary. A hyperglycemia red light indicates that there may be a problem with insulin infusion and the user should verify proper operation of their insulin pump, tubing and the infusion site. An exploration of the DiAs User Interface design is presented in [35].

2.2. Software Architecture

The DiAs software was designed in a modular fashion to enable reuse of software components and to support researchers in preparing Investigational Device Exemptions (IDEs) for home trials of AP systems. DiAs permits developers to modify the behavior of the system by replacing certain modules for clinical testing while making use of previously validated and verified DiAs components deposited in a Master File at FDA. The idea is eliminate the need for researchers to build, validate and verify sensor and pump drivers, insulin accounting, database, cloud communication and other software elements, which are common to most AP implementations. In support of this, each DiAs module is defined as System, User or User-Replaceable. System modules are part of the Master File deposited at FDA and are considered fixed elements. User modules are created by researchers planning to use DiAs in their clinical trial, while User-Replaceable module binaries are distributed as part of the Master File software and may be used “as is” or replaced by researchers if desired.

The system design is informed by the Modular Architecture of Closed-Loop Control [36,37], a multi-level blueprint for implementation of AP systems. The idea is that AP system elements are segmented into distinct layers based on function and cycle time. At the base is a Hardware Layer consisting of the CGM, insulin pump and interface software, operating in real time. Layer 1 is a Safety Supervision System that receives data from the devices, performs subject state estimation, checks insulin infusion requests against an internal model, and approves or rejects all insulin requests before they can be sent to the insulin pump. Layers 2 and above run episodically or on demand to correct for BG excursions after meals, adjust the basal insulin infusion rate based upon metabolic changes and provide priming insulin boluses prior to meals to reduce the size of post-meal BG excursions.

Android is used as the operating system because it is open source, provides an advanced set of software tools and flexible inter-process communication and is available on a wide variety of smartphones and other devices. Since Android is a general-purpose operating system that is normally not used in medical devices we made operating system modifications to disable unneeded device functionality and limit the applications running on the device to those required for artificial pancreas. The open source nature of Android has been critical in addressing regulatory concerns arising from using a consumer electronics smartphone as an element of an FDA Class III medical device. The phone, browser, Android Market, SMS messaging, games, music, video, camera and other non-critical elements are disabled. Application package loading is restricted, the GUI status line is enhanced and audio muting is modified to ensure that emergency alarms are always audible.

The software consists of a collection of Android applications, each of which creates one or more activities, services and content providers in its own sandbox area, which communicate with one another through Android. Activities manage the touchscreen interface, services provide long-running background processing and content providers support resource sharing among processes. Figure 3 shows the major elements of the DiAs software, the blocks representing the main components created by each application. Activities and services communicate with one another via directed and broadcast messages, known as Intents, as well as through a central SQLite database (wrapped inside a content provider), which also stores time stamped CGM, insulin, state estimate and other data. DiAs activities and services operate asynchronously, that is they run in response to the availability of new data or a signal from the user, from Android or from another application. The Supervisor process generates a broadcast message at regular intervals, awakening other processes and causing them to evaluate the patient’s basal insulin needs every five minutes and request insulin delivery if required. All insulin-dosing modes permit users to manually request insulin delivery at any time.

Applications shaded gray in Figure 3 are involved in communication with external sensors and pumps and may be considered part of the Hardware Layer as described in the Modular Architecture. The Safety Layer, shaded red, corresponds to Layer 1 of the Modular Architecture. It runs as required to perform state estimation and verify that insulin delivery requests are within a safe range. Automated control processes, shaded green, request insulin delivery at regular intervals—normally every five minutes when triggered by the Supervisor process. Users can request insulin at any time, and the processes that support this asynchronous function are colored blue.

Figure 3. DiAs Software Architecture.

Figure 3. DiAs Software Architecture.

The Hardware, Database, Network Interface, Supervisor, Coordinator and Setup Applications, along with modified Android, are considered core elements of the system and are included in the DiAs FDA Master File. The Main GUI, Meal GUI and Meal Calculation applications are distributed as part of the DiAs Master File code and may be used as-is or replaced by custom versions developed by individual researchers. All other applications must be provided by developers and are specific to particular AP implementations. The SSM Service is a safety module (corresponding to Layer 1 in [36]) which must approve all insulin requests while Constraint Service permits calculation of a maximum value for the patient’s Insulin on Board (IOB), an estimate of the amount of insulin that has yet to be cleared from the subject’s body. The APC Service and BRM Service are controller modules (corresponding to Layers 2 and 3 respectively in [36]), which developers may populate with control algorithms of their own design. Several control algorithms have already been ported to DiAs by groups in the US and Europe. As long as developer applications conform to the DiAs Application Programming Interfaces (APIs), researchers may load their own versions of these modules along with the rest of the DiAs software in order to test them as part of a full AP system. Researchers are responsible, however, for filing an Investigational Device Exemption for the entire system—including DiAs—that includes hazard analysis and mitigation and system level testing of the final configuration.

2.3. Application Programming Interfaces

User and user-replaceable modules communicate with system modules using APIs described in detail in the DiAs AP Software Developer’s Kit (APSDK) provided to approve third-party developers. All modules read and write data to tables within the central SQLite database through the same API. A protection scheme built into the database controls each module’s ability to Query, Update, Insert and Delete database records on a table-by-table basis. User modules also communicate with system modules using a series of Intent-based APIs, which are described in the APSDK.

Figure 4. APC Service APIs.

Figure 4. APC Service APIs.

The APC Service user module contains an artificial pancreas insulin-dosing algorithm and makes use of APIs to communicate with the Coordinator process (via Intents) and the database. Figure 4 outlines the sequence of events, which occur when APC Service is given control at a system tick:

• The Supervisor module emits a broadcast Intent every five minutes, which is received by a broadcast listener within the Coordinator module.
• The Coordinator broadcast listener handler sends the “calculate bolus” command to the APC Service module using an Intent message through a bound connection.
• APC Service queries the database for recent time-stamped CGM, SMBG, calibration and delivered insulin data. It may also request data regarding meals, physical activity and previously calculated quantities.
• After verifying that APC Service has appropriate read permissions the Database returns the requested information.
• APC Service calculates the appropriate amount of insulin to deliver and sends a “calculation result” message to the Coordinator using an Intent through a bound connection. Attached to this Intent is the amount of insulin, in Units, which should be immediately delivered to the subject as well as the “differential basal rate” in Units/hour, which indicates how much the current profile basal rate should be increased or decreased.
• Coordinator sends an Intent to SSM Service notifying it of the size of the bolus and differential basal rate which should be delivered to the insulin pump.

The CGM service and Pump service asynchronously store time-stamped CGM and insulin information to the database as it is received. Details of the APIs for all user and user-replaceable modules are provided in the DiAs Master File.

2.4. Smartphones and Peripheral Devices

The DiAs regulatory approach requires that the smartphone, its customized version of Android and all supported peripheral devices be described in the DiAs Master File. DiAs currently supports the Google Nexus-5 (LG Electronics, Seoul, South Korea) and Verizon Moto-X (Motorola Inc., Schaumburg, IL, USA) Developer Edition smartphones, the Dexcom G4 CGM (Dexcom Inc., San Diego, CA, USA), the Roche Accu-Chek Spirit Combo (Roche Diagnostics, Basel, Switzerland) and Tandem t:AP insulin pumps (Tandem Diabetes Care, San Diego, CA, USA) and the Zephyr HxM BT and BioHarness activity monitors (Zephyr Technology, Annapolis, MD, USA). As shown in Figure 3 each peripheral communicates with a “device driver” application, which translates generic messages into the data stream required by a particular device and transmits it to the device using Android resources. For example the Dexcom G4 CGM and Tandem t:AP pump make use of the Android Bluetooth Low Energy (BLE) stack while the Roche Accu-Chek Spirit Combo and Zephyr activity monitors communicate using Classic Bluetooth. We are continuing to add support for additional CGM sensors, insulin pumps and wireless SMBG meters to DiAs.

2.5. Cloud Services

The smartphone transmits encrypted subject and system data to a secure server via WiFi or a cellular link for storage and use by manual and automated monitoring systems. In all outpatient trials to date a technical/medical team has been responsible for manually monitoring the state of the patients and the performance of the system via the DiAs Web Monitoring (DWM) system [38]. Figure 5 shows the DWM Overview screen, which contains a series of tiles representing the corresponding smartphone screens and summarizing the status of each study subject. Tapping a tile reveals the Subject screen, permitting study staff to examine the status of the subject and the system in greater detail. Although the DWM system has proven useful for real-time monitoring of trials lasting a few days, it is not a practical way to monitor an AP system for weeks or months at a time. As a risk mitigation measure for longer-term home trials we have developed the Automated Notification System (ANS), which is co-resident with the cloud database and DWM. The ANS uses a set of rules defined by the system administrator to generate automated SMS and email Alerts to medical and technical staff. The ANS uses staff schedules to make sure that the appropriate people are notified and verifies that dispatched Alerts are claimed and resolved, escalating the notifications to additional staff as necessary.

Figure 5. Web Monitoring Overview Screen.

Figure 5. Web Monitoring Overview Screen.

3. Results and Discussion

On October 24, 2011 the first pilot trials of outpatient Closed Loop Control running on a smartphone began simultaneously in Montpellier, France and Padova, Italy [39]. These first DiAs trials were successfully conducted with one subject at each site and lasted 42 hours. In the Spring of 2012, the first outpatient AP clinical trials ever conducted in the US were performed at the University of Virginia, Charlottesville, VA and at the Sansum Diabetes Research Institute in Santa Barbara, CA and additional trials were completed in Padova and Montpellier. These studies showed that it was indeed feasible to use a smartphone as a platform for a portable artificial pancreas system. The systems worked well throughout the trials although there were significant challenges with device connectivity and battery life. Many of these issues stem from the fact that the CGM and insulin pump devices used in these early trials were re-purposed versions of commercial products which were not designed to be remotely controlled and required inelegant, wired connectivity techniques. In particular we found that the micro-USB connectors found in most Android smartphones do not provide reliable electrical connectivity, particularly after repeated insertion cycles, and the USB software support in older versions of Android was not fully stable. Not surprisingly we have found that overall system reliability has improved dramatically now that the smartphone communicates wirelessly with all peripheral devices. In some situations shielding or absorption by the body can cause intermittent loss of device connectivity—for example if the subject is lying atop their sensor. The system is designed to handle CGM data gaps of up to 20 min duration and the insulin pump is configured to resume autonomous basal insulin dosing based on a pre-programmed daily schedule if connectivity with the smartphone is lost for more than 30 min.

After these first experiments the DiAs platform was used in a second multi-center artificial pancreas outpatient trial [40] that showed efficacy in reduction of hypoglycemia. In the summer of 2012 the DiAs platform and DiAs Web Monitoring were used in an overnight remote monitoring trial at two diabetes summer camps run by Stanford University [41]. In this trial the insulin delivery portion of the system was disabled and DiAs/DWM was used as a platform to record and remotely display CGM samples from study participants. This trial demonstrated that a DiAs-based remote monitoring system was able to achieve a significant reduction in the occurrence and duration of nocturnal hypoglycemia when compared with standard CGM. In the summer of 2013 DiAs and DWM were used for overnight glucose control at two diabetes summer camps run by Stanford University [42] and demonstrated statistically significant improvements of time in range and reduction in nocturnal hypoglycemia when compared with a control group.

In 2014, a series of DiAs home trials lasting from two weeks to several months will be conducted across the US and Europe to assess AP in real-life conditions. As the duration of the trials increases we expect to learn much more about the performance of the DiAs artificial pancreas platform, and perhaps more importantly, how patients will react to long-term use of closed loop glucose control systems.

4. Conclusions

In this paper we presented the Diabetes Assistant (DiAs) Artificial Pancreas research platform and described its software architecture in detail. The DiAs research platform has greatly accelerated the rate at which artificial pancreas trials are conducted by streamlining the engineering and regulatory processes involved in preparing for a clinical trial while greatly reducing the cost per subject of conducting human studies. Results of pilot and short-term outpatient use have shown that artificial pancreas systems based on DiAs are usable by patients and are effective in reducing the incidence of hypoglycemia, particularly overnight. Over the next three years the DiAs artificial pancreas will be tested in real life conditions during extended duration home trials. This will give researchers a chance to see out how well AP systems perform in the real world as well as how people with T1DM will react to daily use of an Artificial Pancreas system.