Smart Framework for Managing Diabetes Based on Service Oriented Architecture

Modafar Ati, College of Engineering and Computer Science, Abu Dhabi University, United Arab Emirates Modafar.ati@adu.ac.ae
Abstract: Due to the increase of sedentary life style in most of the world and specifically in the region where this research is conducted, led to the raise in chronic diseases that start to emerge in the region. These diseases appear in the form of increase in obesity, heart disease, and diabetes. In order to manage such diseases, a close monitoring to patients is essential in order to control its level. The system that we are proposing in the paper is capable of collecting the data from the patients, analyzing them and suggesting the appropriate diagnosis. Hence, this work advises a system that is capable of reducing the physical access load on healthcare centers via notifying both healthcare provider and patients with the acquired results I.
INTRODUCTION

Wail Omar, Faculty of Computing and Information Technology, Sohar University, Oman w.omar@soharuni.edu.om highlighting the higher prevalence in the native UAE population. As a result, the Ministry of Health in the UAE set the priorities to draw a strategy that aims to increase people awareness as first step to control this chronic disease. The aim of this research is to create a model that is capable of colleting the data remotely from the patient and then predicting the condition based on certain number of factors. Also, the current proposed model is considered as the bases for predicting other diseases as well as other services. Therefore, SOA is used in order to accommodate these services in future work. The paper is structured as background, followed by problem statement and brief description to the model. A motivating scenario of using the proposed model is also shown. Evaluation to the model is presented in section that follows. Conclusion is demonstrated at the end.
II. BACKGROUND

According to World Health Organization (WHO), chronic diseases are diseases of long duration and generally progress slowly [1]. The current living styles has a direct effect on our life which, in turn, appears through increasing the percentage of people who have chronic diseases such as diabetes, blood pressure, heart disease, stroke, cancer, and others. In this work we are focusing on people with diabetes chronic disease. The number of people who have been diagnosed as diabetes is too high; Statistics indicates that such a chronic disease causes approximately 5% of all deaths globally each year. Due to the sedentary lifestyle in the Middle East in recent years led to the increase chronic illness. This increase appeared in the form of increase in obesity, heart diseases, and diabetes in both types 1 and 2. Consequently, great pressure on healthcare providers has been imposed, especially when trying to ensure that structured patient follow up is achieved after each therapeutic change. The research is conducted in the United Arab Emirate ( UAE ) that is the second highest in the entire world as far as diabetes cases are concerned. It is estimated that people suffering from diabetes over the age of 60 is around 40%. While in younger generation and middle age people is 19.6%. This percentage is distributed as 24% among nationals and 17.4% among expatriates,

The advancement in communication and information technologies in recent years has gave the researchers an opportunity to use these technologies in order to resolve problems that are associated with managing and monitoring chronic disease patients. Omar et al[2-4] proposed a semantic framework that provides an intelligent remote health monitoring service via implementing a method of exchanging information between sensors and actuators in an open standard format. Where data can be collected via a request from the health provider as part of a structured patient follow up. This is along with the proposal from Black et al[5], where they proposed an automated remote monitoring system that involves patients proactively in the care of their condition by using spoken dialogue technology. However, the study was limited to only 5 patients. Furthermore, Benny et al[6] proposed the use of pervasive sensing technology and wireless communication in order to create the concept of Body Sensing Networks ( BSN ). However, the latter

proposed system has not been implemented for chronic patients monitoring. Baiet al[7] suggested the building of web-based services information system to aid the activities in diabetic healthcare. Two groups were recognized; healthcare receivers (patients) and various care providers. Mobilenetwork communication platform for homecare supervision used for preparation prior to face to face diagnoses. Web applications were also used for delivering worthwhile health care services to chronic diseases patients. These web applications were developed in order to support patients in self-managing their diabetes via monitoring their health as well as communicating with their healthcare providers[8].
III. PROBLEM STATEMENT

