Ahlem Rhayem
email: ahlemrhayem@gmail.com

Mohamed Ben

Ahmed Mhiri

| Khalil Drira

| Said Tazi

| Faiez Gargouri

A semantic-enabled and Context-aware Monitoring System for the Internet of Medical Things

Keywords: Medical Connected Objects, Patient monitoring, Ontology, Context-awareness Ahlem Rhayem ET AL

The emergence of the Internet of Things (IoT) in the medical field has led to a myriad of medical connected objects (MCOs). These MCOs are being developed and implemented for remote healthcare monitoring purposes (elderly patient with chronic diseases, pregnant woman, patients with disabilities). Accordingly, different associated challenges are emerging and include the heterogeneity of the gathered health data from these MCOs with ever-changing contexts. These contexts are relative to the continuous change of constraints and requirements of the MCOs deployment (time, location, state). Other contexts are related to the patient (medical record, state, age, sex, and so on) that should be taken into account to ensure a more precise and appropriate treatment of the patient. These challenges are difficult to address due to the absence of a reference model for describing the health data and their sources and linking this data with their contexts. This paper addresses this problem and introduces a semantic-based context-aware system (IoT Medicare system) for patient monitoring with MCOs. In fact, this system is based on a core domain ontology (HealthIoT-O) that is designed to describe the semantic of heterogeneous MCOs and their data. Moreover, an efficient interpretation and management of this knowledge in diverse contexts are ensured through SWRL rules such as the verification of the proper functioning of the MCOs and the analysis of the health data for diagnosis and treatment purposes.

A case study of gestational diabetes disease management is proposed to evaluate the effectiveness of the implemented IoT Medicare system. An evaluation phase is provided and focuses on the quality of the elaborated semantic model and the performance of the system.

INTRODUCTION

It has been revealed that IoT enables seamless communication between diverse devices and objects and helps people to interact continuously with them to establish a large connected network. The IoT is widely applied especially in the healthcare domain. According to [START_REF] Cai | Iot-based configurable information service platform for product lifecycle management[END_REF] Fernandez and Pallis (2014) medical care and health care stand as one of the most attractive application areas for the IoT.

Referring to the association of important R&D direction, the IoT with the medical sector applications gave birth to an Internet of Medical Things (IoMT)1 . According to [START_REF] Gatouillat | Internet of medical things: A review of recent contributions dealing with cyber-physical systems in medicine[END_REF], IoMT designates the interconnection of communication-enabled medical-grade devices and their integration to wider-scale health networks in order to improve patients' health. This harmonious relationship paves the way of various intelligent services such as diagnoses and prevention of illness, decision support for appropriate treatment for patients, and remote patient

• Evaluating the semantic quality of the proposed knowledge base (HealthIoT ontology) based on the OQUARE frameworkDuque-Ramos et al. (2014). In addition, we aim to assess the performance of our system in terms of precision, recall, f-measure and response time.

The rest of this paper is organized as follows: Section 2 describes our proposed use case about gestational diabetes monitoring. Section 3 provides an overview about IoMT systems and the semantic representation in this domain. Section 4 highlights our semantic-based context-aware architecture, which is composed of four main phases: the data collection and preprocessing, the semantic modeling, the analysis, and the implementation phases.

These phases are described in Section 5, 6, 7 and 8 respectively. The evaluation of our approach is illustrated in Section 9 based on technical and functional levels and a comparison with existing approaches. Finally, section 10 draws our conclusion and suggests some future perspectives.

USE CASE: GESTATIONAL DIABETES MONITORING

Gestational Diabetes is a disease that should be continuously monitored in order to follow its evolution and make an adequate decision according to its behavior. In this context, a pregnant woman needs to communicate and to share her glucose level with the medical staff, receive notification from them, accelerate their intervention in difficult cases. On the other hand, medical staff needs easy access to the patient's data to interpret them and suggest the appropriate treatment. To alleviate these challenges, the medical sector adopts IoT technology. Thereby, various researchers [START_REF] Cappon | Wearable continuous glucose monitoring sensors: A revolution in diabetes treatment[END_REF] [START_REF] Kim | Wearable non-invasive epidermal glucose sensors: A review[END_REF] [START_REF] Wang | Recent developments in blood glucose sensors[END_REF] have implemented diverse

MCOs to monitor the state of a pregnant woman. These MCOs contains diverse sensors to detect the patient's blood glucose, heartbeat, blood pressure, etc. These objects are heterogeneous in terms of deployment contexts, computing capabilities, and communication protocols. They generate a huge amount of heterogeneous and ambiguous data that describe various cases. The health data represents the state of the patient and technical data concerning the state of the medical objects. They generate a huge amount of heterogeneous and ambiguous data that describe various cases. The health data represents patients' states while technical data shows the states of medical objects. Moreover, this amount of data, including semantic heterogeneity (synonymy, antonyms, polysemy, etc.), keeps growing. This numeric information can be badly understood and exploited by users. For instance, if the blood glucose sensor value reaches200, doctors in this case will need further details to understand that this value refers

