An Ontological Approach for Early Detection of Suspected COVID-19 among COPD Patients

Abstract

Recent studies on chronic obstructive pulmonary disease (COPD) patients in the context of the coronavirus 19 (COVID-19) pandemic have reported two important problems, i.e., high mortality and vulnerability among COPD patients vs. non-COPD patients. The high number of deaths are caused by exacerbations, COVID-19, and other comorbidities. Therefore, the purpose of this article is to reduce the risk factors of COPD in the COVID-19 context. In this article, we propose approaches based on adaptation mechanisms for detecting COVID-19 symptoms, to better provide appropriate care to COPD patients. To achieve this goal, an ontological model called SuspectedCOPDcoviDOlogy has been created, which consists of five ontologies for detecting suspect cases. These ontologies use vital sign parameters, symptom parameters, service management, and alerts. SuspectedCOPDcoviDOlogy enhances the COPDology proposed by a previous research project in the COPD domain. To validate the solution, an experimental study comparing the results of an existing test for the detection of COVID-19 with the results of the proposed detection system is conducted. Finally, with these results, we conclude that a rigorous combination of detection rules based on the vital sign and symptom parameters can greatly improve the dynamic detection rate of COPD patients suspected of having COVID-19, and therefore enable rapid medical assistance.

1. Introduction

Since 2019, the world has been affected by the coronavirus 19 (COVID-19) or SARS-CoV-2 (the name of the virus) pandemic, which has caused many deaths. Although all people are exposed, patients with chronic diseases remain the most vulnerable since they face a high risk of death. The mandatory social-distancing measures that have been implemented to combat the high infectiousness of the disease have increasingly encouraged the use of telemedicine. Telemedicine is also used to assist patients from their homes or the hospital. These patients often suffer from breathing difficulties caused by chronic obstructive pulmonary disease (COPD).

Chronic obstructive pulmonary disease (COPD) encompasses a group of lung conditions that cause breathing difficulties, due to damage to and inflammation of the lungs and airways. The disease consists of emphysema associated with chronic bronchitis [1]. Its common symptoms are increased breathlessness that may occur during exercise or at night, persistent coughing, persistent chest infection, and wheezing [1]. COPD is usually associated with a long history of cigarette smoking. According to Stiell [2], COPD patients may experience exacerbations and serious complications after hospital discharge. Exacerbations can be identified and treated. However, within the context of the COVID-19 pandemic, COPD patients may either experience exacerbations or contract COVID-19. Real-time detection of suspected cases would enable doctors to manage cases of COVID-19 and provide appropriate care, different from exacerbation care.

A mechanism of adaptation is a set of approaches to provide appropriate service based on context. Weiser [3] reported that a ubiquitous system provides service anywhere, anytime, depending on the context. In this article, we propose an ontology-based mechanism of adaptation, to identify early COPD patients suspected of having COVID-19. Our ontology is composed of five ontologies reused from the Ajami [4] project, and five ontologies built during our project. Our proposal enables us to establish a generic detection process with the Semantic Web Rule Language (SWRL) engine, at the earliest possible stage, for any abnormal evolution, and, consequently, improves the medical diagnosis for COPD patients with COVID-19 in particular, for elderly patients.

Protégé [5] is an ontology building tool in addition to using “implement” language. We propose a solution based on ontology because ontology allows us to manipulate several rules as well as generate alerts and other rules, using the power of the inference engine integrated into the Semantic Web Rule Language (SWRL) language of the Protégé [5] platform. In addition, ontology can be used to extract knowledge from other questionnaires or ontologies, enriching the COPD medical domain.

Our solution is to design a COVID-19 ontology model, as well as an alert system combining vital sign parameters and symptom parameters, to identify suspected early cases of COPD patients with COVID-19. With the power of the SWRL reasoning engines of the Protégé [5] Ontology Web Language Description Logics (OWL/DL) tool, this alert system uses standard COVID-19 test criteria [6] and dynamically collected data from the COPD patient context to detect suspected cases. First, if the results of the assessment of vital signs (temperature, fever, and Spo2) are positive, the alert system automatically proposes a questionnaire form to the patient or nurse staff. This questionnaire based on the symptom parameters invites patients to answer a question about their health state.

Finally, this article is organized as follows: In Section 2, we describe the state-of-the-art and methods; in Section 3, we present an architecture for COVID-19 suspected detection; in Section 4, we provide the experimental results; in Section 5, we discuss contributions and limitations; and in Section 6, we state our conclusions and future work.

2. Materials and Methods

2.1. Related Work

Alert and detection mechanisms aim to prevent complications of a disease. According to Sahoo et al. [7], the implementation of telemedicine systems is necessary for the protection of COPD patients against COVID-19, “As COPD patients are at an increased risk of severe outcomes if they became infected with COVID-19, it is recommended that patients and clinicians establish effective plans for ensuring prevention, such as using tele-medicine to ensure that COPD receives the best care.” Smith et al. [8] believes that detecting COPD and telemonitoring exacerbations accelerate recovery, improve quality of life, and reduce the need for hospitalization, as patients may not recognize worsening symptoms, resulting in a delay in treatment.

