DiAs Web Monitoring: A Real-Time Remote Monitoring System Designed for Artificial Pancreas Outpatient Trials

Abstract

Background

Developments in an artificial pancreas (AP) for patients with type 1 diabetes have allowed a move toward performing outpatient clinical trials. “Home-like” environment implies specific protocol and system adaptations among which the introduction of remote monitoring is meaningful. We present a novel tool allowing multiple patients to monitor AP use in home-like settings.

Methods

We investigated existing systems, performed interviews of experienced clinical teams, listed required features, and drew several mockups of the user interface. The resulting application was tested on the bench before it was used in three outpatient studies representing 3480 h of remote monitoring.

Results

Our tool, called DiAs Web Monitoring (DWM), is a web-based application that ensures reception, storage, and display of data sent by AP systems. Continuous glucose monitoring (CGM) and insulin delivery data are presented in a colored chart to facilitate reading and interpretation. Several subjects can be monitored simultaneously on the same screen, and alerts are triggered to help detect events such as hypoglycemia or CGM failures. In the third trial, DWM received approximately 460 data per subject per hour: 77% for log messages, 5% for CGM data. More than 97% of transmissions were achieved in less than 5 min.

Conclusions

Transition from a hospital setting to home-like conditions requires specific AP supervision to which remote monitoring systems can contribute valuably. DiAs Web Monitoring worked properly when tested in our outpatient studies. It could facilitate subject monitoring and even accelerate medical and technical assessment of the AP. It should now be adapted for long-term studies with an enhanced notification feature.

J Diabetes Sci Technol 2013;7(6):1427–1435

Introduction

Since 2003, significant progress has been made in the development of an artificial pancreas (AP) for patients with type 1 diabetes mellitus (T1DM). On one side, the primary source of information used to calculate insulin doses has become more accurate and reliable thanks to the improvement of subcutaneous continuous glucose monitoring (CGM).^1,2 On another, external pumps used to deliver insulin have progressed in terms of size, robustness, and precision.³ Between these two components, control algorithms have proven to be more efficient, in particular, during nighttime.^4–8 As a result, several AP systems have been developed by various teams around the world, trying to reach the old dream of a fully automatic system that controls glucose levels of T1DM patients.^9–12

A number of clinical trials were performed to evaluate these systems and document the feasibility and the efficacy of a subcutaneous–subcutaneous AP concept using commercially available devices.^5,9,13–15 Following these studies in a hospital setting, our group designed a transitional outpatient home-like trial that was performed in October 2011 using a portable handheld AP platform for the first time. This phone-based system developed by the University of Virginia and now known as the Diabetes Assistant (or DiAs) was used in Italy and France by two patients during 42 h in a hotel near a hospital, clearing one of the major remaining hurdles before home use.^16,17

Moving from a hospital to an outpatient setting involves several requirements: (1) the AP should be fully autonomous and portable for daily use, e.g., the size of the system becomes important and using a laptop as a platform is no longer possible; (2) the patient becomes the main user of the AP, hence the user interface (UI) should be simple, user-friendly, patient-oriented, and no longer designed strictly for study personnel; and (3) outpatient studies should be performed in the same safety conditions as inpatient trials, raising as a consequence the question of appropriate monitoring.

While the two first-listed requirements are covered by the design of the DiAs platform, a new system had to be created to ensure proper supervision of AP outpatient experiments.¹⁸ Such a tool should include medical information intended for clinicians who remain responsible for their patients, as well as technical details for engineers who need to ensure the proper functioning of the AP components. In 2010, the main monitoring applications available did not have any remote feature that would allow their use in outpatient studies.^19,20 Several systems have since been developed.^12,21,22 We therefore decided to build our own platform. The choice of a phone-based device to develop DiAs fulfills the size requirement for home use and also offers telecommunication capabilities, allowing the design of a remote monitoring system. 3G and Wi-Fi chips are indeed embedded in most smartphones, allowing communication with a remote server as described in Figure 1.

