A Context Awareness System for Clinical Environments

Abstract

This study addresses the complex management of patient-related information in hospitals and clinical settings. This information includes treatments, medications, vital signs, patient locations, and data exchange between healthcare professionals. The lack of effective synchronization between these elements often delays timely care. This study proposes an architecture based on a semantic representation model that articulates the various components of a hospital environment. This model supports decision-making in healthcare by facilitating inferences from the environment. The semantic model serves as a basis for executing predefined rules that trigger actions through a reasoner, resulting in notifications, such as administering medications or responding to abnormal vital signs. The model integrates supervised learning to improve the accuracy of alerts. The experiment focused on monitoring vital sign parameters, such as Spo2, body temperature, and heart rate. The combination of semantic representation modeling and machine learning algorithms demonstrates a robust approach for improving the efficiency and accuracy of healthcare alerts in clinical settings.

1. Introduction

Providing care for a patient requires the use of various biomedical devices and equipment, including X-ray machines, blood pressure monitors, and electrocardiographs. Additionally, it involves managing patient information, such as records, medical history, and profiles, as well as coordinating with healthcare personnel such as doctors, nurses, and social workers. Each component is intricately linked to contextual variables that define the overall functional requirements of healthcare services. For example, biomedical devices require specific hardware and sensor variables tailored to their medical functions. The state variables related to the operation, availability, and location of these devices are equally crucial. Vital data encompassing profiles and medical histories are essential for various aspects of care such as treatments, monitoring, medication, and surgery. Healthcare providers are intricately connected to assignments, shift exchanges, and patient care schedules, which are determined by factors such as the specialty and location of care. In decision-making, doctors and nurses must be informed about prior procedures, treatments, medications, etc. The contextual variables in this scenario were linked to the patient’s temporal aspects and clinical history. Communication among healthcare professionals has emerged as a pivotal contextual variable, demanding great coordination among medical staff, biomedical equipment, and data transmission technologies. Staff members often rely on devices for data transmission, introducing another layer of contextual variables. Effective communication mechanisms must ascertain the location of the devices, identify their users, determine when they are needed, and understand the reasons for their use.

Efficient information management within hospitals demands substantial collaboration, mobility, and seamless data integration, presenting a challenge characterized by unique contextual requirements. Contextual awareness technology plays a pivotal role in addressing tasks related to medical care [1], encompassing communication activities between doctors and nurses, as well as patient tracking and monitoring [2,3]. The technology’s capacity for contextual awareness enables the detection of a patient’s condition and the environment in which they are situated, which is achieved through specialized sensors capturing pertinent information. This capability allows medical staff to continuously monitor changes in patients’ conditions and respond promptly and effectively to diverse health situations. Incorporating contextual awareness computing is essential for healthcare systems, not only for implementing new tools but also for refining the interaction between users, patients, and the environment, providing system autonomy and reasoning capacity.

Hospitals and clinical settings exhibit considerable intricacy in handling patient-related information. This information encompasses details regarding treatments, medications, vital signs, patient locations, and the coordination and exchange of data among healthcare professionals working in these environments. The absence of synchronization among various elements constituting the clinical context, including sensors monitoring vital signs and medical records, frequently delays the provision of timely care for convalescent individuals.

Primarily, the objective is increasingly focused on enhancing the patient’s experience in clinical environments, irrespective of their specific ailments or diseases. Systems designed to monitor patients aim to inform medical personnel effectively and facilitate decision-making processes that contribute to improved care. Although contextual-awareness systems and ubiquitous computing have been successfully implemented in hospital settings [1,4,5,6,7,8,9], there remains substantial ongoing research in this area. A particular research focus is tied to the intricacies arising from the heterogeneity of information within clinical environments, resulting in the challenging task of real-time synchronization and monitoring of patients. The literature reflects numerous proposals dedicated to managing and monitoring a patient’s condition [10,11,12,13]. However, many of these studies predominantly address aspects such as monitoring vital signs or personal care, neglecting the crucial consideration of interactions among doctors and nurses and the exchange of information between them for enhanced decision-making.

Smart healthcare has brought e-healthcare to a higher level by providing the ubiquitous and intelligent delivery of healthcare and treatment services. This is achieved through context awareness, which involves extracting current contextual information from users such as patients, doctors, and nurses. Intelligent healthcare systems can provide autonomous and intelligent services by understanding the current context and situation of the users. Despite the importance of this topic, no studies have investigated and reviewed the various context-aware healthcare systems proposed in different aspects of healthcare and treatment. Therefore, this study examines context-aware healthcare systems from four central viewpoints: setting, type of service, type of context, and source of context. The aim is to discuss and technically classify these systems, identify their strengths and weaknesses, and provide guidance for future research in this area.

The proposed architecture is rooted in a semantic representation model of hospital context components, enabling inferences guided by the environment and facilitating decision-making in medical care. The semantic model serves as the foundation for executing a predefined set of rules established by the hospital environment. These rules trigger actions through a reasoner, generating notifications such as administering medication to a patient or responding to alerts regarding abnormal vital sign parameters. Furthermore, it is integrated with supervised learning models to enhance its capacity to accurately generate alerts.

