Ontological MobiHealth System

ABSTRACT


INTRODUCTION
Introduction of networking technologies has resulted in the emergence of a new field in E-health, known as mobile health (m-Health). "MobiHealth [1] systems are tele-monitoring systems based on BAN (Body Area Network) and mobile health care (m-health) service platform utilizing next generation public wireless networks" [1]. Smart phone applications have self-monitoring and sensing capabilities and are used in health interventions and disease prevention. Mobile patient monitoring is an m-Health service for the assessment of mobile biosignals [2], which are periodically or continuously monitored. Some biosignals include electroencephalograms (EEG), galvanic skin responses (GSR), electrocardiograms (ECG), and MagnetoEncephaloGram (MEG). By using the measured biosignals, we can determine other parameters, including heart rate variability (HRV) [2]. M-Health applications perform patient alarms, E-prescriptions, automatic tracking, and mobile patient monitoring [2]. In this study, a prototype mobile sensing platform was introduced for m-Health and telemedicine applications, which medical sensors on patient body reports biological signals and environmental sensors send environment raw data to base station (smart phone). Then raw data were preprocessed and necessary features (situations) were extracted. In order to context computation and respond with adaptability, we have used ontology-based model. Some used situations in this system are activity, blood pressure, body temperature, ratio of oxygen in the blood (SpO2), and ECG features, which are extracted from normal sinus rhythm for a human heart, as seen on ECG (e.g., HR, P, Q, R, S, P-R, QRS, S-T, and QT).

THE MAIN MODELS FOR CONTEXT INFORMATION
There are three main models:

Object-role-based models
Object-role-based is one the main modality approaches to databases using a context modeling language which is introduced by Henricksen [2], [3]. It describes an atomic context using a flat information model, but it ignores the importance and priority of context atoms, such as location [3]. Henricksen et al. [3] are working to update their model to be a hierarchical model to encompass the heterogeneity of a contextaware system. In a context-aware location-based application, space (i.e. location) is considered as one of the most important factors [3].

Spatial models
Spatial models are fact-based models that organize environmental entities to derive the user's location. The location data relate either to the location of entities in the physical world or to nonphysical entities such as virtual notes left on Google maps [3]. The location information is measured using the global positioning system and triangulation methods [4]. It indicates the longitude and latitude of a mobile object by an error of only a few meters. Location can also be measured or predicted imprecisely using inertial sensors, device cell ID or Wi-Fi access point ID [3]. Heterogeneous context information, such as environmental and user's physiological data, is considered as a form of knowledge whose attributes can be defined in the ontology. Therefore, reasoning and inferring can be carried out on the context knowledge [3].

Ontology-based models
Ontology-based models have the advantages of describing heterogeneous environments and their relationships based on a hierarchical model of a domain of knowledge using graphical software programs such as "protégé [5]" through the OWL-DL language. However, the ontology model does not support the timelines and mobility attributes that correspond to the any-time any-where availability of a context-aware system [3]. On the basis of the above-mentioned points, it appears necessary to provide a hybrid version of spatial and ontology models. Once the ontology and spatial data are combined, advantages such as mobility and timeliness are added to the other advantages of an ontology-based model [3].

DESIGN AND IMPLEMENTATION
This framework has three modules:  Data collection (WBAN)  Extraction of context situations and creating a dynamic ontology with the OWL language  Diction making: Rule programming and alarm management on smart phones; we programmed this module with java for android operating systems (smart phones). The conceptual model of a context-aware mobile patient monitoring framework is illustrated in Figure 1.

Data collection
A back-end system (BESys) and body area networks (BANs) comprise a mobile patient monitoring system. Every BAN is characterized by a controlling entity, called "base station", which collects and processes information. In BAN, the sensors regularly communicate information to the base station (i.e., smart phones in this study). Therefore, BANs have different applications, including postoperative care, sports health management, and home-based care for the elderly [5], [6]. In this research, three types of sensors were used as follows: (1) physiological sensors for vital signs, such as ECG, PPG, and SPO2; (2) motion detection sensors for situations such as accelerometer; (3) environmental sensors such as CO, O2, temperature, and humidity. Low-level sensor data are transmitted to a base station (a cell phone with an android operating system is used in this project). The initial processing is performed on the base station, and the data are transmitted to the server for storage. In fact, data modeling is utilized on the server for better context description, and context reasoning is performed for the activities of an individual and for being used in context-aware applications in the base station.

