A non-interventive monitoring system prototype for chronic patients with hypertension and asthma

1.Introduction

Significant financial resources are currently going toward developing telemedicine projects in Jordan, all of which have as their primary goal raising the patient quality of life. It is a well-known fact that there must be an unsolved problem for research to existing, and in the case of this work, the monitoring of chronic patients with hypertension, asthma, and chronic obstructive pulmonary disease (COPD) vital signs is a key factor in whether this is the case. Risk factors may influence these symptoms [1]. This is done to prevent their health conditions from becoming unstable, which could occasionally result in death. These individuals should monitor their vital signs in a discreet manner over time, meaning that they should only do so occasionally or when a sudden symptom necessitates it. In order to avoid problems brought on by variations in these variables at particular times, the idea of developing a prototype of a monitoring system for these vital signs was born. The prototype of a remote monitoring system that can transmit data readings over the internet to be viewed from a Progressive Web Application (PWA) was developed using microcontrollers, sensors, and cloud computing technology [2]. To confirm the proper operation of its components, this prototype was tested on relatives who were close to the researchers. The execution of the work is also integrated into the E-Health research line of the E-Solutions research group [3], promoting an increase in the popularity universities due to the development and reforms that this would bring to the work environment in healthcare providers and the daily life of people with the aforementioned diseases. It should also be noted that this connection catalyses the scientific community to focus on developing electronic components to enhance patient quality of life.

The world’s top IT Company mentions the Internet of Things (IoT) and how it connects physical objects to the internet to make data and technologies that were not previously possible [4]. If it’s true that the components currently in use are what restrict computer systems, it’s also true that when these components are in place, the constraints placed on them by their users. For instance, using the ideas discussed above and demonstrating a particular issue, a monitoring system could be developed to measure the vital signs of patients with chronic diseases and significantly impact patient care procedures. E-Health is a term used to refer to information technology (ICTs) [5]. The management of the IoT Devices, receipt of the data they collect, assurance of data transmission, and interaction with the devices are therefore required for this work to function as expected. It is also necessary to store those elements. In their unprocessed, unanalysed state in order to process and analyse them and produce the desired information. After the foregoing, possess the capacity to instigate action [6].

It was further supported by an article from 2014’s Vacuoles Magazine titled “E-Health Systems for the Treatment of Diabetes” [7], which exposes the effects of engineering’s contribution to diabetes patient care and prevention. Two of the four E-Health systems for the management of diabetes that they mention have a direct bearing on this work. The first is the use of wearable computing in the management and treatment of diabetes. The second is a system for daily control and monitoring of diabetes at home [8]. According to the literature that is currently available, there are still a lot of projects that are connected to the one that will be developed in this research, such as one that was demonstrated in the UK in 2015 and is called Bridging eHealth and the Internet of Things: the SPHERE Project [9]. This project essentially provides an overview of recent advancements in sensing, networking, and machine learning. Another of these is an article published in Dubai in 2014 that is full of interesting information and proposes a framework for collecting patient data in real time and carrying out appropriate non-intrusive monitoring. The seamless integration of various technologies, applications, and services is made possible by this framework based on Service Oriented Architecture (SOA) and the Cloud. Additionally, it incorporates mobile technologies for simple data collection and transmission from a patient’s wearable biosensors. Its title was Novel cloud and SOA-based framework for E-Health monitoring using wireless biosensors [10].

This work created a prototype of a non-invasive remote monitoring system that collects data based on the disease identified in the patient due to the aforementioned and assists those patients who cannot be constantly monitored by healthcare providers. Constantly, and these are kept in the cloud as histories. They can then be processed, and the system has the capacity to notify the medical professional and relative in charge of the patient.

With these features, the system is focused on enhancing the patient’s quality of life and advancing the state of the art by creating a prototype of a system composed of a hardware device and a software component at a lower price than the ones used today [11, 12]. This would enable it to be distributed more effectively to those with the chronic conditions that this work aims to address, namely COPD, asthma, and hypertension.

A doctor’s job involves caring for patients’ health anywhere in the world. Although there are standardised protocols for monitoring patients, such as setting appointments and home visits, each patient is unique, so sometimes these protocols do not function as intended. Even a minute can make a difference in situations where the patient’s life is in danger.

This research focuses on the potential dangers to the lives of chronic patients when the vital signs linked to their illness are not being watched. Chronic illnesses, as is well known, necessitate much closer monitoring and care than those that do not, requiring patients to alter their diets, increase their physical activity, and even search for more suitable environments in order to reduce stress. Every year, a sizable sum of money is spent on research into these issues to enhance the quality of life for these people. Electronic blood pressure monitors, for instance, were a development that had a significant impact as soon as it was introduced to the market. They eliminated the need for many patients with hypertension to rely on someone with the necessary training to use the older models.

