Monitoring Artificial Pancreas Trials Through Agent-based Technologies

Abstract

The increase in the availability and reliability of network connections lets envision systems supporting a continuous remote monitoring of clinical parameters useful either for overseeing chronic diseases or for following clinical trials involving outpatients. We report here the results achieved by a telemedicine infrastructure that has been linked to an artificial pancreas platform and used during a trial of the AP@home project, funded by the European Union. The telemedicine infrastructure is based on a multiagent paradigm and is able to deliver to the clinic any information concerning the patient status and the operation of the artificial pancreas. A web application has also been developed, so that the clinic staff and the researchers involved in the design of the blood glucose control algorithms are able to follow the ongoing experiments. Albeit the duration of the experiments in the trial discussed in the article was limited to only 2 days, the system proved to be successful for monitoring patients, in particular overnight when the patients are sleeping. Based on that outcome we can conclude that the infrastructure is suitable for the purpose of accomplishing an intelligent monitoring of an artificial pancreas either during longer trials or whenever that system will be used as a routine treatment.

Home care delivery is considered a key issue to enforce a better control on chronic diseases,¹ delay the onset of their complications, and save any related cost.² Unfortunately, until the past decade only few parameters could be collected in real time outside clinical settings mainly because of technical and connection-related limitations. However, the recent progresses in the information and communication technologies (ICT), together with the appearance of new biosensor families made available through advances in miniaturization and nanotechnologies,³ are deeply reshaping the way in which real-time surveillance of physiological parameters is accomplished. That trend anticipates new scenarios for the development of monitoring devices that are no longer constrained at the bedside, and whose focus will be on data integration, yielding an improved and more timely detection of abnormal situations representing deviations off the normal course of a disease.⁴

Networking and mobile technologies represent the most promising solutions for bridging the gap between outpatients and the clinic since they guarantee an adequate level of mobility and freedom.⁵ We believe that they are now ready to support novel home care treatments emphasizing optimization and individualization or provide the required connection with health care centers during trials, such as the one described in this article involving an artificial pancreas (AP).

The AP is a closed-loop system that aims to regulate glucose level in diabetes patients.⁶ It has 3 main components: a real-time continuous glucose monitoring (CGM) device acquiring blood glucose levels readings, a control algorithm that calculates the appropriate insulin dosage given those readings, and a continuous subcutaneous insulin infusion (CSII) pump delivering the computed insulin doses. Even if the AP development started about 50 years ago when the possibility of controlling blood glucose in Type 1 diabetes using intravenous glucose measurement along with the infusion of insulin and glucose was proven,⁷ the first closed-loop project that provided evidence for the feasibility of a subcutaneous route for the fully automated glucose control was published only in 2006.⁸

Following those achievements, the European Union funded the AP@home project⁹ within the 7th Framework Programme to foster the investigation on the AP and reduce the time for its adoption as a routine treatment. The path leading to a domestic application goes through 3 trials during which the subject will become progressively autonomous. The first AP@home trial accomplished in 2011 was meant to be a test bed for the whole AP architecture and proved that 2 closed-loop algorithms developed by different partners of the project are viable to be used on real patients.¹⁰ The second trial, which is the one addressed by this article, was the first outpatient trial since it took place in semicontrolled environment where the patient and the AP were remotely monitored by the clinical and technical staff. The final trial will take place in a domestic environment and will cover several weeks.

This case-report article focuses on the agent-based telemedicine infrastructure that has been successfully tested during 20 outpatient experiments to report clinical parameters and operational information concerning the AP so that both clinicians and biomedical engineers involved in the project were able to oversee the trial. The article is not concerned with the clinical results emerged through the experiments. Nonetheless, the success of the remote monitoring infrastructure represents a prerequisite for the accomplishment of the final trial of the AP@home project during which it will be the only means for the clinical staff to ascertain the proper operation of the AP throughout the whole time extent of the trial. The impact of remote monitoring when the AP will be used as a routine therapy is still under discussion and investigation. While during the present phase real-time web tracking represents the key issue for the research, in the future the capability of performing analyses on the acquired data will increasingly become the most prominent feature of the telemedicine infrastructure.

Methods

The study was designed to test a closed-loop system in a semicontrolled environment (ie, at a hotel location) and especially to evaluate if the telemedicine infrastructure can accurately report data coming from a patient’s AP for more than 80% of its operational time. Thus 12 subjects diagnosed with type 1 diabetes mellitus were enrolled by 3 clinical partners of the project. The purpose of the trial was to prove that