Ajami and Mcheick [4] proposed an integrated solution that makes recommendations and alerts to physicians for the treatment of COPD exacerbations. The limitations of their solution are the absence of COVID-19 screening rules in ontology reasoning. Paganelli et al. [9] worked on a research project of alert mechanisms based on ontology, to involve medical staff (nurses, doctors, and emergency physicians) according to the level of alerts (very low, low, medium, and high). However, their studies lacked COPD patient rules, detection approaches, and rules applicable to COVID-19. In effect, the objective of Lassierra et al. [10] was to contribute to personalized clinical management by developing an ontology-based solution that could provide the ontological representation of a wide range of scenario detection. One interesting part of their research is the possibility of the patient filling out a questionnaire to provide symptom information, which is used by the reasoning mechanism to activate different types of alarms. Questionnaires help to investigate exacerbation symptoms. Exacerbations, in general, and COVID-19, in particular, are complex for COPD patient health because the distinction between exacerbations and COVID-19 is not obvious in the pandemic context. Furthermore, Benlamri et al. [11] proposed an ontology-based alerting mechanism for mobile applications. These mechanisms use two vital parameters, i.e., temperature and heart rate. The alarm action properties affect what actions the system performs based on each alarm level. The following four actions can be assign to each alarm level in any number of desired combinations: change the data acquisition rate, gather Global Positioning System (GPS) location data, send out a Short Message Service (SMS) alert, or send an email. This project proposes different levels of alerts according to different rows of parameters. The data transmission uses Bluetooth systems, which remain limited in a COPD patient-monitoring context with exacerbation. Bluetooth cannot support large volumes of data manipulated on medical platforms.

Despite these limitations, telemedicine is developing several surveillance projects to protect senior citizens. Among these projects, Andres et al. [12] reported that several telemedicine projects of detection in chronic diseases have recently been developed, in France, such as SCAD (remote cardiological, monitoring), PIMP’s (interactive healthcare platform), OSICAT (optimization of ambulatory heart failure monitoring with telecardiology), and MEDICA (home electronic monitoring of chronic heart failure) [12]. However, no published results were available from these projects.

Furthermore, He et al. [13] introduced the Coronavirus Infectious Disease Ontology (CIDO) which is a community-based ontology for coronavirus disease knowledge and data integration, sharing, and analysis within the field of informatics. Liu et al. [14] proposed a project named “Ontological and bioinformatics analysis of anti-coronavirus drugs and their implication for three drug repurposing against COVID-19”. Liu et al. [14] stated that their ontology-based bioinformatics strategy could enhance network standardization and computer interpretation in a logical, interoperable, and consistent way, leading to improved prediction of drugs for COVID-19.

Finally, COVID-19 alert tools exist. Some popular alert tools are CoronaMap [15], COVID-19 SAFETY SOLUTION [16], Rombit [17], MILA [18], COVIDSAFE [19], ReelyActive [20], and COVID Alert, which is an additional tool to identify COVID-19 risks with aggregated information. CoronaMap offers a WHO COVID-19 Dashboard. COVID-19 SAFETY SOLUTION is also an alert system that protects workers with social-distancing alerts. Rombit and COVID also provide a system that protects workers with social-distancing alerts. MILA provides information on social-distancing measures offered by public-health authorities. COVIDSAFE uses Bluetooth® technology to help identify users who have been in contact with someone who has tested positive for COVID-19. ReelyActive is digital contact tracing and is an automated means of detecting and recording close physical interactions between people, providing traceability of contact with any individual who tests positive for infectious diseases, and offering peace-of-mind, to evaluate and respond to risk effectively [20]. The common limitations of these tools and applications include the following: (a) no personal data, (b) no geolocation, (c) no timestamps, and (d) no adaptation mechanisms or other aspects of vital sign assessment in real time. For example, MILA does not offer the adaptation mechanisms to propose services depending on patient context information. In our research, we focus on adaptation mechanisms to propose alerts services, using information about COPD context.

Table 1. Existing COVID-19 alert applications.

Application Alerts	Disadvantages/Limits
(1) ReelyActive	No personal data, no geolocation, no timestamps, no adaptation mechanisms, no vital sign assessment in real time No agreement to monitor QoS
(2) Rombit	No vital sign assessment in real time, no adaptation mechanisms using the context-aware system
(3) Covid-19 Safety solution	No vital sign assessment in real time, no adaptation mechanisms using the context-aware system
(4) MILA	No vital sign assessment in real time, no adaptation mechanisms using the context-aware system
(5) COVIDSAFE	No vital sign assessment in real time, no adaptation mechanisms using the context-aware system
(6) CoronaMap	No personal data, no adaptation mechanisms

summarizes the limits of each COVID-19 alert application.

2.2. Methods and Tools

2.2.1. Protégé Ontology Editing Tool

