Open-source data management system for Parkinson’s disease follow-up

Requirement analysis

The development of the system was based on the Rapid Application Development (RAD) concept. RAD is an approach based on agile project, and it was chosen because this methodology is incremental, emphasizing rapid and reusable coding for the development of application modules. It can be understood in four main steps: (i) requirement planning: developers, software users, and team members discuss the objectives and expectations of the project and address the requirements; (ii) design: in this step, a prototype is drawn up and discussed with software users and refined until an acceptable design is reached; (iii) construction: this step is mainly related to database development and coding of the prototypes. (iv) cutover: final coding, tests on the system, and the system users are trained. Bugs can be reported for correction, and new requirements will reinitialize step (i). This concept focuses on lean documentation, relying on the essentials for coding the functionality of the system, but requires an experienced programmer (Jailia et al., 2016; Sommerville, 2010; Qodim, Busro & Rahim, 2019).

In line with the RAD concept, several functionalities were analyzed to construct an integrated system providing an adequate tool. To reach this objective, the process was guided by the expertise of seasoned professionals in research on PD, interviews with specialists in PD diagnosis, and professionals specialized in software development. Furthermore, the development of the system took into consideration all aspects and conditions of PD patients (biological, social and cultural), and a complete study of well-known questionnaires and clinical scales to evaluate PD patients (Andrade et al., 2013).

All the identified requirements were used to develop the system architecture and organization, to design the graphical user interface, and to model data structure. The system was developed incrementally, that is, it was tested and improved as the unit was developed (Sommerville, 2010).

Integrated biomedical data system architecture

The aim of the Integrated Biomedical Data System (in Portuguese, Sistema Integrado de Dados Biomédicos (SIDABI)) is to manage and secure data from PD patients and research volunteers. Fig. 1 depicts the architecture and structure of the system.

Figure 1 shows the security levels that a system user or administrator has to go through to access the distinct modules of the system. Fig. 1A illustrates the first security barrier to authentication. The access to specific screens and modules is released according to the user’s profile (Fig. 1B). Users may have permission to create, view, update and delete records. Each module of the system is presented in Fig. 1C. The system has five interconnected modules that can share information among them: Clinical Assessment, Data Management, Idea Collection and Sharing, Education and Training, Data Query. All the modules of the system are connected to a security module, Fig. 1D.

The system architecture is based on the Model-View-Controller (MVC) pattern (Fig. 1E). The Apache web server was used to host the system because it is the most used web server. Apache web server is an open source project, easy to customize environments, fast, reliable, and highly secure (Fielding & Kaiser, 1997; Baş Seyyar, Çatak & Gül, 2018) and the Apache web server can be set up to accept distinct programing languages and databases. The data are stored in the PostgreSQL database that also is open-source software, secure, robust, works with relational and no relational data, highly concurrent, and the most popular database system (Hellerstein, 2018). The Apache web server and the database are illustrated in Fig. 1F

Design pattern

In general, the design pattern provides best practices in a framework of solutions for common problems in the context of designing software. The MVC is a pattern used to build interfaces in three separated logic layers: the Model manages the data and rules of the application; the View is the representation and appearance of the data on the screen such as text, tables, charts; the Controller handles the requests from View or Model layers validating and processing these data, and sending commands to execute the appropriate action (e.g., store data, retrieve data, show some information in a table) (Jailia et al., 2016; Sommerville, 2010; Syromiatnikov & Weyns, 2014).

In the literature, it is possible to find recent patterns based on MVC such as Model-View-ViewModel (MVVM) in which the ViewModel layer controls the functions of presentation, sending commands, automating communication between View and ViewModel layer, and supporting the View state. MVVM supports multiple views. It was created to facilitate interactions between the View and ViewModel layers of graphical user interfaces. The Model-View-Presenter (MVP) is more flexible about layer’s responsibilities, and the pattern also was based on MVC. The Presenter layer is responsible for supervising the View and Model layers, handling user events, listening to the View layer, making changes to the View layer, and maintaining the application synchronized. In general, the Model and View layers in MVVM and MVP follow the principles of the MVC pattern (Syromiatnikov & Weyns, 2014).