• The closed-loop system can be remotely supervised by nurses, physicians, and technicians to confirm its proper operation outside of the hospital setting

• The closed-loop system can be deployed, with an appropriate subject involvement, outside of the hospital setting

The duration of the study for each patient was set to 9 weeks (with 3 visits), with a screening run-in period of up to 8 weeks. The first 2 visits were devoted to pump training and sensor initialization, respectively. The third visit represented the main part of the study and it consisted of a 3-day period during which patients were provided with the closed-loop system for testing it in a hotel nearby the hospital. This last visit was arranged into 3 parts:

1. Remote monitoring, from 18:00 (day 1) to 07:00 (day 2), dedicated to the set up and validation of the monitoring system running in open loop (ie, 13 hours)

2. Closed-loop activation, from 07:00 (day 2) to 18:00 (day 2), while the patient was trained to the AP platform (ie, 11 hours)

3. Remote monitoring + closed loop, from 18:00 (day 2) to 12:00 (day 3), when the patient was alone and continuously monitored by study team (ie, 18 hours)

In summary, as stated by the protocol, the overall operational time for the AP during each patient experiment was set to be 42 hours. Throughout that time the remote monitoring infrastructure was requested to provide a full track of all data acquired on the patient or generated by the AP device itself.

During those 3 days meals were served in a nearby restaurant to the patient who performed several calibrations and self-monitored blood glucose according to the time schedule reported in Figure 1. The clinical team could ask additional measurements if needed.

Figure 1.

A diagram of the protocol reporting the hotel timeline with specific event scheduling.

In the following sections we describe the design and implementation of the remote monitoring infrastructure following the work described in Lanzola et al.¹¹

The Telemedicine Infrastructure

To support the accomplishment of the clinical trial we devised a generic telemedicine infrastructure for making patients’ data available in real-time to both the clinicians and the bioengineering staff. It must be said that such an infrastructure is not meant to guarantee the safety of the patients enrolled in the study, albeit it provides notifications about malfunctioning and missing values. For that purpose the AP already triggers several local alarms targeted at the patient who, as part of his training with the device, is taught how to service them.

Figure 2 illustrates the component architecture of the infrastructure which, at the leftmost side, sees the patient connected to the CSII pump and CGM sensor that are positioned on his skin and kept in place by sticking plasters. Both pump and sensor are connected to the controller device (CD) hosting the control algorithm, giving rise to the so-called AP unit. Those links can be implemented either as serial wired connections or as wireless ones exploiting Bluetooth¹² or some other radio technology. In alternate configurations provided by biomedical device manufacturers, the CGM sensor is directly managed by the CSII pump and there is a single link connecting the pump with the CD also carrying glucose data over it.

Figure 2.

The overall component architecture of the telemedicine infrastructure.

A major effort during the design of the infrastructure has been devoted to the implementation of an architecture emulating an agent-based framework,¹³ which allows the complete decoupling of the AP unit from the telemedicine implementation along with a high modularization of the latter inspired by the separation of concerns ¹⁴ to ensure its portability across a wide range of platforms.

In a nutshell, the equipment located at the patient’s home includes both the AP unit and the telemedicine (TMD)-Remote Agent acting as a gate for dispatching information to and from the clinic. The AP unit encompasses the CGM sensor and CSII pump, possibly resorting to manual input for acquiring information such as meals or physical exercise, while the TMD-Remote Agent has the duty of forwarding those data to the Clinical Practice Agent (CPA).

Besides being requested on a functional basis, the separation between CD and TMD-Remote Agent mainly depends on safety and pragmatic reasons. As shown in Figure 2, the preferred platform supporting a TMD-Remote Agent implementation is the mobile device, since it privileges patient comfort and mobility ensuring data transmission virtually anywhere and anytime. Thus the TMD-Remote Agent acts as a radio waves source which is incompatible with the status of a sensitive medical device such as the CD. Furthermore, even the power requirements of the TMD-Remote Agent would be very different from those of a continuously operating wearable device such as the CD, which is also a good reason to keep them separate.