One of the essential ways of controlling any chronic disease is via keeping the factors that are affecting the patients at least within the allowed threshold. However, any variation of these factors requires measures that need to be put in place in order to bring these factors as near as possible to the accepted level. Due to the increase of number of patients in recent years a continuous monitoring to patients physically would be extremely difficult and requires a clear strategy to lay out clearly the appropriate infrastructure. However, proposing a new method of delivering the appropriate services to chronic disease patients that, in turn, contribute to easing the pressure on healthcare centers is essential. As a result, we are proposing a system that is able to collect the medical readings remotely according to either schedule time or on demand, save the readings in patient's profile (which is part of the Patient Health Record), analyze the data and then propose a feedback to patient as well as healthcare centers. Thus, the system should be smart enough to propose the appropriate diagnose to the collected medical readings.
IV. MODEL

chronic diseases ( diabetes in this instance ), yet the model architecture was developed to serve other services that will be used for future expansion for the proposed model. It is intended during the design of the model that it will be used to provide other services as well as the current ones. The model that we are proposing is classified into two parts; Human-Resources Interaction that has the responsibility of enabling the users to interact with all system resources, while the second part is responsible for controlling the security, managing the system and offering ontology for assisting in exchanging information between the layers and the system in an open standard format. This arrangement is done in order to make sure that the model offers as well as the above features, it offers transparency, interoperability, openness, portability, flexibility and extensibility. Each of the two parts consists of separate layers that are communicating in a hierarchical arrangement. Humanresources part is refined into five layers; Resource, Resource Management System, Control System, Support Functions, and Log Management and Intelligence Layers. System management part, on the other hand, is formed from three layers; Security, Management, and Knowledge System layers. These arrangements are shown in figure 1.

In this research work, healthcare applications were implemented as services to the users ( patients and physicians with different degree of accessibility ) rather than in case of static applications. This, consequently, requires that the model as well as the services to be generic rather than static as in client/server applications. As such, service oriented architecture ( SOA ) was the natural choice to be used that offers a generic model for healthcare framework for the purpose of deploying and integrating these services in an open standard format. Even though the present work concentrates on creating a management system that is used to monitor patients with

Fig. 1: Health Management Model

Fig. 2: Resource Management Layer

Each of the above layers is further refined to separate sub-categories and services. Resource layer (RL) consists of three main components; Services, Computational, and Data Process. These components consist of varieties of sub-components such as service type, infrastructure, communication systems, monitoring resources, and controlling facilities. Components of each layer are interlinked together to form cohesive layers and well robust model. Each of these components has a specific task that contributes to the overall components in the layer as well as to the system as a whole. Service Resources component contains all the services and applications that offer services to the customer. Even though that currently, this component offers patient monitoring services only, it can include healthcare services [3], financial services [4], as well as other services that need to be added to the system as part of its functionality. The computational component includes all resources that needed for processing tasks that are requested from the services recourses component, or other services that are demanded by the user. The Data Process component consists of all the storage system and the access methods to the storage data. Due to the fact that this component contains both the data and accessibility functions to these data, then processing services are added as part of this functionality such as data mining. All of the layers of the human interaction system are arranged hierarchically in such a way that each layer has certain protocols responsible for making sure that the data travel in both directions efficiently. Each layer has protocols that are responsible for translating information that are received from both upper and lower layers. When a protocol receives information from an upper layer, it usually simplifies the information/requests and makes them more specific as they travel downwards. The Resource Management layer ( RML ) is proposed in order to enhance the functionality of the resource layer (RL) via enhancing the manageability and fidelity of selecting the appropriate resources. One of the major responsibilities of the RM is classifying the resources that are deployed by the service provider according to the nature, functionality, and behavior of resources. Hence, the protocols that are associated with this layer serve two main purposes; one that receives requests from upper layer and that communicate with the lower layer in order to send the appropriate requests. The formers main functionality is receiving the request, analyzing it in order to obtain those services that match the requests. Therefore, there are three main components that are

