Keywords

1 Introduction

Considering that mobility is a common practice in the everyday life of physicians, which implies in transit through different environments (hospitals, clinics, ambulatory, etc.), it is possible that they remain periods of time without contact with the nursing teams that support them in the treatment of patients [6].

In turn, studies have indicated that the frequency in the communication between physicians and other health professionals in hospitals is an important aspect in the treatment of hospitalized patients. Longer periods between communication can lead to delays in performing procedures, drug prescribing, etc., which contributes to a possible increase in the period of hospitalization [30].

The premise pursued in this paper is to explore Internet of Things (IoT) resources, both for the acquisition of information about patients and to perform an interoperation with the medical community whenever necessary. This interoperation will be coordinated by automated procedures, governed by mechanisms for Situational Awareness.

Situational Awareness refers to a model in which the computational system is able to verify the aspects which are of its interest and, when necessary, to react to its changes by triggering relevant procedures. This approach materializes IoT premises, in which there is an autonomous communication between intelligent objects, used by health professionals, cooperating for the advancement of their different activities [25].

According to [31], for the construction of Situational Awareness in distributed environments, as in the case of the present proposal, some challenges must be addressed: (i) context acquisition from heterogeneous and distributed sources; (ii) processing of contextual data acquired; and (iii) the respective actions directed at the devices and individuals involved.

Considering this scenario, this paper aims at the conception of an approach, called I2VSM (Interactive and IoT-based Vital Signs Monitor), which integrates: (i) a platform for acquiring vital signs; (ii) an environment for contextual processing, which through customizable rules builds the patients’ Situational Awareness, and, when necessary, sends notifications to the health professionals involved; and (iii) a textual and graphical display interface of these signals, which can be accessed remotely.

To do so, the software architecture of the EXEHDA middleware, particularly its subsystem dedicated to contextual processing, will be explored in the conception of the I2VSM approach, which will be used in the inference of the patients’ situation.

It is expected that the I2VSM allows physicians to remotely anticipate diagnoses and the consequent prescribing of procedures. In addition, it is understood that the research in progress has the potential to contribute to the reduction of hospitalization time.

This paper is organized into seven sections. The second section presents theoretical concepts considered interesting when reviewing the literature related to the proposal. In the third section, the related works are discussed. In the fourth section, the EXEHDA middleware is introduced and highlight its main functionalities involved in obtaining the Situational Awareness. The fifth section presents the I2VSM approach, addressing its main characteristics. In the sixth section, the prototyping and tests for the I2VSM approach are discussed. Finally, the final section presents the final considerations and future work.

2 Scope

In this section are presented concepts judged relevant when reviewing the literature in relation to the developed proposal.

2.1 Situational Awareness

Situational Awareness consists of perception and comprehension of one or more contextual information and projection of their status in the future [10, 11]. The definition of contextual information was proposed by Dey [8], which defines context as any information that can be used to characterize the situation of an entity.

In order to obtain situational awareness, three levels can be defined [24]:

  • Perception: involves the processes of monitoring, detection, and recognition that leads to realizing the value of multiple situational elements. These elements could be the temperature registered by a sensor, alerts reported by intrusion detection systems, events recorded in files as well as their current states: time, place, conditions, forms, and actions;

  • Comprehension: consists of the synthesis and correlation of disconnected elements identified in the level of perception through different strategies, for example, based on knowledge or anomalies. This level requires the integration of these pieces of information to understand how could impact on the situation of the computational environment;

  • Projection: responsible for the ability to avoid occurrences of unwanted situations, through the comprehension of the elements of the current system. Achieved by the knowledge of the situation, the dynamism of the elements and the comprehension of the situation.

2.2 Vital Signs