The hardware used for our experimental platform was a laptop and a server. The software platform used was Protégé [5] ontology. For the application development, we used Python, SQL server, and the integrated ONTYP platform for the database. Python is open source. For the questionnaire aspects, and the collection of information from COPD patients, we used Google Forms. The use of the protégé tool is described as follows: (1) “extraction of knowledge from the simulated database”; (2) “queries are built with the Protege query tool”; (3) “the Protégé...”; (4) “the Protégé tool displays results of OWL queries”.

The protégé framework is described in Figure 1.

2.2.2. Database Presentation

The database contains information on patient profiles, vital sign parameters data, alert information, and symptom parameters data collected from the symptom investigation questionnaires. The main objects or tables of this data base are: T_Patient, T_SensorData, T_Parameter, T_VitalSignData, T_SymptomData and T_Alert. Figure 2 describe the structure of the table for T_SensorData.

Figure 3 below presents the main components of the data conceptual model.

3. Architecture for COVID-19 Suspected Detection in the Context of Monitoring COPD Patients

3.1. System Architecture

As shown in Figure 4, the architecture of our proposal is composed of four layers: the data acquisition layer, representation layer, processing layer, and application layer. Figure 4 also describes the mechanism related to detecting suspected COVID-19 cases among COPD patients.

Sensors installed on COPD patients collect information on vital sign parameters from the patient context. Then, the dynamic data is stored in a dynamic database. Data collected from patients represent context information.

The adaptation engine evaluates each data range according to the COVID-19 detection rules. Depending on the result of the assessment and symptom evaluation, the adaptation or inference engine proposes the appropriate service. This service can be COVID-19 alert, patient alert for actual COVID-19 test, and vital sign alert. The set of actions constitute mechanism adaptation. Adaptation engine belongs reasoning layer of Architecture for COVID-19 suspected detection described in Figure 4.

In Section 3.1.1 and Section 3.1.2 below, we describe the different layers of this architecture for COVID-19 suspected detection.

3.1.1. Data Acquisition and Representation Layers

The data has been collected from sensors, installed on COPD patients at home, in their residences, or hospital rooms. These data populate a dynamic database containing vital parameter data and also patient profile data, such as age, BMI, address, surname, first name, and medical history. Then, these data are evaluated by the alert mechanisms (ontology). In a representation view, the ontology (classes, object, and data properties) is represented according to the OWL/DL model (RDFs).

Table 2. List of COPD patient parameters.

Profile Parameters	Symptom Parameter	Vital Sign Parameters
1. Gender (male, female)	5. Dyspnea (EVA)	12. Pulse ox (Spo2) (% O2)
2. Age (year)	6. Shortness of breath	13. HR or heart rate (pulses per minute)
3. Body mass index (BMI)	7. Cough	14. Temperature (℃)
4. Medical history (medical background)	8. Sputum	15. Fiev1 (%)
	9. Infection
	10. Respiratory symptom wake you up
	11. Wheezing

describes the patient parameters. The context concerns only the patient context, which includes the data for the 15 parameters described in Table 2. These data regard the parameters of vital signs, profiles, and symptoms. The following are examples of data parameters: buccal temperature = 38.7 °C, Fiev = 88%, heart rate = 105, Spo2 = 87% (O₂), gender = male, BMI = 17, age = 50 years. Spo2 helps determine the O₂ rate in the patient’s blood. The color of sputum is used to detect symptoms of COVID-19.

The time granularity at which patient parameters are measured can be every 3, 6, or 9 h. Time granularity depends on the physician’s approach.

3.1.2. Reasoning and Application Layers

The reasoning approach used by the adaptation engine to realize alerting and detecting COPD patients suspected of having COVID-19 is rule based. Rule based is an adaptation technique used during adaptation activity. As an example, a buccal temperature greater than 38.5 °C and the patient having a headache is a rule for detection of COVID-19. For each temperature range and each headache symptom, the adaptation engine checks if the temperature data range and headache assessment match with the rule. If they match, then, the inference engine triggers the appropriate service to dynamically inform patients or healthcare staff. This process is executed for a while. The setup of action constitutes the mechanism adaptation. The standard COVID-19 [6] detection criteria is the following: temperature, fever, Spo2, headache, and fatigue. The reasoning approach consists of two parts. The first part realizes the assessment of vital sign data. If the result is positive, the system triggers the COVID-19 symptom investigation questionnaire. The reasoning engine, in this part, uses the answers from the questionnaire as input to provide support services. These services are the following: Service 1, call COVID-19 testing service or 911; Service 2, alert the detection of a COVID-19 suspected COPD patient profile; Service 3, Dashboard COVID-19 COPD patient profile, and to the application layer. Figure 5 describes the reasoning process.

3.2. Design Ontology for Symptoms COVID-19 Detection in COPD Patients

Ontology Overview and Methodology for Building Ontologies

○

Ontology Overview

The most common and accepted definition of ontology in the research community is that proposed by Studer et al. [21], “an ontology is a formal, explicit specification of a shared conceptualization”. Conceptualization refers to an abstract model of a certain phenomenon in the world. The reasons that motivated the choice of ontology for our research were the provision of high and formal expressiveness, supporting reasoning techniques, the ability to reuse existing representations, and the complexity of medical rules.

