Keywords

1 Introduction

Diabetes Mellitus (DM) has become a significant health challenge, reaching alarming numbers of people with the diagnosis. It is estimated that in 2019, the number of people with DM around the world was 463 million and the projection for 2045 is that this number may reach 700 million people [1].

The number of people with DM in Brazil follows the same worldwide trend. Accordingly to epidemiological data from the Brazilian Society of Diabetes [2], between 2006 and 2018, the prevalence of men and women with DM older than 18 increased by 54% and 28%, respectively. In 2019, the number of Brazilians aged 20–79 with DM was 16.8 million. Also, Brazil is the third country with the highest health expenditure related to DM [1].

The studies and monitoring of the disease make it possible to carry out control and apply precise measures for the treatment and better quality of life. For a person with DM, control of blood glucose and cardiometabolic risk factors, medication management, and early monitoring of complications with an organised health system reduce the acute and chronic complications of the disease and prolong the lives of these individuals [3].

Other countries report having diabetes monitoring records but do not provide sufficient information about their outcomes. In low-income countries, few vital reports are recorded, and the reliability of data collection on diabetes is dubious and incomplete. Most data on diabetes derived from monitoring systems in most countries are sparse and inadequate, and most countries do not have a system to evaluate national actions or programs [4].

In Brazil, the National Health Data Network (RNDS) was established in 2020 as the national platform for interoperability in the healthcare system; this interconnectivity environment is to be fully implemented by 2028. In addition to being a structuring project of the Connect SUS, the RNDS is a Federal Government program to carry out the digital healthcare transformation in Brazil, aiming to promote the exchange of information between the Health Care Network, allowing for the transition and continuity of care in public and private sectors [5].

The implementation of an interoperable healthcare system requires a standard protocol, and the RNDS has defined the HL7 (Health Level Seven) FHIR (Fast Healthcare Interoperability Resources) to exchange information [5].

Considering the increasing number of people with DM and the current restructuring of the health data system in Brazil, the Institute of Biomedical Engineering of the Federal University of Santa Catarina (IEB-UFSC) is developing a project to record and monitor data from patients with DM, using a system called SDC-X (Screening for Diabetes Complications).

The article presents the structuring of the SDC-X project, the use of an HL7 FHIR server complemented by the ElasticSearch server, and the development of a multi-user web platform to present the data to be monitored, seeking to comply with the current Law of Data Protection (LGPD) in Brazil.

2 Materials and Methods

2.1 SDC-X Project

The SDC-X project is a system to assess patients with DM from different locations through data collection, storage and analysis. The “X” of the acronym represents the various data acquisition modules and may represent data related to the cardiovascular, visual, and other physiological systems.

The SDC-X comprises four modules (Fig. 1): the Acquisition Module, Concentrator Module, Storage Module, and Analysis and Interface Module.

The Acquisition Module consists of a set of equipment for collecting vital signs. This data is then processed, analysed and sent to the server by the Storage Module. The Storage Module contains the HL7 FHIR server that must receive the data and make it available to the Analysis and Interface Module through an API (Application Programming Interface). The Analysis and Interface Module then presents the data in different formats for different users.

Fig. 1. 
figure 1

SDC-X project comprises four blocks, where the Acquisition Module is essentially hardware, and the other 3 are software.

Full size image

Every module was developed for different researchers at the IEB-UFSC. The Acquisition Module has, until now, three hardware developed: X-Cardio, X-Eye and X-Esc. How these modules were developed and how they work can be viewed in [6,7,8]. These developments involve non-invasive measurements, but other relevant information is more significant to monitoring the DM and involves invasive measures, like Hb1A1c, HDL [9, 10], blood glucose and cholesterol [10].

The Concentrator Module is software installed in a computer, where the data are collected, processed, analysed and send to the Storage Module [6].

2.2 HL7 FHIR and ElasticSearch Servers

HL7 is a non-profit organisation credited with creating standards for sharing, integrating, exchanging and requesting electronic health information. The HL7 FHIR, built in 2011, is a standard that proposes to facilitate the exchange of information by combining web standards and focusing on implementation. It is structured in a data model that can be accessed via a URL via REST (Representational State Transfer), called “Resources” [11,12,13].

Access to the server must be performed through RESTful requests, and the responses are delivered in XML (eXtensible Markup Language) or JSON (Javascript Object Notation) formats through an API (Application Programming Interface) [11, 12].

