Design an Adaptive Mechanism Model for Supporting the Prevention of SLAs Violation in a Context of COPD Patient Monitoring.

During recent decades, contextual computing applications have emerged in the field of healthcare and particularly in the field of telemonitoring of patients suffering from chronic obstructive pulmonary disease (COPD). According to WHO rankings, chronic obstructive pulmonary disease (COPD) is the third leading cause of death worldwide. Various research works are therefore carried out to improve the health of patients and the monitoring of patients in the comfort of their home environment. To this end, several telemonitoring systems are designed to COPD patients. These systems are connected to health center. Emergency physicians follow the patients subscribed to these systems remotely. These systems focus mainly on prediction, decision-making and the requirements of the healthcare profession, and do not address the quality control aspects of services or QoS based on service level agreements (SLAs). This situation can be dangerous for patients in case of extreme exacerbation of COPD patients. For example, the unavailability of the monitoring system can lead to the death of the patient because the emergency physician could not have access to the patient's data in real time in the context of COPD Patient Monitoring. In addition, Remote medical monitoring platforms are manipulating large volumes of data and the risks of data lost or data quality are real. It is therefore important to have the mechanisms to continuously improve the quality of service of these monitoring platforms in general and COPD patients particularly. In this article, we propose an ontology that uses SLA information from COPD monitoring platforms with dynamic data from the patient context . The purpose of this article is to propose a dynamic mechanism model for evaluating SLA violations. This solution allows retrieving knowledge from the main items of the SLA document based on XML and the COPD patient context data dynamically from a COPD SLA ontology. These data retrieved in real time allow the calculation of SLO-based metrics and display a SLA template available on the supplier and consumer interfaces. The information of the SLA violation control Interface changes dynamically depending the context-aware system and SLA document data. The SLA parties can dynamically control their Key Performance Indicators (KPI) Target.


I. Introduction
During the last few decades, ubiquitous computing, commonly referred to as pervasive/ubiquitous systems, has impacted the world of research. This revolution is materialized by many context-aware applications that have become important in different fields of research in general and particularly in the medical field. SLA was introduced in the 1980s. SLA today is considered a standard service agreement between the various parties. The SLA has been used in various fields such as telecommunications, call centers, security, cloud, health systems . One of the main features of the ubiquitous systems used in medical research is the coupling of context and software. This coupling of patient context and software offers the possibility in the medical field to carry out prediction, and the monitoring of patients, despite of many challenges. These healthcare systems focus mainly on prediction, decision-making and the requirements of the health care profession. However, they do not address well the quality control of services (QoS) based on service level agreements (SLAs) in the context of COPD diseases. This situation can be dangerous for patients in case of extreme exacerbation of patient COPD. Indeed, the lack of monitoring dynamic QoS [4] in COPD patients' systems can have dramatic consequences for the patient and affect their quality of life. For example, the delayed and unavailability of the monitoring system can cause the death of the patient because the emergency physician would not be able to have real-time data on the patient. In addition, Remote medical monitoring platforms are manipulating large volumes [4] of data and the risks of data lost or data quality are real. It is therefore important to have the mechanisms to continuously improve the quality of service of these platforms in general and COPD patients particularly. In this article, we propose an ontology that uses SLA information from COPD monitoring platforms with dynamic data from the patient context. The purpose of this article is to propose a dynamic mechanism for evaluating SLA violations. The solution allows to retrieve the main items from SLA XML documents based on WSA and then retrieve the COPD patient context data dynamically from a COPD SLA ontology. These data retrieved in real time allow the calculation of Key Performance Indicators (KPI) Targets based on Service Level Objective (SLO). The adaptive SLA model displays the result of SLA control. This model is available on the supplier and consumer interfaces in real-time. The information of the interface SLA control changes dynamically depending the context-aware system data and SLA document data. The SLA parties can dynamically control their Key Performance Indicators (KPI) Target. Our solution can be also deployed on different COPD patient monitoring systems, in the application layer to integrate quality control mechanisms. This paper presents our adaptive mechanism model of control SLA violations, in the context of monitoring COPD patients. The structure of the article is organized as follows: Section 2 describes the problem. Section 3 presents an overview of the related works. Section 4 describes the details of our proposal model. Section 5 presents Interface for supporting the prevention of SLAs violation. Section 6 gives conclusion and future works.