sought essential to achieve such a task, these are; classification for classifying resources, prediction for predicting the category of resources that are requested from upper layers, and finally reasoning for understanding the requests and interact according to it With the intention of ensuring that the services that are delivered by the system to all participant are achieved in a timely manner, then the control layer ( CL ) was included in the model. The main aim and responsibility of this layer is to manage the resources that are found in the resource layer( RL ). This is done via offering a high reliability, Quality of Service ( QoS ), availability as well as maintainability. Hence, to make sure that this layer has the capability of delivering all of the tasks that are designed for, then a number of tools and services should be included in the model. Some of these tools are replication, fault tolerance, load balancing, mirroring . . . etc. There are a number of resources that the users have the ability to access via interacting with the system. In order to coordinate and execute these resources reliably and proficiently, the need for a layer that is capable of managing the processes of deploying, discovering, and then invoking these resources is fundamental. Due to the fact that this layers primary task is to support and coordinate the different resources that are available in the system, thus Support Functions Layer (SFL ) is used to refer to it. Main responsibilities of the different functions that are contained in this layer can be summarized as; Deploy function that have the responsibility of coordinating the deployment of the resources from providers to resources containers that are located in the resources layer, Discovery function has the task ( as the name indicates ) of managing the process of discovering the different resources that are requested by the users, and finally Invoke function that controls and then advices on the way of accessing the resources in the lower layers. Log management and intelligence layer (LMI) is responsible for dealing with the users (doctors and patients) via presenting the data in different forms. Furthermore, this layer should have the ability to monitor the users medical activities and record them in a history log that is used as input to the management and knowledge layers for further processes such as categorizations, predictions, and other activities that the system is configured to deal with. The user layer ( UL ) represents the consumers as well as applications of the healthcare framework. In this model, the user usually interact with the system in order to

improve the operation of the framework through providing the system with experiences, arguments (rules), services specification and other information assists in reconfiguring the framework to give better services. Plus this active user would feed the whole system with a very vital and important ingredient, the Data that would be the main engine to the smart healthcare system. System Management subsystem consists mainly of three layers; security, management, and knowledge system layers. All of these layers are responsible for ensuring the smoothness operation of the system as well as protecting the system. Other functionalities that are associated with ensuring the integrity of the model are part of this subsystems functionalities. To protect the system, a security layer is added to the model and integrated with other layers of the model. The main aims of the security layer is to validate the authorization of users trying to access the system as the first step, then checking the Service Level of Agreement (SLA) in support function layer. The SLA is required to control and protect the users who have the right and privilege for deploying and using resources from those who do not have such privileges. A file system is proposed to be used to record the authority and SLAs for different users, and an encryption mechanism can be very useful to encrypt these files and protected them against sniffing and vandalizing activities. The security at the control layer is to manage the administrator access to control services. At the end, security at the resources layer is to protect the layer from the different types of attacks from outside or inside which can be implemented in sourced or outsourced security systems (virus protection, worms protection applications, etc). The management layer works in corporation with all layers of the model for managing the healthcare system. This layer consists of numbers of capabilities working together for managing the framework. Such capabilities are framework configuration, optimization, adaption, healing, protection, organizing, and others which assist in improving the operational framework and moving it to on demand framework [3]. All these capabilities should be selected, executed, blocked and destroyed in an automated way. Therefore, autonomic computing [4, 5] is proposed to be used in this case for implementing the self management task. Different services and infrastructures from resources layer will be used in this layer, such as monitoring system, intelligent services (for planning), effectors, and others.

The knowledge layer in this model is proposed to offer wealthy information to all layers of the system that would assists in efficient usage of the framework. This layer should be attached to all layers of the system for gathering and providing information to each one of them. For example, this layer should collect and provide information regarding the available control services to control layer, the security policies and SLA to security layer, user information, experiences to user interface layer, classification and prediction service to resources management layer, and the available sensors, actuators, loggers and other monitoring resources to the monitoring system,. Furthermore, this layer assists the user in selecting the healthcare services from resources layer based on the information provided by resources management. Because this layer is involved with all layers, it should use an open standard format that can be readable and understandable by all components. So the existence of such layer would offer a storage and retrieval mechanism for all layers in the framework, and this would facilitate the process of information exchange between layers (not necessarily contiguous layers) in a great way, also it can be a backup for the information found in each layer which will add a precious amount of robustness to the whole system. Obviously a huge amount of data will have to be stored in some way, and this way can be achieved through utilizing the data grid.
V. MOTIVATING SCENARIO

