0642
Implementation of an Artificial Pancreas System on a Mobile Device Caterina Lazaro, Erdal Oruklu, Mert Sevil, Kamuran Turksoy and Ali Cinar Illinois Institute of Technology Chicago, IL 60616
[email protected] Abstract—In this work, an artificial pancreas (AP) system, implemented on a mobile device is described. The proposed AP platform integrates hardware (insulin pump, glucose monitor, various sensors for vital signs and physical activities) and software (closed-loop control algorithm, sensor fusion, data storage and remote server access) components via smartphone that is running a dedicated Operating System designed for AP systems. Interfacing with this OS and custom application development steps are presented. Closed loop operation is demonstrated with case studies. Keywords—closed Loop; artificial pancreas; Type 1 Diabetes, Bluetooth LE;
Our previous work [7,8] presented the initial framework for the multi-sensor AP platform, with especial emphasis on the server communication. In this work, we focus on the embedded system; mobile device and the host applications. Section II introduces the Operating System (OS) installed on the smartphone, its Graphical User Interface (GUI) and its default functions and capabilities. Section III describes the implementation of the closed loop algorithm and sensor fusion operations. Section IV presents the necessary steps for integrating additional sensor devices to the proposed AP system. Section V concludes the paper.
I. INTRODUCTION Research on artificial pancreas (AP) systems promises significant improvement for Type 1 diabetes patients’ daily lives and it is expected to impact millions of patients [1-4]. A major component of the AP system is a closed-loop control algorithm [5,6], which aims to keep the glucose levels within acceptable margins by infusing insulin or suggesting carbohydrate intakes. However, glucose concentration (GC) variations are not easy to predict based only on its current value, since its reaction to the past stimulus can be rather slow. Additionally, GC is influenced by the type and level of exercise the person is engaged in. Therefore, GC predictions require not only a continuous monitoring of GC, but also additional vital signs such as heart rate, breathing rate, galvanic skin response (GSR), energy expenditure (EE), sleep state and vigorous activity to provide accurate real time predictions. The ultimate goal of this research is to develop an artificial pancreas: a portable, autonomous system that a person with diabetes can carry during their everyday life. The proposed platform includes traditional components highly used by diabetes patients: a glucose sensor (for continuous GC monitoring) and an insulin pump (to infuse basal insulin and insulin boluses on demand). Since the algorithm relies on key vital signs (such as heart rate or breathing rate) as well as activity parameters (acceleration vectors or galvanic skin response), fitness sensors are also included. Furthermore, the proposed AP system is designed to provide a remote monitoring of the person, by medical professionals or family members (to access their real time data). Hence, a dedicated server-AP system interface is also necessary. Fig.1 shows the hardware and software components for the AP platform.
Fig. 1. Artificial pancreas platform
II. AP PLATFORM A. Mobile device: Diabetes Advisory System (DiAs) A dedicated Operating System (OS), DiAs is used as the host for the AP system. DiAs [9] is a Diabetes helper platform, developed for Nexus 5 by the University of Virginia (UVA)’s Center for Diabetes Technology. The mobile device on our platform is based on DiAs. User interaction is enabled by the same GUI, allowing different operating modes. The AP system is comprised of multiple devices, such as a Dexcom glucose sensor [10], a Tandem insulin pump [11] and a Zephyr Bioharness 3 chest band [12]. Another critical feature is the remote monitoring server web platform, which could be accessed by medical professionals or engineers. The next sections explain these characteristics in more detail.
978-1-4673-9985-2/16/$31.00 ©2016 IEEE
0643
1) Graphical User Interface When DiAs is started, the first step is to enter the user’s information. This information contains personal details (height, weight, date of birth etc.) and insulin intake parameters (maximum insulin per day, basal profile etc.). An identification number for each patient is created in this step. For anonymous access to personal data, only ID numbers are used.
Fig. 3. DiAs web portal [9]
Fig.3, illustrates that the portal reflects the real state of DiAs screen (such as the traffic lights or the last CGM value). Moreover, it contains graphs with the past values, logs of error/actions and additional calculations. Fig. 2. DiAS Closed Loop mode main screen [9]
Next, the devices and sensors which are to be connected with DiAs are setup. The system uses a Device Manager Menu. As more features of DiAS are enabled, new buttons will be appearing on the screen: for example, when the pump is connected, a “Start Pump Only” button appears. The “Start Closed Loop” is seen when there is both a pump and a CGM sensor. Additional information is always displayed on the screen. In Fig.2, taskbar at the top shows: current mode (CLOSED - for closed loop), Value of glucose level (78mg/dl), State of the CGM sensor (CGM is green, to show it is correctly connected) and state of the insulin pump (PUMP in green, to show pump is properly connected). Furthermore, DiAs has a system of Low and High GC alerts, based on two traffic lights (on the left and right of the screen correspondingly). DiAs operates in three main modes: Sensor Only Mode (just reading the values from the devices), Pump Only Mode (where the user can manually infuse insulin via the pump) and Closed Loop Mode (where a closed loop algorithm will be running, to automatically infuse the right amount of insulin depending on the values read from the sensors). 2) Devices Connected: Device Manager Menu DiAs has a driver dedicated to each of the compatible devices. In the end, a driver is just an independent application which is able to: pair DiAs and the desired device, establish and keep a connection, and display some visual confirmation of the state of the connection. All drivers are constantly receiving data from their sensor and writing it into a local database. This database can be accessed/read anywhere in the code. This feature is used in the Closed Loop implementation. If connection is lost, the system uses popup windows as warnings. The user should then verify the driver. 3) Webportal - server access DiAs can also be accessed for remote monitoring. A web portal is provided by University of Virginia as shown in Fig. 3. DiAs sends data to the selected server/url. Then, a person properly authenticated (username and password) can access the server, and monitor the patient’s activity.
B. Developing new functions and applications This section describes the key steps of DiAs development. The platform incorporates some default algorithms and services, but it also offers an open platform for developers to code new functions. 1) Installing the Operating system First step is installing the OS onto the Nexus device. DiAs disables calls, text messages functions of the phone and installs the components to run the Advisory System. In order to configure DiAs, there are two files that need to be modified which define basic behavior of the system as well as enable certain applications and their capabilities. These configuration files are: • configuration.txt: regarding apks (JAVA apps) to be installed in the smart phone. • parameters.txt: initial parameters that can be changed. 2) Developing custom functions and services DiAs is based on complex interaction of applications and services. They represent logical blocks, each of them managing a vital function of glucose and insulin control. From the services open for developers (APCService, APCServiceQuad, BRMService, ExerciseService, MCMService, SSMService and SSMServicePassThrough), three of them are modified for implementing closed loop algorithm: • Artificial Pancreas Closed-loop (APCService) - handles the closed loop operations • Basal Rate Modulation Controller (BRMService) handles basal values and controls the hypo/hyper alert traffic lights.. • Meal Bolus Calculator Service (MCMService) - gives a manual meal bolus.
0644 TABLE I. SENSORS AND DEVICES
III. THE CLOSED LOOP IMPLEMENTATION In this section, execution of the main functions is explained and the necessary system modifications are highlighted. The end result is a modified version of DiAS. The sequence of the main program can be described in four steps: a) Data acquisition - before performing any calculation, the platform needs to obtain the desired information from three devices: a glucose sensor and two fitness bands. Each device requires an independent connection, works at its own sampling rates and gathers particular data. Regardless of their differences, data are presented uniformly to the algorithm. b) Control algorithm - prediction of future glucose level and making a decision c) Insulin infusion/snack warning - hyperglycemia is avoided by infusing insulin. Hypoglycemia is averted suggesting the intake of food. d) Communication with the remote server - last crucial step is to store the information of the phone (data collected, results of the algorithm, reaction time...) in a remote server. In order to collect GSR and EE values, a BodyMedia armband is used [13]. This device is not included by default in DiAS. We designed a new application to manage the armband (Connect BodyMedia) and a local database to be accessed by DiAs and the app (dbSensors). Fig. 4 shows the relations between the Nexus 5 and other devices. It also specifies the applications on Nexus 5 handling the wearable devices: Start_DiAS connects with Tandem pump, CGM Dexcom and activity monitoring Zephyr, whereas Connect_BodyMedia uses Bluetooth to connect with BodyMedia armband
Fig. 4. Sensors and Nexus 5 interface
A. Data acquisition Data are received from the sensors listed in Table I. They are connected to Nexus 5 using Bluetooth LE protocol. The pairing and connection varies in each case. DiAS software provides a driver or application for each of them. All driver/apps have to be initialized at least once when starting the system:
Device
Features Sensors
Communication
Tandem T:slim
Insulin Pump
Bluetooth LE
Dexcom G4
Glucose blood level sensor
Bluetooth LE
Zephyr Bioharness 3
Accelerometer Heart rate sensor Breath rate Accelerometer Activity/calories Heart rate sensor GSR
BodyMedia
Bluetooth LE Proprietary RF Bluetooth LE
Other
Bluetooth Control only Hypo/hyper warnings Glucose sensor and transmitter G4 Receiver Increased range when using an RF receptor Data sent encrypted
1. Pair the device with the Nexus 5 - different procedures are implemented by each company 2. Establish and start the connection - this connection will be maintained unless: • Phone is turned off - by default, devices will stay connected. However, sometimes the connection is restarted (especially when phone is off for a long time) • There is an error in the connection - a warning window will then alert the user Apart from initializing the corresponding device, the driver will be constantly receiving data from it. These data are written in a local database, so that it can later be used by the main thread of the program. In the DiAs closed-loop application, the correct table needs to be accessed when retrieving data. This will happen every 5 minutes (when a new CGM value is received). The algorithm will need all the samples collected during that period. Since the sampling period is not the same, neither will be the number of samples. For each device, this corresponds to: CGM - 1 sample, Zephyr - 300 samples, BodyMedia - 5 samples. B. Control algorithm The proposed closed loop control algorithm [2-4] was originally developed in MATLAB. It analyzes past and present glucose samples, as well as other activity parameters (such as heart rate, GSR, EE) to predict current and future GC. Depending on GC values, the algorithm will suggest different measures to avoid entering hyperglycemia or hypoglycemia. In this study, we have been working in its adaptation for an Android application (DiAs main app). The former algorithm has been divided into different functional blocks. The algorithm results in three actions: do nothing (if no alerts will be triggered), infuse a bolus of insulin thru the pump (if GC is too high) or suggest an intake of carbohydrates/a snack (if GC is too low). The following sections explain how the two active actions are implemented. 1) Insulin Infusion When the glucose level is predicted to increase in excess, the system will infuse an insulin bolus on the patient. In order
0645
to do so, APCService will send a message to PumpService, containing the amount of insulin (as a correction bolus). However, DiAs system has an upper limit for the bolus: the maximum amount that can be infused is 6U. To overcome this limit, sub-boluses can be sent over a period of time. The system has to verify that the bolus has been received and executed by the pump (wait for an acknowledge message). Also, the program has to verify the connection itself (if no ACK is received), since the pump may have been disconnected without DiAS detecting it. Insulin level values are stored on the phone and the remote server. The correct behavior of the pump can be verified at either location. Fig. 5 and Fig. 6 shows examples for 18.2U and 10.4 U boluses, tested with a mock insulin algorithm. After testing, it was observed that up to 50 unit bolus can be delivered every 5 minutes. Note that this is an extremely high value, which the algorithm would never request.
Fig. 5. Example of bolus of 18.2 U and 10.4 Units, as seen on the phone
2) Snack warning In contrast, if the GC predicted is a low, unacceptable value, the patient should eat a rescue snack to increase the glucose and avoid a dangerous situation. The algorithm calculates the amount of carbohydrates needed, depending on the GC and the patient’s data (their fast/slow reaction to snacks and their personal routines). Then, DiAs shows a popup warning window: in this window, the patient sees the amount of carbohydrates to take and a snack suggestion (which holds the equivalent carbohydrates). C. Communication with the Remote Server A remote server workstation is used to store data coming from the Nexus smartphone. Data is saved in a SQL database. After every iteration of the algorithm, DiAs will send JSON (JavaScript Object Notation) packages to the server, for the server to decode and store in tables. These packages contain samples from Dexcom G4 (glucose level), Zephyr Bioharness 3, BodyMedia armband and insulin values (bolus resulting from the algorithm and sub boluses sent to the insulin pump). Ultimately, any computer/device can access these tables with necessary authorization. 1) Data transmission from the smartphone A single message is prepared per device, containing all data from the last 5 min. This way, each device is treated independently, in case any of them exceeds the maximum size per packet (this may happen when trying to send Zephyr data that covers a period over 1 hour and 30 min). Moreover, the application should consider potential issues while connecting to the Internet. It may happen that either the phone cannot access the Internet or that the server itself is not available. Data loss should be avoided in these situations: JSON Objects which has not been acknowledged will be sent again after the next iteration of the algorithm. Following this principle, data will be accumulated and resent until the issue is solved.
Fig. 6. Example of a bolus of 18.2 Units, as seen on the server
2) Server database The server has a PHP interface to interact with the smartphone. Each JSON object sent from DiAs is decoded, and its information is inserted into a mySQL database (in the corresponding table). On the server, four tables are created, one per device. These tables are: bm_sample, cgm_sample, insulin_sample and zephyr_sample. 3) Computer access to server To facilitate access to the server, a Java interface has been developed: it serves as a bridge between a table in the server and an excel file on the computer. The “Server Interface” functions in a simple manner to enable a two ways communication: • Server to computer download: Read values from server’s table, and write new rows in the excel file.
0646
IV. INTEGRATING ADDITIONAL DEVICES TO DIAS As stated before, BodyMedia armband is not included by default in the DiAs system. However, it is possible to run third party applications and thus, have additional devices connected as well. A new application, running a background service, has been developed to collect BodyMedia’s sensor information continuously. This information is stored in a new database. When the closed loop control algorithm is running, apart from the information read from the original DiAS database, it will also fetch the data from the new BodyMedia database.
Fig. 7. Java interface with server. User can select the excel file to upload/download the info. The screenshot also shows the results of pressing Send and Get buttons.
• Computer to server upload: Read new values in excel file, and send them to the server to be stored. In order to guarantee synchronization, the Excel file contains a column called ‘synchronized’, as a flag for new values which were not yet sent to the server. Fig.7 shows server interface and buttons. It is possible to modify both the table (in the server) and excel file (in the computer). User can enter the table name of the database, writing its field (bm_sample on the figure), to access a certain table on the server. Also, the excel file on the computer can be changed: the program can open a navigation window to select an .xsl file. Sending and getting data is done by the corresponding buttons (“Send” and “Get”). Fields besides these buttons show the current state of the transaction: Typically, an acknowledgement message is shown (For example, Values_posted...updated). The interface can automatically send data to the server as well. This function is activated/deactivated by the ON/OFF button, as seen in Fig. 8. With this interface, the interaction with the server can be reduced to write/read operations in the excel file. Moreover, the uploading process has been automated. There are also security advantages to this approach. Thanks to having an executable file as a black box, server’s details (credentials with write and read permissions in the database) are masked inside the Java interface. A third party program does not need to know the exact transactions taking place between the computer and server.
Fig. 8. Automatic service can be turned ON and OFF at any time.
A. External application: BodyMedia connect When the application is started, it will scan for a BodyMedia device in pairing mode. It will display all available devices for the user to select the one they are wearing. The armband can be identified by its serial number, printed on the carcass and written on the Nexus screen. In order to enable the connection, the user verifies the right armband pressing the button on the device. From this moment on, that device will appear as one of the known devices (and no more pairing will be needed). The application will now enter its main activity and user interface. There are three types of packets the armband can send: Minute information, Cumulative information and High rate samples. Furthermore, background service allows interaction with DiAs. B. Background service Background service is the key to maintain a connection with the BodyMedia armband while running DiAs test program. It constantly receives information and stores it in the database. Background service also utilizes a warning system. If, for any reason, the connection with the device is lost, users will see a pop-up window. V. CONCLUSION In this work, a complete framework of an artificial pancreas solution on a mobile device has been presented. This solution integrates an insulin pump (Tandem t:slim), a glucose sensor (Dexcom G4) and two exercise sensors (Zephyr Bioharness 2 and BodyMedia Armband). All devices are managed by a smartphone (Nexus 5). The operating system installed on the phone is the Diabetes Advisory System (DiAS), developed by University of Virginia. In particular, implementation of a closed-loop system for controlling the glucose levels has been described in detail. Steps necessary for integrating external applications and sensors (i.e. BodyMedia) capable of interacting with DiAs main program have been shown. Accessing the remote server has been accomplished with a new interface implemented with a Java program which can exchange data between a remote table (on the server) and a local excel file (which can also be modified by other programs in the computer). Currently, we are migrating the closed loop algorithm developed in [2][4] to the Android based platforms and this will facilitate further experimental studies for AP.
0647
ACKNOWLEDGMENT This work was supported by JDRF grant #17-2013-472 and by National Institutes of Health (NIH) grants 1DP3DK101075 and 1DP3DK101077. The authors acknowledge University of Virginia for providing the DiAs operating system and the developers of DiAs system for their advice in using the software.
[6]
[7]
[8]
REFERENCES [1] [2]
[3]
[4]
[5]
C Cobelli, E. Renard and B. Kovatchev, “Artificial Pancreas: Past, Present, Future” Diabetes, vol. 60, no. 11, November 2011. K. Turksoy, L. T. Quinn, E. Littlejohn and A. Cinar “An Integrated Multivariable Artificial Pancreas Control System,”, Journal of Diabetes Science and Technology, 8(3): 498-507, May 2014. K. Turksoy, L. T. Quinn, E. Littlejohn and A. Cinar “Artificial Pancreas Systems: An Integrated Multivariable Adaptive Approach”, Proceedings of the 19th IFAC World Congress, 2014. K. Turksoy, L. T. Quinn, E. Littlejohn and A. Cinar “Multivariable Adaptive Identification and Control for Artificial Pancreas Systems”, IEEE Trans. on Biomedical Engineering, Vol. 61, No. 3, March, 2014 . T. G. Farmer, Jr., T. F. Edgar and N. A. Peppas, “The Future of Open and Closed-Loop Insulin Delivery for Diabetes Mellitus”, J Pharm Pharmacol.; 60(1): 1–13, Jan 2008.
[9]
[10] [11] [12] [13]
H. Thabit and R.Hovorka, “Closed-loop Insulin Delivery in Type 1 Diabetes”, Endocrinol Metab Clin North Am. 41(1): 105–117, Mar 2012. C. L. Martinez, E. Oruklu and A. Cinar, "Sensor fusion and distributed platform development for artificial pancreas," Electro/Information Technology (EIT), 2015 IEEE International Conference on, Dekalb, IL, 2015, pp. 592-597. doi: 10.1109/EIT.2015.7293403. C. Lazaro, E. Oruklu and Ali Cinar. "Cyber-Physical Platform Development for Multivariable Artificial Pancreas Systems," International Journal of Handheld Computing Research (IJHCR) 6(3), 2015, doi:10.4018/IJHCR.2015070101. P. Keith-Hynes, S. Guerlain, B. Mize, C. Hughes-Karvetski, M. Khan, M. McElwee-Malloy, and B. P. Kovatchev, “DiAs User Interface: A Patient-Centric Interface for Mobile Artificial Pancreas Systems”, J. Diabetes Sci. Technol., Vol. 7, Issue 6, November 2013. Dexcom G4, http://www.dexcom.com/dexcom-g4-platinum-share Tandem t:slim, https://www.tandemdiabetes.com/products/t-sliminsulin-pump Zephyr Technology Corporation,, http://zephyranywhere.com/ BodyMedia Fit Armband, http://www.cnet.com/news/my-life-with-thebodymedia-fit-activity-tracker/