II. Problems Description
Quality of service (QoS) is important in the field of monitoring systems because context-aware applications must constantly adapt their services to the context [11]. This context changes dynamically and meeting QoS requirements becomes a challenge. Tamura explained [11]: '. These new requirements, such as having to fulfill changing QoS levels under different context situations, further exacerbate the problem of guaranteeing the expected quality of these services, especially under varying conditions of system execution.'. Context-aware applications must constantly adapt their services to the changing context. The question is how to dynamically monitor the service level agreement (SLA) during the adaptation activity in which context can be changed. Abawajy et al. [2] state: "An SLA model is a partially completed SLA document and defines the initial negotiable SLAs and the constraints (placed on the negotiable SLAs, such as lower limits of acceptable values)". In SLA models, we can identify the standard types of metric groupings, such as platform performance metrics, hardware performance metrics and software performance metrics. Khattak argues that Context Quality of Service (CQoS) errors [1], which can occur at any stage of the adaptation process, can have an impact on the quality of service provided by contextual applications. Khattak [1] also declared that: " (1) Context-aware information fusion is based on data received from a number of sources. (2) Some sensors may give false readings. (3) Some sensors may be offline due to low power levels". As an example of data acquisition, errors and failures sensor can provide erroneous data. At the inference level, the algorithms, on which the calculations are based, may be erroneous. All these situations can cause violations of service level agreements between the provider of context-aware applications and users or customers. In the field of COPD patient monitoring, several COPD patient monitoring systems are implemented but according to the literature, quality control is not fully ensured. This situation can be dangerous for patients in case of extreme exacerbation of patient COPDs health. Indeed, the lack of dynamic QoS monitoring of COPD patients of different severity levels can have dramatic consequences for the patient and affect their quality of life. For example, In light of the large volume of data manipulated by healthcare monitoring platforms, the problem of quality of service(QoS) of these platforms must be addressed by the actors (suppliers and customers) for the preservation of patients' health.. Therefore, how to monitor QoS violations in the context of dynamic COPD? In the Cloud computing, research is in progress in the implementation of SLA for business services, but in the context of monitoring the health of COPD patients, the mechanisms to control dynamically the quality of services is almost absent [4]. The different technical challenges are: 1) how to extract data and knowledge in SLA documents based on XML, WSA and dynamic data from the patient COPD context? 2) how to dynamically compile these data for the calculation of SLA control indicators and then display the main items in the adaptive SLA template? The analysis of existing approaches is important in order to be able to find the most appropriate solutions to address these issues.

III. RELATED WORKS
Shah et al. [16] discuss the concept of QoS for the health care system as a whole. The authors explain that these systems handle large volumes of data and that quality control mechanisms are needed to improve the quality of service. They [16] explain the importance of adapting the SLA approaches of the systems to a patient monitoring system. The quality of transmission of data collected on patients is a very promising area of research in the health field according to Khan et al. [4]. Thus, the field of body area networks (BANs) is an emerging field with applications for monitoring vital signs in addition to other contextual information. Khan et al. [4] proposed a solution for the transmission of patient data. The 'QoS Routing Protocol for Reliability Sensitive Data in Hospital Body Area Networks' [4] is an approach that ensures the quality of transmission of data collected from patients, but it does not guarantee transmission quality regardless of the large number of patients to be monitored. Furthermore, this approach does not provide a means or agreement between the patient and the clinic to monitor the quality of service. The requirements of patients are not addressed in the definition of this approach. In the same service quality approach, Kouame et al. [3] and Abawajy et al. [2] indicate that an SLA model is a document that defines negotiable Service Level Objective (SLO)s and constraints. In addition, other research projects have used SLA to improve System QoS. This is the case of the 'SLA predictive monitoring' project [6]. According to Comuzzi et al. [6], this research project presents a new definition of the reliability of SLA forecasts, which includes terms related to the variability of the service provision scenario in which a prediction is made. These predictions are based on SLOs, but this later project is limited by the lack of dynamic control of the SLA. In addition, the research project [5] indicated that: 'SLA based healthcare big data analysis and computing in cloud network' is proposed by combining big data analysis techniques with data collected from patients'. SLA according to Sahoo [5]: 'A PSNB method is proposed for big data analysis of healthcare and a CAM algorithm is also designed for dimension reduction to improve the accuracy of the PSNB algorithm. In addition, a GPS algorithm is proposed to prioritize patient emergency work'. Despite the contribution of this research project to prioritize patient emergency work, this project has limitations such as, non-dynamic SLA and absence of SLA violation control mechanism. The research project also [7] 'Cloud SLA Terms Analysis Based on Ontology' focused on the problem of SLA and QoS violation in the context of services offered by the Cloud. In the context of service offered by providers, this project allows subscribing consumers to monitor SLA violation, however the data for calculating the metrics are not extracted from a patient context and no adaptation mechanism is implemented. The authors even indicated the limitations of this approach [7]: 'For future work, we opt to enhance process by automatically predict SLA violation using context-aware system'. Finally, in the same vein, the AISel project [8] aims to help emergency physicians or practitioners to have relevant information and knowledge about COPD patients in order to better monitor their health status. This project proposes a VOS virtual organization to share knowledge between patient and practitioner actors in compliance with data protection laws. The organisation is based on SLA, a multi-agent system as explained in [8]:'Conceptual definitions of SLA parameters, metrics, and economic values as well as resource characteristics are given in an OWL DL ontology W3C'. The MORF project of Luke et al. [14], is a mobile patient monitoring system with 2 vital parameters: SAO2 and HR. This monitoring system seamlessly integrates vital data from different health services sensors to identify a patient's condition. The system can then take appropriate measures for timely support. It is an ontology-based system that generates alerts based on the values of vital parameters. This system uses ontology-based reasoning but the quality of service aspects of the system are not addressed. Finally, Labidi et al. [17], worked on an ontology-based SLA project. The objective of this project is to help users to better understand the terms of the SLA as part of the monitoring of its violation. Labidi et al. [17] explain: 'We describe the cloud SLA modeling and analyzing approach that assists consumers automatically analyze terms of various SLA documents'. Their approach is based on static data. They plan to integrate the dynamic aspect in their future work: 'For future work, we opt to enhance the SLA management process by automatically predict SLA violation using context-aware systems'.