Despite some improvements in MVVM and MVP, the MVC design pattern was used to construct the proposed web system because it is the most acceptable standard used to develop custom applications on the Web in different programing languages (Jailia et al., 2016; Sommerville, 2010). Additionally, MVC gives more focus on the Controller layer (Syromiatnikov & Weyns, 2014) that is suitable for this study once the main idea is based on controlling requests made by the software user and verifying its permissions of access in a module, page and data manipulation. These verifications can slow the response of requests in some milliseconds, MVC can result in additional classes and objects, and in more complex file organization, however, the MVC pattern also allows reliable access to the database, providing a clean, organized, reusable, scalable, and efficient code (Jailia et al., 2016; Sommerville, 2010).

The MVC pattern is used by a number of well-known frameworks and companies such as Django (National Geographic, Instagram, Pinterest, Open Stack, Mozilla) (Django Web Framework, 2021), Ruby on Rails (GitHub, Airbnb, Basecamp, Shopify) (Hansson, 2021), Spring (Netflix, VMware Tanzu, Alibaba, Amazon, Google, Microsoft) (Spring Framework, 2021). Despite this, software that uses the MVC pattern in the medical field related to Parkinson’s disease is still rare. Studies found in the literature showing software development, such as the use of a mobile and web application to improve gait in patients with PD (Garzo et al., 2018), an augmented reality game to assess upper limb impairment in stroke (Bank et al., 2018) and PD patients (Bank et al., 2018; Van der Meulen et al., 2016), and a mobile mental health monitoring application (Kamdar & Wu, 2016), did not describe any pattern of development used.

Figure 1E illustrates the MVC adopted, in which the interaction between the user and the system’s response to the user is represented. The View layer contains the elements presenting information to the software user, and these elements can be built using HTML5 (the language used to create the structure of the elements shown on web pages), Cascading Style Sheets (CSS3), which is the mechanism for formatting the pages, and JavaScript (JS) that is the programing language used on the client-side to make it possible the interaction between the user and the components presented on the screen (Jailia et al., 2016; Freeman et al., 2004). The JS library JQuery 3.1.1 was used to optimize interactions.

Therefore, when the user interacts with the system, for example, by clicking on a button, JS handles this event and passes it on to a controller. The controller layer uses the PHP programing language to code the server-side system. The view controller assembles the results brought by the model controller or simply assembles the response of a specific request and returns it to the browser. The model controller is responsible for interacting with the model layer, which has classes that interact directly with the database (Jailia et al., 2016; Majeed & Rauf, 2018).

In addition to the MVC pattern, the Responsive Web Design (RWD) concept was also used to design the layout with optimized experience, good ergonomics and usability while using the system on different devices. The Bootstrap Framework 3.3.7 was used to ensure proper functioning on different platforms (Majeed & Rauf, 2018).

Usability evaluation

Usability is a term used to define how easy people can employ a tool or object in order to accomplish a specific task. Usability is also related to the evaluation of a system with the aim to improve (i) human computer interaction, and (ii) the social and practical acceptance of the system (Nielsen, 2004; Ganney, Pisharody & Claridge, 2013). Thus, the usability of an interface should be good enough allowing the users to perform the system's tasks easily.

In this way, the usability of a system should focus on developing interfaces that are easy to handle and quick to learn. The functionality of the layout should avoid and deal with operational errors efficiently and with appropriate feedback to the user. In addition, usability must address user satisfaction and provide an effective solution to the problem that the system was designed to solve (Nielsen, 2004; Ganney, Pisharody & Claridge, 2013).

In this sense, SUS was used to evaluate the usability of the system. The scale has ten questions, $q=\left\{q_1,\cdots ,q_{10}\right\},$and each of them can assume a value, w, ranging from 1 (strongly disagreement) to 5 (strongly agreement) (Table 1). The calculation of the scores for a specific question, $S_q$, is given in Eq. (1). The final scale score, $\mathrm{S}\mathrm{U}{\mathrm{S}}_{\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}}$, ranges from 0 to 100 points, with 68 points being an acceptable score (Jordan et al., 1996), and this final score is given in Eq. (2).

Bangor, Kortum & Miller (2009) proposed an adjective rating scale according to the average points obtained from SUS, with the usability classified as worst imaginable (12.5), awful (20.3), poor (35.7), ok (50.9), good (71.4), excellent (85.5) and best imaginable (90.9).