Vital signs are medical signs that indicate the status of the vital (life-sustaining) functions of the human body. These measures are taken to help assess a person’s overall health, provide clues to possible illness, and show progress towards recovery. Among vital signs, the following are considering the main ones:

  • Temperature: it represents the equilibrium between the produced heat and the lost heat, also known as thermoregulation [23];

  • Pulse: it is defined as the palpable rhythmic expansion of an artery produced by the increase in the volume of blood introduced into the vessel by the contraction and relaxation of the heart [34];

  • Blood pressure: refers to the pressure exerted by the blood against the arterial wall. It is influenced by cardiac index, peripheral vascular resistance, blood volume and viscosity, and elasticity of the vessel wall [26];

  • Respiratory frequency: is the designation given to the number of completed respiratory cycles in a specific time interval, more often being expressed in breaths per minute. The respiratory rate is an important data in the observation of the patient and its precise measurement is fundamental for its evaluation [13];

  • Heart rate: is the velocity of the cardiac cycle, blood flow, and blood pressure that occur from the beginning of a heartbeat to the next heartbeat, divided into two periods. Relaxation period called the diastole, in which the heart distends when it receives the blood, and contraction period named systole, in which the heart ejects the blood [22]. It is measured by the number of heart contractions per minute and may vary according to the physical needs of the body [32]. It is usually equal to or close to the arterial pulse measured at any peripheral point of the body;

  • Pulse Oximetry: is the measurement of oxygen saturation of the blood, which is the percentage of oxygen being transported in the blood circulation. Pulse oximetry is a non-invasive method to monitor the oxygen saturation of a person (SO2). Although the reading of SpO2 (peripheral oxygen saturation) is not always identical to the most desirable reading of SaO2 (arterial oxygen saturation) of the arterial blood gas, both are sufficiently correlated so that the safe, convenient, noninvasive and inexpensive method of pulse oximetry is a valuable option for measuring oxygen saturation in clinical use [21];

  • AVPU Scale: the AVPU Scale (an acronym for “alert, voice, pain, unresponsive”) is a system with which health professionals can measure patients’ level of consciousness [16]. The AVPU scale has four possible outcomes for analysis and subsequent recording. The evaluator should always work from the best (A) to the worst (U) to avoid unnecessary testing in clearly conscious patients. The four possible outcomes are [4]: (A) Alert - the patient is alert, able to communicate and responsive; (V) Verbal - the patient does not respond until you speak to him; (P) Pain - the patient only responds when you apply a painful stimulus (such as pinching the trapezius muscle); and (U) No response - the patient is unconscious.

2.3 Tracking and Monitoring Scoring Systems

There are systems called Track-and-trigger scores, and these systems calculate a score that reflects the health status of a patient regarding his or her vital signs. Several scoring systems are used internationally [3], such as the Early Warning Score (EWS) [5], the Modified Early Warning Score (MEWS) [35] and the VitalPAC Early Warning Score (VIEWS) [28]. In addition, some hospitals introduced their own prior warning scores, such as the Chelsea Early Warning Score (CEWS), introduced by the Chelsea and Westminster Hospital in the United Kingdom [2].

Among these systems, one of the most used is the EWS, which is based on vital signs of respiratory rate, oxygen saturation, temperature, arterial pressure, pulse/heart rate and AVPU response [5]. The value ranges were established in each vital signal (see Table 1) and a value was adopted for each one. Thus, the EWS calculation consists of the sum of the scores of each Vital Sign.

Table 1. EWS computation
Full size table

2.4 Medical Information Mart for Intensive Care (MIMIC)

The MIMIC, currently in version III, is a relational database containing data on patients who remained in intensive care units at Beth Israel Deaconess Medical Center (Boston, Massachusetts, USA), which comprehends more than 58,000 hospital admissions of 38,645 adults and 7,875 newborns [14]. Data range from June 2001 to October 2012, including vital signs, medications, laboratory measurements, observations and annotations by care providers, fluid balance, procedure codes, diagnostic codes, image reports, hospitalization time, survival data, among others.

The MIMIC-III database is notable for the following reasons: (i) it is the only database of critical care on open access. The open nature of the data allows the clinical studies to be reproduced and improved upon, which otherwise would not be possible; (ii) its data set covers more than one area, with detailed information on the individual care of each patient; and (iii) the data analysis is unrestricted, which allows both clinical research and its use in education.

3 Related Works

During the research effort, several approaches related to the remote monitoring of patients were identified, among which five papers were selected. For its selection the work should contemplate the following aspects: (i) monitor vital signs; (ii) support remote operations of both sensors and actuation (sending of alerts, etc.); and (iii) consider the use of Situational Awareness.