Today, there are also various solutions for monitoring and care, depending on the risk factors that could change the health status of a chronic patient, such as a sudden rise in blood pressure for hypertensive patients. The first is exemplified by the cardiac pacemaker, a device that improves the function and supervision of the heart’s blood pumping. We can name the Holter as one of the others, which is a tool typically used for 24 to 48 hours to track the heart’s functionality throughout daily activities. Although it is known that some conditions may be brought on by low blood oxygen levels, in the case of the latter, the device in question is unable to track this symptom, so further research is required to address it. The patient’s symptoms.

It was decided that for the development of this work, the chosen chronic diseases would be those that are directly related to the state of vital signs, blood pressure, and blood oxygen levels. This was done due to the expense of economic resources and time for both health providers and patients, caused by the studies in the case described above that are handled sequentially without the need for it. Particularly hypertension, which the first corresponds to, and asthma and COPD, which the second corresponds to [12].

This work aims to develop a prototype for a non-invasive system for collecting blood pressure and oxygen saturation data. This has a hardware component that monitors the aforementioned vital signs using inexpensive sensors connected by a programmable card that allows the data collected from the patient to be sent periodically to the cloud through WiFi technology, where it is managed and processed in such a way that the relatives and doctors in charge of the person are informed of the state of their health and appropriate action is taken. Using platforms based on free software, which represents a significant decrease in cost and ease of implementation of the product prototype, allows the work to be economically feasible without compromising its viability. The current project uses open-source software and Internet of Things (IoT) technologies to create a working prototype of a remote monitoring system for tracking blood pressure and blood oxygen saturation of chronic patients in Jordan who have hypertension, asthma, and COPD.

2.Methodology

3.Methodology and development of the prototype

This work used the RUP software development methodology, articulated with the specific objectives as follows:

3.4Stage 1

“Propose software architecture for a web platform that supports the integration of previously identified measurement services by the IoT technologies provided by the market, establishing the functional and non-functional requirements of the monitoring system.”

3.4.1Requirements

It is stated that chronic patients are classified as such when they are diagnosed with a chronic disease; they are assigned psychological support so that they can face the situation and adopt a new appropriate lifestyle without leaving behind their life work. Despite the lifestyle change, for one that helps prevent the symptoms of the chronic disease suffered by the patient, there are always external stimuli that can cause an alteration in the patient’s vital signs. Normally when this happens, two things can happen: that the alteration is mild or that it is serious. If the alteration is severe, in the worst-case scenario, the patient could die.

The ideal would be to have real-time knowledge of the vital signs of chronic patients so that, if a worrying situation arises regarding their health, action can be taken quickly to treat it in time and prevent the problem from escalating to a serious state worse.

The interview also showed that currently, the medical centres in the city of Irbid do not have the technology to monitor patients when they are at home.

3.4.2Architecture

According to the system requirements, the approach given to the solution and how it is planned to be implemented, the following artefacts were produced corresponding to general schemes that serve as support for the explanation of the system to users who are not familiar with the components. From this, Fig. 1 shows a general system scheme that will superficially explain its main parts to users who do not handle technical terms and to whom it is not necessary to explain them in depth.

Figure 1.

General scheme of the system.

3.5Stage 2

“Build the design artifacts required when using the RUP software development methodology.”

3.5.1Hardware components

Figure 2.

ESP32 pin diagram.

Figure 2 shows the pin diagram with the legends explaining each of these characteristics. This board version was selected because it allowed it to be used with a breadboard, facilitating performance for the development stage.

Figure 3.

MAX30102 pinout diagram.

Figure 3 shows the ports of the MAX30102 pulse oximeter. This version was chosen because it has Infrared and LED protection, which was considered an advantage when assembling the prototype.

Figure 4.

Functional diagram of the MAX30102.

Figure 4 shows the schematic representation of the pulse oximeter sensor shown in Fig. 3.

Figure 5.

TP4056 pinout diagram.

Figure 5 shows the pins of the TP4056 module and what each of them is used for.

Figure 6.

Schematic diagram of the TP4056.

Figure 6 shows the schematic representation of the load module shown in Fig. 5.

3.5.2Physical view

Figure 7 shows how the total deployment of the system was planned. More specifically, it shows the technologies used and what the direct and indirect interactions of the system components are.

