The Development of the Vital Signs Tele-monitoring System for the Elderly by Using ‘UML’ Language and the Interoperability Standard ‘Continua’

2.1. Medical Telemonitoring

The purpose of telemonitoring is to allow telemetric recording, usually at home, of physiological parameters or targeting the environment or the behavior of a patient and, then, to transmit them to the concerned practitioners who interpret them remotely [5].

Medical telemonitoring allows physicians to make remote decisions about patient care and possibly delegate actions to another health professional.

Medical telemonitoring has become an important element in medical systems for the elderly, postoperative treatment and management, and chronic disease [6].

Among its benefits, one could list a few:

- Improve the immediate medical follow-up at home of the elderly non-autonomous and/or with chronic pathologies to guarantee their safety;

- Promote their home support and allow them to live at home in a familiar environment, independently;

- Faster doctor interventions when needed;

- Avoid the prolongation of certain hospitalizations and anticipate the return to the home. This results in a reduction of the costs thanks to monitoring, which can be done outside the hospital;

- Prevent possible hospitalization. Provide personalized support to the person concerned and involve the family in the care process so that the patient feels more reassured;

- Response to growth in the number of seniors and the needs of patients living in remote rural areas.

The functions that can theoretically be activated by a remote monitoring system can be separated into three types [7].

- Remote telemetry: The sensors on the patient's medical technical assistance device are continuously “tested” via home computer equipment. As soon as there is a problem, the host is notified and a technical team immediately intervenes to adjust or repair the sensor or equipment.

- Tele-alarm: As soon as the sensors detect a critical situation of the patient or the equipment, an alarm is transmitted instantly to the host center which, immediately in return, teletests the devices and triggers the alarm with the attending physician, the first service care or staff of the host according to the type of the alarm.

- Remote monitoring: It remotely collects information on the operation of the equipment and on the state of health of the patient. Thus, if some patients do not respect, for various reasons, the durations of the treatment, this type of telemonitoring allows in particular to quickly informing the prescribing physician [8].

2.2. Vital Signs Monitored

The project opted for five vital signs and the body mass index.

Heart rate: It is defined as the number of heart beats per unit of time (usually the minute). It is a crucial vital parameter. A normal resting heart rate for an adult ranges from 60 to 100 beats per minute. A heart rate higher than 100 beats per minute at rest can be a tachycardia. Heart rate lower than 50 beats per minute corresponds to bradycardia. Taking certain drugs can cause acceleration or a slowing down of the rhythm. In addition, smoking, alcohol and caffeine contribute to the increase in heart rate while “beta blockers” reduce it strongly.

2.2.3. Glycemia

It refers to the level of glucose (sugar) in the blood and is usually expressed in grams per liter of blood. When it is below 0.7g/l, it is called hypoglycemia. Normal blood glucose should be between 0.70 and 1.10 g/l. Between 1.10 and 1.26 g/l is called hyperglycemia and glucose intolerance is suspected in such a case. Above 1.26 is referred to as diabetes. These values ​​are measured on a fasting blood test Pulse oximetry or SpO2 oximetry: It is a non-invasive and painless test that measures the level of oxygen saturation in the blood. Between 95 and 98%, oxygen saturation is normal and healthy; Between 85 and 94%, it corresponds to Hypoxia. Less than 85% is severe Hypoxia. Oximetry is used to monitor people who have all types of risks that affect oxygen in the blood, namely Chronic Obstructive Pulmonary Disease (COPD), asthma, pneumonia, lung cancer, anemia, heart attack or heart failure, congenital heart defects.

Body Mass Index (BMI) is a simple index of weight in relation to height. It is calculated using (1):

(1)

A high BMI can be an indicator of high body fatness. BMI can be used to screen for weight categories that may lead to health problems [9].

Table 1.

-	Systolic (mm Hg)	Diastolic (mm Hg)
Hypotension	<90	<60
Normal tension	90 – 119	60 – 79
Prehypertension	120 – 139	80 – 89
Hypertension level 1	140 – 159	90 – 99
Hypertension level 2	160 – 179	100 – 109
Hypertensive crisis	>= 190	>=110

2.3. Standardization of Remote Monitoring Systems

With the Internet of Things (IoT) and data sharing, e-health is able to meet the needs of healthcare professionals and patients. In terms of medical surveillance, these technologies make it possible to better monitor health status through better patient knowledge (access to the file and the medical history, knowledge of its physiological parameters via the health IoT, etc.). Collecting data from different medical devices associated with a patient at one location and sending that data to the doctor or other place in an integrated format is challenging. Therefore, a mechanism is needed to combine this data from various medical devices associated with a person and transmit them to the relevant system via the Internet. Sharing dematerialized documents between health professionals to follow a patient is the scope. However, being able to read these documents without problems on your computer is a challenge and it is precisely the purpose of the interoperability of health information systems. To enable this communication, it is therefore necessary to use a common language. By taking digital issues into account, these new regulations will enable e-health to develop in a serene and transparent manner. Nowadays, medical devices are more compliant with the norms and standards in force. This is the reason why the designed solution is developed according to the standards and guidelines ‘Continua’. [10]

2.4. Tools and Languages Used

