Identification of blood glucose patterns through continuous glucose monitoring and decision trees

Identification of Blood Glucose Patterns through Continuous Glucose Monitoring and Decision Trees Trabajo de Fin de Grado en Ingenier´ıa Inform´atica Francisco Jos´e Lozano Serrano Dirigido por Jos´e Ignacio Hidalgo P´erez Departamento de Arquitectura de Computadores y Autom´atica Facultad de Inform´atica Universidad Complutense de Madrid Junio 2017 Documento maquetado con T EXiS v.1.0+. Identification of Blood Glucose Patterns through Continuous Glucose Monitoring and Decision Trees Francisco Jos´e Lozano Serrano Bachelor’s Degree Final Project in Computer Science Directed by Jos´e Ignacio Hidalgo P´erez Computer Architecture and Automation Department Computer Science Faculty Complutense University of Madrid June 2017 Acknowledgments This work was partially supported by the Spanish Government Minister of Science and Innovation under grant TIN2014-54806-R. The authors also acknowledge Mar´ıa Aranzazu Aramendi Zurimendi, Remedios Mart´ınez Rodr´ıguez and MD Marta Botella Serrano from Hospital Universitario Pr´ıncipe de Asturias-Alcal´a de Henares and MD Esther Maqueda Villaiz´an from Hospital Virgen de la Salud de Toledo for collecting the data for the experiments and giving us useful comments. v Abstract The demand for Continuous Glucose Monitoring (CGM) systems is increasing among type 1 diabetic patients. Some companies are trying to improve the monitorization and the usability of these systems. One example is Abbott FreeStyle Libre, which provides a new concept of glucose monitoring called Flash Glucose Monitoring (FGM). FGM is more affordable and does not need calibration. This increased demand for these devices means an opportunity for data and computer scientists, who can contribute to the development of decision-making support systems based on the data collected from the devices. Type 1 diabetic patients that use FreeStyle Libre must enter the number of insulin and carbohydrates units that they are going to take before a meal. Using both the entered data and the blood glucose values collected by the device automatically, the application developed in this project generates a report of the patient’s glucose patterns. In addition, it provides a web application that allows the user to upload the data obtained from his device and download the report on his computer or smartphone. The application uses decision trees to detect the patterns and entails a starting point in the creation of ensemble models with more predictive power, also based on decision trees. Furthermore, the methodology makes a segmentation of the data set in blocks, determined by the different meals done throughout the day, adding more information to the set of variables used to train the model. As a result, the application can discover repetitive patterns in the daily life of the patient, which can help him to take early preventive measures for risk situations in a period close to the next meal. Key words: Diabetes, Decision Trees, Glucose Monitoring, Patterns vii Resumen La demanda de sistemas de Monitorizaci´on Continua de Glucosa (CGM) est´a aumentando entre los pacientes diab´eticos de tipo 1. Algunas empresas tratan de mejorar la monitorizaci´on y la usabilidad de estos sistemas. Un ejemplo es Abbott FreeStyle Libre, que proporciona un nuevo concepto en monitorizaci´on de glucosa llamado Monitorizaci´on Flash de Glucosa (FGM). FGM es m´as asequible y no requiere calibraci´on. El aumento de demanda de estos dispositivos significa una oportunidad para inform´aticos y cient´ıficos de datos, que pueden contribuir al desarrollo de sistemas de apoyo a la toma de decisiones basado en los datos recogidos por estos dispositivos. Los pacientes diab´eticos de tipo 1 que usan FreeStyle libre, deben introducir los datos de insulina y carbohidratos antes de cada comida. Usando los datos introducidos por los pacientes y los niveles de glucosa recogidos autom´aticamente por el dispositivo, la aplicaci´on desarrollada en este proyecto es capaz de generar un informe de patrones de glucosa del paciente. Adem´as, se proporciona una aplicaci´on web que permite al usuario subir los datos obtenidos del dispositivo y descargarse el informe en su propio ordenador o dispositivo m´ovil. La aplicaci´on hace uso de ´arboles de decisi´on para detectar los patrones y supone un punto de partida en la elaboraci´on de modelos ensamblados con mayor poder predictivo, tambi´en basados en ´arboles de decisi´on. Adem´as, la metodolog´ıa segmenta el conjunto de datos en bloques marcado por las diferentes comidas del d´ıa, a˜nadiendo informaci´on adicional al conjunto de variables usadas para entrenar el modelo. Como resultado, la aplicaci´on es capaz de describir patrones repetitivos en la vida diaria del paciente, que le pueden ayudar a anticiparse a una situaci´on de riesgo en un periodo de tiempo pr´oximo a la siguiente comida. Palabras clave: Diabetes, ´ Arboles de decisi´on, Monitorizaci´on de glucosa, Patrones. ix Chapter 1 Introduction Diabetes mellitus is a disease that is characterised by the presence of hyperglycemia as a consequence of defects in insulin secretion, insulin action or both (Diaz Aguilar y M´ezcua Navarro, 2007). Diabetes mellitus can be classified into four different types: Diabetes mellitus type 1, which causes the destruction of a beta cell that is present in the pancreas, and an absolute deficiency in insulin production. Diabetes mellitus type 2, which causes resistance to the insulin action and certain deficiency in the insulin secretion. Other types of diabetes, related to genetic defects that affect to the beta cell such as pancreatic lesions, drugs and other factors. Gestational diabetes, which appears during the gestation period. It is estimated that one to five percent of the Spanish population suffers from diabetes mellitus type 1 (Soriguer et al., 2012). Although this kind of diabetes is not related to the lifestyle, its incidence is increasing among the population. Diabetics must take an insulin dose before or shortly after each meal to keep their blood glucose level in harmless range. Many tools allow diabetic patients to monitor their blood glucose values in real time and have a better control of their disease. The increment in the commercialization of blood glucose monitoring systems is an opportunity for data and computer scientists to create innovative tools that help diabetics to anticipate to upcoming risk situations and improve their lifestyle. It is important to provide them with a service that detect repetitive risky situations, but it is even more important to give them meaningful answers according to these patterns. This last guidance must be by thoroughly designed by means of a joint effort among computer scientist and 1 2Chapter 1. Introduction physicians, who are responsible for giving a correct characterization to the identified patterns. This project aims to provide a decision-making support system to type 1 diabetic patients. The application uses the data obtained from an FGM (Flash glucose monitoring) device. The main difference with traditional CGM (Continuous glucose monitoring) devices is that the patient does not see his blood sugar levels until he scans the sensor with the reader. Another difference is that the device does not need to be calibrated whilst some other CGM devices need to be calibrated several times per day (Heinemann y Freckmann, 2015). The patient has access to a report of patterns of his blood glucose values by uploading the data of the reader to a web application. This idea has been inspired by other studies and applications focused on the development of a solution for diabetic people using data from a monitoring system. One example of an application developed for diabetics is glUCModel, a monitoring and modelling system for chronic diseases applied to diabetes (Hidalgo et al., 2014). This application allows doctors to consult the information of their patients and have better control over their illness. Moreover, glUCModel offers a recommendation system that provides automatic recommendations to their patients, increasing their awareness of their condition. This project has a similar goal, but using a different approach through decision trees to recognise the patterns and segmenting each day in blocks determined by the meals. Another study that has provided some ideas to this project has been described in (Wiley, 2011). This thesis presents a support system to diabetics using data from a CGM device and machine learning techniques, which try to predict the blood glucose values of the patients. This study contains interesting contributions about data preprocessing, feature engineering, classification of glycemic variability and evaluation techniques. In the following subsections, the motivation, the objectives and the structure of the document are described. 1.1. Motivation Currently, many different models try to predict the blood glucose values of diabetic patients and warn them when these values are not in a safe range. However, these models often act like black boxes that send alerts, but do not provide an explanation regarding their provenance. Furthermore, the patient sometimes has a greater need of knowing how to react to frequent dangerous situations that compromise his health. Once the patient becomes aware of these patterns, he is able to modify his daily habits to avoid unwanted scenarios. Detecting patterns in blood glucose levels is a challenge that we wanted 1.2. Objectives 3 to face with this project. Giving a useful and accessible description to both patients and physicians is even more challenging. It is necessary to innovate to address these challenges and provide solutions potentially helpful. However, innovation and willingness are not sufficient if they are not coupled with the creation of realistic scenarios using actual data. Working with data collected from diabetic patients is something that made this project very attractive to us because accessing to real information is often limited or restricted. Data-driven solutions are a trend in the last years due to the existence of tens of data mining and big data tools to discover hidden patterns in large datasets. This project was an opportunity to turn our ideas into action and use our knowledge in data science to improve the life quality of diabetics. Further, we wanted to contribute to the research of new methods of prevention of hyperglycemia . We believe that computer scientists have the social responsibility of providing solutions to society problems using the available technology. Developing this application is only one small contribution to a collective effort of helping diabetics to live as normal a life as possible. 1.2. Objectives The primary purpose of this project is to develop a Python package that generates reports using data files obtained from FreeStyle Libre, a blood glucose monitoring device. To enhance this package, we had as secondary objective to develop a web application that integrated the package and offered its services to the user through a web browser. The main package is not intended to be a predictive tool for the patient but rather a descriptive instrument to support decision making. The application is not connected in real time to another device or smartphone, but it uses the data files obtained by the patient from the reader. Despite these limitations, another objective of the application is still being useful for the patient. Finally, and according to the open source and multiplatform phylosophy of Python, the ultimate objective is to contribute to an active community that is looking for new models and creating decision-making support systems to help diabetic people and physicians. Therefore, the project is available on GitHub and works in Windows and Linux operating systems that can run Python and conda environments. This ensures that other researchers can use the software, either through the Python package or the web application, and get new ideas about data preprocessing and the use of decision trees in the creation of models of blood glucose. 4Chapter 1. Introduction 1.3. Document structure This document follows a structure that consists of the following chapters: In Chapter 1, we introduce the project, describing its motivation and objectives that defined the guidelines of the development process. In Chapter 2, we describe the materials and methods that allowed us to work on this project. Firstly, the device in charge of monitoring the blood glucose values and secondly, the decision trees used to create the model, explaining their features and the algorithm they use. Chapter 3 explains the design of both the application core and the web application that wraps the core. This chapter also includes the structure of classes, the flow chart and some details about the used technology. Chapter 4 describes the whole methodology from the beginning, when the application reads the data files and process them, to the creation of the model and the generation of the report. In Chapter 5 shows the results of applying the methodology in a series of data files, commenting the relevant ones and discussing which were expected beforehand. Finally, Chapter 6 contains a conclusion and suggests new ideas for a possible improvement of the methodology. Chapter 2 Introducci´on La diabetes mellitus es una enfermedad caracterizada por la presencia de hiperglucemia como consecuencia de defectos en la secreci´on de insulina, la acci´on de insulina, o ambas (Diaz Aguilar y M´ezcua Navarro, 2007). La diabetes mellitus puede ser clasificada en cuatro tipos diferentes: 1. Diabetes mellitus tipo 1, que causa la destrucci´on de una c´elula beta que est´a presente en el p´ancreas, y una absoluta deficiencia en la producci´on de insulina. 2. Diabetes mellitus tipo 2, que causa resistencia a la acci´on de la insulina y cierta deficiencia en la secreci´on de insulina. 3. Otros tipos de diabetes, relacionadas con defectos gen´eticos que afectan a la c´elula beta tales como lesiones pancre´aticas, drogas y otros factores. 4. Diabetes gestacional, que aparece durante el periodo de gestaci´on. Se estima que entre el uno y el cinco por ciento de la poblaci´on espa˜nola sufre de diabetes mellitus tipo 1 (Soriguer et al., 2012). Aunque este tipo de diabetes no est´a relacionada con el estilo de vida, su incidencia est´a aumentando entre la poblaci´on. Los diab´eticos deben administrarse una dosis de insulina antes o poco despu´es de cada comida para mantener sus valores de glucosa en sangre en un rango no da˜nino para su salud. Muchas herramientas permiten a los pacientes diab´eticos monitorizar sus valores de glucosa en sangre en tiempo real y tener un mejor control sobre su enfermedad. El incremento en la comercializaci´on de sistemas de monitorizaci´on de glucosa es una oportunidad que se presenta a cient´ıficos de datos e inform´aticos para crear herramientas innovadoras que ayuden a los diab´eticos a anticiparse a situaciones de riesgo pr´oximas y mejorar su estilo de vida. Es importante proveerles de un servicio que detecte situaciones de riesgo repetitivas, pero es a´un m´as importante darles respuestas significativas de 5 6Chapter 2. Introducci´on acuerdo a esos patrones. Esta ´ultima orientaci´on debe ser minuciosamente dise˜nada por medio de un esfuerzo conjunto entre inform´aticos y m´edicos, responsables de dar una correcta caracterizaci´on a los patrones identificados. Este proyecto aspira a proporcionar un sistema de apoyo a la toma de decisiones a pacientes diab´eticos de tipo 1. La aplicaci´on usa data obtenida de un dispositivo FGM (Monitorizaci´on de glucosa Flash), La principal diferencia con los dispositivos CGM (Monitorizaci´on continua de glucosa) es que el paciente no ve sus niveles de glucosa en sangre hasta que ´el escanea el sensor con el lector. Otra diferencia es que el dispositivo no necesita ser calibrado mientras que otros dispositivos CGM necesita ser calibrados varias veces por d´ıa (Heinemann y Freckmann, 2015). El paciente tiene acceso al informe de patrones de sus niveles de glucosa en sangre subiendo los datos del lector a una aplicaci´on web. Esta idea ha sido inspirada por otros estudios y aplicaciones enfocados en el desarrollo de una soluci´on para personas diab´etica usando datos de un sistema de monitorizaci´on. Un ejemplo de una aplicaci´on desarrollada para diab´eticos es glUCModel, un sistema de monitorizaci´on y modelado de enfermedades cr´onicas aplicado a la diabetes (Hidalgo et al., 2014). Esta aplicaci´on permite a los doctores consultar la informaci´on de sus pacientes y tener un mejor control sobre su enfermedad. Adem´as, glUCModel ofrece un sistema de recomendaci´on que proporciona recomendaciones autom´aticas a sus pacientes, aumentando la concienciaci´on sobre su enfermedad. Este proyecto tiene un objetivo similar, pero usando un enfoque diferente a trav´es de ´arboles de decisi´on para reconocer los patrones y segmentando cada d´ıa en bloques determinados por cada comida. Otro estudio que ha aportado algunas ideas a este proyecto ha sido descrito en (Wiley, 2011). Esta tesis presenta un sistema de apoyo a los diab´eticos usando datos de un dispositivo CGM y t´ecnicas de aprendizaje autom´atico, que tratan de predecir los valores de glucosa en sangre de los pacientes. Este estudio contiene contribuciones interesantes sobre preprocesamiento de datos, ingenier´ıa de factores, clasificaci´on de la variabilidad gluc´emica y t´ecnicas de evaluaci´on. 2.1. Motivaci´on En la actualidad, diferentes modelos tratan de predecir los niveles de glucosa de pacientes diab´eticos y avisarles cuando estos valores no est´an en un rango seguro. Sin embargo, estos modelos a menudo act´uan como cajas negras que enviar alertas, pero no proporcionan una explicac´on sobre su origen. Adem´as, el paciente a veces tiene una necesidad mayor de saber c´omo reaccionar a situaciones frecuentes de riesgo, que ponen en peligro su salud. Una vez el paciente es consciente de estos patrones, es capaz de 2.2. Objetivos 7 modificar sus h´abitos diarios para evitar escenarios indeseados. Detectar patrones en los niveles de glucosa en la sangre es un reto al que quisimos hacer frente con este proyecto. Dar una descripc´on ´util y accesible a pacientes y m´edicos supone un reto a´un mayor. Es necesario innovar para atajar estos desaf´ıos y proporcionar soluciones potencialmente ´utiles. Sin embargo, la innovac´on y la predisposic´on no son suficientes si ellos no van ligados con la creac´on de contextos realistas usando datos reales. Trabajar con los datos recogidos de pacientes diab´eticos es algo que hizo este proyecto muy interesante para nosotros ya que el acceso a la informac´on real est´a a menudo limitada o restringida. Las soluciones basadas en datos son una tendencia en los ´ultimos a˜nos debido a la existencia de decenas de herramientas de miner´ıa de datos y big data que descubren patrones en conjuntos de datos muy grandes. Este proyecto fue una oportunidad para poner en pr´actica nuestras ideas y usar nuestro conocimiento en ciencia de datos para mejorar la calidad de vida de los diab´eticos. Adem´as, quisimos contribuir a la investigaci´on de nuevos m´etodos en la prevenci´on de la hiperglucemia. Creemos que los inform´aticos tenemos la responsabilidad social de proporcionar soluciones a los problemas de la sociedad usando la tecnolog´ıa disponible. Desarrollar esta aplicaci´on es solo una peque˜na contribuci´on a un esfuerzo colectivo de ayudar a los diab´eticos a tener una vida lo m´as normal posible. 2.2. Objetivos El objetivo principal de este proyecto es desarrollar un paquete de Python que genere informes usando ficheros de datos obtenidos de FreeStyle Libre, un dispositivo de monitorizaci´on de glucosa. Para mejorar este paquete, tuvimos como objetivo secundario desarrollar una aplicaci´on que integrara y ofreciera sus servicios al usuario a trav´es de un navegador web. El paquete principal no pretende ser una herramienta de predicci´on para el paciente, sino un instrumento descriptivo para el apoyo en la toma de decisiones. La aplicaci´on no est´a conectada en tiempo real a otro dispositivo m´ovil, pero usa los ficheros de datos obtenidos por el paciente del lector. A pesar de estas limitaciones, otro objetivo de la aplicaci´on es ser aun as´ı ´util para el paciente. Finalmente, y de acuerdo a la filosof´ıa de c´odigo abierto y multiplataforma de Python, el objetivo final es contribuir a una comunidad activa que est´a buscando nuevos modelos y crear sistemas de apoyo a la toma de decisiones para ayudar a pacientes diab´eticos y m´edicos. Por lo tanto, este proyecto est´a disponible en GitHub y trabaja en sistemas operativos Windows y Linux que sean capaces de ejecutar Python y entornos conda. Esto asegura que otros investigadores pueden usar el software, sea a trav´es del paquete Python o de la aplicaci´on web, y adquirir nuevas ideas sobre pre- 8Chapter 2. Introducci´on procesamiento de datos y el uso de ´arboles de decisi´on en la creaci´on de modelos de glucosa. 2.3. Estructura del documento Este documento sigue una estructura compuesta de los siguientes cap´ıtulos: 1. En el cap´ıtulo 1presentamos el proyecto, describiendo su motivaci´on y los objetivos que definen las directrices del proceso de desarrollo. 2. En el cap´ıtulo 2 describimos los materiales y m´etodos que nos han permitido trabajar en este proyecto. En primer lugar, el dispositivo encargado de la monitorizaci´on de los valores de glucosa en sangre, y en segundo lugar, los ´arboles de decisi´on usados para crear el modelo, explicando sus caracter´ısticas y el algoritmo que usan. 3. El cap´ıtulo 3 explica el dise˜no de el n´ucleo de la aplicaci´on y la aplicaci´on web que lo envuelve. Este cap´ıtulo tambi´en contiene la estructura de clases, el diagrama de flujo y algunos detalles sobre la tecnolog´ıa usada. 4. El cap´ıtulo 4 describe la metodolog´ıa completa desde el principio, cuando la aplicaci´on lee los ficheros de datos y los procesa, hasta la creaci´on del modelo y la generaci´on del informe. 5. En el cap´ıtulo 5 mostramos los resultados de aplicar la metodolog´ıa en una serie de ficheros de datos, comentando los m´as relevantes y comentando cuales eran esperados de antemano. 6. Finalmente, el cap´ıtulo 6 contiene una conclusi´on y sugiere nuevas ideas para una posible mejora de la metodolog´ıa Chapter 3 Materials and methods 3.1. FreeStyle Blood Glucose Monitoring System The data files that are processed in this project were obtained from FreeStyle Libre devices, provided by the company Abbott Diabetes Care, which sells several appliances for glucose control by diabetic patients. Continuous glucose monitoring (CGM) became available in the year 2000, having a measurement error of more than ±20 %. New devices have reduced this error 10 %, but there is a continuous effort for reducing this margin by the producers (Rodbard, 2016). FreeStyle Libre is an an interstitial glucose monitoring system, which is an alternative for the capillary and venous blood glucose measurement (Bailey et al., 2015). One advantage of this kind of devices is that it provides more reference points of measurement than conventional blood glucose devices, which makes them an interesting source of data to create a model. The reader captures the data from the sensor when it is closer than 4 cm, and the patient can get his blood glucose values at any moment by reading the data from the sensor. The patient must synchronise the data with the sensor at least once each 8 hours. If not, the sensor erases all the information until the patient does a new synchronisation. On the other hand, the reader can keep blood glucose values for 90 days and provide data through the sensor that is easy to interpret by the patient. The patients can obtain the data files by connecting the device to a PC. Ten patients provided twelve data files to test the application. The data files were anonymized before their analysis, leaving only the initials of the patients as an identifier. Some of the data files were incomplete or suffered from a lack of data that had to be considered and managed by the application. The quality of the datafiles and the results obtained are discussed in chapter 6. The data files obtained from a FreeStyle reader contained the following columns: 9 16 Chapter 4. Design of the application the number of samples of each class and its impurity. One important function is str , the built-in function of Python that can be overwritten to define the string that represents the object. This function returns a human-readable version of the pattern that is displayed in the reports. Rule: This class only encapsulates three attributes: A feature, an operator and a threshold value. It also contains some support functions that are used by the str to create the string representation of the class. Translator: The class translator contains two bidirectional dictionaries (bidict) that allow establishing one-to-one mappings between two variables efficiently. These dictionaries include the internal representation of the variables in the program and its translation to the corresponding language. The Translator class translates the headers of the source files to its internal representation and all the variables that are written in the report. All the described classes and their relations can be observed in Figure 4.1. The support modules are the following ones: preprocessor.py: The preprocessor contains all the functions necessary to transform the raw data into a dataset that can be passed to the decision trees. It carries out the validation of periods and the division of the data set in blocks. It also cleans the data, generates new columns and binarizes the labels. visualization.py: This module has functions that generate plots and images that are included in the report such as the blood glucose values or the representation of the decision trees. It also has functions that support the generation of plots like smoothing the curves of the plots. report.py: A module that allows generating a report from the command line with a series of arguments. 4.2. Web application The web application has been built using the Django Framework, written in Python. This framework lets the user define the model of your application and forget about the interaction with the database thanks to its ORM (Object-Relational Mapping). It provides automatic generation of formularies and it has a good interface to build templates. Also, it contains a series of modules that reduces development time and increase the security. 4.2. Web application 17 One of the packages included in the web application is the core package of the project, described in the previous section. The core is completely integrated into the web application because it does not require a communication protocol since it is also developed in Python. The user needs to fulfil two requirements before starting to use the application: 1. The user must sign up and enter some personal data: His name, his email and a password. After this step, he must log in with his account to have access to the service of the application. This authentication protocol has been implemented using the authentication system of Django, which handles user accounts and permissions while preserving security. 2. The user must accept a document of terms and conditions of the application. These conditions imply to relinquish some data that it is used by the application to generate the reports. This mechanism has been implemented using the module Django-termsandconditions, and it allows to define the terms and conditions from the administration. It also keeps version control of the conditions, forcing a user to accept the terms again if they are updated. When a logged user accepts the terms and conditions, the application records his IP address and the date of acceptance, giving him access to the service. Through the web interface, the user can upload and delete a series of data files obtained from his FreeStyle devices. It also contains some buttons to select which of the features must be used for training the model and some additional features of the reports like defining the language or including information about the blocks. Figure 4.2 shows the interface of the page that the user access to generate the report. Once the user clicks the button “Generate report”, it sends a POST request to the server. The time necessary to produce the report may vary depending on the resources of the host server and the number of data files that the application must process. After the application core has generated the PDF file, it is returned as a response, and the user can visualise it on the browser or download it to his file system. 18 Chapter 4. Design of the application Figura 4.1: Class diagram of the core application 4.2. Web application 19 Figura 4.2: Web interface used by the user to generate a report Chapter 5 Methodology 5.1. Introduction The application core has been designed to work as an independent component which can be used as a standalone application or as part of an outer application like the web application developed in this project. The main input of the application core is a series of data files that are used for training the model, and that can be obtained directly from a FreeStyle Libre device. Also, the application provides the possibility of specifying the source language of the data file and some configuration parameters of the decision trees. The output is a report that contains the blood glucose patterns, the decision trees used to extract them and some additional information related to the blood glucose values of the patient. This report can be exported both in PDF and HTML format. In the following sections, we describe the different steps of the program flow (See Figure 5.1) 5.2. Data preprocessing The data preprocessing process starts reading a data file (or a set of data files). The Model object uses the preprocessing module to deal with the raw data and build the main data set of the patient. The main data set is composed of every preprocessed data file and it is used as a single data frame to train the model. This object accepts a list of file paths and the language of the data files’ headers to identify each column. It creates aTranslator object, in charge of translating the columns to the syntax used inside the code to select the columns. In the next step, the program iterates all the data files, preprocessing and adding each of them to the main data set. If the format is not the one expected (Different headers, corruption of the data file, wrong extension, etc.), it raises a DataFormatException, which can be handled by the web 21 22 Chapter 5. Methodology Figura 5.1: Main flowchart of the application methodology application and reported to the user. The information in the data files comes from the values recorded by the device, which means that the noise is also encoded in the blood glucose 5.2. Data preprocessing 23 values. The most common anomalies in the data collected by blood glucose monitoring systems appear when the device becomes uncalibrated. Although FreeStyle Libre devices do not need to be calibrated, they have an estimation error that can not be corrected with information obtained from any external source (such as finger sticks). Other CGM devices provide the possibility of entering external data to calibrate them, which can be used to detect and fix the anomalies in the recorded values. We made the assumption that the estimation error of the sensor is propagated to the patterns extracted by the model. The three most important preprocessing techniques used to treat each data file are missing data management, the definition of blocks and smoothing of blood glucose curves. 5.2.1. Dealing with missing data One of the main issues of the FreeStyle device is that it deletes all the entries in the last 8 hours if the patient do not synchronise the reader with the sensor in that period. As a consequence, the data file may contain some discontinuities in the data. In the application, these gaps are handled dividing one data file in a subset of valid periods. The definition of a valid period is a period of no more than 8 hours without carbohydrate registers. This definition is necessary because some features (like the time elapsed since the last meal) are calculated considering the period between two meals. If this period is too large (Greater than 8 hours) because of missing data, it introduces some noise in the data set that may decrease the accuracy of the model. Once each period is defined, they are preprocessed separately and incorporated to the main dataset. In any of the following cases, the program discards a period: If it has no carbohydrates registers Its duration is less than 24 hours. It results in an empty set after preprocessing it. Another drawback is that the information of meals is only available from one single source: The input made by the patient in the device. If the patient does not specify the number of carbohydrates, it assigns one by default. However, if the patient does not enter any carbohydrate data, this data is not available in the dataset. Some data such as the meal time cannot be inferred easily because a patient typically does not eat at the same time every day. The patient should provide accurate and realistic information so that the report can reveal if carbohydrates have any impact on the patient’s blood glucose values. 24 Chapter 5. Methodology If some carbohydrate data are missing, it causes a poor division of the day in blocks and, therefore, decrease the quality of the dataset and the patterns. This issue is notified in the program as a warning (and reflected in the report subsequently) when the mean of carbohydrates of each day in the period is less than one per day. 5.2.2. Define blocks Each day of the patient is divided into a series of blocks defined by the different meals that the patient has throughout the day. A time window from two hours before to four hours later is defined for each carbohydrate entry (register type number 5), and it only includes automatic measurement of blood glucose values (register type number 1). Each block also contains the number of insulin doses that the patient has taken in the block. The column that contains the number of carbohydrates units and the column without numerical value of carbohydrates units in a meal (one unit) are merged. This intersection is also made for the columns that contains the values of rapid insulin doses taken by the patient before a meal. Figura 5.2: Division in blocks of a sample day. Some blocks are overlapped. The next step entails iterating all the days of the dataset and define their corresponding blocks from 0 to n(Block 0 is the block associated with all entries that have not been included in any other block). For each day, all the occurrences of carbohydrates of that day are used to define its time window and include all the values of carbohydrates and rapid insulin that correspond to that block. Therefore, several blocks may reference to the same doses of carbohydrates and insulin due to a possible overlapping between blocks. The preprocessor considers this overlapping and it unfolds every overlapped entry in several entries, indicating in one new feature that the block is overlapped 5.3. Define features and labels 25 Datetime Glucose Auto Block Day Block Overlapped Block Carbo Block Rapid Insulin Block 05/04/2016 7:46 97 1 05/04/2016 FALSE 1 1 05/04/2016 8:01 94 1 05/04/2016 FALSE 1 1 05/04/2016 8:16 83 1 05/04/2016 FALSE 1 1 05/04/2016 8:31 74 1 05/04/2016 TRUE 1 1 05/04/2016 8:31 74 2 05/04/2016 TRUE 1 0 05/04/2016 8:46 74 1 05/04/2016 TRUE 1 1 05/04/2016 8:46 74 2 05/04/2016 TRUE 1 0 Table 5.1: Unfolding of registers with overlapped blocks 5.2.3. Smoothing curves Capillary measurements allow a maximum error of 15 % for glucose levels ≥100 mg/dL and ±15 mg/dL for glucose levels <100 mg/dL (Fokkert et al., 2017). Even though CGM sensors are useful tools in the management of diabetes due to their high accuracy (Mastrototaro et al., 2008), these errors must be considered by their users. For example, a physician usually smooths the blood glucose values implicitly when he analyses the data. This technique is used by the program when the visualisation module creates the daily plots included in the report. Cubic spline smoothing is one technique that many physicians identify as the one that is more similar to the implicit smoothing that they apply when they analyse a time series of blood glucose values (Wiley, 2011). Cubic spline smoothing is a cubic spline interpolation that uses a regularisation parameter, and it is described in (Pollock, 1993). I used the implementation that pandas library includes, which is a wrapper of the method interp1d, present in package interpolate, which belongs to the library scipy. One feature of the cubic spline smoothing technique that we could not use is the possibility of giving extra weighting to some register values rather than others. Other devices allow entering finger stick data, which is more reliable than the automatic measurement, and more weight is usually assigned to this kind of registers. A FreeStyle Libre device does not support to enter external data and therefore the algorithm treats all the blood glucose values of the time series equally. 5.3. Define features and labels After preprocessing all the valid periods and add them to the main dataset, the process of feature engineering starts. One of the constraints of 32 Chapter 5. Methodology 5.5. Report generation The last step of the methodology is generating the report using the patterns extracted in the previous step together with some additional information obtained from the main dataset. The application uses an HTML template that is the backbone of the report, and the library Jinja2 renders this template using a dictionary that contains the variables generated in Python. This template is completely dynamic, and its style and content can be customized just like a web page. The method that generates the report accepts a parameter with the language of the report and configures the Translator object according to this parameter. Therefore, all the variables that the method passes to the template are previously translated, and the help page that is included at the end of the report also changes depending on the language. The method can generate the report in both PDF and HTML format. The images that appear the report (such as the tree graphs or the plots) are saved previously in a folder with a unique identifier provided as a parameter in case the user application wants to use them for other purposes. The report is structured in four parts: 1. Information about the patterns along with their rules for each risk situation 2. Decision trees that have been used to obtained the patterns 3. Statistics and division in blocks of every day in the data set 4. Information about the contents of the report The warnings issued by the application core are displayed at the beginning of the report. For example, if the quality of the dataset is not sufficient, a message alerts the patient that the patterns may not be accurate. After these warnings, the first part contains the patterns of hyperglycemia, hypoglycemia and severe hyperglycemia. If it has not been possible to obtain patterns for any of these conditions, the report does not include the section of patterns for that condition. The following elements compose each pattern: 1. Set of rules that describe the risk situation in the next block. 2. Number of samples of the data set that are obtained by the defined rules in the pattern together with the percentage of samples regarding the total of the data set 3. Impurity of the pattern. 4. Positive samples classified as a risk situation in the next block along with the percentage of samples regarding the total of positive samples 5.5. Report generation 33 5. Negative samples classified as a situation without risk in the next block along with the percentage of samples regarding the total of negative samples. The second part of the report shows the graphical representation of each tree. These images provide additional information that cannot be obtained from the patterns. The trees show all the patterns, including the ones that do not define a risk situation. The colour scale of each node determines both the majority class and the impurity. The colours of the tree are a good indicator to identify if the patient tends to suffer from a condition more than another. For example, in Figure 5.6, it can be observed that the patient tends to suffer from hypoglycemia at least one time in each block. Figura 5.6: Decision tree that detects patterns of hypoglycemia. Nodes that correspond to risk situations are drawn in blue.Figure C.2 shows another example of a hypoglycemia tree The intensity of the colour increases as the impurity of the node decreases. It means that the patterns that end in a leaf with an intense colour (either blue or orange) are the ones that are capable of separate samples that only belongs to one class. Also, each node also indicates its impurity value, the number of samples that follow its rule, the number of samples that belongs to each class and the majority class (which determines the label of the node). The third part of the report is optional and appears in the report only if the user passes a certain parameter. This information can help the patient or physician to see where the decisions of the tree come from and see the blocks that usually lead to a risk situation. It includes statistics per block and day such as the maximum and minimum, mean and standard deviation of the blood glucose values and the glycemic variability measured with MAGE. Finally, the fourth part is just information that helps the patient and the physician to understand the concepts that are detailed in this document 34 Chapter 5. Methodology and makes each report a self-contained piece of information. In Appendix B, there is a sample of a generated report containing all the patterns, the information of the blocks of one day and the information about the report. Chapter 6 Experimental results Ten patients provided twelve different data files for developing and testing the application. The mean age of the patients was 34 years with a standard deviation of 10.34. Regarding their height, the patients had an average height of 165 cm with a standard deviation of 9.12m. Finally, their weights values had a mean of 66.11 kg with a standard deviation of 16.75 kg. Two of the data files provided by these patients did not contain any register of carbohydrates (Register type 5), and the application returned an error because no block could be defined. The ten remaining files contained a broad range of rows from 427 to 11444 and a mean of 2668,2 rows. There is no a perfect positive correlation between the number of days and the number of rows because some of the data files contained time gaps. These time gaps were produced if the patient did not synchronise the sensor with the device at any moment in a period of eight hours (As it was described in Section 5.2.1). These gaps also vary in a wide range of time from 8 hours to 2 weeks. The minimum period is four days; the maximum is 152 days, and the mean is 39,9 days. Seven out of ten files produced a warning by the application, which reported that they had an average of less than three registers of carbohydrates per day. This warning may be considered as an indicator of the quality of the datafiles and, consequently, the quality of the generated patterns. Some of the features calculated from the data rely on the carbohydrates information entered by the patient such as the blocks or the minutes since the last meal. If this information is incomplete or faulty, the generated patterns also are likely to be imprecise. The patients that provided a high-quality data files were ACN, CAA and MPA (The data file corresponding to the period 25/05/16 - 29/05/16). The decision trees were analysed considering several parameters: 1. Number of patterns extracted 35 36 Chapter 6. Experimental results 2. Percentage of samples regarding the total, and impurity of the pattern with the largest coverage. The coverage was defined as the proportion of samples that fulfilled the rules of the pattern. 3. AUC score of the decision tree using 5-fold cross validation. 4. The degree of importance of its features AUC (Area Under Curve) measures the overall performance of a model and its values usually fall in a range from 0.5 to 1. The minimum value is obtained by a model that makes random predictions and the maximum value is obtained by a perfect classifier. Values lower than this range indicates that the model performs worse than a random classifier (Hernandez et al., 2006). AUC metric is derived from the ROC (Receiver Operating Characteristic) plot and it is the most common quantitative index that describe it (Hanley y McNeil, 1982). This curve shows the relation between the true positive rate and the false positive rate as its discrimination threshold varies. K-Fold cross validation splits the data set into ksubsets (folds) of approximately equal size. After splitting the data set, the model is trained k times rotating k-1 folds and validating over the remaining fold (Kohavi et al., 1995). This evaluation was done using the AUC metric and rotating over five folds of each data set for this project. An existing implementation of cross-validation is provided by the method cross val score included in the package model selection of the sklearn library. The importance of the features of each tree is calculated using the Gini importance. (Breiman, 2015). The Gini importance of a feature is computed as a normalised total reduction of the Gini index in each split done considering the feature. The higher the Gini importance is, the more informative is a feature. After computing the importance of each feature in each tree for all the data sets, the results were grouped by the mean of the importance of the features for each type of tree. Figure 6.1 shows a summary of the importance of all the features. All the decision trees that detected patterns of hyperglycemia provided at least one pattern with zero impurity. The largest patterns had a coverage average of 40,86 % and detected a mean of 1,8 patterns for all the data files. Two of the ten hyperglycemia decision trees did not provide any pattern, and the ones that provided only one pattern, it had a high coverage (71,08 and 67,66 %). The mean AUC score of the eight trees that produced at least one pattern was 0,6703, with a maximum of 1 and a minimum of 0,4186. It is relevant to highlight that the tree that scored an AUC of 1 was obtained using a data file that contained only 427 rows and a mean of more than three carbohydrates entries per day. The most relevant feature of the hyperglycemia decision trees was maxB−1, with an average value of 0,1552. With similar values, there were other features related the blood glucose values of the patient such as µD−1and σB−1 37 Figura 6.1: Average Gini importance of each feature for the three types of decision trees, obtained after processing ten different data sets. 38 Chapter 6. Experimental results Patient Dates Number of patterns Samples ( %) of the pattern with more coverage Impurity of the pattern with more coverage ACN 31/03/16 -14/04/16 2 10,43 % 0 APD 20/06/16 - 04/07/16 0 - - APD 06/07/16 - 20/07/16 2 34,24 % 0 CAA 07/09/16 - 22/09/16 3 30,13 % 0 DPE 20/05/16 - 03/08/16 1 67,66 % 0 DSG 30/01/16 - 30/06/16 3 38,76 % 0 MPA 04/04/16 - 27/04/16 3 50,19 % 0 MPA 25/05/16 - 29/05/16 1 71,08 % 0 SBF 04/04/16 - 08/04/16 0 - - VGO 30/03/16 - 22/06/16 3 24,40 % 0 Table 6.1: Information about the decision trees focused on detecting hyperglycemia patterns. with average values of 0,1395 and 0,1270. The following set of features were not used in any of the trees to describe a pattern: {B, carB−1,∆GD−1, G, GD−1, minB−1, HLM ,MAGED−1, OLB} Regarding the hypoglycemia trees, all of them produced at least one pattern. The maximum coverage of a pattern was 63,38 %, with no impurity. The average of detected patterns 1,8, just as hyperglycemia decision trees. The mean AUC score of the trees was 0,6197, lower than the hyperglycemia trees with a maximum score of 1 and a minimum of 0,2834. The tree that scored the maximum score also was produced by a file with a low number of rows (407). The most relevant feature of the hypoglycemia decision trees was MAGED−1 , with a value of 0,2443. The second and third most importance features were µD−1and minB−1, with average values of 0,1206 and 0,1110. It is relevant the difference between the primary feature and the second most important: the value of the first one is twice as high as the second one. MAGED−1also had the highest value of Gini importance of all the trees, which means that is the most informative feature to describe a pattern (of hyperglycemia in this case). The set of the following features had an average Gini importance of 0: {carB−1, G, GD−1, OLB} The decision trees focused on detecting severe hyperglycemia patterns recognized patterns in seven cases, with a mean of 1,1 patterns, lower than the hyperglycemia and hypoglycemia decision trees. The mean AUC score 6.1. Results discussion 39 Patient Dates Number of patterns Samples ( %) of the pattern with more coverage Impurity of the pattern with more coverage ACN 31/03/16 - 14/04/16 2 25,78 % 0 APD 20/06/16 - 04/07/16 1 63,38 % 0 APD 06/07/16 - 20/07/16 2 17,52 % 0 CAA 07/09/16 - 22/09/16 2 10,42 % 0,1728 DPE 20/05/16 - 03/08/16 3 29,05 % 0 DSG 30/01/16 - 30/06/16 3 35,49 % 0 MPA 04/04/16 - 27/04/16 2 40,36 % 0 MPA 25/05/16 - 29/05/16 1 44,58 % 0 SBF 04/04/16 - 08/04/16 1 58,59 % 0 VGO 30/03/16 - 22/06/16 1 18,62 % 0,1653 Table 6.2: Information about the decision trees focused on detecting hypoglycemia patterns. was close to the hyperglycemia decision trees score (0,6774), with a maximum of 1 and a minimum of 0,4463. The decision tree that scored the maximum AUC used the same data file that the decision tree of hyperglycemia that scored the maximum AUC, which contained the lowest number of rows of all the data files. The average coverage of the patterns was 31,81 %, lower than the other two types of decision trees. The most informative feature of the patterns of severe hyperglycemia was W D, with a value of 0,1865. The second and third features in the ranking were σB−1and ∆tLM with an average Gini importance of 0,1619 and 0,1120. The set of features that were not considered in any of the patterns is the following one: {carB−1,∆GD−1, G, maxD−1, H, OLB} 6.1. Results discussion The coverage results indicated that the patients of the study either were prone to suffer further from hypoglycemia than hyperglycemia or that the hypoglycemia patterns can be described better by the features used by the decision trees. The first theory may follow the intuition that the diabetic patients that decided to participate in this study has a better control of their blood glucose values and therefore, a tendency to keep them low. As it was expected, the coverage of the severe hyperglycemia patterns was lower than the ones produced by the hyperglycemia decision trees. This phenomenon happened because the number of positive cases of severe hy- 40 Chapter 6. Experimental results Patient Dates Number of patterns Samples ( %) of the pattern with more coverage Impurity of the pattern with more coverage ACN 31/03/16 - 14/04/16 0 - - APD 20/06/16 - 04/07/16 2 36,54 % 0 APD 06/07/16 - 20/07/16 1 19,19 % 0,2824 CAA 07/09/16 - 22/09/16 1 10,47 % 0,06479 DPE 20/05/16 - 03/08/16 2 38,00 % 0 DSG 30/01/16 - 30/06/16 2 19,72 % 0,1034 MPA 04/04/16 - 27/04/16 2 34,85 % 0 MPA 25/05/16 - 29/05/16 0 12,85 % 0 SBF 04/04/16 - 08/04/16 1 82,82 % 0 VGO 30/03/16 - 22/06/16 0 - - Table 6.3: Information about the decision trees focused on detecting severe hyperglycemia patterns. perglycemia was a subset of the number of positive labels of hyperglycemia and consequently, their coverage should be lower or equal than the largest hyperglycemia pattern. Furthermore, the results indicated a negative correlation between the number of rows and the AUC score. This negative correlation is more marked in severe hyperglycemia decision trees (-38,51) and can be appreciated in Figure 6.2. A possible explanation for this result may be that the data files with a low number of rows are biased due to their size and the patterns are easier to model than the ones with a higher sample size. Some studies like (Entezari-Maleki et al., 2009) showed that the AUC score of a single data set tends to increase when the sample size is larger. However, in this case, we are comparing the score of decision trees that use data sets of different patients. Thus, the bias produced by the sample size and the quality of the carbohydrates entries has a high impact on the AUC score of the trees. It was no possible to establish a fair comparison between the AUC value of the decision trees of each patient because some variables such as the size of the data set, the number of carbohydrates entries and the number of gaps have a high variance in each of them. This negative correlation may not be a relevant result as the data files were not taken under the same circumstances and the data quality differs in each of them. The analysis of the importance of the features led to several interesting conclusions. The first important result is the fact that hypoglycemia patterns used the glycemic variability of the previous day (MAGE) as the most informative feature. This phenomenon also appears in (Perea et al., 6.1. Results discussion 41 Figura 6.2: AUC score of the different decision trees and the number of rows of the provided data file. 2013), which states that MAGE was the only measure of glycemic variability significantly higher in the group of patients with repeated hypoglycemia. The average Gini importance of MAGED−1in hypoglycemia trees shows a contrast with the value obtained for hyperglycemia trees, where it was not used to do any split, resulting in a Gini importance of 0. This result has multiple possible interpretations, and it is an interesting topic to discuss. My hypothesis about this phenomenon is that patients who suffered a high glycemic variability the previous day tend to over-control their blood glucose values the next day, leading to hypoglycemia situations. Another important result is that it does not exist a strong correlation between the importance of the features of hyperglycemia trees and severe hyperglycemia trees. Whereas the features that provide more information to the hyperglycemia trees were statistics related to blood glucose values, the decision trees focused on severe hyperglycemia used more the variables of time such as the day of the week or the minutes elapsed since the last meal to do their splits. This result may indicate that severe hyperglycemia situations can be more predictable by looking into the variables related to the lifestyle of the patient or the actions that are out of its routine. On the other hand, decision trees focused on detecting hyperglycemia situations should use blood glucose value to detect the risk situations rather than variables of time. 48 Chapter 8. Conclusiones y trabajo futuro es dif´ıcil estimar si los resultados van a ser de utilidad o significativos a etapas tempranas del proceso de desarrollo. Este riesgo es inherente a una aproximaci´on enfocada en los datos porque no siempre contienen toda la informaci´on necesaria para ofrecer un servicio adecuado al usuario final. Esta metodolog´ıa creemos que funcion´o en este proyecto ya que la aplicaci´on final provee un servicio al usuario, situando los datos en el centro de la aplicaci´on. Sin embargo, es posible hacer varias mejoras en la aplicaci´on, las cuales son discutidas en la siguiente secci´on. 8.2. Trabajo futuro Al principio del proyecto quisimos atajar el problema con una t´ecnica de aprendizaje no supervisado y el uso de clustering para detectar los patrones de glucemia. Sin embargo, esta t´ecnica fue replanteada como una tarea de aprendizaje supervisado para tratar de predecir una situaci´on de riesgo futura en los valores de glucosa en sangre del paciente. La idea de dividir cada d´ıa del paciente en bloques, determinados por la ingesta de carbohidratos, puede ser usada para generar nuevas variables y desarrollar una herramienta online predictiva en futuros proyectos. Una limitaci´on de la aplicaci´on es que los patrones no son extra´ıdos en tiempo real, si no que el paciente necesita subir el fichero a la aplicaci´on web para obtener los resultados. Esta limitaci´on tambi´en est´a presente en la aplicaci´on de FreeStyle Libre, que requiere una conexi´on desde el lector a un ordenador a trav´es de un cable USB. Este proyecto ha sugerido una manera de detectar patrones, pero el algoritmo y las variables pueden ser modificadas para convertir el modelo en una poderosa herramienta de predicci´on en tiempo real. Hay varias t´ecnicas de aprendizaje autom´atico basadas en ´arboles de decisi´on que usan m´etodos ensamblados para obtener un mejor rendimiento en t´erminos de predicci´on. Un ejemplo de un clasificador ensamblado son los bosques aleatorios, que usan una multitud de ´arboles de decisi´on, capaces de mitigar la distorsi´on causada por la existencia de ruido en el conjunto de datos o reducir el sobreajuste del modelo. Otro ejemplo de una t´ecnica ensamblada son los modelos gradient boosting basados en ´arboles de decisi´on, que usan dichos ´arboles como modelos de aprendizaje base y distribuyen los pesos para identificar los ´arboles capaces de identificar los patrones m´as complicados. Estos modelos ensamblados tienen un mejor rendimiento que un simple ´arbol de decisi´on, pero reducen la transparencia del modelo. Por este motivo, ellos no cumpl´ıan la restricci´on del proyecto de crear un modelo transparente, y no fueron usados para detectar patrones. Otro proceso que puede ser mejorado es el de ingenier´ıa de factores. La aplicaci´on solo hace uso de variables que est´an disponibles al m´edico o al paciente y le dan la libertad de elegir que variables son las que desea usar 8.2. Trabajo futuro 49 para descubrir nuevos patrones. Si el objetivo del modelo es predecir una situaci´on de riesgo futura usando todas las variables a su disposici´on, decenas de variables pueden ser extra´ıdas de una serie temporal. Adem´as, muchas librer´ıas son capaces de hacer una extracci´on autom´atica de caracter´ısticas de una serie temporal. Un ejemplo de esta librer´ıa es tsfresh, cuyo algoritmo es descrito en (Christ et al., 2016). Esta librer´ıa extrae hasta 100 caracter´ısticas de una serie temporal en paralelo y hace selecci´on de las variables m´as relevantes. Some parts of the code, especially the generation of the report, can speed up by parallelizing its execution. Python has many libraries to make parallel computing like Dask. This library allows optimising an application using dynamic task scheduling and multicore execution. The application could offer a better experience to the patient if the time to generate the report is reduced and this is an excellent opportunity for improvement. Finalmente, usando las caracter´ısticas del conjunto de datos, es posible definir etiquetas alternativas para descubrir nuevos patrones. Dos ejemplos de posibles fen´omenos que pueden ser analizados usando los datos obtenidos de FreeStyle Libre son el fen´omeno del alba y el efecto Somogyi. (Este ´ultimo es bien descrito en (Stephenson y Schernthaner, 1989)). El efecto Somogyi consiste en el aumento de los niveles de glucosa en sangre como una reacci´on del cuerpo a una situaci´on de hipoglucemia nocturna, y que resulta en valores altos de az´ucar por la ma˜nana. El modelo podr´ıa ser adaptado para detectar si el paciente sufre de este efecto y avisarle para que su m´edico pueda proporcionarle alg´un consejo para evitarlo. Appendix A DecisionTreeClassifier example The following code written in Python shows one example of how to use the libraries sklearn and mlxtend to train four decision trees and display the decision areas of the trees. This code has the purpose of studying the effect of varying the maximum depth constraint in the decision areas of each decision tree. The decision trees are trained to predict hyperglycemia and hypoglycemia situations using blood glucose values of the previous and subsequent registers. The resulting plots can be seen in Figure 3.2. from sklearn.tree import DecisionTreeClassifier from sklearn.model_selection import StratifiedShuffleSplit import matplotlib.pyplot as plt import matplotlib.gridspec as gridspec 5from mlxtend.plotting import plot_decision_regions import itertools import pandas as pd # Function that set the thresholds which define the labels 10 def label_map(value): hypoglycemia_threshold = 70 hyperglycemia_threshold = 180 if value > hyperglycemia_threshold: return 0 15 elif value < hypoglycemia_threshold: return 1 else: return 2 20 # Read the FreeStyle data file in CSV format file ="../data/ACN_20160331_20160414_FREE_STYLE.txt" 51 52 Appendix A. DecisionTreeClassifier example raw_data = pd.read_csv(file, header=0, skiprows=1, delimiter="\t", index_col=0, 25 usecols=list(range(0, 9)), parse_dates=['Hora'], decimal=",", date_parser= lambda x: pd.to_datetime( x, format=" %Y/ %m/ %d %H: %M")) 30 # Keep only registers of type 0 (Automatic blood # glucose measurement) data = raw_data[ raw_data["Tipo de registro"] == 0][ 35 ["Hora","Historico glucosa (mg/dL)"] ].set_index( "Hora", drop=True) # Create the input dataset with two columns resulting from 40 # shifting the column of blood glucose values +/- one period X = pd.concat([data.shift(periods=-1),data.shift(periods=1)] ,axis=1).dropna() X.columns = ["Glucose_Minus_15min", "Glucose_Plus_15min"] 45 y = data.loc[X.index].iloc[:,0].apply(label_map) # Create the DecisionTreeClassifier objects with different # max_depth clf1 = DecisionTreeClassifier(criterion='gini', 50 splitter='best', max_depth=1) clf2 = DecisionTreeClassifier(criterion='gini', splitter='best', max_depth=2) clf3 = DecisionTreeClassifier(criterion='gini', splitter='best', max_depth=3) 55 clf4 = DecisionTreeClassifier(criterion='gini', splitter='best', max_depth=4) # Get a stratified sample of training and test examples # (80 % Training - 20 % Test) 60 sss = StratifiedShuffleSplit(n_splits=1, test_size=0.2, random_state=0) train_index, test_index = next(sss.split(X, y)) X_train, X_test = X.iloc[train_index], X.iloc[test_index] y_train, y_test = y.iloc[train_index], y.iloc[test_index] 65 # Plot decision regions of the four decision trees gs = gridspec.GridSpec(2, 2) fig = plt.figure(figsize=(14, 14)) for clf, lab, grd in zip([clf1, clf2, clf3, clf4], 70 ['DT Max. Depth = 1', 'DT Max Depth = 2', 53 'DT Tree Max Depth = 3', 'DT Tree Max Depth = 4'], itertools.product([0, 1],repeat=2)): 75 # Train the decision tree clf.fit(X, y) #Create a subplot withits decision region ax = plt.subplot(gs[grd[0], grd[1]]) 80 fig = plot_decision_regions(X=X.as_matrix(), y=y.as_matrix(), clf=clf, legend=2) plt.title(lab) plt.xlabel('Blood glucose (mg/dL) -15min') 85 plt.ylabel('Blood glucose (mg/dL) +15min') plt.show() Appendix B Report example 55 Report of patterns ACN 31/03/16 - 14/04/16 Hyperglycemia patterns Pattern 1 • Maximum level of glucose of the previous block is lower or equal than 234.5 • Mean level of glucose of the previous block is lower or equal than 145.3 • Maximum level of glucose of the previous day is greater than 192 • Standard deviation of the level of glucose of the previous block is lower or equal than 40.99 • Standard deviation of the level of glucose of the previous day is lower or equal than 40.95 Samples: 210 (10.43%) Impurity: 0 Number of positive samples: 210 (25.93%) Number of negative samples: 0 (0.00%) Pattern 2 • Maximum level of glucose of the previous block is greater than 234.5 Samples: 210 (10.43%) Impurity: 0.2024 Number of positive samples: 186 (22.96%) Number of negative samples: 24 (2.00%) Hypoglycemia patterns Pattern 1 • Maximum level of glucose of the previous block is greater than 139 and is lower or equal than 208.5 • Glycemic variability (MAGE) of the previous day is greater than 81.53 • Mean of the level of glucose of the previous day is lower or equal than 121.1 Samples: 297 (14.75%) Impurity: 0.271 Number of positive samples: 249 (18.11%) Number of negative samples: 48 (7.52%) Pattern 2 • Maximum level of glucose of the previous block is greater than 139 and is lower or equal than 208.5 • Glycemic variability (MAGE) of the previous day is greater than 81.53 • Mean of the level of glucose of the previous day is greater than 121.1 Samples: 519 (25.78%) Impurity: 0 Number of positive samples: 519 (37.75%) Number of negative samples: 0 (0.00%) Decision trees Hyperglycemia Hypoglycemia 64 Appendix C. Examples of decision trees Figura C.1: Decision tree specialised in detecting patterns of hyperglycemia. 65 Figura C.2: Decision tree specialised in detecting patterns of hypoglycemia. 66 Appendix C. Examples of decision trees Figura C.3: Decision tree specialised in detecting patterns of severe hyperglycemia. Bibliography Decision treesscikit-learn 0.18.1. documentation. http: //scikit-learn.org/stable/modules/tree.html# tree-algorithms, 2016. Accessed: 2017-05-06. van der Aalst, W. M. Process mining: data science in action. Springer, 2016. Bailey, T.,Bode, B. W.,Christiansen, M. P.,Klaff, L. J. yAlva, S. The performance and usability of a factory-calibrated flash glucose monitoring system. Diabetes technology & therapeutics, vol. 17(11), p´aginas 787–794, 2015. Breiman, L. Random forests leo breiman and adele cutler. Random ForestsClassification Description, 2015. Christ, M.,Kempa-Liehr, A. W. yFeindt, M. Distributed and parallel time series feature extraction for industrial big data applications. arXiv preprint arXiv:1610.07717, 2016. Diaz Aguilar, P. yM´ ezcua Navarro, S. Manual cto de enfermer´ıa. Tomo I , vol. 4, 2007. Entezari-Maleki, R.,Rezaei, A. yMinaei-Bidgoli, B. Comparison of classification methods based on the type of attributes and sample size. Journal of Convergence Information Technology, vol. 4(3), p´aginas 94– 102, 2009. Fokkert, M.,van Dijk, P.,Edens, M.,Abbes, S.,de Jong, D.,Slingerland, R. yBilo, H. Performance of the freestyle libre flash glucose monitoring system in patients with type 1 and 2 diabetes mellitus. BMJ Open Diabetes Research and Care, vol. 5(1), p´agina e000320, 2017. Hanley, J. A. yMcNeil, B. J. The meaning and use of the area under a receiver operating characteristic (roc) curve. Radiology, vol. 143(1), p´aginas 29–36, 1982. 67 68 BibliograPHY Hart, A. yWyatt, J. Evaluating black-boxes as medical decision aids: issues arising from a study of neural networks. Medical informatics, vol. 15(3), p´aginas 229–236, 1990. Heinemann, L. yFreckmann, G. Cgm versus fgm; or, continuous glucose monitoring is not flash glucose monitoring. 2015. Hernandez, P. A.,Graham, C. H.,Master, L. L. yAlbert, D. L. The effect of sample size and species characteristics on performance of different species distribution modeling methods. Ecography, vol. 29(5), p´aginas 773–785, 2006. Hidalgo, J. I.,Maqueda, E.,Risco-Mart´ ın, J. L.,Cuesta-Infante, A.,Colmenar, J. M. yNobel, J. glucmodel: A monitoring and modeling system for chronic diseases applied to diabetes. Journal of biomedical informatics, vol. 48, p´aginas 183–192, 2014. Kohavi, R. et al. A study of cross-validation and bootstrap for accuracy estimation and model selection. En Ijcai, vol. 14, p´aginas 1137–1145. Stanford, CA, 1995. Lim, T.-S.,Loh, W.-Y. yShih, Y.-S. A comparison of prediction accuracy, complexity, and training time of thirty-three old and new classification algorithms. Machine learning, vol. 40(3), p´aginas 203–228, 2000. Madigan, E. A. yCuret, O. L. A data mining approach in home healthcare: outcomes and service use. BMC health services research, vol. 6(1), p´agina 18, 2006. Mastrototaro, J.,Shin, J.,Marcus, A. ySulur, G. The accuracy and efficacy of real-time continuous glucose monitoring sensor in patients with type 1 diabetes. Diabetes technology & therapeutics, vol. 10(5), p´aginas 385–390, 2008. Monnier, L. yColette, C. Glycemic variability. Diabetes Care, vol. 31(Supplement 2), p´aginas S150–S154, 2008. ISSN 0149-5992. Pedregosa, F.,Varoquaux, G.,Gramfort, A.,Michel, V.,Thirion, B.,Grisel, O.,Blondel, M.,Prettenhofer, P.,Weiss, R.,Dubourg, V.,Vanderplas, J.,Passos, A.,Cournapeau, D.,Brucher, M.,Perrot, M. yDuchesnay, E. Scikit-learn: Machine learning in Python. Journal of Machine Learning Research, vol. 12, p´aginas 2825–2830, 2011. Perea, V.,Amor, A.,Gim´ enez, M.,Blanco, J. yConget, I. Glycemic variability measures in a group of subjects with type 1 diabetes and repeated severe and non-severe hypoglycemia. Journal of diabetes science and technology, vol. 7(1), p´aginas 289–290, 2013. BibliograPHY 69 Pollock, D. Smoothing with cubic splines. 1993. Ribas Ripol, V. Are gini index, entropy or classification error measures causing any difference on decision tree classification? 2013. Rodbard, D. Continuous glucose monitoring: a review of successes, challenges, and opportunities. Diabetes technology & therapeutics, vol. 18(S2), p´aginas S2–3, 2016. Soriguer, F.,Goday, A.,Bosch-Comas, A. et al. Prevalencia de la diabetes mellitus y de las alteraciones del metabolismo de los carbohidratos en espa˜na: estudio di@ bet. es. Diabe tolog´ıa, vol. 55, p´aginas 88–93, 2012. Stephenson, J. M. ySchernthaner, G. Dawn phenomenon and somogyi effect in iddm. Diabetes Care, vol. 12(4), p´aginas 245–251, 1989. Tan, P.-N. et al. Introduction to data mining. Pearson Education India, 2006. Pg. 172. Wiley, M. T. Machine learning for diabetes decision support. Tesis Doctoral, Ohio University, 2011.