Scalable Architecture for Telemonitoring Chronic Diseases in Order to Support the CDSSs in a Common Platform

Abstract

Introduction:

In recent years, a variety of clinical decision-support systems (CDSS) have been developed to monitor the health of patients with chronic disease from far away. These systems are effective in overcoming human resource limitation and analyzing information generated by Tele-monitoring systems. These systems, however, are limited to monitoring a particular disease, which allows them to be used only in one specific disease. In reuses of these systems to monitor other diseases, we need to re-establish a new system with a new knowledge base. However, this type of healthcare system faces many challenges, including low scalability for change, so that, if we want to modify a health monitoring system designed for a specific disease to be used for another disease, these changes will be very substantial, meaning that, most components of that system should be changed. The lack of scalability in these systems has led to the creation of multiple health monitoring systems, while many of these systems share a common structure.

Aim:

In this paper, to solve the scalability problem, architecture has been presented that allows a set of CDSSs to be placed on a common platform for Tele-monitoring.

Material and methods:

In order to provide the proposed architecture in this study, we extracted the related concepts from the literature. The anatomical concepts used in these studies are as follow: users, transmitted data, patient data storage databases, data transfer network, and medical setting and the work is done in this setting. Finally, to design the proposed architecture, UML has been used.

Results:

The innovation of this research is to provide a scalable and flexible architecture, which as a platform, is able to monitor multiple diseases with a common infrastructure. In this architecture, all components are commonly used simultaneously without the interference of several CDSSs.

Conclusion:

Utilizing the proposed model in this paper, while reducing the setup costs and speeding up the launch of various remote monitoring systems, many rework in the implementation of these systems is also reduced.

1. INTRODUCTION

Chronic diseases are considered as the main challenges of healthcare institutions. According to the World Health Organization (WHO) statistics in 2010, chronic diseases account for 63% of all deaths in the world, and based on 2017 report, this figure has reached 70% and is even estimated to increase to 88% by 2020 (1). Patients with chronic illness may suffer from a worsening of their condition frequently and this can increase the risk of hospitalization. Early diagnosis in these patients can lead to successful interventions, patient improvements and cost reductions (2). Monitoring the status of patients with chronic disease is one of the main challenges of health information technology (3). To provide reliable information and early diagnosis, different technologies are used to collect and process data and facilitate analysis of patient data. These technologies have been named under the heading of telemonitoring, home monitoring, telehealth, remote monitoring or telecare (2). In recent decades, telehealth monitoring has grown rapidly as a subset of telemedicine. Telemedicine means the use of remote communication technologies to assist the transmission of medical information and services between the healthcare providers and patients (4). Telehealth monitoring systems are widely used in advanced countries to reduce the high cost of chronic diseases, to provide daily assessment of patients and the early diagnosis, and to prevent the exacerbation of patient condition (5). In reviews conducted on the effectiveness of telehealth monitoring systems, the reduction of patient referrals has been mentioned as one of the effective factors in reducing the cost of care. However, producing a large amount of patient data that requires careful evaluations can lead to unacceptable increase in workloads of physicians. Therefore, a combined decision support tools and telemedicine can be used as a possible solution to overcome human resource limitation and analyze generated data (6). Decision Support Telemedicine Systems (DSTS) is a combination of clinical decision support systems and telemedicine. A hybrid system that transmits information from the patient’s home to the health monitoring center and allows them to support decision-making and interpretation of their monitoring data is an example of DSTS (7). In recent years, to reduce the mortality rate and hospitalization and consequently the costs, and also to improve the quality of life of patients, a large variety of clinical decision-support systems for monitoring long-term health status of patients with chronic illnesses have been developed (8). AA Benyahia et al., have developed an ontology and CDSS-based platform as a solution for data management and diagnosis of anomalies in telehealth monitoring systems. This architecture has been developed by employing the modules of systems that collect auscultation sound (5). V Vives-Boixet al., have presented a decision support system to monitor the status of people with chronic disease based on the knowledge of experts. This system provides patients with the ability to freely and autonomously choose lifestyle changes that they are more likely to have (3). Estefanía Caballero-Ruiz et al., have provided a web-based clinical decision support system with a dual-layer CLIENT-SERVER architecture. This telemonitoring system identifies patients with gestational diabetes and prioritizes them on the basis of their metabolic status. This system automatically sends patients recommendations based on patient’s data analysis and rule-based database. However, recommendations based on the amount of insulin injections are initially sent to physician to decide what amount of insulin should be prescribed for the patient (9). B Nannings et al., have developed a conceptual model for Decision Support Telemedicine Systems. This model has three reusable templates for three medical tasks, including prevention, diagnosis, and monitoring. The proposed conceptual model is useful for gaining an insight into DSTS and its early design (7). S Kareem et al., have developed a combined Virtual Telehealth Framework and CDSS capable of reporting patient history at local level. The modules of this framework include a natural language processor, a module for extracting patient’s signs and symptoms, a decision support system, and finally an outlet of decision support system for disease diagnosis and drug prescription. The CDSS knowledge base in this system includes the knowledge related to common illnesses in order to answer nursing questions in the field of diagnosis or prevention. If the system is unable to diagnose a disease, a report will be sent to the physician who is based in the hospital via email. Updating the knowledge database of this system is done according to the responses that the physician gives to the requests (10). Benmimoune et al., have presented an ontology-based decision support system to improve patients’ lifestyles. This system has two main components. One part of the system collects patient’s lifestyle data by designing questions related to the history of disease, and the advice provider part offers individualized suggestions to change lifestyle. The system is integrated with the e-care home health monitoring platform to improve patient’s lifestyle, educate patient in accordance with the type of disease, and detect risk conditions (11). N Lasierra et al., have provided innovative two-layer architecture to monitor the status of patients remotely. This architecture is based on the web services, ontology, rule sets, and autonomic computing paradigm, and is used for data management. This ontology-based solution is a flexible and scalable architecture that addresses the main challenges of remote monitoring of patient’s health at home. It is also a solution for intergradations and transfer of data related to the technical and clinical issues (12).

