#  Executive Summary

The Data Management Plan describes all the data management processes related
to the WorkingAge project. First of all, the document will define some general
principles about data management policy and scientific publications in
research context. Then, the Data Management Plan will define all the
procedures to collect, manage and store data with the priority to be GDPR
compliant. The document will define also technical procedures, such as
pseudonymization and data encryption, directly related to the GDPR compliance.
Finally, the Data Management Plan will describe official figures already
stated by the GDPR, such as Data Controller, who will deal with Data
Management and Data Protection issues.

#  1\. Introduction

This document is Version 1 of the Data Management Plan (DMP), presenting an
overview of data management processes, as agreed among WorkingAge

(WA) project’s partners. This DMP will first establish some general principles
in terms of data management and Open Access.

Subsequently, it will be structured as proposed by the European Commission in
H2020 Programme – Guidelines on FAIR Data Management in Horizon 2020, covering
the following aspects:

  * Data Summary; 

  

  * FAIR Data; 

  

  * Allocation of resources; 

  

  * Data security; 

  

  * Ethical aspects; 

  

The DMP is a “living” document outlining how the research data collected or
generated will be handled during and after the WorkingAge project. The DMP is
updated over the course of the project whenever significant changes arise.
 

#  2 General principles for data management

##  2.1 Data collected and personal data protection

**Within the WorkingAge (WA) project, partners collect and process research
data and data for general project management purposes, according to their
respective internal data management procedures and in compliance with
applicable regulations** . Data collected for general purposes may include
contact details of the partners, their employees, consultants and
subcontractors and contact details of third parties (both persons and
organisations) for coordination, evaluation, communication, dissemination and
exploitation activities. Research data are collected and processed in relation
with the research pilots. During the project lifetime, data are kept on
computers dedicated to this purpose, which are securely located within the
premises of the project partners. Data archiving, preservation, storage and
access, is undertaken in accordance with the corresponding ethical standards
and procedures of the partner institution where the data is captured,
processed or stored. The data is preserved for a minimum of 10 years (unless
otherwise specified). All data susceptible of data protection are subject to
standard anonymization and stored securely (with password protection). The
costs for this are covered by the partner organization concerned.
**Confirmation that the aforementioned processes comply with national and EU
legislation is provided by each partner and verified by each Data
Controller.**

#  3 Research data and Open Access

The WorkingAge project is part of the H2020 Open Research Data Pilot (ORDP)
and publication of the scientific results is chosen as a mean of
dissemination. In this framework, open access is granted to publications and
research data and this process is carried out in line with the Guidelines on
Open Access to Scientific Publications and Research Data in Horizon 2020.

The strategy to apply Open Access for the project’s scientific results is
revised, step by step, according to personal data protection regulations, the
results of the ethical approval process of the research protocols and the
provisions of the Consortium Agreement. If needed, it will be possible to “opt
out” from this open access strategy for specific and well-defined subsets of
data.

##  3.1 Scientific publications

Open access is applicable to different types of scientific publication related
to the research results, including its bibliographic metadata, such as:

  * journal articles; 

  

  * monographs and books; 

  

  * conference proceedings, abstract and presentations;  grey literature (informally published written material). 

  

Grey literature includes also reports and deliverables of the projects related
to the research, whose Dissemination level is marked as Public.

Open access is granted as follows:

  * Step 1 – Depositing a machine-readable electronic copy of a version accepted for publication in repositories for scientific publications (before or upon publication). 

  

  * Step 2 – Providing open access to the publication via the chosen repository. 

  

For access to publications, a hybrid approach is considered (both green OA and
gold OA), depending on the item and the dissemination channels that will be
available:

  * Green OA (self-archiving) – depositing the published article or the final peer-reviewed manuscript in repository of choice and ensure open access within at most 6 months (12 months for publications in the social sciences and humanities). 

  

  * Gold OA (open access publishing) – publishing directly in open access mode/journal. 

  

##  3.2 Data Management Policy

The Data Management Policy will address the points below and will detail the
current status of reflection within the consortium regarding the data that is
being produced. According to ORDP requirements, the WorkingAge DMP observes
FAIR (Findable, Accessible, Interoperable and Reusable) Data Management
Protocols.