to the blood glucose level of an ordinary diabetic patient or a pregnant woman that equals to 200 mg/dl. Consequently, information related to the context of the obtained measurements (source, the type of measurement, unit, patient's personal information, time of detection, location and so on) are primordial in both analysis and treatment phases within a reasonable period.

Both doctors and patients use connected objects that are designed by different manufacturers (Google, IBM, Nokia, etc). Accordingly, the generated data has different coding formats leading to a complex data exchange task.

In the same vein, technical data is incredibly important to configure and manage the state of the used object in order to repair any functional breakup.

Assuming that the MCO of a pregnant woman fails (discharged battery, ending lifetime, broken connection), the medical staff encounters a big challenge to remotelymonitor their patient. In this case, these devices should be replaced with anotherof the same type (e.g. blood glucose sensor should not be replaced with a temperature sensor). Hence, the monitoring task will be assigned to the new available object to perform this new task. Indeed, this object should be connected to the internet. Therefore, in indoor environments, the object can be connected to the home gateway as the patient stays at home. In outdoor environments, however, the object can be connected to the internet via the 4G wireless network. In this respect, verifying the connectivity and availability of this object is a vital stepbefore assigning the new task. Besides, testing the MCOs mobility can determine the location of the pregnant woman and consequently facilitate the intervention of healthcare professionals in any emergency case. As a result, treating information about the crossed trajectory is vital to track the MCO mobility. Once the state of the object is reliable, doctors are able to treat and diagnose patients' states. First, the validity of the obtained blood glucose level for possible treatment should be checked. Diagnosing the blood glucose level during a predefined time interval helps avoid adverse events, like fainting and dyspnea. Second, doctors will diagnose blood glucose values in pregnancy. Thus, they are permanently diagnosed during the second and third semesters of pregnancy. These values can be recognized based on one of these two different glucose tests. The Fasting Plasma Glucose (FPG) should be between 92 mg/dl (5.1 mmol/L) and 126 mg/dl (7.0 mmol/l). The Oral Glucose Tolerance Test (OGTT) is greater than or equals to 180 mg/dl (10.0 mmol/L) after one hour and greater than or equals to 153 mg/dl (8.5mmol/L) after two hours according to Association et al. (2018). Third, the diagnostic test results and medical records of a pregnant woman (age, weight, historical diseases, tests) help doctors estimate possible health complications and the most dangerous risks. In fact, according to the World Health Organization (WHO) [START_REF] Organization | Global report on diabetes[END_REF], uncontrolled diabetes during pregnancy cause hazardous effects on both the mother and child, such as the risk of fetal loss, congenital malformations, and stillbirth. Diabetes treatment in pregnancy depends on the blood-glucose level. In fact,at a medium level, doctors can resort to just a dietary plan. However, at a high glucose level, doctors suggest a medication therapy (for example: metformin 3 times per day during or after meals, insulin injections) that will be taken only during the pregnancy period. After that, doctors send notifications of adequate treatments for patients or their families through alarms sent by doctors'connected objects. In an emergency case, when symptoms of fetal loss appeared, an emergency alert should be forwarded to the hospital in order to urgently send an ambulance.

To treat these cases, it is essential to develop an application in order to assist users to control and configure MCOs regardless of their location (e.g. a doctor at home can control the remotely-connected medical devices of his patients to verify their reliability and trust; he can send/receive notifications to/from them). Besides, this application will enable users to share knowledge about the state of patients and the appropriate treatments, via their objects. In this regard, the main goal of this work is to propose a semantic-enabled context-aware approach that consists in:

-Defining a semantic representation of medical objects with their data and contexts to resolve the semantic heterogeneity problem.

-Facilitating the diagnosis of the health states of pregnant women based on the semantic model by taking into account myriad contexts such as, age, symptoms, hypertension, etc.

-Ensuring the good functioning of the employed medical objects to guarantee sustainable and effective pregnant women's monitoring.

-Facilitating the interaction between doctors and users through the development of a semantic-based patient monitoring system. This system fulfills the following users' requirements:

• Patient requirements: Patients (pregnant women) can continuously control their states by consulting the collected measurements. Each patient is also willing to receive and verify any notification sent by his/her doctor.

• Doctor requirements: The doctor is able to monitor a group of patients by analyzing their measurements in a given context; they can remotely consult the proposed diagnosis report by our system and to make a change if necessary. In addition, doctors can communicate and sent the appropriate diagnosis and results for patients through the triggering of alarms.

• Administrator requirements: The administrator can control the proper functioning of the medical connected objects used by the doctors and their patients. He is able to send notifications for users if he encounters a problem in the object and to automatically resolve it.

LITERATURE REVIEW

This section is divided into two sub-sections. In the first one, we give an overview of the most recent applications of the IoT in the healthcare domain. It is divided into two parts, namely monitoring system for IoMT and context-aware monitoring system for IoMT. In the second sub-section, we will focus on the semantic representation approaches in this domain. First, we study the proposed approaches in the IoT in general. Second, we interest in approaches that define the semantics of IoT-based healthcare systems. After that, we underline the main contributions of our work.

IoT-enabled Smart Healthcare

The continuous need of a low-cost remote monitoring system for elderly patients with chronic diseases has encouraged software developers to adopt IoT technologies in the healthcare field. The works of [START_REF] Mishra | Iot health care monitoring and tracking: A survey[END_REF] and [START_REF] Jayatilleka | Internet of things in healthcare: Smart devices, sensors, and systems related to diseases and health conditions[END_REF] have overviewed the recently developed IoT devices that guarantee a reliable and secure patient monitoring and treatment delivery in the healthcare domain.

This adoption shows important and adequate results for improving the quality of healthcare services in smart environments [START_REF] Turcu | Improving the quality of healthcare through internet of things[END_REF], [START_REF] Meigal | Ambient intelligence at-home laboratory for human everyday life[END_REF].

In the following sub-sections, we will start by displaying the most recently proposed monitoring system in the IoMT. Then, we will focus on the context-aware monitoring system in IoMT.

Monitoring System for the IoMT

IoT has been widely used for remote monitoring of cardiovascular diseases [START_REF] Jabeen | An iot based efficient hybrid recommender system for cardiovascular disease[END_REF]. In fact, diverse applications have been developed for diabetes [START_REF] Puri | Biosenhealth 2.0-a low-cost, energy-efficient internet of things-based blood glucose monitoring system[END_REF], heart diseaseKhan (2020), hypertension [START_REF] Sood | Iot-fog-based healthcare framework to identify and control hypertension attack[END_REF], Alzheimer [START_REF] Varatharajan | Wearable sensor devices for early detection of alzheimer disease using dynamic time warping algorithm[END_REF] , epileptical patient monitoring [START_REF] Gupta | Monitoring of epileptical patients using cloud-enabled health-iot system[END_REF], and so on.

In what follows, some recent IoT-based monitoring systems are detailed.

Diabetes monitoring:

The authors in [START_REF] Chatterjee | Designing an internet-of-things (iot) and sensor-based in-home monitoring system for assisting diabetes patients: iterative learning from two case studies[END_REF] implemented an IoT-based home monitoring system for diabetic patients. This approach aims at monitoring the daily activities of these patients to trigger alerts concerning their dietary behavior when necessary. [START_REF] Puri | Biosenhealth 2.0-a low-cost, energy-efficient internet of things-based blood glucose monitoring system[END_REF] have developed an IoT-based diabetes monitoring system that is capable of detecting and analyzing blood sugar, body temperature and other environmental parameters (temperature, humidity). This system encrypte data to ensure its secure transmission, analysis and storage in the cloud.

Heart rate monitoring: [START_REF] Liu | Intelligent medical iot system based on wsn with computer vision platforms[END_REF] have applied a medical IoT system based on wireless sensor networks for ECG monitoring. This system detect and transmit physiological parameters and image data to the base station. This data can be easily accessed and analyzed by medical professionals through their PDA and computers to ensure a timely treatment in an abnormal state. Therefore, [START_REF] Khan | An iot framework for heart disease prediction based on mdcnn classifier[END_REF] have developed and

IoT framework for heart disease prediction. They used a smartwatch and a heart monitor device to monitor blood pressure and electrocardiogram measurement. These measurements were then analyzed through the modified deep convolutional neural network (MDCNN) for heart disease prediction. [START_REF] Santos | Accessible ehealth system for heart rate estimation[END_REF] have set forth an e-health system for heart rate monitor in Ecuador. This system supports continuous care and suggests primary diagnostic assistance service of heart disease. It bases its operation on video processing algorithms, which are collected through web cam and mobile device that communicate with a central data base station via WAN network.

Hypertension monitoring: [START_REF] Sood | Iot-fog-based healthcare framework to identify and control hypertension attack[END_REF] proposed an IoT-fog health monitoring system to monitor the blood pressure level to predict real-time hypertension event. In addition, this system focused on predicting health complications and risks based on several machine learning algorithms and alerts generation.

CoronaVirus monitoring: with the CoronaVirus outbreak, which first appeared in China, several researchers are working on IoT exploitation to be able to control and prevent this pandemic. [START_REF] Bai | Chinese experts' consensus on the internet of things-aided diagnosis and treatment of coronavirus disease[END_REF]

Context-aware Monitoring System for the IoMT

To ensure reliable and efficient health data analysis and interpretation, an IoT-based system should understand the contextual information of the obtained measure. [START_REF] Dey | A conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications[END_REF] have defined context as "any information that can be used to characterize the situation of an entity. An entity is a user, place, or physical or computational object that is considered relevant to the interaction between a user and an application, including the user and applications themselves". [START_REF] Perera | Context-aware sensor search, selection and ranking model for internet of things middleware[END_REF] and [START_REF] Yürür | Context-awareness for mobile sensing: A survey and future directions[END_REF] have surveyed context-awareness from an IoT perspective.

In this section, we propose an overview of the suggested IoT-based context-aware systems. [START_REF] Rahman | Multi-modal context-aware reasoner (can) at the edge of iot[END_REF] have put forward a multi-modal context-aware reasoner (CAN) for different IoT applications at the IoT edge.

First, contextual information will be extracted from raw data. Second, this information will be filtered and then transfered to the reasoner to decide to which application it may refer. [START_REF] Chegini | A framework of automation on context-aware internet of things (iot) systems[END_REF] have defined a microservice framework to implement automatic functionalities for IoT-fog-cloud ecosystem, such as automatic IoT orchestration and collaboration, automatic task workflow, automatic task scheduling, etc. This framework helps developvIoT-based context-aware intelligent decision-making systems.

To tackle the challenges of heterogeneous data fusion and context-awareness query processing in the IoT health domain, [START_REF] Baloch | A context-aware data fusion approach for health-iot[END_REF] have proposed a context-aware data fusion in the IoMT domain. This approach is composed of context acquisition, data fusion, and inference and reasoning steps.

Authors in [START_REF] Aborokbah | Adaptive context aware decision computing paradigm for intensive health care delivery in smart cities-a case analysis[END_REF] have also introduced an SVM-based context-aware decision support system for healthcare service delivery in smart cities. This system interpreted the patient's clinical state based on multiple vital signs (heart rate, temperature, blood pressure) for early prediction of heart failure risks. Furthermore, it could provide real-time analysis of physiological data to continuously determine the state of the patient and provide optimal health care services. [START_REF] Barbosa | Trailcare: An indoor and outdoor context-aware system to assist wheelchair users[END_REF] have offered a context-aware system to assist wheelchair users. It recommends accessible resources in indoor and outdoor environments during their displacement process based on various contexts, like location, time, users' identity, etc.

To ensure the security of health data transmission between sensors, Arfaoui, Kribeche, and Senouci (2019) have adopted a context-aware and lightweight anonymous authentication scheme for Wearable Body Area Networks (WBAN) applications in emergency and normal situations. Their proposed scheme provides selective anonymous authentication between nodes in WBAN while taking into account the dynamic context changes (the battery level of sensors, memory capacity, etc).

Table 2, shows a comparative study of the context-aware monitoring systems. We are based on the same criteria as the previous table and we add another one concerning the type of the treated contexts with the aim to highlight the most important contexts processed by these works.

According to Table 1 andTable 2, diverse types of IoT devices are used in the healthcare domain and connected to various communication technologies. In addition, they are based on diverse techniques for data interpretation and management tasks. However, approaches in Table 1 put special focus on context-awareness in the internet of medical things. Several contexts are defined, such as location, time, patient's state, device's requirement, etc. In fact, contexts related to the device's functioning are only considered by [START_REF] Arfaoui | Context-aware anonymous authentication protocols in the internet of things dedicated to e-health applications[END_REF], who directed their attention to ensure safe operation of IoT devices during data collection and transmission.

Moreover, approaches presented in Table 2 and 3 have not considered using ontologies to model and manage their contexts and to deal with the semantic interoperability problem in the IoMT domain. This was our main objective in this paper. From this regard, much attention has been given

to the related works presented in section 3.2

Semantic Representation in the IoMT domain

In this section, we will focus on the semantic representation of the IoMT knowledge. Accordingly, it is crucial to study at first the proposed approaches in the IoT field in general and then on the IoMT.

Internet of Things Ontologies

Over the last few years, diverse ontologies are suggested in the IoT field. The most referenced work was suggested by [START_REF] Compton | The ssn ontology of the w3c semantic sensor network incubator group[END_REF], who put forward a Semantic Sensor Network (SSN) ontology. It describes sensors in terms of capabilities, measurement processes, observations and deployments in order to define the semantic interoperability of physical sensor networks. Its core concepts are sensors and their properties, The SSN ontology is then extended to wireless sensor networks (wireless sensor network ontology) by [START_REF] Bendadouche | Extension of the semantic sensor network ontology for wireless sensor networks: The stimulus-wsnnode-communication pattern[END_REF]. It is also used later to model sensor clouds (sensor cloud ontology) byMüller, Cabral, Morshed, and Shu ( 2013) and multimedia sensor by [START_REF] Angsuchotmetee | Mssn-onto: An ontology-based approach for flexible event processing in multimedia sensor networks[END_REF].

Nonetheless, the IoT domain does not only include sensors, but also other concepts that have to be addressed, namely the actuator, the physical object. The former is responsible for generating actions while the latter is connected to the internet and integrates sensors, actuators, devices, among others. For that reason, diverse approaches were realized in the last few years in order to represent the IoT domain knowledge. Among these approaches, we will present the most common and cited ones.

To achieve this purpose, [START_REF] Bauer | Iot reference architecture[END_REF] have defined an IoT-A architecture in IoT. This model defines the core concepts of this domain, such as physical entity, virtual entity, sensor, tag, actuator, service, and user.

In addition, to represent the semantics of actuators and their capabilities and roles, the SOSA ontology was suggested by [START_REF] Janowicz | Sosa: A lightweight ontology for sensors, observations, samples, and actuators[END_REF]. It was proposed by both the joint group World Wide Web Consortium (W3C) and the Open Geospatial Consortium (OGC) in order to elucidate the interactions between sensors, observations, actuators and sample concepts.

Therefore, in the context of the ADREAM project, [START_REF] Seydoux | Iot-o, a core-domain iot ontology to represent connected devices networks[END_REF] proposed a modular ontology (IoT-O) 3 to ensure a semantic interoperability between IoT components. IoT-O contains several modules, like sensing, actuation, life cycle, service and energy modules.

Ma, Wang, and Chu ( 2014) set forth a semantic information model for IoT applications, known as OntoIoT ontology. In fact, the latter describes (i) real word entities (objects being monitored, sensor devices, and network infrastructure), (ii) spatial and temporal dimensions, (iii) the captured (dynamic and static) data, (iv) services including applications (e.g. in the areas of healthcare or traffic), functions, and interfaces.

In the context of both the EU FP7 FIWARE project 4 and the EU H2020 FIESTA-IoT project 5 Bermudez-Edo, Elsaleh, [START_REF] Bermudez-Edo | Iot-lite: a lightweight semantic model for the internet of things[END_REF] developed an IoT-lite ontology with the aim of describing IoT concepts in three different classes: Objects, systems or resources, and services. This ontology is a lightweight instantiation of the SSN ontology.

In the same context, [START_REF] Agarwal | Unified iot ontology to enable interoperability and federation of testbeds[END_REF] proposed a unified ontology, which reuses a number of core concepts from several ontologies, such as Semantic Sensor Network (SSN), M3-lite, WGS84, IoT-lite, Time, and DUL in the IoT domain.

X X ¢ ¢ ¢ ¢ ¢ Bendadouche et al. (2012) SSN X X X ¢ ¢ ¢ ¢ Müller et al. (2013) SSN X X X ¢ ¢ ¢ X Angsuchotmetee et al. (2018) SSN, SOSA, MA-Ont X X ¢ X ¢ ¢ X Bauer et al. ( 2013
) SSN ¢ ¢ X ¢ ¢ ¢ ¢ Janowicz et al. (2018) SSN X X ¢ ¢ ¢ ¢ ¢ Seydoux et al. (2016) SSN, DUL, PowerOnt X ¢ ¢ ¢ X ¢ X Ma et al. (2014) ¢ X X ¢ ¢ ¢ ¢ X Bermudez-Edo et al. (2016) SSN, Geoname, SAO X X ¢ ¢ ¢ ¢ ¢ Agarwal et al. (2016) SSN, IoT-lite, M3, Time X X ¢ ¢ ¢ ¢ ¢
We present a comparative table, of the different approaches mentioned above, that shows the use of ontologies to resolve the semantic heterogeneity in the IoT domain. The comparison is based on the following criteria:

• Links to other ontologies: within this criterion, we aim to identify if the proposed ontology reuses concepts from a previous one and to check whether these ontologies are built from scratch.

• Contextual information: This criterion determines the presented contexts in the proposed ontologies. We have identified five major contexts that are important in the IoT domain, namely time, location, inter-connectivity, trajectory and objects' requirements.

• Reasoning: This criterion verifies whether the proposed approaches suggested rules for either device management or data management.

According to Table 11, we notice that most of these approaches take advantage of reusing existing ontologies instead of building new ones from scratch. SSN was one of the most referenced ontologies in these approaches as it presents a pivotal component for each IoT-based system. Furthermore, the main modeling contexts in these works are time and location with little emphasis on interconnectivity, requirement, and trajectory contexts. Concerning the reasoning phase, none of these approaches was interested in managing the state of the employed object, such as checking its availability, connectivity, and task allocation. Therefore, reasoning about the obtained data from IoT devices was addressed by only some works, like [START_REF] Müller | From restful to sparql: a case study on generating semantic sensor data[END_REF], [START_REF] Angsuchotmetee | Mssn-onto: An ontology-based approach for flexible event processing in multimedia sensor networks[END_REF], [START_REF] Seydoux | Iot-o, a core-domain iot ontology to represent connected devices networks[END_REF], [START_REF] Ma | Ontology-based semantic modeling and evaluation for internet of things applications[END_REF].

The next sub-section will be devoted to the semantic representation of the adoption of IoT in the healthcare domain. '

Semantic-based IoMT systems

Ensuring the semantic interoperability in the IoT and the healthcare fields gave rise to diverse research issues. Therefore, numerous ontologies are available in the medical domain. SNOMED-CT6 is the most known thesaurus, in which medical terms and their synonyms, are treatable with machines.

The Open Biomedical and Biological Ontology (OBO), according to [START_REF] Smith | The obo foundry: coordinated evolution of ontologies to support biomedical data integration[END_REF] 2018) have implemented an ontology-based context-aware architecture for personal monitoring that can be deployed in mobile devices. This architecture has addressed the challenge of self-configuring IoT devices, contextual information extraction related to patients for later analysis and interpretation, the fusion of contextual information with sensor data in order to detect suspicious anomalies and supply adequate alerts. This architecture comprises four distinct layers, namely the sensing layer, the perceptual layer, the reasoning layer and the actuating layer.