The usability test (SUS) of the system was performed by 36 examiners, and the resultant data is available in the Supplemental Information section. The data is organized in a comma-separated file (usability-db-en.csv) in which the first four columns are related to the characterization of the examiners, and the fifth to fourteenth columns deal with the SUS questions.

In addition, Kendall’s coefficient of concordance was estimated to verify the overall agreement between the examiners in the SUS questionnaire. It was used because it is a non-parametrical statistic, more accurate to smaller sample sizes, which can be used for assessing agreement among examiners considering ordinal data, and can be used for assessing agreement among a variety of raters. This coefficient can assume values from 0 (without agreement) to 1 (complete agreement) (Legendre, 2005).

The statistical analysis and data visualization were performed in R, a language and environment for statistical computing (R Core Team, 2019), using the open-source integrated development environment (IDE) RStudio for R, version 1.2.5042. Thus, an R file with the analysis presented in this study (data-analysis-usability-v01.R) is also available in the online repository pointed at the Supplemental Information section.

Experimental protocol

This research follows the Resolution 466/2012 of the National Health Council. The study was conducted at the Centre for Innovation and Technology Assessment in Health of the Federal University of Uberlândia (UFU), Brazil. The experimental protocol was approved by the Human Research Ethics Committee (CEP-UFU), CAAE Number: 93993118.4.0000.5152. The participants were informed about the data collection procedures and signed a consent form before data collection.

During the experiment, the system was evaluated by 36 examiners and the examiners were not trained on how to use the system before carrying out the proposed tasks. They remained comfortably seated and accessed the web system through a computer. In order to evaluate the usability of the system, the user was asked to execute several common tasks, such as logging in to the user account, accessing specific software modules and filling in form data, uploading experimental session data, using search fields, and others. The duration of the interaction tasks was approximately 15 minutes.

The user was asked to inform the level of computer skills (1–2, 3–5, more than 5 years), age (18–25, 26–35, 36–45, more than 46 years old), and the number of hours of computer use per week (2–5, 6–10, over 10 h). Subsequently, the examiner answered ten questions about the usability evaluation questionnaire.

System description and visualization

Figure 2 illustrates the authentication screen (A) and interface that provides access to the distinct modules of the system (B). The ordinary user or administrator performs authentication using a username and password. The security module validates access into screens, modules, and information manipulation levels that the user has on each page, such as inserting new data, data visualization, updating information, or data removal.

Currently, the system contains five implemented modules (Fig. 2B) and a security administration area to manage user permissions. Each module has its functionalities, and some of them share data. The principal functions of the modules are described in Fig. 3 as a use case diagram. Besides that, the complete system can be downloaded and is available in the Supplemental Information section.

The use case diagram is a feature of Unified Modeling Language (UML) and is commonly used to show the relationship between functionalities and system users. It is used for a high-level view of the system and identifies the fundamental factors. The use case diagram utilizes some notations such as an actor that performs a role (i.e., a user and an administrator of the system), a system user can be researcher’s labs, hospital staff, nonprofit organizations staff; an ellipse drawing that is the use case representing a function or an action in the system. The system object is represented as a rectangle, which defines the scope of the use case (Sommerville, 2010).

Besides that, as shown in Fig. 3, the relationships in a use case diagram are used to represent the interactions between actors and use cases. A continuous line connects an actor to functionality, a dashed line with an arrow and marked with an <<include>> word means a necessity to add that use case (the arrow points to the use case included). On the other hand, a dashed line with a <<extend>> label means a possible additional functionality but not mandatory (the arrow points to the use case that extends the functionality) (Sommerville, 2010).

In this context, Fig. 3 represents the main use case diagrams of SIDABI modules shown in this study. It is essential to emphasize the words manage and control presented in the use cases meaning junction of some data manipulation functionalities such as insert, edit, delete, and find information. Thus, Fig. 3A represents the security module with two actors, the administrator can manage all the permissions functionalities, and the simple user can visualize its account and the modules permitted. In Fig. 3B, the clinical assessment software shows two distinct roles, that is, the researcher, which is a person who can manage the main functions of the clinical assessment module and can apply a questionnaire, and the patient or caregiver role, that is the actor that can respond the questionnaire.