At the network level the TMD-Remote Agent accomplishes data transmission exploiting secure standard protocols (ie, https) and interacting with a TMD-Hub hosted on the CPA. It exploits SyncML, which is a high-level bidirectional synchronization protocol¹⁵ providing reliability and traffic optimization. Data received by the CPA are stored into the patient personal health record where automatic processing is accomplished for detecting hazardous situations and automatically issuing alerts. As the right side of Figure 2 suggests, those are notified using push technology in terms of emails and SMS messages. A web application has also been designed to allow physicians, nurses and biomedical engineers to select and browse data across a patient’s past clinical history or to track his or her real-time conditions, which are continuously updated throughout closed-loop sessions whenever an intensive monitoring is required. The CPA also supports the complete download of all the patient’s data for accomplishing offline analyses by the researchers working on algorithm performance and tuning or just for plain reporting.

The Patient Platform

The patient platform uses the Dexcom Seven Plus as the CGM sensor and the Roche Spirit Combo as the CSII pump, which are both commercial devices supporting wireless data exchange. The implementation of the CD and TMD-Remote Agent hinges on an application called Diabetes Assistant (DiAs) running on an Android smartphone (Samsung Galaxy Nexus),¹⁶ on which, for safety reasons, all phone features are disabled. The DiAs takes care of interacting with the CGM sensor and the CSII pump encapsulating their protocols and provides the patient graphical user interface (GUI) allowing him to set the control mode either in open- or in closed-loop, to enter a meal announcement or calibrate the CGM sensor. That GUI also displays charts about the past glucose measures and the insulin delivered which are remotely mirrored to the clinic staff by the telemedicine infrastructure. Finally, the DiAs provides visual indications and acoustic alarms which are triggered in hazardous situations such as hypo- or hyperglycemia events requiring an immediate action by the patient. It also implements additional safety rules causing, for example, the automatic switch to open-loop control mode whenever no CGM data are received from the sensor for at least 15 minutes.

Thanks to the modularity provided by Android, the DiAs allows the integration of external modules, such as the ones implementing the CD and TMD-Remote Agent, which were implemented by the authors, sharing data through a common database. The CD realizes a control-to-range strategy comprising 2 algorithmic components: a Safety Supervision Module described in Hughes et al¹⁷ and an automated Range Correction Module described in Toffanin et al.¹⁸

To better enforce the separation of concerns, the TMD-Remote Agent functionality was complemented by an additional module, called TMD-Bridge, which is in charge to fetch data from the DiAs database. When the user starts the DiAs, the TMD-bridge begins to periodically (ie, every 180 sec) and autonomously query the shared database for new events or measures. If it founds any, it takes care of translating them according to the TMD-Remote Agent format, therefore minimizing the impact of any change on the database with respect to the overall telemedicine architecture.

The Clinic Platform

For a safe accomplishment of the trial a web application was implemented, so that members of the staff could remotely display in real time the data produced by the AP. This was a sensible topic since that trial was the first one of its kind testing the new AP technology, and also involved overnight control sessions in closed loop.

The web application is displayed in different languages according to the user location and is accessed by users with different roles and privileges, so that administrators, physicians, and patients all have separate sections. The Administrative Section was conceived to accomplish the usual management chores and will not be described being of little interest in this context. The Clinical Section is used by the physicians to monitor patients either in single or in multiple mode, so that they may compare several experiments at once during an online trial or explore in detail the whole history of experiments for a single patient. In fact, during the trial each center performed simultaneous experiments involving up to 5 patients, calling for the implementation of a summary page, shown in Figure 3, which was very handy in spotting the major problems experienced by patients, particularly when they occurred overnight.

Figure 3.

The summary page providing information about patients during an ongoing trial.

That page encompasses several panels, each one referring to a patient and showing minimal information about him, such as the actual Control Mode, the last CGM value received along with its Trend, the Hyper/Hypo Risk values represented in terms of a pair of traffic lights and several additional warnings which are triggered upon their occurrence. Whenever an alarm is triggered, the panel box of the corresponding patient turns red displaying a message, as shown in the rightmost one, and depending on the alarm severity a beeping sound may be played as well. The user may acknowledge the alarm pushing a button, clearing the red box and stopping the sound. For critical events both the red box and the beeping sound are automatically resumed after a while if the cause triggering it has not been resolved.

