Semantic Web Technologies in Sensor-Based Personal Health Monitoring Systems: A Systematic Mapping Study

2.2.1. Languages and Standards

The development of SWTs is facilitated using different languages and standards. Resource Description Framework (RDF), ² a standard for the description and exchange of interconnected data in the form of subject–predicate–object triples, can be considered one of the core building blocks of the semantic web. As RDF is an abstract data model, it can be serialized in different formats, including N-Triples, Terse RDF Triple Language (Turtle), eXtensible Markup Language (XML), and JavaScript Object Notation for Linked Data (Schreiber & Raimond, 2014). Several extensions to RDF have been proposed. These include RDF Schema (RDFS), ³ which provides a vocabulary to enrich RDF data; RDF-star, ⁴ which allows an RDF triple to be embedded as the subject or object of another triple, without necessarily asserting the embedded triple, thereby enabling richer metadata annotation; and the Notation3 ⁵ specification, which extends the representational abilities of RDF by supportive declarative programming and allowing the access of online knowledge. Other important standards in the semantic web community are: Web Ontology Language (OWL), ⁶ a language for constructing ontologies; Semantic Web Rule Language (SWRL), ⁷ a language for expressing rules and logic; Shapes Constraint Language (SHACL), ⁸ a language for describing RDF graphs, which also includes a rules language; and SPARQL Protocol and RDF Query Language (SPARQL), ⁹ a language for retrieving and manipulating RDF data. SPARQL-star extends SPARQL to allow querying and updating of RDF-star data, while SPARQL Inferencing Notation (SPIN) ¹⁰ is a rules language based on SPARQL.

2.2.2. Ontologies

Arguably, the key technology underpinning the semantic web is ontologies, which have been widely used for reasoning and representation in sensor-based systems (Ye et al., 2011). Their ability to represent knowledge formally and unambiguously not only enhances interoperability but is also useful in capturing the domain knowledge necessary for situation analysis and subsequent decision support. Several ontologies have been developed to support the description of sensors and their observations, which is critical in any sensor-based system. Two particularly prominent sensor ontologies are the semantic sensor network (SSN) ontology (Compton et al., 2012) and the Smart Appliances REFerence (SAREF) ¹¹ ontology (García-Castro et al., 2023). Both are standardized ontologies developed by the World Wide Web Consortium (W3C) and the European Telecommunication Standardization Institute (ETSI), respectively, with the aim of enabling semantic interoperability. However, while SSN was developed for sensors and sensor-based systems in general, SAREF focuses on smart appliances and IoT devices. The latest version of SSN is based on the Sensor, Observation, Sample, and Actuator (SOSA) ontology (Janowicz et al., 2019), which provides it with a lightweight, user-friendly, and extendable core. SAREF has mappings to SSN, from which it borrows modeling patterns for several classes (García-Castro et al., 2023; Moreira et al., 2020).

As domain-agnostic ontologies, both SSN and SAREF require augmentation to meet application-specific requirements (Poveda-Villalon et al., 2018). SAREF provides a suite of ontologies that extend the core ontology for different domains, including two that are relevant for personal health monitoring: SAREF4EHAW ¹² for eHealth and ageing well, and SAREF4WEAR ¹³ for wearable devices. SAREF4EHAW provides support for modeling concepts such as health system actors (including patients and caregivers) and health devices (including wearables), with the wearable concept linked to the SAREF4WEAR ontology. An additional extension, SAREF4Health, was developed to address the limitations of SSN and SAREF in representing real-time ECG time series data exchanged between mobile devices and cloud gateways (Moreira et al., 2020). In contrast to SSN, SAREF is targeted at industry developers rather than ontology experts (Moreira et al., 2020), making it more readily adoptable by those without extensive ontology development experience. Furthermore, its extensions for the health domain provide a solid foundation for building semantic personal health monitoring systems. Additional representational support can be obtained by integrating resources such as standardized clinical terminologies and medical knowledge bases.

2.2.3. Knowledge Graphs

A knowledge graph can generally be understood as a knowledge base of real-world data represented in a graph-based data model. Ontologies are a vital building block in many knowledge graphs, and are used to define their data schema (such as properties, restrictions, and relationships) as well as enable semantic reasoning and entailment (Hogan et al., 2022). Knowledge graphs have seen increasingly widespread use in the health domain. Their graph structure enables the conceptualization, representation, and integration of data (Hogan et al., 2022). This is advantageous in health monitoring systems, where the integration of various sources of health data is critical. An example of this is the Precision Medicine Knowledge Graph, which integrates diverse biomedical data from multiple sources with the goal of enabling precision medicine analyses (Chandak et al., 2023). Previous research has also explored the automatic construction of knowledge graphs from electronic health records (Chen et al., 2019; Rotmensch et al., 2017), which can then be used for clinical decision support. This is related to personal health knowledge graphs, which are used to represent and reason over individual health data, including data from sensors (Gyrard & Boudaoud, 2022) and electronic health records (Jiang et al., 2024; Tao et al., 2020). Additionally, knowledge graphs have been proposed for drug discovery (Zeng et al., 2022) and as a tool for explainability in AI-driven health monitoring systems (Lecue, 2020; Rajabi & Kafaie, 2022). Knowledge graphs have also proven useful in sensor-based systems, for example, by providing graph-based visualizations of the data generated by IoT devices, which can then be queried in real time (Le-Phuoc et al., 2016).

2.2.4. Linked Data

Both knowledge graphs and ontologies can be published using a linked data approach (Hitzler, 2021), whereby uniform resource identifiers are used to identify distinct resources (Bizer et al., 2011). When the emphasis is on free use, modification, and sharing, it is referred to as Linked Open Data (Hitzler, 2021). Linked data have been proposed for augmenting and representing sensor data in order to improve their accessibility and interoperability (L. Yu & Liu, 2015). In the health domain, it has been explored in applications ranging from drug discovery (Gray et al., 2014) to the representation of electronic health records (Pathak et al., 2013). Linked data can contribute to interoperability by ensuring heterogeneous health data are stored in a consistent format and structure. However, their use in health monitoring is not well explored in the literature.

5.1.1. Technical Interoperability

Differing data transmission technologies can contribute to a lack of technical interoperability in health monitoring systems, particularly those that use a range of different sensors. Data transmission protocols used in sensors include Bluetooth, Bluetooth Low Energy, ANT+, and Zigbee, with the first three being the most common among wearable devices today (Gravina & Fortino, 2021). Interoperability among these different protocols can be achieved using gateway devices, which receive data from different sensors and transmit it to cloud services (Rahmani et al., 2018). This is done by Ali et al. (2018), who use a router as a gateway to receive sensor data and transmit it to the internet. Eleven of the systems (Ali et al., 2020; Alti et al., 2022; Ammar et al., 2021; Elhadj et al., 2021; El-Sappagh et al., 2019; Hussain & Park, 2021; Khozouie et al., 2018; Lopes de Souza et al., 2023; Peral et al., 2018; Villarreal et al., 2014; Zhang et al., 2014) use a mobile phone as a gateway device or base station, typically receiving sensor data via Bluetooth or Bluetooth Low Energy and transmitting it to the cloud via WiFi or mobile data.

5.1.2. Syntactic Interoperability

While technical interoperability is associated with hardware components and infrastructure, syntactic interoperability is usually associated with data formats (Veer & Wiles, 2008). There are several standards that are widely used to promote syntactic interoperability among systems. Among them is the ISO/IEEE 11073 standard, which provides a common format for communication involving medical devices and patient health data, with an emphasis on vital signs. This is used by El-Sappagh et al. (2019) for formatting data for transmission to the base unit or gateway. Other important standards for health data are provided by Health Level 7 (HL7). One of these is FHIR, which describes data formats, resources, and an application programming interface through which health information can be exchanged (Benson & Grieve, 2021). Two of the 48 systems make use of FHIR. El-Sappagh et al. (2019) convert sensor data from the ISO/IEEE 11073 standard to FHIR formats, while also receiving data in FHIR format from hospital information systems. In this way, both sensor data and data from hospital systems are in the same format. Similarly, Kilintzis et al. (2019) propose a semantic model based on FHIR, using its data types and defining classes as FHIR categories. FHIRs can be defined using different data formats, ²⁴ including XML, RDF serializsed in Turtle, and JSON. Both systems use the JSON format.

5.1.3. Semantic Interoperability

The next type of interoperability is semantic interoperability, which is concerned with the meaning of the exchanged information. Semantic interoperability can be achieved through the use of unambiguous codes and identifiers, which can be provided by existing standard classifications and terminologies (Benson & Grieve, 2021). Ontologies are, of course, a well-established way to embed semantic interoperability in a system (Sheth et al., 2008). Within the medical domain, many existing medical terminologies are available as ontologies, including SNOMED CT, ²⁵ the International Classification of Diseases (ICD), ²⁶ and the International Classification for Nursing Practice (ICNP). ²⁷ Among the systems, SNOMED CT is the most commonly used (Bampi et al., 2025; Chatterjee et al., 2021; El-Sappagh et al., 2019; Kilintzis et al., 2019; Kordestani et al., 2021; Lopes de Souza et al., 2023; Reda et al., 2022; Rhayem et al., 2021; Titi et al., 2019; Zhou et al., 2022). ICNP is used by Elhadj et al. (2021) and Henaien et al. (2020), while ICD is used by Spoladore et al. (2021) and G. Yu et al. (2022) (ICD-11, the latest version) as well as (ICD-10; Titi et al., 2019). The Unified Medical Language System (UMLS; Bodenreider, 2004) is a large thesaurus that integrates multiple terminologies of medical knowledge. It is used by Peral et al. (2018), and Zhou et al. (2022). Another thesaurus is Medical Subject Headings (MeSH), which is used for indexing, cataloguing, and searching health information, and is integrated in the system proposed by Reda et al. (2022). Garcia-Moreno et al. (2023) and Spoladore et al. (2021) incorporate the International Classification of Functioning, Disability and Health (ICF). ²⁸

Terminologies for specific diseases and conditions also exist. For example, Ali et al. (2021) and El-Sappagh et al. (2019) reuse ontologies specific to diabetes. Similarly, De Brouwer et al. (2022) use the third edition of the International Classification of Headache Disorders (ICHD-3), ²⁹ while Hristoskova et al. (2014) and Zafeiropoulos et al. (2024) reuse the Heart Failure Ontology and Parkinson and Movement Disorder Ontology, respectively. The Vital Sign Ontology is extended by El-Sappagh et al. (2019) and Ivaşcu and Negru (2021). Xu et al. (2017) posit that it is difficult to build scalable ontology-based systems suitable for large amounts of healthcare data and instead opt for a linked data approach to add semantic information to the data. Their proposed system uses linked open data medical knowledge graphs, namely Diseasome, DBpedia, and DrugBank. Using these resources, they create a knowledge graph showing the relationships between symptoms and diseases. Domain-independent concepts can also be referenced from SWTs. For instance, Peral et al. (2018) and Reda et al. (2022) both use WordNet, a lexical English language database of semantic relations between words, linking them into semantic relations.