Rubí and Gondim (2020) have developed an interoperable IoMT platform by the alignment between the SSN ontology and the Electronic Health Record (EHR). This platform is based on the M2M architecture that enables communication between the different components of the IoT platform.

Table 4 displays a comparison of the developed ontologies in the IoMT domain based on some criteria. First, the IoT devices criterion determines the modeled IoT devices in the proposed ontologies. Second, the interoperability criterion verifies whether the proposed ontology was either developed from scratch or based on reusing other ontologies. Third, the context-aware criterion demonstrates if the ontology contains concepts related to both the deployed medical context, such as time, location, and trajectory, and patients' contextual information, like diseases, symptoms, historic data. Fourth, the reasoning criterion determines whether the proposed works were interested in not only diagnosing the patients' state, anticipating possible risks for prevention purposes, and proposing treatment but also checking the connected objects' states. Finally, the users' criterion aims to identify to whom the proposed system was addressed.

Synthesis

After examining Table 4, we can still recognize some shortcomings in applying SWT in IoMT, as described below.

• None of the aforementioned works proposed an ontology that covers the essential concepts in both the IoT and Healthcare domains. The majority of the suggested approaches in the healthcare field ignored reusing the already defined IoT models. That is to say, they limited health data source description to only one sensor concept.

• Little attention was paid to the semantic relationships between IoT and healthcare components that can provide a comprehensive model to analyze health data gathered from IoT devices.

• The semantic context modeling is limited to time, location and users in the almost of approaches. It does not represent a specific context (e.g. capability, network, trajectory) for medical connected objects that affects their functioning. In addition, health care contexts were not considered in these approaches. way. Additionally, to the best of our knowledge, none of these approaches have been interested in managing and interpreting the states of medical connected devices.

• Except for the study in Y. [START_REF] Chen | A context-aware search system for internet of things based on hierarchical context model[END_REF], all the proposals do not take into account the whole diagnosis process which starts by detecting health data from heterogeneous sources followed by analyzing the occurring event, then, anticipating risks and finally suggesting the suitable service in order to provide real time notifications to patients.

From this perspective, our purpose was to address these problems. First, in order to increase the interoperability of our ontology, we reused some concepts extracted from diverse IoT ontologies, such as SSN, IoT-O, and IoT-lite. Second, diverse contexts were presented in our model that deals with the functioning of the used objects and the patients' states. Third, in the reasoning step, we focused on the remote monitoring of both medical objects and patients. To this end, we put forward and emphasized the M-E-R-T-A process which started by analyzing the obtained data with a special emphasis on other factors (symptoms, historical diagnosis, age, sex), predicting the potential health risks and finished with the treatment proposition.

SEMANTIC-BASED CONTEXT-AWARE APPROACH FOR IOMT

In this section, we detail our proposed semantic-based approach as depicted in Figure 1 for patient monitoring through MCOs. This approach is based on four mains phases. The first phase describes the data collection process via the MCO and the patient medical records. In order to understand this data, a semantic modeling representation is suggested by defining their sources and their contexts in relation with either the MCO or patient. As a result, we obtain a HealthIoT ontology that will be analyzed by proposing three categories of SWRL rules. The first ones are used to configure and manage the MCO function state. The second ones are highlighted to diagnose the patient state and to predict possible health complication risks. The last category is defined to notify end-users by sending suitable alerts. These three previous phases represent the knowledgebase that will be exploited in our implementation phase to provide the appropriate services for end-users through a friendly user interfaces. These phases will be well detailed in the next sections.

DATA COLLECTION AND PREPROCESSING PHASE

Heterogeneous health data is required to understand more the medical system features. Accordingly, comprehensible and reliable data analysis will be easily performed that enables seamless and efficient communication between healthcare professionals and patients. In our work, we use two different data sources such as medical connected objects and medical reports that provide dynamic and static health data, respectively.

Data from medical connected objects

In managing and monitoring gestational diabetes, doctors pay attention to patient information that comes from several sources. Blood glucose monitoring devices are exploited for continuous monitoring of blood glucose levels. Therefore, to avoid health complications during pregnancy, diverse other measurements should be taken into account, such as blood pressure, heart rate, cholesterol, patients' activity. In this context, patients consider other medical objects, namely ECG monitoring devices, blood pressure monitoring devices and smartphones containing sensors for activity tracking. Furthermore, according to Abu-Elkheir, Hayajneh, and Ali (2013), data captured through connected objects are classified into two distinct categories: technical data which describes the general context of the data collection process (time, Id sensor, space, MCOs properties, etc.) and data relative to the monitored patient (measurement, unit of measurement, etc). Figure 2 represents an example of temperature data obtained from medical object in JSON format, where the red color designates the technical data and the blue color designates the health data. In this study, we use various data sets (CSV format) from the physiobank7 , namely temperature, cholesterol, blood pressure, blood glucose, and heart rate. PhysioBank is a large and growing archive of well-characterized digital recordings of physiologic signals and related data for use by the biomedical research community. It is one of the resources of the National Institutes of Health8 , which is intended to stimulate current research and new investigations in cardiovascular studies and other complex biomedical signals [START_REF] Goldberger | Physiobank, physiotoolkit, and physionet: components of a new research resource for complex physiologic signals[END_REF]. These data sets contain numeric and string data type.

