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. Project is an important instance and a compulsory to have to start data collection. Every user except SYSTEM_ADMIN is categorized based on a project. A user can be assigned to one or more projects. A project-name should be unique and essential to create a project. It can only be created by a SYSTEM_ADMIN.
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 an unique identifier for every subject. Since the identifier provided by MP is in UUID format and less human-readable, MP allows to store a human readable identifier as additional metadata. While a study participant is the most obvious real-world counterpart of the subject, it is not limited to that use case. 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 catalog-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. E.g. catalog-version 1.0.0 of Empatica E4 can collect data from five sensors and catalog-version 2.0.0 can collect from six sensors. The source type identifier can be defined as follows e.g. considering Empatica E4 the producer is Empatica, model is Empatica E4, and catalog-version is 1.0.0. In MP a project can use one or more source types and should be entered accordingly in MP. E.g. for a depression study we could use FitBit 2, an application to collect phone sensor data and a questionnaire etc. 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, application usage from a smartphone. A source data can be used in a source type and 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 which produces the data, e.g. a device, an app. Similar to a subject, a source should be assigned to a project , uniquely identifiable and the identifier is generated by MP. A Source is an instance of a Source Type e.g. a particular device of FitBit 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 have. A source-type must be created and used in the project where the source is expected to be used. E.g. the device A00017 of Empatica E4 can be used in a project which uses Empatica E4 as a source-type.
Currently, security architecture of the RADAR-base validations allows only a subject registered in 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 Management Portal can have one or more role.
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, reading a project. An authority is formed by a collection of permissions according to the requirements. This allows clear separation of what can be done and what cannot be done by a particular user with a particular role.