Figure 6 describes the percentage use of our ontology as compared with other models [21].

Other models include the programming object-oriented model, key-value model, and graphic model.

The use of models that are not based on an ontology requires significant programming effort and strongly links the context model to the rest of the system [21,24]. There are manual and semi-automated approaches to ontology building [25]. Indeed, researchers are trying to overcome these drawbacks of manual ontology construction by using semi-automatic or automatic methods to construct ontology [25].

○

Methodology for Building Ontologies

Sánchez [26] combined two well-referenced methodologies, METHONTOLOGY [27] and Cyc 101 [27], to obtain one of the most concrete methodologies [28,29,30,31] for building medical ontologies.

Table 3. The steps in Sanchez’s proposal.

Step	Description and Purpose
1	Determine the domain and scope of the ontology, COPD domain, and alert management.
2	Ontology reuse and addressing poor ontological coverage of pulmonary diseases.
3	Development of a conceptual model.

describes the steps in Sanchez’s proposal.

The steps in Sanchez’s proposal used to build the ontologies were as follows: Step 1, COPD domain; Step 2, four components of COPDology are reused; Step 3, five ontologies are built.

According to Ajami [4], COPDology is a specific model of the medical field collected from numerous research documents and obtained from pulmonologists. COPDology contains concepts related to disease, environment, equipment, patient data (personal information, symptoms, risk factors, and clinical test results), and treatment [4]. Figure 5 describes some of these concepts. Our ontology (SuspectedCOPDcoviDOlogy) will enhance this COPDology for detecting COPD patients exposed to COVID-19. The ontologies created during this research project are red, and the reused ontology is white. The reused ontology was built by Ajami and Mcheick. Reuse and extensibility [32] refer to the possibility of using existing ontology in a new project. Modifying existing ontology is referred to as extension; unmodified ontology is considered to be a reuse approach. The ontologies that have been constructed in this research project are evaluation vital sign ontology, symptom COVID-19 ontology, questionnaire ontology, alert ontology, and service ontology. The ontologies that have been reused in this research project are location ontology, patient ontology, device ontology, and COPD disease ontology.

The patient’s ontology consists of three main branches, i.e., physical factors, psychological factors, and personal information. The main information of the reused ontology is described as follows: Device ontology covers the mobile device used to collect and send data as well as all fixed and portable biomedical equipment used by the patients to monitor their vital signs, in addition to environmental sensors to detect any change in the environment [4]. Location ontology serves to determine the physical parameters to be measured, where relevant contextual information varies between indoor and outdoor spaces [4]. A disease ontology comprises the type of illness, stage, treatment, risk factors, conditions, and physical characteristics of the disease [4].

In this article, we focus only on the ontologies that we have created to support the detection of suspected COVID-19 cases. Figure 7 presents the SuspectedCOPDcoviDOlogy ontology overview. Based on Sánchez’s [26] approach, the following four steps should be realized: (1) identify the terms, (2) identify their relations, (3) identify attributes, and (4) create instances of the ontology.

The steps used in designing our five ontologies are given below. These ontologies use detection rules described in

Table 4. Detection of suspected patient’s rules.

Type	Rules-Based on Ontology Web Language Description Logics (OWL/DL/SWRL)
1. Evaluation vital sign (Rule1)	Patient(?P)^SensorDataBucaTp(?BT)^hasSDBTp(?P, ?BT)^SensorDataFev1(?Fv) ^hasSDF(?P, ?Fv) ^SensorDataSpo2(?Sp) ^ hasSDSp(?P,?Sp)^hasCurrentValue(?Sp,?cv)^hasRangeMin(?Sp,?Min) ^ swrlb:lessThanOrEqual(?cv, SPmin) ^swrlb:greaterThanOrEqual(?BT,BTmax) -> has_TriggeredQ(?QE, Posif), SendMessage(?He)
2. Identification suspected (Rule2)	Patient(?pt)^Fever(?fv)^hasSymptom_Fever(?pt, ? Fv)^Cough(?cg) ^ hasSymptom_Cough (? pt, ?cg)^headaches (? hd)^hasheadaches(?pt,?hd)^Extreme_tiredness(?et) ^hasSymptom_Extreme_tiredness (?pt, et) ^Pneumonia (? pm)^hasSymptom_Pneumonia(?pt, ?pm)^SensorDataBucaTemp(?bt) ^hasSDBTp(?pt,?bt)^SensorDataFev1(?fv)^hasSDF(?pt,?fv)^SensorDataSpo2(?Sp)^hasSDSp(?pt,?Sp)^hasCurrentValue(?Sp,?cv)^hasRangeMin(?Sp,?Min) ^ swrlb: lessThanOrEqual(?Cv,spmin) swrlb:greaterThanOrEqual(?bt,Btmax) –> SuspectedCOVID-19Alert (?pt, Suspected)