SWTs also provide a means to represent sensors and the data they capture. Sensors can be represented with varying degrees of expressiveness. Concepts that can be captured about sensors include unique identifier, manufacturer, location of deployment, dimensions, operating conditions, type of data captured, and hierarchy with regard to related sensors (Compton et al., 2009). Similarly, various sensor data concepts can be represented, such as the property being observed, units of measurement, and measurement timestamps. Thirty-eight systems represent sensor and sensor data concepts in ontologies. The reuse of existing sensor ontologies, particularly established ones such as SAREF, can contribute to a higher degree of expressiveness for sensor and sensor data concepts. This is because these validated ontologies provide rich modeling of such concepts, facilitating more effective querying of and reasoning on sensor data, which is essential for situation analysis. Comprehensive sensor ontologies also support sensor management, allowing sensors to be catalogued based on their attributes as captured in ontologies (Compton et al., 2009). Despite these benefits, only 16 systems reuse existing sensor or device ontologies, namely SSN/SOSA (Bampi et al., 2025; Chatterjee et al., 2021; Elhadj et al., 2021; El-Sappagh et al., 2019; Garcia-Moreno et al., 2023; Ivaşcu & Negru, 2021; Martella et al., 2025; Rhayem et al., 2021; Stavropoulos et al., 2021; Titi et al., 2019), SAREF and its extensions (De Brouwer et al., 2022; Hadjadj & Halimi, 2021; Lopes de Souza et al., 2023; Zafeiropoulos et al., 2024), the Amigo device ontology (Hristoskova et al., 2014), and the Moving Objects ontology (Rhayem et al., 2021). This could be attributed to the existing ontologies providing more complexity than the systems require, although this can be mitigated by selectively importing only the relevant classes.

Foundational ontologies can contribute to semantic interoperability by providing unambiguous and domain-independent concept definitions (Amaral et al., 2021). Three of the selected systems directly incorporate a foundational ontology. El-Sappagh et al. (2019) use the Basic Formal Ontology, while De Brouwer et al. (2022) and Stavropoulos et al. (2021) use the DOLCE + Description and Situation (DnS) Ultra Lite (DUL) ontology. Other systems indirectly integrate foundational ontologies by reusing other ontologies that have already incorporated them. For example, the SSN ontology uses DUL as its upper ontology (Compton et al., 2012), and the SAREF ontology also has an indirect reference to DUL through its mappings to the SSN ontology (Daniele et al., 2015). Consequently, any system that reuses the SSN or SAREF ontologies inherits an indirect connection to DUL.

5.1.4. Supporting Data Fusion

For real-time health monitoring, streaming sensor data must be retrieved and dynamically fused with other heterogeneous, multimodal, and distributed sources of data. This data fusion is pivotal for downstream situation detection, situation prediction, and decision support. Interoperability serves as an enabler for effective data fusion. Technical interoperability provides the protocols and hardware necessary to collect data from diverse sources; syntactic interoperability ensures data formats and structures are compatible across systems; and semantic interoperability establishes shared meaning for data elements, allowing accurate interpretation. Additionally, data fusion supports process interoperability by creating a unified and comprehensive patient view from diverse data sources, which enables different healthcare providers to coordinate their workflows effectively (Kuziemsky & Peyton, 2016).

As seen in Table 6, the selected systems support a wide range of heterogeneous and multimodal data. All 48 systems collect physiological data from body sensors, while 15 systems additionally incorporate weather data from ambient sensors. Health and medical records are the most frequently incorporated data source other than sensor data, with 21 systems supporting the incorporation of such data from external hospital systems. These records provide additional information that is useful for health monitoring, such as an individual’s disease history, laboratory test results, medications taken, allergies, and previous hospital admissions. The systems proposed by Ali et al. (2018, 2020), El-Sappagh et al. (2019), and Rhayem et al. (2021) have the most comprehensive records, capturing laboratory tests, prior disease diagnoses, and lifestyle information such as exercise, nutrition, alcohol consumption, and smoking status. Some systems use medical records to extract diagnosis status (Ali et al., 2021), while others use them to extract an individual’s risk factors for disease (Ali et al., 2020). These records can also be used to overcome limitations of sensor data, such as missing values, as was done by Ali et al. (2021). Besides health and medical records, data from social networks can also be used to complement sensor data. This is done in two systems: Ali et al. (2021), who use social networking data to monitor individuals’ mental health through sentiment analysis; and Ammar et al. (2021), who use social networks, blogs, and news articles as sources of public knowledge.

A detailed analysis of the data sources, including sensor devices and existing datasets, is provided in Section 6.1.

SWTs do not inherently provide support for technical interoperability, since they operate at a higher, more abstract level to formally represent and derive meaning from the data. Therefore, in order to achieve technical interoperability, health monitoring systems must leverage data transmission protocols and devices. However, SWTs are critical in the achievement of semantic interoperability among the selected systems. Twenty of the systems make use of terminologies such as SNOMED CT and ICD through ontologies, and access knowledge graphs such as DrugBank and Diseasome, which are published as linked data. This allows the systems to access and reason with standardized health domain knowledge.

SWTs can also contribute to syntactic interoperability. For instance, El-Sappagh et al. (2019) and Kilintzis et al. (2019) map FHIRs to an ontology, allowing for interoperability between their proposed system and hospital information systems that use FHIR. These are the only two systems that use SWTs to achieve interoperability with established health standards. This can be attributed to the historical gap in user-friendly tools for this purpose. For example, although FHIR has an RDF representation serialized in Turtle format, early adopters noted several issues precluding its ease of use, such as literal values and FHIR references being nested under blank nodes, and unnecessarily long predicate names (Sharma et al., 2022). However, more recent versions of FHIR RDF have largely addressed these issues.

Finally, with regard to the representation of heterogeneous and multimodal data, 42 systems use ontologies for this purpose. The exceptions are three systems which represent the data in knowledge graphs (Ammar et al., 2021; Xu et al., 2017; G. Yu et al., 2022), and three systems which only use SWTs (i.e., domain ontologies, external knowledge graphs, and linked data repositories) as a source of domain knowledge (Ali et al., 2021; Hussain & Park, 2021; Zhou et al., 2022).

5.2.1. Forms of Situation Detection

In health monitoring systems, situation detection can take a variety of forms. One of these is the categorization of individual sensor observations based on whether they are within or outside a given range as determined by domain knowledge. For example, in the system proposed by Akhtar et al. (2022), when vital signs such as temperature and heart rate are outside the normal range, the situation is classified as an emergency. Likewise, Elhadj et al. (2021) classify expected observations as normal, while observations outside the normal ranges are classified as abnormal. They also include a third classification, wrong, for faulty observations from malfunctioning sensors. Similar threshold-based situation categories are used in 19 of the systems (Alti et al., 2022; Ammar et al., 2021; Bampi et al., 2025; De Brouwer et al., 2022; Garcia-Valverde et al., 2014; Hadjadj & Halimi, 2021; Hristoskova et al., 2014; Ivaşcu & Negru, 2021; Khozouie et al., 2018; Kilintzis et al., 2019; Lopes de Souza et al., 2023; Martella et al., 2025; Peral et al., 2018; Rhayem et al., 2021; Titi et al., 2019; Villarreal et al., 2014; Zafeiropoulos et al., 2024; Zeshan et al., 2023; Zhang et al., 2014). Thresholds have also been used to classify physical activity based on level of intensity (Chatterjee et al., 2021; El-Sappagh et al., 2019; Esposito et al., 2018; Garcia-Valverde et al., 2014; Ivaşcu & Negru, 2021). A better approach than using individual sensor observations is to consider different observations and personal attributes to classify individuals. This is done by Ali et al. (2018), who classify the patient health condition as either healthy, moderate, or serious based on multiple sensor outputs and properties such as sex, weight, and height. Similarly, Chiang and Liang (2015) classify situations as either healthy, moderate, or severe based on age, blood pressure, blood glucose, heart rate, and cholesterol.

Another form of situation detection in health monitoring is the detection of medical conditions and diseases. Some conditions, such as hypertension and hyperglycemia, can be diagnosed based on individual sensor observation thresholds. This is done by J. Kim et al. (2014), who detect prehypertension and steps 1 and 2 hypertension based on defined blood pressure thresholds. Similarly, hyperglycemia is detected by Rhayem et al. (2021) based on blood glucose levels. Other diseases require the analysis of signs and symptoms based on a combination of different sensor observations and other sources of data. For example, Ivascu et al. (2015) detect mental disorders (Parkinson’s, Alzheimer’s, psychosis, and depression) using signs and symptoms related to behavior, motor skills, cognitive skills, facial appearance, mood, sleep, weight, and speech. Other systems are able to detect types of headaches (De Brouwer et al., 2022), heart disease (Ali et al., 2020), diabetes (Ali et al., 2021, 2018; Hooda & Rani, 2020), frailty (Garcia-Moreno et al., 2023), stroke (Hussain & Park, 2021), and skin and kidney diseases (Kordestani et al., 2021). Beyond the detection of diseases, Zafeiropoulos et al. (2024) detect medication adherence in Parkinson’s disease patients by recognizing missed doses based on two features: tremors and bradykinisia.

5.2.2. Techniques for Situation Detection

Thirty-nine of the systems implement some form of rule-based reasoning for situation detection. Of these, 28 systems specify using semantic web rules in particular (Akhtar et al., 2022; Ali et al., 2018; Alti et al., 2022; Bampi et al., 2025; Chatterjee et al., 2021; Chiang & Liang, 2015; Elhadj et al., 2021; El-Sappagh et al., 2019; Esposito et al., 2018; Garcia-Valverde et al., 2014; Hadjadj & Halimi, 2021; Henaien et al., 2020; Hooda & Rani, 2020; Hristoskova et al., 2014; Kilintzis et al., 2019; J. Kim et al., 2014; Lopes de Souza et al., 2023; Mezghani et al., 2015; Minutolo et al., 2016; Reda et al., 2022; Rhayem et al., 2021; Spoladore et al., 2021; Stavropoulos et al., 2021; Titi et al., 2019; H. Q. Yu et al., 2017; Zafeiropoulos et al., 2024; Zeshan et al., 2023; Zhang et al., 2014). A discussion of the specific rule languages used in the systems can be found in Section 6.2.2. Rules provide a way to implement expert knowledge in an if–then form, whereby if certain conditions are met, then a consequent conclusion is made or action taken. Despite their widespread use, rules have several limitations. Firstly, crisp rules are unable to handle uncertainty and ambiguity in sensor observations and the determination of health situations. To mitigate this, five systems incorporate fuzzy logic (Ali et al., 2018; Chiang & Liang, 2015; Esposito et al., 2018; Fenza et al., 2012; Minutolo et al., 2016), while one incorporates defeasible logic (Akhtar et al., 2022) within the rules. These techniques are discussed in greater detail in Section 5.7, which focuses on techniques for handling uncertainty in health monitoring. Secondly, rules are typically based on existing expert knowledge, and therefore cannot incorporate new knowledge that experts may be unaware of. Additionally, manually updating rules is time-consuming, making them difficult to scale. This challenge can be overcome using learned rules based on ML algorithms, which can acquire new, high-quality knowledge automatically (Hitzler et al., 2020) and contribute to dynamic and adaptable rule-based systems. The systems proposed by Hussain and Park (2021), Henaien et al. (2020), and Peral et al. (2018) extract rules from decision trees. However, caution should be exercised when using ML-derived rules, as they may still need verification and validation from domain experts. As an alternative to rule-based reasoning, Xu et al. (2017) implement case-based reasoning, arguing that it is easier to capture human experiences using cases rather than rules. By searching for historical cases that are similar to the current case, their proposed system is able to obtain treatment plans that have been successful in the past.