{ "messageID": "urn:uuid:be422ea8-289d-49fa-bd39-6a48f4711c75", "messageTime": "2014-08-20T14:32:56.125Z", "message": { "SensorID": "urn:uuid:8f5308d5-a1ca-4ad4-9a7f-3a70d4177551", "SensorName": "Sensor1", "Battery-state": "50%", "Sensor-Type": "Temperature-Sensor" "measureName": {"Temperature"}, "measureType" : "numeric", "measureAcquire" : "sample", "measureUnit" : "°C", "value" : ["29.

Data from medical rapport

To provide a precise and suitable treatment for patients, doctors should not only rely on data from mobile objects. In this regard, they need to refer to patients' medical records as another source of healthcare data. This source contains basic patient information (age, sex, name, address), laboratory test data, symptoms, patient medical record, and medical family history. In our work, these valuable information are provided by three domain experts (doctors) from their patients' personal health records (PHR). In that phase, the SNOMED-CT terminology is recommended by our experts to represent this clinical information as it contains the largest clinical terminology.

Data Preprocessing

Due to the ambiguous, heterogeneous and noisy data acquired from the MCOs, a preprocessing phase should be performed to reduce and remove erroneous and unusual data. First, we apply a data cleaning phase that consists in removing data with values outside the IoT devices thresholds. In fact, each device has a maximum and a minimum range. Healthcare data with values outside this range are considered as erroneous data that will be removed. Missing data are also removed. Second, we carry out a normalization phase before integrating this data in the ontology to avoid such inconsistencies. For example we have changed the time format (from "YYYY/MM/DD hh:ss:mm" to "YYYY-MM-DDThh:ss:mm") using the ISO 8601 standard adopted by SNOMED-CT.

In order to make this data understandable and interpretable by MCO and IoMT-systems, the next section will be devoted to the formal representation of the MCO and the healthcare domain knowledge and their relationships. The OWL2Motik et al. ( 2009) is used for the formalization of the knowledge domain.

SEMANTIC MODELING PHASE

In this phase, a HealthIoT ontologyFigure 3 is proposed for the following reasons:

• Defining a standard and unified model of the collected data and linked it with their contexts. This model will be shareable and exploited between objects as well as between humans.

• Facilitating the discovery, integration, manipulation, and configuration of clinical devices.

• Supporting reasoning mechanism on the defined context to infer intelligent decision.

For this end, we aim to extend our proposed HealthIoT ontology Rhayem, Mhiri, and Gargouri (2017) in order to cover and express diverse contexts that affect the diagnosis and monitoring of both MO's and patients' states missed in the previous version.

Furthermore, to build the present ontology, we relied to some relevant existing one such as SSN Compton et al. (2012) The main concepts of our ontology are classified into three categories: concepts that represent the knowledge about MCO, the knowledge about the patient states and that about their contexts.

MCO Knowledge

This step is conceived to model the heterogeneous medical connected objects and their specificities. The main defined concepts are as follows:

HIoT:Medical-object represents the semantic of heterogeneous medical connected objects used for remote patient monitoring. For example, the blood glucose monitoring device, blood pressure monitoring device, smartphone, and the medical box represent the MCOs used to monitor pregnant woman who has a gestational diabetes disease.

HIoT: virtual-resource class is proposed to define one of the main IoT goals, which is the virtualization of real-world objects in order to facilitate their management and configuration.

ssn:Device it is a concept extended from the SSN ontology and has two sub-classes: ssn:Sensing-device and iot-lite:actuating-device. The first represents medical-sensor and RFIDs tags which are responsible for the detection of the occurring event and the second describes the actuators acting on the environment. The sensors used for gestational diabetes monitoring such as the blood glucose sensor, the blood pressure sensor, the ECG sensors, and so one, are presented as instances of the sensing device concept. The vibrator, screen, alarm represent the instances of the actuating device concept.

HIoT:properties represents the properties of the used connected-objects. Thereby, we extend some properties from cloud resource that are satisfied by IoT resources such as shareable/non-shareable, elastic/non-elastic, limited and not-limited. Other properties that we can take into consideration in the IoT are "moving" and "stop". These properties are modeled as sub-classes of "HIoT:IoT-properties" concept. Details about these properties are given in Table 5. HIoT:Task: it allows the description of the allocated task by the connected objects and the embedded devices (e.g. sensing blood glucose level, triggering treatment alerts).

Patient Knowledge

In order to represent the health state of the monitored patient, it is necessary to represent some knowledge from the medical sector. At this level, we adopt the Systematized Nomenclature of Medicine Clinical Terms (SNOMED-CT)9 standard. These concepts can be briefly described as follows:

HIoT:Measurement is designed to represent the semantics of massive quantity of health data obtained from medical connected objects. It has two sub-classes HIoT:signs and HIoT:Activity. The HIoT:signs defines the detected vital signs of the patient such as the blood glucose, the blood pressure, heartbeat, and so on which are modeled as sub-classes of this concept. HIoT:Alert contains different categories of alerts that can be generated by the actuator device. These alerts can be for objects management or for patient monitoring (treatment adjsutement, emergency call for ambulance).

HIoT:Event represents an abnormal detected event from the MCO. It refers to the healthcare event such as hyperglycemia, hypertension, etc.

HIoT:Risk: represents the health complications of uncontrolled disease that may happen.

HIoT:Actor determines the principal actors in the healthcare domain, such as HIoT:Patient, HIoT:medical-staff.

HIoT:Service describes various services that can be generated by the medical connected objects. These services can be classified into several categories such as treatment services (HIoT:treatment), emergency services when the patient's state is critical (HIoT:emergency-service) and configuration services which contain the state of the connected objects and the proposed solution.

HIoT:Symptom defines the changes in patient behavior and sensations about the disease.

Context Knowledge

HIoT:Context characterizes the MCOs and the obtained data about the monitored patient. In fact, the state of both MCOs and the patient's health changes continuously according to several factors. It is fundamental to consider these factors during the configuration of the MCO state and during the diagnosis of the patient's state in order to propose a precise and suitable services.

Context related to the medical objects deployment

• To:Time: describes the medical connected objects' employment time and the temporal validity of their captured data stream. It has several sub-classes extended from the time ontology as for instnace with To:duration, To:instant, To:interval.

• goe:Location: describes the surrounding environment of the employed objects. This concept has two subclasses, including the Indoor-Location and Outdoor-Location in order to express the functioning of the connected objects in a large scale.

• Moo:Trajectory: extended from MOO ontology [START_REF] Wannous | Modelling mobile object activities based on trajectory ontology rules considering spatial relationship rules[END_REF]. It allows representing the mobility characteristics of the connected objects. Trajectory refers to a list of locations that the object crosses during a predefined period. This concept is related to the Location concept with "has-source" and "has-destination" object properties and to the Time concept with "starts" and "ends" properties.

• Capability: is defined by the HIoT:Capability class. It represents the network context, the resource context, and the sensing and actuating capability context (e.g. energy capability, memory capability, life cycle capability). HIoT:Capability has several sub-classes HIoT:Sensing-Capability, san:Actuating-Capability, HIoT: Tags-capability, HIoT:network, and HIoT:MO-Capability concepts.

• Environment: is modeled with the HIoT:Environment concept, which determines different factors (humidity, temperature, etc.) that can influence the state of the connected objects and the validity of the detected measurement.

Context related to the monitored patient

To facilitate the management of complex state and provide the suitable treatment, modeling the context relative to the patient is a promising solution. The main proposed classes in our model are described below.

• HIoT:Disease: in the health care domain, it is intrinsic to take into account several contexts like the patient disease. For example, in the general case, a person who has a temperature value greater than 37 C, he has a fever, but for a patient suffering from hypertension disease, he has a fever when the temperature value is greater than 36:5 C.

• HIoT:Historic: represents medical information about patients such as their diseases, their causes, symptoms, historic treatments, and so on.

This knowledge helps to provide correct diagnosis, and

• HIoT:Patient: is a primordial context in the healthcare domain. It is a sub-class of "ssn:FeatureofInterset" concept, which refers to the observed and controlled element. This concept defines personal information such as age, sex, weight, etc. that play a primordial role during the diagnosis phase.

• HIoT:Activity: defines the patient's activity (e.g. sleeping, running, walking), which are detected by specific sensors such as cameras, accelerometers during health measurements monitoring.

Axioms Modeling

A set of axioms, between HealthIoT ontology concepts, which cover the union, the disjoint and the specialization relations are illustrated in Table 6. Therefore, in order to represent how these concepts are related to each other, we define several semantic relationships, some of them are highlighted in Table 7.

As example, the

ANALYSIS PHASE

After the data collection and the semantic knowledge modeling phases, proposing a rule base in order to interpret and exploit this knwoledge is a necessary step. Thereby during this phase, we propose and implement a reasoning process as detailed in Figure 4. It is basically composed of two main steps detailed below.

• Initial diagnosis and data collection step: this phase is carried out by the doctor and the MCOs. Firstly, the doctor diagnoses the patient and recommends the suitable object to be used. Then, the detected measurements of this object are stored in the HealthIoT ontology.

• Reasoning step: here, the collected data are analyzed. In fact, several rules are developed based on the SWRL language. These rules consists of an antecedent part specifying the condition that must be met and the consequent part defining the fact that may happen. Our rules are formally defined according to the ECA structure (On Event if Conditions do Actions) [START_REF] Poulovassilis | Event-condition-action rule languages for the semantic web[END_REF]. The event part determines the contexts for triggering the rules. The condition part represents a set of circumstances that should be achieved. The action part specifies the list of actions to be performed if the conditions will be held. The proposed rules are classified into two categories:

rules for connected objects' management and others for diagnosis, treatments and notification proposal. These categories will be detailed with regards to the gestational diabetes context.

Medical Objects Management

To exploit the MCOs in a reliable and effective way, it is necessary to ensure and check their proper functioning, their adaptability level with diverse contexts and their ability to perform configurations.

In this section, we develop diverse rules some of them are described below, which mainly focus on: i) the diagnosis of the objects state ii) the allocation/de-allocation of tasks, and iii) the verification of their capabilities. We present in ?? some SWRL rules for MCOs management in accordance with the proposed use case.

Determine the mode of MCOs: Connected objects can have three different modes:

