Bringing the Artificial Pancreas Home: Telemedicine Aspects

Abstract

The design and implementation of telemedicine systems able to support the artificial pancreas need careful choices to cope with technological requirements while preserving performance and decision support capabilities. This article addresses the issue of designing a general architecture for the telemedicine components of an artificial pancreas and illustrates a viable solution that is able to deal with different use cases and is amenable to support mobile-health implementations. The goal is to enforce interoperability among the components of the architecture and guarantee maximum flexibility for the ensuing implementations. Thus, the design stresses modularity and separation of concerns along with adoption of clearly defined protocols for interconnecting the necessary components. This accounts for the implementation of integrated telemedicine systems suitable as short-term monitoring devices for supporting validation of closed-loop algorithms as well as devices meant to provide a lifelong tighter control on the patient state once the artificial pancreas has become the preferred treatment for patients with diabetes.

Introduction

Since the late 1980s, there has been an increasing interest in the implementation of information and com-munication technology (ICT) systems supporting the management of diabetes mellitus. After the early work on the “Biostator” artificial pancreas¹ and the test of portable computerized systems for decision support,^2,3 the first telemedicine systems have been implemented and tested.^4–7 Such interest has been motivated by the inherent complexity of blood glucose control and caring for patients with diabetes. As a matter of fact, as reported elsewhere,^8–10 diabetes management can be seen as a hierarchical control system where day-by-day glucose control algorithms are implemented in accordance to a strategy that is revised on a visit-by-visit basis. It is thus not surprising that several telemedicine projects have been designed following this principle, coupling applications and devices running at home (patient units) with software tools devoted to periodic assessments of data transmitted from home to the hospital (medical units).^11,12 The distinction between medical and patient units has become less and less important as telemedicine and telecare have begun to be provided through a set of services made available to both patients and physicians via the Internet. Multiple devices, ranging from mobile phones to tablets, laptops, and personal computers (PCs), can easily access these services, so that implementation of decision support strategies will require concentrating on the proper organization of the different services rather than on their physical location.¹³

Quite interestingly, the availability of a wearable artificial pancreas (AP) is again changing the scenario of home monitoring and diabetes control, leading to an ICT organization that is somehow similar to the early days of diabetes telemedicine. The AP requires implementation of a device that integrates basic components, such as glucose sensors, insulin pumps, a microprocessor pro-grammed with a closed-loop control algorithm, and a data transmission module. The AP can be easily seen as a wearable patient unit, which finely controls blood glucose excursions on a day-by-day (or better, a minute-by-minute) basis. Supervision of the performance of the AP as well as its adaptation to the specific needs of patients require that collected data (e.g. insulin and blood glucose values) be transmitted to the caregivers who should assess the quality of diabetes control and provide feedback and interventions, if necessary. This requires the definition of a high-level decision-support software tool, i.e. a medical unit. With respect to design principle and technological solutions, however, implementation of such a scenario may largely vary. For example, the AP could connect directly to the Internet via a wireless link, or it might send information to an external device, such as a mobile phone, which could also provide suggestions and reminders to the patient while, at the same time, handle communication with a central server accessible to physicians and nurses. Furthermore, the interaction with the medical unit could potentially supervise the clinical activity and provide only feedback to physicians, or it may also be designed to allow changes to the settings of the AP, including its control algorithm.

Several projects and initiatives have been presented to leverage benefits afforded by embedding an AP into a telemedicine application.^14,15 In particular, many efforts have addressed the implementation of a set of control algorithms and monitoring strategies in a mobile personal assistant, which was then integrated into a telemedicine system. Such a distributed control approach may be of great help in effectively monitoring the performance of the AP in a timely fashion while at the same time enforcing communication with the health care providers.^15–17 A general architecture for supporting lifelong monitoring in diabetes patients has also been proposed by Capozzi and Lanzola,¹⁸ with prototypical implementations in the areas of diabetes and dialysis monitoring. Moreover, a variety of mobile telemedicine tools are presently undergoing tests, thus showing that there is a convergence of different technologies toward implementation of very advanced systems for ubiquitous diabetes management and care.^19–22 Grounding on these experiences, we will illustrate in this article the basic requirements of a general architecture that may be successfully used to implement a telemedicine system aimed at supporting a wearable AP.