The work of [12] presents a model that automates the collection, delivery, and processing of vital patient data with the help of an edge device and the Docker container [37]. According to the author, health monitoring and IoT-based emergency response applications require a shorter latency and delay when exchanging information. Information is exchanged between the edge server, the cloud, and the user’s device, which directly affects performance. To reach the goal proposed in the paper, a Raspberry Pi is used as the edge device to optimize the process of data analysis of the sensors, thus it is possible to work with low bandwidth, low latency and with congested networks.

In the paper of [9], the SM-IoT platform is proposed, an IoT-based platform for intelligent and personalized health care for patients and caregivers. The objective of this platform is to improve the remote monitoring of the patient and to promote health services. The SM-IoT platform is capable of collecting data from heterogeneous information sources, integrating them using a flexible semantic web, storing them in the cloud for later analysis, visualizing these data with friendly interfaces and facilitate their sharing, taking into account their aspect of privacy.

In the work of [15], a distributed, autonomous, flexible and low-cost hospital automation system is proposed. It consists of servers and sensors that can be easily configured. An Intel Galileo board with an integrated Wi-Fi card acts as a web server, allowing access to authorized people on the same LAN using a personal computer, or remotely via Wi-Fi or 3G/4G using a smartphone. The system benefits not only patients receiving more efficient treatment, but also physicians who can expedite their efforts to serve a larger number of patients. The main idea of this system is continuous monitoring of patients and an instrument control via the internet.

The proposal of [1] presents a generic Health-IoT framework that contains a Clinical Decision Support Systems (CDSS), to provide a self-adequate health monitoring system personalized for the elderly in the home environment. The framework is focused primarily on support sensors, the communication means, secure and reliable data communication, cloud-based storage, and remote data access. CDSS is used to provide a personal report on the health status of individuals based on the daily observation of vital signs. A set of predetermined rules is used to classify individual health parameters and Case-Based Reasoning (CBR) is applied to generate the general state of health of a user.

In [20], the EcoHealth (Health Care Devices Ecosystem) is presented, a middleware platform that integrates heterogeneous body sensors to allow remote monitoring of patients and improvement of medical diagnostics. Its main objective is to integrate information obtained from these heterogeneous sensors for the purposes of monitoring, processing, visualization and storage of such data, as well as notification and acting concerning the current conditions of the patients and their vital signs. The EcoHealth project is based on several well-established Web technologies (HTTP, REST and EEML) with the aim of standardizing and simplifying the development of applications in the context of IoT, thus minimizing compatibility and interoperability problems between manufacturers, proprietary protocols and data formats.

Among the main differences in I2VSM is the use of the Early Warranty Score (EWS), which is a recognized international standard for Vital Signs Tracking and Monitoring, which has been used in non-automated approaches and is not included in the related work.

Another particularity of I2VSM is the use of a middleware, which is only employed by one related work [20]. For the treatment of the challenge of providing support for the Situational Awareness to the IoT applications, it is worth highlighting the use of middleware, which is inserted between computing infrastructures and applications [27]. The middlewares, through high-level interfaces, allow the interoperability of different IoT devices, providing, among other functionalities, a standardized means for access to the resources available in them.

4 EXEHDA Middleware

EXEHDA consists of a service-centric, service-oriented middleware that aims to create and manage a widely distributed computing environment, as well as to promote the execution of applications on it. The middleware has been explored on research fronts that address IoT challenges [33].

EXEHDA has an organization composed of a set of execution cells, as can be observed in Fig. 1. Each cell, regarding the provision of Situational Awareness, is composed by a Context Server (CS), and by several Edge Servers (ES) and/or Gateways.

Fig. 1.
figure 1

IoT environment managed by EXEHDA

Full size image

The gateways collect contextual information from physical or logical sensors and are intended to treat the heterogeneity of the various types of sensors, in both hardware and protocol aspects, and to transfer the collected in a standardized way to the Edge Servers. In EXEHDA, the Gateways are implemented on a specific embedded hardware for the purpose of interoperating with the sensors and actuators.

In EXEHDA, the processing of the contextual information is distributed, being the Edge Server responsible for one part, and the Context Server with another (see Fig. 1).