In addition to the development of rules as discussed above, ML is also used in a number of systems for the classification of diseases based not only on sensor data but also other data sources. Ali et al. (2021) use a bidirectional long short-term memory (BiLSTM) model to detect diabetes and blood pressure, to classify sentiments from social networking data for mental health monitoring, and to classify drug side effects. Their proposed system uses domain ontologies to extract important features that can enhance the ML classification. Zhou et al. (2022) also use a BiLSTM model for disease prediction, while Garcia-Moreno et al. (2023) use k-nearest neighbors to classify elderly individuals based on frailty and dependence. Other ML algorithms used include a multi-layer perceptron for heart disease detection (Ali et al., 2020) and a random forest for stroke detection (Hussain & Park, 2021). ML is also used for physical activity classification, for example, using the k-nearest neighbors (Garcia-Valverde et al., 2014; Mavropoulos et al., 2021), decision trees (Mavropoulos et al., 2021), and random forest (Ivaşcu & Negru, 2021; Mavropoulos et al., 2021) algorithms. Finally, ML can also be used to classify situation severity for reporting purposes. This is done by Zafeiropoulos et al. (2024), who use a graph neural network to distinguish between medium and high alerts. A full review of ML techniques for situation analysis in the health domain is outside the scope of this study. Readers are referred to the reviews by Ravì et al. (2017) and Li et al. (2021).

5.2.3. The Role of SWTs

SWTs can support situation detection in two main ways: firstly, they formally represent important concepts and the relationships between them, that is, sensor data, domain knowledge, contextual information, and even the situations themselves; and secondly, they support reasoning through which new knowledge can be derived from existing knowledge (Ye et al., 2011). Although several situation-focused ontologies have been developed, including the Situation Theory Ontology (Kokar et al., 2009) and the Scenes and Situations ontology (Almeida et al., 2018), none of the selected systems reuse any such ontologies. Despite this, SWTs remain vital for situation detection among the selected systems. Rule-based reasoning is the most common mechanism for situation detection among systems. These rules rely heavily on concepts that are formally defined in ontologies, and they are more often than not expressed in standard semantic web languages such as SWRL.

5.3.1. Forms of Situation Prediction

All 12 of these systems explore the concept of risk as a situation prediction feature, since determining an individual’s risk profile for a certain condition can be used to predict future adverse health situations. This includes the risks of heart disease (Ali et al., 2020; Hristoskova et al., 2014), arthritis recurrence (Chiang & Liang, 2015), stroke (Mcheick et al., 2016), and fetal loss in gestational diabetes patients (Rhayem et al., 2021). Zhou et al. (2022) use a multi-label classification approach to simultaneously assess the risk of multiple chronic diseases, including hypertension, diabetes, and arthritis. De Brouwer et al. (2022) detect triggers as a means to anticipate potential headache attacks in the future, which can be considered a form of risk prediction. To support the identification of potential risks, future physiological readings can also be predicted using historical sensor observations, as is done by Peral et al. (2018). Their proposed system predicts blood glucose levels over three-day and five-day windows. These predictions of sensor measurements can then be analyzed to determine future health risks. Hristoskova et al. (2014) similarly adopt a temporal analysis, determining the risk of congestive heart failure over a four-year time horizon.

Another useful aspect of situation prediction is the determination of the prognosis, that is, expected progression, of a detected disease, although this is poorly explored in the systems. Hussain and Park (2021) mention the intention to extend their system in future work to include automated stroke prognosis; however, this is not implemented in the current version of the system. In contrast, H. Q. Yu et al. (2017) include a disease progression class in their proposed ontology, representing past diagnoses or potential health risks and their associated times. However, the system does not include any methods to predict the progression of detected conditions.

5.3.2. Techniques for Situation Prediction

Similar to situation detection, the most common technique used in situation prediction is rules, which is used in nine of the 12 systems. Of these, seven specify semantic web rules in particular (Ali et al., 2020; Alti et al., 2022; Chiang & Liang, 2015; Hristoskova et al., 2014; Reda et al., 2022; Rhayem et al., 2021; H. Q. Yu et al., 2017). As discussed in Section 5.2, both Chiang and Liang (2015) and Fenza et al. (2012) use fuzzy rules to enhance crisp rules. ML is used for situation prediction in four of the systems (Ali et al., 2020; Peral et al., 2018; Zafeiropoulos et al., 2024; Zhou et al., 2022). Ali et al. (2020) use an ensemble deep learning classifier, which consists of a five-layer feed-forward network that incorporates a boosting algorithm, to predict future heart attacks, while Peral et al. (2018) use support vector machine and logistic regression models to forecast future blood glucose measurements. Although De Brouwer et al. (2022) use ML to detect headache triggers, the actual prediction of headaches is knowledge-based using SPARQL queries on stored data.

Besides rules and ML, Bayesian networks (BNs) are used in two of the systems. These are probabilistic models in the form of directed acyclic graphs that can represent causal relationships among variables in a domain. Mcheick et al. (2016) use a BN to calculate the risk of stroke occurring in the next seven days, based on risk factors such as age, presence of diabetes, high blood pressure, and symptom duration. This approach is also taken by Kordestani et al. (2021) to determine the probability of the occurrence of kidney disease. The use of fuzzy rules and BNs is discussed in greater detail in Section 5.6 on explainability and Section 5.7 on uncertainty handling.

5.3.3. The Role of SWTs

By providing a structured representation of risk factors, temporal concepts, health outcomes, and situations, and supporting reasoning over these concepts, SWTs support more effective situation prediction. Similarly to situation detection, rules remain the most used reasoning approach for situation prediction among the systems, with seven of them using semantic web rules specifically. However, as discussed in Section 5.2, semantic-based approaches to situation analysis face drawbacks such as scaling difficulties and the inability to handle uncertainty inherently. These limitations can be mitigated by combining them with complementary techniques such as ML, fuzzy logic, and BNs. In fact, several extensions of semantic web standards and languages have been proposed that incorporate these uncertainty handling techniques, and these are discussed in Section 5.7.6. However, none of these are used in the reviewed systems.

5.4.1. Forms of Decision Support

Messages and notifications are used in the majority of the systems to warn of potentially dangerous situations, issue reminders, and prompt mitigating action. These notifications can be sent to monitored individuals, caregivers, clinicians, and emergency services, depending on the severity of the situation. The most common form of decision support is alerting users to adverse situations. This is done in nearly all of the selected systems, with the exception of 11 which do not mention this crucial functionality (Ali et al., 2020, 2021; Alti et al., 2022; Chatterjee et al., 2021; El-Sappagh et al., 2019; Fenza et al., 2012; Kilintzis et al., 2019; J. Kim et al., 2014; Minutolo et al., 2016; Reda et al., 2022; H. Q. Yu et al., 2017). A well-documented issue with alerts in the health domain is alert fatigue, a phenomenon in which users become desensitized to alerts due to their frequency (Cash, 2009). Esposito et al. (2018) mitigate this by differentiating between critical and non-critical abnormal situations, with the latter being sent out in a daily summary report email rather than an instantaneous notification for each case. Additionally, 10 systems send reminder messages of some kind to users, for instance about medications, exercise, and other interventions (Ammar et al., 2021; Chiang & Liang, 2015; Hadjadj & Halimi, 2021; Henaien et al., 2020; Kordestani et al., 2021; Mavropoulos et al., 2021; Stavropoulos et al., 2021; Titi et al., 2019; Vadillo et al., 2013; G. Yu et al., 2022). For example, the system proposed by Kordestani et al. (2021) can remind clinicians to order additional laboratory tests when previously taken tests become out of date.

In addition to alerts and reminders, health monitoring systems can also trigger actions in response to adverse situations. For example, the system proposed by Alti et al. (2022) triggers the injection of insulin in response to a blood glucose level above a certain threshold, while the system proposed by Hadjadj and Halimi (2021) can trigger the opening of a vehicle door. Such systems must be integrated with an actuation device capable of carrying out the action. The system proposed by Titi et al. (2019) includes several actuators, such as a smoke alarm. Other systems are integrated with actuators capable of opening doors and moving beds (Bampi et al., 2025), turning on lights and heaters (Chiang & Liang, 2015), making emergency calls (Rhayem et al., 2021), or turning off water or gas if detected (Vadillo et al., 2013).

Another form of decision support is the generation of suggestions or recommendations for the mitigation of adverse situations, which is implemented in 29 systems. The recommendations include lifestyle modifications, such as diet and activity (Ali et al., 2020, 2018; Alti et al., 2022; Ammar et al., 2021; Chatterjee et al., 2021; El-Sappagh et al., 2019; Garcia-Valverde et al., 2014; Hadjadj & Halimi, 2021; Hussain & Park, 2021; J. Kim et al., 2014; Lopes de Souza et al., 2023; Rhayem et al., 2021; Spoladore et al., 2021; Villarreal et al., 2014; G. Yu et al., 2022), medication (Alti et al., 2022; Elhadj et al., 2021; El-Sappagh et al., 2019; Hristoskova et al., 2014; Kordestani et al., 2021; Lopes de Souza et al., 2023; Peral et al., 2018; Rhayem et al., 2021; Titi et al., 2019; Xu et al., 2017), suitable environmental conditions (Chiang & Liang, 2015), hospital visits (Zhou et al., 2022), and other unspecified treatments and mitigations (Akhtar et al., 2022; Ali et al., 2021; De Brouwer et al., 2022; Martella et al., 2025; Mavropoulos et al., 2021; Zafeiropoulos et al., 2024). Two important considerations when choosing appropriate medications are their side effects and how they interact with other medications. Ali et al. (2021) use drug review websites to collect data on side effects, while Elhadj et al. (2021) keep track of medication interactions as well as patient allergies. Similarly, the system proposed by Ammar et al. (2021) includes an app where monitored individuals can report medication side effects. This information assists clinicians in prescribing appropriate medications for each patient. Related to recommendations is the ability for the monitored individual to seek out relevant and trusted medical information. For example, the system proposed by Rhayem et al. (2021) includes a notification module that allows patients to contact a clinician and receive recommendations and treatments from them.