Scenarios and Constraints for Telemedicine Systems Supporting the Artificial Pancreas

Information and communication technology solutions and telemedicine technologies can be exploited in a variety of contexts to support diabetes care and, in particular, to push translation of wearable APs into clinical practice. More specifically a twofold goal can be pursued. On one hand, it is possible to exploit ICT for implementing a generic telemedicine architecture providing an effective support for clinical trials in which a wearable AP can be tested in the home environment. This requires collecting and transmitting clinical measurements along with enough information describing the AP operational conditions during closed-loop sessions. All this information can be used to highlight the occurrence of hazardous situations promptly and to investigate the performance of AP controllers off-line for further optimizations and tuning. On the other hand, in a longer-term scenario, APs will be employed as a routine treatment and moved to embedded devices. This will require acquisition of monitoring data generated by wearable devices to enable a normal lifestyle for patients with diabetes. The ultimate goal will be better monitoring and control for patients with diabetes, keeping them in contact with their treating centers, reducing the risk of developing related complications, and cost/effectively increasing their quality of life.

In both scenarios, while designing and implementing the AP along with current telemedicine architectures, special effort should be made to adhere to solutions ensuring the safety of patients and enforcing data security.²³ To this aim, along with the general regulations of medical devices, there are also a variety of requirements that a “telemedical” AP must follow, including telemetry,²⁴ wireless connections, and electromagnetic protection.^25,26 Furthermore safety requirements must be an essential part of the design of the entire telemedicine system functionality, as reported in the International Electro-technical Commission 61508 standard and described as concerns about implications for software development in health care by Adriano and colleagues.²⁷ Finally, to complete the scenario, issues related to data security and privacy need to be taken into account carefully, following national and international regulations and best practices.^28–30

Following the goals and constraints mentioned above, it is possible to design a generic telemedicine architecture that, thanks to a modular design, may enforce a reliable transfer of data while preserving the performance level needed by the AP. Modularity can be achieved by abstracting the data exchange functionality between the different units located at the root of the telemedicine system.

General Telemedicine Architecture

The purpose of the telemedicine platform is to enable exchange of information between the wearable artificial pancreas units (APUs) and the clinical practice respon-sible for patient follow-up and to make patient data easily accessible by treating physicians. The flow of such information is bidirectional and, on the uplink, includes the patient’s monitoring data, his/her therapy, and the operational conditions of the APU, whereas on the downlink, it should support sending messages or configuration parameters required to dynamically tune the behavior of the APU itself. Figure 1 shows the general architecture illustrating the different tools involved, the several tiers needed and the communication links interconnecting them.

Figure 1.

Different components of a general telemedicine architecture to support the artificial pancreas.

At the topmost part of the figure, a remote agent (RA) is shown. The RA is composed of the whole assembly including the APU, continuous glucose sensor, insulin pump, and the telemedicine facility enabling communication with the clinic, based on a module called TMD Remote. More specifically, the APU hosts the controller, which is the only component that is connected to sensors (blood glucose sensors, manual input) and actuators (insulin pump). TMD Remote is the remote component of the telemedicine infrastructure hosted on the device providing network connectivity and located wherever the APU is located. TMD Hub is the gate managing the communication with the clinical practice.

