R6 |
Groups, studies, and HCPs |
Users should be able to join one or multiple groups. These groups can represent studies, HCPs or other groupings (e.g., test users). Users can be invited to groups by their respective group owner (e.g., the HCP) or join them via different join mechanisms (e.g., join requests, password-restricted or freely). |
R7 |
High availability and Performance |
The platform should be available to its users in the best possible way. There should not be any noticeable performance drops under higher loads. |
R8 |
Offline availability |
The mobile app should still be functional when there is no internet connection (or more generally, no connection to the server) whenever possible. All data should be stored on the device where appropriate and synchronized with the server. |
R9 |
Safety, security, and privacy |
The platform should meet high safety, security and privacy standards. Region-specific regulations like the EU General Data Protection Regulation (GDPR) and the Medical Device Regulation (MDR) should be considered. All confidential data should be stored securely and transmitted in encrypted form. User data and credentials should be stored separately from the answer data. Health risks should be identified and addressed at an early stage and outlined to users and HCPs in a transparent way. A security model for the mobile apps and the entire platform should exist. |
R10 |
Data quality |
Data quality should be kept as high as possible. Different data quality aspects like believability, relevancy, accuracy (i.e., error-free, reliable, precise), interpretability, understandability, accessibility, objectivity, timeliness, completeness and (representational) consistency (Wang and Strong, 1996) should be addressed depending on the specific requirements of the use case. The platform should perform input validation and prevent invalid inputs, perform plausibility checks, as well as other measures to improve quality of answer and sensor data. This also includes measures for detecting and handling misstatements by users, which might be both intentional and malicious (e.g., faking), as well as unintentional (e.g., self-deception), summarized with the terms faking and socially desirable responding (SDR) (Paulhus, 2001; Van de Mortel, 2008). |
R11 |
Data analysis |
The platform should offer easy-to-use data analysis functionalities on live data for researchers, HCPs, and also the users themselves. Both static and dynamic data analysis (e.g., aggregation with the help of filters and time windows or clustering) should be enabled. All relevant data should be exportable to common formats (e.g., CSV, SPSS, R, PDF). The HCP and the user should be able to review and analyze the individual answers to questionnaires as well as sensor measurements and compare them to the data of other users. |
R12 |
Interoperability |
The platform should offer a good interoperability with other (external) systems. This includes implementing common data exchange format standards and communication protocols, as well as providing uniform, understandable, and well-documented interfaces. |