Clicking on a panel on the summary page opens the main dashboard for that patient providing a much deeper insight on him, as shown in Figure 4. On the top part of it the Patient Parameters (ie, ID, name, surname, date of birth, gender, treating center, weight, height, body mass index, and notes) are shown along with a Control Panel enabling the user to change the glycemia measure unit or select the time period to inspect. The main part of the page may display 4 different subpages according to which tab is selected. The first 2 tabs, namely Initial Parameters and Time-Range Parameters, include the parameters pertaining to the traditional open-loop therapy, such as the basal insulin rate foreseen by the therapeutic plan, or the carbohydrates ratio and the correction factor to be used in calculating the extra boluses at every meal. The Measures tab shows a list including all the measurements acquired from the patient and any signal generated by the AP. That list is sorted according to a time basis and can be filtered or exported in standard formats for offline analyses. Finally the Graphs tab, which is the one currently selected in Figure 4, charts the time series of the main measurements and events traced by the system. Those include glycemia, basal rate, insulin delivered, extra boluses of insulin, intravenous glucose, blood glucose measures for sensor calibration, and many more. The same chart also shows patient’s meals and physical exercises and allows to input additional values through the web, such as extra blood glucose level measurements, notes, and so on.

Figure 4.

The main dashboard used for monitoring in real time the artificial pancreas trials.

The dashboard, besides tracking in real time an ongoing experiment and automatically updating upon the arrival of new measurements, may also be used to review an already saved one underwent by a patient which is selected from an index page. For policy and privacy reasons, physicians can access information only about patients belonging to their own center, while the patient may access only his or her personal past history.

Results

The patient platform was deployed on the smartphones shipped to the 3 clinical centers, which received approval by their ethical committees for a fully automated closed loop control. Before accomplishing the official experiments involving 12 subjects, 2 centers also performed a set of pilot experiments involving 4 subjects each, which were useful for tuning the AP software and hardware platform. This resulted in 5 sets totalizing 20 experiments, as shown in Table 1 reporting the technical outcomes of the remote monitoring. Each patient was involved on average for a little more than 40 hours (see average time/pat), while according to the study protocol the duration of each experiment was set to 42 hours. As we said in the methods section, the aim of this research was to prove that the telemedicine infrastructure is able to report data for more than 80% of the AP operational time. Thus, in the light of the data provided in Table 1, the system is able to comply with this requirement.

Table 1.

Summary of Data Transmission During the Experiments.

Clinic center	Average time/pat (hr)	Overall no of data	Data rate per pat (data/hr)	CGM data	CSII pump data	Hypo/hyper data	Log data	Calibr data	BGM data	Control mode switches
PAD pilot	43.23	8542	49.40	1896	1875	4184	0	20	22	34
MPL pilot	40.52	9939	61.32	1902	1845	1910	721	19	40	89
MPL exper	41.51	9102	54.82	1962	1955	2780	58	17	100	11
PAD exper	43.99	9646	54.82	2039	2054	2732	203	32	200	12
AMS exper	43.71	9521	54.46	2007	1938	2764	277	33	102	14

The overall number of data sent during each experiment set was nearly 9000 with an average data rate for each patient between 49.40 and 61.32 data/hr. This means 5-6 data points every 5 minutes, which is consistent with the observation that the AP unit is clocked at 5 minutes and at every cycle it sends out a CGM value, a CSII pump directive, information about the hyper and hypo-glycemia risks calculated by the algorithm¹⁹ when running in closed loop, battery status information, and logs. Those are configurable pieces of information generated inside the AP which describe its internal state. Their availability is very important for offline debugging purposes, such as those involving the “replay” of the controller actions for better tuning its behavior. Details about the actual data sent are indicated in the subsequent columns in Table 1. Among those are reported the number of calibration data and that of manual blood glucose measurements (BGMs) data. Each patient usually performs 5-8 calibrations during each experiment, which justifies the values reported in that column. BGM instead are extra blood glucose measurements which are recorded into the system but have no special meaning for it. Each center was allowed to enforce the safety of their patients by accomplishing BGM measurements, with no constraint on their number. Thus PAD during the experiment decided to duplicate BGMs by analyzing blood samples using both fingerstick and hemocube (which is not available to the patient at home) as a double check, resulting in a BGM data number twice as much.

This particular trial was accomplished at a hotel and it was agreed to use GPRS/UMTS to connect the smartphone hosting the CD to the Internet, avoiding any Wi-Fi connection despite its availability. This was to emulate as much as possible the situation occurring in real life when a patient is not constrained to stay at a specific setting, which was also reinforced by the fact that patients went to a restaurant for their meals. Thus during the experiments it has been quite customary to have time periods in which poor connectivity or no connectivity at all was experienced. Such inability to send data over the network was just a temporary glitch since no data loss has been experienced in all cases. The TMD-Remote Agent properly implemented all the caching mechanisms required to locally save any data before they could be successfully sent to the CPA. Given that the causes of those blackouts were not related to the TMD/AP design nor to their implementation and all data were eventually transmitted, they turned out to be completely transparent for the data collection process. Thus, since the aim of the remote monitoring system was not that of enforcing the patient’s safety, there was no point in further analyzing their causes or occurrences.