Extraction of context situations
The raw data directly acquired from the sensors are changed continuously. This leads to limitations in human interaction modeling, context reasoning, and interpretation. Therefore, instead of using low-level data, perception and situation concepts from the sensor are used. The term "situation" refers to a higher-level concept for representation of a state [7]. It was first used in 1980 in linguistic and semantic sciences [7]. Situations are the "semantic abstraction" [7] of low-level data, human knowledge, and interpretation, which are integrated in one model and are labeled using human definitions.
Considering the level of abstraction [9], the context data are classified into 3 layers: context atom, sensor, and context situation layers. The context atom layer is an abstraction between semantic and physical worlds (fusing context atoms), the sensor layer represents a source of context information, and finally, the context situation layer describes complex facts.
(1) Sensor data: S refers to the sensor layer output: (1) where St,i refers to the output of sensor i at time t, Vt represents the sensor i value at time t, and qi represents its credibility.
(2) Context atom: A denotes the atom set: (2) where At,i represents a semantic element from sensor i at time t, and Γ shows assertion by the sensor information using ontology technology, not divided into smaller assertions.
(3) Context situation: C describes the situation set: An entity's current state is represented by a context situation. A situation is characterized by the set of atoms (Ai constitutes). Seri refers to the set of services in this situation (it can be null), and pi describes the situation priority for safety (more than entertainment) [5]. The external semantic interpretations of low-level contexts describe situations. Besides adding meaning to applications, these situations are more stable and simpler to define and sustain in comparison with low-level data. By using these situations, applications are more easily implemented and designed, since the programmer or designer operates with high abstraction on context cues creating the situation.
In this framework, situations based on WBAN data are activity, blood pressure, body temperature, ratio of oxygen in the blood (SpO2), and ECG features, which are extracted from normal sinus rhythm for a human heart, as seen on ECG (e.g., HR, P, Q, R, S, P-R, QRS, S-T, and QT). The ECG features and heart signals are illustrated in Figure 2.
Therefore, there are two main types of ontology: 1) person ontology, and 2) health ontology. These ontologies are shown in Figure 3. The ontological diagrams for environment, health and activity are depicted in Figures 4, 5, and 6.
Ontologies are built based on ontology diagrams using protégé tool [4], which presents a graphic user interface for developing and managing the ontology architecture. Therefore, for more reasoning, it can convert files into the OWL format [7]. In order to obtain temporal data, we used additional classes including intervals and instances. Furthermore, time slice and time interval classes were defined in relation to the temporal entity. Using ontology for context modeling, logical reasoning is possible. A method of context reasoning is used to infer implicit high-level contexts from explicit low-level ones. Some rules (e.g., predefined rules) are defined in ontological reasoning. In this project, pellet reasoner [10] was installed and run.   A protégé tool was applied to build this ontology and to create some instances in the framework. Protégé is an ontology-editing tool, providing a graphical user interface for users to easily create and manage the ontology architecture. So, for further reasoning, using this tool helps to export files in an OWL format [7]. implemented an ontology provided in Figure 7.
As it can be seen in the Figure 7, in order to achieve temporal data, we have used additional classes including intervals and instances. Furthermore, time slice and time interval classes are defined in relation to the Temporal Entity. Object property is also defined with an object property tab. To have a good characterization, every object property must be defined. An example is "after Inverse of before". In next step, the individuals were defined. Generally, individuals are representatives of ontology. They are shown in Figure 8. The overall view of ontology (classes, properties, individuals) is shown in Figure 9. A graphic display of context-aware ontology is also illustrated in Figure 10.

Decision-making
In the next step of implementing ontology, the collected data on environmental, biosignals, and activity features were analyzed at the base station (i.e., a smart phone) and compared with the thresholds. If necessary, an appropriate response was provided to the situation. There are four types of alarms, as shown in Figure 11 and an alarm management diagram is shown in Figure 12. It is worth mentioning that there is a medium risk, but if patients do not send ACK (SMS), it is considered a high risk [10]. We programmed this module with java for android operating systems. Some of our programming for sending SMS is illustrated in Table 1 and Table 2. Some android manifest codes for sending SMS are shown in Table 1, and android activity codes are presented in Table 2.

EVALUATION
This framework is evaluated by three scenarios, based on Table 3. Scenario 1: The patient is sitting in a sitting room, and QRS of ECG signal is more than 120. According to Tables 1 and 2, the patient needs emergency help. Scenario 2: The patient"s activity is running, although blood pressure is higher than 140, the situation is normal. Scenario 3: The patient is sitting in a sitting room. The spo 2 value is less than 60%, and the patient"s activity has declined. Automatically, the system sends an SMS and requests for acknowledgement. If it receives an acknowledgement from the patient, the situation is normal; otherwise, emergency help is needed. On the other hand, pellet reasoner is used to check integrity and consistency of ontology. Moreover, three experts evaluated this ontology.

CONCLUSION
In this research, we introduced a context-aware mobile application for patient monitoring at home. This framework has three steps. First, we collected physiological, activity, and environmental data using WBAN. In the next step, we extracted context situations from raw data and created a dynamic ontology with OWL language. In this research, context situations include activity, blood pressure, body temperature, ratio of oxygen in blood (SpO 2 ) and ECG features, which are extracted from normal sinus rhythm for a human heart on ECG (e.g., HR, P, Q, R, S, P-R, QRS, S-T, and QT). In the third step, we programmed rules and alarm management using java code for android operating systems (smart phones). Finally, this framework was evaluated in three scenarios.