Figure 1.

Architecture of a remote monitoring system: one or several devices such as an AP send data in real time to a remote server using a 3G or Wi-Fi network. Data are then stored and displayed through an application accessible from a laptop, a tablet, or a smartphone connected to the Internet.

One of our key objectives in support of outpatient trials was to design a remote monitoring system that allows realtime monitoring of patient state and closed-loop control functioning. While our primary goal was to develop a first prototype that could be used during clinical studies, we also wanted to evaluate its performance, in particular, for data transmission. This tool, presented in this article, was tested during three outpatient clinical trials.

Methods

Development of the remote monitoring system was divided into several steps as described here. We followed an agile methodology called Scrum, which provides flexibility and rapid development, as well as the DRY (“don’t repeat yourself”) principle to optimize our work.

Features Definition

The design of the remote monitoring system was primarily based on analysis of existing systems, either in the diabetes field or related to other chronic diseases (Table 1). These systems have been used by our team in previous clinical studies and have similar concepts. APS¹⁹ and DIAdvisor²⁰ aim at real-time monitoring during inpatient studies. Diabeo,²³ Diasend,²⁴ and Cellnovo²⁵ are telemedicine applications that intend to facilitate communication between patients and physicians.

Table 1.

Nonexhaustive List of Existing Monitoring Systems in the Diabetes Field

Name	Developer		Purpose		Context		Device sending data		Communication	Synchronization	Data recorded
Diabeo (Telediab)	Voluntis for CERITD		Electronic daily logbook		Daily care		Windows personal digital assistant (pocket personal computer)		3G	On patient request	Self-monitoring of blood glucose, insulin dose, meal, activity
APS	University of California, Santa Barbara		AP		Clinical trials		Windows laptop (Matlab)		Wi-Fi or Ethernet cable	Real time	Text message or email with hypoglycemia information
Cellnovo handset	Cellnovo		Diabetes management		Daily care		Cellnovo handset		3G	Real time	Self-monitoring of blood glucose, insulin dose, meal, activity
Diasend	Diasend		Diabetes management		Daily care		Upload box		Wi-Fi or Ethernet cable	On patient request	Self-monitoring of blood glucose, insulin dose, meal, CGM
DIAdvisor	DIAdvisor consortium		Automatic advice validation		Clinical trials		Windows laptop (.net application)		Wi-Fi or Ethernet cable	Real time	CGM, basal and bolus insulin, self-monitoring of blood glucose, meal, exercise, heart rate

This analysis was followed by in-person interviews of clinicians, engineers, and nurses who are involved in AP studies. Interviews started with an open discussion to understand what information is used to monitor AP studies. Then a discussion based on mockups was initiated to decide what should be kept or changed.

Finally, a risk analysis was performed to assess the consequences of events that could occur during AP trials, with the goal to delineate their levels of importance. We listed risk scenarios related to diabetes and devices as well as their repercussion on patient health. The risk level of each scenario was assessed by the risk likelihood and its severity of impact. A list of mitigations was finally proposed.

These steps resulted in the definition of a list of features and a list of parameters that must be included in the remote monitoring system, all classified by priority (mandatory, important, optional).

User Interface Design

