In the field of Parkinson's Disease (PD), wearable sensors are commonly used to collect movement data from patients for various purposes such as analysis, monitoring, and alerting. To ensure interoperability with other personal health data, such as PHR data, it is crucial to semantically describe this data. Our work focuses on reusing existing ontologies and introducing new conceptualizations to engineer Personal Health Knowledge Graph (PHKG) for PD patient monitoring and doctor alerting. We aim to address the specific knowledge requirements in personal health for PD and support rule-based high- level event recognition. Developing a PHKG can greatly assist health specialists in efficiently assessing patients' conditions, providing timely and cost-effective care for PD patients.
This research article presents the development of a new ontology in the field of PD
patient monitoring and alerting, namely the Wear4PDmove ontology. This ontology is built
by reusing and extending existing ontologies to fulfill specific requirements, as the related
works do not fully address them, filling the semantic gap of high-level event recognition
based on low-level events i.e., tremor and bradykinesia. To engineer the Wear4Pdmove
ontology, a collaborative, agile, and iterative approach to ontology engineering (OE) has
been used i.e., HCOME [
Younesi et al. [
The proposed Wear4Pdmove ontology captures knowledge of PD patient monitoring,
integrating movement data with PHR data for real-time event recognition and alerting. The
ontologies we reuse (Figure 2), such as DAHCC [
An agile and collaborative ontology development workflow based on the HCOME
methodology is employed, incorporating the latest recommendations in ontology
engineering. It includes collaborative tools, iterative evaluation, reuse of ontologies, and
modular development in a shared workspace. The HCOME methodology comprises three
phases: specification, conceptualization, and exploitation. The specification phase captures
ontological requirements efficiently. The conceptualization phase involves design choices
and preparations. In the exploitation phase, the modular ontology supports decision-making
and analysis in the PD domain, with continuous evaluation and refinement based on
stakeholder feedback [
The Wear4PDmove ontology integrates stream data from wearables and static/historic data from PHR databases to create a PHKG. Its purpose is to enable health apps to reason about high-level events, such as 'missing dose' or 'patient fall'. The ontology has specific requirements that need to be met. Our approach encompasses a comprehensive representation of patient data, including movement patterns, daily activities, and personal health records. By integrating data from diverse sources like wearables and personal health records, we create a unified, real-time view of an individual's health. This integration enables continuous monitoring and timely alerts for healthcare professionals. To analyze and interpret this integrated data, we employ a scientific methodology and structure it uses a PHKG. This logical framework supports informed decision- making.
Based on the aim and requirements of the ontology, a number of competency questions (CQ) have been shaped in collaboration with the domain experts. The following is a selective list of such questions, which have been transformed to SPARQL queries in the evaluation phase: (CQ1) retrieve activities performed by patients for behavior analysis and disease progression monitoring. (CQ2) identified patients performing Sketching Activity and their performance level for personalized treatment plans. (CQ3) retrieve recorded observations for specific patients to analyze disease progression and adjust treatment plans. (CQ4) retrieve patient's PHR and relevant information for personalized treatment plans and dosing.
Following the specification of the aim and requirements of the ontology, and the generation of the competency questions, the subsequent phase involves the design and development of the related ontology. The Wear4PDmove ontology aims to provide an inclusive and fused model for PD patients' personal health information, supporting customized monitoring, alerting, advanced data analytics, and decision-making. It incorporates/reuses related ontologies and introduces novel classes and properties to meet specific requirements.
In Figure 3 an example set of triples describing an inferred PD patient observation is
presented, including information about the accelerometer sensor, patient movement
features, observed properties (e.g., tremor, wearable acceleration), and observation result
time. To be able to define the triplified knowledge presented in [
The Wear4PDmove ontology presented in this paper is encoded in OWL using Protégé 5.5.
The latest version is publicly available with a permanent URL at
https://w3id.org/Wear4PDmove/onto for further evaluation and criticism by related
communities of interest and practice. The ontology is evaluated with OOPS! [
The ontology files, example SPARQL queries (Qx), and SWRL rules are available at https://github.com/KotisK/Wear4PDmove. SPARQL queries Q1, Q2, Q3 and Q4 are in correspondence with CQ. In Wear4PDmove ontology, SWRL rules identify missing dose high-level events by analyzing low-level events (such as tremor or bradykinesia) in patients.
Boolean data types are used to represent low-level events such as a patient with tremor
or bradykinesia. Event values (true/false) are derived from raw sensor/wearables data
analysis performed with a custom API which is currently under development as part of an
ongoing research project [
Rule 1: If tremor is observed after dosing in a PD patient, a missing dose event is recognized, and a notification is sent to the doctor via the sendNotification function. Instances of PD patient observations are automatically classified as "PD patient Missing Dose Event Observations".
SWRL syntax: Observation(?obs), obsAfterDosing(?obs, true), observedProperty(?obs, 'Tremor for PDpatient'), hasTremor(?obs, true) -> sendNotification('Missing Dose Notification', true), 'PDpatient Missing Dose Event Observation'(?obs)
Rule 2: Similar to Rule 1, this rule detects missing dose based on the low-level event of bradykinesia in the upper limb of PD patients. If an observation for bradykinesia of the upper limb is made after dosing and bradykinesia is detected, a missing dose event is recognized. A notification is sent to the doctor using the sendNotification function.
SWRL syntax: observedProperty(?obs, 'Bradykinisia Upper Limp for PDpatient'), Observation(?obs), obsAfterDosing(?obs, true), hasBradykinisiaOfUpperLimp(?obs, true) -> sendNotification('Missing Dose Notification', true), 'PDpatient Missing Dose Event Observation'(?obs)
These rules aim to identify missed medication doses in PD patients and promptly notify doctors, but their effectiveness requires testing and validation. The evaluation process involves assessing the accuracy of observations, sensitivity and specificity of the rules, and usability of the notifications. Collaboration between domain experts and data scientists is necessary, and real- world patient data may be collected and analyzed for this purpose. This research is a first step towards engineering the Wear4PDmove ontology for monitoring and alerting PD patients, integrating personal health data sources for high-level event recognition such as a missing dose event. While it introduces necessary new classes and properties for personalized health monitoring, we are aware of potential limitations in terms of scalability and resource constraints when deploying efficient PHKGs in real-time PD patient monitoring platforms/systems. On the other hand, the scenarios and rules presented in this paper are only a first indication of what is possible to be represented in this domain. For example, we acknowledge that tremor is one of the main symptoms of PD, but even when taking medication (e.g., levodopa) consistently, the effectiveness of the medication may vary based on factors such as recent meals, sleep patterns, and minor changes in health conditions. Our future work will address these challenges, including experiments with scalable OWL reasoning engines on edge devices like Raspberry Pi or Arduino.