In order to better proceed with Data Management and Data Protection issues,
all partners which deal with data require the figure of the Data Controller,
this role will be achieved by the legal representative of each partner
managing (i.e. generating and/or processing) data, as stated by the Article 4
and the Article 24 of the GDPR. Each partner might nominate a Local Data
Manager, who will manage data on behalf of Data Controllers as a result of a
relationship that links them. Local Data Managers will be responsible for
contacting the users in order to provide the information sheet for the WA
project and obtain consent forms.

##  3.3 Research data

In addition, open access is granted also to underlying research data (data
needed to validate results presented in publication) and their associated
metadata, any other data (not directly attributable to the publication and raw
data) and information on the tools needed to validate the data and, if
possible, access to these tools (code, software, protocols etc.).

Open access is granted as following.

  * Step 1 – Depositing the research data in a research data repository. A repository is an online database service, an archive that manages the long-term storage and preservation of digital resources and provides a catalogue for discovery and access. 

  

  * Step 2 – Enabling access and usage free of charge for any user (as far as possible). 

  

The consortium will try to publish as much research data as possible, but this
will be decided on a case-by-case basis, in order to be compliant with the
GDPR in terms of publishing non-sensitive and personal data.

##  3.4 Other project’s outcomes

As per any other outcomes of the project, they are disseminated accordingly to
the Dissemination level indicated in the Description of Action and they are
also subject to protection in accordance with the Consortium Agreement and in
reference to Access Rights.

#  4 FAIR Data management plan

##  4.1 Data summary

The Data Summary provides an overview of the purpose and the nature of data
collection and generation, and its relation to the objective of the WorkingAge
(WA) project.

###  4.1.1 Objectives of the project and research

The WA project as a complex research requires careful planning, management and
administration in its development and implementation. Work has been structured
in ten work packages: six covering Research and Innovation work, two for test
(Integration and User tests), one for exploitation and dissemination, one for
the definition of all specifications and one management work package. WP1 will
include all management issues. Prior to the main research cycle, the
consortium will participate in WP2: this WP intends to set the bases for all
ulterior research including the selection of tools and participants,
optimizing the time for the tests. Research cycles (Expected at least two)
will start with the definition of the interventions for the users (WP3) at
work and in daily life process. This work will be the base for WP4 (HCI
platform), WP5 (IOT infrastructure and services), WP6 (Data Analysis) which
occur in parallel (and sharing produced knowledge). Ethics and security domain
performed during WP7. Deployment and Integration (WP8) in which the final
prototypes and the optimization of the research cycles will be adapted for the
tests. The intervention models and measurement prototypes will be then
integrated and used to collect data in the WP9 (Test Performance). In WP10
Standardization and Business Development, Commercialization and IPR Management
will be worked considering the future the market release of the studied
solution. This WP will also summarize all the actions proposed for
dissemination.

###  4.1.2 Purpose of the data collection during the project

WorkingAge will use innovative Human-Computer-Interaction (HCI) methods
(augmented reality, virtual reality, gesture/voice recognition and eye
tracking, neurometrics) to measure the user’s cognitive and emotional states
and create communication paths. At the same time with the use of Internet of
Things (IoT) sensors will be able to detect environmental conditions. The
purpose is to promote healthy habits of users in their working environment and
daily living activities in order to improve their working and living
conditions.

###  4.1.3 Relation to the objectives of the project

By studying the profile of the >50 (year old) workers and the working place
requirements in three different working environments (Office, Driving and
Manufacturing), both profiles (user and environment) will be considered.
Information obtained will be used for the creation of interventions that will
lead to healthy ageing inside and outside the working environment.

WorkingAge will test and validate an integrated solution that will learn the
user’s behaviour, health data and preferences and through continue data
collection and analysis will interact naturally with the user. This innovative
system will provide workers assistance in their everyday routine in the form
of reminders, risks avoidance and recommendations. In this way the WorkingAge
project will create a sustainable and scalable product that will empower their
user's easing their life by attenuating the impact of aging in their autonomy,
work conditions, health and well-being.

###  4.1.4 Processing of the data and consent form

Processing of all the WorkingAge project data will take place in several
countries, complying with GDPR and other local legislation. The consent form
in paper format will be stored in the correspondent country in which they are
generated.

###  4.1.5 The types and formats of data generated/collected

All the data are stored in digital way and the different types are defined as
follows:

####  4.1.5.1 Raw data

Raw data is data produced by all the devices used in the measurements: EEG
(Electroencephalography), ECG (Electrocardiography), GSR (Galvanic Skin
Response), Camera (video and images), Voice Recognition, Movement and Pose
Recognition.

####  4.1.5.2 Online pre-processing