to identify suspected COPD patients.

Table 4 describes the rules that enable the detection of suspected patients.

Rule 1 means, for any patient instances and all instances of vital parameters, if the percentage rate in the blood is smaller than a minimum (80%), with a temperature greater than a maximum (38.5 °C), then, an alert is sent to the health care staff.

○

Evaluation Vital Sign Ontology

We identify the key terms of our domain, such as sensors, sensor data buccal temperature, FEV1, SPo2, medical profile, and patients. Next, we identify the relations between these entities (terms), such as isPartOf, collectsData, hasSDF, hasId, and isa. Finally, attributes are identified and linked to entities, such as hasPhone, hasFname, and hasLname. Details of these elements are given in Figure 8.

The concepts of this ontology are proposed according to the criteria of the first symptoms of COVID-19. SensorDataFEV1, SensorDataSpo2, and SensorDataBuccaTp are concepts in the ontology approach, but their instances represent data collected from sensors. The following are examples of such instances: SensorDataFEV1 = 88%, SensorDataBuccaTp = 38.8 °C, and SensorDataSpo2 = 80%. If a patient’s vital signs range matches with the COVID-19 vital signs rule, then, the alert vital sign and the COVID-19 questionnaire are activated. Furthermore, a message is sent to healthcare staff (physicians, nurses, etc.) for information. Figure 8 describes the vital sign assessment based on Rule 1.

Engine reasoning uses Rule 1 to trigger questionnaire forms if the evaluation of a vital sign parameter is positive.

Table 5. Some concepts of evaluation vital sign ontology.

Object Property	Domain	Range	Datatype Property	Domain	Range
hasSDBTp	Patient	SensorDataBucaTp	hasFname	Profile	String
hasSDF	Patient	SensorDataFEV1	hasLname	Profile	String
hasSDSp	Patient	SensorDataSpo2	hasGender	Profile	String
hasAlertcovid	Patient	AlertVitalSign	Hasphone	Profile	String
hasTriggeredQ	AlertVitalSign	Questionnaire	hasAdress	Profile	String

presents some concepts and properties of the vital sign assessment ontology. The questionnaires are used to assess the symptoms of COVID-19 for patients with a positive vital signs result. The information is extracted from Google Forms by program, and then transmitted to populate the ontology.

○

Questionnaire Ontology

The questionnaire has seven questions, and patients answer during the process of assessing for symptoms COVID-19. These questions concern pneumonia, extreme tiredness, cough, headache, difficulty breathing dyspnea, headache, vomiting symptom, abdominal pain symptom, cough questionnaire, sensory loss questionnaire, fever sensation questionnaire, chills questionnaire, losing taste questionnaire, muscle stiffness questionnaire, diarrhea symptom, gastrointestinal symptoms, diarrhea symptom. The questionnaire helps to better provide data for assessing symptoms that sensors cannot collect in real time. Figure 9 presents the questionnaire ontology.

When a COPD patient answers positively over several periods, the system identifies the patient as a suspect case to be monitored. The detection system, then, displays it in the dynamic dashboard of suspected cases. Then, the system sends a recommendation to the patient to receive a COVID-19 screening test.

○

Symptom COVID-19 Ontology

The answers provided on the questionnaires are extracted by this ontology; indeed, they go into an excel file generated by Google Forms. Information is saved in a Database. The SQL program (object data) reads this file and sends it as instances in the ontology. Then, answers are evaluated with criteria based on Rule 2 from Table 4. If the patient has one of the symptoms, then, the system sends an alert to healthcare staff and a recommendation to the patient to receive a COVID-19 screening test is triggered. Figure 10 presents three symptoms for detecting suspected patient Ontology.

Rule 2 is based on the symptom-based investigation to confirm whether the patient is a suspect case of COVID-19 according to symptoms-related criteria.

Table 6. Four properties that are Involved in the detection system.

Object Property	Domain	Range	Datatype Property	Domain	Range
isPartOf	Cough Symptoms	Symptom Covid-19	Id	Symptom Covid-19	Integer
Answers	Patient	Questionnaire	Name	Patient	String
isSuspected	Patient	Symptom Covid-19	hasStatut	Symptom Covid-19	String
Has	MedicalProfile	Patient	hasBMI	MedicalProfile	String

describes some properties that are involved in the detection systems.

○

Alert Ontology

The healthcare staff receive the alert messages, such as SMS or emails, if a COPD patient has been detected as a suspected patient with COVID-19 symptoms, and therefore they must pay more attention to the suspected patient. The suspected COVID-19 alert is triggered depending on the evaluation of symptoms result. Figure 11 describes different concepts and properties that contribute to the alert ontology.

○

Service Ontology

This ontology is designed to provide alerts services and interact with patients to control suspected symptoms. These services are monitoring, sending alerts, and making recommendations. Figure 12 describes the concepts and properties of this ontology.

3.3. Ubiquitous System and Adaptation Mechanisms during Detection of Suspected COPD Patient Activity

3.3.1. Ubiquitous/Pervasive System

