#  3 Data, Materials, Resources Collection Information

The purpose of this section is to provide a full description of the data that
will be generated and stored during this project. The information provided in
here might be adapted or updated in further versions of this document.

###  3.1 Description of the data

All data will be generated through the use of the CAREGIVERSPRO-MMD online
platform by several categories of users, _i.e._ health professionals,
caregivers and patients. Each category of user will have access to specified
content and will be able to generate different types of information according
to the permissions granted.

For each user of the platform, different datasets described in this section
may be generated. Additional datasets may be generated in the future. The data
will be collected before and after the pilot phase of the project.

The platform will also provide means to assess and store data no directly
produced by users _i.e._ the interaction among users and the evolution on
their activity in the social network, which will also be subject to further
analysis.

##  3.1.1 Personal Dataset

_Table 2 Personal Dataset_  
  
<table>  
<tr>  
<th>

**Data set reference and name**

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

C-MMD-Personal

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

**Data set description**

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

This data set contains all the personal data captured through the registration
tools integrated in the C-MMD platform for the dyad (patient and caregiver)
and the health professionals. The registration tool collects standard personal
information. i.e. as described in EU Data Protection Directive (95/46/EC)  3
:

_"Personal data” shall mean any information relating to an identified or
identifiable natural person ('Data Subject'); an identifiable person is one
who can be identified, directly or indirectly, in particular by reference to
an identification number or to one or more factors specific to his physical,
physiological, mental, economic, cultural or social identity_ .

Therefore, the nature of the data corresponds to the values used to represent
such concepts (e.g. text, integers). At this moment the registering tool has
not been implemented in its final version, further details will be given in
future versions.

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

**Standards and metadata**

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

Data will be stored each time a user (be it patient, caregiver or health
professional) registers to the platform or modifies their profile. Although at
this moment the registering tool and

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

profile management tool have not been defined yet, it is expected that data
will be stored in a MySQL database, using noSQL database for complementary
purposes. Records will also be related (and identified) with other datasets
and the date when the data was recorded.

Metadata will include information about the profile creation time, range of
possible values, etc. This metadata will be associated to each table and will
follow the Common European Research Information Format (CERIF) metadata
standard  4  .

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

**Data sharing**

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

This dataset will not be shared outside of the Consortium boundaries for
ethical and security reasons. Each dataset record belongs to the user and to
the Consortium partner responsible for the user. Only the user, people
authorised by him/her ( _e.g._ caregiver) and authorised personnel of the
Consortium partner responsible for the user, can access the record. Data will
be available to users and people authorised by them through the C-MMD
platform. Authorised personnel of the pilot partner generating the data will
be able to access aggregated data in periodic reports and also will be able to
access raw data dumped from the database in _csv_ files or through a web
service. Each access will be identifiable and traceable.

Dataset records will be shared among defined Consortium partners anonymised
for research purposes in order to be used for the tasks of the project.
Anonymisation is the standard procedure followed to preserve confidentiality
of participants.

Each participant ( _e.g._ patient, caregiver, doctor) will sign an informed
consent at recruitment phase authorizing access to all his/her data (raw,
aggregated, anonymised). Users will agree to the anonymised and aggregated
data being used for research and possibly commercial exploitation.

The data repository will be in the C-MMD host in the UPC premises (more
details are given in section 6).

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

**Archiving and preservation (including storage and backup)**

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

See section 6 and 7.

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

##  3.1.2 Screening Dataset

_Table 3 Screening Dataset_  
  
<table>  
<tr>  
<th>

**Data set reference and name**

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

C-MMD-Screening

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

**Data set description**

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

This data set contains all the clinical and social data captured through the
screening tools integrated in the C-MMD platform for the dyad (patient and
caregiver). The screening tools

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

4  
  
<table>  
<tr>  
<th>

implement standard evaluation scales for different conditions (physical,
psychosocial, neurological, functional, _etc_ .). Therefore, the nature of the
data corresponds to the values used to evaluate such scales. At this moment
the screening tool has not been implemented yet, further details will be given
in future versions.

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

**Standards and metadata**

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

The data will be stored following the standard numeric scales defined by each
screening tool each time that a user (be it patient, caregiver or health
professional) uses one of the screening tools. Although at this moment the
screening tool has not been defined it is expected that data will be stored in
a MySQL database, using noSQL database for complementary purposes. Records
will also be related (and identified) with the user to which the recorded data
belong and the date when the data was recorded.

Metadata will include information about the scale recorded, range of possible
values, etc. This metadata will be associated to each table and will follow
the Common European Research Information Format (CERIF) metadata standard  5
.

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

**Data sharing**

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

This dataset will not be shared outside of the Consortium boundaries for
ethical and security reasons. Each dataset record belongs to the user and to
the Consortium partner responsible for the user. Only the user, people
authorised by Him/her ( _i.e._ caregiver) and authorised personnel of the
Consortium partner responsible for the user can access the record. Data will
be available to users and people authorised by them through the C-MMD
platform. Authorised personnel of the pilot partner generating the data will
be able to access aggregated data in periodic reports and also will be able to
access raw data dumped from the database in csv files or through a web
service. Each access will be identifiable and traceable.

Dataset records will be shared among the Consortium partners anonymised for
research purposes in order to be used in the tasks of the project.
Anonymisation is the standard procedure followed to preserve confidentiality
of participants.

Each participant will sign an informed consent at recruitment phase
authorizing access to all his/her data (raw, aggregated, anonymised). Users
will agree to the anonymised and aggregated data being used for research and
possibly commercial exploitation.

The data repository will be allocated in the C-MMD host in the UPC premises
(more details in section 6).

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

**Archiving and preservation (including storage and backup)**

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

See section 6 and 7.

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

5

##  3.1.3 Treatment Dataset

_Table 4 Treatment Dataset_  
  
<table>  
<tr>  
<th>

**Data set reference and name**

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

C-MMD-Treatment

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

**Data set description**

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

This dataset contains all the treatment information for each dyad. The
treatment information will come from: (1) a specific toolset integrated in the
platform for that purpose, (2) through the API to connect with national
healthcare systems where possible. The nature of the data corresponds to
medication descriptions, doses, schedules and follow-up of the adherence. At
this moment the data-capturing tool has not been implemented, further details
will be given in future versions.

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

**Standards and metadata**

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

The data will be stored following the numeric/text standards each time that a
user (be it patient, caregiver or health professional) uses the treatment
management interface to introduce or modify information about the
pharmacological treatment being followed and the adherence regime to the
treatment. Although at this moment the treatment management tool has not been
defined it is expected that data will be stored in a MySQL database, using
noSQL database for complementary purposes. Records will also be related (and
identified) with the user to which the recorded data belong and the date when
the data was recorded.

Metadata will include information about the data recorded, range of possible
values, etc. This metadata will be associated to each table and will follow
the Common European Research Information Format (CERIF) metadata standard  6
.

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

**Data sharing**

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

This dataset will not be shared outside of the Consortium boundaries for
ethical and security reasons. Each dataset record belongs to the user and to
the Consortium partner responsible for the user. Only the user, people
authorised by him/her ( _i.e._ the caregiver) and authorised personnel of the
Consortium partner responsible for the user, can access the record. Data will
be available to users and people authorised by them through the C-MMD
platform. Authorised personnel of the pilot partner generating the data will
be able to access aggregated data in periodic reports and also will be able to
access raw data dumped from the database in _csv_ files or through a web
service. Each access will be identifiable and traceable.

Dataset records will be shared among the Consortium partners, anonymised for
research purposes, in order to achieve with the tasks of WP6. Anonymisation is
the standard procedure followed to preserve confidentiality of participants.

All described accesses to data (raw, aggregated, anonymised) will be
authorised though an informed consent signed by the participant at the
recruitment phase. Users will agree to the

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

6  
  
<table>  
<tr>  
<th>

anonymised and aggregated data being used for research and possibly commercial
exploitation.

The data repository will be allocated in the C-MMD host in the UPC premises
(more details in section 6).

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

**Archiving and preservation (including storage and backup)**

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

See section 6 and 7.

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

##  3.1.4 Intervention Dataset

_Table 5 Intervention Dataset_  
  
<table>  
<tr>  
<th>

**Data set reference and name**

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

C-MMD-Intervention

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

**Data set description**

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

This data set contains all the intervention contents created by the consortium
members during the lifetime of the project. These intervention contents
include posts, articles, tips, multimedia, tutorials, webinars and any kind of
educational content produced to support the caregiving process and the healthy
ageing lifestyle. These intervention contents will be introduced in the
platform through specific tools designed for that purpose ( _e.g_ . the ones
available in Wordpress to edit blog posts). Standards in multimedia and text
posts storage will be followed. At this moment the editor tools have not been
implemented, further details will be given in future versions.

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

**Standards and metadata**

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

The data will be stored following the standard text/media formats following
best practices for data management (see section 6). Although at this moment
the editing tool has not been defined, it is expected that data will be stored
in a MySQL database, using noSQL database for complementary purposes. Records
will also be related (and identified) with the user authoring the contents and
the date when the data was recorded.

As explained in section 5.1 of DoA and later in this document in section 4,
all contents created will follow the HONCode.

Metadata will include information about the intervention recorded and a list
of tags or keywords that relate the content with specific symptoms, conditions
or problems that the content refers to ( _e.g._ a video about Alzheimer could
have the tags _Alzheimer_ , _dementia_ , _cognitive decline_ , etc.) This
metadata will be associated to each table and will follow the Common European
Research Information Format (CERIF) metadata standard  7  .

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

**Data sharing**

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

7  
  
<table>  
<tr>  
<th>

Each dataset record belongs to the Consortium partner responsible for creating
it. All the Consortium and suitable users  4  are authorised to access the
recorded contents. Data will be available to users and people authorised by
them through the C-MMD platform. Aggregated data about the amount of contents
generated and specific metadata ( _e.g._ tags) will be available as well as
access to raw data dumped from the database in files to selected Consortium
members.

Dataset records, particularly aggregated data, will be shared among the
Consortium partners for research purposes in order to be used in the tasks of
the project.

Users will agree to the anonymised and aggregated data being used for research
and possibly commercial exploitation.

The data repository will be allocated in the C-MMD host in the UPC premises
(more details in section 6).

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

**Archiving and preservation (including storage and backup)**

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

See section 6 and 7.

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

##  3.1.5 Dissemination Dataset

_Table 6 Dissemination Dataset_  
  
<table>  
<tr>  
<th>

**Data set reference and name**

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

C-MMD-Dissemination

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

**Data set description**

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

This data set contains all the dissemination contents created by the
consortium members during the lifetime of the project. These dissemination
contents include scientific papers, newsletters, multimedia, press articles,
conferences and any kind of dissemination content produced to support the
communication activities of the project and dissemination of results. These
contents created from different sources will be stored in a
database/filesystem.

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

**Standards and metadata**

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

The data will be stored following the standard text/media formats following
best practices for data management (see section 6). Records will also be
related (and identified) with the user authoring the contents and the date
when the data was recorded.

Metadata will include information about the dissemination data recorded, the
target audience, identifier ( _i.e._ DOI, URI), authors, title of the
publication, time of publication, related event ( _e.g._ conference, forum,
_etc._ ) and a list of tags or keywords that relate the content with specific
topics or results. This metadata will be associated to each table and will
follow the Common European Research Information Format (CERIF) metadata
standard  5  .

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

**Data sharing**

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

Each dataset record belongs to the Consortium partner/s responsible for
creating it. These contents are open for access.

The data repository will be allocated in the C-MMD host in the UPC premises
(more details in section 6).

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

**Archiving and preservation (including storage and backup)**

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

See section 6 and 7.

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

##  3.1.6 Dataset Summary

_Table 7 Dataset Summary_  
  
<table>  
<tr>  
<th>

Dataset

</th>  
<th>

Who

</th>  
<th>

Ownership

</th>  
<th>

Access

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

Personal Dataset

</td>  
<td>

User

</td>  
<td>

Yes

</td>  
<td>

Yes , full

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

Partner (recruiting)

</td>  
<td>

Yes

</td>  
<td>

Yes, full to authorised personnel

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

Rest of Consortium

</td>  
<td>

No

</td>  
<td>

Yes, only anonymised and aggregated data

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

World

</td>  
<td>

No

</td>  
<td>

No

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

Screening Dataset

</td>  
<td>

User

</td>  
<td>

Yes

</td>  
<td>

Yes , full

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

Partner (recruiting)

</td>  
<td>

Yes

</td>  
<td>

Yes, full to authorised personnel

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

Rest of Consortium

</td>  
<td>

No

</td>  
<td>

Yes, only anonymised and aggregated data

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

</td>  
<td>

World

</td>  
<td>

No

</td>  
<td>

No

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

Treatment Dataset

</td>  
<td>

User

</td>  
<td>

Yes

</td>  
<td>

Yes , full

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

Partner (recruiting)

</td>  
<td>

Yes

</td>  
<td>

Yes, full to authorised personnel

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

Rest of Consortium

</td>  
<td>

No

</td>  
<td>

Yes, only anonymised and aggregated data

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

World

</td>  
<td>

No

</td>  
<td>

No

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

Intervention Dataset

</td>  
<td>

User

</td>  
<td>

No

</td>  
<td>

Yes, depending on their needs

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

Partner (authoring)

</td>  
<td>

Yes

</td>  
<td>

Yes, full to authorised personnel

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

Rest of Consortium

</td>  
<td>

No

</td>  
<td>

Yes, full to authorised personnel

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

World

</td>  
<td>

No

</td>  
<td>

Limited and depending on project needs and exploitation policies

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

Dissemination Dataset

</td>  
<td>

User

</td>  
<td>

No

</td>  
<td>

Yes

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

Partner (authoring)

</td>  
<td>

Yes

</td>  
<td>

Yes

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

Rest of Consortium

</td>  
<td>

No

</td>  
<td>

Yes

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

World

</td>  
<td>

No

</td>  
<td>

Yes

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

###  3.2 Quality Assurance Process

Every data gathering process is susceptible to contamination in the absence of
adequate preventive measures. Data contamination results from a process or
phenomenon, other than the one of interest, which can affect the variable
values. Data contamination results in erroneous values in the data set. In
general, there are two types of errors that can occur in a data set. Firstly,
errors of commission, which are the result of incorrect or inaccurate data
being included in the data set. This may happen because of a malfunctioning
instrument that produces faulty results, data that are mistyped during entry,
or other problems.

Errors of omission are the second type of errors. These result from data or
metadata being omitted. Situations that result in omission errors occur when
data are inadequately documented, when there are human errors during data
collection or entry, or when there are anomalies in the field that affect the
data.

Quality assurance/quality control (QA/QC) activities should be an integral
part of any inventory development processes as they improve transparency,
consistency, comparability, completeness and accuracy.

**Quality control (QC)** is defined as a system of checks to assess and
maintain the quality of the data inventory being compiled. Quality control
procedures are designed to provide routine technical checks to measure and
control the data consistency, integrity, correctness and completeness; and to
identify and address errors and omissions. Quality control checks should cover
everything from data acquisition and handling, application of approved
procedures and methods, and documentation. Examples of general quality control
checks include:

  * checking for transcription errors in data input; 

  

  * checking that scale measures are within the range of acceptable values; 

  

  * checking that proper conversion factors are used; 

  

In future versions of this document we will provide more details on the QC
protocols to be adopted during the project lifetime.

**Quality assurance (QA)** is a planned system of review procedures conducted
outside the actual inventory compilation by personnel not directly involved in
the inventory development process. It is a non-biased, independent review of
methods and/or data summaries that ensures that the inventory continues to
incorporate correctly the scientific knowledge and data generated. Quality
assurance procedures may include expert peer reviews of data summaries and
audits to assess the quality of the inventory and to identify where
improvements could be made. If deemed necessary, selected members of the
Advisory Board may perform this task in the course of the project lifecycle.

#  4 Ethics, Intellectual Property, Citation

###  4.1 Ethics

The lack of ethical principles standardization at international level may
potentially lead to the abuse of data collection, use and storage by
exploiting differences between societies with regard to established ethical
standards. Ethics of data collection, and data use and storage in medical
applications, is of growing importance since the quality and quantity of
medical data usage is growing quickly both in Europe and worldwide. Great
concerns are raised about data protection and privacy issues in the area of
biometric and health applications with growing markets that might be affected
by insufficiently protected sensitive information.

The healthcare providers that are involved in the project follow strict
ethical codes. All ethical, legal and regulatory issues will be studied in
detail in T8.6 and presented in the incremental versions of D8.3. The most
relevant findings will be included in the final version of this document.

###  4.2 Intellectual Property

With regard to property and ownership of medical data and records, there are
two distinct views. From the standpoint of practitioners (i.e., healthcare
providers, hospitals), patient medical records are their property because they
are the ones who write, compile and produce the records (data producers). At
the same time, patients tend to believe that medical records belong to them as
they provide the relevant information.

Nevertheless, the project will produce data assets that do not correspond to
medical records. For instance:

  * Intervention contents and guidelines; 

  

  * Gamification reports; 

  

  * Treatment adherence reports; 

  

  * Aggregated medical data reports; and 

  

  * Reports and statistics of platform usage. 

  

The ownership and IPR of these assets will be detailed in future versions of
this document. The resulting agreements will be compliant with corresponding
legislation (i.e. Data Protection Act, Copyright, Freedom of Information Act,
_etc_ .).

###  4.3 Citation

An article, paper or presentation that refers to, or draws, information from a
data set should cite the data set, just as it would cite other sources such as
books and articles. A citation gives appropriate credit to the data set
creator(s), and allows interested readers to find the data set so they can
confirm the data is being correctly represented, or can use it in their own
work. There is no universal standard for formatting a data set citation.

There are many different styles for formatting citations, such as APA and
Chicago Manual of Style. In addition, most scientific publications have their
own style, either unique to themselves or based on an existing style. A few of
these styles, such as APA 6th edition, specify how to cite data sets. However,
most citation style manuals do not currently cover citing data sets.
Consequently, adaptation of the styles’ general format can be applied to the
needs of data sets.

At this early stage, the information used to cite C-MMD data sets could be:

  * Author(s) ( _the principal investigator can be used as the “author” of a data set_ ) 

  

  * Title 

  

  * Year of Publication 

  

  * Publisher ( _partner producing the dataset_ ) 

  

  * Version 

  

  * Access information ( _doi or url_ ) 

  

#  5 Access and Use of Information

One of the objectives of the CAREGIVERSPRO-MMD project is to develop the
solution into a commercial product. This is the main reason why the Consortium
has decided that potentially publishable data will not be available for open
access until the end of the project, once the exploitation paths have been
defined.

However, results of the pilot execution and platform evaluation will be made
publicly available through the deliverables **D6.1 – Mid-Pilot preliminary
analysis report, D6.2 – Final Pilot analysis report** and **D6.3 – User
feedback and usability report.**

More details on specific dataset access regimes are defined in section 3.1.

#  6 Storage and Backup of Data

In order to safeguard the appropriate preservation of the data, portion of the
budget has been allocated in the data storage and backups during the lifespan
of the project and at least for the following two years.

The data will be stored in databases installed on the same server that holds
the CAREGIVERSPRO-MMD platform. These Databases are only accessible locally
(i.e. only available to the server itself) in order to prevent any connection
from outside. The system and server configuration have been arranged in order
to support local data encryption to avoid physical access to the hard disk
drive. This measure would prevent access to the data if the physical storage
was stolen or accessed directly.

The server has a local firewall that only allows secure web connections to the
Internet and verified IP addresses for development/updates of the C-MMD
application. A local log file records every access to the server.

The server is located in the UPC campus Data Center. This data center is a
dedicated 250m  2  facility with controlled access, personal ID cards for
authorized staff and video surveillance 24x7. The server has dedicated
bandwidth and backup power system in order to guarantee availability.

A daily backup procedure has been designed in order to ensure data integrity
and recovery. This backup has two main subsystems:

  1. File system backup: A daily copy of every file in the file system is stored in compressed format. 

  

  2. Database backup: A daily dump of every database/table is stored in a single file. 

  

  3. Daily encryption and compression of log files. 

  

  

Optionally, this backup can be physically moved to a safe location outside the
UPC Data Center if the personal data requires this level of protection. A
specific budget is reserved for this task.

A 30-day window backup system has been programmed and enough disk space has
been reserved for a monthly operation.

###  6.1 Best Practices for File Formats

The file formats used have a direct impact on the ability to open those files
at a later date and on the ability of other people to access those data.

##  6.1.1 Proprietary vs Open Formats

Data should be saved in a non-proprietary (open) file format when possible. If
conversion to an open data format will result in some data loss from the
files, it should be considered saving the data in both the proprietary format
and an open format. Having at least some of the information available in the
future is better than having none.

When it is necessary to save files in a proprietary format, it will be
included a readme.txt file that documents the name and version of the software
used to generate the file, as well as the company who made the software.

##  6.1.2 Guidelines for Choosing Formats

When selecting file formats for archiving, the formats should ideally be:

  * Non-proprietary; 

  

  * Unencrypted;  6 

  

  * Uncompressed; 

  

  * In common usage by the research community; ▪ Adherent to an open, documented standard: 

    * Interoperable among diverse platforms and applications o Fully published and available royalty-free 

  

    * Fully and independently implementable by multiple software providers on multiple platforms without any intellectual property restrictions for necessary technology 

  

    * Developed and maintained by an open standards organization with a welldefined inclusive process for evolution of the standard 

  

  

##  6.1.3 Some Preferred File Formats  7  8

  * Containers: TAR, GZIP, ZIP 

  

  * Databases: XML, CSV 

  

  * Geospatial: SHP, DBF, GeoTIFF, NetCDF 

  

  * Moving images: MOV, MPEG, AVI, MXF 

  

  * Sounds: WAVE, AIFF, MP3, MXF 

  

  * Statistics: ASCII, DTA, POR, SAS, SAV 

  

  * Still images: TIFF, JPEG 2000, PDF, PNG, GIF, BMP 

  

  * Tabular data: CSV 

  

  * Text: XML, PDF/A, HTML, ASCII, UTF-8 

  

  * Web archive: WARC 

  

#  7 Archiving and Future Proofing of Information

The national legislation (European compliant) of the server site (Spain)
compels UPC to preserve all data and access records for **two years** after
the project completion. The server will remain in the same safe location in
order to preserve physical and logical access. Consequently, the data will be
kept in the server and will be accessible under the same terms that will be
agreed among partners during the project lifespan.

All public project deliverables will be available at least for **five years**
after the project completion at the project portal.

Selected datasets, databases, standalone documents, and even software may be
made public or open for exploitation at the end of the project. These
resources may prove useless without explanatory notes (metadata) accompanying
them. Metadata will be clearly linked to the materials so that they can
adequately inform any future user about the material. For example, a published
dataset will typically be accompanied by a metadata document that explains the
various fields, their usefulness and summarises the purpose of the dataset in
general. These documents will be stored along with the dataset and made
accessible in the same manner as the dataset ( _e.g._ online, or download).
Contact information will be provided accordingly in case that the future user
needs further clarification.

#  8 Resourcing of Data Management

This section outlines the staffing and financial details of the data
management within the CAREGIVERSPRO-MMD project. The former aspect provides
information about the role and responsibilities of the partners that generate
the data and those who control it. The latter aspect describes the financing
process for data management and data storage.

###  8.1 Roles in Data Management

Each pilot partner (HUL, COO, FUB, CHU) is responsible for the data generated
in their own pilots by the different stakeholders of the platform as **data
producers** . Each pilot partner will assign a responsible person from his or
her institution for this task to be designed for the next version of this
document.

The UPC is responsible for all the aspects related with data storage and
backup as **data processor** .

MDD and CERTH as the main developers of the C-MMD platform will be responsible
as **data processor** and **service provider** of all the aspects related with
data gathering, data integrity, access logging, _etc_ .

As specified in section 5.1.3 of DoA, specific agreements will be signed among
partners in order to grant access to the different datasets for the different
uses (data storage, data processing, service provision).

###  8.2 Financial Data Management Process

As mentioned before, the Consortium has reserved a portion of the project
budget for data hosting and backup.

#  9 Review of Data Management Process

The follow-up of this plan will be reported in future versions of this
document, where detailed protocols and measures will be described to ensure
the compliance with the plan along with preliminary results on the observed
evolution. UPC as main contributor to this plan, supported by the roles
described in section 8.1, will perform the follow-up.

External reviewers of the Consortium as well as selected members of the
Advisory Board will support the peer-review process.

#  10 Statements and Personnel Details

###  10.1 Statement of Agreement

The Consortium agree to the specific elements of the plan as outlined.  9

####  Project Coordinator  
  
<table>  
<tr>  
<th>

Title

</th>  
<th>

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

Designation

</td>  
<td>

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

Name

</td>  
<td>

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

Date

</td>  
<td>

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

Signature

</td>  
<td>

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

####  Project Manager  
  
<table>  
<tr>  
<th>

Title

</th>  
<th>

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

Designation

</td>  
<td>

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

Name

</td>  
<td>

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

Date

</td>  
<td>

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

Signature

</td>  
<td>

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

**Management Board** (one table for each member)  
  
<table>  
<tr>  
<th>

Title

</th>  
<th>

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

Designation

</td>  
<td>

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

Name

</td>  
<td>

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

Date

</td>  
<td>

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

Signature

</td>  
<td>

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