The data received by the various Edge Servers are transmitted to the Context Server that manages and performs the contextual processing and storing steps. The Context Server can combine data from Edge Servers with historical information, which is stored in the Context Information Repository. A broader discussion of the different functionalities of both Gateway and Edge Servers is available in [33], and in turn, an evaluation of the different potentialities of the Context Server can be found in [19].

5 I2VSM: Conception and Functionalities

The software architecture designed for the I2VSM approach is presented in Fig. 2, below. During this section, the functionalities of the different modules are treated and their operational profiles are discussed.

Fig. 2.
figure 2

I2VSM software architecture

Full size image

5.1 Environment Interoperation Block

The Environmental Interoperation Block is constituted by the API Input Module, Devices Module, and Communication Module. This I2VSM block operates on a native EXEHDA middleware gateway.

The API Input Module includes the input of vital signals from commercial parametric monitors and has a RESTful API that allows any manufacturer to make their data available to the I2VSM. The Device Module is responsible for receiving information from vital-signal sensors by means of an ESP32, having a Python program that collects the data coming from the sensors. In turn, the Communication Module is responsible for transferring/receiving information and commands from the Vital Signs Processing Block.

5.2 Edge Processing Block

Two modules form the Edge Processing Block, which is instantiated on the EXEHDA Edge Server. The Communication Module, which is responsible for interoperating with the User Interface Block; this functionality is instantiated in the Edge Server Interoperation Module of EXEHDA. And the Persistence Module, which aims to perform a temporary persistence if the Internet connection with the User Interface Block is lost. This feature is instantiated on the EXEHDA’s Edge Server Persistence Module.

5.3 User Interface Block

The User Interface Block is constituted by the Vital Signs Processing Module, Web Visualization Module, Alerts Module, and the Contextual Information Repository, operating on an EXEHDA middleware Context Server.

Vital Signs Processing Module

Processing takes place in the Vital Signs Processing Module, where the data is received and standardized according to the internal pattern of the system. After standardized, these data will pass through the set of rules that will define the EWS indexes. Afterward, it is processed by the Medical Individual Rules Pattern (MIRP), which is a set of rules defined by the physician, individuated for each patient. In this module, all the rules related to the triggering of alerts, based on the collected vital signs, are treated. The following integrate the set of rules: (i) rules defined by the user, that will meet their specifics based on their professional experience or their specialty’s particularities; (ii) rules based on international standards.

The EWS score is used by default by the I2VSM for the generation of alerts. Triggers and alerts are different for each hospital, and I2VSM allows the EWS score to be defined and allows the physician to define their own triggers and corresponding alerts. The triggers used by the Norfolk and Norwich University Hospital, or NNUH, will be used as a base. According to the NNUH, physicians should be called for a review when the EWS score is equal to or higher than 5, and if greater than or equal to 6 the physician needs to attend to the patient immediately (within 30 min).

The physician user of I2VSM can configure its rules templates using their own definitions, established pattern rules, or a hybrid set of rules - which makes the configuration of their personalized alerts flexible. The configuration of custom rules (see Fig. 3) has an intuitive interface, called the Template Register, where the physician defines which vital signs will be used, their values, relational operators (equal, different, higher, lower, higher or equal, lesser or equal) and the logical operators (and, or) to concatenate the different vital signs. With this, the practitioner creates a template for each situation of his or her specialty. This template gets a name and will be stored for later use on any patient.

Fig. 3.
figure 3

I2VSM template register screen

Full size image

Alerts Module

In this proposal, the role of alerts is preponderant, considering the characteristics of health professionals’ activities regarding mobility and long periods without the possibility of answering telephone calls. Alerts will be issued to the team responsible for the patient according to the set of rules and/or internationally accepted indicators. From a literature review, it was observed that it is internationally accepted the use of 2 services of alert sending that use the Internet as a medium: (i) PushOver and (ii) Telegram. And, if the Internet or the hospital’s local network is inoperative, the Short Message Service (SMS) service of the GSM (Global System for Mobile Communications) network will be used.

Pushover: it is a paid service – the cost is greatly reduced and the payment is made only once – of instant notifications for tablets and cell phones, which can be generated from a variety of sources. In more detail, Pushover is a platform for sending and receiving push notifications. On the server side, there is an HTTP API for receiving the requests, and on the opposing one an application where the professional receives the alert and stores them for offline visualization [29].