This study introduces the development of a semantic representation model to manage information within a clinical environment. The model encompasses various elements including patient information, treatment details, medications, and vital signs. Additionally, it integrates information about healthcare professionals such as doctors and nurses, as well as details about locations and sensors monitoring vital sign locations. The proposed semantic representation model serves as the foundation for an architecture that extracts information from the model and uses it to generate inferences. These inferences are instrumental in facilitating decision-making in patient care.

Related Works

In Ref. [14], the authors propose an object-oriented service architecture to create an intelligent hospital by integrating pervasive computing technologies. They use context-sensitive techniques to perform automated selection and classification of services according to patient information, in order to facilitate the management and personalization of medical care in the hospital environment.

In Ref. [15], the authors propose a context-aware architecture and IoT technologies for remote monitoring of patients with chronic diseases. The architecture consists of four modules: IoT module, data preprocessing module, context-aware module, and decision module. The IoT module collects biometric data such as temperature, pulse, blood pressure and oxygen saturation from IoT sensors. The preprocessing module optimizes the data received from the previous module, eliminating redundant data and providing structure to the relevant information. The context-sensitive module uses contextual information to tailor treatment and medical care to the specific needs of each patient. The decision-making module extracts relevant features from the processed data and uses classification techniques such as Dual Interactive W-GAN to categorize patient conditions.

In Ref. [16], the authors develop a classification model using an artificial neural network with the aim of analyzing healthcare data stored in the cloud and determining the severity level of diseases. The proposed model has three main subsystems: user subsystem, cloud subsystem, and alert subsystem. The user subsystem performs data collection from biomedical IoT sensors. The cloud subsystem is responsible for central data storage and processing. The use of cloud computing resources facilitates advanced medical monitoring and diagnosis using artificial neural networks. The alert subsystem detects critical health anomalies and generates early warnings for physicians and healthcare personnel. The model presents efficient performance in sensitivity, specificity, accuracy and F-value, with an average sensitivity value of 96.094%, specificity of 93.492%, accuracy of 94.066% and an F-value of 94.066%.

In Ref. [17], the authors propose a health monitoring model for elderly patients using IoT sensors and context awareness. The proposed architecture is based on four modules: IoT module, data preprocessing module, context-aware module and decision-making module. The IoT module collects patient physiological data through sensors and mobile devices. The preprocessing module performs the processes of collecting, storing, and redundancy of input data to the system. The context-aware module makes use of a fog layer and a cloud layer to analyze contextual data and obtain relevant information. The decision-making module uses neural networks and optimization algorithms to classify and extract features from the data, as well as send health alerts to medical staff. Evaluation results with respect to other approaches such as BPNNN, K-nearest neighbor and artificial neural network, in terms of high accuracy, scalability, network latency and lower response time, show that the proposed model provides better performance.

In Ref. [18], the authors state that the complexity in devices, heterogeneity in data and lack of interoperability in platforms impose difficulties to the accuracy of treatments in patient care and monitoring. They propose a framework for intelligent health care using an ontology for IoT. The architecture is composed of three modules: (1) data collection and preprocessing, (2) reasoning and inference, and (3) knowledge management. The evaluation of this model achieves an accuracy of 89.81% in medical decision-making.

In Ref. [19], the authors propose a medical data mining system that comes from physiological metrics such as the following: ECG, PPG, temperature and accelerometer data taken from biosensors that are sent to the cognitive engine for final data processing. The proposed model uses the following components: (1) a feature extraction and classification block to support physician decision-making; (2) a fusion analysis model Kernel Multiview Canonical Correlation Analysis (KMCCA) which evaluates associations between the data; (3) a data classifier based on machine learning techniques. The evaluation of the proposed model reports an accuracy of 96.33%.

In Ref. [20], the authors develop a system for monitoring patients with chronic diseases based on the Do-Care ontology. It uses sensors and IoT devices for patient data collection as well as the use of SWRL rules to improve medical recommendations. The architecture of the Do-Care system consists of five subsystems: (1) Context Sensing, (2) Network Communication, (3) Data Storage, (4) Application, (5) Ontology and Reasoning. The efficiency of the Do-Care system is demonstrated through an experimental implementation.

In Ref. [21], the authors implement an IoT-based context-sensitive recommendation system for data collection. This system provides personalized recommendations to patients with diabetes through four phases: (1) data collection, (2) context modeling, (3) reasoning through an artificial neural network, and (4) context dissemination. The results indicate an overall accuracy of 89.5%.

Table 1. Comparative table.