5.4.2. Techniques for Decision Support

Much like situation detection and situation prediction, rule-based reasoning is the most commonly used technique for decision support in the selected systems. Rules are used by 37 of the 45 systems that implement decision support, of which 27 systems use semantic web rules in particular (Akhtar et al., 2022; Ali et al., 2020, 2018; Alti et al., 2022; Bampi et al., 2025; Chatterjee et al., 2021; Chiang & Liang, 2015; Elhadj et al., 2021; El-Sappagh et al., 2019; Esposito et al., 2018; Garcia-Valverde et al., 2014; Hadjadj & Halimi, 2021; Henaien et al., 2020; Hooda & Rani, 2020; Hristoskova et al., 2014; Kilintzis et al., 2019; J. Kim et al., 2014; Lopes de Souza et al., 2023; Mezghani et al., 2015; Rhayem et al., 2021; Spoladore et al., 2021; Stavropoulos et al., 2021; Titi et al., 2019; H. Q. Yu et al., 2017; Zafeiropoulos et al., 2024; Zeshan et al., 2023; Zhang et al., 2014). They are typically implemented based on detected and predicted situations, such that adverse situations trigger alerts or recommendations. Zafeiropoulos et al. (2024) combine ML and rules, using a graph convolution network to classify alerts into one of two levels (medium or high), after which the alerts are sent based on rules.

Similar to their approach for situation detection, Xu et al. (2017) adopt case-based reasoning rather than rules for decision support. They compare treatments and clinical paths in similar patients, and, if differences are found, the system sends an alert to flag the treatment plan for adjustment. Among the agent-based systems, the functionality related to decision support is often delegated to agents, such as the notification and alert agents in the systems proposed by Ivascu et al. (2015) and Ivaşcu and Negru (2021). Additionally, interactive agents and chatbots play an important role in decision support. Ammar et al. (2021) propose digital assistants that provide personalized alerts and suggestions and summarize text. Similarly, Mavropoulos et al. (2021) propose a smart virtual agent that clinicians can interact with via voice commands, while G. Yu et al. (2022) implement an AI chatbot to answer user questions.

5.4.3. Quality of Decision Support

An important factor in the quality of decision support is user agency. Rather than simply providing recommendations, decision support tools should allow decision-makers the agency to engage in decision-making by helping them to: (1) identify and narrow down options; (2) identify possible outcomes for each option; (3) judge which outcomes are most likely; (4) identify the value of each option based on their impact on stakeholders; (5) make tradeoffs using the aforementioned criteria; and finally, (6) understand how and why the tools work (Miller, 2023). This approach to decision support aligns with the human-centered AI paradigm, which advocates for AI systems to augment and enhance human capabilities and performance, rather than automating them away (De Cremer et al., 2022). Considering the first five of these criteria, none of the selected systems demonstrate this level of decision support. Among the systems that provide intervention recommendations, none offer more than a single option for a particular situation, nor do they identify the possible outcomes of the recommendation. Thus, users are likely to either dismiss the recommended interventions or accept them blindly (Miller, 2023), neither of which is optimal. We discuss the sixth criterion in Section 5.6 on explainability.

Furthermore, the soundness of recommended interventions can be ensured by incorporating established and clinically validated medical guidelines or vetted information from medical or allied health professional bodies. This can contribute to the acceptance of health monitoring systems by medical professionals and regulatory bodies. Despite this, only 15 of the selected systems mention the use of such guidelines or vetted medical information. They include Lopes de Souza et al. (2023), who incorporate risk level classifications from the American Heart Association, and De Brouwer et al. (2022), who use the International Classification of Headache Disorders’ criteria to issue relevant alerts. Garcia-Moreno et al. (2023) and Spoladore et al. (2021) use the International Classification of Functioning, Disability and Health for health status classification; while Ali et al. (2020) and Hristoskova et al. (2014) use the Framingham Risk Score to determine congestive heart failure risk. El-Sappagh et al. (2019) extract knowledge from bodies such as the American and Canadian diabetes associations, while H. Q. Yu et al. (2017) use guidelines from the United Kingdom’s National Health Service. Finally, the system proposed by Ammar et al. (2021) includes an option for clinicians to refer patients to trusted medical knowledge sources such as the Centers for Disease Control and Prevention.

5.4.4. The Role of SWTs

The main value that SWTs add to decision support in the selected systems is their ability to represent important concepts, particularly situations and domain knowledge, which can then be reasoned over. This is consistent with our findings on the role of SWTs in situation detection and situation prediction. It also aligns with previous research findings on the use of SWTs for decision support (Blomqvist, 2014; Jing et al., 2023). Rules are the most common reasoning tool among the selected systems, with semantic web rules used for decision support in 27 of them. However, rule-based reasoning for decision support faces the same limitations in scalability and lack of inherent uncertainty handling as discussed in the previous sections.

5.5.1. Location

Ye et al. (2007) highlight three types of locations that can be represented: symbolic locations, coordinate locations, and regions. The systems proposed by Akhtar et al. (2022), Bampi et al. (2025), Chiang and Liang (2015), and Vadillo et al. (2013) keep track of the different rooms in a house where an individual may be, while those proposed by Khozouie et al. (2018), Titi et al. (2019), and Zeshan et al. (2023) indicate more generally the place the monitored individual is (e.g., “home” or “hospital”). These are symbolic locations. One purpose of such locations is to allow the systems to suggest relevant services based on the type of space currently occupied, as is the case in the system proposed by Chiang and Liang (2015). In the system proposed by Hristoskova et al. (2014), the clinician’s location (i.e., the room they occupy in a hospital) is used to determine which device to send notifications to, optimizing for the closest device. Likewise, Zeshan et al. (2023) determine the closeness between the monitored individual and their caregivers in order to select which caregiver or clinician to notify in case of abnormal sensor observations. This is similar to the system proposed by Alti et al. (2022), which supports a GPS sensor that captures the current coordinates of the monitored individual. In this system, location is used to select devices closest to the user from which to deploy health services so as to increase efficiency and minimizse inter-device communication costs. Coordinate locations also serve the purpose of alerting caregivers and emergency services of the exact location of a person in the event of a medical emergency, as is suggested by Rhayem et al. (2021). The system proposed by Hadjadj and Halimi (2021) integrates health monitoring in the public transport system, and therefore includes location sensors in public transportation vehicles. The final type of location is regions, which are geometrical two- or three-dimensional representations of locations (Ye et al., 2007). This type of location is used in the system proposed by J. Kim et al. (2014) in order to advise users of region-specific situations, such as adverse or dangerous weather. Similarly, Ammar et al. (2021) use ZIP codes, which represent a small geographic region, to extract neighborhood-specific social determinants of health such as walkability. El-Sappagh et al. (2019) use the spatial region class from the Basic Formal Ontology to represent the patient’s current location, as well as the placement of the sensors. Despite the importance of location as an aspect of context, only 21 of the 48 systems (Akhtar et al., 2022; Alti et al., 2022; Ammar et al., 2021; Bampi et al., 2025; Chiang & Liang, 2015; De Brouwer et al., 2022; Elhadj et al., 2021; El-Sappagh et al., 2019; Garcia-Moreno et al., 2023; Hadjadj & Halimi, 2021; Henaien et al., 2020; Hristoskova et al., 2014; Khozouie et al., 2018; J. Kim et al., 2014; Martella et al., 2025; Reda et al., 2022; Rhayem et al., 2021; Titi et al., 2019; Vadillo et al., 2013; H. Q. Yu et al., 2017; Zeshan et al., 2023) include it.

5.5.2. Time

In contrast, all of the systems include the concept of time, with the exception of five (Ali et al., 2020, 2018; Fenza et al., 2012; Hooda & Rani, 2020; G. Yu et al., 2022). Observation time is the most common way time is incorporated in the systems, with 25 systems capturing the exact timestamp for each sensor observation (Alti et al., 2022; Bampi et al., 2025; Chatterjee et al., 2021; De Brouwer et al., 2022; Elhadj et al., 2021; El-Sappagh et al., 2019; Esposito et al., 2018; Garcia-Moreno et al., 2023; Hadjadj & Halimi, 2021; Hussain & Park, 2021; Ivascu et al., 2015; Khozouie et al., 2018; Kilintzis et al., 2019; Lopes de Souza et al., 2023; Martella et al., 2025; Mavropoulos et al., 2021; Minutolo et al., 2016; Peral et al., 2018; Reda et al., 2022; Rhayem et al., 2021; Stavropoulos et al., 2021; Titi et al., 2019; Vadillo et al., 2013; Zafeiropoulos et al., 2024; Zeshan et al., 2023). Besides observation time, the time at which certain events occur can be captured, for example, calls to emergency services (Alti et al., 2022). This allows the systems to display or analyze trends over time. Additionally, Alti et al. (2022) capture the time intervals in which reports should be sent. Rather than a timestamp, Ali et al. (2021) record the general time of day during which daily activities occur, that is, morning, afternoon, or evening. Similarly, Peral et al. (2018) use mealtimes as a point of reference, which is particularly important when taking blood glucose measurements. They distinguish between pre-breakfast, pre-lunch, and pre-dinner readings.

Duration and frequency are other important aspects of time. Duration can be captured for disease (Zafeiropoulos et al., 2024), physical activity (Chatterjee et al., 2021; Spoladore et al., 2021), sleep (Chatterjee et al., 2021; Stavropoulos et al., 2021; Zhou et al., 2022), symptoms (Mcheick et al., 2016), and treatment (Titi et al., 2019; Xu et al., 2017). De Brouwer et al. (2022) capture headache duration as well as the duration of events that influence headaches, such as stress and sleep. Symptom duration can influence the risk for certain illnesses, while specifying treatment duration ensures medication reminders are sent only during the prescribed period. When combined with thresholds, duration can be useful in identifying different situations. For example, Stavropoulos et al. (2021) determine that an individual has a lack of movement if they have fewer than 500 steps and their heart rate has been <100 beats per minute for longer than 800 min. Frequency is used by Chiang and Liang (2015), Spoladore et al. (2021), and H. Q. Yu et al. (2017) as a metric for physical activity. Other examples of frequency in the systems are frequency of sensor observations (Mezghani et al., 2015) and frequency of disease occurrence (Villarreal et al., 2014).