Following a design principle called “separation of concerns”³¹ a desirable strategy is to keep the APU roles separate from those of the TMD Remote. In particular, interfacing with the patient should only happen through the APU component, which is the only element responsible for acquiring blood glucose measurements and subsequently adjusting the insulin therapy driving the pump according to the control law implemented inside the APU itself. If such a control law requires additional information (i.e. meals, physical exercise) from the user that cannot be directly acquired through any sensor attached to the patient body, the APU itself should provide a facility for manual input such as a keyboard-display pair or push keys. This requirement greatly simplifies the design and interaction among all components. According to this design principle, telemedicine infrastructure may be committed to provide logging facilities only, supporting the home validation of the AP therapeutic scheme but not being involved with therapy delivery. Thus, while the APU is responsible for exchanging data with the front-end (i.e. the patient), the TMD Remote component has the duty of accomplishing the same task on the back-end (i.e. through the TMD Hub) and exchanging data with the clinical practice. This implies that the crucial part of the RA is interfacing between the APU and TMD Remote which ensures that exchanged data are conveyed between the two different modules as illustrated in Figure 2. According to a best choice strategy, those data can be coded either as plain text files or as more structured repositories depending on the capabilities of the devices upon which TMD Remote is rooted.

Figure 2.

The remote agent and data exchange strategy.

More specifically, during initial development of an APU, it is quite customary to implement the device using PC hardware. Then it could be extremely useful to exploit a database, such as MS-Access for instance, as a data storage/representation formalism to speed up implementation. In fact, it relieves the developer from the burden of defining a custom format because records are easily manipulated through high-level SQL queries. However, porting the APU on an embedded device with limited capabilities requires a different approach. In that case, records can be best represented as structured lines that are sent by the APU through a Bluetooth link to a smartphone where they will be appended to plain text files and handed over to TMD Hub. In both cases, exchanged data represents only a staging area used for organizing and controlling data flow across the boundaries of separate systems with different capabilities, and it is not meant to provide a perpetual storage area for the APU. Should the APU ever need a short-term data repository with a small set of historical data to control the actuator better, it should separately manage these data inside its own implementation.

The TMD Remote is the RA component responsible for forwarding data to the clinical practice agent (CPA). It should accomplish this task by leveraging secure standard protocols such as https and interacting with a TMD Hub component hosted on the CPA. In essence, TMD Remote and TMD Hub are a pair of matching hubs accomplishing the task of synchronizing any data that is handed to components on either side (i.e. making data identical on both sides). TMD Hub is linked to the personal health record (PHR) service component to which it sends the information exchanged from the remote side. Thus, all patient data can be incrementally added and stored, building up their PHR. Furthermore, data available through the PHR enables implementation of decision support services devoted to analyzing sessions, detecting criticalities within patient data, or sending alarms to the treating staff. This is represented in Figure 1 by the single block named “Ancillary Services.”

Thanks to a Web application service, any data stored in the PHR or generated by the decision support tools are made accessible using a regular Web browser, thus allowing physicians and nurses to select and browse patient’s data across the past clinical history or track real-time conditions that are continuously updated during closed-loop sessions. Besides reporting data acquired on the RAs, the functionality of the Web application could also allow physicians to input messages that are delivered to the patient or to set parameters that are sent to the APU to change its logging level or even the controller’s behavior. In the latter case, an acknowledgment on the patient’s side would be advisable as a safety measure. Access to the Web application, and thus to the data, should enforce the security requirements of the hospital/care-giver institution.

It is interesting to note, however, that this architecture also allows implementation of more complex scenarios. More specifically, by combining a specialized service available within the CPA with a RA particularly designed for the staff, the same TMD Hub/TMD Remote pair functionality could be exploited for exchanging data and setting up customized monitoring services. For example, the data exchanged could report about criticalities concerning the patient so that a treating endocrinologist is promptly and asynchronously notified about the values of some physiological parameters, or about any remarkable event signaled by the patient APU.

Supporting Multiple Scenarios