Ref.	Proposed Architecture	Main Modules	Technologies and Techniques Used	Collected Data	Evaluation
[14]	Object-oriented service architecture	Not specified	Pervasive computing, context-sensitive techniques	Patient information	Not specified
[15]	Context-aware architecture with IoT	IoT module, data preprocessing module, context-aware module, decision module	IoT sensors, Dual Interactive W-GAN, classification techniques	Temperature, pulse, blood pressure, oxygen saturation	Accuracy: 94.066%
[16]	Classification model using artificial neural networks	User subsystem, cloud subsystem, alert subsystem	Biomedical IoT sensors, cloud computing, artificial neural networks	Biomedical data	Accuracy: 94.066%
[17]	Health monitoring model for elderly patients	IoT module, data preprocessing module, context-aware module, decision module	IoT sensors, mobile devices, neural networks, optimization algorithms	Physiological data of patients	Not specified
[18]	Framework for intelligent healthcare using ontology for IoT	Data collection and preprocessing, reasoning and inference, knowledge management	Ontology for IoT	Not specified	Accuracy: 89.81%
[19]	Medical data mining system	Feature extraction and classification block, KMCCA fusion analysis model, data classifier	KMCCA, machine learning techniques	ECG, PPG, temperature, accelerometer	Accuracy: 96.33%
[20]	System for monitoring chronic disease patients using Do-Care ontology	Context sensing, network communication, data storage, application, ontology and reasoning	IoT sensors, SWRL rules	Not specified	Not specified
[21]	IoT-based context-sensitive recommendation system	Data collection, context modeling, reasoning, context dissemination	IoT sensors, artificial neural networks	Data from patients with diabetes	Overall accuracy: 89.5%
Ours	Context-aware architecture with IoT	Mapping and retrieval, ontology, context management, physical environment detection	IoT sensors, SWRL rules, machine learning	ECG, Temperature, pulse, blood pressure, oxygen saturation	Overall accuracy: 98.10%

shows a comparison of the different studies that have been conducted for intelligent clinical environments. The proposals contemplate the inclusion of IoT systems, contextual awareness systems, ontology technologies, and automatic learning, among others. The aim of this study was to improve patient care and treatment. The developed architecture proposes a wide variety of alternatives for patient care and personalization. Most of the systems analyzed had precision metrics for patient care. However, despite the accuracy observed in different studies, there is not much emphasis on the quality of the alerts. In this study, in addition to proposing an IoT system for patient care in clinical environments, we developed a system capable of generating alerts with high reliability for patient care, using a semantic representation model and supervised learning techniques to filter and generate reliable alerts in such a way that the medical staff can attend to the patient when alerts are generated, owing to the reliability of the system. Finally, in this section, it can be seen that there are still challenges to overcome that are related to the complexity of the systems and interoperability for data exchange and efficiency.

2. Approach

2.1. Semantic Representation Model (Ontology)

The model under consideration incorporates a knowledge base that mirrors the information stored within two relational databases. This knowledge base serves as the repository of information, enabling the context management layer to execute various inference rules in response to situations arising within a context-aware clinical environment. Figure 1 delineates the constituents of the ontological model, while

Table 2. Description of the relationships of concepts in the ontology.

Relationship	Description	Domain/Range Restrictions
hasActivity	Allows recording of activities of patients, doctors and nurses.	Domain: Person Range: Location, Device
isDeviceLocation	All devices are located in one location.	Domain: Device Range: Location
hasDevice	All people have a device allowing them to interact with the context.	Domain: Person Range: Device
hasTreatments	Patients receive one or more treatments according to the diagnosed diseases.	Domain: Treatments Range: Patient
hasDiseases	A patient may have been diagnosed with one or more diseases.	Domain: Diseases Range: Diagnostic
hasDiagnostic	A patient has one or more diagnoses.	Domain: Patient Range: Diagnostic
hasGeneratedg	A doctor generates one or more diagnoses.	Domain: Doctor Range: Diagnostic
hasAlert	The system sends alert notifications to doctors about the patient’s current situation.	Domain: Notify Range: Doctor, Nurse
hasPlanning	Every patient has a series of procedures, treatments, and medications according to the diagnosed disease that must be monitored and executed according to the patient’s evolution times.	Domain: Planner Range: Patient, Doctor, Diseases, Treatments
hasTracking	A device constantly monitors the evolution of a patient.	Domain: Device Range: Patient
hasDateBeginning	Every treatment has a set time to execute it.	Domain: Treatments Range: Time
hasDateEnd	Every treatment has a set completion time.	Domain: Treatments Range: Time
hasLocation	Every patient has a location.	Domain: Patient Range: Location

describes selected relationships between the domains.

The main domains of the ontological model are described in detail below:

Person: Describes the roles of individuals within the system, such as patients, doctors, nurses, assistants, and administrators.

Event: Generates notifications and alerts depending on the data acquired by the sensors that monitor the patient and notifies the medical staff about monitoring a patient or their treatment.

Measure: Characterizes the measurements with their respective parameters according to the monitoring sensors associated with the patients.

Profile: Describes all personnel associated with a clinical environment. In the case of patients, all personal information and clinical history are included, while for health personnel, information associated with their specialties and roles is considered.

Location: Identifies the location of the hospital environment. This information can be obtained through the devices. It also refers to the location of patients (e.g., inside a space, a recovery room, an emergency room, or other places assigned for care and follow-up). Likewise, it refers to the location information of medical staff, nurses, and assistants and their proximity to patients.

Diagnostic: Refers to patients’ diagnoses and prognoses. Includes doctors’ assessment concerning patients’ laboratory tests.