Discussion

The implementation of the proposed telemedicine architecture for remotely monitoring patients was definitely successful both from the data transmission and the visualization viewpoints, as it emerges from the data reported in the previous paragraph. The DiAs platform encompassed a TMD-Remote Agent deployed on top of it, sending data roughly every 3 minutes through a GPRS/UMTS connection to the CPA located at the Laboratory of Biomedical Informatics of the University of Pavia where 3 of the authors belong (GL, SS, RB).

The experiments of the trial described in the article were accomplished at hotels where both patients, clinical and engineering staff were lodged in separate rooms. This was planned as a safety measure to promptly provide patients with the assistance they might require in case of a malfunction of the AP platform or upon the occurrence of any health threatening situation. Nevertheless, despite the staff was very close, the patient stayed alone in his room for most of the time and the telemedicine infrastructure was often the only means available to the staff to oversee the ongoing experiment, in particular overnight when the patient was sleeping.

Remote monitoring enabled the researchers to detect many wrong situations and undertake the corresponding recovery actions, thanks to the alarms triggered each time. In particular during the first 2 pilots there was a problem with the Bluetooth protocol connecting the DiAs with the insulin pump, which caused frequent overnight disconnections. As a result of being unable to drive the pump the DiAs signaled the event and switched its mode from Closed Loop to Open Loop. That event triggered a pump alarm on the remote monitoring screen, which was noticed by the staff and also recorded the control mode switch. This explains the higher number reported in the Control Mode Switches column of Table 1 during the 2 pilots. After those pilots the DiAs was updated and the problem was fixed, turning the number of mode switches closer to 8 that represents the target for the protocol. In fact the protocol called for 2 switches for each of the 4 patients (ie, 12 hours of Open Loop followed by 28 hours of Closed Loop) for a total of 8.

During the trial we also experienced many temporary blackouts affecting the Internet connection, which were not caused by faults occurring either on the TMD-Remote Agent nor on the CPA. Sometimes those were due to the patient moving in an area of poor network coverage, but in others they were ascribed to some malfunctioning on the networking routing infrastructure. While the real-time monitoring service obviously stopped during those events, no data was ever lost thanks to the buffering capabilities embedded into the TMD-Remote Agent, and by the end of each experiment a full track of all its progression was always recorded on the CPA and made available to the researchers for inspection and further analysis.

Summarizing, from a technical point of view this trial has been most valuable in assessing and validating many choices concerning the implementation of the remote monitoring infrastructure and in demonstrating the technical feasibility of a similar solution. The test has also proven its compatibility with mobile networks capabilities, preparing for further trials to be accomplished later on at the patients’ homes. Based on the experience gained the implementation is presently being improved to match the requirements of a notification system relying on a more asynchronous approach exploiting emails and SMS reports. In particular, as we move to longer experiments an increasing amount of raw data will be generated which cannot be managed by the clinical staff directly. To overcome this limitation we are implementing a set of modules for extracting significant features from those data, such as the number of hyper- or hypo-glycemia events or the number of control mode switches, to provide more synthetic reports. A similar approach can also be useful once the AP is adopted as a routine treatment to better tune the therapy and monitor its outcome on the long term.

Finally, it is worthwhile noticing that the proposed architecture is one of the alternative solutions that are nowadays available for monitoring AP clinical trials. Very recently, Place et al have presented the DiAs Web Monitoring system,²⁰ which was successfully used in the JDRF trials of the DiAs platform. Even if the design of the interface is rather similar to our system, the technological platform used has several differences, in particular since we used an agent-based design to allow an easy software components interchange. Finally, Hernando and colleagues are proposing advanced solutions for AP monitoring based on the integration of telemedicine and artificial intelligence methods.^21-23

Conclusions

The article illustrated the implementation of a general architecture for a telemedicine system able to support outpatient trials that are a key issue to improve the development of an AP. The implementation was successfully tested during a trial scheduled within the AP@home project funded by the European Union that involved 20 experiments lasting for 40 hours each. The success of the telemedicine architecture and the lessons learned about the overall use of the technological solutions are driving the next ICT steps of the AP@home project, which will entail a longer-term trial.