Figure 7.

Deployment diagram.

3.6Stage 3

“Develop the prototype of a non-invasive remote monitoring system for patients suffering from hypertension, asthma and COPD.”

Next, everything related to developing the prototype of the Remote Monitoring System for chronic patients with hypertension, asthma and COPD, CCFHAC, is explained. Information such as tools, libraries, modules, frameworks, platforms and configurations will be mentioned.

3.6.1Hardware

As the central axis of the device, the ESP32 was used, a low-consumption module from Espressif, successor to the ESP8266. Integrates WiFi and Bluetooth, pins for I2C protocol, SPI, etc. This component served to provide the WiFi connection, storage of the configuration parameters thanks to its internal flash memory and the integration of the other necessary components, such as the MAX30102, which is a low-power pulse oximeter sensor that communicates through the I2C protocol, used to take measurements of the corresponding vital signs.

Finally, the TP4056 component, a Li-Ion battery charger, is used for the ESP32 to be powered from said battery.

The code was made with PlatformIO, an open-source ecosystem for the development of the Internet of Things (IoT), which is made up of different platforms and libraries compatible with different frameworks such as Arduino, ESP-IDF, or Simba. In the case of this work, it was chosen to work with Arduino. Therefore, it was necessary to look for libraries compatible with this and the Espressif 32 Platform. For the WiFi configuration, the ESPAsyncWifiManager and ESP Async WebServer libraries were used, which allow configuring a Web Server to enter the credentials of a nearby WiFi network to establish a connection. In addition, custom parameters can be entered, such as the data necessary to connect to the broker and publish your readings.

The AsyncMqttClient library was used for the MQTT connection, which encapsulates the publication and subscription management in broker topics. You only have to enter the connection parameters, such as the broker URL, broker port, user and password for authentication, broker. The ArduinoJson library was used in conjunction with the SPIFFS library, to load from or save to the configuration file. And finally, the SparkFun MAX3010x Pulse and Proximity Sensor Libra library were used to perform the blood oxygen saturation readings of the MAX30102 oximeter and mean arterial pressure through the readings of the infrared sensor and after validating the values sent them by MQTT to the broker.

Figure 8.

(A) Esp32 and Max30102 (B) Finished prototype.

Figure 8A shows the system in its early stages of development, where Esp32 and Max30102 are connected and work in a breadboard test. Figure 8B shows the finished prototype.

3.6.2Back-end software

It is built on the Node JS platform, enabling modular and event-driven development using JavaScript. A minimalist and flexible web application framework called ExpressJS was used to develop the API. It provides a solid set of features for web applications, with thousands of HTTP methods and middleware at its disposal, allowing the quick and easy implementation of robust APIs. MongoDB was chosen for data persistence; therefore, the ODM (Object Document Mapper) MongooseJS was used to define the models with a strongly typed schema for the application. Includes data types, validations, query building and more.

The set of all the above components forms the basis of the entire Backend. The MVC architecture is used. Controllers are a series of ExpressJS middlewares: functions that access the request object (req), the response object (res), and the next function in the application’s request-response loop. Middlewares can perform various tasks, including:

• • Run some code.

• • Make changes to the request and response objects.

• • Terminate the request-response cycle.

• • Call the next middleware in the stack.

The controllers used in this work are responsible for receiving requests from a user, performing some action on the database if necessary, and responding to the user by ending the cycle or directing the error-handling middleware. There is one controller per collection in the database. As can be seen, the REST API is closely related to the database models, as shown by the architecture used. Controllers are used by routes in Express, which refer to application endpoints (URIs) that respond to client requests. These are defined using the methods of the app Express object that correspond to HTTP methods. They can receive one or more middleware as parameters or receive a route first and then one or more callbacks.

The models have implemented thanks to Mongoose; these models have the necessary functions to interact with the database collections, which made it easier to perform queries. It also provides the necessary methods to establish the connection between the backend and MongoDB; you just have to tell it the connection URI.

The system allows users to authenticate with the system and protects the routes so that they are only accessible to users with the allowed Roles. To achieve this functionality, several modules are necessary in addition to having the finished models, especially the user one.

The necessary modules are the following:

• • Passport: It is an authentication middleware for Node JS, extremely flexible and modular. Allows easy integration with Express-based web applications. It has a set of strategies for authentication.

• • Passport-local: An authentication strategy with Passport allows identification with username/email and password.

• • Passport-jwt: An authentication strategy with Passport allows authentication with JSON Web Token (JWT).

