## 4 Towards a Complete Solution by Means of an ICT Structure  
In this section, the structure of an IoT platform that is aimed at managing diabetes, modeled in layers where different technological issues are arranged, is presented as a summary of the present work. This structure can also be found in several areas, such as energy savings in buildings or smart services in cities [54], but has not been employed in a diabetes management system up to now. Therefore, as shown in Figure 1, the configuration of an integral diabetes management platform should be built as follows:  
* Biological substrate. This is the layer where the patient is located. His or her physical changes, reflected in skin, blood, movement, and so on, will be disaggregated as variables to be measured. This layer is where the inception of the data occurs, where it is generated, and, finally, where the system's outputs will actuate (via therapeutic decisions). * Sensorization layer. Input data are acquired from a plethora of sensors, all of them connected to an IoT framework. Sensors can be configured and controlled remotely through the Internet, enabling a variety of monitoring applications and creating a technological structure. * Communication layer. This tier allows for data permeation until the next stage. All of the sensors must support several communication channels in order to connect easily. Avoiding direct input/output (I/O) through regular wiring, Wi-Fi, 4G, ZigBee (or 6 LowPAN), and Bluetooth connections need to be available to support direct access to sensors, mainly via another smart device (smartphone, tablet) used as a gateway, following an IoT approach. All of the elements are connected to each other by using a little Local Area Network (LAN), and, likewise, to a smartphone (or the cloud). * Middleware layer. Given the heterogeneity of data sources and the necessity of a seamless integration of devices and networks covered by the sensors and communication layer of our architecture, a middleware mediator is needed to deal with this task. Therefore, the transformation of the collected data from the different data sources into a common language representation is performed in the middleware layer. As mentioned before, HL7 is a proper candidate to deal with this task. The ontology implemented to represent the knowledge of the bloodstream glucose level clearly follows a user-centric approach, which takes into account all of the information characterizing the situations, the devices and their status, and the patient himself of herself. * Computing and management layer. In this layer, data collected are handled in order to carry out a data analysis, obtain a glucose prediction, and chose an optimal therapeutic solution. Here, is where a data-processing center and modeling core are placed. Pervasive computing has to be done on two levels: one local, in the smartphone, and another in the cloud. In this way, it is possible to avoid the risk of lack of connection to the Internet or battery failure. Data harvested are sent, via LAN, to a smartphone, or maybe, in some circumstances (e.g., the absence of a smartphone), directly from the sensors to the cloud, if it is provided. Therefore, ubiquitous computing allows for a powerful and safe way to address the problem. * Display layer (interface). Access to the system will be via browser. Thus, the parameters can be adjusted either by a smartphone or by a computer, local, or external, which is close to the patient or remote for healthcare staff. Data collected are also accessible, as well as statistics and the general status of the glycemia control system. It should be noted that the previous layer must have reached a blood glucose (BG) prediction and an optimized solution of insulin input, and this can be shown to the user either for information only or to await confirmation or variation. * Outputs. With the goal of integral management, the platform, thanks to all of the data collected and available resources, needs to be ready to cover the following exposed requirements.