IV.1 SLA Concepts & Approach
Telemonitoring is an essential activity to not only improve the quality of life of COPD patients but also to help emergency physicians make monitoring decisions with real-time data. Today, we are experiencing the emergence of several remote monitoring systems for COPD patients. As these systems are extremely important to the health of COPD patients and the quality of care, quality of service (QoS) must be assessed (add a reference HERE). Our proposal is based on a virtual, dynamic SLA that monitors the patient context and updates the violation control interface. According to [9] the SLA is the main document to guarantee the quality of services provided by a computer system. The SLA is defined as a Service Level Agreement. It defines a service agreement between the IT service provider and the consumer of these IT services. Kritikos et al. [10] argue that an SLA comprises a set of service levels (SLs) explicating the different performance behaviors that a service can exhibit. The different activities in the life cycle of an SLA are description, matchmaking, negotiating, monitoring, assessment, settlement and archive [15]. Different languages are used to model and implement the SLA. We distinguish [9]: WSLA, WSA, WSOL, RBSLA, LUA, SLALOM, and Q-SLA. The structure of the SLA document in WSA format allows to translate the SLA document into Preprints (www.preprints.org) | NOT PEER-REVIEWED | Posted: 24 August 2020 doi:10.20944/preprints202008.0526.v1 an XML file. In this XML file, we can easily extract the data with another XML-compatible language. Our approach described in the figure 1, is based on the WSA, XML compatible language. The figure 1 describes our approach to defining dynamic control mechanisms for SLA in a COPD monitoring setting. Indeed, our approach consists of four steps described below.

a) Step1 : Extraction Data and Rules
Data extraction consists in extracting information from the COPD patient context (patient parameters) and from the SLA (metric or KPI-Targets). On the SLA side, the information is the SLA items in WSA format and the rules. On the COPD side, the information source is the real-time database. b) Step 2 and 3: Semantic Analysis The step consist in analyzing the Items, proposing the rules based on the SLA side and on the context-aware system side, the information on the vital parameters data allow to populate in real time the COPDViolationSLaOntology ontology.
Step 3: Semantic Reasoning The COPD rules and patient data will be used in the reasoning process to generate the dynamic control services and populate the adaptive and virtual template.

c) Step 4 : Control Interface
Depending on the period chosen by the user, it is possible to control the SLA monitoring in real time. It is also possible for the user to set the control period. Example every hour. Whenever the patient context changes, the control mechanisms change the information in the template.

V.2 Dynamic control Architecture for COPD diseases based on SLA
The architecture of COPD adaptive control is described in four layers. The application layer which presents the interfaces emergency doctor, patient interface, emergency reception interface and triage. For each interface, two main functionalities are presented.

V.2.1 Application Layer
The application layer provides two categories of services i) Administrator Service and ii) Functional Services for the control of the SLA. The administrator service allows the emergency physician to create or delete vital signs parameters (FIEV, SAo2, HR, Temperature) with their respective limits, triage agent profiles and COPD patient profiles in the system. The functional services for SLA monitoring are available in the different interfaces described below. The control interfaces allow to dynamically monitoring the respect of the SLA according to the period chosen by the user.
▪ Emergency Interface The emergency physician's interface allows you to view the SLA control by period, to have alerts that adapt to the patient and SLA context. Only the emergency physician can cancel the SLA.
▪ Triage Agent Interface The agent interface allows you to view SLA monitoring by period, to have incident alerts that adapt to the patient context and SLA e context. The CODP patients triage dashboard at the emergency reception desk is dynamically updated.
▪ Patient Interface The agent interface allows to view SLA monitoring by period, to have incident alerts that adapt to the patient context and SLA Patient Interface context .V.

Reasoning Layer
The reasoning engine is mainly based on rules, KPI_TARGET extracted from the SLA and income Data sensor. The reasoning process consists of 4 phases: the phase of identification of the metrics items or KPI-TARGET, the detection incident phase result from comparison of the vital data of the four parameters collected on COPD patients, the phase of implementation of the SLA violation control algorithm and the phase of SLA virtual Template. The rules concerning Key Performance Targets or metrics allow to know the metrics of the SLA and specially to know the classes, relationships and properties to which these metrics are attached. These rules are important for the SLA violation evaluation mechanism. The two metrics of the dynamic SLA violation monitoring mechanism in the context of patient COPD monitoring are: The number of incidents from patient data numberIncidentData and the number of incidents of unsuccessful patient queries numBeRequestSend. The SLA violation rules are proposed based on the definition of the concept of violation. In effect, if the number of incidents is greater than the metric defined in the KPI-Target, then there is a violation of the SLA. The rules for the SLA evaluation mechanisms are important for dynamically triggering the control of the SLA according to the data of the context-aware and the data of the SLA document in WSA format. ▪ Identification KPI-TARGETS Phase The information extracted from the SLA can be grouped into two parts: Content Items and KPI-TARGET. The KPI-TARGETs participate in the assessment or dynamic control mechanisms of the SLA. The other Content Items will populate the virtual adaptive SLA template. KPI_IncidentDataValue and KPI_IncidentRequestValue are important items for the mechanism of violation's SLA assessment.

▪ Detection Incident Rules Phase
To design these rules we consider that for every vital sign parameter, there is an interval with a minimum and a maximum value, in which the value of the sensor is considered as data incident. The Table 2 describes the different rules to detect incident data for the SLA evaluation mechanism.  ▪ SLA violation control algorithm Phase There are two approaches to the reasoning process: the data incident approach and the request incident approach. For data incidents, the reasoning is performed as soon as the following data are inserted in the dynamic database: FIEVSensorData, SAo2SensorData, HearateSensorData, TemperatureSensorData. For each data of parameters, the system checks through each rule if it is an aberrant or erroneous value. If it is an aberrant or erroneous value then it is classified as a data incident. The system increments the AlarmLevelIncrement data incident counter. Then the system compares AlarmLevelIncrement with the metric KPI_IncidentValue extracted from the SLA. If AlarmLevelIncrement>KPI_IncidentDataValue then the data quality SLA violation alarm is triggered. For request incidents, the incident counter (IncidentRequestNumber) is calculated as the difference between the number of incidents (RequestSendNumber) sent to the emergency physician by patients and the number of requests (RequestReceiveNumber) confirmed or received by the emergency physician in a period. The system then compares KPI_IncidentRequestValue extracted from the SLA to IncidentRequestNumber. If IncidentRequestNumber >KPI_IncidentRequestValue then the requested QoS SLA violation alert is triggered. All of these mechanisms are implemented in the SLA violation algorithm. This algorithm represents the core of the system's reasoning.

Figure 3: SLA Quality Service Violation Algorithm
▪ Populate Phase The populate phase consists in displaying the results of the evaluation algorithm SLA Violation to the virtual template. These results will therefore be accessible from the interface in a dynamic mode.