• • Bcrypt-nodejs: Module that allows the use of a Hash algorithm to secure passwords in the database.

• • Jsonwebtoken: Module that allows creating, signing and reading JWT.

The Backend has functionality almost separate from the MVC architecture, and it is the MQTT Client, since the system allows communication through a Broker, that is, as the central node of the star topology formed by using the MQTT protocol. This allows messages to be sent in real-time from the device to the web application. But since the broker executes separately from the Backend, the latter must participate in the communication to analyse data and store it in the database. To meet this need, the MQTT module was used. It works as a handler for MQTT messages going through the broker. To send these to Doctors or Patient Managers, the Node Mailer module was used to test an alert message sent to email, which helps to send emails by different means.

Front end: On the other hand, the views were developed with the framework for Ionic hybrid applications. To consume the REST API the Angular HttpClientModule Module is used in its version 5.2 since it is the one used by the Ionic Framework in version 3.9.2. And for communication with IoT devices through MQTT through the broker, the ngx-MQTT module was used in version 5.4.0, since versions greater than or equal to 6 are only compatible with Angular in its version greater than or equal to 6.

Most of the pages have clear and specific functions. Still, the most complicated logic of these is related to authentication since the following pages are involved: Tabs, Login and App, in addition to the Authentication Provider. A Provider is a special class responsible for providing a service to the application pages that need it. Generally this service is responsible for making HTTP requests to the REST API, using the HttpClientModule module.

The main “page” of most applications in Ionic or Angular is App, this page is a Shell that encompasses the entire application, and it does so using the ion-nav tag in its Template, which is an Ionic component that is handles navigation, the page that this tag receives via property binding to the root attribute is the page that is displayed. To deal with authentication, the page sent as root is the Login page.

• • Login page: which performs several operations; first, through the Authentication Provider it sends a JWT (if it has one) to a dedicated REST API endpoint to validate the token. If the API responds correctly, change the root with the NavController (used to work on the ion-nav component) and place the Tabs page that would be that of the application as such so that the JWT Authentication is carried out correctly. If the token is not valid, it remains on the Login page, allowing you to enter your email and password to authenticate those values. Once the user is authenticated, the operation of the pages is trivial; each one has its specific function. Here is an explanation of some pages:

  • – The Tabs page is used to obtain the operation of the navigation using tabs.

  • – The Profile page, where the user already authenticated by the system, can see his basic information.

  • – Patients page: this loads all the patients of a Physician or Manager, where they can select the option to monitor the patient they want.

  • – Monitoring page: this is the one used by the ngx-MQTT module to obtain real-time readings from the selected patient’s device. And they can select to view the history of the specified patient.

  • – History page: this loads the data of the vital signs that the selected patient has saved in the database.

  • – Manage page: shows the Administrator the options he has to manage users, devices, make assignments, for them you can access the specialized pages for that.

  • – User Registration page: shows a form that allows the Administrator to create system users.

  • – The User List page: shows the Administrator all the system users to carry out operations such as updating or deleting them.

  • – How to delete users: not a page but rather an alert that allows the Administrator to confirm if he wishes to delete the indicated user.

3.6.3Conditions for its operation

The MAX30102 module has an Infrared sensor and a light sensor. For the correct use of the readings of the sensor values, the research group was based on the process followed by a group of researchers from Shivajinagar, India, where they converted the values of the Infrared sensor into Mean Arterial Pressure readings [13] dividing them by a factor that depends on the average readings obtained by the sensor in its time of use. For this reason, an experiment was carried out to find said factor and compare the sensor readings to those of a digital tensiometer. Evidence of this can be found in the results section under stage 4.

On the other hand, in most of the sources found, the measurement of the patients’ pressure was given according to the Systolic and Diastolic, which correspond to the movements made by the heart at the time of the cardiac cycle. And for the most part, a patient’s health risks are defined by those because the most prominent use of Mean Arterial Pressure (MAP) is an indicator of the body’s ability to deliver oxygen to the organs and fabrics.

The Manual of Clinical Neurology states that elevated MAP can lead to increased oxygen demand by the heart, ventricular remodelling, vessel damage, organ damage, and sudden heart attacks [14]. This information was taken into account to ensure the existence of the danger of high MAP values and not immediately rule it out because it is not used conventionally.

GlobalRPH, a clinical reference page that complies with the standard for reliable medical information [15] proposed by the Health on the Net Foundation, was searched to find these risk values. Spanish, which was granted the status of NGO by the Economic and Social Council of the United Nations in 2002. From this source, the limit values of mean arterial pressure were taken; these are 70–110 mmHg [16].