Notably, valuable features can be extracted from changes in time series sensor data. For instance, Hussain and Park (2021) and Ivaşcu and Negru (2021) use the time-domain features of the ECG to calculate heart rate and heart rate variability. Additionally, the multi-agent system proposed by Akhtar et al. (2022) incorporates temporal logic, which allows for the formalization of temporal ordering operators such as “next,” “always,” “until,” and “while” without referencing actual times (Alagar & Periyasamy, 2011). Another interesting time-related aspect is trajectory, which combines both spatial and temporal properties to represent the mobility of a sensor. This is incorporated in the system proposed by Rhayem et al. (2021) to define a source and destination of a sensor within a particular duration of time.

5.5.3. Identity

Identity, which pertains to the actors in a system, is another important aspect of context (Ye et al., 2007). This includes the definition of individuals and their properties, such as name, address, gender, and age. For health monitoring, this can include additional information such as weight, height, and blood group. This is the most ubiquitous aspect of context in the systems, with every system including personal information about the monitored individuals. Besides personal properties, identity also encompasses different user roles within the system. Nearly all of the systems support different users besides the individual being monitored, typically including clinicians and, in some cases, caregivers and family members, with the exception of 11 systems (Chiang & Liang, 2015; Fenza et al., 2012; Garcia-Valverde et al., 2014; Henaien et al., 2020; Khozouie et al., 2018; J. Kim et al., 2014; Martella et al., 2025; Minutolo et al., 2016; Vadillo et al., 2013; H. Q. Yu et al., 2017; Zhang et al., 2014). Identity also includes agents, which are used in the agent-based systems (Akhtar et al., 2022; Alti et al., 2022; Ammar et al., 2021; Ivascu et al., 2015; Ivaşcu & Negru, 2021; Martella et al., 2025; Mavropoulos et al., 2021; Vadillo et al., 2013). Agents, that is, computer systems capable of acting autonomously to achieve some goal(s) (Wooldridge, 2013), have been applied extensively in the health domain (Isern & Moreno, 2016) as well as in sensor-based systems (Savaglio et al., 2020). The agent-based approach offers several advantages. For example, agents can be used as personal assistants to support humans in performing tasks and services (Montagna et al., 2020), such as the interactive virtual agent in the system proposed by Mavropoulos et al. (2021). Agent-based architectures and their advantages are discussed in greater detail in Section 7.

5.5.4. Activity

The fourth essential aspect of context is activity. This can refer to physical activity or the different activities of daily living, such as eating and sleeping, both of which are important considerations for situation analysis. Activity can be derived from sensors such as accelerometers, or can be deduced from location or time (e.g., a person in a bedroom in the middle of the night can be assumed to be sleeping). Physical activity is closely tied to health, and there are many physical activity guidelines issued by governments and global health organizations, including the World Health Organization (Bull et al., 2020). Due to this link between physical activity and health, 31 of the systems include physical activity as contextual information. Such systems monitor physical activity using smartphones, smart watches, or inertial measurement units, which combine accelerometers, gyroscopes, and in some cases, magnetometers (Ali et al., 2020, 2021; De Brouwer et al., 2022; El-Sappagh et al., 2019; Esposito et al., 2018; Garcia-Moreno et al., 2023; Garcia-Valverde et al., 2014; Ivascu et al., 2015; Ivaşcu & Negru, 2021; Khozouie et al., 2018; Lopes de Souza et al., 2023; Mavropoulos et al., 2021; Minutolo et al., 2016; Zafeiropoulos et al., 2024). Chiang and Liang (2015) monitor body movement using motion sensors placed around the home. This serves two purposes. Firstly, the individual’s movement within the home is able to be monitored. This can determine their location at any given time. Secondly, they are able to interact with the system using body movements, such as hand-waving to activate the system. Ali et al. (2018) similarly use motion sensors to keep track of body movement. They use range of motion as a metric, which is particularly important for elderly patients who may lose their ability to perform daily activities as their range of motion decreases. The systems proposed by Ivascu et al. (2015) and Zafeiropoulos et al. (2024) perform gait analysis, capturing features such as freezing of gait, postural instability, and rigidity.

Self-reported information can also be used to determine physical activity, but this may not be accurate. To mitigate this, Chatterjee et al. (2021) use a combination of sensor and questionnaire data. Sensors are used to monitor the number of steps and duration of activity, while questionnaires are used to determine the type of activity, for example, running or weightlifting. Beyond tracking physical activity, activity recognition is also important in health monitoring. It can help in the detection of adverse events such as falls, as is done in the systems proposed by Chiang and Liang (2015), Vadillo et al. (2013), and Zafeiropoulos et al. (2024). Additionally, seven systems are able to recognize daily activities such as sitting, walking, and sleeping (De Brouwer et al., 2022; Garcia-Moreno et al., 2023; Garcia-Valverde et al., 2014; Ivaşcu & Negru, 2021; Mavropoulos et al., 2021; Rhayem et al., 2021; Zafeiropoulos et al., 2024).

5.5.5. Other Types of Context

Besides location, time, identity, and activity, other types of contextual information are incorporated in the systems. Alti et al. (2022) include hardware and network information as part of context, such as available communication protocols, CPU speed, battery power, and memory size. This information is used to ensure the efficient deployment of health services. Similarly, Zeshan et al. (2023) use battery level and device response time to determine which caregiver or clinician’s device to send notifications to. Hristoskova et al. (2014) incorporate media devices and their properties in their interpretation of context. For example, the screen size of devices such as mobile phones and tablets is used to determine how to display the health monitoring results. For small screens, the results are summarized. An important factor in health monitoring is the state of a person’s environment. Fifteen of the systems use weather data such as temperature and humidity from ambient sensors to provide additional context (Akhtar et al., 2022; Bampi et al., 2025; Chatterjee et al., 2021; Chiang & Liang, 2015; Elhadj et al., 2021; Fenza et al., 2012; Garcia-Moreno et al., 2023; Henaien et al., 2020; Khozouie et al., 2018; J. Kim et al., 2014; Kordestani et al., 2021; Martella et al., 2025; Rhayem et al., 2021; Titi et al., 2019; Vadillo et al., 2013; Zhou et al., 2022). Weather data sources such as forecasts and indices are used by J. Kim et al. (2014) to supplement sensor data, while the other systems (Akhtar et al., 2022; Khozouie et al., 2018; Martella et al., 2025; Vadillo et al., 2013; Zhou et al., 2022) include sensors to monitor air quality by checking the levels of different gases and/or inhalable particulate matter in the air. Contextual information can also include details about an individual’s diet, medication, and emotional state. These details are collected in the system proposed by De Brouwer et al. (2022) through self-reporting via a mobile app. Finally, Martella et al. (2025) and Zafeiropoulos et al. (2024) capture information about the user’s fatigue level.

5.5.6. The Role of SWTs

Ontologies appear to be particularly useful for the representation of contextual information, and the majority of the selected systems reuse existing ontologies to do so. For instance, OWL-Time, ³⁰ an ontology that describes temporal properties of real-world objects such as sensors, is reused by a number of systems (De Brouwer et al., 2022; Mavropoulos et al., 2021; Rhayem et al., 2021; Titi et al., 2019; H. Q. Yu et al., 2017). Friend of a Friend (FOAF), ³¹ an ontology that describes people profiles, is also widely reused among the systems (Ammar et al., 2021; Elhadj et al., 2021; Garcia-Moreno et al., 2023; Henaien et al., 2020; Mavropoulos et al., 2021; Reda et al., 2022; Spoladore et al., 2021; Titi et al., 2019; H. Q. Yu et al., 2017). Additionally, sensor ontologies, while not focused solely on contextual information, also include some aspects of context. For example, SAREF and SSN/SOSA ontologies include timestamps for sensor observations. Knowledge graphs can also be used to represent contextual information, as is done by Ammar et al. (2021) and G. Yu et al. (2022), who use a knowledge graph to capture patient profile data from health records. Linked data are also useful for context awareness. For instance, Ammar et al. (2021) use linked open data to access global knowledge from the web, including data relating to social determinants of health. Additionally, Martella et al. (2025) mention the possibility of using linked open data as a source of external information, although this is not implemented in the system.

Table 7 summarizes the contextual information included in the systems and indicates which types of contextual information are captured using SWTs.

5.6.1. Intrinsic Explainability

It can be argued that SWTs are inherently intuitive and can contribute to the development of explainable systems; we discuss this in Section 5.6.4. However, the use of these technologies does not guarantee the explainability of the system as a whole. Other technologies and techniques implemented within the systems, and the ways in which they are combined, can also play a role in either enhancing or hindering the overall explainability of the system. For example, rules are inherently easy to understand (Hagras, 2018), and nearly all the selected systems implement some form of rule-based reasoning using semantic web rule languages. However, in some cases, rules are implemented for one aspect of the system while less interpretable techniques are used for other components. An instance of this is the system proposed by Ali et al. (2020), where a deep learning model is used for disease prediction, while rule-based reasoning is applied for recommendation generation. This results in the decision support functionality being highly explainable, while the situation prediction component remains less so.

BNs can also be considered highly interpretable, as they can perform predictive and diagnostic reasoning (Derks & de Waal, 2020) in a way that can be visually interpreted due to their graphical structure (Kyrimi et al., 2021). Predictive reasoning is done by Mcheick et al. (2016), who use a BN to determine whether a person has a high risk of stroke based on risk factors. The reason for whether the risk is high or not can be traced back to the presence of risk factors. On the other hand, Kordestani et al. (2021) use a BN for diagnostic reasoning, allowing for the understanding of a kidney disease diagnosis based on its causes. Fuzzy logic represents another class of interpretable techniques, since it allows variables and their classifications to be presented in a way that is intuitive (Hagras, 2018). Fuzzy approaches are used in five of the selected systems; we discuss them in more detail in Section 5.7.1.

While ML is often criticized for its tendency to produce black box models, certain ML models are intrinsically interpretable, such as logistic or linear regression models and decision trees (Molnar, 2023; Petch et al., 2022). However, even such models can be rendered uninterpretable as their complexity and scale increase, as is the case with large decision trees (Petch et al., 2022). In cases where less interpretable ML models are used, they can be combined with SWTs to enhance explainability. This is closely related to neuro-symbolic AI, in which the strengths of neural networks and symbolic AI are combined to achieve the best of both worlds (Sarker et al., 2021). Zafeiropoulos et al. (2024) and Zhou et al. (2022) explore this hybrid approach, with both using a knowledge graph to provide training data for deep learning models. Additionally, Ali et al. (2021) use an ontology for feature extraction, providing some transparency into the selection of features for their BiLSTM model.

5.6.2. Post hoc Explainability