IV.2.1 Semantic Layer: Development of COPD Violation SLA Ontology domain
Ajami and Mcheick [18] explain that the semantic approach is a formalism often used to interpret complex information. With the protected SWRL tool, it is possible to perform queries based on concepts or classes [18]. According to Ajami and Mcheick [18]: 'Ontology is considered to be one of the richest semantic structures for facilitating the representation, integration and reasoning of knowledge'.

a) Structure of COPD Violation SLA Ontology
The figure 4 shows the core of the COPDViolationSLaOntology structure. Each component of this structure is an ontology that participates in the implementation of the dynamic evaluation mechanisms of SLA by the different parties. Each component is reusable to enrich other SLA ontologies. This structure is modular. Each module is described in detail in the following sections. This structure can be linked to the standard COPD i.e. COPD ontology from the Patient COPD Ontology component. Finally, our ontology can also be linked to the SLA Ontology from the SLA Ontology component. COPDViolationSLaOntology is therefore not an isolated structure. It is a modular ontology that is reusable and extensible with SLA Ontology Standard, COPD. The objective of this ontology in the construction of SLA control mechanisms is the dynamic collection of COPD patient data. The data come from the vital parameters Fiev, Heartrate, Sao2 and Temperature. The ObjectProperty and Datatype relationships of this ontology are described in Figure4. Only the main relationships that participate in the dynamic control mechanisms of the SLA are described in Figure 3. In the evaluation mechanism, the current value of the parameters will be compared to the Min and Max values of each row of vital parameters. The object property relationships that participate in the SLA violation evaluation mechanisms are: hasTemperatureSensorData, hasHeartRateSenSorData, hasSAO2SensorData, and hasFIEVSensorData. Indeed, these relationships allow the collection of temperature, heart rate, Oxygen Saturation and FIEV data respectively from the sensor installed on COPD patients. The collected data is evaluated according to the rules defined in the reasoning section for each defined collection time period determined by the emergency physician. During this period, if the collected data does not satisfy the rules then the reasoning engine increments the SLA violation incident counter. When the counter reaches the limited trigger threshold defined in the KPI-TARGET Data Incident then the inference engine allows the SLA violation alert to be triggered. Figure 5. COPD Patient Ontology Patient ontology is structured into two main branches: vital parameters, psychological profile parameters and patient's personal information. The vital parameters represent the core of the evaluation mechanism. The SLA control rules are mainly based on the values of these parameters. For example, if the current value of the temperature does not belong to min and max, then there is a data incident. The SLA control counter is then incremented. If the counter value is beyond the KPI-TARGET limits, then the SLA control mechanism triggers the SLA violation alert according to the period chosen by the user. All signatory actors are automatically informed. This is therefore the main ontology.

b) SLA items ontology
This ontology aims to provide information about the SLA context. For this purpose, it only addresses the description of the different Items of the SLA. The items that are mainly involved in the mechanisms of control SLA are KPI-TARGET, Services and SLO. The ObjectProperty and Dataproperty that characterize them are represented in the main table. The hasKPI_Expression_IncidentRequest and hasKPI_Expression_IncidentData relationships will identify the incident levels discussed with the various parties signing the SLA.
Indeed, the value of the data incident counter is compared to the KPI-Target defined in the SLO expression related to the data: KPI_Expression_IncidentData. The same is true for the query incident request counter value, which is also compared to the SLO expression related to the queries requests: KPI_Expression_IncidentRequest. The details of the SLA Item ontology are described in Figure 6 below.
To design the ontology, we first performed an analysis to identify the concepts that will allow better control of the violation in a COPD patient surveillance context. For this purpose, we analyzed the SLA document and the patient surveillance information in order to propose the concepts, ObjectProperty , relations and dataproperty.
Finally, these elements are entered in Protégé software for analysis and reasoning. The classes in blue color are the classes that participate in several modules. The elements in orange color are the dataproperty types. Concepts in gray are important concepts for this module Preprints (www.preprints.org) | NOT PEER-REVIEWED | Posted: 24 August 2020 doi:10.20944/preprints202008.0526.v1 Figure 6: SLA Item Ontology