The design of this project is based on the object concept, and is articulated around Unified Modeling Language (UML) [13]. UML, therefore, provides professionals with diagrams to represent the software to develop its operation, its start-up, and the actions that can be performed by the software. We also used the WampServer. It is a Windows-based web develop- ment platform for dynamic web applications using the Apache2 server, the PHP scripting language and a MySQL database. It also has PHPMyAdmin to manage databases more easily. Languages used are HTML, CSS, PHP, MySQL, Javascript, and Bootstrap.

The architecture of the designed system is defined as in Fig. (3); the sensors acquire the data periodically then transmit them to the gateway, which in turn makes them go back to the web server. The data is retrieved from the web server and stor- ed in a database. Depending on the case, an alert could be sent following the analysis of the data and the detection of cri- tical situations. Viewing the patient’s history is also possible.

The architecture is multi-level and end-to-end: It is the set of connected medical devices and sensors that communicate the vital signs of the patient. The gateway is used to link the sensor network to the web server. The data are, therefore, not directly transmitted but translated to ensure continuity. The web server with the different interfaces from which health professionals can access patient data, adjusts therapy, view alarms, exchanges messages with other users. This server performs processing on each new data received, analyzes it and then displays it. The database server allows secure access to the database. This server consists of a database storing all relevant information about the users: Demographic data, physiological data, patient record alerts and generated notifications as well as messages.

This section is devoted to the analysis and design of the medical telemonitoring management system. We identified the different used cases as well as the actors. Then, we detailed the system specifications while defining the functional and non-functional requirements. Finally, we presented the general and detailed architecture of the designed application.

2.4.1. Use Case Diagram

A use case diagram is used to give an overall view of a system to formalize needs in a graphical representation simple enough to be understandable. Therefore, it allows identifying the major features of a system. It presents the actors involved in the system as well as the different use cases. An actor represents a role played by an external person or by a process that interacts with the system. The actors of our system are:

- The administrator; he has access to all features,

- The Doctor; he can from this platform manage the list of his patients. It can also access other interfaces,

- The Patient: he has no access to any page except the home page. These different actors are represented in Fig. (4).

2.4.2. System Specification

In this part, we detailed all the features that the system must be able to perform. Indeed, the achieved application meets the following functional needs.

- Authentication; each user (physician, administrator) has a user name and a password that allows him to verify his identity, to allow access to this entity to resources safely.

- Management of user accounts; this functionality is provided by the administration of our system, which is able to manage all users.

- Control of doctors; the administrator must associate an account for each doctor wishing to join this application while associating the specific information.

- Verification of doctors; the administrator must verify the identity of each new user from the number of his professional health card (CPS), before validating the creation of the accounts.

- Display of the medical history of the patient; the doctor can consult the medical history of the patients he follows in deciding on their state of health in a better way.

- Sending notification; the system displays notifications with information about the health status of patients.

In addition to the important features mentioned above, non-functional needs are important since they indirectly affect the result and system performance. The developed solution takes into consideration some additional constraints and meets the following requirements:

- Speed: The application provides efficient and consistent results in an insignificant time due to user requests since the display speed has a strong influence on the efficiency of the application

- Usability: The application is easy to use with consistent interfaces, visual appeal and the speed of obtaining information.

- Reliability: The results provided by the application must be reliable and effectively reflect the state of the database at the time of its query, i.e. updated data.

- Availability: The application is available at all times and easily accessible for use by any user.

- Extensibility: Any improvement or modification is easy to achieve, so this application ensures a degree of extensibility to any developer wishing to contribute.

2.5. Needs Analysis

Initial class diagram is a static representation of the elements that make up a system and their relationships. Each application that implements the system is an instance of the different classes that compose it, (Fig. 5).

The sequence diagram represents the chronological succession of the performed operations by a user: entering data, consulting data, launching a treatment, etc. It indicates the objects that the user can manipulate and the operations that move from one object to another, (Fig. 6).

The diagram, shown in Fig. (6), describes the possible scenarios when registering a user (doctor). Indeed, the user requests access to the site. The system displays the requested interface with an empty form. The user fills the fields. The system verifies the validity of the entered data. A series of tests must be performed (already existing username, password verification, CPS number).

The diagram, shown in Fig. (7), describes the possible scenarios when identifying a doctor. The doctor requests access by entering their username and password. A verification test must be performed (existence and compatibility of the entered data). If the entered data is correct, then, it allows the doctor to access all the site’s interfaces. If the data is incorrect, the user must try again or leave the site.

The diagram, shown in Fig. (8), describes the possible scenarios when adding a new patient. The doctor requests access to the site. The system displays the requested interface with an empty form and the doctor fills out the form with the patient's demographic data. The system verifies the validity of the data. After the test, the data will be saved in the database.

Design: The use of the UML ensures the following design objectives:

- Formalize the design of the application. Limit many risks of errors.

- Gradually improve the working methods while preserving the modes of operation, (Fig. 9).

Hereinafter, we presented the conceptual phase, (Fig. 10), and the logic phase, (Fig. 11), of the design of the database.

A medical remote monitoring system involves the installation of sensors and devices near the elderly or patient. This equipment (e.g. blood pressure monitor, ECG, glucometer, etc.) is interconnected and allows the collection, recording of patient health data, storage and transfer to the concerned health professionals [2].