Weiser [3] argued that ubiquitous computing has as its goal the nonintrusive availability of computers throughout the physical environment, virtually (if not effectively) invisible to the user. Weiser [3] also explained that, unlike virtual reality, ubiquitous computing would integrate information displays into the everyday physical world. Its proponents value the nuances of the real world and aim only to augment them; and unlike current personal digital assistants, ubiquitous computing would be a world of fully connected devices, with cheap wireless networks and would not require that you carry around a PDA, since information would be accessible everywhere. According to Gu et al [33,34], the advanced deployment of wireless networks and mobile devices is moving computing towards a new field knows as pervasive computing in which devices and services are seamlessly coordinated to support user tasks. Emerging pervasive computing technologies provide “anytime, anywhere” computing by decoupling users from devices and viewing [33,34].

3.3.2. Adaptation Mechanism to Deliver Vital Sign Alerts and the Alert Symptom Investigation

Adaptation mechanism is an approach used by a context-aware system to deliver service depending on current context information [35,36]. Figure 11 describes the adaptation mechanism to deliver vital sign alerts and alert symptom investigations.

3.3.3. Adaptation Mechanism That Delivers Alert Recommendations for the Screening Test

The adaptation mechanism delivers alert recommendations for the screening test depending on current context information (Range 1).

The main components of the mechanism adaptation of Figure 13 are the following:

• Context information (patients’ information, sensors);
• Representation (ontology);
• Reasoning (adaptation and inference engine);
• Services (services offered by application of context-aware tools);
• Rule based (rule to detect suspect COPD patient).

The context information component provides the machine data or range. For example, “buccal temperature = 38.9 °C” is context information. Representation (ontology) are the five ontologies that provide knowledge to implement the detection system. The reasoning is the engine adaptation program that proposes services depending on current context data. The reasoning technique is the rule-based approach.

Figure 13 describes how the adaptation mechanism can deliver the service of a COVID-19 screening test recommendation. Section 3.4 presents the implementations and applicability approach.

System uses adaptation mechanism described in Figure 14 to deliver an alert recommendation for the screening test.

3.4. Implementations and Applicability

3.4.1. Implementations

We use the Ontopy framework [37] to integrate ontology development tools (Protégé) and application context-aware tools (Python). Ontopy is a free software Python module (GNU LGPL v3 license) for ontology-oriented programming and agile ontology-based application development. The Python 3.4 language was chosen because it is a dynamic object language with multiple inheritances. The choice of Ontopy is justified by its adaptation to the medical environment. Ontopy has many advantages versus Java: Ontopy allows (a) loading ontologies in OWL 2 XML format; (b) accessing the ontology’s content; (c) loading the ontology’s content in the OWL 2 XML format as if they were Python objects; (d) creating OWL Python classes; (e) adding Python methods to OWL classes; and (g) performing automatic classification of instances, classes, and properties. Figure 15 presents Ontopy’s platform.

The python platform has many functions and libraries, which can send email, SMS, and alerts easily without building a mobile application. We have, for example, the libraries Smtplib and zerosms, and the email message function. Concerning database tools, we use SqlServeur. This tool uses SQL(Structured Query Language) and PL(Procedural language)/SQL languages to describe tables, relations, views, and objects of the database. This tool also contributes to building procedure, function, and the package used as a user interface to offer medical services and alerts to patients. Furthermore, we use SQL and PL/SQL to manipulate data from the database. The objective of this implementation is to realize the validation and applicability of our detection model.

3.4.2. Applicability of the Project

To prove the feasibility of this work, we conducted an stimulation process to check the capacity of model detection for detecting suspected COPD patients who need to take COVID-19 screening tests; indeed, a survey was conducted among COPD patients using Google Forms questionnaires. The results were compared with the results of our prototype. In the first phase, we considered the scenarios of 30 elderly COPD patients who had the results of their COVID-19 screening test. We send a questionnaire on Google Forms to each COPD patient. In the Google Forms, we explain and invite elderly patients to give exactly their symptoms that motivated them to take a COVID-19 screening test based on their answers to the questionnaire. The structure of this file is the following F_questionnaire answers: extreme tiredness, cough, headache, difficulty breathing dyspnea, headache, vomiting symptom, abdominal pain symptom, cough questionnaire, sensory loss questionnaire, fever sensation questionnaire, chills questionnaire, losing taste questionnaire, muscle stiffness questionnaire, diarrhea symptom, gastrointestinal symptoms, diarrhea symptom. With Google Forms, we generate an answer file. Furthermore, we simulate the identification of suspected elderly COPD patients who need to take a COVID-19 screening test by extracting data from the F questionnaire answers file with our prototype programs. Finally, we compare real patients’ COVID-19 screening test results and the program of prototype results. In the following section, we present the results and discuss the capacity of the prototype for discovering or identifying early suspected COPD patients who need a COVID-19 screening test. Then, we evaluate the performance of the proposed system for identifying abnormal situations or patterns that may pose serious health risks for COPD patients in the context of the COVID-19 pandemic.