Treatments: Considers the possible treatments that can be applied to a certain disease depending on the patient’s medical pathologies.

Device: Describes the hardware and software features required to interact with the clinical environment, including patient monitoring sensors and smartphones used by medical personnel, among others.

Time: Refers to the notion of real time in context. It represents the interaction time between patients and medical staff with the system. This dimension is important because it determines the execution timeframe of an activity at the current moment or at its scheduled time, such as administering a patient’s medication or conducting laboratory tests.

Diseases: Describes information related to patients’ illnesses, treatments, and medications.

Table 2 describes some of the main relationships between the concepts of the semantic representation model for the smart clinical environment.

2.2. Ontology Comparison

After searching the ontologies by domains, the NeOn methodology [22] criteria were applied to determine which ones to use and which ones to discard. For this purpose, the following actions were performed:

-

Checking the scope and purposes of the ontology.

-

Analyze the terms in the candidate ontology if they are similar to the ontology to be developed.

-

Calculate the precision and scope of the terms in the candidate ontology to be reused with respect to the terms included in the competency questions defined for the new ontology.

-

Analyze whether the candidate ontology answers the competency questions of the ontology requirements specification document.

After reviewing the ontologies, the one that best fits our research problem is COPD Patients [23]; however, it lacks some domain elements to be able to define the inference rules, as shown in

Table 3. Comparison of different ontologies for healthcare environments.

Criteria	Do-Care [20]	COPD Patients [23]	Cobra [24]	ITEMAS [25]	Disease Ontology [26]	Ours
Similarity in scope	No	Partial	Partial	Yes	No	Yes
Similar objective	No	Partial	Partial	Yes	No	Yes
Coverage of non-functional requirements	Partial	Partial	No	Partial	No	Yes
Coverage of functional requirements	Partial	Partial	No	Partial	Partial	Yes

.

As shown in

Table 4. Comparative Evaluation of Ontologies.

Criteria	[20]	[23]	[24]	[25]	[26]	Ours
Taxonomy	√	√	√	-	-	√
Language	√	√	-	√	√	√
Application	-	√	√	√	-	√
Vocabulary	√	√	-	√	√	√
Requirements Architecture	-	-	-	-	-	√
Social Acceptance	√	-	-	-	-	-
Automatic Reasoning	-	-	√	-	√	√
Software	-	-	-	-	-	√

on the evaluation of the different ontologies, our ontology is the only one that satisfies all the criteria, because it is more understandable and versatile, and responds to the needs of an intelligent clinical environment. Although other ontologies have positive aspects, they do not meet the requirements of our research. Therefore, we decided to develop an ontology from scratch that meets all the criteria listed in the table above.

2.3. Proposed Architecture

This architectural framework enables adaptive responses to diverse situations or behaviors encountered within an intelligent clinical environment. The nature of these situations varies based on contextual information, such as an individual’s location and role (e.g., patient, doctor, auxiliary health personnel), planning activities related to patient care, and proximity to objects or physical spaces intrinsic to specific medical activities. The proposed architecture facilitates contextual information management to align with user needs. To achieve this objective, mechanisms for context acquisition, modeling, storage, processing, notification, and information presentation must be defined. These mechanisms are intricately integrated into each layer.

The architecture comprises the following layers: persistence, data mapping and recovery, knowledge base, context management, and physical environment. The distribution of these layers is illustrated in Figure 2.

Each layer is described in detail below.

2.3.1. Storage

Persistence comprises two relational databases: context and treatments. The context database stores information related to patient profiles, medical records, medication, treatment monitoring, and the location of physical spaces such as intensive care units, intermediate care units, recovery or emergency rooms. It also stores all information related to medical personnel and their specialties, nurses, and nursing assistants. The treatment and disease object database stores data on treatments for patients with different diseases.

2.3.2. Data Mapping and Recovery

This layer is responsible for mapping and retrieving the information from relational databases, subsequently transferring it to the ontological model, as depicted in Figure 3. The mapping process entails the identification of tables with their corresponding fields, relationships, and constraints. Several tools offer interfaces to facilitate the transformation of relational databases into semantic models [27,28,29]. However, adapting from relational to semantic models introduces challenges in discovering constraints, including treating primary and foreign keys, alongside managing inheritance. Notably, most existing works do not adequately represent data transformation into the Web Ontology Language (OWL) format. This proposed solution addresses these issues by facilitating the identification of parent and daughter classes (inheritance), defining class restrictions, and generating both direct and inverse relationships. Furthermore, it enables the creation of mappings in the OWL language, thereby supporting the reasoning of inference rules within the Semantic Web Rule Language (SWRL) framework.

Ontological Mapping

This layer extracts information from the relational model schema and transforms it into an ontological model structure. The relational database structure is transferred to an OWL format with RDF triples (subject, predicate, and object) describing the different classes’ instances. A class in the OWL schema represents a table in a Relational Database (RDB). The field of an RDB table is the equivalent of a property with its respective OWL data type. The foreign key RDB corresponds to a relationship in an OWL class. To explain how the mapping and recovery process is generated, four phases have been defined (Figure 3).