The data store must be mapped to specific resources described in the HL7 FHIR documentation [11].

An ElasticSearch server is implemented to assist the FHIR server in more complex tasks. ElasticSearch is a free and open distributed data search and analysis engine for all data types, including textual [14].

2.3 SDC-X Interface

The web interface represents the Analysis and Interface Module of the project. This interface intuitively presents patient information and collected data through the Acquisition Module for different user profiles (e.g., patient, clinician, health manager) [15].

The interface is developed using the MVC (Model-Views-Controller) design pattern and PHP as the programming language. This design pattern structures the project in 3 layers, which helps to reduce coupling and promotes increased cohesion in the project's classes, facilitating code maintenance and reuse [15].

Within the project structure, the three layers are separated by tasks. The Model layer communicates with servers and databases; the interface, i.e., what the user sees, is created by the Views layer, and the Controller is the layer that executes the user's actions. The communication between the layers is represented in Fig. 2, and the arrows represent information exchanges between layers [15].

All users go through the interface module, as shown in Fig. 3. The user accesses the platform through a login and password system using his previously registered profile. The servers return with the data to be presented through the interface.

Fig. 2. 
figure 2

Diagram of the MVC model. The user interacts with the system through a browser, interpreting the View layer. The Controller executes user requests through the browser and sends commands to the Model and View layers [15].

Full size image
Fig. 3. 
figure 3

SDC-X Project Analysis and Interface Module System Flowchart.

Full size image

The interface allows five user profiles: Administrator, Patients, Researcher, Practitioner and Manager. The data accessed in each profile follow a permissions rule verified by the Controller and Model blocks. The description of each user profile is presented below.

Administrator: It controls who can access the project interface.

Patient: This user only views their data.

Researcher: This user accesses the raw data, preserving patient identification. This profile allows to export and process of data as desired.

Practitioner: This profile is implemented for health practitioners who can consult direct information from patients.

Manager: This user has access to a series of analyses of the set of data collected. This profile is intended to assist in obtaining information from the health system, thus allowing the establishment of goals and solutions in an informed and accurate manner.

3 Results

All tests were performed locally, where the interface application was executed through the XAMPP server (version 3.3.0), an open-source server developed by Apache Friends. Furthermore, for the HL7 FHIR and ElasticSearch servers, Docker software (version 4.3.0) was used, an operating system-level virtualisation system that delivers software in packages called containers.

3.1 FHIR Server and Data Usage

Dummy data were used by a Synthetic Patient Population Simulator called Synthea. This simulator generates realistic data, but not from patients in different formats, including the FHIR [16]. One thousand simulated patients were developed for the tests, and 824 had diabetes, which was included in the database.

The open-source server HAPI (HL7 Application Programming Interface) was used, a complete implementation of HL7 FHIR in JAVA. This server is supported by the UHN (University Health Network), and its team of programmers is recognised for producing open-source software related to projects integrated with HL7 [17].

The HAPI FHIR server uses the HL7 FHIR R4 version and allows all access to FHIR Resources through RESTful API and the freedom to create Resources to suit the data formats of SDC-X projects.

3.2 SDC-X Interface

The interface implements login and password verification, and a MySQL database was created to store information from the users of the interface and thus verify if the login data are compatible and determine their registered profile.

Each profile has different access to the interface, meeting security and data protection criteria.

The profile registered as an Administrator has two screens, one to accept or block users from the interface and another to apply a data visualisation blocking rule through the Practitioner profile. This rule aims to comply with paragraph 5 of article 7 of Law No. 13,709 of August 14th 2018, which says that the data controller must have consent from the data owner in case of sharing information [18].

The Patient profile aims to comply with articles 6, 9 and 18 of Law No. 13,709, which determines free access to subjects’ data [18]. This last aspect is covered through pages within the patient profile interface, which allows consulting all the information and contact for questions.

The Researcher profile user can see the data, but patients are anonymised, e.g., the name is replaced by the id of the database. In this profile, it is possible to download data, in JSON format, every 20 patients, as the interface loads 20 patients per page. The Researcher's profile can also see patients’ information and download their data individually for analysis. It is also possible to filter patients on the patients’ page, which performs a series of rules for the server to return the desired data.