In order to use the system efficiently, there is a need to build an accurate skeleton model that is accurate enough to model all factors required to model diabetes patients. This followed by populating the model with real life data, and then trains the system with the assistance of an expert opinion. Health service providers usually define the data that are required to be collected from the patients, which is usually similar to those collected from patient during medical checkups visit and laboratory tests. The parameters that are used for training the model in this research includes; age, sex, history of heart disease, BMI, SBP, DBP,Hb1Ac, HDL, LDL, Trig, urea level, . . . etc. By providing such parameters, the medical schema is then created and the model is ready for training. Following the creation of the skeleton model and populating it with a bulk of data, the model would be ready for training. Training the system can be achieved via applying different techniques including: SVM, machine learning and data mining techniques. These techniques are usually used along with initial classifications and categorizations to the different cases

that are provided as part of the training data. The quality and quantity of data contribute greatly to the adequacy of the operational system. During the training stage, physicians play a vital role for correcting the diagnoses whenever appropriate in order to align diagnoses with real life cases. By doing so, the system will start to have more data coming in as well as diagnosis are provided by physician which increase the reliability of the system. At some stage, the physicians role would move from being diagnosing the cases to monitoring role. The management system proposed in this paper is an on demand system that reacts to the hospitals stipulate. This management system is usually instigated via issuing a request by the health provider to invoke the appropriate sensor that is located at the patient side to collect target data. The data received are inspected by the previously trained model in order to diagnose the case based on both the readings and the categorization method used to train the system at the initial stages. It then saves the results into the patient health record along with timestamp that serves for patient condition monitoring over a period of time. The system would then predict the outcome based on these data and inform both the patient and the health provider of the predicated condition. Figure 3 highlights the activities that are stated above.

<?xml version="1.0" encoding="utf-8" ?> <DiabetesSchema> <Patient ID=""> <Socio_demographic_variables> <Age></Age> <Gender></Gender> <Marital_Status></Marital_Status> <Job_Status></Job_Status> <Education></Education> <Ethnicity></Ethnicity> <Address></Address> <Telephone></Telephone> </Socio_demographic_variables> <Risk_Factor> <Smoking_history></Smoking_history> <Years_of_Smoking></Years_of_Smoking> <Used_Cigar></Used_Cigar> <Family_History_of_Diabetes></Family_History_of_Diabetes> <Women> <History_of_Pregnancy></History_of_Pregnancy> <Gestational_Diabetes></Gestational_Diabetes> </Women> </Risk_Factor> <Laboratory_Data> <BMI></BMI> <SBP></SBP> <DBP></DBP> <SBP1></SBP1> <DBP1></DBP1> <HRREST></HRREST> <FBS></FBS> <PPS></PPS> <HBA1C></HBA1C> <TRIG></TRIG> <HDLC></HDLC> <LDLC></LDLC> </Laboratory_Data> <Diagnose></Diagnose> </ Patient ID > <//DiabetesSchema> Fig. 4. XML Database Schema

VII.

TRAINING DATA AND RESULTS

Fig. 3. System Scenario

VI.

DIABETES SCHEMA

The schema is considered as prototype for defining the required information, training system, and collecting data. The schema is designed based on the required information from health authority in the UAE. The schema is divided into six main categories, which are general information, risk factors, laboratory data, physical examination data, and chemistry examination data. Figure 4 shows part of the schema used for diabetes model.

The schema used in this research is based on the information that are required by the health authority in the UAE. The schema is divided into a number of categories that were stated previously along with the main factors that are required for each category, such as the laboratory data stated above. There are different techniques that can be used in machine learning that provide the system with the prediction process that is needed as part of the diagnosing process. In this work we implemented Weka[10] for prediction. However, different types of machine learning are needed to be tested in order to find the most appropriate model for serving our purpose. The listing below highlights some of the attributes and data that are used in the process of training the model. It must be stated that the last attribute as well the last data value of each patients data refers to the diagnose for that patient. At the first stage physicians are usually derive