a) Violation Data Concepts and Alarm Managment
The purpose of this ontology is to record violations with different time periods in relation to the data. It then provides the information to the template dynamically. The Items or concepts that mainly participate in the SLA control mechanisms are the vital, patient and violationSLaDataConcepts parameters. . The hasAlarmViolationSlaManagementProfile and IncrementAlarmLevel links will respectively associate the incident to the patient concerned and increment the incident counter to compare it to the KPI-TARGET extracted from the SLA. The hasAcquisitionRate relationship allows the emergency physician to define data collection periods. This approach makes the SLA control system more flexible. collection period with the request incident control algorithm. If there is an incident request, then an alarm is generated with the hasGenerateAlarmRequest relationship. Then the request incident counter is incremented with the relation hasIncrementAlarmLevelRequest.

Figure 8: Violation SLA Request concepts and alarm managment
The main branch of this ontology that participates in SLA control mechanisms is Request, ViolationRequest_Concepts. A Request incident occurs if the sent request has not been received by the emergency physician i.e. the status of the request is not confirmed. The difference between the number of requests sent and the number of confirmed requests in a period determines the number of Request incidents. The concept or class allows to record these incidents and to populate the virtual template dynamically according to the period.

c) Subscription to Service Monitoring COPD ontology
This ontology is not directly involved in the control mechanisms of the SLA, however it provides important information to enable the control mechanisms to function correctly and, above all, to arrange the interfaces adapted to the context. Indeed, it provides information such as the connected patient, the services concerned by the SLA. Then the dynamic interfaces with different functionalities allow controlling the SLA by selected periods. The items that mainly participate in the SLA control mechanisms are patients, service and SLA actor. The hasSubscribeSystemCOPDMonitoring relationship allows the subscription of the COPD patient, the emergency physician and triage agent. For each contract with the COPD monitoring system, a service or services are assigned to the subscribed patient. No branch of this ontology is directly involved in the control mechanisms of the SLA, but only the interfaces of the actors can make it possible to see the results of the control according to the chosen period.

IV.1.3 Acquisition Layer
The collected data refer to the parameters presented in the table below, but for the evaluation of the SLA, we focus on vital parameters only.  There are two categories of data. On the one side, there are static data: Age, BMI, Gender, Medical history. These data are available in the patient's medical records and only the emergency physician can consult them. On the other side, there are dynamic data collected from the sensors: Vital Parameters and Symptom Parameters. The data incidents for the evaluation of SLA are mainly concerned vital parameters. Decisions in a monitoring system are fundamentally based on the quality of the data. Incorrect data can influence the emergency physician's decision-making process. A wrong decision can have a negative impact on the patient's health. Evaluating the data aspects of the SLA aims to improve the quality of service. The other aspect of the SLA assessment concerns the requests transmitted to the emergency physician by the patient. A request incident occurs when a request sent by the patient has not been received by the emergency physician for any reason.

V Design of Virtual and Adaptative Template SLA
The purpose of Virtual SLA is to dynamically monitor quality of service (QoS) guarantees of SLA in a COPD patient monitoring context. This template has two parts. Part 1 represents the offered service that has been validated by the parties. If the data of the Part 1 is changed the Virtual template will also be modified in real time. In addition, Part 2 presents the dynamic control elements of the SLA. This part adapts dynamically according to the data of the patient context and the context-aware ubiquitous system. Finally, the information described in these two parts is extracted from the ontology presented in the previous sections. To allow a better understanding of the Virtual SLA template, important concepts are presented. According to the literature [17], the SLA template must have important information: SLO, KPI-TARGETS, CONDITION the agreement. Concerning the SLO, Labidi et al. [17]

VI. CONCLUSION
At the end of this research project, several contributions can be noted. One of the major contributions is that, however large or small volume of data manipulated by the COPD monitoring platforms, our SLA violation control mechanism allows us to monitor the quality of the data and thus allow the ER physician to improve the quality of service provided to COPD patients. . Firstly, our solution allows the dynamic evaluation of the SLA by extracting relevant data from the SLA Documents and extracting dynamic data from the patient COPD to populate an SLA violation control ontology. Second, our solution provides Virtual and Adaptive SLA for SLA violation prevention. Thirdly, Virtual SLA is accessible to all SLA stakeholders from their context-aware application-based interface. Finally, the implementation of SLA in health monitoring systems in general and COPD patients' health particularly, is a big step forward. Indeed, physicians will now be able to monitor the quality of service and make quality decisions. Patients will also feel even safer and this contributes to improving their quality of life. In the future experimental article, the proposed model will use this algorithm and rules (SWRL) to populate, dynamically the virtual SLA presented in the previous sections.