The architecture illustrated in the previous section may be instantiated with minimal work to support different scenarios utilizing different devices. In a first scenario, in a design to support clinical trials for assessing the control algorithm, the APU can be hosted on a PC, and actually no other hardware will be involved except for a single PC directly linked to sensors and actuators. In this case, the TMD Remote is implemented on the same PC where the APU is located, and exchanged data can be stored as a database located on the same PC. However, the very same architecture can also be tailored to different “real telemedicine” scenarios. In fact, an alternative scenario can be characterized by having the APU located on a wearable embedded device paired with a mobile/smartphone for sending data to the clinic. The APU will still have the burden of interfacing with sensors and actuators. However, it will be located on a very small-size component typically worn by the patient. Its connection with sensors and actuators will be either wired or, more likely, take place through a wireless link such as Bluetooth or Infrared. Bluetooth is a low power technology that is perfectly acceptable for these devices as it only radiates 2.5 mW power during transmission and there are already insulin pumps on the market featuring it. A much higher power is required instead for long-range communication. Mobile phones, for example, radiate powers in the order of 500 to 3000 mW and there have been reports of dangerous interactions with medical appliances.³² Furthermore, the APU is also directly connected to the patient through the infusion needle and the glucose sensor which may act as antennas, and therefore it is not acceptable that the embedded device will also host the components required for establishing a network connection with the carrier. It is therefore likely that such a connection will exploit a standard mobile phone or PDA terminal for exchanging data with the CPA. Therefore, in this case, the TMD Remote component will be best implemented on the mobile device and the APU will exploit the same Bluetooth connection for forwarding measurements to and for retrieving incoming directives sent from the clinic.

It is clear that in an embedded health context, besides identifying the software architecture, it is also important to properly design the hardware layer and the coupling of the different components. In addition to interfacing with a glucose sensor and an insulin pump, a platform based on an embedded device may also provide a wide range of monitoring signals, such as electrocardiogram, heart rate, breathing rate, movements, and physical activities. Moreover, the platform might also perform a preliminary analysis on the acquired data and issue alerts automatically to the patient as well as to the CPA in order to highlight the onset of specific health conditions requiring a prompt intervention. Addressing a similar platform requires selecting, porting, and optimizing the whole software tool chain (i.e. operating system, wireless connectivity stacks, sensors interface and acquisition firmware), along with the hardware design. This is particularly relevant for the resulting system because it affects its shaping and requirements in terms of processing, power consumption, battery cell dimensions, and operational lifetime. Finally, a crucial design goal also concerns the form-factor of a complete wearable prototype solution, so that the patient may feel comfortable with it during everyday use.

Conclusions

Defining telemedicine solutions to support the AP requires applying advanced design principles that allow modular implementation starting from the very basic components that comprise the system. As much as possible, modularity should leverage proper data messaging and synchronization strategies that enable “separation of concerns” among the different components. Rather interestingly, this architecture may also represent the ICT backbone for complex decision support strategies, which include day-by-day support for patients and physicians, as well as long-term recommendations.³³ More specifically, the increasing computational and data analysis capabilities shown by mobile devices may be useful in providing short-term support during patients’ monitoring through prompt notifications regarding the onset of potentially hazardous situations. Retrospective analysis performed on the complete monitoring dataset at the server side may allow instead the overall optimization of treatment and clinical resources. It should be noted that the flexibility of this architecture raises the issue of properly planning the roles and functionalities of all software agents to be included, in particular, in terms of the coordination of the different decision support actions.^34–36 Recent efforts have been made to study agent-based systems from a control system viewpoint, thus holding the promise of properly designed complex, hierarchical, distributed decision support systems, grounded on solid theory to cope with safety-critical contexts, such as telemedicine.³⁷

As a final remark, modularity of the architecture may also enable incremental addition of new monitoring signals, which open up possibilities for the AP to be integrated into more complex clinical scenarios or even to be used in addressing completely unrelated telemedicine applications.

The general architecture reported in this article is the basis of work that is currently being performed within the project AP@Home, funded by the European Commission. A specific implementation of this architecture is presently being used to support the evaluation of AP control algorithms.

Glossary

Abbreviations

(AP)

artificial pancreas

(APUs)

articifical pancreas units

(CPA)

critical practice agent

(ICT)

information and communication technology

(PC)

personal computer

(PHR)

personal health record

(RA)

remote agent