This process allows the ontology to be stored in a persistence unit, as shown in Algorithm 1 the operation of this layer.

Algorithm 1 Relational Data Mapping and Extraction Algorithm to OWL

Input data: relational database schema

Output data: ontology persistence unit

Begin

If (no ontology exists) then

First phase: move all tables and relationships from the relational model to the Data Representation Model for Ontologies (DRMO)

Second phase: map from the DRMO to the OWL schema, representing the tables in classes, the attributes in properties and relationships

Third phase: extract the data from the relational database and instantiate the tuples of all the tables to the OWL schema

Fourth phase: store the ontology in a persistence unit

Else

Third phase

Fourth phase

EndIf

End

2.3.3. Context Management

The function of this layer is the management of contextual information related to the environment, which allows real-time information about the patient to be offered according to the data obtained from the hospital environment. The purpose is to monitor the context variables and respond to their behavior according to the information mapped in the ontology. Context management comprises six modules: context detection, broker, profile management, treatment planner, diagnosis and disease management, notification, and presentation. Figure 4 shows the module distribution.

The following sections describe each of the modules of this layer.

Patient profile management:

This module is tasked with delineating the clinical history of the patient, encompassing information about pre-existing conditions (such as diabetes, cancer, hypertension, coronary arteries, among others), medical allergies, including those related to food, prior surgeries, and past medical interventions. Establishing the patient’s profile is grounded in the information initially extracted upon admission to the hospital. This information is gathered through a questionnaire administered to the patient in a conscious state or to a close family member. These data serve as the foundation for the system to make preliminary adjustments, providing suggestions or recommendations concerning potential treatments for illnesses and contraindications for medications. Figure 4 illustrates the state diagram depicting the system’s profile management behavior.

To establish the rules that will generate the patient’s profile, the patient’s clinical history and data associated with the diseases diagnosed according to laboratory tests performed at the hospital were initially taken as a reference. Based on the previous parameters, possible treatments and medications can be suggested to the patients. The rules used to explain the profile behavior are described below.

Rule 1

Patient(?patient), Diseases(?disease),

Doctor(?doctor),

Diagnostic(?diagnostic), hasDiseases(?diagnostic,

?disease), hasDiagnostic(?patient,?diagnostic),

hasGeneratedg(?doctor,?diagnostic), hasProfile(?pati

ent, ?profile), has_MedicalTests(?test, ?result),

swrlb:stringEqualIgnoreCase(?result, “YES”)->

NotifyTreatment(?patient)

Activity planner:

The activity planner is responsible for monitoring patients’ treatment and vital signs within a clinical environment, enabling healthcare professionals, such as doctors and nurses, to fulfill the healthcare needs of individuals. Patient treatments are systematically allocated specific time intervals for execution. The scheduler inputs include details such as start and end dates and start and end times. Furthermore, the traceability of all treatments is intricately linked to a particular patient with a designated location for their administration. For the planner to efficiently respond to treatment monitoring based on factors such as time, location, or NFC/QRCode tag reading, the broker must initiate the request utilizing the event trigger.

Rule 2

Planner(?plan), Patient(?patient), Activity(?act),

Treatments(?treatment), Location(?loc),

hasPlanning(?plan, ?act), hasTreatments(?patient, ?

treatment), hasDateBeginning(?treatment, ?datebegin),

hasDateEnd(?treatment, ?dateend),

swrlb:lessThanOrEqual(?datebegin, ?dateend),

hasLocation(?patient, ?loc) -> NotifyActivity(?patient)

Explanation of Rule 2 corresponding to event planner: The planner has an identifier number, the patient has an identifier, the activity has its identifier, the treatment has its identifier, and the location also has an identifier. The planner has a schedule associated with the planner identifier and activity. The patient has a treatment that is associated with the patient identifier and treatment identifier. It has a treatment start that is associated with the treatment identifier, start date, and time. Finally, it has a treatment end time associated with the treatment identifier and the end time and date. The patient has a location that is related to the location and patient identifier. The rule notifies the patient of the location, including the date, start time, and end time of the patient’s treatment. This notification is sent to the medical staff (doctors and nurses) so that they can follow the patient’s procedure.

2.3.4. Broker

This is an intermediary between the context detection, profile management, scheduler, notification, and presentation modules. This module is integrated with context monitor classes, inference engines, machine learning models, and the JENA API. These classes are shown in Figure 5.

The context monitor class comprises the context interpreter and event trigger methods. The context interpreter is responsible for receiving the data emitted by the retrieval and extraction module. The data come associated with a tag, which allows the interpreter to assign an identifier for each context source stored in the ontology’s persistence unit. Figure 6 gathers data sources obtained from the context in JSON format.

As seen in the previous code, an idPatient with its respective location is assigned to the patient-context data source. Similarly, the device identifier is extracted using the session token. After identifying each context source, the event trigger invokes the profile and scheduler management modules. These two modules execute queries that provide SWRL rules, which are sent as parameters to the inference engine class. The inference engine executes the rules and generates context instances for each invoked module.

