IoT + DBMS = Periodic Summary of the Health Status of Remote Patients ^†

Abstract

There is a growing number of frail patients whose health conditions require constant monitoring by physicians. Unfortunately, the budget restrictions of hospitals and the concomitant decision that patients should stay home require that this monitoring is to be carried out remotely. Today, Internet of Things (IoT) wearables are the most promising technology solution for sensing patients’ physiological values 24/7. These measurements need to be stored permanently and then processed in order to provide support to physicians in charge of making real-time clinical decisions consistent with the patient’s health status. This paper elaborates on the combination of the IoT and DBMS technologies. In detail, a PostgreSQL relational database stores patient-generated health data (PGHD), while a set of SQL views generates standard summary statistical indicators.

1. Introduction

With advances in mobile health technologies, patients are able to generate more health-related data than ever before. Therefore, the best way to provide adequate assistance to the elderly consists of resorting to solutions based on the Internet of Things (IoT). PGHD can consist of clinical measurements of blood pressure, heart rate, and oxygen saturation taken by the patients themselves or their caregivers over 24 h. PGHD are a continuous stream of data. Their use in clinical practice allows for monitoring the value of vital parameters of remote, fragile patients. Interesting IoT systems for this purpose have already been proposed [1,2,3,4]. The relevance of remote IoT health monitoring systems was reaffirmed by Narasimharao et al. [5] in 2023.

Previous studies have proposed solutions based on the IoT that allow physicians to see PGHD graphically on a mobile phone almost in real time [4]. In the present paper, another use of PGHD is proposed. We assume that the PGHD are collected in a database. The objective is to provide physicians with summary statistics based on physiological measurements over a given time interval (e.g., daily, weekly, etc.). A Database Management System is the best software technology that suits such a need. In detail, a PostgreSQL relational database suitable to collect PGHD has been designed and implemented; the database is enhanced by a set of SQL views which compute standard summary statistics. The solution is parametric, so the interval of investigation can be customized according to the physician’s requirements. Adding to the graphical view of PGHD, summary statistics about them enrich the basis on which physicians can make data-driven clinical decisions.

The implementation of an effective long-term care service implies that different channels are adopted in a consistent and coordinated way. A database collecting PGHD is one of those media. In 2022, Siddik et al. [6] pointed out that the combined usage of the IoT, cutting-edge computing (mostly cloud computing), DBMSs and visualization tools is the best strategy for implementing a modern system for the management of a large number of illnesses, while Kawu et al. [7] complemented the work of [6] by providing an up-to-date survey on the state of the art and the open issues of the integration of the diverse sources of PGHD into already existing health databases.

In [6], PGHD stored in a database are retrieved to be visualized in a dashboard in order to show the patient’s health conditions to physicians. Our proposal emphasizes the need to process PGHD to extract statistics over a given time interval. These statistics complement the information that physicians can derive by looking at the instantaneous values of physiological parameters, thus enriching the basis on which they make clinical decisions. As far as we know, no previous studies have focused on the same issue.

The remaining part of the paper is structured as follows. Section 2 provides an overview of the structure of the database and the summary statistics taken into account, while Section 3 details the proposed solution by creating a sample database and by showing the SQL code of a set of views that compute the summary statistics. Section 4 ends the paper.

2. Materials and Methods

2.1. The Database

Databases containing PGHD are a precious intangible asset that allow the implementation of quantitative methods as an alternative to qualitative ones. By querying these databases, it is possible to build summary statistics over fixed periods of time.

Figure 1 shows the database conceptual schema. As a DBMS, we adopted the open-source PostgreSQL, ver. 14. PostgreSQL is an object-relational system that offers a robust support to the JSON data type. The latter allows us to store unstructured data in the database as well. A certain degree of flexibility is highly recommendable in our case, because it will help to deal with the attributes p_description and m_value, which are containers of manifold fields.

Figure 2 shows the PostgreSQL’s SQL/DDL scripts of the two tables of the designed database.

2.2. Summary Statistics

Summary statistics come under the umbrella of descriptive statistics. Summary statistics consist of a set of metrics that provide insights into the behavior of a data set. To support physicians in performing a “data-driven” evaluation of the health status of a remote patient, the following metrics are provided to them: minimum (min), maximum (MAX), range (range), average (AVG), standard deviation (STD), and coefficient of variation (CV = STD/AVG). Standard deviation is defined as the square root of the variance. Variance measures how far each number in a data set is from the average. A low variance indicates that the values tend to be close to the mean. A variance equal to zero means that all the values in the data set are equal to the average. In turn, standard deviation is a measure of the amount of variation or dispersion of a set of values. A low standard deviation indicates that the values tend to be close to the mean (also called the expected value) of the set, while a high standard deviation indicates that the values are spread out over a wider range.