In existing studies, the architecture of remote healthcare systems that are based on decision support systems is largely confined to a specific disease and it means these architectures are not scalable.

Electronic health has become very important in recent years and requires the development of new solutions (13). Scalable information systems are used as a solution that provides developing frameworks for medical research and development (14). Recently, two flexible and scalable approaches have been developed in the design of platforms and telemonitoring architectures (15). Flexibility is a feature of information systems that enables them to respond to predictable and unpredictable changes both internally and externally (16). Scalability is a function of the system that addresses a growing amount of work, so that, the services provided by the system are resistant to the changes of requests’ volume (17). Z Weiping et al., using ontology technology, have developed a context-based remote scalable platform. Design of a Context-Aware Middleware enables new sensors and different data formats to easily aggregate with this system (18). C Rivas et al., have developed an Open Platform for home-based healthcare services. This architecture offers the ability to add new services and aggregate external platforms. This solution is not dependent on software or hardware of a particular supplier, and easily permits the assembling of a variety of telemedicine devices in such a way that, each software provider and developer is able to add new healthcare services and modules to the platform (19). XM Zhang et al., have emphasized on the open and flexible capabilities in the telemedicine architecture that is based on Internet of things (IOT) and cloud computing (20).Therefore, platforms with flexible features can easily be developed to meet the needs of other diseases (21) Also, scalable architectures can also be developed to support a variety of telemedicine applications (22).

In spite of the very high performance of these architectures, these systems are single-use and the knowledge base of them contains the knowledge associated with one specific disease. Therefore, if this architecture is to be used to monitor the health status of other diseases, it should be re-established with the new knowledge base (the new decision support system). This issue will result in the creation of multiple island systems for monitoring the status of patients. Therefore, there is a need for an open architecture with a common platform that is capable of uploading CDSS for various diseases. Also, such architecture prevents the creation of multiple CDSS-based telemonitoring systems. The architecture proposed in this study is a scalable and flexible architecture that is used for the use of various CDSSs in remote monitoring systems.