• Active mode, which verifies that the object is currently active and it is not available to be, used for other tasks.

• Standby mode: verifies that the object finalizes its work and it becomes available for other tasks;

• Passive mode: indicates that the state of the sensor is out of order and it is not available for new tasks that implies to be replaced by another.

These states should be verified using the time context. For example, the standby mode verification consists of:

Event: A MCO contains a sensing device with a blood glucose type and used by a pregnant woman has finished its task and waited for another one.

(the instant when the sensor accomplishes its task should be before the actual time). This event was triggered thanks to the temporal built-ins ("temporal:before" and the subject "now") used from the temporal ontology.

Condition:

The lifetime of the sensing device should be after the actual time. For that, we use the temporal built-ins "temporal:after".

Action:

The medical object becomes in standby mode. Then state-battery(?b, "Low") has-state(?s, "standby")

Mobility Verification: MCOs can be either in fixed or moving states. In fact, moving state defines their dynamic position that changes continuously instead of the fixed one that designates their constant location. Verifying this state needs spatio-temporal data. Therefore, based on the temporal:duration builtins, and the Time, Location and Trajectory contexts, we proposed an SWRL rule that determines if the location of this object changes. We have considered a time interval depending on the estimated period needed for the patient monitoring task that takes into account the patient's state and the complexity of the disease. For example, we supposed that a pregnant woman needs to monitor her blood glucose 8 times per day, separated by two hours. In these times, we aim to control the mobility of the MCO. Accordingly, it will be easier to allocate tasks in case of failure of MCO by considering only the nearest objects. In addition, it helps to control the activity of the patient. It consists of:

Event: MCO has a trajectory that is composed of a set of crossed locations during an interval of time

Condition: the location is the same during two hours.

Action: MCO object is in stopping state and consequently the patient is motionless.

rule: "Mobility verification"

When

Medical-object(?o) Sensing-device(?s) contains (?o, ?s) has-type(?s, "blood-glucose-sensor") has-user(?o,?p) sexe(?p, "woman") has-state(?p, pregnant) Trajectory(?t) has-trajectory(?o,?t) has-source( ?t,?l1) has-name(?l1, ?m) hasdestination(?t,?l2) has-name(?l2, ?n) starts(?t,?i1) ends(?t,?i2)

IF

swrlb:stringEqualIgnoreCase(?m,?n) temporal:durationEqualTo (2, ?i1, ?i2, "Hours") Then has-state(?o, "stopping")

Patient State Diagnosis and Decision Making

One of the main contributions of this work is to propose a decision-making process namely Measure-

Event-Risk-Treatment-Alert (M-E-R-T-A)
that takes into account the whole remote diagnosis process for the patient. M-E-R-T-A starts with the analysis of the obtained measures, then the detection of the health event that may happen, the prediction of risk complication, and finishes with the proposition of the adequate treatment and the notification of the patient. Figure 5 shows an example that allows interpreting the detected data with a Glycemia sensor based on M-E-R-T-A.

Thereby, the analysis of glycemia level leads to the detection of hyperglycemia event and the possible risk that may happen as the fetal loss for the pregnant woman. After that, the next phase determines and notifies the patient with the appropriate treatment (Metformin Mylan).

To perform this process, we develop diverse SWRL rules to treat five different health measurements (temperature, blood pressure, heart rate, blood glucose, and cholesterol). In the next sub-sections, we describe some rules in accordance to the proposed use case (gestational diabetes context).

Validity of Data;

For the purpose to analyze the obtained data in real-time, we define the following to verify the validity of the blood glucose. It consists of:

Event: MCO detects blood glucose level of a pregnant woman.

Condition: the deadline of the obtained blood glucose is greater than the time required for data access and analysis by the doctor. To verify this condition we exploit the temporal SWRL builtins. temporal:before and the subject "now" that refers to the actual time.

Action:

The blood glucose is valid to be processed and analyzed.

IF

temporal:before(?s, "now") temporal:after(?e, "now") Then validity(?t, true)

Events detection; These rules are proposed to enable medical staff to predict and detect events on time. For this end, we define several SWRL rules which aim to examine the patients' vital signs from different contexts in real time and to provide an adequate solution. For example, the next rule identifies the hyperglycemia event (Gestational diabetes) for a pregnant woman. Therefore, in the normal case, hyperglycemia is diagnosed when the blood glucose level is greater than or equal to 126 mg/dl. But, in the case of pregnant woman, it is diagnosed if it is greater than or equal to 92 mg/dl. This rule consists of:

Event: MCO detects blood glucose level of a pregnant woman.

Condition:

The detected blood glucose is valid and it is greater than 92 mg/dl and the pregnancy is meanwhile the forth and ninth months. We use the temporal built-ins "temporal:durationGreaterThan" and "temporal:durationLessThan" to analyze the pregnancy duration of the patient.

Action: Hyperglycemia event is detected.

rule: "Hyperglycemia event detection"

When

Patient(?p) sexe(?p, "woman") has-state(?p, pregnant) start-at(pregnant,?s) temporal:durationGreaterThan (4, ?s, "now", "Months") temporal:durationLessThan (9, ?s, "now", "Months") Medical-object(?o) has-user(?o,?p) Blood-glucose(?t) detect(?o,?t)

IF

validity(?t, true) has-value(?t,?v) swrlb:greaterThan (?v,92) has-unit(?t, ?u) has-name (?u, "mg/dl") Then has-event(?p, Hyperglycemia) has-disease(?p, Gestational-diabete)

Action: The actuator of the ambulance is on state "ON" and has a message, which indicates the name and the location of the corresponding patient.

rule: "Emergency Alert" When

Medical-Object(?o) has-type (?o, "ambulance") actuator(?c) contains(?o,?c) Hospital(?h) has-object (?h,?o) availability(?o, true) Patient(?p) has-name(?p,?name) located-in(?p, ?l) IF need(?p, ambulance)

Then swrlb:stringConcat(?m, ?name, ?l) has-state(?c, "ON") has-message(?c, ?m)

IMPLEMENTATION PHASE

Once our Knowledge-base is defined referring to previous phases, it is necessary to be exploited by end-users. From this regard, the main goal of this implementation phase is to develop an IoT-based clinical decision support system (IoT Medicare system). This system is integrated with query and inference engine (Drools engine) developed with SWRLAPI, OWLAPI, and Jena APIs which are used to deal with SWRL rules, and SPARQL queries. To provide a suitable decision, this system takes into account the health data that describes the patient's information and technical data that represents the state of the medical objects. The IoT Medicare system consists mainly of three modules: Medical Objects Management, Diagnosis and treatment module, and a Notification module. The connected object management module deals with ensuring the proper functioning of the connected objects. The second module focuses on the analysis and the interpretation of the detected patient vital signs, to treat and prevent diseases. The notification module allows notifying patients with the decision of the doctor.

The reliable exploitation of the IoT system requires a secure actor authentication to protect the accessed information through a password stored in the HealthIoT ontology. After that, the end user is able to ask simply a query using easy ways (button choose, or menu choose). This query is transferred to the knowledge base to run an inference engine (Drools engine). The latter, firstly, loads the ontology on the basis of OWLAPI and executes the developed SWRL rules. Subsequently, it gives the actors the appropriate decision through the obtained inferred results.

FIGURE 6 Update MO's state

MCO Management Module

With the continuous growth of medical connected objects, a manual monitoring of their states has become infeasible and very hard. Therefore, it is paramount to propose a monitoring system that enables the administrator user to:

-Facilitate the search, the update and the exploitation of these devices.

-Ensure a periodic monitoring of medical connected objects.

-Help to anticipate problems and provide preventive and predictive maintenance.

The administrator is the responsible for this task. Thus, he is able to monitor the state of the medical object and configure it, add new objects, consult the list of objects, update its properties, among others.

Figure 6 shows an example of updating some parameters of a selected object from the returned list. This list is the result of the SPARQL query illustrated in Figure 7d. This query returns the objects that need a configuration (e.g. object with active mode and with availability true). The administrator can easily change the value of the availability state to false through a user-friendly interface. The confirmation of this task is insured via the "UpDate" button, which executes a SPARQL update query Figure 7a. This query consists of two main operations. The Delete operation removes the "true" value of the data property availability and the insert operation inserts the "false" value. (c) SPARQL Query to select the list of patients, their measurements, the detected events, risks and the proposed treatments.

(d) SPARQL Query to select the list MO, their states, their tasks, and their availability.

FIGURE 7 SPARQL Queries.

Patient State Diagnosis Module

This module has been designed to describe how healthcare professionals can remotely provide diverse systematic care services including the analysis and diagnosis of the patients' states.

The meaningful interpretation of vital signs obtained from several connected objects; this implies to provide adequate treatments for patients, which presents the main goal of this module. In fact, through a simple authentication, the doctor can perform various functionalities. Firstly, he should specify the appropriate object to be used to monitor the patient's state. Once this object is activated and based on its detected vital signs, he is able to diagnose the patient's state. Then, he can consult the list of patients in charge in order to know their status, their disease record, and followed treatments, notify them with a suitable cure, and so on. When the doctor selects the patient to be monitored, a decision-making interface is displayed in Figure 8. This interface illustrates the obtained vital signs from the patients' medical objects. Accordingly, by clicking on the button "Diagnostic", the doctor can check the patient's actual state, the possible risk and the appropriate treatment for this predicted event. In this interface, the diagnostic, the risk and the treatment areas are alterable in order to offer the doctor the possibility of updating them because the role of a doctor is irreplaceable. After that, through the button "Notify Patient" the doctor sends his decision to the patient.

FIGURE 8 Decision Making

Notification Module

The main reason to design this layer is to make patients capable to receive recommendations and treatments from their doctors and contact them when they face adverse effects following a proposed medication.

This module is very important because it ensures a high health care service delivery during a reasonable time.

EVALUATION

We evaluate our approach on the functional and technical level. In the technical level, we focus on evaluating the semantic quality of the proposed model (HealthIoT-O). In the functional level, we focus on the reasoning performance and the response time of our proposed system "IoT Medicare system".

Technical Evaluation: OQUARE Framework