2.3.5. Context Detection

The system obtains information from the clinical environment. Its function is to permanently detect requests made by mobile clients and identify each of the contextual factors. These factors include the time intervals at which a patient is monitored, given medication, location, and vital sign sensor readings. Authentication, registration, discovery, and extraction submodules are within context detection. Figure 7 shows the context detection distribution. The modules of this layer are described as follows:

Authentication module: The authentication process of medical personnel and devices associated with the patient is performed. If the authentication service validates the existence of the medical staff, it proceeds to send the data to the mediator to extract the information from the patient’s profile and associated treatments. This is because patients may have different types of devices and sensors to connect to the system. Each device has a token that allows a user to be associated with the device; therefore, the context management layer always recognizes its characteristics.

Context discovery and extraction module: Gathers context data from different sources, including sensors provided by the mobile device. Once the data are obtained, it proceeds to validate and classify them depending on the origin, according to the ontological model stored in the persistence unit of the knowledge base. For classification, labels are used as a reference that allows the identification of data from each entity that is a part of the context. A tag allows the locations of patients and medical staff in the clinical environment to be known. After extracting the data, they are sent to the broker. The broker interconnects with the remaining modules. Each module has inference rules that define the patient profile, activate the planner, and verify the monitoring and follow-up of the treatments. The medical staff are subsequently notified using the notification and presentation module.

Registration module: Registers different context data sources in the medical and patient database, updating the interactions from the clinical environment and server. These updates allow the traceability of each patient with their vital signs, monitoring data, and treatments according to their diseases.

2.3.6. Notification and Presentation

This delivers information related to the interaction of the contextual awareness system with the mobile device of the medical staff. One of the main functions of this module is to notify doctors and nurses by sending messages about new changes in the environment (patient status). These messages may be related to location changes, abnormal measurements, and start or end times of treatment.

2.3.7. Physical Environment

This corresponds to the physical infrastructure that allows information to be extracted from the context through devices, including Near Field Communication (NFC) sensors, Bluetooth Low Energy (BLE), Global Positioning System (GPS), cameras, and vital sign sensors, among others. Technological artifacts useful for interaction between people and the environment, such as NFC and QRCode tags, are also a part of it. Communication between the physical environment and the context server occurs through mobile devices that operate with the MQTT protocol. Bluetooth standards, already integrated, and NFC readers available on smartphones were used to communicate between devices and physical objects.

As shown in Figure 8, through the sequence diagram, the system architecture is designed to detect the physical environment using different types of sensors (NFC, QRCODE, GPS, biometrics, etc.). These send the information to the context detection module, which subsequently extracts the data so that the broker is subsequently responsible for managing the patient’s profile information. After managing the profile, rules are generated based on the origin of the data obtained by context detection. The profile management layer immediately sends instances to the treatment management module, which in turn transmits it to the broker to generate the respective event to the planner. The planner module searches for information related to the activities to be performed with the patient. The planner sends rules to the broker, which in turn processes them. The planner then sends an instance to the treatment management module, which again generates the rules for the broker to process and return to the treatment management module. According to the rules and respective validations, the treatment management module sends alerts to the notification and presentation module in the event that it is the monitoring of vital signs that have exceeded the thresholds or, failing that, it is the notification for the traceability of the parent treatment. This patient traceability notification may be an indication to provide the patient with medications and take them for medical examinations, among others.

3. Analysis and Results

3.1. Metrics for Model Evaluation

To evaluate the quality of the model we use the precision, recall, F1 score and specificity metrics [30] as described below:

The confusion matrix shows the structure of two classes as seen in Figure 9.

The terms described in the confusion matrix are:

True positives (TP): Indicates that the model positively predicts the class.

True Negative (TN): Indicates which model negatively predicts the class.

False Positive (FP): Indicates that the model incorrectly predicts the positive class, which is called type 1 error.

False Negative (FP): Indicates that the model incorrectly predicts the negative class, which is called type 2 error.

The confusion matrix metrics are described below:

-

Accuracy: This metric indicates whether the model made predictions correctly.

$$Accuracy={\displaystyle \frac{TP+TN}{TP+TN+FP+FN}}$$

-

Precision: Indicates the dispersion of the set of values obtained from repeated measurements of a magnitude. The smaller the dispersion, the greater the precision.

$$Precision={\displaystyle \frac{TP}{TF+FP}}$$

-

Sensitivity: indicates the ability of the estimator to discriminate positive cases from negative ones. Sensitivity is represented as the fraction of true positives.

$$Recall={\displaystyle \frac{TP}{TP+FN}}$$

-

Specificity: this is known as the true negative rate. These are the negative cases that the model has correctly classified, indicating how well the model can detect a class.

$$Specificity={\displaystyle \frac{TN}{TN+FP}}$$

-

F1 Score: This metric is very useful when the distribution of classes is uneven. An example may be when the number of patients with one condition is 15% and the other is 85%, which in the healthcare field is quite common, as in our case.

$$\mathrm{F}1 \mathrm{S}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}={\displaystyle \frac{2\ast Precision\ast Recall}{2\ast TP+FP+FN}}$$