this value based on the data attributes, which are then fed to Weka in order to train and test the system. The diagnose attribute used in our model is represented as a numerical value between 1 and 10, where 1 indicates healthy patient while 10 indicates that the condition of the patient is critical and an urgent attention is needed. The scale of 10 is selected to give more option to the system to classify monitored cases. Values between these two ends indicate different conditions ranges from being Very Good, Fair, and Very Bad. Following training the system, a total number of 300 patients were tested using the proposed system, table 1 shows the absolute residual between physician diagnose and that predicted by the system along with number of patients with each residual level. It can be seen that maximum residual is around |0.4| with around 21% of predictions were identical to physicians diagnoses. Number of training data used for training was 842 cases.
Residual No of Diagnoses % 0.4 21 7% 0.35 23 8% 0.3 32 11% 0.25 30 10% 0.2 43 14% 0.15 25 8% 0.1 27 9% 0.05 38 13% 0.0025 63 21% Table 1 : Residual vs. number of patients

provider are notified of the condition of the patient following the collection and analyzing of data. Comparisons between physicians diagnoses and that produced by the system were demonstrated and the results shown were very promising. However, different techniques need to be tested in order to choose the most appropriate techniques that suit our model. At this stage, the model proposed here is adequate and can be implemented for diagnosing and monitoring patients in the region of interest.

REFERENCES
1. 2. WHO. http://www.who.int/diabetes. W. Omar, A. Taleb-Bendiab, E-Health Support Services Based On Service Oriented Architecture. IEEE IT Professional, 2006. 8(2): p. 35-41. 3. W. Omar, B. Ahmad, A. Taleb-Bendiab. Grid Overlay For Remote E-Health Monitoring. in 4th ACS/IEEE International Conference on Computer Systems and Applications (AICCSA-06). 2006: IEEE Computer Society. 4. W. Omar, A. Abbas, A. Taleb-bindiab, SOAW2 For Web2 Framework. IEEE IT Professional, 2007. 9(3): p. 30-35. 5. L.A. Black, M. McTear, N. Black, R. Harper , M. Lemon. Appraisal of a Conversational Artefact and its Utility in Remote Patient Monitoring. in 18th IEEE International Symposium on Computer Based Medical Systems. 2005. Dublin, Ireland. 6. Benny P.L. Lo, Guang-Zhong Yang. Body Sensor Networks: Infrastructure for Life Science Sensing Research. in Life Science Systems and Applications Workshop. 2006. Bethesda, MD, USA. 7. Guohua Bai, Peng Zhang, Developing a Semantic Web Services for Interoperability in Diabetic Healthcare, in IEEE Conference on service systems and service management. 2005: Chong Qing, Chine. 8. Nicol Nijland, Erwin R. Seydel, Julia E.W.C. van GemertPijnen, Bart Brandenburg, Saskia M. Kelders, Marijke Will Evaluation of an Internet-based application for supporting self-care of patients with diabetes mellitus type 2. in eTelemed. 2009. Mexico: IEEE Computer Society. 9. W. Omar, A. Taleb-Bindiab. Service Oriented Architecture for E-health Support Services Based on Grid Computing Over. in IEEE International Conference on Services Computing 2006. Chicago , USA. 10. Mark Hall, Eibe Frank, Geoffrey Holmes, Bernhard Pfahringer, Peter Reutemann, Ian H. Witten, The WEKA Data Mining Software: An Update. SIGKDD Explorations, 2009. 11(1)

Fig. 5 : Residual VS. Percentage of patients VIII. CONCLUSIONS

In this work a smart framework for managing patients with diabetes has been developed and is able to collect medical readings from patients. Data received are analyzed based on a proposed medical schema from the healthcare provider. Both patient and healthcare