To define the limit values of oxygen saturation in blood, the information found on the website of the British Lung Foundation [17] was taken as a reference, which has the quality mark of the British information standard of the UK NHS, which is awarded only to those organizations that demonstrate a commitment to reliable information on health and care. From this source, it was defined that the normal value of blood oxygen saturation is 94%–99% in people without respiratory diseases. And for patients who suffer from these, the levels should be between 92–94, possibly higher if oxygen treatments are performed [18]. A lower value warrants requesting a more rigorous review of blood gases due to the risk of hypoxia.

4.Limitations

The current project uses open-source software and Internet of Things (IoT) technologies to create a working prototype of a remote monitoring system for tracking blood pressure and blood oxygen saturation in patients in Jordan who have chronic hypertension, asthma, and COPD.

5.Conclusions

After the development of this work, several conclusions can be reached. First, as directed, information was gathered. The information collection stage was completed after searching secondary sources and interviewing primary sources. System architecture, as well as functional and non-functional requirements, were established. In addition to the requirements, the 2 scheme defined the system’s components and communication. Artifacts were created. Before implementation, diagrams were created to model the system’s components, behaviours, and relationships. The system was used to prototype a remote vital signs monitoring system for hypertension, asthma, and COPD patients. Annexes contain the System Manual, User Manual, and Requirements Specification. The tests revealed that sensor readings were within a reasonable margin of error, so they cannot be dismissed as false right away.

Second, the system’s functional tests confirm its development success. As a result, a system for tracking means arterial pressure and blood oxygen saturation was developed and compared to the diabetes daily control and monitoring system from home mentioned in the article E-Health Systems for Diabetes Treatment [19]. The new system is similar but monitors vital signs specific to diseases. This allows patients to mail their blood sugar levels to their doctor. However, after further research and development, the system could be used to monitor diabetes and other diseases. By developing electronic components, this research improves patient quality of life. The current prototype data is untrustworthy. Device collection tests and actual data differ due to uncertified sensors and algorithms. The data from the prototype and the digital sphygmomanometer differ by 7.16%. The pulse oximeters chose for the project overheated after use. Despite a small margin of error and a more recent sensor, these findings are surprising.

6.Recommendations

During the execution of this work, it was evidenced that there are certain limitations of it, which will be mentioned below, along with the strategy to address each one.

The first difficulty was transferring real-time data from an IoT device to managers or doctor’s mobile device or personal computer progressive web application. Due to the high volume of messages, it was necessary to find communication protocols for this use case that could send multicast messages, be used by devices with limited resources, and allow sending of light messages with low bandwidth load. MQTT was chosen as the IoT communication protocol to get around this restriction. Libraries for ESP32 (Arduino) and Angular (web browser) were sought after MQTT was decided upon. By type of library, restrictions vary. The web browsers and Arduino’s ESP32 libraries only act as MQTT clients using the broker’s ports for WebSockets and TCP, respectively. Interface for brokers. The broker should open both ports as a result. Due to prior restrictions and decisions, it was necessary to implement a Broker in work as a backend module called Mosca in NodeJS. This broker could not deploy and expose the interface; it could only expose it over WebSockets on the web server’s port. CloudMQTT, a free broker, was selected to get around this restriction. A private broker with the necessary interfaces, authentication, and encryption is advised because sensitive data is handled there. An oximeter with an I2C interface was simple to locate, but a sphygmomanometer that worked with the communication protocols of the ESP32 microcontroller was not. Thus, other blood pressure measurement techniques were looked for in the literature. The alternative was to use digital light sensors and infrared LEDs. The standard of the sensors is to be used as another restriction. To ensure patient reading quality, certified sensors should only be used in production settings because they are expensive and outside the scope of the work.

Ethics statement

The Committee of Scientific Research & Conferences at the Faculty of Medicine, Najran University reviewed the study protocol and ethically approved the study application (No. 2\3\2022). All participants understood the purpose of the research and agreed to participate voluntarily. The study complies with the Declaration of Helsinki.

Funding

No funding was received for this research.

Data availability statement

The data used to support the findings of this study are included within the article.

Author contributions

Conceptualization, H.A. and A.A.; methodology, A.A.; software, H.A.; formal analysis, H.A. and A.A.; investigation, H.A.; resources, A.A.; data curation, H.A. and A.A.; writing-original draft preparation, A.A.; supervision, H.A.; project administration, H.A. and A.A.; Both authors have read and agreed to the published version of the manuscript.