The use of inherently interpretable models should be prioritized in high-stakes domains (Rudin, 2019). Nonetheless, explaining the workings of a model after it has been trained is a well-established approach to explainability (Molnar, 2023). Two well-known post hoc explainability techniques are Local Interpretable Model-agnostic Explanations (LIMEs; Ribeiro et al., 2016) and SHapley Additive exPlanations (SHAP; Lundberg & Lee, 2017). LIME approximates a black box model with an interpretable surrogate model that is then used to explain the original model’s predictions. SHAP, by contrast, uses Shapley values from coalitional game theory to explain individual predictions by quantifying how much each feature contributes to the outcome. Beyond these methods, plotting techniques can also be used to visualize feature effects. They include partial dependence plots, which show the marginal effects of one or two features on predictions; accumulated local effects plots, which provide more accurate feature effects by accounting for feature correlations; and individual conditional expectation plots, which show how an individual prediction changes when a feature changes (Molnar, 2023). However, such post hoc explainability methods are not mentioned in any of the selected systems.

5.6.3. Explanation Quality

Once the reasoning behind the system’s outputs has been determined, the next step is to communicate this to the users of the system through explicit explanations. An explanation can be defined as the answer to a why-question (Miller, 2019), such as “Why was the situation classified as an emergency?,” “Why was an alert sent to the clinician?,” or “Why was this medication recommended?” Good explanations have the following characteristics (Molnar, 2023):

They are contrastive, showing the contrast between the selected outcome and other possibilities.

The target audience is also an important consideration in the communication of explanations, since different audiences may value distinct aspects based on their role and perspective (Barredo Arrieta et al., 2020). Health monitoring systems should therefore tailor explanations to the needs of various audiences, such as monitored individuals, clinicians, and caregivers. For certain audiences, such as regulatory stakeholders, it may be more appropriate to include explanations as part of the overall system documentation. Only eight of the selected systems report or indicate that some form of explanation is made available to users (Akhtar et al., 2022; Chiang & Liang, 2015; Elhadj et al., 2021; Martella et al., 2025; Mavropoulos et al., 2021; Rhayem et al., 2021; Villarreal et al., 2014; G. Yu et al., 2022). This is typically through a user interface, messaging platform, or, as in the system proposed by Akhtar et al. (2022), as part of system logs. Chatbots and virtual agents, as implemented by Mavropoulos et al. (2021) and G. Yu et al. (2022), can also provide explanations, since they are designed to answer queries from users.

5.6.4. The Role of SWTs

Domain knowledge can enhance explainability (Tocchetti & Brambilla, 2022), and SWTs excel at structuring such shared knowledge formally (Confalonieri & Guizzardi, 2025). Ontologies can contribute to the development of explainable systems from three perspectives: by providing sound and explicit knowledge reference models; by supporting common-sense reasoning through the representation of context-aware semantic information; and by facilitating flexible knowledge abstraction and refinement (Confalonieri & Guizzardi, 2025). Since most of the systems use ontologies to represent expert knowledge and contextual information, this can be seen as a first step toward achieving explainability. Moreover, many ontology reasoners, such as HermiT (Shearer et al., 2008) and Pellet (Sirin et al., 2007), provide justifications for their inferences. These justifications can be generated into human-readable explanations, which in turn can be presented to system users (Van Woensel et al., 2024). Although 11 systems (Ali et al., 2018; Chatterjee et al., 2021; Elhadj et al., 2021; El-Sappagh et al., 2019; Esposito et al., 2018; Hooda & Rani, 2020; Hristoskova et al., 2014; Khozouie et al., 2018; Titi et al., 2019; Vadillo et al., 2013; Zafeiropoulos et al., 2024) mention using ontology reasoners, none of them indicate that the reasoner justifications are presented to users as explanations. Beyond reasoners, explanations themselves can be represented using ontologies. For instance, the Explanation Ontology (Chari et al., 2024) is a general-purpose ontology that connects explanations to underlying data and knowledge. Similarly, the Evidence and Conclusion Ontology (Nadendla et al., 2022) captures evidence to support annotations and assertions in the biomedical domain, which can be used to generate explanations. Yet, none of the reviewed systems formalize explanations in this way.

Knowledge graphs can also contribute to better understanding of system outputs in several ways, including providing a graph-based visualization of concepts, entity and relation extraction from unstructured data, enrichment of datasets, and inference and reasoning (Rajabi & Kafaie, 2022). Finally, although the connection between linked data and explainability is not direct, the open accessibility and interconnection of knowledge shared using a linked data approach can nonetheless contribute to explainability.

Fuzzy logic is a widely used technique for representing ambiguity and vagueness in sensor data (Khaleghi et al., 2013). It is used by five of the systems, making it the most commonly implemented uncertainty handling approach among the systems, besides the preprocessing of sensor data. In fuzzy logic, the truth of a statement is not binary (i.e., either true or false), but can rather be represented in a range from false to true. Therefore, rather than having crisp thresholds for different categories, fuzzy logic allows for values with different degrees of membership for the different categories. The process of converting crisp inputs into fuzzy sets is called fuzzification. For example, heart rate is represented in beats per minute, which can be classified into crisp categories. Generally, a heart rate greater than 100 beats per minute can be categorized as “fast,” a heart rate between 60 and 100 beats per minute can be categorized as “normal,” and a heart rate below 60 beats per minute can be categorized as “slow” (Bennett, 2013). However, with fuzzy logic, any given heart rate value has a certain degree of membership to any of the categories. For instance, a heart rate of 80 beats per minute may have a high degree of membership to the “normal” category (e.g., 75%), a lower degree of membership to the “fast” category (e.g., 20%), and an even lower degree of membership to the “slow” category (e.g., 5%). Fuzzy logic provides a better approach to dealing with boundary conditions. For example, when the heart rate is either 100 or 101, it can be reflected as mostly normal and, to a lesser degree, fast. Both Ali et al. (2018) and Chiang and Liang (2015) fuzzify sensor data such as blood pressure and heart rate, as well as attributes such as age and weight. Similarly, Esposito et al. (2018) fuzzify the intensity of physical activity, which provides important context for heart rate thresholds. Fenza et al. (2012) incorporate fuzzy logic with rules to determine the degree of membership to different situation categories based on different combinations of vital signs, while Minutolo et al. (2016) use hybrid rules that incorporate both crisp and fuzzy variables. Fuzzy logic provides a simple but effective mechanism for representing imprecision and vagueness in sensor observations and allows this to be taken into account for more effective situation detection.

5.7.2. Bayesian Networks (BNs)

BNs are well known for modeling uncertainty and have been widely used in the health domain (Kyrimi et al., 2021). Kordestani et al. (2021) use a BN for probabilistic diagnosis of acute kidney injury. The BN models immediate (short-term) and background (long-term) causes of acute kidney injury, as well as its symptoms. They used experts to determine the conditional probabilities of the presence of acute kidney injury given these variables. Similarly, Mcheick et al. (2016) represent risk factors for stroke using a BN.

5.7.3. Nonmonotonic Reasoning

Monotonic reasoning holds that the rejection of an earlier conclusion must only be done if the evidence for the conclusion is also rejected. Contrastingly, nonmonotonic reasoning holds that an earlier conclusion can be rejected based on new evidence, even when earlier evidence was valid (Nute, 2003). This ability to revise conclusions in the face of new evidence is useful in handling uncertainty. Defeasible logic is an example of nonmonotonic reasoning in which there are three kinds of rules: strict rules, which can never have exceptions, defeasible rules, which are typically true but can have exceptions, and undercutting defeaters, which are weak possibilities (Nute, 2003). Akhtar et al. (2022) use defeasible logic to handle inconsistencies in sensor data as well as patient information. Another type of nonmonotonic reasoning is answer set programming (ASP), which is used by Kordestani et al. (2021) to automatically customize treatments for each patient. They combine ASP with probability to reason with uncertain knowledge regarding treatment. Using probabilistic ASP rules, their proposed system obtains all possible treatment options for a medical episode and the associated probability of the episode occurring. If the probability of the episode occurring decreases with a particular treatment, then the treatment’s award value is increased. The treatment with the highest award value is ultimately selected by the system.

5.7.4. Probabilistic Risk Classification

Hristoskova et al. (2014) account for uncertainty in situation prediction by classifying patients into risk stages based on the four-year probability of congestive heart failure. They use probabilistic rules defined using SWRL to analyze risk factors and classify individuals based on the Framingham Risk Score.

5.7.5. Preprocessing Sensor Data

Uncertainty can stem from various factors in sensor data, including ambiguous or imprecise readings, noise, or missing values caused by sensor malfunctions or network failures (Gravina et al., 2017; Khaleghi et al., 2013). Sixteen systems have addressed the issue of missing or invalid values in sensor data. Ali et al. (2020, 2021) replace them with mean and median values from existing data, while Hooda and Rani (2020) replace them using the preceding value. Rhayem et al. (2021) take the approach of removing any missing or unusual values, for example, those outside the device measurement ranges. Similarly, Kilintzis et al. (2019), Martella et al. (2025), Titi et al. (2019), and Reda et al. (2022) use rules to check whether sensor data falls within the expected minimum and maximum bounds. In their proposed system, Hussain and Park (2021) use the Pan-Tompkins algorithm to detect the QRS complex in the ECG. This identifies beats without a QRS complex, which may be premature, missing, or ectopic, and are subsequently eliminated. While Garcia-Moreno et al. (2023) mention missing value imputation as part of their ML pipeline, they do not specify a technique for this. To deal with noisy data, three systems use filters to improve signal quality. Ali et al. (2020, 2021) use a Kalman filter to remove noise, while Garcia-Valverde et al. (2014) use a moving average filter for the same purpose.

5.7.6. The Role of SWTs

As discussed in the previous challenges, SWTs provide limited inherent support for uncertainty handling, but this can be mitigated through the techniques discussed in this section. Several extensions for semantic web standards have been proposed in the literature that make use of fuzzy logic and Bayesian inference, such as BayesOWL (Ding et al., 2006) and Bayes-SWRL (Liu et al., 2013), probabilistic extensions for OWL and SWRL, respectively, as well as fuzzyDL (Bobillo & Straccia, 2016), a fuzzy ontology reasoner. However, none of the selected systems reports using any such extensions, opting instead to define custom solutions. Another way that SWTs can support uncertainty handling is through using ontology reasoners for inconsistency detection. Missing values or otherwise invalid data can be detected through ontology reasoners based on specified and inferred axioms; the use of these tools is discussed in greater detail in Section 6. Additionally, rule-based reasoning can be combined with ontologies to detect invalid data, an approach used by five of the selected systems (Kilintzis et al., 2019; Martella et al., 2025; Reda et al., 2022; Rhayem et al., 2021; Titi et al., 2019). Finally, SWTs can indirectly support uncertainty handling by representing data quality properties that affect uncertainty. For instance, Garcia-Moreno et al. (2023) model quality properties of sensor data using an ontology, including correctness and completeness.

5.8.1. Security and Privacy