In order to evaluate the quality of our ontology, we applied the OQuaRE evaluation framework Duque-Ramos et al. ( 2013), which is mainly based on the Software product quality standards ISO/IEC 25012:2008 (SQuaRE) ISO/IEC (2008). In this work, the authors used the SQuaRE characteristics namely structural, functional adequacy, adaptability, maintainability, operability, reliability, and transferability. Each characteristic was assessed with various sub-characteristics and metrics.

Table 8 recapitulates these characteristics, their definitions, their sub-characteristics, and the related metrics.

For more details about the relative metrics of each sub-characteristic, how each metric is calculated and how the score is assigned, readers may refer to these works [START_REF] Duque-Ramos | Evaluation of the oquare framework for ontology quality[END_REF][START_REF] Duque-Ramos | Oquare: A square-based approach for evaluating the quality of ontologies[END_REF][START_REF] Duque-Ramos | Evaluating the good ontology design guideline (goodod) with the ontology quality requirements and evaluation method and metrics (oquare)[END_REF].

Based on these works, our experimentation process is summarized as follows:

1. Firstly, we calculated the value of each metric for each sub-characteristic (note that one metric can be used for several sub-characteristics). 3. Then, we calculated the average score of these sub-characteristics that is equal to the mean score of all their associated metrics.

4. Finally, we calculated the average score of each characteristic which is equal to the Mean Score of their sub-characteristics.

Figure 10 depicts the score of each quality characteristics of the HealthIoT ontology. The structural, functional, reliability as well as the operability characteristics are above average, which reflects the good quality of the HealthIoT ontology. However, for the Maintainability and compatibility characteristics, the average score is above 3 (minimally acceptable) but still less than 4. For these characteristics, some metrics should be improved to reach this score. For example, in the maintainability characteristics, LCOMOnto and DITOnto metrics have the score 3, which is minimally acceptable. Consequently, the HealthIoT ontology needs some improvements related to these indicators.

Functional Evaluation

In this step, we evaluated the reasoning performance of HealthIoT ontology and the effect of the quantity of data obtained from medical devices and their contexts on the response time of the IoT Medicare system.

Reasoning Performance of HealthIoT

To evaluate the effectiveness degree of our model reasoning, three evaluation measures including Recall, Precision, F-Measure were considered using the following equations. We relied on the contingency table as described in Table 9. We denote TP, FP, TN and FN as True Positive (correctly diagnosed instances as required), False Positive (incorrectly diagnosed instances as required), False Negative (incorrectly diagnosed instances as not required), and the True Negative (correctly diagnosed instances as not required).

Precision= TP (TP+FP)

(1)

Recall=

TP (TP+FN)

(2)

F-measure= 2*Precision*Recall Precision + Recall (3)
The values of these measures reflect the relevance level of the inferred axioms by identifying the correct and the ambiguous ones.

For the experimentation we considered five datasets (temperature, blood pressure, blood glucose, cholesterol and heart rate) from physiobank10 and we took 10 patients as sample. Therefore, for each dataset, we only took 1200 data records that correspond to the one-month duration for the monitoring of these patients (4 measurements per-day * 30 days * 10 patients). Consequently 6000 data records (1200*5) are stored in the HealthIoT ontology. These datasets contains others informations such as the time and the location of these measures. Consequently, a total of 18300 instances (measures, time, location, symptoms, disease, drugs, food) were created to form the whole knowledge base of our clinical decision support system (IoT-Medicare).

In fact, we have proposed diverse rules validated with health care experts (3 doctors) that helped us to calculate the reasoning phase performance of our knowledge base. Firstly, we proposed some rules taking into account just few contexts (age, and sex) (arround 20 rules) that help doctors for primary diagnosis. Secondly, we deeply focused on diverse contexts for advanced diagnosis process (arround 35 rules). Table 9 and Table 10 show the results of the correctly diagnosed patients with our system compared to those diagnosed manually (with domain experts), in the first and the second cases respectively. Thereby, the performance of the developed system was improved as demonstrated by Figure 11.

Response Time of IoT Medicare System

This section was devoted to evaluate the effect of the data quantity and their contexts in the response time of the IoT Medicare System. Thereby, the response time is defined as:

Trep = T load +T inf +Tquery where T load is the time needed to load the ontology in the Drools engine, T inf is the time of the execution of the SWRL rules and Tquery determines the processing time of the SPARQL queries to display the results for the users. HealthIoT ontology is made up of more than 80 concepts, 100 object properties, and more than 90 data properties.

The first experimentation consists to set the number of rules to 30 and 65 for the second one. Then we vary the number of instances (600, 1000, 5000, 10000, 18300) in each experimentation.

The simulation is conducted with the following software platforms: Protege 5.0.1, JVM 1.8.1, Windows 7. The hardware platform is Intel Core 5GHZ CPU and 4GB RAM. In Figure 12, when the number of the stored data increases from 5000 to 18300, the response time of the processing rules increases from 7,5 s to 14,87 s if we use only 30 rules. However, when we increase the number of rules to 65, the response time is increased from 11,12 to 23,43 s. Thus, the number of stored data and proposed rules can have a significant impact on the performance of the response time, especially if they involve complicated context reasoning.

Comparison with existing approaches

In this section, we conduct a comparative study between the above mentioned works in section 3.3 and our work. The comparison is based on three main criteria as presented in Table 11. These criteria respond to our approach's goals. The coverage criterion identifies and highlights the reutilization of IoT concepts and in order to evaluate the performance of our model, we try to compare it with other ones using their overall coverage as an assessment criterion. From this context, there are diverse referenced IoT models such as IoT-A [START_REF] Bauer | Iot reference architecture[END_REF] [START_REF] Agarwal | Unified iot ontology to enable interoperability and federation of testbeds[END_REF]. we have considered these ontologies and we calculated the coverage value of our ontology using the following equation.

C = RC=T C

(4)

Where C is the coverage, RC is the used concepts from the IoT domain TC is the whole number of concepts in the IoT model. The second criterion is about the reasoning task. Within this criterion, we verify what is the main objective of the proposed rules. Is it for device management or for disease management? The last criterion focuses on the adopted method for the evaluation of the proposed models.

Framework

From the comparative table our system differs from other approaches, by the following aspects:

• It is based on a generic knowledge base (HealthIoT-ontology) that describes the amalgamation between the basic IoT domain concepts and healthcare concepts. So that, it is useful for other applications in various contexts. It is better than the other systems which are based only on sensor device. Our ontology presents the best coverage value that ensures its reliability.

• Unlike other systems, our approach ensures configuration and management services for the deployed objects to guarantee a continuous and reliable patient monitoring.

• It suggests a whole diagnosis process which starts with data collection, diagnosis, risk prediction, treatment suggestion and then triggered alert. Most of these systems are proposed to accomplish a specific task, such as treatment or diagnosis. None of them has defined a whole diagnosis process unlike D. Chen et al. (2016) that focused on specific application (Hypertension disease).

• It is a context-aware system that treats diverse contexts by taking into account patients' states and medical devices.

• It offers user-friendly interfaces that can be used by three different users (patients, doctors, and administrators). However, the majority of other systems have been proposed for just one user; patients.

• Our system is flexible as it presents a graphical interface to doctors to be able to add or delete new patients and medical objects in the knowledge base.

• It provides patients with other various functions, such as the possibility to contact their doctors via a graphical interface which contains their healthcare information.

CONCLUSION AND OUTLOOK

This paper proposed a semantic-based context-aware architecture approach for patient monitoring with MCOs. It was designed based on four fundamental phases such as the data collection and preprocessing phase, the semantic modeling phase, the analysis phase, and the implementation phase. The data collection and preprocessing phase considered two sources of data: data collected from MCO and data collected from medical records. The semantic modeling phase was interested in the representation of knowledge about the MCO, the monitored patient, and their contexts. The resulted semantic model called "HealthIoT Ontology" was exploited by defining diverse rules based on the SWRL language in the analysis phase. These rules were suggested for two main objectives: the configuration and the management of the employed objects and the patient state diagnosis and decision making taking into account the alterable context. The implementation phase was focused on the development of an IoT

Medicare system for patient monitoring, which integrated both the proposed knowledge base (HealthIoT-O) and the rule base in order to provide diverse services for end-users (doctor, patient, and administrator) according to its deployment context. The evaluation of our approach focused on two objectives: a technical evaluation that interested in the semantic quality of HealthIoT ontology and a functional evaluation that focused on the reasoning performance and the response time of the IoT Medicare system.

The current work offers many challenges and different perspectives that we plan to address them in future works. Firstly, we will focus on extending and improving our approach firstly, by implementing a real use case and using health standards such as FHIR, ISO TS for health sensor data representation. In addition, we will extract clinical information automatically from electronic sources (the EHR) by applying the NLP technics and deep learning. Therefore, will focus on the alignment of our ontology with other domain ontology in order to enhance its capacity on accommodating different application domains. Secondly, we aim to evaluate the capacity of our approach in the monitoring of patients which suffers from Coronavirus.

In addition, we aim to propose and to implement an intelligent solution to optimize the use of the ontology instances to be then smartly processed and analyzed. This solution will be able to define a direct and seamless interpretation of the knowledge base and the system without using the inference engine. By this way, we ensure that the more accurate used knowledge, the more understandable and reasonable system we can define. In addition, we will focus on the scalability challenge of the IoT-Medicare system in order to be capable to manage the possible huge quantity of data accurately. In this context, Big data technology can be exploited as a solution.

FIGURE 1

 1 FIGURE 1 Semantic-based context-aware approach

  through the ssn prefix, IoT-OSeydoux et al. (2016), IoT-liteBermudez-Edo et al. (2016) with the iot-lite prefix, Time ontologyHobbs and Pan (2006) with the To prefix, Geonamesontology through the geo prefix and MOO ontology Wannous, Malki, Bouju, and Vincent (2013) through the moo prefix. Formally, we define our ontology as 3-tuples: O= (C, A, I) where : • C : set of concepts • A : set of axioms between concepts • I : set of instances of each concept