2. MATERIAL AND METHODS

In this research, a literature review was conducted systematically which was focused on telemonitoring and CDSS keywords. The pubmed, Elsevier, and IEEE, Springer databases between 2005 and 2018 were used to access the articles.

Keywords such as; e-health, telehealth, telemedicine, open platform, flexible platform, service-oriented architecture, conceptual framework, telemonitoring, expert system, and CDSS were used to search for the related articles and a total of 1326 articles were identified. Finally, based on the title of the articles, we applied the following inclusion criteria:

• Articles should propose an architecture or platform for telemonitoring.

• Articles should use decision support systems in their architecture or platform.

Application of these criteria resulted in the inclusion of 73 full-text articles in our study. In the literature review, the focus was on the definitions, conceptual models, service-oriented architectures, and modules.

In order to provide the proposed architecture in this study, we first extracted the related concepts from the literature. The anatomical concepts used in these studies are as follow: users (patient, patient family, physician, healthcare team) and their related sites, transmitted data (text, image, video), data collection tools (tablet, smartphone, sensor ...), patient data storage databases (EMR, PHR), data transfer network (Wifi, ZigBee, Bluetooth, GPRS), and medical setting and the work is done in this setting (diagnosis, treatment, training, prescribing). Finally, to display the proposed architecture, we used UML.

3. RESULTS

In order to create the architecture, a care protocol should first be designed. In the section A the care protocol that we used, along with the activity diagram are described. The interactive structure of the intelligent platform of telemonitoring with the proposed architecture is shown in the section B. Finally, the modules used in our architecture are described in detail in section C.

The care protocol used in proposed architecture

Patient data is collected by sensors or manually by the patient interface. The data are proportionate with the intervals that the physician has determined, and are sent to the server for storage and processing. If no data is sent within the time limits set by the physician, a SMS reminder will be sent to the patient. The SMS reminder is sent repeatedly as long as the patient enters a new data. The server, after verifying the data and store them in the database, automatically analyzes the data to determine the related CDSS. After determining the CDSS, patient data will be analyzed. The result of this analysis is to determine the patient’s condition in one of the two Normal or Alert status. The physician can have access to patient data at any time through the physician interface and is able to view patients’ status on a priority basis. This prioritization is done based on the patient status (Normal and Alert). The CDSS in the Alert mode displays the proposed prescription to the physician. After reviewing the patient’s data, the physician can approve the proposed CDSS prescription or prescribe his own recommendation. The final prescription (CDSS prescription or physician prescription) is communicated to the patient via the patient interface. If more information is needed for prescription therapy, the patient will be informed and coordinated to have face to face meeting with the physician through the patient interface. All events in this telehealth monitoring architecture, including physician and CDSS prescriptions, are stored as patient record in the database. Figure 1 shows the interaction between the different sections of the proposed architecture.

Figure 1. Activity diagram of proposed architecture.

Figure 4. Communication transmission module.

Proposed architecture

The proposed architecture (Figure 3) has three layers: User Base, Function Baseand Data Base. In the user base layer, users who include physician, healthcare team, patient and system administrator, connect to the server through the client interface. A user-based interface can be installed on a smart device (tablet, cell phone) or be presented as web-based (Figure 2).

Figure 3. Proposed architecture.

Figure 2. The system structure of the smart monitoring and interactive platform.

The database layer has a database where physiological data is stored along with the physician’s prescriptions, diagnosis and recommendations of decision support system. Function base layer contains the main architectural modules provided in section C.

Modules

The proposed model contains five modules: Membership management module, communication transmission module, notification module, CDSS setting module, and supervisor module.

Membership management module

The components used in this module include:

Registration: This section allows user to register a patient, a physician and a healthcare team. Also, the disease and its related symptoms are determined by the physician for monitoring for each patient.

Checkup period: In this section, the intervals in which patient data should be collected and sent are determined by medical staff.

Rule selection: After registering the patient’s detail and selecting the disease and its related symptoms for telemonitoring, a CDSS related to that disease will be determined along with the rules that are proportionate with the symptoms selected by the physician.

Communication transmission module

This module has two functions to ensure that data aggregation tools are attached and data are sent. Currently, a wide range of remote transmission technologies, such as Bluetooth, Wi-Fi, Zig Bee, and RFID, are used (23). Selecting any of these technologies at the time of implementation depends on effective factors such as; power consumption, interference, and real-time data. In this architecture, the XML format was used to exchange patient data. The reasons for using XML include (24):

The label elements of the content used in XML documents are independent of communication protocols. Therefore, XML documents are suitable to be used in Internet and public data transfer networks.

XML is a great choice for editor’s application, middleware, and application tools, which greatly enhances the efficiency and financial savings related to the managing and developing of information systems. Users in this architecture can send and request patient data, view patient status, and receive prescription and notifications at any location that has GPRS and Wi-Fi coverage.

Supervisor module

This module, as the system core, is responsible for determining the CDSS associated with the data received from the client interface. By using this module, the proposed model can have the scalability and flexibility needed to upload more than one CDSS. This innovation in the proposed architecture, contrary to previous telemonitoring architectures that were limited to one context, makes it possible to provide a context-aware architecture in which CDSSs monitor patient’s condition based on the context information received from the patient. In the proposed architecture, during the patient data exchange from the patient interface to the server, meta data is added to the XML file, by which the supervisor can determine the CDSS analyzer of the patient data. This process is performed by the XML parser in the supervisor module. Finally, the information is sent to the relevant CDSS by the CDSS detection function for analysis.

CDSS setting module

This module is included in the architecture for defining the CDSSs and Rules associated with each of them, which is done by two functions of add CDSS and update rules. The Medical Informatics specialists, as the system administrators, are responsible for the uploading of CDSS through the administrator interface. Each system is easy to use after being uploaded by the medical staff.

Notification module

The results of patient data analysis are communicated to the medical staff by the physician notification function in this module. Patients will be informed of physician’s prescription, recording information and requesting an appointment by the patient notification function.

4. DISCUSSION

CDSS-based telemonitoring systems are an emerging technology that is rapidly developing. The explosion of information and the need for communication between healthcare providers are the starting point for such systems. However, this type of healthcare system faces many challenges, including low flexibility for change, so that, if we want to modify a health monitoring system designed for a specific disease to be used for another disease, these changes will be very substantial, meaning that, most components of that system should be changed. The lack of flexibility in these systems has led to the creation of multiple health monitoring systems, while many of these systems share a common structure. In this paper, to solve the flexibility problem, architecture has been presented that allows a set of CDSSs to be placed on a common platform for remote health monitoring. By providing greater flexibility, this platform is capable of supporting the knowledge base of various diseases simultaneously. In this context, flexibility is achieved by providing a number of specific modules that are available in most remote health monitoring systems. By using these modules and adding the CDSSs of different diseases, we can monitor several diseases on a common platform. Utilizing the proposed model in this paper, in addition to reducing the setup costs and speeding up the launch of various telemonitoring systems, we can avoid many re-works in the implementation of these systems. This open architecture provides an opportunity to develop a variety of technologies such as Internet of tings and cloud computing. Moreover, it provides the ability to support a variety of knowledge base such as ontologies. It is also possible to connect this architecture to the electronic health record in order to integrate patient health information.

Funding Information:

This research received no specific grant from any funding agency in the public, commercial, or not-for-profit sectors

Author’s contribution:

All authors were included in all phases of preparing this article. Final proof reading was made by the first author.

Conflict of Interest:

The authors declare that they have no conflict of interest