Once the main features had been listed, we designed the UI of the remote application. The objective was to build a UI that could be used by clinicians but also by engineers. While clinicians asked for quick access to medical data such as glucose levels, engineers wanted to visualize technical details. We drafted several mockups using an open-source software called Pencil (by Evolus) and complied with several best practices used for electronic case report forms and health care applications, in particular, the ones proposed by Microsoft Health Common UI (http://www.mscui.net). As an example, these recommendations were very useful to decide how dates should be displayed: depending on the country, 06–10–2013 could mean either June 10, 2013, or October 6, 2013; the format 10-Jun-2013 is therefore recommended to avoid ambiguity.

Software Platform

Since DiAs is Android-based, we chose Android and Java to develop the module that sends data to the remote server. The remote application was first built with Symfony2, a web framework developed in PHP language, but we then decided to move to Django, a python framework that proved to be more flexible, more robust, and easier to use. Data are stored in a centralized MySQL database, which is able to manage millions of data.

Bench Tests

Once the application was developed, we performed stress tests with Apache JMeter to simulate heavy loads. The goal was to test the robustness of the architecture of the system and make sure that it can support several users and several data transfers at the same time.

Clinical Tests

The remote monitoring system was finally tested during three clinical trials performed between October 2011 and June 2013. The first trial involved 20 adult T1DM patients from four clinical centers located in Virginia, California, Italy, and France. Its primary objective was to evaluate the feasibility of outpatient studies using the DiAs platform and the remote system. The study was conduced between October 2011 and May 2012. DiAs and the remote system were used for 42 h per subject.^16,17 The second clinical trial was led by Buckingham’s team from Stanford University in July and August 2012. It consisted of three adolescent camps of 5 to 6 days each and aimed at assessing the efficiency of overnight remote monitoring of CGM devices. It involved 60 children who used Dexcom G4 CGM. On alternating nights, they were randomized to remote monitoring or usual wear of CGM.²⁶ The third trial was conducted between November 2012 and June 2013 in the same four centers as the first study. The objective was to assess the efficiency of outpatient AP compared with sensor-augmented pump therapy. Remote monitoring provided real-time information to the clinical team. Eighteen patients participated in two admissions of 40 h in a hotel setting, one in open-loop and one in closed-loop.²⁷ In total, 68 patients participated in these trials, and the remote monitoring system was used during a cumulative period of 3480 h.

Results

We developed a novel remote monitoring system that consists of two components: (1) “Network Service” (NS), an Android application embedded in DiAs and responsible for data transmission, and (2) a web-based application entitled “DiAs Web Monitoring” (DWM), which ensures reception, storage, and display of data sent by NS (Figure 2).

Figure 2.

Communication process between DiAs NS and the DWM application. Network Service looks for new data coming from the AP platform and sends them to the remote server using a secured HTTP request. The data collection module of the remote server ensures the reception and storage of time-stamped values into a database. Finally, data are organized and displayed through a UI.

Features

Network Service was the first to be developed in parallel with the data collection module of DWM. In addition, the web application needed several other functionalities to be fully useable: secured user access, real-time data display, patient management, and file export assistant for data analysis purposes. Needs for monitoring several patients at a time as well as the possibility to enter notes were also expressed during our interviews. An alert module has finally been added in order to help detecting events such as hypoglycemia and CGM and pump failures. Other features were discussed but not implemented. In particular, options to configure the AP remotely or to collect global positioning system location could be considered as helpful but would introduce an important security flaw and be quite invasive with regard to patient privacy.

Data Transmission

Numerous parameters are transmitted: CGM data, insulin bolus delivered, meal entries, AP algorithm state, device details (such as battery level), and technical logs from DiAs. Each value is time stamped. Because patient state is the major concern of clinical teams, CGM values are the first ones to be sent to describe, in priority, the medical state of the patient using the AP. Transmissions are done automatically on decision of NS if a 3G/Wi-Fi network is set up and available. When new data are saved into the DiAs database, NS converts them to JSON format and sends them using HTTPS (hypertext transfer protocol secure). Data reception is performed by DWM, which ensures data integrity by checking expected values before their association with a corresponding subject and final storage in the remote database. Data are stored anonymously, and sensitive data are encrypted using random salts and hashing algorithms. For security reasons, the communication between NS and DWM is a one-way-only process, meaning that DiAs cannot be remotely controlled by DWM.

Communication Performance

During the camp trials, 10 systems were running in parallel, showing that the remote monitoring system was able to handle 10 simultaneous data transmissions. This confirmed the result of the overload tests, which showed that the DWM server was able to handle up to 100 simultaneous connections with 10 requests per second, which is equivalent to 17,647 DiAs systems’ simultaneous connections (Figure 3).

Figure 3.

Overload tests performed with Apache JMeter. Number of simultaneous requests increases step by step to reach a maximum of 100 active connections, with 10 requests per second (red line). Despite this increase, server response time remains stable (blue line).

During our third trial, 334,261 remote requests were performed, representing approximately 460 data transmissions per subject per hour. Log messages represent approximately 77% of these requests, while CGM data represent less than 5% (Table 2). When comparing the time of recording by DiAs and the time of reception by the remote server, we observed that 86% of data were collected in less than 1 min, and up to 97% in less than 5 min. Approximately 3% of data were received more than 5 min after their creation (Table 2). These delays did not have any significant impact on the trial supervision, as they mostly concerned log messages that do not have a high transmission priority.

Table 2.

Type of Data and Delays Observed during Data Transmission for the Third Clinical Trial, with 18 Subjects and 1440 Hours of Data Recording

Parameters	Mean (per subject)	Total	%
CGM	833.53	15,837	4.74%
Meal	9.84	187	0.06%
Total bolus	755.05	14,346	4.29%
Basal bolus	746.26	14,179	4.24%
Meal bolus	10.79	205	0.06%
Correction bolus	7.16	136	0.04%
Log	13,542.26	257,303	76.98%
State	894.53	16,996	5.08%
Device	793.32	15,073	4.51%
Total	17,592.74	334,261	100%
Delay	Data received	% Data received
<1 min	289,866	86.34% ± 8.88%
1–5 min	34,561	10.76% ± 5.96%
5–10 min	3760	1.13% ± 1.86%
10–30 min	4608	1.36% ± 1.86%
>30 min	1466	0.41% ± 0.30%

Data Display

One challenging task is to display the data in a form that allows their quick interpretation at-a-glance. An effort was therefore made to produce an efficient UI. We proposed two layouts: one for single-patient monitoring (Figure 4) and one for monitoring several patients simultaneously (Figure 5). In the individual interface, a chart representing the evolution of CGM values and insulin delivery is the main element of the page. The simultaneous overview displays for each patient a file that includes the last CGM value and trend, as well as the last alert triggered. Pages are refreshed every minute so that new incoming data can be displayed.

Figure 4.

Single patient monitoring screen. Continuous glucose measurements (blue dots) and insulin bolus (green bars) are represented in a chart. Current state of AP, current CGM value and trend, last alerts, and insulin amounts are displayed on the right-hand side. Traffic lights representing hyperglycemia and hypoglycemia risk are on the left-hand side. Other data are accessible from horizontal tabs menu.

Figure 5.

Simultaneous patients monitoring screen. Here, five patients are monitored at a time, and the system alerts that one of the patient is at risk for hypoglycemia (red box).

Designing a web application means that it should be accessible from computers, laptops, and also tablets and mobile phones, which have become increasingly widespread. This requirement was considered, and a mobile version of the UI was also introduced. It was particularly helpful during the camp studies when counselors used a tablet while walking from tent to tent.

Discussion

The AP research is now in a transition to home use. The difference in location—hospital versus home setting— mandates, as a matter of fact, major changes in the way AP systems are conceived and in the way clinical trials should be conducted.¹⁰ New technologies offer powerful tools that have been very instrumental in the development of AP devices. These technologies contributed to the building of the remote monitoring system presented in this article.

When we began working on outpatient closed-loop control trials, it was not evident whether a remote monitoring system would be helpful. However, after two years of use, our system proved to provide valuable assistance to clinical teams. Thanks to real-time charts and alerts, it helped prevent hypoglycemic and hyperglycemic episodes and also sensor failures and pump occlusions that patients were not able to detect immediately, especially during night periods. It also facilitated supervision of trials because several persons could connect and monitor patients at the same time, wherever they may be; a clinician on call has access in a few seconds to the same information as the team onsite and can therefore provide more relevant advice. Finally, having a remote monitoring system contributed to reducing patient apprehension to using an experimental device, as they knew that they were under supervision at all times.

The utility and the efficiency of our remote monitoring system were demonstrated during camp trials conducted in diabetes camps. The objective was to compare overnight glucose levels in children when using the CGM device only or the CGM device connected to our remote monitoring system. All systems had the same predefined alerts. Using remote monitoring resulted in a two-fold reduction of the risk of prolonged nocturnal hypoglycemia (blood glucose <50 mg/dl) as well as in a three-fold reduction of the duration of hypoglycemic events.²⁶ The CGM alarms were working properly, but we noticed that children and counselors present in campers’ cabins did not always respond quickly to them. The development by Medtronic of a commercial product called mySentry™ that allows display of CGM traces in a remote location (e.g., the room of a parent of a child with diabetes) is another step toward having remote systems for better management of glucose control.²¹

Although it may seem trivial, the concept of monitoring several patients on the same screen had never been tried before in the AP field. While most inpatient trials involved a maximum of one or two patients at a time, we were able to perform up to 10 simultaneous experiments in the same clinical center. This ability of monitoring several patients at a time can speed up the execution of clinical trials while reducing their duration and cost.

We have to admit that real time does not always mean instant data transfer. In reality, data transmission can suffer from time delays. It indeed depends on the availability and quality of the wireless network, as well as on the response of the remote server. While the remote server can be enabled with powerful hardware and software optimization, the availability of the wireless network cannot be ensured in most cases. In our trials, we observed data transmission delays, in particular, when patients were eating inside restaurants where mobile broadband access was sometimes unavailable. This will be the case in real-life conditions when patients may go to the countryside or drive in a tunnel. Such delays in data transmission could be considered a limitation to the benefit of remote monitoring. Nevertheless, in our experience, short lags can be acceptable without compromising the study monitoring. Indeed, blood glucose rarely drops from normal range to hypoglycemic range in less than 5 min, and its short-term evolution can be predicted with more recent data displayed on a chart.

As always in software development, the importance of the UI was crucial for user acceptability and utility of the overall system. Colors, text size, layout, navigation, and interaction do have a real importance, and important efforts were made to provide a clear and easy-to-use interface. Patient identification should be very clear, and information such as last CGM value and trends should be easily and quickly accessible. Real-time monitoring also implies time representation. The format “x time ago” was chosen and proved to be a good format to inform the user about the time of data reception in order to detect possible lags. Finally, practical issues had to be solved, as we had to face patients and clinical teams from various countries, meaning that several languages and time zones had to be taken into account.

Our remote monitoring system was designed for onsite real-time monitoring, with staffs looking at a screen for several hours. This was very useful for short-term studies but cannot be applicable to long-term AP trials including hundreds of patients. No one could imagine clinical teams looking at monitoring screens for months or years; it would be neither feasible nor efficient. However, the real-time human monitoring could be replaced by other automated options, one of which is an advanced algorithm that would analyze data in real time and send notifications by, for instance, short message service to clinical staff when necessary. Such a feature would still provide useful information and help prevent adverse events without increasing study costs.

Although debatable for long-term use, we believe that remote monitoring must be part of early AP development, in particular, during first feasibility outpatient trials where evolving technologies are used. Remote monitoring does not require expensive technologies and provides valuable assistance. When AP systems prove robust enough for unsupervised use, then the cost and the medical benefits of such telemonitoring systems will have to be reevaluated.

Conclusions

Remote monitoring systems can be powerful tools assisting in the transition of the AP to outpatient use. Our application proved to work properly during three clinical studies and answered its initial goal of displaying medical and technical information to clinical teams and alerting them when necessary. Further improvements should be made for long-term AP trials to replace real-time screen monitoring by alert and notification algorithms.

Glossary

(AP)

artificial pancreas

(CGM)

continuous glucose monitoring

(DWM)

DiAs Web Monitoring

(NS)

Network Service

(T1DM)

type 1 diabetes mellitus

(UI)

user interface

Funding:

This work was supported by JDRF.