ManagementPortal: A management system of remote monitoring studies #
ManagementPortal (MP) is a component built by the RADAR-base community to manage remote monitoring studies of participants/patients. It facilitates the default security protocol followed in RADAR-base data workflow. It helps to manage studies, participants, data sources and handles authentication and authorization of entities with the help of role-based access control. It uses OAuth2 workflow to support authentication and authorization.
Concepts in ManagementPortal #
Management Portal is designed to support remote monitoring of subjects. RADAR-base follows a few terms and concepts across the platform, which are defined below.
Project: A project refers to a study or a phase of a study/project. A Project is an important instance and compulsory to have to start data collection. A project name must be unique and can only be created by a SYSTEM_ADMIN type user. Every user except SYSTEM_ADMIN is categorized based on a project. A user can be assigned to one or more projects.
Subject: A subject refers to a person or an object from whom/which the data is collected. A subject should be assigned to a project and uniquely identifiable. MP creates a unique identifier for every subject. Since the identifier provided by MP is in UUID format and less human-readable, MP allows storing additional human-readable identifiers. While a study participant is the most obvious real-world counterpart of the subject, it is not limited to that use case. A Subject can refer to anything in the environment you want to assign a set of sensors to e.g. a plant or a pet.
Source Type: As the name suggests, source type is the type or a category of a source, i.e. FitBit Charge 2, Empatica E4, a questionnaire, a glucometer etc. A source type is identified by the unique combination of producer, model and catalogue version. A catalog defines how data is collected from a source type and it should be versioned. It provides additional flexibility for defining or customizing a source-type. For example, catalog version 1.0.0 of Empatica E4 can collect data from five sensors, and catalog version 2.0.0 can collect data from six sensors. The source type identifier can be defined as follows e.g. considering Empatica E4 the producer is Empatica, the model is Empatica E4, and catalog version is 1.0.0. In MP, a project can use one or more source types, and they should be entered accordingly. For example, for a hypothetical depression study, we could use FitBit 2, an application to collect phone sensor data, and a questionnaire. Source type has a collection of source data.
Source Data: Source Data is the definition of data collected from a source type. E.g., acceleration data from Empatica E4 and smartphone app usage. A source type can have multiple source data. Source data contains the metadata of how data is collected from a source, e.g. type of the data, format, schema, topic where that data is sent to, unit, frequency etc.
Source: A Source is the object that produces the data, e.g., a device or an app. Similar to a subject, a source should be assigned to a project and be uniquely identifiable, and MP generates the identifier. A Source is an instance of a Source Type, e.g., a particular FitBit device or an instance of an application. A source can be dynamically created without user interaction by an application or manually entered by a user in MP based on the source type and the permissions that a user or an application has. A source type must be created and used in the project where the source is expected to be used. For example, the device A00017 of Empatica E4 can be used in a project that uses Empatica E4 as a source type.
Currently, the security architecture of the RADAR-base validations allows only a subject registered in the Management Portal to send data from the source(s) assigned to him/her.
Security and Role-Based Access Control. #
Management Portal(MP) makes use of the Role Based Access Control (RBAC) method and OAuth2 to provide security. Every user in the Management Portal can have one or more roles.
A role in MP is a combination of a project and an authority. An authority is a privilege that allows a user to perform certain actions in the platform, e.g. a SYSTEM_ADMIN can create a project, a PROJECT_ADMIN can add subjects to the project he/she is assigned to, and a PARTICIPANT can send data to the platform etc. A role defines the actions that a user is authorized to perform on which projects.
An authority has a set of permissions. A Permission is the smallest definition of an action that can be performed on RADAR-base platform. E.g. creating a project or reading a project. An authority is formed by a collection of permissions according to the requirements. This allows a clear separation of what can be done and what cannot be done by a particular user with a particular role.