As health-related information is highly sensitive, security and privacy are important to consider. Particular aspects of this include security of data storage, network and transmission security, user authentication and access control, consent management, and the use of privacy-preserving techniques such as federated learning. For insights on security and privacy, we direct interested readers to the following articles: Rasool et al. (2022) review security and privacy in the context of the Internet of Medical Things; Thapa and Camtepe (2021) explore security and privacy challenges and techniques for health data in general; and finally, Kirrane et al. (2018) provide an overview of security and privacy issues that relate to SWTs.

5.8.2. Usability

Usability is another factor that health monitoring systems should consider, and can broadly be defined as the ease of use of a system. It is a multi-faceted concept with several contributing factors, including understandability (which is closely related to explainability), attractiveness, and overall user satisfaction (Saeed et al., 2020). Interested readers can refer to the following articles for more information: Saeed et al. (2020) explore pertinent usability issues in health monitoring systems and identify possible solutions. With regard to the evaluation of usability, Maramba et al. (2019) identify current methods used in usability testing in health monitoring applications, while Cho et al. (2018) present a usability evaluation framework for mobile health applications. Finally, considering the usability of the sensors themselves, the reviews by Cusack et al. (2024), Dias and Cunha (2018), and Andreu-Perez et al. (2015) highlight the types and characteristics of wearable sensors available for health monitoring.

5.8.3. Scalability

Scalability generally refers to the ability of a system to handle increased workload (Weinstock & Goodenough, 2006). In the context of sensor-based health monitoring, this workload could arise from an increased number of sensors, other data sources, users, and services provided by the system. For further reading on scalability in IoT applications, readers can consult the review by Fortino et al. (2021). The reviews by Albahri et al. (2018) and Philip et al. (2021) discuss scalability in the context of IoT and healthcare.

5.8.4. Ethics and Regulatory Compliance

The high-stakes nature of the health domain necessitates careful consideration of ethical issues. Although there are many benefits of technology-enabled personal health monitoring, there are also potential harms that it exposes. Many of these ethical issues overlap with the challenges already discussed, such as situation detection and situation prediction (how accurate and reliable are the detected and predicted situations?), decision support (how appropriate are the suggested recommendations and how much autonomy do system users have?), explainability (to what extent can system outputs be understood?), and security and privacy (how secure is user data and how is consent managed?). An additional ethical concern is the cascade of care, a phenomenon in which incidental findings from screenings or monitoring result in further clinical care. This may cause undue anxiety and psychological harm to the monitored individual, while also potentially leading to costly or invasive diagnostic procedures. Some of these ethical considerations can be enforced through regulation. Readers seeking further exploration on this challenge may consult the following articles: Morley et al. (2020) comprehensively map the ethics of AI in healthcare; Kwan et al. (2017) highlight the ethical issues associated with health monitoring applications; Nittari et al. (2020) review ethical and legal challenges in telemedicine more broadly; Hassanaly and Dufour (2021) explore the regulation of mobile health applications in the United States, the European Union, and France; and Thapa and Camtepe (2021) explore legality and regulatory compliance from the perspective of security and privacy.

6.2.1. Development Methodologies

The use of a development methodology can streamline the process of developing SWTs. In particular, the literature on ontology development methodologies is quite rich, with a large number of established methodologies proposed (Fernández-López & Gómez-Pérez, 2002; Iqbal et al., 2013). There have also been several proposed approaches toward developing knowledge graphs (Cimiano & Paulheim, 2017) and ensuring the quality of linked data (Debattista et al., 2016; Kontokostas et al., 2014). Despite this, only five systems specified an existing methodology for SWTs, with all five methodologies being ontology-focused. Hadjadj and Halimi (2021) used the NeOn framework (Suárez-Figueroa et al., 2015), a scenario-based methodology for building ontologies, while Zafeiropoulos et al. (2024) used the Human-Centered Ontology engineering MEthodology (HCOME; Kotis & Vouros, 2006). Titi et al. (2019) used an existing case-based ontology engineering methodology (El-Sappagh et al., 2014). Similarly, Kilintzis et al. (2019) followed four of the ontology construction steps recommended by Spear (2006). Although not a development methodology, Peral et al. (2018) used the SemanTic Refinement of Ontology MAppings (STROMA; Arnold & Rahm, 2014) approach for aligning corresponding concepts between different ontologies.

Additionally, two systems reported the use of existing methodologies for overall system development. Garcia-Moreno et al. (2023) used the design science research methodology (Hevner & Chatterjee, 2010), while Vadillo et al. (2013) used CommonKADS (Knowledge Acquisition and Development Systems; (Kingston, 1998)), a knowledge-based system design methodology, and its extension for multi-agent systems, MAS-CommonKADS (Iglesias et al., 1998). Overall, only 16 of the systems reported or described the use of a systematic methodology, whether existing or novel, in the development of either the SWTs, other system components, or the system as a whole.

6.2.2. Development Tools

Various programming languages, frameworks, and libraries were used to develop the systems. When it comes to rule languages, SWRL is the most commonly used, with 24 systems either explicitly mentioning it or demonstrating SWRL syntax in code snippets (Akhtar et al., 2022; Ali et al., 2020, 2018; Alti et al., 2022; Bampi et al., 2025; Chatterjee et al., 2021; Elhadj et al., 2021; El-Sappagh et al., 2019; Esposito et al., 2018; Hadjadj & Halimi, 2021; Henaien et al., 2020; Hooda & Rani, 2020; Hristoskova et al., 2014; Lopes de Souza et al., 2023; Mezghani et al., 2015; Minutolo et al., 2016; Reda et al., 2022; Rhayem et al., 2021; Spoladore et al., 2021; Titi et al., 2019; H. Q. Yu et al., 2017; Zafeiropoulos et al., 2024; Zeshan et al., 2023; Zhang et al., 2014). Apache Jena includes a general purpose rule-based reasoner which is used by three systems (Chiang & Liang, 2015; Garcia-Valverde et al., 2014; J. Kim et al., 2014). Other semantic web-based rule languages include SHACL, used by Stavropoulos et al. (2021) and SPIN, used by Kilintzis et al. (2019). Although Mavropoulos et al. (2021) mention using OWL to create rules, this approach is inherently limited for situation analysis and decision support because OWL lacks the expressivity for if–then rules. The authors indicate that they will implement more complex reasoning rules in future work.

Programming languages can also be used to configure rules, as is done by Khozouie et al. (2018) using Java. Similarly, Fenza et al. (2012) use MATLAB and Fuzzy Control Language to define their fuzzy rules, while Kordestani et al. (2021) use Drools, ³⁵ a business rule management system. Therefore, among the 41 systems that implement rules, 25 systems use semantic web-based rule languages, while three use non-semantic web languages. Eight systems do not mention or indicate a specific formal language in which rules are defined (Ali et al., 2021; Ammar et al., 2021; Hussain & Park, 2021; Ivascu et al., 2015; Ivaşcu & Negru, 2021; Martella et al., 2025; Peral et al., 2018; G. Yu et al., 2022). For queries, 26 of the systems use SPARQL, with five also using Apache Jena Fuseki, a SPARQL server, to publish their SPARQL endpoints.

Among the systems that incorporate ontologies, Protégé ³⁶ is most commonly cited as the ontology development platform of choice, used in 27 of the systems (Akhtar et al., 2022; Ali et al., 2018, 2020, 2021; Alti et al., 2022; Bampi et al., 2025; Chatterjee et al., 2021; Chiang & Liang, 2015; De Brouwer et al., 2022; Elhadj et al., 2021; El-Sappagh et al., 2019; Esposito et al., 2018; Hadjadj & Halimi, 2021; Henaien et al., 2020; Hooda & Rani, 2020; Hussain & Park, 2021; Ivascu et al., 2015; Ivaşcu & Negru, 2021; Khozouie et al., 2018; J. Kim et al., 2014; Martella et al., 2025; Spoladore et al., 2021; Titi et al., 2019; Vadillo et al., 2013; Zafeiropoulos et al., 2024; Zeshan et al., 2023; Zhang et al., 2014). Protégé is an ontology editor that supports the latest OWL and RDF specifications. Another commonly used platform is Apache Jena, ³⁷ a Java framework for building semantic web and linked data applications, used in 18 of the systems (Ali et al., 2018; Alti et al., 2022; Bampi et al., 2025; Chatterjee et al., 2021; Chiang & Liang, 2015; De Brouwer et al., 2022; Elhadj et al., 2021; Garcia-Valverde et al., 2014; Hadjadj & Halimi, 2021; Hooda & Rani, 2020; Ivascu et al., 2015; Ivaşcu & Negru, 2021; J. Kim et al., 2014; Rhayem et al., 2021; Titi et al., 2019; Vadillo et al., 2013; H. Q. Yu et al., 2017; Zeshan et al., 2023). Twenty-seven systems report using OWL (Ali et al., 2018, 2020, 2021; Ammar et al., 2021; Chatterjee et al., 2021; Elhadj et al., 2021; El-Sappagh et al., 2019; Esposito et al., 2018; Fenza et al., 2012; Hadjadj & Halimi, 2021; Hooda & Rani, 2020; Hristoskova et al., 2014; Khozouie et al., 2018; Kilintzis et al., 2019; J. Kim et al., 2014; Mavropoulos et al., 2021; Minutolo et al., 2016; Reda et al., 2022; Rhayem et al., 2021; Spoladore et al., 2021; Stavropoulos et al., 2021; Titi et al., 2019; Vadillo et al., 2013; H. Q. Yu et al., 2017; Zafeiropoulos et al., 2024; Zeshan et al., 2023; Zhang et al., 2014), while 16 report using RDF (Ammar et al., 2021; Bampi et al., 2025; Chatterjee et al., 2021; Chiang & Liang, 2015; De Brouwer et al., 2022; Hadjadj & Halimi, 2021; Hooda & Rani, 2020; Hussain & Park, 2021; Kilintzis et al., 2019; Lopes de Souza et al., 2023; Mezghani et al., 2015; Reda et al., 2022; Titi et al., 2019; H. Q. Yu et al., 2017; Zafeiropoulos et al., 2024; Zhang et al., 2014). Ammar et al. (2021) use Solid (Social Linked Data), ³⁸ a platform for developing decentralized linked data applications with the goal of enhanced privacy and data ownership. They also mention the JavaScript-based LDflex ³⁹ and the Python-based RDFlib ⁴⁰ for linked data manipulation and querying, the latter of which is also used by Zafeiropoulos et al. (2024). These platforms and libraries are all free and open source.