In Fig. 3C, the data management module is represented, and the system user with appropriated permissions can control the functionalities and upload the files resulting from the session of data collection. Fig. 3D illustrates the module so-called idea collection and sharing, which allows the system user to control new project proposals.

Figure 3E represents the education and training module from which the user can manage the information of the symptoms of PD and learn from a page that overviews the symptoms, tutorials, and extra materials about the disease. Fig. 3F shows the patient or volunteer management functions that are used to add and control the records of people in the system. Finally, Fig. 3G illustrates the data query module with an actor accessing a menu with filters that can help to narrow the results of research data. The software users can select the filters (e.g., study group, participant, equipment) to help them to get more accurate results, for instance, if it was chosen a specific equipment, the query result brings all the files related to that equipment. These functionalities mentioned above are detailed in Table 2. Additionally, the whole database diagram of SIDABI is available in the Supplemental Information section.

Figure 4 exemplifies some functionalities implemented in the system. In (A) represents the screen for viewing and downloading data collection files, shared or not within research groups. The filters (e.g., protocol, equipment, session date, researcher group) are used to narrow the database’s file search. Figure 4B illustrates the list of symptoms used to study and understand the theory and practical issues by videos of Parkinson's disease and separated by categories. Figure 4C illustrates the volunteer registration screen with various specific information, and these data remain in common with other modules.

Finally, Fig. 4D illustrates the screen developed to view projects requested on the Idea Collection and Sharing module. This screen exemplifies the behavior of the responsiveness in using the system from a mobile device.

The SIDABI system presented so far has some characteristic similar to a clinical data warehouse (CDW) in which it is possible to storage distinct file format, a complex type of data, integration of a variety of applications, security, support decision making, support to researchers, helps in querying and presenting information, and data management. However, CDW has a complex infrastructure based on a variety of databases (raw data, meta data, summary data, data marts), operational data sources, a layer to Extract, Transform and Load (ETL) information, and many data access front end (e.g., analyzing, reporting, mining, medical information, business). Besides that, CDWs also deal with policies of data backups, the workload in the system, capacity of storage and no deletion of information (Khalaf Hamoud, Salah Hashim & Akeel Awadh, 2018).

Sistema Integrado de Dados Biomédicos focuses on the integration of web applications to take care of people with Parkinson’s disease and help non-profit organizations. SIDABI is free and open-source, and in any necessity, programmers can change the code and the database related to medical record forms and functions that deal with information about Parkinson’s disease and the system can cover other disorders. The entire structure and source code of SIDABI can be found in the Supplemental Information section.

Usability and agreement results

The questionnaire that evaluates SIDABI was designed to obtain the examiner experience and the general characteristics of the system regarding the usability of the interface, error handling and system feedback messages, ease of use, satisfaction, and whether the system meets the tasks for which it was designed.

In this sense, from the 36 examiners, 83.33% had over five years of experience using computers, 77.78% were between 18 and 25 years old, and 52.78% used the computer for more than 10 h a week. The dataset and codes to compute these statistics can be found in the Supplemental Information section.

Figure 5 shows the answers obtained from the 36 examiners for each question of the SUS questionnaire. Most of the even-numbered questions yielded scores around 1–2 points, which characterizes a fair evaluation of negative purpose questions concerning the system's usability. On the other hand, most of the odd questions scored between 4 and 5, a high score for questions with a positive purpose, given the usability of the system.

The SUS scores are given in Fig. 6. The red dashed line represents the mean score obtained (82.99). The estimated standard deviation was 13.97, confirming the good usability of the system as the obtained SUS score is above the blue dotted line (68 points), which represents the acceptable value for a system evaluated with this scale.

In addition, it is possible to observe, according to the scale proposed by Bangor, Kortum & Miller (2009), that the system is between good (71.4) and close to excellent (85.5 points). Most of the examiners gave scores higher than 82.99 points, and 7 of them evaluated the system with usability below 68 points.

The agreement between the examiners was verified using Kendall coefficient for the SUS scale score. The SIDABI reached 70.2% of concordance with p = 5.9 × 10⁻⁴⁴, which suggests a good agreement among the evaluators.