3.2. Definition of Dataset

Next, we describe the datasets used to make predictions to refine alerts. Three alert types were considered, i.e., body temperature, heart rate, and blood oxygen level in hospitalized patients. Each of the datasets is discussed.

3.2.1. Body Temperature

To measure body temperature, the variables age, gender, body temperature, and the objective dependent variable were considered. 1346 instances were taken as reference, see

Table 5. Body temperature.

Age	Gender	Body_Temp	Target
10	1	35.72	1
15	0	38	0
…	…	…	…

.

The value of the categorical variable gender is changed to male = 0, and female = 1. In the case of the target variable, the value of yes is changed to 1 and the value of no is changed to 0.

In other words, if the target variable is equal to 1, it means that the body temperature is elevated.

3.2.2. Heart Rate

To measure heart rate, the heart attack dataset available in [31] was adopted, which considers the dependent variables of age, gender (0 female, 1 male), impulse (heart rate), high blood pressure (systolic), low blood pressure (diastolic), glucose, KCM (creatine kinase), troponin, and the independent variable target (0 to positive, 1 to negative). The number of instances for this data set was 1319, see

Table 6. Heart rate.

Age	Gender	Impulse	Pressurehigh	Pressurelow	Glucose	Kcm	Troponin	Target
64	1	66	160	83	160	1.8	0.012	0
21	0	94	98	46	296	6.75	1.06	1
…	…	…	…	…	…	…	…	…

.

3.2.3. Blood Oxygen Level

In measuring the level of oxygen saturation in the blood, the independent variables were age, gender (0 female, 1 male), Spo2 (oxygen saturation level in the blood) and the objective dependent variable target (0 abnormal, 1 normal). The number of instances for this dataset is 1208, see

Table 7. Blood oxygen level.

Age	Gender	Spo2	Target
64	0	80	0
21	1	95	1
…	…	…	…

.

In preprocessing, 70% was used for training and 30% for testing on the three datasets. Likewise, k-fold cross-validation was applied for better classification accuracy, sensitivity, and specificity. These data are important when generating smart alerts.

The goal was to permanently monitor the patient against an abrupt change in vital sign variables. For this purpose, vital signs sensors sending data to the developed system were provided. Its architecture implements techniques combining knowledge-based inference rules and machine-learning models based on medical data. Combining these techniques generates confidence in the alerts the system issues to medical personnel.

To train the dataset collected from the sensors, these supervised learning models were used:

• K-Neighbors Classifier (KNN)
• Naive Bayes Gaussian (Gaussian NB)
• Decision Tree Classifier
• Logistic Regression
• Support Vector Machine (SVM)
• Random Forest Classifier
• Linear Discriminant Analysis (LDA)

3.3. Experimentation

For the experimental phase, a patient was randomly selected in intermediate care from a clinical center in the city of Monteria to observe the efficiency of the system. This study aimed to validate the alerts generated by heart rate monitoring. Normally, in health centers, one of the most critical alerts that medical personnel must pay attention to is the heart rate. Normally, systems tend to generate false alarms at some point. Faced with this, our system has a double validation, which is basically the establishment of inference rules, and it is then filtered by a machine learning model to generate confidence with the alert.

Our system addresses the notification of alerts for monitoring the level of oxygen saturation in the blood, temperature, and medical treatments in the clinical environment. We will use a rule and different machine learning models to generate a reliable alert in heart rate measurement. This rule is described as follows:

Rule 3 generates a medical alert based on the heart rate; this patient was diagnosed with an underlying disease (hypertension). The treating doctor made a diagnosis based on the clinical examinations performed on the patient. The heart rate was monitored, and if it exceeded the threshold of 100 or below 50, a notification was generated to the medical staff so that they could care for the patient.

Rule 3

Patient(?patient), Diseases(?disease), Doctor(?doctor),

Diagnostic(?diagnostic), hasDiseases(?diagnostic,

?disease), hasDiagnostic(?patient,?diagnostic),

hasGeneratedg(?doctor,?diagnostic), hasProfile(?patient,

?profile), has_heart_rate(?profile, ? heart_rate),

swrlb:lessThan(?heart_rate, 50), swrlb:greaterThan

(?heart_rate, 100)-> Notify (?doctor)

Once the rule is triggered according to the parameters of the heart rate readings with the minimums and maximums (50 and 100), it is validated using the random forest supervised learning model. To determine whether this is the best model to fit the alerts, it was compared to six additional machine learning models, as described below in

Table 8. Supervised learning models for heart rate alerts.

Model	Score 1	Score 2	Score 3	Score 4	Score 5	Mean	Std
SVM	0.64150943	0.63507109	0.67772512	0.67772512	0.65402844	0.65721184	0.01992801
LogisticRegression	0.78301887	0.77251185	0.85781991	0.77251185	0.81042654	0.7992578	0.0362238
RandomForest	0.97169811	0.97630332	0.99052133	0.99526066	0.99052133	0.98486095	0.01023141
GaussianNB	0.75	0.63507109	0.67772512	0.66350711	0.58767773	0.66279621	0.05966437
LinearDiscriminant	0.68396226	0.69668246	0.72985782	0.68246445	0.69668246	0.69792989	0.01908389
KNeighbors	0.58490566	0.5971564	0.56398104	0.67772512	0.63981043	0.61271573	0.04569165
DecisionTree	0.97641509	0.98578199	0.99052133	0.98104265	0.97156398	0.98106501	0.00747602