Online pre-processing is the action of checking the quality and/or decoding
and/or modifying raw-data before storing or uploading them (e.g. by filtering
techniques).

####  4.1.5.3 Online markers / annotation / indicators calculation

Thanks to sensors data and online calculations one can identify specific
events (e.g. interruptions during the working task, etc.) and/or compute
various indicators (e.g. performance indicators).

####  4.1.5.4 Offline markers / annotation / indicators calculation

Thanks to observers and/or offline calculations one can retrieve contextual
information and/or identify specific events (e.g. unsafe situations, events
complex to automatically identify online), and/or various indicators. Such
process can be used to enrich and/or manually/automatically annotate or mark
information in the database.

####  4.1.5.5 Offline data acquisition

Some data are acquired using either questionnaires or interviews that are
potentially supported by markers and/or annotation data. Such data (sometimes
called subjective data) can be stored in raw form (audio-visual recording or
scanned documents), or encoded form. Moreover, it is possible that data will
be acquired offline, deriving from service providers (e.g. weather forecast).

####  4.1.5.6 WorkingAge database

The WorkingAge database will consist of data collected during studies (online
/ offline), plus markers / annotations / indicators (online / offline). The
project database will be organized in directories: each partner could use a
directory in which store the different data acquired types. All the data
stored in the database will be encrypted and each dataset will be accessible
only to the partner who acquired the dataset and to other partners who own the
secondary decryption key.

###  4.1.6 Data sources

In this section, all the sources of data are briefly discussed. The data will
be generated by two types of test ( _in-LAB_ phase, and _in-COMPANY_ phase) in
three different time-scales (single test, week test, long-term test).

It is noted that upcoming D2.6 “Study Protocols for the Test” will describe
the tests with more detail, which may introduce some modifications.

####  4.1.6.1 In-LAB Phase

#####  4.1.6.1.1 Single Tests

Experiments will be performed with one individual in a single occasion. Single
tests will run in two sessions and two series of these tests will be
implemented. These tests will be performed with up to 90 individuals. They
will involve the analysis of in-depth aspects and validity of the intervention
focusing on user expectation, usability and validity. Users of these tests
will not have age requirements (only gender and/or health requirements) and
will not be rewarded.

In-LAB tests will be performed at the end of the development of three modules
of the WA system, namely WP4, WP5 and WP6. The aim of these tests is to verify
the functionality of each element of the WA system, irrespective of its
effectiveness, which will be tested in the second set of tests described
hereinafter. Researchers and students from the responsible partners will be
involved for testing the measure, teach and adapt modules, whereas tests for
the middleware will consist mainly in software tests to verify the
communication among the elements of the WA system. Preliminary in-lab tests
aim at verifying that the different modules are able to detect mental strain
and monitor user’s interaction with the system and the validation of the
technical functions and the identification of software bugs of the offline and
online training system. Therefore, users will be asked to carry out
representative tasks with the developed training system. Three types of
activities will be included in this type of tests:

“Offline” assessment, consisting in questionnaires regarding demographic
questions, or tests for perceptive, cognitive or motoric capabilities.
Moreover, skills and constitutional characteristics will be queried by
questioning.

Real-time measurements consist in measuring physiological indicators for
mental strain, such as pupil diameter, blinking rate, skin conductance,
cerebral activity, body temperature, and heart rate. Other measurements to
create HCI interactions will also be tested.

Performance indicators will be tracked, e.g. time for decisions, executions
step for the task, mistakes, and redundancies.

For these tests, users recruited by each organization developing a module will
interact with the system: UCAM for facial expression analysis and recognition,
EXO for gesture recognition, RWTH for eye tracking, ITCL for body pose
recognition, AUD and POLIMI for voice and BS for EEG, ECG.

####  4.1.6.2 In-Company Phase

At the moment of writing, the pilot tests are planned to be performed in Spain
and Greece, by end-user’s organizations Grupo Antolin, Piraeus Bank in Greece
and FirstAid ambulance company in Greece, led by INTRAS. This multi  site
design will allow the evaluation of the WA system in different social and
cultural contexts. The variety of partners’ profiles will allow the consortium
to test the WA solution in heterogeneous environments: some tests will be more
focused on the company dimension involving occupational health and safety
professionals or human resources managers, while others will address the
worker’s environments with the support of ICT or organizational departments.