FIGURE 3

 3 FIGURE 3 HealthIoT Ontology

  Patient class has the relation "has-object" with the Medical-object. Medical-object class is associated with the concept Device via the object property "contains". To define the role of the Medical-Object class, which is the surveillance of a Patient, we propose the object property "monitors" with the range domain ssn:FeatureofInterest and Patient concepts. The objects properties("has-location" and "has-time") are associated between the Medical-object and both Location and Time concepts respectively. The object property "analysis" is assigned between the Doctor concept and the Measurement concept.

  (?o) battery(?b) Sensing-device(?s) contains (?o, ?s) allocated(?o,?t) has-battery(?o,?b) IF has-value(?b,0.1)

FIGURE 5

 5 FIGURE 5 M-E-R-T-A: diagnostic and decision making method

( a )

 a SPARQL Query to update the state of MO. (b) List of Patients and their personal information.

Figure 9 FIGURE 9

 99 Figure9represents an example of a notification that contains adequate treatment after the analysis of the state of the selected patient (colored in red) in the last module and how this notification is saved in the knowledge base "HealthIoT-Ontology". This module is composed of a diverse menu. The profile menu provides general information about the patient and the suggested treatments by the doctor. The diagnostic menu shows the

FIGURE 10

 10 FIGURE 10HealthIoT-Ontology Evaluations using OQuaRE metrics.

FIGURE 11

 11 FIGURE 11 IoT-Medicare system performance

  have offered a diagnosis and treatment system for COVID-19 based on the IoT. The main asset of this system is to remotely monitor outpatients in the containment zone and ensure a fast and reliable intervention if necessary. It helps doctors, at the early stages of this disease, guarantee timely treatment of confirmed cases and facilitate the interaction between experts and managers to deeply investigate or expand the diagnosis and treatment of COVID-19. Both a smartphone and a PC, key components of this system, are used for patient monitoring and cloud computing for data storage, communication, and transmission technologies.In Table1, we present a comparison of the above-mentioned works, related to the IoT-based healthcare monitoring system. This comparison is based on diverse criteria to give a general overview of the main properties of IoT-based systems in the healthcare domain. The used devices criterion aims to list the different deployed IoT devices. The communication technology identifies the types of the used technologies to connect the IoT devices. The application criterion determines the application domain of the developed system. The use of the ontologies criterion verifies if the proposed works addressed the semantic-interoperability challenge or not. The reasoning methods criterion identifies the principal used methods and technics for data interpretation. The tools criterion verifies if the proposed works have developed and evaluated their approaches on a real use case.

					TABLE 1 A comparison of recent monitoring systems for the IoMT.
	References		IoT devices				Communication	Application	Use	of	Reasoning	Tools
								Technology		ontologies	methods
	Chatterjee et	Ambient sensors (switch, sen-	WSN	Diabetes	NO		replicator neu-	Yes
	al. (2018)		sor for activity), IoT devices (BG					ral	network
				monitor), Body wearable devices					(RNN)
	Puri	et	al.	Glucose	sensor,	transcon-	WiFi	Diabetes	NO		If-Then rules	Yes
	(2020)			ductance	amplifier,	and
				microcontroller
	Liu et al. (2018)	ECG sensor				Wireless Sen-	Heart	NO		image	pro-	Yes
								sor Networks				cessing
								(WSN)				techniques
	Khan (2020)		smart watch and heart monitor	LoRa	Heart	NO		Modified Deep	Yes
				device				technology				Convolutional
												Neural Network
												(MDCNN)
	Santos et al.	Web cam and			WAN network	Heart	NO
	(2019)
	Sood	and	Health sensor (Blood pres-		Hypertension	NO		Artificial Neural	Yes
	Mahajan		sure sensor, heart arte; etc),					Network (ANN)
	(2018)			accelerometer, Bio sensor, RFID
				tag, etc
	Bai et al. (2020)	sensors for heart rate, tempera-	5G technology	Coronavirus	NO		Yes
				ture, respiratory rate, etc

TABLE 2

 2 Comparison between Context-aware Monitoring systems for the IoMT

	References	IoT devices	Communication	Application	Use	of	Context type	Reasoning	Tools
			Technology			ontologies				methods
	Rahman et	sensors, raspberry pi	¢	IoT	in	No		application domain	rules-	No
	al. (2017)			general				(smart	home,	based and
								healthcare, etc)	Bayesian
										network
	Chegini and	¢	¢	IoT	in	No		Location, Environ-	¢	Yes
	Mahanti			general				mental contexts (air
	(2019)							pollution)
	Baloch et al.	IoT sensors	¢	Healthcare	No		Location, environe-	¢	No
	(2018)							ment
	Aborokbah	¢	¢	Healthcare	No		Considering	SVM	Yes
	et al. (2018)							multiple vital signs
	Barbosa et	RFID cards	RS-232,	Healthcare	No		Indoor,	Outdoor	Yes
	al. (2018)		Bluetooth					locations, Time
	Arfaoui et	Wearable Body Area		Healthcare	No		Device	contexts
	al. (2019)	Network (WBAN)						(battery	level,
								memory capacity,
								etc.)

observations, systems, measuring capabilities, operational and survival restrictions, and deployments.

TABLE 3

 3 Comparison of Semantic-IoT related works

	Reference	Links to other ontologies	Contextual information	Reasoning
			Time	Location Connectivity Trajectory Device	Device	Data Man-
					Manage-	agement
					ment
	Compton et al.	SemSOS,	Ontonym-
	(2012)	Sensor,	CESN,
		O&M

  , was developed in the field of biomedical informatics. It is based on the upper-level ontology Basic Formal Ontology (BFO). UFO (ECG) ontology[START_REF] Gonçalves | An ontological analysis of the electrocardiogram[END_REF] is an ontology for the electrocardiogram diagnosis based on the UFO ontology. This model proposed a reference and a standard model of the ECG data. Therefore, several researchers have addressed the semantic interoperability issue in the IoMT domain. Authors in Lasierra, Alesanco, O'Sullivan, and García (2013) provided an ontology representing the management procedure MAPE-Loop (monitoring, analysis, planning, and execution) of technical data in the case of a patient monitoring. Authors in Alirezaie et al. (2017) came up with an ontology-based system called "E-care@home". It consists of three different parts, namely Ecare@home database, IoT devices, and software and protocols. This Smart Home Ontology is proposed to describe and interpret the heterogeneous sensor data.The work achieved by[START_REF] Forkan | Cocamaal: A cloud-oriented context-aware middleware in ambient assisted living[END_REF] proposed a cloud-based real-time context-aware framework in ambient assisted living. This framework deals with the aggregation and management of heterogeneous sensor data in different contexts. In D.[START_REF] Chen | Context-awareness based personalized recommendation of anti-hypertension drugs[END_REF],

the authors proposed an Antihypertensive Drugs Personalized Recommendation Service Context Ontology (HyRCO). This model is divided into seven core classes, namely: User, Activity, Environment, Device, Service, Location and Anti-hypertensive. It defines context rules to provide a drug recommendation service for the hypertension disease based on SWRL language. Recently, the SAREF ontology was extended for the healthcare domain

[START_REF] Moreira | Saref4health: Iot standard-based ontology-driven healthcare systems[END_REF]

and specifically for monitoring ECG data.

Esposito et al. (

TABLE 4

 4 Criteria and Health care ontologies comparison

	References	IoT devices	Interoperability	Context-aware	Reasoning goals	Users
	Criterion
	Lasierra et al.	sensors	No	No		Device management: ON,	Patient
	(2013)						OFF
	Alirezaie et al.	sensors	SSN	Time,	Loca-	Activity recognition	Patient
	(2017)				tion, Patient's
					activity
	Forkan et al.	sensors	No	Device,	Envi-	Diagnosis	Patient
	(2014)				ronment, Place,
					Person
	D. Chen et al.	sensors	No	Patient		Treatment for hypertension	Patient
	(2016)						disease
	Moreira et al.	sensors	SSN/SOSA, UFO	No		No	Patient
	(2018)			ECG
	Esposito et al.	sensors	No	Patient's		Diagnosis	Doctor	and
	(2018)				activity			Patient
	Rubí	and	Sensors	SSN	No		No	Doctor
	Gondim
	(2020)

• The reasoning task is conceived to analyze the patient's health care state in a simple case. Researchers have not treated contexts in a detailed

TABLE 5

 5 Internet of Things resources properties

	Properties	Definition
	Shareable	IoT resources can perform two task at the same time.
	non-shareable	IoT resources is capable to execute just one task at a given time
	limited	In almost of cases IoT resources have a maximum capacity as for instance with battery life time and
		energy consumption that if it is reached than the IoT resource is no longer working
	non limited	IoT resources have unlimited capacity
	elastic	it's possible to add/remove resources in order to increase their capability (memory, lifetime, response
		time, etc)
	non-elastic	there is no possibility to change the capability of IoT resources
	stop	IoT resources are deployed in a specific environement during a predefined period.

move

IoT resources are in moving state if their environment of deployment change during time.

TABLE 6

 6 HealthIoT's axioms Axiom Sensing-device Device ; Actuating-device Device Patient Actor ; Medica-staff Actor; Patient ssn: Feature-of-interest context Time t Location t Trajectory t Capability t Environment t Disease t Patient t Activity t Historic Service Treatment-service t Emergency-service t

	Configuration-service