Table 7. Example of vital sign parameters data.

id	Buccal Temperature	Spo2 (%)	Fiev1 (%)
1	37.7	89	65
2	38.5	87	29
3	38.8	88	38
4	37	91	40

presents data collected by sensors and also describes an example of vital sign parameters data for a patient who receives a COVID-19 screening test.

Table 8. Questionnaire answers.

Id	Headache Symptom	Extreme_Tiredness Symptom	Pneumonia Symptom	Difficulty Breathing	Cough Symptom	Fever Sensation
1	N	N	N	N	N	N
2	N	N	N	N	N	N
3	Y	Y	Y	Y	Y	Y
4	N	N	N	N	N	N

describes an example of the main symptom data parameter from the questionnaire answer file of the patient.

The objective is to determine the applicability of the project based on data from COPD patients. In the results section, we compare the theoretical results provided by the prototype with the real patient results.

○

Experimental Approach

A patient sample was extracted from a database to perform the simulation and implementation step. The data from the questionnaire answer file is extracted by the prototype or detection system and alerts the application as input. At the output, the results of suspected COVID-19 are presented in tabular form. Figure 16 describes this experiment and the implementation process.

○

Implementation Approach of the SuspectedCOPDcoviDOlogy

All concepts, relationships, and properties are created using the Protégé tool, which was chosen for its automatic reasoning engine. Figure 17, Figure 18, Figure 19 and Figure 20 present, respectively, class hierarchy, list of object properties, data properties of the detection system, and connection interface of the ontology proposed.

(i)

Description of the class hierarchy of system detection

Figure 17 describes the hierarchy of the main concepts for illustrating the detection of suspected COPD patients with COVID-19. Figure 17 is an extract of object properties that connect the concepts of the ontology. These concepts can be grouped into four groups. The first group allows the detection of suspected cases of COVID-19 with vital sign parameters. The main concepts in this group are SensorDataBucTemp, SensorDataFiev, and SensorDataSpo2. The purpose of this first group is to propose an evaluation of vital signs to check if the patient is developing the first symptoms of COVID-19. The second group gathers the concepts, allowing the symptomatic investigation to be carried out. Examples of symptom concepts are gastrointestinal symptoms, abdominal pain symptom, diarrhea symptom, and vomiting symptom. The third group concerns questionnaires to assess the patient’s state of health. As an example of concepts from this group, we have a questionnaire, answers, options, etc. The fourth group includes all alert and service concepts. The following concepts can be distinguished in this group: Alert, suspected COVID-19 alert, etc.

(ii)

Description list of object properties

Figure 17 describes a list of object properties. These object properties, or the relations between classes, can be grouped into four groups. The first group is relations that are involved in the detection of suspected cases of COVID-19, with vital sign parameters. Some main relations or object properties in this group are hasTriggeredQ, hasSDBTp, and hasSDsp. The purpose of this first group is to propose an evaluation of vital signs. The second group concerns the group of relations with the concepts allowing the symptomatic investigation.

(iii)

Description of data property hierarchy

Figure 17 presents object properties of the detection system. The classes, instances, relationships, and properties are, then, exported to the Ontopy platform to allow the development of the prototype (suspected application detection COVID-19) with the Python tool and Visual Studio. Figure 17, Figure 18, Figure 19, Figure 20 and Figure 21 show, respectively, the Class hierarchy, the object properties, data properties, connection interface and the dashboard of COVID-19 suspected patients, by frequency of symptom appearance. The physician or the emergency doctor uses the connection window presented in Figure 20 to connect to the automated detection system.

• (iv) Description of Interface Connection

The connection Window is composed of three items, i.e., user name, password and connexion button. The differents users are physicians, nurses, and others members of health care staff. The COPD patients also use the system.

• (v) Presentation of adaptative dashboard of suspected cases

Patients are sorted in descending order of frequency of symptom occurrence. The experiment was carried out using this prototype with real data and the results are described in Section 3. Figure 21 presents an adaptative dashboard of suspected patients with symptoms. This tool can help emergency doctors focus on these patients in the context of monitoring COPD patients.

This dashboard is important to better monitor patients. This adaptative dashboard of suspected cases is structured as follows: current date of connection, patient identifier, detection date, and patient address residence. The current date connection is a system date; patient identifier is patient ID in the system, and residence is a patient postal address. When the data of the patient context changes, the dashboard changes by period.

4. Results

As mentioned in the previous section, we have two results to analyze. First, statistically, out of 30 COPD patients from sample who were tested for COVID-19, three were identified as positive. We have examined also the same 30 COPD patients answers. The comparison between theoretical and experimental results is shown in Figure 22.

Table 9. Experimental results vs. detection program results.

	Suspected for COVID-19 (Experimental)	Negative for COVID-19	Suspected for COVID-19 (Prototype)	Negative for COVID-19
N	3	27	5	25
%	10%	90%	16.67%	83.33%

presents the results of the simulation and the detection program (prototype).