The Practitioner profile contains a screen where you can search for a specific patient through their identification document (e.g., CPF); then, the server returns the patient's data, and the Practitioner has access to all the patient's information necessary to carry out a consultation and evaluate the patient. On the patient's profile screen, the Practitioner sees the exams performed previously (e.g. blood glucose, cholesterol, weight) in a graphic format. The Practitioner can also see all exams, results, and medications prescribed. Figure 4 details the patient profile page for a Practitioner.

The Manager profile contains global but not individualised patient information. So, to acquire this information, a bunch of requests to the server are needed, overloading the server, and slowing the web page. Therefore, the ElasticSearch server is implemented to minimise this issue.

Fig. 4. 
figure 4

Interface for the Practitioner profile viewing a patient's data. (a) Menu of interface screens. (b) Patient identification data. (c) Patient data navigation menu. (d) Graphs of patient exam data.

Full size image

ElasticSearch (version 7.9.2) was implemented in a container using Docker software, working in parallel with the FHIR server, helping with more complex requests. So, the Concentrator Module must send the data to the FHIR server and the ElasticSearch server, and both are the Storage Module. As the data in ElasticSearch is not intended for independent visualisation, it does not need to be identifiable; the Storage Module must anonymise the data when sending it to ElasticSearch.

Therefore, the SDC-X flowchart can be more understandable in Fig. 5. The data are collected by the hardware composing the Acquisition Module, manipulated by a practitioner. These data are processed by a computer with software that comprises the Concentrator Module. These data are analysed and sent to a RESTful API to the servers, composed of the FHIR server and ElasticSearch, forming the Storage Module. The Analysis and Interface Module can access these data by the RESTful API and show the application in any browser. This application web can be accessed by everyone with internet and an account in the SDC-X project.

Fig. 5. 
figure 5

The data is collected by the equipment of the Acquisition Module and sent to the Concentrator Module that analyses and processes the data. The FHIR protocol sends the data to the FHIR server, anonymises the patients and sends it to the ElasticSearch server. The users can visualise the data using the Analysis and Interface Module.

Full size image
Fig. 6. 
figure 6

Statistical data is presented for the Manager profile based on the collected data. The information on this page are processed through ElasticSeach, which provides a more elaborate and faster query to the data than the FHIR server.

Full size image

The Manager profile allows one to view the data together; it is not allowed to see the data individually and can create policy guidelines for managing diabetes. Figure 6 displays the Manager profile statistics page.

4 Discussion

The HAPI FHIR tool was excellent for implementing the HL7 FHIR server. In addition, the ElasticSearch software proved to be a complementary tool, improving the processing time of the information.

The interface implementation presented an intuitive development when using the MVC method, allowing agile changes, and its modularity allows adding new functions as the SDC-X project develops.

The interface presented all the functions proposed in each profile, and only the Manager profile was implemented to use ElasticSearch requests.

It was observed that the rapid availability of data from diabetes patients, for the Practitioner profile, we have a quick analysis of the patient's history graphically and individually of the exams, which allows an agile and more accurate consultation.

The Researcher profile has permission to download data for other research, and the Manager profile allows for creating more decisive actions regarding diabetes.

The Administrator, Patient and the other profiles aim to comply with the LGPD in force in the country, and this project must be in constant development and revision to always be in conformance with the law.

This project was entirely implemented on the same machine, and new tests must be carried out through cloud implementation. Thus, more severe security measures must be implemented, meeting data protection protocols, anonymisation, secrecy, and carrying out safety reports as described in section X of article 6 of the LGPD.

The project so far focuses on diabetes mellitus. Still, there is a possibility of adding new developments, such as the insertion of laboratory markers and new equipment for monitoring other pathologies, including systemic arterial hypertension, autoimmune diseases and chronic diseases in general. In addition, with the help of EMG and EEG equipment, we can use the system developed to provide the follow-up of pathologies such as epilepsy, stroke and cardiovascular problems in general.

5 Conclusion

This work describes the implementation of a HAPI FHIR server in parallel with the ElasticSearch software and developing a web interface to complement the SDC-X project that aims to collect, store, treat, analyse and make available data from patients with diabetes. In this interface, rules were developed for five user profiles, seeking to meet the GDPR in force in the country.

Future research should conduct more tests to implement the cloud system and apply new security protocols. The interface has been created in an intuitive and modular format following the MVC design and thus can include new interpretations of data from future SDC-X projects.