TABLE 8

 8 OQuaRE Charecteristics and metrics

	Characteristics	Definitions	Sub-characteristics	Metrics
	Structural	Allows evaluating the ontology based on diverse	Formal,	Cohe-	RROnto,	LCOMOnto,
		formal and semantic ontological properties	sion,	Redundancy	TMOnto, ANOnto
			Tangledness
	Functional Ade-	Evaluates the degree of the ontology to execute	Controlled	vocabu-	ANOnto, RROnto, AROnto,
	quacy	concrete function purposes	lary, Consistent search	INROnto,	INROnto,
			and query, knowledge	NOMOnto,
			acquisition, results rep-
			resentation, knowledge
			reuse
	Reliability	Determines the degree of the ontology to main-	Availability,		WMCOnto,	DITOnto,
		tain the performance level under several condi-	Recoverability	NOMOnto, LCOMOnto
		tions
	Maintenability	Determines the flexibility of the developed model	Modularity, Reusability,	WMCOnto,	DITOnto,
		to adapt to changes in the environment, require-	Analysability, Change-	NOCOnto,	RFCOnto,
		ments, and functional specification	ability,	Modification	NOMOnto,	LCOMOnto,
			Stability, Testability	CBOOnto
	Compatibility	Checks how much the ontology can be deployed	Replaceability,	WMCOnto,	DITOnto,
		for different applications and with different soft-	Adaptability	RFCOnto,	NOMOnto,
		ware			CBOOnto
	Operability	Verifies how much the ontology enables users to	Learnability	WMCOnto,	LCOMOnto,
		learn its application			NOMOnto,	CBOOnto,
					NOCOnto
	2. Secondly, we assigned a score for each metric that shows the acceptability degree of each measurement. The score range varies between
	1 and 5. Where 1 means highly unacceptable, 2 unacceptable and improvement is required, 3 minimally acceptable, 4 acceptable, and 5
	exceeds the requirements. The mapping process is well detailed in Duque-Ramos et al. (2011).

TABLE 9

 9 Comparing system classification with domain experts classification, in the primary diagnosis

		Correctly diagnosed cases by	Incorrectly diagnosed cases by
		expert domain	expert domain
	Correctly diagnosed cases by IoT Medi-	(2700) TP	(1310) FP
	care system
	Incorrectly diagnosed cases by IoT Medi-	(1030) FN	(1020) TN
	care system

TABLE 10

 10 Comparing system classification with domain experts classification with diverse contexts

		Correctly diagnosed cases by	Incorrectly diagnosed cases by
		expert domain	expert domain
	Correctly diagnosed cases by IoT Medi-	(3230) TP	(630) FP
	care system
	Incorrectly diagnosed cases by IoT Medi-	(780) FN	(1360) TN
	care system
	we recognized that taking into account context-aware reasoning gives a more precise and correct diagnosis and reduce adverse event that usu-
	ally happens in the case of incorrect diagnosis.

  composed by 16 concepts, IoT-lite Bermudez-Edo et al. (2016) composed by 18 concepts, IOT-O Seydoux et al. (2016) that is composed by 28 concepts and FIESTA ontology that contains 26 concepts

TABLE 11

 11 Comparison with existing works

	Reference		Coverage of IoT concepts				Reasoning			Evaluation
			IoT-A (16)	IoT-O	IoT-lite	FIESTA-O	DM	DiD	DiT	RP	Alert Functional	Technical
			Bauer et	(28)Sey-	Bermudez-	(26)						evaluation	evaluation
			al. (2013)	doux et al.	Edo et al.
				(2016)	(2016)
					(18)
	Lasierra et	1/16=	1/28= 3%	1/18=	1/26= 3%	+/-	No	No	No	Yes	Competency	No
	al. (2013)	6.2%		5.5%							Questions
	Forkan et	1/16=	1/28= 3%	1/18=	1/26= 3%	+/-	Yes	No	No	Yes	Response	No
	al. (2014)	6.2%		5.5%							time	of
												cloud node
	D. Chen et	4/16=25%	3/28=	3/18=	3/26=	No	Yes	Yes	Yes	Yes		No
	al. (2016)		10%	16%	11%
	Alirezaie
	et	al.
	Our		12/16=75% 7/28=	7/18=	7/26=	+/+	Yes	Yes	Yes	Yes	F-measure,	OQUARE
	Approach		25%	38%	26%						Precision,
												Rappel,
												Response
												Time

https://www.huffingtonpost.com/josh-stein/the-emergence-of-the-inte_b_6801714.html

https://www-03.ibm.com/press/us/en/pressrelease/49475.wss

http://www.snomed.org/

https://physionet.org/data/

https://www.nih.gov/

http://bioportal.bioontology.org/ontologies/SNOMEDCT/

https://physionet.org/physiobank/

/28= 7% 2/18= 11% 2/26= 7% No Yes No No No No No Moreira /26= 3% No No No No No Competency Questions No Esposito /26= 3% No Yes No Yes Yes No No Rubí and Gondim /28= 3% 1/18= 5.5% 1/26= 3% No Yes No No Yes No No

rule: "Standby mode verification" When Medical-object(?o) Sensing-device(?s) contains (?o, ?s) has-type(?s, "blood-glucose-sensor") has-user(?o,?p) sexe(?p, "woman") has-state(?p, pregnant) finish-at(?s,?f) has-value(?f,?v) temporal:before(?f, "now") IF has-life-time(?s,?t) has-value(?t,?v) temporal:after(?t, "now") Then has-state(?s, "standby") Verify the availability of MCOs: In this category, the proposed rules determine if the MCOs are available for new tasks or not. These rules depend on the result of the verification of the mode rules. If the MCO was in active or passive state, it is not available. However, if it is in a standby mode, it becomes available to execute other tasks. The proposed example consists of:

Event: a MCO that contains a sensing device with a blood glucose type is by a pregnant woman.

Condition: the MCO is in a standby mode.

Action: the MCO is available to execute a new task (e.g. the detection of the blood glucose level after two hours).

rule: "Availability verification"

When

Medical-object(?o) Sensing-device(?s) contains (?o, ?s) has-type(?s, "blood-glucose-sensor") has-user(?o,?p) sexe(?p, "woman") has-state(?p, pregnant)

IF

has-state(?s, "standby") Then availability(?o, true)

Task allocation: The main goal of these rules is to allocate/de-allocate tasks for MCOs. They are based on the verification of the mode and the availability rules. Therefore, if the MCOs is available, it can allocate a new task. For example, the suggested rule in this paper is formed by: Event: a MCO contains a sensing device with a blood glucose type turns passive (e.g. lifetime exceeded).

Condition: another MCO contains a sensing device with the same type of the previous MCO is available to execute a new task.

Action: the task of the first MCO is allocated by the second one that will be attached to the monitored patient.

rule: "Task Allocation"

When

Medical-Object(?o1) Sensing-device(?s1) contains(?o1, ?s1) has-user(?o1,?p) sexe(?p, "woman") has-state(?p, pregnant) availability(?s1, false) has-type(?s1, ?type1) task(?t) allocated(?o1,?t)

IF

Medical-Object(?o2) Sensing-device(?s2) contains(?o2, ?s2) has-state(?s2, "standby") has-type(?s2,?type2) swrlb:stringEqualIgnoreCase(?type1, ?type2) Then allocated(?o2,?t) de-allocate(?o1,?t) has-user(?o2,?p) Capability Verification: To examine the proper functioning and capabilities (battery level, RAM memory, energy consumption, etc) of the medical objects, it is very important to propose various rules. The following rule consists of:

Event: MCO executes a task

Condition: its battery level is 10% Action: the state of the battery is Low and the mode of its sensing-device becomes standby (sleep state) to save energy consumption.

Risk anticipation; Risk prediction and management are very paramount in the healthcare domain. Thereby, the main goal in this phase is to control and detect potential health risks in order to prevent it and minimize critical crises. For this reason, it is very important to propose a risk management plan that should identify the controlled situation, the critical of the result if it happens and its impact.

According to the WHO, uncontrolled diabetes during pregnancy give rise to a very dangerous effect on both mother and child as for instance with the risk of fetal loss, congenital malformations, stillbirth, and obstetric complications. However, the degree of severity of these risks depends on other factors and symptom such as hypertension, cramping, age greater than 40 years and so on. The next rule is formed as:

Event: an hyperglycemia is detected in a pregnant woman.

Condition: the woman has another disease (hypertension), her age is greater than or equal to 40, she has a cramping symptom.

Action: This woman has a high risk of fetal loss. rule: "Risk of Hyperglycemia in pregnant woman" When Patient(?p) sexe(?p, "woman") has-state(?p, pregnant) has-event(?p, Hyperglycemia) IF has-event(?p, hypertension) has-symptom(?p, cramping) hasage(?p,?a) swrlb:greaterThanOrEqual(?a, 40) Then has-risk(?p, fetal-loss) has-degree(fetal-loss, "High")

Treatment proposition; In this phase, diverse rules are defined to assist doctors in making an efficient and suitable treatment according to the diagnosis results. The proposed treatment can be a lifestyle recommendation, drugs proposition, and adjustment, or emergency service that requires the quick intervention of the medical staff. The next rule describes an emergency service for a pregnant woman. This rule is defined as Event: an hyperglycemia is detected in a pregnant woman.

Condition: the woman has a high risk of fetal loss.

Action: the woman needs an emergency service(e.g. ambulance).

rule: "Emergency service proposition for pregnant woman" When Patient(?p) has-risk(?p, fetal-loss)

IF

has-degree(fetal-loss, "High") Then need(?p, ambulance) Rules for alert generation; A generated alert from the MCOs is classified into three categories according to their importance (normal, medium and urgent). The normal alert is automatically produced by the MCOs where the analysis of the data is performed by the controller devices, and the decision is provided within the actuator devices. This kind of alert is usually used in simple cases (e.g., message contains the value of the detected signs). The medium alert is proposed in cases that need the intervention of medical staff, the data would be transferred to the healthcare professionals to analyze it and to propose the adequate alert that would then be sent to the MCOs of the patient. The urgent alert is provided when the medical staff detects a critical case, which needs urgent intervention. The following rule represents an example of a normal alert, which consists of: Event: hyperglycemia is detected in a pregnant woman.

Condition:

The woman has a MCO that contains an alarm actuator.

Action: The alarm state will be "ON" and the received message was "High blood glucose, contact your doctor". rule: "Normal Alert" When Patient(?p) has-event(?p, Hyperglycemia)

IF

Medical-Object(?o) contains(?o, Alarm) has-user(?o,?p) sexe(?p, "woman") has-state(?p, "pregnant") Then has-state(Alarm, "ON") has-message(Alarm, "High blood glucose, contact your doctor")

The next one describes an emergency alert triggered in critical cases. It is formed as Event: the patient (pregnant woman) needs emergency service (ambulance).

Condition: a hospital has an available ambulance.

Conflict of interest

The authors declare no potential conflict of interests.