The question is whether the result of the prototype includes all the individuals who tested truly positive. Indeed, the prototype identifies only suspected cases. The prototype does not test but provides a list of individuals to be tested after evaluation with the vital sign and symptomatic criteria of COVID-19. In the Discussion Section of this paper we evaluate the results and draw conclusions. Our detection system has been compared to other applications.

4.1. Applicability to Other Domains

The detection system can be used for other diseases. To achieve this, the following steps must be followed:

(1)

Define the patient context by specifying the vital sign and symptom parameters of the disease.

(2)

Define the detection rules for the disease and link these rules to the information in the context.

(3)

Define the relevant alert services for this disease.

(4)

Modify the questionnaire.

(5)

Modify the program of the adaptation and inference engine.

(6)

Modify the mechanism adaptation.

The ontology must also be modified according to the parameters identified for characterizing the disease. Overall, these are minor modifications because several parts of the detection model can be reused.

4.2. Comparison of the Prototype to Other Tools (Prototype vs. Others Projects)

Our system is based on the ontology of detecting suspected cases of COPD patients with COVID-19 symptoms to propose a dashboard of suspected cases and send alerts to the patient’s medical staff in a COPD patient-monitoring context. This system is dynamic and uses adaptation mechanisms fitted to the COPD patient context. The system detection facilitates medical assistance.

Table 10. Table of comparison for prototype, machine-learning approaches, and other alert applications.

Advantages/Features	Prototype	Machine Learning	ReelyActive	COVIDSAFE
Adaptation mechanisms	x		x
Dynamic medical assistance service	x		x
Vital sign data acquisition	x	x
Symptom data acquisition	x
Physician dynamic dashboard	x
Automatic engine reasoning	x
Adapted to monitor COPD patient	x	x	x	x
Algorithm prediction		x
Respect social distancing			x	x
Prevention of contamination risks COVID-19	x
Alert and detection of COVID-19 risks	x		x	x
Digital contact tracing		x	x

presents a comparaison of detection system to others. Finally, the system uses the Protégé [5] tool SWRL’s automatic reasoning engine, with interfaces developed in Python.

5. Discussion

Our objective for the implementation of this prototype was to verify the feasibility of the project; indeed, the problem presented in this paper was to address the high mortality and vulnerability of COPD patients in the context of the COVID-19 pandemic. To address these problems, we presented a set of mechanisms to detect suspected patients who could develop the first symptoms of COVID-19. The comparison of the results of the detection approach by our prototype with detection based on real screening tests gives promising results. All patients detected by the prototype were also detected by real screening tests. The analysis of our approach leads to the conclusion that a combination of rules for vital sign and symptom parameters improves the efficiency of detection.

The main benefits of this model are the ability to reason about various COPD patient context information and the capacity to propose an appropriate alert service based on an adaptation engine. The system uses its adaptation engine to propose different types of alert services according to the patient’s context. For example, if the vital data meets the criteria for vital signs, then, the system proposes to trigger the evaluation of symptoms via questionnaires; otherwise, the normal monitoring service is activated. Our alert system is not a COVID-19 screening system. The system allows us to monitor, in real time, suspected persons (especially those elderly), including low mobility COPD patients. The system, then, sends alerts, proposes a dynamic list of patients suspected of having symptoms of COVID-19, and invites these patients to go for a screening test. This system offers the possibility for healthcare teams to reinforce monitoring of elderly COPD patients anytime and anywhere. The emergency physician does not need to go into the patient’s home to assess vital signs and symptoms. The major contributions of our system are implementations of mechanisms adaptation, the dynamic dashboard of suspected patients, and alerts. This is a breakthrough in surveillance to reduce potentially the mortality rate of COPD patients in the COVID-19 pandemic. The medical team has a dynamic dashboard of people who need to be screened. This dynamic dashboard is periodically updated according to the evolution of vital sign data and the evolution of symptoms, such as fever, Spo2, headache, fatigue, respiratory difficulty. Our system helps medical staff reinforce the surveillance of, prevent complications, and better protect these elderly COPD patients.

6. Conclusions and Future Work

In this paper, we have presented a dynamic and extensible detection of suspected COPD patients with COVID-19 model based on Ontology/OWL. Our solution (SuspectedCOPDcoviDOlogy) for detecting suspected cases enriches the knowledge of existing ontologies, such as COPDology in the field of COPD domain, for improving the quality of service of COPD patient monitoring platforms. The detection model also provides medical staff with a dynamic dashboard of suspected COPD patients with COVID-19 symptoms in real time, based on dynamic detection with a pervasive healthcare system. This tool allows the medical staff to be on continuous alert for the protection of COPD patients. Finally, our model detection could contribute to the prevention of COPD complications and a reduction in mortality rate among COPD patients.

In our future work, we plan to replace the questionnaires with exhaustive rules detection; therefore, all alert systems would be fully automated. To achieve complete automation of the rules requires better medical knowledge of COVID-19. However, with new variants of COVID-19 emerging, the detection criteria for these variants are still under study in research laboratories.