and Figure 10.

After evaluating the different supervised learning models, the random forest model was found to be the best fit to generate reliable alerts. Using the aforementioned metrics, this model has an accuracy of 98.98%, a classification error of 0.0038, a Recall or Sensitivity of 100%, allowing the discrimination of the negative and positive phases of the trained instances, and a specificity of 0.9940. Finally, it achieved an F1 score of 99%. This indicates that after the inference rule is generated, the random forest model is capable of generating a reliable alert regarding the patient’s heart rate, thereby allowing the medical staff to care for the patient in a confident and timely manner. The confusion matrix shown in Figure 11 corroborates what has been previously described.

In the experiment, HealthyPi v4 was used with oxygen saturation, heart rate, and temperature sensors. In Figure 12 and Figure 13, monitoring can be seen. Figure 14 shows the generated alerts.

4. Discussion

This study presents a significant advance in the management of patient-related information in clinical settings. By integrating a semantic representation model with supervised learning algorithms, the proposed architecture addresses the critical need for the effective synchronization of patient data, vital signs, and medical records. This dual approach enhances decision-making capabilities and ensures timely care, distinguishing this study from previous studies that have focused on semantic modeling or machine learning in isolation. The ability of the system to infer and trigger actions based on predefined rules represents a robust mechanism for improving patient care by efficiently processing and responding to real-time data from various biomedical devices.

This study builds on existing work by incorporating elements from ontologies, such as Disease Ontology, Cobra, Do-Care and COPD Patients, and refining them to fit the specific needs of hospital contexts. This approach ensures comprehensive coverage of functional and nonfunctional requirements and establishes a new standard for healthcare data management systems. Additionally, the system’s high accuracy in alert generation, achieved through the integration of machine learning models, demonstrates a practical and scalable solution for improving clinical workflows.

Limitations

Despite the positive results, our study has certain limitations that warrant further exploration. First, the system’s reliance on predefined rules may limit its adaptability to unforeseen medical scenarios or the changing nature of patient-care protocols. Second, the experiment primarily focused on three vital sign parameters (Spo2, body temperature, and heart rate), which may not capture the full spectrum of patient conditions in a clinical setting. Expanding the scope to include additional parameters and complex conditions could provide a more holistic assessment of the system effectiveness. Third, there are potential challenges in integrating the system with existing hospital information systems (HIS) and electronic health records (EHR). Ensuring interoperability and seamless data sharing among different systems remains a critical hurdle. Additionally, the study’s validation scenarios were conducted in controlled environments while demonstrating high accuracy. Real-world implementation may introduce additional variables and complexities that could impact the system performance. Future studies should include extensive field testing and user feedback to refine the functionality and user interface of the system.

5. Conclusions and Future Work

This study mainly focused on the semantic representation of medical contexts through the implementation of an ontology. The developed ontology delimits essential domains in an intelligent clinical environment, including interactions with the patient, medical staff, vital signs, and location sensors, among other relevant aspects. The relationships between these domains are explained in detail within the ontological model, which facilitates comprehensive interactions within the clinical environment and its constituent elements.

Additionally, the study implemented an architecture designed to interact with the intelligent clinical environment and efficiently access the knowledge base containing contextual information. Machine learning models have been integrated into this architecture to produce highly reliable predictions, guaranteeing the high quality of medical alerts generated by the system.

The system was designed and implemented to manage information from the clinical environment related to patients, treatments, medications, and vital signs. It integrates information about medical personnel, locations, and vital sign monitoring sensors. The semantic representation model is used through an architecture that extracts information from the model and generates inferences to support decision-making in patient care. Supervised learning models are used to accurately predict the quality of alerts based on data from vital-sign sensors, thereby improving the efficiency of patient care and the overall clinical environment.

The validation of the system through medical scenarios designed to monitor patients with underlying health conditions demonstrated that the system can generate inferences that allow alerts with a confidence level close to 98% accuracy.

Future Research Directions Include the Following

-

Implementation of machine-learning models for medical treatments:

Development and integration of machine-learning models to predict medical treatments for specific diseases commonly found in clinical settings.

-

Establishment of inference rules:

Create rules capable of addressing disease-related information to improve the system’s inference capabilities.

-

Integration with advanced sensor technologies:

Incorporation of more advanced sensor technologies to improve the accuracy and reliability of patient-monitoring and alert systems.

-

Expansion of the Ontological Domains:

The ontology should be extended to cover additional medical domains and contexts to support a broader range of applications and clinical scenarios.

-

Improving decision-making support systems

Real-time data synchronization:

Focus on improving the real-time synchronization of heterogeneous information within clinical environments to ensure timely and accurate monitoring of patient conditions.