Pilot application will consist of the following phases: (i) protocol design,
(ii) analysis of the pilot study with sample size considerations, (iii) pilot
applications, (iv) assessment of results. The research body of the consortium
will focus this pilot application to seek the potential mechanism of efficacy
for a new intervention and investigate those indicators that are triggering
the aforementioned intervention. The selection of the sample sizes for the WA
project includes judgement- and aims-specific considerations, but also
practical feasibility that leads to proper conclusions and interventions. The
inclusion criteria for the tests will be being healthy age 50+ and exclusion
criteria having neuropsychiatric disorders or addiction problems.

#####  4.1.6.2.1 Single Tests

Experiments will be performed with one individual in a single occasion. These
tests will be used to fine-tune the subsystems for the users that will perform
the week and long-term tests.

These tests will aim to assess reliably the psychological, physical, cognitive
and social health status in the presence of an occupational health specialist
by means of the HCI services. This experiment should be done with a large
group of 30 subjects (10 for each use case) from the total 90, and would be
preceded by development of the different assessment methodologies. These will
include information from existing renowned tests, such as: quality of life
(WHOQOL-BREF) and activities of daily living (ADCS-MCI-ADL), reduction in
health resource consumption (EQ-5D), Mini-Nutritional Assessment (MNA);
Health-related quality of life (HRQOL), Life’s Simple 7 metric., EQ5, ESM,
PHQ, GAD score, test of executive functioning, PAST, fluency tests, long-term
memory tests working memory and Lubben Social Network Scale. These
methodologies will be tested with questionnaires, speech, or AR interaction.

Other tests may be added, according to the decisions of the specialists.
Performance should be compared with questionnaires and other tests managed by
a trained specialist (external validity). Additionally, test-retest
reliability should be assessed.

#####  4.1.6.2.2 Week Tests

Experiments will run for several sessions and involving up to 45 individuals
from the final 90 individuals that will test the system. These experiments
will assess unmonitored interaction, track occupational related parameters for
analysis, and test if the system detects a health risk and delivers an
intervention. It will also be used for the assessment of the ability of WA to
self-improve. Objective (Are they still using it after three weeks?) and
subjective reactions (what did they like best? what didn’t they like?) will
also be tracked.

The scenarios considered in the tests, called evaluation scenarios, will be
defined for the three use cases. These specify what tasks the study
participants will be asked to perform while the effectiveness of the WA system
is measured. As part of the evaluation scenarios, the most frequent errors
likely to occur when using the traditional interaction systems will be found.
The goal will be to improve the interaction approach and, hence, decrease the
occurrence of such errors.

These tests (of the week category) will be comprised by a whole series of
experiments, with a total amount of 45 users involved (15 per use case) from
the 90 users. The interventions could take many forms. In order to test their
effectiveness in all WA aspects (physical, psychosocial, working and health)
they must be activated one-at-a-time and not all at once.

#####  4.1.6.2.3 Long-Term Tests

This test type will assess the ultimate goal of prevention and monitoring on a
long-range time scale, Up to 90 individuals will be monitored for about a year
towards the end of the project. Such a last testing session will also
investigate issues and benefits that may arise with long-term usage without
the interference of more controlled testing conditions and at the same time
test adherence and compliance. Good predictions and compile advice on how to
further pursue this objective in future research and development will be
included in the final report. There will also be a follow-up after 6 months to
see whether the technology is still used (reflecting sustainability). Users
will be rewarded with the equipment needed for the experiment. These users
will include the week tests users and new users performing the questionnaires
of the single tests to fine tune the system.

In order to test the adherence rate of the solution 90 users (30 per use case)
will have to use the complete solution for a long period of time (1 year).
Participants’ average weekly compliance rate will be calculated. Tests for
Dropout and Compliance; TAM will also be considered for evaluation. The
following Key-Point Indicators will be covered: i) reported average weekly
compliance of the indications; ii) Use of the networks to report improvement,
iii) attrition rate.

A compendium of tools series of testing for the assessment of the Physical,
Psychosocial, working and Health wellbeing of the worker in the context of
primary prevention will take place during the year.

The evaluation methodology will be user centred and will describe a series of
Key Performance Indicators (KPI) supported by the knowledge and input of the
parallel research. This evaluation will be supported on the evidence exposed
during the validation with real users.

##  4.2 FAIR Data

In general terms, research data generated in the WorkingAge project are – in
as far as possible – “FAIR”, that is findable, accessible, interoperable and
reusable.

###  4.2.1 Findability - Making data findable, including provisions for

###  metadata

Publications are provided with bibliographic metadata (in accordance with the
guidelines). Unique and persistent identifiers are used (such as Digital
Object Identifiers - DOI), when possible also applying existing standards
(such as ORCID for contributor identifiers). As per the European Commission
guidelines, bibliographic metadata that identify the deposited publication are
in a standard format and include the following:

  * The terms ["European Union (EU)" & "Horizon 2020"]. 

  

  * The name of the action, acronym and grant number. 

  

  * The publication date, the length of the embargo period (if applicable) and a persistent identifier. 

  

Datasets are provided with appropriate machine-readable metadata (see
paragraph 4.2.3) and keywords are provided for all type of data.

####  4.2.1.1 Naming conventions and versioning

Files are named according to their content to ease their identification with
the project, following this format:

  * Country code, e.g. 00 for Italy, 01 for Spain, 02 for UK (eventually we could include also the partner code). 

  

  * Dominant hand, R for right handed or L for left handed. 

  

  * Gender, M for male or F for female.  Participant order. 

  

  * Age. 

  

  * Protocol code, e.g. LBA for In-LAB Acceptability. 

  

  * Data Type, e.g. A for EEG data, B for ECG data, C for GSR data. 

  

Each partner will keep this pseudo-ID on his side, in particular it will be
stored by the Data Controller. BrainSigns, as Data Manager of the project,
will receive only the anonymous data label containing the partner’s name and
the participant’s order. An example is reported below:  
  
<table>  
<tr>  
<th>

Mapping on Data Controller’s Side

</th>  
<th>

Label uploaded on server (BrainSigns)

</th> </tr>  
<tr>  
<td>

03RM0001045LBAE

</td>  
<td>

EX001

</td>  
<td>

EX001

</td> </tr> </table>

###  4.2.2 Accessibility – Making data openly accessible

Data and related documentation are made available depositing them in the
repository of choice (Zenodo), together with the publications, and are
accessible free of charge for any user **. Zenodo is a repository built by
CERN, within the OpenAIRE project, with the aim of supporting the EC’s Open
Data policy by providing a set of tools for funded research** . Zenodo
provides tools to deposit publications and related data and to link them. Any
needed restriction in access to the data is evaluated before final
publication, in accordance with ethical aspects (conducting research with
humans and children) and with protection of personal data.

All the consent forms related to the WorkingAge activities will explicitly
indicate that the pseudonymized dataset will be published on a public
repository. In case of privacy issues, Zenodo repository allows the publisher
to restrict the data access, asking for the data owner approval before
downloading them.

###  4.2.3 Interoperability - Making data interoperable

Metadata models were evaluated among the ones available in the Metadata
Standards Directory.

Dublin Core standard (Table 1) was selected to add metadata to each of the
datasets identified in sub-section 4.1.

**Table 1 –** DC Metadata Element Set  
  
<table>  
<tr>  
<th>

**Term name**

</th>  
<th>

**contributor**

</th> </tr>  
<tr>  
<td>

URL

</td>  
<td>

http://purl.org/dc/elements/1.1/contributor

</td> </tr>  
<tr>  
<td>

Label

</td>  
<td>

Contributor

</td> </tr>  
<tr>  
<td>

Definition

</td>  
<td>

An entity responsible for making contributions to the resource

</td> </tr>  
<tr>  
<td>

Comment

</td>  
<td>

Examples of a Contributor include a person, an organization, or a service.
Typically, the name of a Contributor should be used to indicate the entity

</td> </tr>  
<tr>  
<td>

**Term name**

</td>  
<td>

**coverage**

</td> </tr>  
<tr>  
<td>

URL

</td>  
<td>

http://purl.org/dc/elements/1.1/coverage

</td> </tr>  
<tr>  
<td>

Label

</td>  
<td>

Coverage

</td> </tr>  
<tr>  
<td>

Definition

</td>  
<td>

The spatial or temporal topic of the resource, the spatial

</td> </tr> </table>  
<table>  
<tr>  
<th>

</th>  
<th>

applicability of the resource, or the jurisdiction under which the resource is
relevant

</th> </tr>  
<tr>  
<td>

Comment

</td>  
<td>

Spatial topic and spatial applicability may be a named place or a location
specified by its geographic coordinates. Temporal topic may be a named period,
date, or date range. A jurisdiction may be a named administrative entity or a
geographic place to which the resource applies.

Recommended best practice is to use a controlled vocabulary such as the
Thesaurus of Geographic Names [TGN]. Where appropriate, named places or time
periods can be used in preference to numeric identifiers such as sets of
coordinates or date ranges

</td> </tr>  
<tr>  
<td>

References

</td>  
<td>

http://www.getty.edu/research/tools/vocabulary/tgn/index.html

</td> </tr>  
<tr>  
<td>

**Term name**

</td>  
<td>

**creator**

</td> </tr>  
<tr>  
<td>

URL

</td>  
<td>

http://purl.org/dc/elements/1.1/creator

</td> </tr>  
<tr>  
<td>

Label

</td>  
<td>

Creator

</td> </tr>  
<tr>  
<td>

Definition

</td>  
<td>

An entity primarily responsible for making the resource

</td> </tr>  
<tr>  
<td>

Comment

</td>  
<td>

Examples of a Creator include a person, an organization, or a service.
Typically, the name of a Creator should be used to indicate the entity

</td> </tr>  
<tr>  
<td>

**Term name**

</td>  
<td>

**date**

</td> </tr>  
<tr>  
<td>

URL

</td>  
<td>

http://purl.org/dc/elements/1.1/date

</td> </tr>  
<tr>  
<td>

Label

</td>  
<td>

Date

</td> </tr>  
<tr>  
<td>

Definition

</td>  
<td>

A point or period of time associated with an event in the lifecycle of the
resource

</td> </tr>  
<tr>  
<td>

Comment

</td>  
<td>

Date may be used to express temporal information at any level of granularity.
Recommended best practice is to use an encoding scheme, such as the W3CDTF
profile of ISO 8601 [W3CDTF]

</td> </tr>  
<tr>  
<td>

References

</td>  
<td>

http://www.w3.org/TR/NOTE-datetime

</td> </tr>  
<tr>  
<td>

**Term name**

</td>  
<td>

**description**

</td> </tr>  
<tr>  
<td>

URL

</td>  
<td>

http://purl.org/dc/elements/1.1/description

</td> </tr>  
<tr>  
<td>

Label

</td>  
<td>

Description

</td> </tr>  
<tr>  
<td>

Definition

</td>  
<td>

An account of the resource

</td> </tr>  
<tr>  
<td>

Comment

</td>  
<td>

Description may include but is not limited to: an abstract, a table of
contents, a graphical representation, or a free-text account of the resource

</td> </tr>  
<tr>  
<td>

**Term name**

</td>  
<td>

**format**

</td> </tr>  
<tr>  
<td>

URL

</td>  
<td>

http://purl.org/dc/elements/1.1/format

</td> </tr>  
<tr>  
<td>

Label

</td>  
<td>

Format

</td> </tr>  
<tr>  
<td>

Definition

</td>  
<td>

The file format, physical medium, or dimensions of the resource

</td> </tr>  
<tr>  
<td>

Comment

</td>  
<td>

Examples of dimensions include size and duration.

Recommended best practice is to use a

controlled vocabulary such as the list of Internet Media Types [MIME]

</td> </tr>  
<tr>  
<td>

References

</td>  
<td>

http://www.iana.org/assignments/media-types/

</td> </tr>  
<tr>  
<td>

**Term name**

</td>  
<td>

**identifier**

</td> </tr>  
<tr>  
<td>

URL

</td>  
<td>

http://purl.org/dc/elements/1.1/identifier

</td> </tr>  
<tr>  
<td>

Label

</td>  
<td>

Identifier

</td> </tr>  
<tr>  
<td>

Definition

</td>  
<td>

An unambiguous reference to the resource within a given

</td> </tr> </table>  
<table>  
<tr>  
<th>

</th>  
<th>

context

</th> </tr>  
<tr>  
<td>

Comment

</td>  
<td>

Recommended best practice is to identify the resource by means of a string
conforming to a formal identification system

</td> </tr>  
<tr>  
<td>

**Term name**

</td>  
<td>

**language**

</td> </tr>  
<tr>  
<td>

URL

</td>  
<td>

http://purl.org/dc/elements/1.1/language

</td> </tr>  
<tr>  
<td>

Label

</td>  
<td>

Language

</td> </tr>  
<tr>  
<td>

Definition

</td>  
<td>

A language of the resource.

</td> </tr>  
<tr>  
<td>

Comment

</td>  
<td>

Recommended best practice is to use a controlled vocabulary such as RFC 4646
[RFC4646].

</td> </tr>  
<tr>  
<td>

References

</td>  
<td>

http://www.ietf.org/rfc/rfc4646.txt

</td> </tr>  
<tr>  
<td>

**Term name**

</td>  
<td>

**publisher**

</td> </tr>  
<tr>  
<td>

URL

</td>  
<td>

http://purl.org/dc/elements/1.1/publisher

</td> </tr>  
<tr>  
<td>

Label

</td>  
<td>

Publisher

</td> </tr>  
<tr>  
<td>

Definition

</td>  
<td>

An entity responsible for making the resource available.

</td> </tr>  
<tr>  
<td>

Comment

</td>  
<td>

Examples of a Publisher include a person, an organization, or a service.
Typically, the name of a Publisher should be used to indicate the entity.

</td> </tr>  
<tr>  
<td>

**Term name**

</td>  
<td>

**relation**

</td> </tr>  
<tr>  
<td>

URL

</td>  
<td>

http://purl.org/dc/elements/1.1/relation

</td> </tr>  
<tr>  
<td>

Label

</td>  
<td>

Relation

</td> </tr>  
<tr>  
<td>

Definition

</td>  
<td>

A related resource.

</td> </tr>  
<tr>  
<td>

Comment

</td>  
<td>

Recommended best practice is to identify the related resource by means of a
string conforming to a formal identification system.

</td> </tr>  
<tr>  
<td>

**Term name**

</td>  
<td>

**rights**

</td> </tr>  
<tr>  
<td>

URL

</td>  
<td>

http://purl.org/dc/elements/1.1/rights

</td> </tr>  
<tr>  
<td>

Label

</td>  
<td>

Rights

</td> </tr>  
<tr>  
<td>

Definition

</td>  
<td>

Information about rights held in and over the resource.

</td> </tr>  
<tr>  
<td>

Comment

</td>  
<td>

Typically, rights information includes a statement about various property
rights associated with the resource, including intellectual property rights.

</td> </tr>  
<tr>  
<td>

**Term name**

</td>  
<td>

**source**

</td> </tr>  
<tr>  
<td>

URL

</td>  
<td>

http://purl.org/dc/elements/1.1/source

</td> </tr>  
<tr>  
<td>

Label

</td>  
<td>

Source

</td> </tr>  
<tr>  
<td>

Definition

</td>  
<td>

A related resource from which the described resource is derived.

</td> </tr>  
<tr>  
<td>

Comment

</td>  
<td>

The described resource may be derived from the related resource in whole or in
part. Recommended best practice is to identify the related resource by means
of a string conforming to a formal identification system.

</td> </tr>  
<tr>  
<td>

**Term name**

</td>  
<td>

**subject**

</td> </tr>  
<tr>  
<td>

URL

</td>  
<td>

http://purl.org/dc/elements/1.1/subject

</td> </tr>  
<tr>  
<td>

Label

</td>  
<td>

Subject

</td> </tr>  
<tr>  
<td>

Definition

</td>  
<td>

The topic of the resource.

</td> </tr>  
<tr>  
<td>

Comment

</td>  
<td>

Typically, the subject will be represented using keywords, key phrases, or
classification codes. Recommended best practice is to use a controlled
vocabulary.

</td> </tr>  
<tr>  
<td>

**Term name**

</td>  
<td>

**title**

</td> </tr>  
<tr>  
<td>

URL

</td>  
<td>

http://purl.org/dc/elements/1.1/title

</td> </tr>  
<tr>  
<td>

Label

</td>  
<td>

Title

</td> </tr>  
<tr>  
<td>

Definition

</td>  
<td>

A name given to the resource.

</td> </tr>  
<tr>  
<td>

Comment

</td>  
<td>

Typically, a Title will be a name by which the resource is formally known.

</td> </tr>  
<tr>  
<td>

**Term name**

</td>  
<td>

**type**

</td> </tr>  
<tr>  
<td>

URL

</td>  
<td>

http://purl.org/dc/elements/1.1/type

</td> </tr>  
<tr>  
<td>

Label

</td>  
<td>

Type

</td> </tr>  
<tr>  
<td>

Definition

</td>  
<td>

The nature or genre of the resource.

</td> </tr>  
<tr>  
<td>

Comment

</td>  
<td>

Recommended best practice is to use a controlled vocabulary such as the DCMI
Type Vocabulary [DCMITYPE]. To describe the file format, physical medium, or
dimensions of the resource, use the Format element.

</td> </tr>  
<tr>  
<td>

References

</td>  
<td>

http://dublincore.org/documents/dcmi-type-vocabulary/

</td> </tr> </table>

###  4.2.4 Data re-use and licensing

Publications and underlined data will be made available at the end of each
experimental phase, once all data are collected and analysed. All the data
indicated as Open Data will be made available for re-use after the end of the
project. The licences for publications and related data will be defined in the
final version of this plan, based on the final data, in order to verify
compliance with personal data protection regulations and the ethical approval
process results.

##  4.3 Allocation of resources

Costs related to open-access to research data in Horizon 2020 are eligible for
reimbursement under the conditions defined in the H2020 Grant Agreement [6.2
D.3], but also other articles relevant for the cost category chosen. Costs
cannot be claimed retrospectively. Project beneficiaries will be responsible
for applying for reimbursement for costs related to making data accessible to
others beyond the consortium.

##  4.4 Data Security

All research data produced during WorkingAge will be stored in dedicated hard
drive and in separated Network Attached Storage (NAS), and for backup purpose.

All the partners will transfer only pseudonymized data. Each transfer will be
protected by end-to-end encryption. The data transfer support will be provided
by the sharing platform called freeNAS, physically placed in BrainSigns and
exposed through HyperText Transfer Protocol over Secure Socket Layer (HTTPS).
All the data stored in the server will be encrypted. The software used for the
encryption and decryption procedure will be GnuPG. Each partner will own the
key to decrypt only the data that he acquired. BrainSigns will not have access
to the other partner’s datasets.

If any partner needs to access other partner’s research data, the data owner
will encrypt the data and will provide the secondary decryption key only to
the partner who needs the access.

The data owner will keep a register of all recipients of decryption keys.

###  4.4.1 Pseudonymization Process at Local level

Data Results in the platform are not associated with user’s identity.

The name of the research participant appears on the consent forms. All data in
the platform is pseudonymized by assigning an anonymized user code to each
participant.

Information of the association between platform user and participant of each
experimental location is transmitted to each Local Data Manager in Excel
format and with the specific data. The Excel sheet is secured through 256-bit
AES (Advanced Encryption Security) codification and password. The Data
Controller is responsible for the Excel sheet security. Participant’s data and
platform’s users’ conversion of the experimental location are stored by the
centre following the legal requirements of the country.

All data collected during the study through the platform is associated to the
platform user. That means that all shared reports, results, internal
communications and external publications do not contain any personal data of
the participant.

###  4.4.2 Data maintenance and storage at central WA level

####  4.4.2.1 Data access in freeNAS platform

Research and research-related personal data collected are encrypted and stored
in the systems of the organization where the data were produced. Personal Data
is only accessible by Data Controller of each organization.

Access is restricted to each participant, under their fictional pseudo-
identity, and to the members of the Data Controller organization and
WorkingAge research team.

Each access to the research data is properly logged with the information of
the authorized user who requests access to the data.

####  4.4.2.2 Process of backups of freeNAS platform

Each partner will send the pseudonymized and encrypted dataset to the server
through the freeNAS platform, after the experimental session conclusion. Each
partner will not transmit the primary decryption key. The partner’s Data
Controller will be responsible for the decryption key security.

##  4.5 Ethical aspects

The project will conform to privacy and confidentiality guidance from the EU
guidance notes, “Data protection and privacy ethical guidelines” and to the

Data Protection Directive (Directive 95/46/EC,
http://ec.europa.eu/justice/data-protection/index_en.htm). The following
ethical issues have been considered in the WA project and will be explained in
this point related to each country involved:

  * Notification/Authorizations of the Tests 

  

  * Data processing in the Cloud 

  

  * Data Controllers 

  

  * Video recording 

  

The ethical aspects of the research generating the scientific data of the
project are covered in the following deliverables, also taking into
consideration the European Commission Ethics Summary Report for the project.

  * D 7.1 - Ethical and Legal report. 

  

  * D 7.2 - Security and Privacy Model. 

  

The correspondence between the participant’s code, described in paragraph
4.2.1, and the participant’s identity is held in a suitably encrypted table
held on a secure computer at the Data Controller’s premises. No reference
about the participant’s code will be written on the respective consent form.

The ethics committee will include one member for each partner of the
consortium. This member will act also as the contact point for data privacy
issues and compliance to the data management plan. Contacts of DPOs of data
collectors will be included in the consent forms as per the Grant Agreement.