To consume the Pushover API, the python-pushoverFootnote 1 library is used. Listing 1.1 shows an example of sending alerts in the Python language, using the python-pushover library.

figure a

Telegram: it is a fast, simple and free messaging application. It functions as SMS and email combined, and can send photos, videos, and files of any kind. It provides an API where alerts can be sent to the medical team [36].

Telegram main characteristics are: (i) the messages are strongly encrypted and can self-destruct; (ii) Telegram allows the access of the messages from several devices; (iii) Telegram servers are scattered around the world for security and speed; (iv) has free open for all API and protocol; and (v) is free of charge, without ads or a subscription fee. This service allows the physician to respond to the alert, thus notifying the hospital that they received the message and, if he or she wishes, to send procedures for the staff to perform until their arrival.

Listing 1.2 shows an example of sending an alert using the Telethon-aio libraryFootnote 2.

figure b

SMS Gateway: service designed to provide alerts using the cellular telephone network, as there may be a lack of internet connectivity, either due to a problem in the backbone or even in the internal network of the hospital.

The SMS Gateway service of the I2 VSM architecture employs the embedded ESP32 NodeMCU. Also used is the SIM800L, a Quad-Band GSM/G-PRS transceiver (GSM 850, EGSM 900, DCS 1800 and PCS 1900), which works on the 850 MHz, 900 MHz, 1800 MHz and 1900 MHz frequencies, and accepts a micro-SIM card, allowing any microcontroller or microprocessor with a Universal Asynchronous Receiver/Transmitter (UART) port to communicate over the GSM network of its choice. The SIM card (subscriber identity module) is a smart card-type printed circuit used to identify, control, and store data from GSM technology cellphones. It usually stores data such as subscriber information, schedules, configurations, contracted services, SMS and other information.

To use the ESP32 with SIM800L, it was necessary to use the original MicroPython variantFootnote 3, called MicroPython LoborisFootnote 4. Originally developed for ESP32 that have a pseudo-static random-access memory (PSRAM), these can be used in any ESP32. The choice by this variation of MicroPython was made on account of containing a native library for access to the SIM800L. The communication between the ESP32 and the SIM800L is based on its General Purpose Input/Output (GPIO). Table 2 shows the GPIOs used in communication between the two chips.

Table 2. GPIOS
Full size table

Using the Loboris MicroPython native library, the alerts are sent through the code shown in Listing 1.3

figure c

Figure 4 shows examples of alerts received using the three services provided by I2VSM.

Fig. 4.
figure 4

Example of alerts sent by I2VSM

Full size image

Web Visualization Module

The Web Visualization Module is responsible for all the I2VSM’s visual interface. Their functions go from the login routines to the patient dashboard views and screens that show important data.

The Web Visualization Module was divided into smaller components, as shown in Fig. 5. These are Authentication, Logs, Data Storage, Web Front End, Cloud Connector, and Administration and Configuration.

Fig. 5.
figure 5

Architecture of the Web Visualization Module

Full size image

Authentication: this component is responsible for the authentication of I2VSM users. Access to the system occurs in 3 ways: (i) Using a password stored in the database; (ii) via the SMTP protocol of an e-mail server; and (iii) using the Lightweight Directory Access Protocol (LDAP) protocol to obtain credentials from an Active Directory domain.

Logs: in the Log component, the logs of all events occurring in I2VSM are written. As I2VSM stores sensitive data [17], a method is necessary to track user activities for audit purposes, if necessary. Thus, this module was designed to record the logs of all the events that occurred in the I2VSM.

Cloud Connector: the Cloud Connector module connects to the Amazon cloud service called AWS IOTFootnote 5. AWS IOT is a suite of cloud services geared to IoT applications. I2VSM publishes data from the “Environmental Interoperation Block” in the AWS IOT. The Cloud Connector component uses AWS service variables to process data, make analyzes, and generate charts for dashboards used for better visualization by the user.

Web Front End: the Web Front End component is responsible for the user interface. In this component are all the screens that will make the interaction between the final users and the I2VSM. They contain the registration of medical templates screen, patients’ registration screen, histories of vital signs history screen, among others. This component is also responsible for consuming the AWS API via the MQTT protocol, whose data will be used in dashboard assemblies.