For storage, Mavropoulos et al. (2021) and Stavropoulos et al. (2021) use GraphDB, while Spoladore et al. (2021) use Stardog. ⁴¹ Both of these are enterprise semantic databases. Non-semantic database management systems are also used by 11 of the systems, with SQL-based systems being more popular than NoSQL alternatives. Four systems use MySQL ⁴² (Alti et al., 2022; Chiang & Liang, 2015; Titi et al., 2019; Villarreal et al., 2014), three use SQLite ⁴³ (El-Sappagh et al., 2019; Esposito et al., 2018; Lopes de Souza et al., 2023), and one uses PostgreSQL ⁴⁴ (Martella et al., 2025), while three systems use the NoSQL database system MongoDB ⁴⁵ (De Brouwer et al., 2022; Elhadj et al., 2021; Martella et al., 2025). A summary of all the development tools used in the selected systems is included in Table 19 in the Appendix.

7.1.1. Layered Architecture

The most common type of architecture among the systems is the layered architecture, implemented in 28 of the systems (Akhtar et al., 2022; Ali et al., 2018, 2020, 2021; Alti et al., 2022; Ammar et al., 2021; Elhadj et al., 2021; Esposito et al., 2018; Fenza et al., 2012; Garcia-Moreno et al., 2023; Hadjadj & Halimi, 2021; Henaien et al., 2020; Kilintzis et al., 2019; J. Kim et al., 2014; Kordestani et al., 2021; Lopes de Souza et al., 2023; Martella et al., 2025; Mavropoulos et al., 2021; Mcheick et al., 2016; Mezghani et al., 2015; Reda et al., 2022; Spoladore et al., 2021; Titi et al., 2019; Vadillo et al., 2013; Villarreal et al., 2014; Xu et al., 2017; H. Q. Yu et al., 2017; Zhang et al., 2014). In this pattern, each layer consists of a group of subtasks, with each group being at a particular level of abstraction (Buschmann et al., 1996). This offers several advantages. It is simple to understand, and the separation of concerns among the different layers makes it easy to test and maintain the systems developed using this architecture (Richards, 2015). Among the systems, there are variations in the number of layers and their functionality. However, the first layer is typically dedicated to data collection from wearable or ambient sensors as well as other data sources. It may be named the data collection layer, as in the systems by Ali et al. (2020, 2021), the sensing layer, as in the systems by Elhadj et al. (2021) and Esposito et al. (2018), or the user layer, as in the system by Alti et al. (2022). Other typical layers include a data storage layer in which data are securely stored; networking layer which manages data communication and transmission in the system; inference and data analysis layer, in which the raw data are processed and analyzed to derive important insights; and finally, presentation layer in the form of a user interface where individuals and in some cases, their clinicians and caregivers, can receive visualizations and alerts. Other specialized layers may also be included, such as the security layer in the system by Ali et al. (2018), or the agents modeling and reasoning layer as proposed by Akhtar et al. (2022).

7.1.2. Modular Architecture

Similar to the layered architecture is the modular architecture, in which the system is subdivided into modules, blocks, or subsystems. This is the second most common architectural pattern among the systems, with some kind of modular pattern implemented in 21 of the systems (Bampi et al., 2025; Chatterjee et al., 2021; Chiang & Liang, 2015; De Brouwer et al., 2022; El-Sappagh et al., 2019; Hooda & Rani, 2020; Hussain & Park, 2021; Ivascu et al., 2015; Ivaşcu & Negru, 2021; Khozouie et al., 2018; Lopes de Souza et al., 2023; Martella et al., 2025; Mavropoulos et al., 2021; Minutolo et al., 2016; Rhayem et al., 2021; Stavropoulos et al., 2021; G. Yu et al., 2022; Zafeiropoulos et al., 2024; Zeshan et al., 2023; Zhang et al., 2014; Zhou et al., 2022). Modular and layered architectural patterns can be used concurrently, as is done in four systems (Lopes de Souza et al., 2023; Martella et al., 2025; Mavropoulos et al., 2021; Zhang et al., 2014). For example, in the system proposed by Zhang et al. (2014), the client management module has a middleware with a layered architecture. Additionally, because layered architectures tend to be monolithic, making them less agile and difficult to scale and deploy (Richards, 2015), modularity of layered architectures is advised, in which each layer consists of a modular set of components with a single function or purpose (Meyer & Webb, 2005). This is implemented by Mavropoulos et al. (2021), whose architecture has three levels (layers), with each containing specific modules. For example, the sensors management level contains a data analysis module, while the communication understanding level contains a natural language processing module. Similarly, Lopes de Souza et al. (2023) implement a semantic module within their layered architecture.

7.1.3. Service-Oriented Architecture

Another well-known architectural pattern is the service-oriented architecture, a distributed pattern in which system components provide and consume services (Bass et al., 2021). This is used in eight of the systems (Alti et al., 2022; Fenza et al., 2012; Garcia-Moreno et al., 2023; Hristoskova et al., 2014; Kilintzis et al., 2019; Martella et al., 2025; Mezghani et al., 2015; Xu et al., 2017). In service-oriented architectures, the different aspects of the challenges can be achieved using specialized services. For example, Hristoskova et al. (2014) implement services such as a notification service to generate alerts (decision support) and a user location service to localize specific users (context awareness). While the service-oriented architectural pattern is powerful and offers a high level of abstraction, it is often overly complex and difficult to understand (Richards, 2015). A way of mitigating these issues is to implement services in a layered architecture, as is done in several other systems (Alti et al., 2022; Fenza et al., 2012; Mezghani et al., 2015; Xu et al., 2017). Additionally, agents can be used to effectively manage services, as is the case in the systems proposed by Alti et al. (2022) and Fenza et al. (2012).

7.1.4. Agent-Based Architecture

Among the systems, nine implement an agent-based architecture. Eight of these use a multi-agent architecture (Akhtar et al., 2022; Alti et al., 2022; Ammar et al., 2021; Fenza et al., 2012; Ivascu et al., 2015; Ivaşcu & Negru, 2021; Martella et al., 2025; Vadillo et al., 2013), while one implements a single-agent architecture (Mavropoulos et al., 2021). Multi-agent systems are characterized by the existence of more than one agent acting autonomously within the system. Typically, each agent manages a particular aspect of the system, which enables decentralization, efficiency, and scalability. For example, Alti et al. (2022) implement situation detection using a situation reasoning agent and a disease classifying agent, while Ivaşcu and Negru (2021) and Ivascu et al. (2015) have notification and alert agents that enhance decision support. Similarly, the system proposed by Vadillo et al. (2013) has a sensor validation agent to verify sensor observations, thereby managing uncertainty in sensor data, a location agent to manage user locations, thereby contributing to context awareness, and a medication agent to oversee the administering of medication, which contributes to decision support. Among the multi-agent systems that incorporate a service-oriented architecture, agents are instrumental in managing the complexity of the services. Both Alti et al. (2022) and Fenza et al. (2012) use agents to handle service discovery and selection. Agents can also enhance decision support by interacting directly with users of the system. This is demonstrated by Mavropoulos et al. (2021), who use a smart virtual agent capable of dialogue to communicate with clinicians and support their decision-making.

Our findings show that three of the seven key challenges are particularly poorly addressed among the systems: situation prediction, explainability, and uncertainty handling. Most of the systems included in this study do not adequately address the challenge of situation prediction, with only 12 systems being capable of predicting health risks or giving insight into how detected conditions may progress with time. In order to achieve the vision of precision health, it is important for health monitoring systems to go beyond detecting current health states and move toward the anticipation and mitigation of adverse health states. With regard to explainability, all the reviewed systems use SWTs, which are inherently interpretable, and three systems provide chatbots or digital assistants that can respond to user queries. However, only nine systems present explicit explanations for system outputs. Additionally, none of the systems implement the criteria for good explanations as outlined by Molnar (2023), nor do any systems mention tailoring the explanations presented to suit different audiences.

Uncertainty handling is similarly poorly implemented or not addressed at all in the majority of the systems. While 16 of the systems consider the impact of sensor limitations such as noise and missing values, only 11 address the inherent uncertainty present in situation analysis and decision support in the health domain. This hinders their ability to perform reliably when faced with ambiguous data or vague or limited knowledge, thus reducing their trustworthiness and dependability. Both situation prediction and uncertainty handling can be enhanced by a combination of techniques, as suggested by Behera et al. (2019), such as ML and BNs. Few of the systems take such an approach, with the majority using solely rule-based reasoning.

To a lesser extent, interoperability and decision support are also not fully addressed in the selected systems. Considering interoperability, we found that only 15 of the systems take advantage of established sensor ontologies such as SAREF. Neglecting to use such ontologies limits the standardization and expressiveness of the descriptions of sensors and, importantly, sensor data. This results in less effective querying of and reasoning on sensor data, which in turn negatively impacts situation analysis. Further, while 20 systems incorporate established medical terminologies such as SNOMED CT and ICD, all but two systems fail to consider existing health data standards. This significantly limits their ability to effectively integrate electronic health records and other standardized clinical data sources.

There is also significant room for improvement in addressing the challenge of decision support. While 37 of the included systems incorporate alerts to warn of hazardous situations, many do not offer recommendations or reminders for medication or lifestyle factors such as diet and exercise. Similarly, only 15 of the systems report using established medical guidelines, clinical workflows, or information from vetted health professional bodies, which can help to provide a sound justification for any recommendations made, thereby enhancing the trustworthiness of the systems. However, the most overlooked aspect of decision support remains the human-centered aspect. Systems should support users’ agency to cognitively engage in decision-making by presenting them with various options and their potential outcomes, and allowing them to be the final decision-makers. While 29 of the selected systems do suggest recommendations, none offer more than one potential option or present their potential outcomes.

8.1.2. Summary of the Quality Assessment

With regard to the quality assessment, we found that 18 of the systems did not report the data collection methods or sources. Additionally, only 19 of the systems reported the specific devices used for data collection. It can be assumed that such systems may not have been properly validated using realistic data, which casts doubts on the claims made regarding the system functionality and performance. To mitigate this, researchers should clearly indicate which data were used to validate their systems, including how the data were collected, who it was collected from, and the devices that were used. Concerning the development of the systems, only 16 systems used an existing methodology or else systematically outlined the development steps followed for any of the system components. However, nearly all the systems provided details of the languages, platforms, tools, and other software used in the development process.

When it comes to the evaluation of the systems and components, nearly all the systems reported on the methods, metrics, and results of the evaluation process. However, only 16 included some kind of external evaluation, whether through a systematic comparison with other similar systems or seeking evaluation from domain experts. Furthermore, as was found in the review by Haque et al. (2022), most of the selected systems are yet to be evaluated in real-world settings. While this is to be expected in an emerging area, it is imperative that more systems be evaluated in real-world settings going forward, so that practical challenges and user feedback can be identified early on and considered in future system proposals. This feedback loop is essential for undertaking further research into personal health monitoring systems that fully harness the potential of SWTs. Finally, accessibility of resources was poor among the systems, with only six systems providing access to relevant system files. Wherever possible, researchers should include the research outputs, such as ontologies, data, and code, as publicly accessible supplemental material in order to enhance reproducibility and verifiability.