Physicians know very well that it is one thing to calculate the standard deviation from a data set and another to interpret it and find out what it is telling us about the data set. The value of the CV is relevant because it tells us if standard deviation is low or high, since it links the standard deviation to the mean. In simple words, the CV allows us to state if the STD is high or low. A CV < 1 means that the STD is low (it also tells us that the STD ≤ AVG), while a CV > 1 means that the STD is high (it also tells us that the STD > AVG).

All physicians are able to interpret the values of the six metrics mentioned above once they are made available to them. This is the role played by the solution detailed in this study.

3. Results

3.1. A Sample Database

As a proof of concept of the method adopted in this study, a database was built with five patients and 24 measurements for each of them. The field m_description comprises the following data: FName, LName, YoB (Year of Birth), Weight, and Height, while the field m_value collects data about temp (temperature), HRate (heart rate), SPO2 (oxygen saturation), SBP (Systolic Blood Pressure), and DBP (Diastolic Blood Pressure). This set of human physiological parameters is systematically taken into account in studies concerning the monitoring of patients’ health status (see, for instance, [8,9,10]). The measures were taken over the 24 h of a single day (6 June 2023); moreover (without loss of generality), the timestamps are the same for each patient (i.e., ’2023-06-01 00:01:01’, ’2023-06-01 01:01:01’, and so on). Figure 3 shows the content of the patient table and the SQL query that displays it, while Figure 4 shows the measurement data set.

3.2. Discussion

As stated above, the focus of this paper is not on a discussion of the actual measures in the PostgreSQL database, nor on the values of the summary statistics inferable from them. In contrast, the emphasis is on underlining the ways these computations were accomplished and, at the same time, on what the output to be returned to the physician looks like. SQL is the tool made available by DBMSs for performing computations. Figure 5, Figure 6 and Figure 7, for example, show the query that returns the summary statistics about SPO2 for patient p_code = 1.

This query performs a relatively complex computation in a way that is simple thanks to the use of the Common Table Expression (CTE) construct. CTEs work as virtual tables (with records and columns) created during the execution of a query, used by the query, and eliminated after query execution. CTEs often act as a bridge to transform the data stored in source tables to a format suitable to the end user.

Table 1. The summary statistics for patient p_code = 1.

p-code	Statistic	Temperature	HRate	SPO2	DBP	SBP
1	min	36.4	60.0	86.0	72.0	111.0
	MAX	36.9	78.0	94.0	79.0	129.0
	range	36.9	78.0	94.0	79.0	129.0
	AVG	36.9	78.0	94.0	79.0	129.0
	STD	36.9	78.0	94.0	79.0	129.0
	CV	0.003	0.074	0.024	0.024	0.049

collects the values of the six statistics taken into account in this study for patient p_code = 1. These values were computed by running the query SELECT * FROM ViewOfViews; the latter is defined in terms of five views (Figure 8). An examination of the statistics in Table 1 offers the physician an overview over a fixed time interval of the state of health of the remote patients for which they are responsible.

To obtain summary statistics about patients, the physician has to connect to the server hosting the PGHD and authenticate themself. To make the access to these data easier, it is helpful develop a WEB application exposing a simple GUI. This step is out of scope of the present short paper.

4. Conclusions

This paper elaborated on the combination of IoT and DBMS technologies from the perspective of implementing an effective long-term care service. The SQL statements necessary for implementing the solution are shown. The stakeholders of this study are IT professionals who can customize our solution to their actual needs.

The workflow of the interaction of the physician with the database comprises two steps:

• First, they choose the code of the remote patient to be monitored (let us say, p_code = 1);
• Then, they enter the time interval that the query processor has to take into account in the computation of the summary statistics of the values of the following vital parameters for the selected patient: temperature, heart rate, oxygen saturation, Systolic Blood Pressure, and Diastolic Blood Pressure.

At that point, the DBMS performs the computation. Technically, the values of the statistics are inserted into a PostgreSQL temporary table (it is known that temporary tables are automatically dropped at the end of an SQL session).

Before each of the 30 summary statistics in Table 1 (let us denote the value of a generic statistic as ss_value) is written in the database’s temporary table, a PL/pgSQL trigger is run. The trigger function that implements the trigger compares ss_value with a threshold value for that parameter. Such a value is entered by the physician who should know its ideal value according to the patient’s (bio)medical and non-(bio)medical characteristics. Each time a potential critical situation of the health status of the patient is identified, the trigger function returns an alert to the physician.

The SQL which implements the alarms has been omitted because of the six-page limit.