Administration and Configuration: in the Administration and Configuration component, all the parameters necessary for the I2VSM to function are inserted. In this component are established the users’ credentials and their access levels. It also has screens for registering variables used at run times, which avoids changes in the source code at every exchange of hosting server, for example.

CIR

It is the Context Information Repository that we already used in the EXEHDA middleware to store the contextual information. This repository explores a relational database model.

CIR is responsible for the data persistence that the Web Visualization Module shows to users. In this repository are stored the contextual data of the users, their templates, visualization interfaces, as well as the I2VSM configuration parameters. Besides, we also store the vital signs of the patients and the situations identified by the processing of the rules. Relational database easiness such as views, stored procedures, and triggers are used to make access to data faster and more reliable.

6 I2VSM: Evaluation

In Brazilian hospitals, it is common practice to measure vital signs when the nurses change their shift, which occurs every 6 h. In the MIMIC-III database, the collections are carried out every 15 min. In order to adapt the database to the reality of the proposal, data outside these values were excluded: 00 h 00 min, 06 h 00 min, 12 h 00 min and 18 h 00 min. Data that is not in the EWS indicator was also suppressed from the table containing the measurements performed on the patients (CHARTEVENTS). In it, there were 5,131 possible measurements per patient, from which only Temperature, SpO2, Manual BP [Systolic], Heart Rate and Respiratory Rate were maintained - which are necessary for the indicators used; with these changes, the total number of registers went from 330,712,483 to 43,332,281.

In order to evaluate the functioning of the Vital Signs Processing Module, the MIMIC-III was adapted to the Brazilian reality and to the scope of this work, and the following alerts were configured: (i) EWS index is greater than 5 (called a yellow alert); (ii) EWS index is equal to or greater than 6 (called a red alert); and (iii) Alert configured by the physician, increase in heart rate, associated with fever. 1,000 patients were processed, generating 45 yellow alerts, 30 red alerts and 12 alerts with the parameters configured by the physician.

Table 3. TAM questionnaire responded by physicians
Full size table

In turn, the Technology Acceptance Model (TAM), a model proposed by [7], was used to evaluate health professionals. This questionnaire has the advantage of being specific for information technology and has a strong theoretical basis, in addition to broad empirical support. The model suggests that when users are introduced to a new technology, several factors influence their decision on how and when they will use it, notably: (i) Perceived Usefulness (PU) - and the degree to which a person believes that using a particular system would increase their performance at work; and (ii) Perceived Ease of Use (PEOU) - and the degree to which a person believes that using a particular system would be free of effort [7]. As such, a questionnaire was elaborated whose questions are shown in Table 3 using the Likert scale [18]: Strongly disagree; Partially disagree; Indifferent; Partially agree; and Fully agree.

In this stage of conception of I2VSM, the evaluation questionnaire developed was applied to 10 physicians from 3 hospitals in the city of Pelotas-RS, Brazil, presenting to them a demonstration of the I2VSM, with the alerts being generated from the MIMIC-III, using the EWS and also the parameters configured by them, which brought them closer to the real operation of the proposal. The applied questionnaire is presented in Table 3, and Table 4 shows the Likert Scale [18] resulting from the evaluation. The performed analysis indicates a promising result for the continuity of I2VSM.

Table 4. Results of perceived usability and ease of use assessment (TAM)
Full size table

7 Final Considerations

The I2VSM acquires the vital signs data of hospitalized patients, through commercial multiparametric monitors and via individual sensors. The acquired data are processed by rules that will define the EWS score, as well as by rules defined by the medical team. Based on the processing of these rules, alerts are generated so that the physicians are notified of events occurring with their patients. With the I2VSM, it is possible to anticipate diagnoses and procedures by the medical team, making possible a reduction in the hospitalization time. The results obtained from the physicians regarding the evaluation of perceived Utility and Ease of Use (TAM) are promising and point to the continuation of I2VSM research, as an approach that employs the EXEHDA middleware in providing approaches to health care. Among the expected future work is the development of a native application for smartphones, and the construction of an API for integrating with the hospitals’ legacy systems.