DOI: https://doi.org/10.21203/rs.3.rs-679710/v1
Ubiquitous Internet of medical things (U-IoMT) technology is designed to predict the efficiency and quality of health care facilities by using various connected objects to support patient monitoring systems. U- IoMT is connected to devices such as RFID tags and several physical sensor devices (WSN) that collect real-time information. This technology is used to comprehend complex security-related tasks. The ubiquitous platform can be used to access smart health care information through mobile and electronic devices, allowing for faster diagnosis and higher service quality. In this study, we use ontology to describe the semantic representation of medical objects and their data in U-IoMT backup in this analysis. The healthcare system aims to examine patient prescriptions and drug supply chain management records. Emergency healthcare services are connected to smartphone-wearable devices of patients for monitoring purposes to reduce emergency cases and to maintain e-patient records. The mobile health application aims to maintain the health status of a patient wherever the patient is located. The semantic sensor networks (SSN) architecture uses peer-to-peer communication to achieve semantic interoperability, which is described as interoperable IoMT platforms. A framework of SSN and the context-awareness layer was additionally created for visualization of patient remote health monitoring, drug management, patient moment analysis, and patient tracking were monitored using various devices, e-health was used to demonstrate the chronic diseases.
Ubiquitous Internet of Medical Things (U-IoMT) is a novel technology for collecting data and processing communication to a digital entity that is connected to a virtual cyber-physical system world and the real physical world [1]. Each actuator and sensor object interprets their environment and real-world technologies, such as real-time location and embedded sensors. U-IoMT concepts are based on universal things or objects connected to RFID, actuators, biosensor devices, and smartphones. IoMT refers to sensor devices that are connected via mobile-to-mobile communication. These devices are identified through a unique ID to define virtual representation within the Internet [2]. The semantic sensor web ontology for ubiquitous health care technology has been proposed by using extraction, semantic modeling, and reasoning [3]. The medicare health system integrates the IoMT ontology (IoMT-O) with the effectiveness of ontology building and evaluation, as shown in Fig. 1 of the IoMT-O architecture.
The advancement of ontologies is considered focal in these endeavors. Ontologies are metadata that provide a controlled vocabulary of terms, and each term has a specific definition and machine-processable semantics. By defining shared and basic area speculations, ontologies enable two individuals and machines to provide adequate information. As a result, it plays a key role in empowering context-based access, interoperability, and correspondence over the Internet.
In the real world, the next-generation social impact employs numerous mobile technologies of smart health care. IoMT smart/portable devices can connect to Wi-Fi/IPv6, and they can monitor patient health status in real-time daily. The institutionalization strategy for displaying information involves initial sensor information based on philosophical standards that utilize the Protégé and Ontology web language (OWL) [4]. As Protégé OWL has been included with an SWRL (semantic web rule language) manager, it allows for the modification of SWRL and OWL standard ontologies [5]. Moreover, a context-awareness framework is proposed with the specific end goal of providing clients with customized human services administration.
The semantic sensor network (SSN) web of medical things technologies are the new Ubiquitous IoMT application known as the Semantic Web of Medical Things (SWoMT). The SSN ontology enables the representation of semantic sensing and actuating devices that are related to information pertaining to energy, security, and quality. The IoMT-O framework that describes the real-world entity (objects, sensors, and things) of spatial and temporal objects could detect data and events [6]. In medical informatics, inquiries are made about the significant difficulties of the semantic web, the arrangement of controlled therapeutic administrations inside the clinical data frameworks, and semantic web interoperability. In the literature, only a few researchers have proposed utilizing a few ontologies based on semantic web to name restorative data for customized health care [7–9].
The W3C's implementation of OWL is critical to the semantic web and Internet metaphysics [10]. OWL is a web-characterization dialect that is more expressive than other cosmology dialects such as RDFS [11]. Semantic annotations are the process of combining semantic information and ontology domain concepts, as well as URLs. To transfer semantic IoMT service, the semantic annotation for IoMT entities and devices is used to annotate the semantic labels. As a result of the IoT increasing number of devices, IoT wireless technology will rapidly expand to approximately 60 billion IoT devices by 2021.
RDF encapsulates recognizing objects that use web identifiers and portray assets based on basic properties. This method could result in the creation of yet another meta-information producing system that utilizes semantic connections. It is an ontology with well-designed knowledge information, context sharing, reusability, and reasoning. Context-aware health ontology employs OWL-descriptive logic (OWL-DL) to define the common health domain, share information, and provide context information to software agents [12].
A sensor network in ubiquitous health IoMT environments for assisted patients resides within the IoT paradigm. To provide context-awareness in IoMT sensor networks, smart wearable health devices and an environmental system with a high-level knowledge ontology framework based in low-level sensor networks should be included. IoMT was initially intended to care for and monitor patients regularly via Wi-Fi connections and ultimately improve the quality of service. IoMTs primary goal is to activate various devices and connect them to a network. Another concept of IoT is everyday objects that are reliable, recognizable, locatable, addressable, and controllable via Wi-Fi through RFID, wireless LAN, or WAN. Some devices are intended for data storage, processing, and energy efficiency. The context ontology editing tool Protégé 5.4 was embedded in a health domain to evaluate the U-IoMT [13]. Protégé is one of the best open-source ontologies with built-in reasoner and rules, such as FACT++, Pellet, Hermit, and RACER-based on Fuzzy logic. Choosing a good reasoner is essential in developing an effective ontology framework.
Section 2 introduces the related works. Section 3 describes the data modeling layer architecture for E-health care. Section 4 describes the ontological structure of data and the modeling. The major challenges of the communication layer, which involved millions of sensor devices connected to the network, were improved based on bandwidth and radio magnetic wave spectrum. Section 5 develops the ontology with the capability of monitor, simulating, and analyzing the health status and various chronic diseases in real-time. Finally, Sect. 6 provides the test analysis and conclusion.
Ranganathan et al. 2003 [14, 16] reported the implementation of cosmology using DAML + OIL as a middleware for establishing mindfulness and semantic interoperability [15, 17]. Zhang et al. 2005 worked on the key technologies of devices with self-sensing mechanisms that provide context, framework, and interoperability that determine personalized health care services [18]. Remote healthcare applications have been used in rural and remote areas to deliver healthcare services on a remote monitoring basis in order to develop standard ontologies [19]. The IoMT recommends that stakeholders' security issues generate a security control for each threat automatically. Ontology tools employ semantic security measures [20]. The IoT healthcare and medicare systems domains generate the quality of semantic interoperability of medically connected objects in order to analyze vital signs and provide adequate service to patients [21]. The semantic sensor network web technologies and sensors utilized in many applications like medicare and security provide interoperability, heterogeneity, and the necessary environment in IoT data [22]. The e-healthcare framework is used in the ontological description to design and implement healthcare data into entities and properties [23]. Smart home environments have the potential to provide long-term monitoring of users and are typically outfitted with a variety of heterogeneous sensors that remotely monitor health and environmental parameters [24]. All smart sensor devices in the IoT environment of ubiquitous sensing and actuation are linked to context-aware applications [25]. The COBRA-ONT is a type of OWL; it is a collection of ontologies for describing places, events, and the properties associated with them in context broker architecture, which provides knowledge sharing, context reasoning, and privacy context-aware systems [26]. The robotic and Li-Fi technology was used for movements of arms and positioning in healthcare services and surgery reduces the risks of patients [27]. A remote patient health monitoring system provides the investigation and collection needed for large amounts of medical data, which improves decision making, process, and early diagnosis [28].
The proposed ubiquitous ontology-based semantic sensor web service for remote patients was shown in Fig. 2. The U-IoMT ontology system was built for remote patients to enable them to communicate with the IoMT gateway via the U-WSN home network using IoMT-O rules. Patients used to connect ubiquitous wireless sensor networks via smartphones, making it easy to contact physicians and medicare services. In this technology, an ontological-based model that uses various semantic annotations was created to reduce risk factors and provide appropriate treatment for those suffering from typical diseases. The U-IoMT needs to be connected to many sensor objects to observe patient conditions regularly on daily basis. Multiple sensors are connected to a patient to monitor his or her physiological condition, which plays a significant role in context annotation. All sensors obtain data from patients and transfer public packets to the U-IoMT network via WLAN and WPAN through the gateway. Simultaneously, the data will be saved for processing. All sensors are installed on the 5G-enabled smartphone. The GPRS 5G network connects to a smartphone and determines the location of the patient, physician, and medicare services. The entire middleware is controlled by semantic knowledge modeling and It controls semantic reasoning, which is responsible for retrieving low-level and high-level context information inference rules from the real world. It employs the setting reflection module to isolate the detected low-level setting from the abnormal state setting control.
Ontological context providers acquired information directly from sensors/devices registered with the U-IoMT platform. The semantic reasoning tasks for the inference engine and rules are applied to execute and process the semantic knowledge modeling. Simultaneously, the SWRL rules will be stored in the U-IoMT database to control administration settings and trigger the activity of reality substances connected to U-IoMT. This module also manages the administrations associated with the IoMT-O middleware. Patient's physiological information such as healing facility, doctor, and medicare will be expanded by sharing the database. For example, illnesses, indications, treatment, causes, and impact are built together in a physiological information extraction database. A doctor additionally gives the treatment procedure and the required medication.
U-WSN network
Contextual information is captured through web services via different sensor nodes that can communicate between the server, patient details, patient location, and physician. Ubiquitous healthcare applications are used to connect various IoMT devices with objects in hospital equipment. IoMT devices are connected to wired/wireless networks, such as Wi-Fi, IPv6, and TCP/IP. The data collected can be shared and transferred to other hospitals.
Reasoning engine
Ontology is based on contextual information provided by various sensors that detect attributes, entities, and individual activities in the healthcare module. Ontology is used to make recommendations based on the inferences of patients. It uses OWL rules and SPARQL queries in Fuzzy logic with SWRL to inform at the knowledge layer. OWL-DL can be easily converted to contextual information that is explicitly based on class relationships and properties. The OWL API creates IoMT Ontology and SWRL rules to perform the reasoning task. Such kinds of rules are classified as rules for connected object management. Each connected object of various sensors is assigned a number of properties such as date range, timestamp, and frequency.
IoMT-O server
It provides the web service for mobile clients and creates different applications according to various contexts.
Client
Different android applications consist of various layers that can visualize the interface, which enable regular web server invocations and patient interaction. The search engine activates data to and from a patient's hearing status and enables the patient to send his/her history details to the doctor via mobile connectivity to SMS.
Figure 3 shows the U-IoMT five layers architecture of semantic ontology, which includes physical U-WSN, web plugin and network, IoMT-O platform, data management, and application. The sensor web-oriented information was collected by various sensors, and data from sensors were tracked and visualized. The IoMT-O platforms are divided into three components such as semantic repository service, context fuzzy logic information service, and IoMT ontology service. The query and reasoning services are used to analyze users’ requests according to concepts and descriptions available in the ontology software. The analysis results are then returned to the sensor naming service. Sensor naming service is the web standard interface for asynchronously transferred messages or object information obtained from an information service and sensor provider service. An information service is a standard web service interface for requesting a sensor collection management environment that is suitable for requesting, filtering, and retrieving observations and sensor system information through a client/sensor naming service. The data modeling architecture is divided into four layers such as a U-WSN Layer, U-IoMT/web plug-in and network, IoMT-O platform layer, data management layer, and a U-IoMT application layer. The object from the U-WSN layer influences the network to connect with the context-aware layer, and exchange data through the semantic communication bus to the administration. Additionally, the context layers ensure a service’s independence and device the setting data provided by a sensor to an administration. If a client activates the detecting gadget, then the setting provide is appropriate for the device.
U-WSN Layer
This layer contains various kinds of WAN/BAN sensors and wearable devices, that can be implemented or injected into patients. The data is collected in real-time to assess health parameters via wired or wireless communication.
U-IoMT Network Layer
In this layer, data is collected in real-time through different sensors that are connected by a wired/wireless network. Once the sensor data is available to transmit and data are received from the other sensor nodes within the sensor network. The sensor nodes from one or more paths return to the gateway or base station to collect the sensed data through the server. The server collects the data through the sensor networks and transfers the same data to other entities. The in-network infrastructure and devices of the U-IoMT/web plug-in network identify service-oriented and high-level communication with other entities.
IoMT Management Layer
In this section, context management for various services is developed and implemented. A context-aware system has three types, namely, context providers (distributed sensors that collect data), context management, and context consumers (software applications that adapt their behavior according to context information). A context manager collects the information from various data sources to create heterogeneous context providers via sensor adapters. The knowledge database and events, rule files, and rule-based reasoners are all managed by the ontology manager. The SWRL that combines OWL and Rule ML is used by a context broker to manage available context information of various applications based on ontological techniques.
Data Management Layer
The data management layer collects and uploads patient information in real-time to the database. The physician must register in data management. Each physician and patient must have a unique ID in the database. The database management system performs the decision process for the physician in the entire emergency.
IoMT Application Layer
The IoMT application layer provides a variety of services that require the use of user interfaces. IoMT provides a variety of applications as well as medical services, report analysis, online tracking, and patient monitoring.
Figure 4 shows the U-IoMT healthcare system, in which authentication consists solely of logging in to automatically connect to the patient mobile applications. A doctor activates the U-WSN, which gathers data from various sensors about the patient’s condition. The information is displayed on the physician’s PC, whenever the information is required to access. The data collected by several sensor devices to obtain patient information are stored in the sensor network for real-time monitoring purposes. The Protégé tool provides the system with appropriate queries and an inference engine developed with the SWRL rules and SPARQL queries. We mainly focus on analyzing and detecting patient conditions and notifying physicians regarding a patient’s condition. The physician gives prescriptions and arranges for them to be delivered to the patient’s home through facilitated on smartphones. To reduce emergency risks, only an authenticated person can connect to the management of objects/things and systems. Numerous and novel rules are applied to configure the ubiquitous IoMT connected objects. The quires are prompted by semantic annotation, which is then transformed into knowledge reasoning via the inference engine. Rules are automatically stored in the ontology repository. After their authentication, physicians can execute the different functionalities and appropriate objects for patients. After receiving the patients' signatures, their health is monitored. Physicians can check the list of patients' health statuses and send real-time consultations to reduce treatment time.
The proposed algorithm's run-time flowchart based on the U-IoMT semantic web is shown in Fig. 5. Sensors can be installed in PC/mobile apps by U-IoMT users/physicists. Once their physical entity is registered and authorized, they can activate their PC and mobile applications.
In the semantic web, identity can be authenticated using a web browser, and activated users are connected via local or public networks. The user interfaces for assigning tasks to the various sensor nodes. The semantic cloud can manage communication by monitoring user activity in real-time.
A physician monitors user/patient healthcare every day and uses GPS frameworks to track the patient's location anywhere in the world. This feature can reduce the waiting time and frequency of patients when consulting their physician, as well as reduce the risks of emergency. U-IoMT ontology management evaluates ontology properties such as relationships, attributes, knowledge base, class properties, and inheritances. The e-health care domain ontology is based on medicare, clinical signs, and vital signs requirements. E-health ontology uses various sensors to stores domain health data in a remote health framework. The IoMT ontology is validated by including individuals and the real-time world. HermiT 1.3.8/Pellet 1.5 Reasoner, which is included with Protégé, and that was used to validate domain expert development. To validate e-health ontology models in the real world, evaluate the ontology-dependent Protégé tool after implementation on the ontology. Manchester validated the W3C consortium's ontology-specified tool. The developing ontology uses various applications in electronic health record data, medicare information, and tracking patient location on remote health framework monitoring using various sensors after verifying health data.
The proposed SWRL rules are intended to classify categories to reduce hospital wait times and identify patient risks. Patient status is sent via SMS to assist doctors. Figure 6 describes a patient interaction with a physician and the healthcare sector through ontology. The U-IoMT system interfaces with patient health records to store personalized data that is regularly updated in the IoMT server. Daily progress reports capture data automatically via clinical IoMT devices or equipment stored in the ontology server. The data collected are relevant information about patients’ medical records, diseases, and clinical symptoms, allowing for personalized quality care. The analysis of medical history is dependent on the relevant data collected from patients. Heterogeneous medical devices (personal digital assists) connected to mobile devices are either logical objects or physical objects used to collect data for task detection and interaction with the environment. A physician uses a portable monitor and observes patient monitoring systems. Generally, the medical parameters sensed by a device are body temperature, pulse, blood pressure, respiratory rate, ECG, and accelerometer. If a patient’s condition is critical then critical advice, medication, surgery, therapy, and suggested care are recommended. If a physician is not available, then a patient will be referred to the nearest hospital and follow-up for further treatment. The device class defines the general features of the hospital, such as interior infrastructures, whereas its subclasses define the types of smart equipment and mobile devices that it supports. An in-patient is assigned to stay in the hospital to determine whether the mobile device is connected to sub-classes, such as smart infusion pumps and smart wheelchairs. Persons and tracking devices are major objects/concepts identified and used to track patient details through RFID technology.
context-aware services can be provided by U-IoMT applications that use the context-aware ontological model. For example, Patient 1 registered online on March 12, at 11:30 AM in a certain hospital. His/her medical data are automatically transmitted to a particular physician. The information is automatically sent via SMS by Patient 1's wristband and implanted IoMT devices. The patient's waiting time is significantly reduced, and the GPS wristwatch tracks his or her location. An alert is automatically sent to the physician if an emergency is detected. Smart U-IoMT devices can automatically detect and monitor if a patient does self-diagnosis. Table 1 displays a list of objects and data properties that describe patient health status and their domain and range characteristics.
| Object property | Domain | Range | Data-type Property | Domain | Range |
|---|---|---|---|---|---|
| has observes | Physician | Patient monitoring | has status | Profile | string |
| has suggests | Physician | Treatment Plan | has report | Profile | string |
| has condition | Emergency Physician | Patient status | has report | Vital signs | Float |
| has symptoms | Patient | Emergency | has family history | Vital signs | Float/ string |
| has prescription | Physician | Patient | has maintain | Record | string |
| has Temperature | Physician | Temperature | has report | Record | string |
| has heart-rate | Physician | heart-rate | has report | Record | string |
| has Resp Rate | Physician | Respiration rate | Has Min Normal Range | vital signs | string |
| has Glucose | Physiological | Glucose | Has Max Severe Range | vital signs | Float |
Measured for Semantic Sensor Signals:
Semantic sensor network signals were measured as part of continuous monitoring of patient diagnosis using various sensors. Signal S is defined as a pair (Os, fs) of a sensor id Osanda signal function fs is on Ŕ-to-Ŕ U {┴}, where ┴ denotes the absence of signal value. A basic sensor signal reading temperature, pulse rate, blood pressure, and glucose are obtained from a wristwatch sensor for different time points that may vary signal have some periods with unknown values. A signal S is identified BY a real-time interval of I and the value of each point time interval.ie; ┴ Ɇ fs(I) and introduce undefined signal function f ┴ that maps are real into ┴. Some typical functions over time intervals are delivered to sensor signal values with a time interval frequency. Let's assume that we are given a finite set of basic signals S= {S1, S2, Sn}.
Fuzzy logic Ontology Knowledge Base and Queries:
A knowledge base is a set of pairs K and the ontology O represents the data set A. An ontology knowledge-based application domain in a formal language that takes into consideration of general characteristics of components and domain locations for logical expression sensors. In order to computational and characterize sensors domain subclasses and individual properties such as patient location and trajectory sensors. A formal basis for OWL2 Query Language and DL2 Lite [29], the main construct of DL-Lite2 are applied to reasoners and query tasks. concepts and roles of the following forms are available in DL-Lite 2:
B::=A │Ǝ R, C::=B│¬ B
R::=P│P¯ E::=R│¬R
Where A denotes atomic concept and P denotes atomic role P¯ is inverse of P, B denotes basic concept and R is the basic role, and C denotes the general concept and E denotes general role. DL-Lite has computational properties and conjunctive queries (CQ's) under semantic ontologies.
Ont(s,K)=(n Ɛ C│ K│=r(n)}
Where C is the set of the constraints appearing in the knowledge base context KB, and r(n) is obtained by replacing the queries as free variables in x with the constraints in n.
Table 2 shows the SWRL rules used to identify the patient health condition among different individuals, which are collected and formed into concepts and relationships in the e-health domain ontology.
| Concept Name | Axiom Description | Logical Expression |
|---|---|---|
| Device | Medical sensor devices that monitors can connect to vital signs of patients | Medical Object(?o) ^ Sensing Object(?s) ^ Connectivity(?o, T ˅ F) ^ has Lifetime(?s,?t) Measures(?m) ^ detects(?o, ?m) ^ has Value(?m, ?V) ^ Swrlb: greater than (?v, ?minV) ^ Swrlb: Less Than (?v, ?maxV⟶ has State( ?s, “ Active” ˅ “ Out of work”) ^ Validity( ?m, True ˅ False). |
| Staff | A person who works in a hospital that specifies staff id, staff name, and designation | Staff(?s)→(℈StaffID.String)∩(℈Name.String)∩ (℈ Designation.String) |
| Treatment | The critical situation occurs physician suggests the treatment occurs. | Patient(?P) ^ Medical_Object(EEG Sensors) ^ Attached to(?P, EEG Sensors) ^ Measured(?P, Brain Electrical Activity) ⟶ identifies( ?P, Neurological disorders) ^ has_risk(?P, Tumor_size increased) ^ spread(cancer, quickly). |
| Emergency alerts | Physician suggests the health risks to vital signs send sms to patient | Patient(?P) ^ Physician (?x) ^ Suggests(?P, ?x) ^ has_profile(?P, above 65) ^ has_risks(?P, memory loss) ⟶has_treatment(?P, Surgical treatment ˅ Drug treatment) ^ has_Message( ?x (prescription), Medicare) ^ has deliver(? Medicine,?P). |
| Paramedics | A person who is not a doctor but can examine in emergency time to take care of the patient. | Paramedics(?s)→Staff(?s)∩(℈Duty. String=‘Patient treatment in ambulance) |
| Doctor | Person Who give the treatments the patients and suggest | Doctor(?s)→Staff(?s)∩(℈ Duty. String=‘Patient treatment’) |
Physiological information has raw data context that should be displayed in the data format in the IoMT server if an IoMT application requests the context-aware system to provide raw data with time-stamped information by physiological context. The physical data context includes the clinical test, medical history, patient details, and supply of medicare information. The status of physical health data is inferred by the applied rule engine using the Protégé tool.
Figure 7 shows that context reasoning is converted from low-level into high-level context language by using ontology model-based rules. The semantic sensor network ontology converts health concerns into IoMT concepts. IoMT-O-based ontology can be considered for user-defined observation relationship classes and individuals properties. The upper layer concept vocabularies defined by physicians, patients, and caregivers automatically generate OWL ontology. date and time are mapped to SSN data types that are provided by the W3C Unicode consortium and the numerical values can direct matching OWL. sensor values, platform classes, and individual devices are all observed and defined by SSN. In the verification, the real-world ontology specification was used to develop the requirements for the basic standard for electronic health records. Pellet reasoned is available for Protégé to verify and validate e-health domain experts. Ontology methods that are used in the Protégé tool should be independently evaluated to develop the ontology. Figure 8 shows that the ontology-based SPARQL queries data by sending GET requests to REST API, thereby passing the query as a parameter. The IoMT service applied a rules component, which included domain-specific rules that describe personalized data by recognizing the status of the patient/administrator. IoMT-O rules can dynamically modify the status of changes made by the administrator. The OWL-DL health care ontology is being processed to be loaded into the memory. The transformed knowledge is applied as a knowledge base into high-level rules and triggers context-aware services. In this query, if the patient’s body temperature is high, then it identifies the disease, stage, and other patient details.
The main goal of this research work is to create a framework for improving the electronic healthcare sector. The proposed framework is based on U-IoMT technologies/platforms that collect patient information, automatically detect their location, and continue remote monitoring of patient health. Semantic web technologies enable the IoMT-O technique's heterogeneity and interoperability.SSN automatically connects to various sensors to access the information of many applications, including medicare, electronic health records, fast healthcare interoperability resources, and security concerns. Semantic web technologies integrate, process, and manage various sensors to allowing technical issues to be resolved while focusing on the concept. Health ontology necessitates the specification and scope of the implementation as well as the requirement of the application. The ontology structure is hierarchical, and it was initial implemented in the Protégé ontology-built environment.
Funding: This research did not receive any specific grant from funding agencies in the public, commercial, or not-for-profit sectors
Conflicts of interest/Competing interests: The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Availability of data and material: Data sharing not applicable to this article as no datasets were generated or analysed during the current study.
Code availability (software application or custom code): No specific code was used for conducting this study.
Authorship clarified: