#  1\. Executive Summary

This deliverable is the first version of the Data Management Plan (DMP) of the
CrowdHEALTH project and it compiles a first description of the datasets
according to the FAIR template. The overall purpose of this document is to
support the data management life cycle for all data that will be collected,
processed or generated by the project.

CrowdHEALTH participates in the Open Research Data Pilot of the H2020
Programme [1], and a DMP is required for all the projects that are
participating in this programme. The DMP is usually intended to be submitted
by month 6 of the project, and the European Commission recommends using a
template that follows the FAIR Data Management Plan Model [2] in order to make
the research data **F** indable, **A** ccessible, **I** nteroperable and **R**
e-usable. However, due to CrowdHEALTH complexity in what regards data, which
comes from the fact that the project deals with heterogeneous sets of data,
from different sources that are initially not interoperable, and taking into
account the high level of privacy and confidentiality of most datasets,
together with the large amount of datasets identified, the FAIR Model was not
appropriate to gather relevant information from the pilots (Use Cases) as a
starting point. A more practical kind of information about the datasets was
needed by the technicians to understand what type of data will be made
available and how it will be used by the pilots. Consequently, some extra time
was needed to create appropriate questionnaires and collect relevant
information.

The whole procedure to gather information about partners’ datasets, and in
particular those provided by the Use Cases who have access to them, has been
described in the introduction of this deliverable and forms for the
compilation of information can be found in annexes. The reason for sharing
information about these steps and the procedure that we have designed previous
to the elaboration of the first DMP is that we proposed what can be seen as a
good practice, which could be appreciated and replicated, and probably
improved for its implementation in other projects of similar complexity
regarding available data and datasets to be researched and used by the
developments.

The project has identified a list of 13 datasets and a FAIR questionnaire has
been completed for each one.

The DMP is a living document that will be updated for the mid-term and the
final review of the project.

#  2\. Introduction

##  2\. 1 Objective

CrowdHEALTH DMP has been conceived to support the data management life cycle
for all data that will be collected, processed or generated by the project.

Moreover, the CrowdHEALTH DMP aims to identify best practices for gathering
information about the variety of data to be used in the project that could
optimise the development, specific standards for the generated data and assess
their suitability for sharing and reuse in accordance with official
guidelines.

##  2\. 2 Document Structure

Section 2 - this introduction - explains what a DMP contains, the datasets
identified during the project, how the CrowdHEALTH consortium proceeded to
gather the information, and why we started to complete simpler templates and
finally completed the FAIR Data Management Plan Template. Section 3 contains
inputs to the FAIR Model following the template for all project Datasets.
Annexes contain the templates of the questionnaires for the Use Cases partners
that were used previously to complete the FAIR Data Management Plan Template
and some additional information.

##  2\. 3 What the Data Management Plan should contain as described in the
Grant Agreement

From the Grant Agreement p. 193: “ _CrowdHEALTH Data Management Plan will
comply with the EC Data Management Plan template_ [2] _and will specify how
the generated data will be easily discovered and accessed, ensuring open
access by adopting the adequate licensing scheme (e.g. Creative Commons
License)._

_The plan will also generate wider interest towards improvements achieved by
the project in order to facilitate and potentiate exploitation opportunities.
CrowdHEALTH capitalizes on the development of a well-defined Data Management
Plan (DMP), including: (i) Data Types, Formats, Standards and Capture Methods;
(ii) Ethics and Intellectual Property, (iii) Access, Data Sharing and Reuse;
(iv) Resourcing; (v) Deposit and Long-Term Preservation, and (vi) Short-Term
Storage and Data Management._

_Moreover, the plan will describe quality evaluating tools/procedures, which
will prove the data intelligibility, and will define the type of accompanying
information in the form of metadata or short description to allow potential
users to gain awareness on the data concepts and evaluate their suitability
for future use._

##  2\. 4 Key Performance Indicators of the Data Management Plan

As stated in the Description of Action (DoA) [3], these will be the means to
measure and Key Performance Indicators (KPIs) of the first evaluation of DMP:

  * _At least 5 open data management packages uploaded_

  

  * _At least 5 repositories, where open data management packages are uploaded_

  

In case of not providing access to data, the DMP must contain the reasons for
not giving access. It is too early to address the KPIs at this early stage of
the project development. This will be addressed in further versions of the DMP
and towards the end of the project.

##  2\. 5 Data classification as identified during the Kick-off meeting

CrowdHEALTH project is complex in what regards data, for the diversity, the
privacy and confidentiality of collected data, and the different sources from
where data come from, and as such operates on the basis of very different and
heterogeneous datasets.

The first questions to the Use Case partners related to the types of datasets
to be considered, their characteristics and descriptions. Answering those
questions, and providing details regarding the available and potentially
available data to be shared within the context of the project, was essential
to start defining the high level architecture of the system.

During the kick-off meeting, the consortium identified two basic stages with
respect to the availability of datasets:

  1. Existing datasets _provided by the use cases_ or open datasets that we may use for the project purposes 

  

  2. Datasets of aggregated data _generated (i.e. collected) during the project pilots_

  

  

Subsequently, an initial and tentative classification guided the consortium
towards the understanding of what the project will face in terms of data.  
  
<table>  
<tr>  
<th>

1) _**EHR Data** (Stockholm University Hospital and Hospital La Fe) _

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

Disease-specific (e.g. obesity, diabetes, etc.) in standardised formats (e.g.
HL7, FHIR, etc)

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

2) _**Living Lab and Chronic Disease Management Data** (DFKI, BioAssist) _

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

a) Nutrition data, lifestyle, activities, biosignals

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

b) Standardisation (ADLs, IADLs, Open mHealth, FHIR, PHRs)

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

3) _**Public Health Data** (Ministry of Education, Science and Sport,
University of Ljubljana ) _

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

  1. Somatic and motor development data sets from SLOfit system (anthropometric measurements of children  1  ); 

  

  2. In a second step, nutrition, physical activity, sedentariness, sleep, resting heart-rate, socioeconomic status and parental physical activity. 

  

  

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

4) _**Social Health Data** (Care Across, BioAssist) _

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

a) Information shared through online platforms with different stakeholders
(e.g. physicians, patients, etc) regarding diagnosis, treatment, co-
morbidities

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

b) Other sources with information about health behaviours related to
interactions between patients and patients-care givers

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

5) _**Non-Medical Data** (ALL) _

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

a) Open and linked data, e.g. World bank or WHO Statistics, Socio-Economic and
Financial Data, etc.

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

##  2\. 6 Pilot on Open Research Data in Horizon 2020

CrowdHEALTH participates in the Pilot on Open Research Data in Horizon 2020
[1] and will offer open access to scientific results reported in publications,
to relevant scientific data and to data generated throughout the project
lifetime in its numerous demonstrators, provided that they are anonymized and
fully respect national and EU privacy regulations. It will aim to improve and
maximise access to and re-use of scientific data generated by the project
i.e., system performance data, user validations, etc.

For those projects that are participating in the Pilot on Open Research Data
in Horizon 2020, the European Commission suggests a template for the DMP
called FAIR Data Management Plan Template. However, this template has been
designed to include information progressively, and after the kick-off meeting
of the project, it was clear that gathering some initial information about the
datasets not included in the FAIR template was needed, not only for the
purposes of preparing the DMP but to provide some information to the project
developers in order to avoid any delay in the definition of the project
architecture and the work package technical development.

##  2\. 7 Original questions asked by the technical WPs

After the kick-off meeting, the leaders of the CrowdHEALTH technical WPs
needed detailed information about the datasets to start their work. Their
questions were gathered into a list that can be found in Annex 1\.

##  2\. 8 Questions to Use Cases partners (UC)

In reality, we have used the pretext of the DMP deliverable – in which we need
to determine what the project intends to do with the data produced within the
project for each dataset– to concretise and better understand the CrowdHEALTH
use cases starting points in terms of available data.

The original questions asked by the technical WPs were merged and reordered
with some basic details that were also needed for this first version of the
DMP. The questionnaire has been distributed amongst the Use Cases partners,
and replies allowed technical WP staff understanding how each Use Case operate
in terms of policy making, what are their prioritised policies, how they
evaluate them and what is expected as project outputs for the creation and
evaluation of policies.

We understand now that not all inputs gathered at that initial stage are
relevant and need to be included in the final version of the DMP. However, we
considered that it would be easier for Use Cases to provide all initial
information related to data and how data is being used in their context into
one single document, which could then serve as a basis to be consulted by the
technical partners.

This questionnaire can be found in Annex 2. The replies to this questionnaire
were compiled in a document restricted to the project participants - D2.1a,
Questions to Use Cases for the DMP. This document served as an input to WP5
and WP6 deliverables.

##  2\. 9 The First Project Dataset Questionnaire form

Annex 3 shows an initial _dataset form_ oriented to the DMP preparation. This
form allowed the consortium to identify all the datasets and their owners and
the most important characteristics of each dataset. At the moment, the owners
of the datasets are the 6 Use Cases. The replies not relevant for the DMP have
been transferred to WP5 and WP6 teams.

##  2\. 10 The initial list of datasets

Thanks to the compiled forms, we identified the project’s first list of
datasets (some of which will be combined to create the envisioned holistic
health records – this is the case of HULAFE, DFKI, CRA):

  * DATASET 1: HULAFE 

  

  * DATASET 2: Stockholm County Council/ Karolinska University Hospital/SwedeHeart 

  

  * DATASET 3: Bio Data (DFKI) 

  

  * DATASET 4: Nutritional Data (DFKI) 

  

  * DATASET 5: Activity Data (DFKI) 

  

  * DATASET 6: Biosignals and Activity Data (BIO) 

  

  * DATASET 7: BIO-PHRs (Personal Health Records) (BIO) 

  

  * DATASET 8: Medication (BIO) 

  

  * DATASET 9: Allergies Dataset (BIO) 

  

  * DATASET 10: Social Data dataset (BIO) 

  

  * DATASET 11: CancerPatientData Dataset (CRA) 

  

  * DATASET 12: SLOfit Dataset (ULJ) 

  

  * DATASET 13: Lifestyle Dataset (ULJ) 

  

##  2\. 11 The FAIR Data Management Template Questionnaire

The initial forms and steps were required to understand the nature of the
datasets. It allowed to design the project architecture and to start the
development with less risks of a delay. But in order to share the information
later with other researchers, the public, etc., and to start the preparation
of the DMP draft, the consortium needed to fill in a more complete form: the
FAIR Data Management Template.

As described in the Guidelines of FAIR Data Management in Horizon 2020 [2],
this template is a set of questions that the partners should answer with a
level of detail appropriate to the project. For this first version it is not
required to provide detailed answers to all the questions.

The DMP is intended to be a living document in which information can be made
available gradually through successive updates as the implementation of the
project. New versions will be produced for the periodic reviews.

Section 3 shows the replies to the FAIR questionnaire of our use cases, what
is the core of this deliverable and will be updated in future versions of this
plan.

#  3\. CrowdHEALTH FAIR Data Management Plan

This section gathers all FAIR forms completed with information from the
project datasets.

##  3\. 1 DATASET 1: HULAFE  
  
<table>  
<tr>  
<th>

**DATASET 01**

</th>  
<th>

**NAME: Hospital La Fe Dataset (HULAFE)**

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

**1\. Data Summary**

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

1.1 Purpose

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

_The purpose of the data is mainly to:_

  * _Allow the data-driven modelling partners to develop risk stratification models for the risk of obesity, the chances of improving the condition, and the identification of population with obesity that have not been diagnosed yet –the under-diagnosis of obesity and overweight is a common and worldwide problem-._

  

  * _Allow the forecasting modelling partners and causal modelling partners to develop forecasting and causal models for aiding in the improvement of public health policies for overweight and obesity, regarding the goal of promoting the systematic detection of obesity and overweight citizens._

  

  * _To help policy makers in evaluating their actions by monitoring population trends in obesity on a clinical and regional level by using key performance indicators and the developed data-driven models._

  

  * _To aid policy makers in creating and evaluating policies relating to adult obesity and overweight by performing big data analysis on collected data. HHRs will provide an opportunity for performing data analysis and building health risk predictive models._

  

  * _To support the endocrinology service with information related to patients that at medium/high risk of becoming obese to carry out preventive actions, as well as giving feedback related to the already diagnosed obese patients._

  

  * _To improve the healthcare management, clinical and public health dashboards introducing Key Performance Indicators to improve the treatment and follow-up of patients with obesity and overweight._

  

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

1.2 Types and formats of data

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

_The data are structured. There are numeric and categorical variables. The
data are originally stored in SQL databases, and they are gathered through SQL
queries and exported in Excel, CSV or any other text formats for research and
data-analysis purposes._

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

1.3 Re-use of existing data

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

_Existing data could NEVER be used for other research projects._

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

1.4 Origin

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

_The data comes from Business Intelligence datamarts that at the same time
comes from some of the integrated databases of the Hospital La Fe Information
Systems IRIS and ORION._

_Additionally, data from the Primary Health Care System will be available and
integrated. This data comes from the databases of the Primary Care Information
Systems ABUCASIS._

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

1.5 Expected size

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

_N > 10.000 individuals, D > 85 variables. _

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

1.6 Data utility

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

_Endocrinologists, the endocrinology service is the main supporter of this
action as they need the information feedback to improve their health care
attention on obese citizens and patients; Data analysts and researchers, might
benefit from the data as they will provide answers on different research
questions regarding the problem of overweight and obesity; Public Health
Institutions, data might provide evidence regarding public health policy
making on the promotion of physical activity, nutrition habits and systematic
detection of obesity and overweight; Primary care professionals, who are the
first health care professionals to diagnose and treat obesity; and hospital
managers, who require information and indicators to take evidence-based
decisions._

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

**2 FAIR Data**

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

**2.1 Making data findable, including provisions for metadata**

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

2.1.1 Are the data produced and/or used in the project discoverable with
metadata, identifiable and locatable by means of a standard identification
mechanism?

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

_The data uses a Unique Random Identifier, they are anonymized and de-
identified. We use generalization and suppression mechanisms to guarantee de-
identification._

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

2.1.2 What naming conventions do you follow?

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

_None._

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

2.1.3 Will search keywords be provided that optimize possibilities for re-use?

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

_No._

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

2.1.4 Do you provide clear version numbers?

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

_We use the date of extraction._

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

2.1.5 What metadata will be created?

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

_None._

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

**2.2 Making data openly accessible**

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

2.2.1 Which data produced and/or used in the project will be made openly
available as the default?

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

_The dataset will only be available for the data analyst partners during the
CrowdHEALTH project upon the signature of a Non-Disclosure Agreement._

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

2.2.2 How will the data be made accessible?

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

_The data will be made accessible using a Hospital La Fe cloud repository._

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

2.2.3 What methods or software tools are needed to access the data?

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

_A web browser._

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

2.2.4 Is documentation about the software needed to access the data included?

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

_No._

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

2.2.5 Is it possible to include the relevant software?

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

_N/A._

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

2.2.6 Where will the data and associated metadata, documentation and code be
deposited?

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

_Hospital La Fe Cloud._

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

2.2.7 Have you explored appropriate arrangements with the identified
repository?

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

_No._

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

2.2.8 If there are restrictions on use, how will access be provided?

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

_Encrypted and compressed files will be available to those partners who signed
a Confidential NonDisclosure Agreement. After the signature a login and a
password will be provided to these partners to get access to those files._

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

2.2.9 Is there a need for a data access committee?

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

_No._

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

2.2.10 Are there well described conditions for access?

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

_To be described by the end of November._

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

2.2.11 How will the identity of the person accessing the data be ascertained?

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

_User login and password._

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

**2.3 Making data interoperable**

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

2.3.1 Are the data produced in the project interoperable?

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

_No._

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

2.3.2 What data and metadata vocabularies, standards or methodologies will you
follow to make your data interoperable?

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

_Only the information about diagnosis are described using ICD-9-CM codes._

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

2.3.3 Will you be using standard vocabularies for all data types present in
your data set, to allow interdisciplinary interoperability?

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

_No._

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

2.3.4 In case it is unavoidable that you use uncommon or generate project
specific ontologies or vocabularies, will you provide mappings to more
commonly used ontologies?

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

_No._

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

**2.4 Increase data re-use (through clarifying licenses)**

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

2.4.1 How will the data be licensed to permit the widest re-use possible?

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

_The data will not be licensed for any re-use._

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

2.4.2 When will the data be made available for re-use?

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

_Data will never be available for re-use._

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

2.4.3 Are the data produced and/or used in the project useable by third
parties, in particular after the end of the project?

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

_The use of the data is limited to the framework of the project. Any re-use of
the data after the project is forbidden by the Legal & Ethical Committee of
Hospital La Fe and the Spanish law for data protection (Ley Orgánica 15/1999,
de 13 de diciembre, de Protección de Datos de Carácter Personal). Once the
project is finished any data should be destroyed by any partner doing research
with them. _

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

2.4.4 How long is it intended that the data remains re-usable?

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

_N/A_

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

2.4.5 Are data quality assurance processes described?

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

_No._

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

**3 Allocation of resources**

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

3.1 What are the costs for making data FAIR in your project?

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

_Unknown._

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

3.2 How will these be covered?

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

_Note that costs related to open access to research data are eligible as part
of the Horizon 2020 grant (if compliant with the Grant Agreement conditions)._

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

3.3 Who will be responsible for data management in your project?

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

_María Luisa Correcher Palau (head of the Business Intelligence Technologies
of Hospital La Fe)_

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

3.4 Are the resources for long term preservation discussed?

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

_No._

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

**4 Data security**

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

4.1 What provisions are in place for data security?

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

_Hospital La Fe has a Data Processing Center with both server and storage
infrastructure racks and communications infrastructure with separated
electrical panel area, with fire detection and protection systems, UPS and air
conditioning units for the area's own air conditioning and with RF-120
fireresistant walls. The access to the data is allowed only to authorized
staff with an active directory with user logins and encrypted passwords. The
Data Processing Center has also disk to disk and tape backup systems._

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

4.2 Is the data safely stored in certified repositories for long term
preservation and curation?

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

_Yes._

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

**5 Ethical aspects**

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

5.1 Are there any ethical or legal issues that can have an impact on data
sharing?

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

_Data from Electronic Health Records (EHRs) must be anonymized and de-
identified to protect patients’ privacy and obey the data protection
legislations specially when the data is to be used for research purposes
within any research project._

_Sensitive private information such as the name, surname, date of birth,
address, zip codes, and identity numbers must be suppressed. A random unique
identifier is needed to link the information of patients without any relation
to them in a way such that backtracking the patient is completely impossible._

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

5.2 Is informed consent for data sharing and long term preservation included
in questionnaires dealing with personal data?

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

_No questionnaires are going to be used in this Use Case._

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

**6 Other issues**

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

6.1 Do you make use of other national/funder/sectorial/departmental procedures
for data management? If yes, which ones?

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

_N/A_

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

##  3\. 2 DATASET 2: Stockholm County Council/ Karolinska University
Hospital/SwedeHeart (KI)  
  
<table>  
<tr>  
<th>

**DATASET 02**

</th>  
<th>

**NAME: Stockholm County Council/ Karolinska University Hospital/SwedeHeart**

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

**1\. Data Summary**

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

1.1 Purpose

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

_A patient diagnosed with one of listed ICD10 Codes for cardiovascular
diseases in Stockholm will be registered in two different databases. The first
one is the Stockholm County Database (VAL) which is responsible for collecting
information from all the hospitals in Stockholm County. The second one is the
SwedeHeart quality registry which is collecting information only for patients
with cardiovascular diseases nationally. More specifically, Swedheart is a
procedural and surgery-related registry, which gathers information, based on
the disease, patient’s risk profile, medical treatment processes and
laboratory results among others. The two databases are independent which means
that different information for the same patient is registered._

_We expect that the extraction of information from the databases _for the same
period_ (2006-2012) will give us the possibility to track the same patients.
Our assumption is strong and it is based on other research projects, which
have actualized similar procedures (SCREAM project). _

_Aims:_

  * _Provide the relevant data to the health analytics partners in order to develop models that can be used from the policy makers in order to identify causality relationships between events, forecast the development of cardiovascular diseases on a population based sample, explore clinical pathways and produce risk stratification outcomes._

  

  * _Create a new policy making data driven process factoring in information from sources that are currently functioning independently._

  

  * _Support the cardiovascular and policy making research community in Sweden._

  

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

1.2 Types and formats of data

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

_Both databases use the same format: .csv_

_The data will be static, meaning that we are going to get two extracts, one
from the VAL database and one from the SwedeHeart Quality registry._

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

1.3 Re-use of existing data

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

_As included in the databases described above_

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

1.4 Origin

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

_Already mentioned._

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

1.5 Expected size

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

_80.000 unique patients._

  * _Phase 1 : 5.000 (December 2017)_

  

  * _Phase 2: 25.000 (September 2018)_

  

  * _Phase 3: 80.000 (March 2019)_

  

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

1.6 Data utility

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

_KI’s use case scenario stakeholders._

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

**2 FAIR Data**

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

**2.1 Making data findable, including provisions for metadata**

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

2.1.1 Are the data produced and/or used in the project discoverable with
metadata, identifiable and locatable by means of a standard identification
mechanism?

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

_N/A_

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

2.1.2 What naming conventions do you follow?

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

None

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

2.1.3 Will search keywords be provided that optimize possibilities for re-use?

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

_No_

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

2.1.4 Do you provide clear version numbers?

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

_Yes. Extraction date_

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

2.1.5 What metadata will be created?

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

_None_

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

**2.2 Making data openly accessible**

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

2.2.1 Which data produced and/or used in the project will be made openly
available as the default?

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

_Samples of the dataset will be shared to the CrowdHEALTH partners responsible
for the data analysis during the project upon the signature of a Non-
Disclosure Agreement. The data should be used for training scripts, systems or
algorithms. The partners should have already implemented the GDPR regulations
in their organizations._

_It must be stated that, it is important to pseudonymise/code, and sometimes
double-code, the data and ensure that it is shared in a secure manner. If the
data is to be sent outside KI, it must be encrypted, or external partners may
be given access to a secure server at KI._

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

2.2.2 How will the data be made accessible?

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

_By deposition in a repository_

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

2.2.3 What methods or software tools are needed to access the data?

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

_Pull/Push methods_

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

2.2.4 Is documentation about the software needed to access the data included?

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

_No_

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

2.2.5 Is it possible to include the relevant software?

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

_No_

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

2.2.6 Where will the data and associated metadata, documentation and code be
deposited?

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

_N/A_

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

2.2.7 Have you explored appropriate arrangements with the identified
repository?

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

_No_

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

2.2.8 If there are restrictions on use, how will access be provided?

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

_N/A_

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

2.2.9 Is there a need for a data access committee?

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

_No_

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

2.2.10 Are there well described conditions for access?

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

_No_

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

2.2.11 How will the identity of the person accessing the data be ascertained?

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

_N/A_

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

**2.3 Making data interoperable**

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

2.3.1 Are the data produced in the project interoperable?

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

_-_

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

2.3.2 What data and metadata vocabularies, standards or methodologies will you
follow to make your data interoperable?

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

_ICD CODE 10_

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

2.3.3 Will you be using standard vocabularies for all data types present in
your data set, to allow interdisciplinary interoperability?

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

_Yes_

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

2.3.4 In case it is unavoidable that you use uncommon or generate project
specific ontologies or vocabularies, will you provide mappings to more
commonly used ontologies?

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

_Yes_

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

**2.4 Increase data re-use (through clarifying licenses)**

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

2.4.1 How will the data be licensed to permit the widest re-use possible?

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

_The data will not be licensed for any re-use._

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

2.4.2 When will the data be made available for re-use?

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

_Data will never be available for re-use_

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

2.4.3 Are the data produced and/or used in the project useable by third
parties, in particular after the end of the project?

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

_No_

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

2.4.4 How long is it intended that the data remains re-usable?

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

_-_

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

2.4.5 Are data quality assurance processes described?

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

_No_

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

**3 Allocation of resources**

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

3.1 What are the costs for making data FAIR in your project?

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

_No costs have been calculated for this purpose at the moment_

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

3.2 How will these be covered?

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

_If any costs are incurred, this will be covered from CrowdHEALTH_

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

3.3 Who will be responsible for data management in your project?

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

_LIME, Karolinska Institutet IT department. The IT department will assign
three data security managers:_

  * _Controller: the person who decides on the purpose of the personal data processing, irrespective of whether anyone else carries out the actual processing._

  

  * _Processor: the person who carries out the personal data processing on behalf of the controller. In GDPR the processor has a direct liability and direct responsibilities. This means, for example, that agreement relations should be updated and that assistants must themselves observe a large proportion of the requirements in GDPR._

  

  * _The Data Protection Officer (DPO) is a physical person who represents the liable instance in matters which relate to GDPR. Requirements governing the appointment of representatives for authorities._

  

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

3.4 Are the resources for long term preservation discussed?

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

_N/A_

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

**4 Data security**

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

4.1 What provisions are in place for data security?

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

_Karolinska Institutet is following the General Data Protection Regulation
(GDPR)_

_Data that will be used for the CrowdHEALTH project may only be gathered for
specific, expressly stated and justified purposes and may not be subsequently
processed in a manner which is incompatible with these purposes._

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

4.2 Is the data safely stored in certified repositories for long term
preservation and curation?

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

_Yes_

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

**5 Ethical aspects**

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

5.1 Are there any ethical or legal issues that can have an impact on data
sharing?

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

_After receiving ethical approval to handle the data, it is important that all
personal data is stored and worked on safely, and it needs to be protected
against unauthorized access. Personal data may only be stored in systems and
solutions that are approved for personal data at KI._

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

5.2 Is informed consent for data sharing and long term preservation included
in questionnaires dealing with personal data?

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

_We are not intending to use any questionnaires_

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

**6 Other issues**

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

6.1 Do you make use of other national/funder/sectorial/departmental procedures
for data management? If yes, which ones?

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

_N/A_

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

##  3\. 3 DATASET 3: Bio Data (DFKI)  
  
<table>  
<tr>  
<th>

**DATASET 3**

</th>  
<th>

**NAME: Bio Data (DFKI)**

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

**1\. Data Summary**

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

1.1 Purpose

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

_This data is collected to get an insight in the physical stress a user had
throughout the day._

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

1.2 Types and formats of data

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

_The collected data will be BioSnapshots (Heartrate, step counter - once per
minute) and sleep data (total sleep duration, list of individual sleep
intervals (REM, deep sleep, light sleep, awake…) with their respective
durations._

_The data will be stored in an SQL database and made available to the
CrowdHEALTH platform through the HHRs communicated through the CrowdHEALTH
platform._

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

1.3 Re-use of existing data

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

_No_

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

1.4 Origin

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

_The data will be aggregated by fitness trackers, i.e. fitbit devices._

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

1.5 Expected size

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

We expect to have data from up to 100 participants, entering per day about 1-2
sleep entries and up to 1440 BioSnapshot entries for at least a year. This
amounts to roughly 1.8 GB of data.

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

1.6 Data utility

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

_The data might be useful to detect relations between food intake, physical
activity, overall mood and sleep patterns, which are all three collected from
the same individuals over the same periods of time._

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

**2 FAIR Data**

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

**2.1 Making data findable, including provisions for metadata**

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

2.1.1 Are the data produced and/or used in the project discoverable with
metadata, identifiable and locatable by means of a standard identification
mechanism?

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

_Yes_

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

2.1.2 What naming conventions do you follow?

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

_Generally the java naming conventions are followed._

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

2.1.3 Will search keywords be provided that optimize possibilities for re-use?

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

_No_

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

2.1.4 Do you provide clear version numbers?

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

_No because the data will be gathered over time no versioning is possible._

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

2.1.5 What metadata will be created?

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

_The whole metadata and interoperability layer will be added via HRR and the
FHIR extensions._

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

**2.2 Making data openly accessible**

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

2.2.1 Which data produced and/or used in the project will be made openly
available as the default?

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

_Information gathered in the DFKI use case will be anonymized and made
available to CrowdHEALTH partners._

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

2.2.2 How will the data be made accessible?

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

_For our raw Data there will be pull interfaces and regular dumps. It will be
made available to the partners in deployed CrowdHEALTH platform instances by
being integrated into the HHRs of patients selected by the use case partners
HULAFE and CRA._

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

2.2.3 What methods or software tools are needed to access the data?

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

_The raw data will be provided as JSON and SQL Dumps, the SQL Dumps are
created from a mariadb 10 server._

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

2.2.4 Is documentation about the software needed to access the data included?

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

_No software will be needed for the raw data, there most likely will be a form
of data documentation._

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

2.2.5 Is it possible to include the relevant software?

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

_-_

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

2.2.6 Where will the data and associated metadata, documentation and code be
deposited?

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

_Data can be accessed directly with an API key associated to every involved
partner, but the best way to access it is via HHR._

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

2.2.7 Have you explored appropriate arrangements with the identified
repository?

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

_-_

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

2.2.8 If there are restrictions on use, how will access be provided?

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

_RESTful or RPC pull interface on the DFKI aggregation platform._

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

2.2.9 Is there a need for a data access committee?

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

_No_

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

2.2.10 Are there well described conditions for access?

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

_No_

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

2.2.11 How will the identity of the person accessing the data be ascertained?

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

_The access will be controlled by API keys_

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

**2.3 Making data interoperable**

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

2.3.1 Are the data produced in the project interoperable?

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

_Yes, but only in the HHR/FHIR representation._

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

2.3.2 What data and metadata vocabularies, standards or methodologies will you
follow to make your data interoperable?

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

_FHIR and the proposed FHIR extensions_

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

2.3.3 Will you be using standard vocabularies for all data types present in
your data set, to allow inter-disciplinary interoperability?

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

_yes_

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

2.3.4 In case it is unavoidable that you use uncommon or generate project
specific ontologies or vocabularies, will you provide mappings to more
commonly used ontologies?

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

_Yes, mappings to used source data sources will be made available_

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

**2.4 Increase data re-use (through clarifying licenses)**

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

2.4.1 How will the data be licensed to permit the widest re-use possible?

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

_The raw data will be only available for all partners in CrowdHEALTH, the data
integrated from it into the HHR/FHIR formatted data will be available under
same restrictions as the HULAFE and CRA data._

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

2.4.2 When will the data be made available for re-use?

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

_As soon as it is aggregated it will be available._

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

2.4.3 Are the data produced and/or used in the project useable by third
parties, in particular after the end of the project?

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

_The data will be reusable by third parties._

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

2.4.4 How long is it intended that the data remains re-usable?

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

_There will be no data maintenance from DFKI, the data is provided as-is._

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

2.4.5 Are data quality assurance processes described?

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

_No_

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

**3 Allocation of resources**

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

3.1 What are the costs for making data FAIR in your project?

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

_The HHR/FHIR formatted data is already defined FAIR._

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

3.2 How will these be covered?

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

_-_

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

3.3 Who will be responsible for data management in your project?

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

_Jan Janssen (DFKI)_

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

3.4 Are the resources for long term preservation discussed?

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

_The raw data will only be preserved for internal access by DFKI, the data
integrated from it into the HHR/FHIR formatted data will be under the same
long-term preservation policies as any other data from HULAFE and CRA._

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

**4 Data security**

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

4.1 What provisions are in place for data security?

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

_Raw data will be stored encrypted in a server room within the DFKI premises
with appropriate access restrictions._

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

4.2 Is the data safely stored in certified repositories for long term
preservation and curation?

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

_No, the raw data will not be safely stored for long term preservation and
curation, at least not for public access._

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

**5 Ethical aspects**

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

5.1 Are there any ethical or legal issues that can have an impact on data
sharing?

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

_The collected raw data cannot be shared without any ethical or legal issues._

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

5.2 Is informed consent for data sharing and long term preservation included
in questionnaires dealing with personal data?

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

_Yes_

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

**6 Other issues**

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

6.1 Do you make use of other national/funder/sectorial/departmental procedures
for data management? If yes, which ones?

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

_No_

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

##  3\. 4 DATASET 4: Nutritional Data (DFKI)  
  
<table>  
<tr>  
<th>

**DATASET 4**

</th>  
<th>

**NAME: Nutritional Data (DFKI)**

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

**1\. Data Summary**

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

1.1 Purpose

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

_This data is collected to get insight into the nutritional behaviour of
individuals, that is food composition, food types, quantity and nutritional
values._

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

1.2 Types and formats of data

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

 _General nutritional information about ingredients, recipes, allergens,
allergies and diets._  _Manually logged nutritional habits of the patients._

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

1.3 Re-use of existing data

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

_Partially._

_Some of the Ingredient and Recipe Data is collected from third party
services, and some of those data will not be publicly available, but in the
scope of the project all the data will be accessible._

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

1.4 Origin

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

  * _The nutritional information comes from public domain sources like the USDA Food Nutrition database._

  

  * _Recipes are gathered from several public domain sources, and some proprietary sources._

  

  * _LanguaL information is gathered from LanguaL._

  

  * _Translations are made with the help of DeepL._

  

  * _Lucene and Stanford NLP are used for matching purposes._

  

  * _The source is always marked and a cleanup based on the source is always possible._

  

  * _Only public domain data can be shared externally, in the scope of the project every consortium member gets access to all of the data._

  

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

1.5 Expected size

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

_We expect to have data from up to 60 participants, entering about 2-10 dishes
per day for a target duration of 1.5 years. The data will stored at DFKI, but
only aggregated nutritional information will be pushed into the CrowdHEALTH
platform. The collected data with all details will amount to 68 GB, from which
7 GB of aggregated nutritional information will be pushed into the CrowdHEALTH
platform by using optimal datatypes._

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

1.6 Data utility

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

_The data might be useful to detect relations between food intake, physical
activity, overall mood and sleep patterns, which are all three collected from
the same individuals over the same periods of time (please refer to
information about the different datasets of DFKI regarding the data collected
and correlated)._

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

**2 FAIR Data**

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

**2.1 Making data findable, including provisions for metadata**

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

2.1.1 Are the data produced and/or used in the project discoverable with
metadata, identifiable and locatable by means of a standard identification
mechanism?

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

_Yes_

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

2.1.2 What naming conventions do you follow?

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

_Generally the java naming conventions are followed._

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

2.1.3 Will search keywords be provided that optimize possibilities for re-use?

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

_No_

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

2.1.4 Do you provide clear version numbers?

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

_No because the data will be gathered over time no versioning is possible._

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

2.1.5 What metadata will be created?

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

_The whole metadata and interoperability layer will be added via HRR and the
FHIR extensions._

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

**2.2 Making data openly accessible**

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

2.2.1 Which data produced and/or used in the project will be made openly
available as the default?

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

_Every piece of information gathered in the DFKI use case will be available to
all CrowdHEALTH partners._

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

2.2.2 How will the data be made accessible?

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

_For the aggregated data there will be pull interfaces and regular dumps. It
will be made available to the partners in deployed CrowdHEALTH platform
instances by being integrated into the HHRs of patients selected by the use
case partners HULAFE._

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

2.2.3 What methods or software tools are needed to access the data?

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

_The raw data will be provided as JSON and SQL Dumps, the SQL Dumps are
created from a mariadb_

_10 server_

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

2.2.4 Is documentation about the software needed to access the data included?

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

_No software will be needed for the raw data, there most likely will be a form
of data documentation._

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

2.2.5 Is it possible to include the relevant software?

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

_-_

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

2.2.6 Where will the data and associated metadata, documentation and code be
deposited?

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

_Data can be accessed directly with an API key associated to every involved
partner, but the best way to access it is via HHR._

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

2.2.7 Have you explored appropriate arrangements with the identified
repository?

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

_-_

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

2.2.8 If there are restrictions on use, how will access be provided?

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

_RESTful or RPC pull interface on the DFKI aggregation platform._

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

2.2.9 Is there a need for a data access committee?

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

_No_

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

2.2.10 Are there well described conditions for access?

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

_No_

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

2.2.11 How will the identity of the person accessing the data be ascertained?

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

_The access will be controlled by API keys_

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

**2.3 Making data interoperable**

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

2.3.1 Are the data produced in the project interoperable?

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

_Yes, but only in the HHR/FHIR representation._

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

2.3.2 What data and metadata vocabularies, standards or methodologies will you
follow to make your data interoperable?

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

_FHIR and the proposed FHIR extensions._

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

2.3.3 Will you be using standard vocabularies for all data types present in
your data set, to allow interdisciplinary interoperability?

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

_Yes_

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

2.3.4 In case it is unavoidable that you use uncommon or generate project
specific ontologies or vocabularies, will you provide mappings to more
commonly used ontologies?

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

_Yes, mappings to used source data sources will be made available_

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

**2.4 Increase data re-use (through clarifying licenses)**

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

2.4.1 How will the data be licensed to permit the widest re-use possible?

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

_The aggregated data will be only available for all partners in CrowdHEALTH,
the data integrated from it into the HHR/FHIR formatted data will be available
under same restrictions as the HULAFE data._

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

2.4.2 When will the data be made available for re-use?

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

_As soon as it is aggregated it will be available._

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

2.4.3 Are the data produced and/or used in the project useable by third
parties, in particular after the end of the project?

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

_The data will be reusable by third parties._

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

2.4.4 How long is it intended that the data remains re-usable?

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

_There will be no data maintenance from DFKI, the data is provided as-is._

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

2.4.5 Are data quality assurance processes described?

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

_No_

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

**3 Allocation of resources**

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

3.1 What are the costs for making data FAIR in your project?

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

_The HHR/FHIR formatted data is already defined FAIR._

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

3.2 How will these be covered?

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

_-_

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

3.3 Who will be responsible for data management in your project?

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

_Jan Janssen (DFKI)_

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

3.4 Are the resources for long term preservation discussed?

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

_The aggregated data will only be preserved for internal access by DFKI, the
data integrated from it into the HHR/FHIR formatted data will be under the
same long-term preservation policies as any other data from HULAFE._

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

**4 Data security**

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

4.1 What provisions are in place for data security?

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

_Raw data will be stored encrypted in a server room within the DFKI premises
with appropriate access restrictions._

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

4.2 Is the data safely stored in certified repositories for long term
preservation and curation?

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

_No, the raw data will not be safely stored for long term preservation and
curation, at least not for public access._

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

**5 Ethical aspects**

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

5.1 Are there any ethical or legal issues that can have an impact on data
sharing?

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

_The collected raw data cannot be shared without any ethical or legal issues._

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

5.2 Is informed consent for data sharing and long term preservation included
in questionnaires dealing with personal data?

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

_Yes_

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

**6 Other issues**

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

6.1 Do you make use of other national/funder/sectorial/departmental procedures
for data management? If yes, which ones?

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

_No._

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

##  3\. 5 DATASET 5: Activity Data (DFKI)  
  
<table>  
<tr>  
<th>

**DATASET 5**

</th>  
<th>

**NAME: Activity Data (DFKI)**

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

**1\. Data Summary**

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

1.1 Purpose

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

_This data is collected to get in amount, duration, intensity and kind of
physical activities of individuals._

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

1.2 Types and formats of data

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

_Data of physical activities as detected from fitness trackers extended by
qualitative information provided by the participants about what activities
(social or physical) they performed._

_Automatically and manually logged (or manually enhanced) information about
the activities carried out._

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

1.3 Re-use of existing data

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

_Partially._

_Some of the Activity Types are gathered from public domain sources_

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

1.4 Origin

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

_Several public domain terminologies, DFKI added and user added data._

_The source is always marked and a cleanup based on the source is always
possible._

_Only public domain data can be shared externally, in the scope of the project
every consortium member gets access to all of the data._

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

1.5 Expected size

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

_We expect to have data from up to 100 participants, entering about 2-10
entries per day for a period of 1,5 years. This will amount then to approx. 1
GB of data using optimal datatypes._

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

1.6 Data utility

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

_The data might be useful to detect relations between food intake, physical
activity, overall mood and sleep patterns._

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

**2 FAIR Data**

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

**2.1 Making data findable, including provisions for metadata**

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

2.1.1 Are the data produced and/or used in the project discoverable with
metadata, identifiable and locatable by means of a standard identification
mechanism?

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

_Yes_

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

2.1.2 What naming conventions do you follow?

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

_Generally the java naming conventions are followed._

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

2.1.3 Will search keywords be provided that optimize possibilities for re-use?

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

_No_

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

2.1.4 Do you provide clear version numbers?

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

_No because the data will be gathered over time no versioning is possible._

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

2.1.5 What metadata will be created?

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

_The whole metadata and interoperability layer will be added via HRR and the
FHIR extensions._

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

**2.2 Making data openly accessible**

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

2.2.1 Which data produced and/or used in the project will be made openly
available as the default?

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

_Every piece of information gathered in the DFKI use case will be available to
all CrowdHEALTH partners._

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

2.2.2 How will the data be made accessible?

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

_For our raw Data there will be pull interfaces and regular dumps. It will be
made available to the partners in deployed CrowdHEALTH platform instances by
being integrated into the HHRs of patients selected by the use case partners
HULAFE and CRA._

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

2.2.3 What methods or software tools are needed to access the data?

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

_The raw data will be provided as JSON and SQL Dumps, the SQL Dumps are
created from a mariadb_

_10 server_

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

2.2.4 Is documentation about the software needed to access the data included?

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

_No software will be needed for the raw data, there most likely will be a form
of data documentation._

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

2.2.5 Is it possible to include the relevant software?

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

_-_

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

2.2.6 Where will the data and associated metadata, documentation and code be
deposited?

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

_Data can be accessed directly with an API key associated to every involved
partner, but the best way to access it is via HHR._

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

2.2.7 Have you explored appropriate arrangements with the identified
repository?

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

_-_

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

2.2.8 If there are restrictions on use, how will access be provided?

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

_RESTful or RPC pull interface on the DFKI aggregation platform._

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

2.2.9 Is there a need for a data access committee?

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

_No._

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

2.2.10 Are there well described conditions for access?

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

_No._

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

2.2.11 How will the identity of the person accessing the data be ascertained?

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

_The access will be controlled by API keys_

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

**2.3 Making data interoperable**

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

2.3.1 Are the data produced in the project interoperable?

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

_Yes, but only in the HHR/FHIR representation._

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

2.3.2 What data and metadata vocabularies, standards or methodologies will you
follow to make your data interoperable?

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

_FHIR and the proposed FHIR extensions_

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

2.3.3 Will you be using standard vocabularies for all data types present in
your data set, to allow interdisciplinary interoperability?

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

_Yes._

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

2.3.4 In case it is unavoidable that you use uncommon or generate project
specific ontologies or vocabularies, will you provide mappings to more
commonly used ontologies?

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

_Yes, mappings to used source data sources will be made available_

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

**2.4 Increase data re-use (through clarifying licenses)**

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

2.4.1 How will the data be licensed to permit the widest re-use possible?

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

_The raw data will be only available for all partners in CrowdHEALTH, the data
integrated from it into the HHR/FHIR formatted data will be available under
same restrictions as the HULAFE and CRA data._

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

2.4.2 When will the data be made available for re-use?

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

_As soon as it is aggregated it will be available._

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

2.4.3 Are the data produced and/or used in the project useable by third
parties, in particular after the end of the project?

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

_The data will be reusable by third parties._

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

2.4.4 How long is it intended that the data remains re-usable?

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

_There will be no data maintenance from DFKI, the data is provided as-is._

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

2.4.5 Are data quality assurance processes described?

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

_No._

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

**3 Allocation of resources**

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

3.1 What are the costs for making data FAIR in your project?

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

_The HHR/FHIR formatted data is already defined FAIR._

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

3.2 How will these be covered?

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

_-_

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

3.3 Who will be responsible for data management in your project?

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

_Jan Janssen (DFKI)_

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

3.4 Are the resources for long term preservation discussed?

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

_The raw data will only be preserved for internal access by DFKI, the data
integrated from it into the HHR/FHIR formatted data will be under the same
long-term preservation policies as any other data from HULAFE and CRA._

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

**4 Data security**

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

4.1 What provisions are in place for data security?

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

_Raw data will be stored encrypted in a server room within the DFKI premises
with appropriate access restrictions._

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

4.2 Is the data safely stored in certified repositories for long term
preservation and curation?

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

_No, the raw data will not be safely stored for long term preservation and
curation, at least not for public access._

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

**5 Ethical aspects**

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

5.1 Are there any ethical or legal issues that can have an impact on data
sharing?

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

_The collected raw data cannot be shared without any ethical or legal issues._

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

5.2 Is informed consent for data sharing and long term preservation included
in questionnaires dealing with personal data?

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

_Yes._

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

**6 Other issues**

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

6.1 Do you make use of other national/funder/sectorial/departmental procedures
for data management? If yes, which ones?

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

_No._

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

##  3\. 6 DATASET 6: Biosignals and Activity Data (BIO)  
  
<table>  
<tr>  
<th>

**DATASET 6**

</th>  
<th>

**NAME: Biosignals and Activity Data**

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

**1\. Data Summary**

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

1.1 Purpose

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

_Chronic disease management calls for constant monitoring of specific vital
signs, while physical activity levels are an important parameter for assessing
a patient’s lifestyle and wellness. Proper analysis of these data can assist
clinicians in effective decision-making and can provide policy makers the
means to measure the impact of relevant policies with respect to a
population’s health, changes in patient behaviour and quality of life._

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

1.2 Types and formats of data

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

_The dataset includes historical data. More specifically, the types of
measurements included are:_

  * _Oxygen saturation_

  

  * _Blood pressure_

  

  * _Blood glucose_

  

  * _Spirometry_

  

  * _Weight_

  

  * _Step count_  _Mood_

  

_Each measurement is accompanied by a timestamp. The data are currently
structured in a custom format for internal use in the BioAssist platform and
can be extracted in JSON or CSV format. However, they will be shared with
CrowdHEALTH in a FHIR format_ 2  _as Observations._

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

1.3 Re-use of existing data

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

_The dataset comprises data collected within the frame of BioAssist’s piloting
activities throughout the past year and is continuously growing. All data that
are already available will be used and new data will be continuously fed to
the CrowdHEALTH platform._

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

1.4 Origin

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

_The data are collected from patients participating in BioAssist’s piloting
operations. Biosignal measurements are collected from a variety of sensors
(pulse oximeter, blood pressure meter, glucometer, weighing scale) and
activity data are collected from wearable activity trackers. This dataset also
includes patients’ daily mood, which is self-reported via BioAssist’s app._

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

1.5 Expected size

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

_Approximately 100 patients are enrolled in BioAssist’s pilots. Each patient
performs daily measurements of at least two types of biosignals and mood self-
report, and uses the platform’s communication features twice a week on
average. Within the next couple of months, these patients will also be
provided with activity trackers, which will allow them to record their daily
step count. This amounts to a dataset of more than 100,000 observations, which
is continuously growing._

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

1.6 Data utility

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

_To the patients’ attending doctors, as well as potentially interested policy
makers._

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

**2 FAIR Data**

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

**2.1 Making data findable, including provisions for metadata**

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

2.1.1 Are the data produced and/or used in the project discoverable with
metadata, identifiable and locatable by means of a standard identification
mechanism?

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

_Yes, the data include identifiers (patient name, observation ID), but after
anonymisation they will not be identifiable._

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

2.1.2 What naming conventions do you follow?

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

_At the moment, the dataset utilises the SNOMED terminology, but any other
standard can be applied if required (e.g. LOINC)._

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

2.1.3 Will search keywords be provided that optimize possibilities for re-use?

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

_Yes._

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

2.1.4 Do you provide clear version numbers?

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

_No._

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

2.1.5 What metadata will be created?

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

_Biosignal measurements are accompanied by the sensor model and in some cases
with metadata created by the sensor related to the quality of the
measurement._

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

**2.2 Making data openly accessible**

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

2.2.1 Which data produced and/or used in the project will be made openly
available as the default?

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

_The dataset shall become available to the consortium after anonymization,
when permission by the Greek Data Protection Authority is obtained. Legal
restrictions do not permit open access to the data._

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

2.2.2 How will the data be made accessible?

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

_The data will be pushed to the CrowdHEALTH big data platform and underlying
store._

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

2.2.3 What methods or software tools are needed to access the data?

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

_The platform provides an API for obtaining the data. This API can be used to
access them._

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

2.2.4 Is documentation about the software needed to access the data included?

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

_Not Required._

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

2.2.5 Is it possible to include the relevant software?

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

_N/A_

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

2.2.6 Where will the data and associated metadata, documentation and code be
deposited?

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

_Legal constraints do not permit us to provide open access to these data. The
data will be deposited on a local deployment of the CrowdHEALTH platform and
will be accessible only within the project._

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

2.2.7 Have you explored appropriate arrangements with the identified
repository?

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

_N/A_

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

2.2.8 If there are restrictions on use, how will access be provided?

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

_The data will only be accessible for use to authorised users of the
platform._

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

2.2.9 Is there a need for a data access committee?

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

_We do not foresee the need for a data access committee at the moment. This
will be verified when the process for obtaining permission by the Greek Data
Protection Authority is completed._

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

2.2.10 Are there well described conditions for access?

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

_No._

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

2.2.11 How will the identity of the person accessing the data be ascertained?

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

_This will be handled by the CrowdHEALTH user authentication and access
control components._

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

**2.3 Making data interoperable**

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

2.3.1 Are the data produced in the project interoperable?

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

_The data are currently in custom format, but will be shared within the
project in FHIR format._

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

2.3.2 What data and metadata vocabularies, standards or methodologies will you
follow to make your data interoperable?

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

_At the moment, the dataset utilises the SNOMED terminology, but any other
standard can be applied if required (e.g. LOINC)._

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

2.3.3 Will you be using standard vocabularies for all data types present in
your data set, to allow interdisciplinary interoperability?

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

_Yes._

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

2.3.4 In case it is unavoidable that you use uncommon or generate project
specific ontologies or vocabularies, will you provide mappings to more
commonly used ontologies?

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

_There is no need to provide mappings._

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

**2.4 Increase data re-use (through clarifying licenses)**

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

2.4.1 How will the data be licensed to permit the widest re-use possible?

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

_The data will not be available for re-use._

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

2.4.2 When will the data be made available for re-use?

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

_N/A_

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

2.4.3 Are the data produced and/or used in the project useable by third
parties, in particular after the end of the project?

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

_N/A_

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

2.4.4 How long is it intended that the data remains re-usable?

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

_N/A_

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

2.4.5 Are data quality assurance processes described?

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

_N/A_

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

**3 Allocation of resources**

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

3.1 What are the costs for making data FAIR in your project?

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

_There may be costs related to e.g. legal support, but they cannot be
estimated at the moment. All other known costs are already covered by the
project._

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

3.2 How will these be covered?

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

_This will depend on the nature of the costs that will arise._

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

3.3 Who will be responsible for data management in your project?

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

_BioAssist’s CTO._

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

3.4 Are the resources for long term preservation discussed?

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

_This has not been discussed yet._

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

**4 Data security**

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

4.1 What provisions are in place for data security?

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

_BioAssist has developed state-of-the-art security, business continuity and
data retention plans which are currently in place._

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

4.2 Is the data safely stored in certified repositories for long term
preservation and curation?

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

_At the moment, all data are stored only on BioAssist’s database._

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

**5 Ethical aspects**

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

5.1 Are there any ethical or legal issues that can have an impact on data
sharing?

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

_Ethical issues have already been resolved. Permission from the Greek Data
Protection Authority is required before the (anonymised) dataset can be shared
with the partners. Legal restrictions do not permit open access to this
dataset._

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

5.2 Is informed consent for data sharing and long term preservation included
in questionnaires dealing with personal data?

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

_Yes, all patients that are supplying data to this dataset have signed
informed consent._

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

**6 Other issues**

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

6.1 Do you make use of other national/funder/sectorial/departmental procedures
for data management? If yes, which ones?

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

_Not at the moment._

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

##  3\. 7 DATASET 7: BIO-PHRs (Personal Health Records) (BIO)  
  
<table>  
<tr>  
<th>

**DATASET 7**

</th>  
<th>

**NAME: BIO-PHRs (Personal Health Records)**

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

**1\. Data Summary**

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

1.1 Purpose

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

_Medical test results of patients enrolled in BioAssist’s pilots are collected
from primary healthcare providers, in order to provide their doctors with
access to this information and support them in monitoring their patients’
health status. Analysis of such data can be useful in tasks such as assessment
of clinical pathways._

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

1.2 Types and formats of data

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

_The dataset contains historical data. Each entry includes a timestamp,
category, description, comments, result type (numeric/description), result
value and unit, as well as a reference range. Currently the data are
structured in a custom format for internal use in the BioAssist platform and
can be extracted in JSON or CSV format. However, they will be shared with
CrowdHEALTH in a FHIR format as Observations._

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

1.3 Re-use of existing data

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

_The dataset comprises PHR data collected within the frame of BioAssist’s
piloting activities throughout the past year and is continuously growing. All
data that are already available will be used and new data will be continuously
fed to the CrowdHEALTH platform automatically whenever new results are
generated._

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

1.4 Origin

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

_The data are collected from primary healthcare providers via appropriate web
services and stored on the BioAssist platform. Some entries may be manual
inputs from the platform’s users._

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

1.5 Expected size

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

_Approximately 100 patients are enrolled in BioAssist’s pilots. The average
number of entries in a patient’s PHR is more than 200, although some patients’
PHRs may contain no entries yet._

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

1.6 Data utility

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

_To the patients’ attending doctors, as well as potentially interested policy
makers._

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

**2 FAIR Data**

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

**2.1 Making data findable, including provisions for metadata**

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

2.1.1 Are the data produced and/or used in the project discoverable with
metadata, identifiable and locatable by means of a standard identification
mechanism?

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

_No._

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

2.1.2 What naming conventions do you follow?

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

_At the moment, the dataset utilises the SNOMED terminology, but any other
standard can be applied if required (e.g. LOINC)._

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

2.1.3 Will search keywords be provided that optimize possibilities for re-use?

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

_Yes_

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

2.1.4 Do you provide clear version numbers?

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

_No_

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

2.1.5 What metadata will be created?

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

_No metadata is created._

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

**2.2 Making data openly accessible**

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

2.2.1 Which data produced and/or used in the project will be made openly
available as the default?

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

_The dataset shall become available to all partners in the CrowdHEALTH project
after anonymisation, when permission by the Greek Data Protection Authority is
obtained. Legal restrictions do not permit open access to the data._

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

2.2.2 How will the data be made accessible?

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

_The data will be pushed to the CrowdHEALTH GW._

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

2.2.3 What methods or software tools are needed to access the data?

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

_All software tools required to access the data will be developed as
components of the CrowdHEALTH platform._

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

2.2.4 Is documentation about the software needed to access the data included?

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

_Not Required._

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

2.2.5 Is it possible to include the relevant software?

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

_N/A_

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

2.2.6 Where will the data and associated metadata, documentation and code be
deposited?

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

_Legal constraints do not permit us to provide open access to these data. The
data will be deposited on a local deployment of the CrowdHEALTH platform and
will be accessible only within the project._

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

2.2.7 Have you explored appropriate arrangements with the identified
repository?

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

_N/A_

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

2.2.8 If there are restrictions on use, how will access be provided?

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

_The data will only be accessible for use to authorised users of the
platform._

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

2.2.9 Is there a need for a data access committee?

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

_We do not foresee the need for a data access committee at the moment. This
will be verified when the process for obtaining permission by the Greek Data
Protection Authority is completed._

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

2.2.10 Are there well described conditions for access?

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

_No._

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

2.2.11 How will the identity of the person accessing the data be ascertained?

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

_This will be handled by the CrowdHEALTH user authentication and access
control components._

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

**2.3 Making data interoperable**

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

2.3.1 Are the data produced in the project interoperable?

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

_The data are currently in a custom format, but will be shared within the
project in FHIR format._

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

2.3.2 What data and metadata vocabularies, standards or methodologies will you
follow to make your data interoperable?

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

_At the moment, the dataset does not utilize any standard. A standard will be
applied depending on the standard that will eventually be used for dataset 6._

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

2.3.3 Will you be using standard vocabularies for all data types present in
your data set, to allow interdisciplinary interoperability?

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

_It is not certain at the moment._

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

2.3.4 In case it is unavoidable that you use uncommon or generate project
specific ontologies or vocabularies, will you provide mappings to more
commonly used ontologies?

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

_There is no need to provide mappings._

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

**2.4 Increase data re-use (through clarifying licenses)**

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

2.4.1 How will the data be licensed to permit the widest re-use possible?

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

_The data will not be available for re-use._

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

2.4.2 When will the data be made available for re-use?

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

_N/A_

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

2.4.3 Are the data produced and/or used in the project useable by third
parties, in particular after the end of the project?

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

_N/A_

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

2.4.4 How long is it intended that the data remains re-usable?

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

_N/A_

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

2.4.5 Are data quality assurance processes described?

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

_N/A_

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

**3 Allocation of resources**

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

3.1 What are the costs for making data FAIR in your project?

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

_There may be costs related to e.g. legal support, but they cannot be
estimated at the moment. All other known costs are already covered by the
project._

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

3.2 How will these be covered?

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

_This depends on the nature of the costs that will arise._

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

3.3 Who will be responsible for data management in your project?

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

_BioAssist’s CTO._

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

3.4 Are the resources for long term preservation discussed?

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

_This has not been discussed yet._

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

**4 Data security**

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

4.1 What provisions are in place for data security?

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

_BioAssist has developed state-of-the-art security, business continuity and
data retention plans which are currently in place._

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

4.2 Is the data safely stored in certified repositories for long term
preservation and curation?

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

_At the moment, all data are stored only on BioAssist’s database._

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

**5 Ethical aspects**

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

5.1 Are there any ethical or legal issues that can have an impact on data
sharing?

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

_Ethical issues have already been resolved. Permission from the Greek Data
Protection Authority is required before the (anonymised) dataset can be shared
with the partners. Legal restrictions do not permit open access to this
dataset._

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

5.2 Is informed consent for data sharing and long term preservation included
in questionnaires dealing with personal data?

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

_Yes, all patients that are supplying data to this dataset have signed
informed consent._

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

**6 Other issues**

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

6.1 Do you make use of other national/funder/sectorial/departmental procedures
for data management? If yes, which ones?

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

_Not at the moment._

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

##  3\. 8 DATASET 8: Medication (BIO)  
  
<table>  
<tr>  
<th>

**DATASET 8**

</th>  
<th>

**NAME: Medication**

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

**1\. Data Summary**

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

1.1 Purpose

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

_Patients’ prescribed medications are recorded by their attending doctors on
the BioAssist platform, in order to maintain a comprehensive profile for each
patient and encourage medication adherence with reminders. This data can be
used for patient profiling and assessment of clinical pathways._

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

1.2 Types and formats of data

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

_This dataset includes prescribed medications of patients enrolled in
BioAssist’s pilots. Each entry includes active ingredient, brand name, drug
form (e.g. tab, capsule, etc.), strength and dose time. It is currently
structured in a custom format, but will be shared within the CrowdHEALTH in a
FHIR format._

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

1.3 Re-use of existing data

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

_Medication data are constantly updated. All modifications to the medication
list are logged (with timestamps). The dataset includes data collected within
the past year and new data are added continuously._

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

1.4 Origin

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

_Medication data is mainly collected from manual inputs from doctors._

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

1.5 Expected size

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

_Prescribed medications are also recorded for all patients (approximately 100
people) enrolled in BioAssist’s pilots and this data can be linked to the
other datasets. The average number of medication doses for each patient is
more than 2 per day. BioAssist will also pursue additions to the dataset with
data from Greek national authorities following the respective approvals._

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

1.6 Data utility

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

_To the patients’ attending doctors, as well as potentially interested policy
makers._

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

**2 FAIR Data**

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

**2.1 Making data findable, including provisions for metadata**

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

2.1.1 Are the data produced and/or used in the project discoverable with
metadata, identifiable and locatable by means of a standard identification
mechanism?

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

_No._

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

2.1.2 What naming conventions do you follow?

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

_N/A_

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

2.1.3 Will search keywords be provided that optimize possibilities for re-use?

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

_N/A_

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

2.1.4 Do you provide clear version numbers?

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

_No_

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

2.1.5 What metadata will be created?

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

_No metadata are created_

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

**2.2 Making data openly accessible**

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

2.2.1 Which data produced and/or used in the project will be made openly
available as the default?

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

_The dataset shall become available to the consortium after anonymization,
when permission by the Greek Data Protection Authority is obtained. Legal
restrictions do not permit open access to the data._

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

2.2.2 How will the data be made accessible?

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

_The data will be pushed to the CrowdHEALTH GW._

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

2.2.3 What methods or software tools are needed to access the data?

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

_All software tools required to access the data will be developed as
components of the CrowdHEALTH platform._

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

2.2.4 Is documentation about the software needed to access the data included?

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

_Not Required._

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

2.2.5 Is it possible to include the relevant software?

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

_N/A_

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

2.2.6 Where will the data and associated metadata, documentation and code be
deposited?

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

_Legal constraints do not permit us to provide open access to these data. The
data will be deposited on a local deployment of the CrowdHEALTH platform and
will only be accessible within the project._

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

2.2.7 Have you explored appropriate arrangements with the identified
repository?

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

_N/A_

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

2.2.8 If there are restrictions on use, how will access be provided?

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

_The data will only be accessible for use by authorised users of the
platform._

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

2.2.9 Is there a need for a data access committee?

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

_We do not foresee the need for a data access committee at the moment. This
will be verified when the process for obtaining permission by the Greek Data
Protection Authority is completed._

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

2.2.10 Are there well described conditions for access?

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

_No_

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

2.2.11 How will the identity of the person accessing the data be ascertained?

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

_This will be handled by the CrowdHEALTH user authentication and access
control components._

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

**2.3 Making data interoperable**

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

2.3.1 Are the data produced in the project interoperable?

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

_The data are currently in custom format, but will be shared within the
project in FHIR format._

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

2.3.2 What data and metadata vocabularies, standards or methodologies will you
follow to make your data interoperable?

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

_At the moment, the dataset does not utilize any standard. A standard may be
applied depending on the standard that will eventually be used for dataset 6._

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

2.3.3 Will you be using standard vocabularies for all data types present in
your data set, to allow interdisciplinary interoperability?

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

_It is not certain at the moment._

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

2.3.4 In case it is unavoidable that you use uncommon or generate project
specific ontologies or vocabularies, will you provide mappings to more
commonly used ontologies?

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

_There is no need to provide mappings._

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

**2.4 Increase data re-use (through clarifying licenses)**

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

2.4.1 How will the data be licensed to permit the widest re-use possible?

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

_The data will not be available for re-use._

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

2.4.2 When will the data be made available for re-use?

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

_N/A_

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

2.4.3 Are the data produced and/or used in the project useable by third
parties, in particular after the end of the project?

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

_N/A_

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

2.4.4 How long is it intended that the data remains re-usable?

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

_N/A_

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

2.4.5 Are data quality assurance processes described?

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

_N/A_

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

**3 Allocation of resources**

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

3.1 What are the costs for making data FAIR in your project?

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

_There may be costs related to e.g. legal support, but they cannot be
estimated at the moment. All other known costs are already covered by the
project._

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

3.2 How will these be covered?

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

_This will depend on the nature of the costs that will arise._

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

3.3 Who will be responsible for data management in your project?

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

_BioAssist’s CTO._

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

3.4 Are the resources for long term preservation discussed?

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

_This has not been discussed yet._

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

**4 Data security**

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

4.1 What provisions are in place for data security?

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

_BioAssist has developed state-of-the-art security, business continuity and
data retention plans which are currently in place._

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

4.2 Is the data safely stored in certified repositories for long term
preservation and curation?

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

_At the moment, all data are stored only on BioAssist’s database._

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

**5 Ethical aspects**

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

5.1 Are there any ethical or legal issues that can have an impact on data
sharing?

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

_Ethical issues have already been resolved. Permission from the Greek Data
Protection Authority is required before the (anonymised) dataset can be shared
with the partners. Legal restrictions do not permit open access to this
dataset._

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

5.2 Is informed consent for data sharing and long term preservation included
in questionnaires dealing with personal data?

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

_Yes, all patients that are supplying data to this dataset have signed
informed consent._

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

**6 Other issues**

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

6.1 Do you make use of other national/funder/sectorial/departmental procedures
for data management? If yes, which ones?

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

_Not at the moment._

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

##  3\. 9 DATASET 9: Allergies Dataset (BIO)  
  
<table>  
<tr>  
<th>

**DATASET 9**

</th>  
<th>

**NAME: Allergies Dataset**

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

**1\. Data Summary**

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

1.1 Purpose

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

_Users of the BioAssist platform can manually input their allergies, adding
useful information for attending doctors. These data can be utilized for
patient profiling._

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

1.2 Types and formats of data

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

_This dataset includes recorded allergies of patients enrolled in BioAssist’s
pilots. Allergy data can be considered static. Entries are allergens in text
format._

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

1.3 Re-use of existing data

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

_This is a static dataset. Only existing data will be used._

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

1.4 Origin

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

_Allergy data is mainly collected from manual inputs from doctors._

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

1.5 Expected size

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

_This dataset does not contain a large number of records, as very few patients
enrolled in BioAssist’s pilots have reported allergies. However, this data
will be useful when linked to the other datasets._

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

1.6 Data utility

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

_Patients’ attending doctors._

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

**2 FAIR Data**

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

**2.1 Making data findable, including provisions for metadata**

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

2.1.1 Are the data produced and/or used in the project discoverable with
metadata, identifiable and locatable by means of a standard identification
mechanism?

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

_No._

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

2.1.2 What naming conventions do you follow?

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

_No naming conventions are followed at the moment._

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

2.1.3 Will search keywords be provided that optimize possibilities for re-use?

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

_-_

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

2.1.4 Do you provide clear version numbers?

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

_No_

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

2.1.5 What metadata will be created?

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

_No metadata are created._

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

**2.2 Making data openly accessible**

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

2.2.1 Which data produced and/or used in the project will be made openly
available as the default?

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

_The dataset shall become available to all partners after anonymization, when
permission by the Greek Data Protection Authority is obtained._

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

2.2.2 How will the data be made accessible?

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

_The data will be pushed to the CrowdHEALTH GW._

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

2.2.3 What methods or software tools are needed to access the data?

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

_All software tools required to access the data will be developed as
components of the CrowdHEALTH platform._

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

2.2.4 Is documentation about the software needed to access the data included?

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

_Not Required._

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

2.2.5 Is it possible to include the relevant software?

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

_N/A_

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

2.2.6 Where will the data and associated metadata, documentation and code be
deposited?

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

_Legal constraints do not permit us to provide open access to these data. The
data will be deposited on a local deployment of the CrowdHEALTH platform and
will be accessible only within the project._

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

2.2.7 Have you explored appropriate arrangements with the identified
repository?

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

_N/A_

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

2.2.8 If there are restrictions on use, how will access be provided?

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

_The data will only be accessible for use to authorised users of the
platform._

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

2.2.9 Is there a need for a data access committee?

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

_We do not foresee the need for a data access committee at the moment. This
will be verified when the process for obtaining permission by the Greek Data
Protection Authority is completed._

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

2.2.10 Are there well described conditions for access?

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

_No._

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

2.2.11 How will the identity of the person accessing the data be ascertained?

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

_This will be handled by the CrowdHEALTH user authentication and access
control components._

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

**2.3 Making data interoperable**

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

2.3.1 Are the data produced in the project interoperable?

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

_The data are currently in custom format, but will be shared within the
project in FHIR format._

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

2.3.2 What data and metadata vocabularies, standards or methodologies will you
follow to make your data interoperable?

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

_At the moment, the dataset does not utilize any standard. A standard may be
applied depending on the standard that will eventually be used for dataset 6._

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

2.3.3 Will you be using standard vocabularies for all data types present in
your data set, to allow interdisciplinary interoperability?

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

_Yes._

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

2.3.4 In case it is unavoidable that you use uncommon or generate project
specific ontologies or vocabularies, will you provide mappings to more
commonly used ontologies?

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

There is no need to provide mappings.

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

**2.4 Increase data re-use (through clarifying licenses)**

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

2.4.1 How will the data be licensed to permit the widest re-use possible?

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

_The data will not be available for re-use._

</td> </tr>  
<tr>  
<td>

2.4.2 When will the data be made available for re-use?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.4.3 Are the data produced and/or used in the project useable by third
parties, in particular after the end of the project?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.4.4 How long is it intended that the data remains re-usable?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.4.5 Are data quality assurance processes described?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

**3 Allocation of resources**

</td> </tr>  
<tr>  
<td>

3.1 What are the costs for making data FAIR in your project?

</td> </tr>  
<tr>  
<td>

_There may be costs related to e.g. legal support, but they cannot be
estimated at the moment. All other known costs are already covered by the
project._

</td> </tr>  
<tr>  
<td>

3.2 How will these be covered?

</td> </tr>  
<tr>  
<td>

_This will depend on the nature of the costs that will arise._

</td> </tr>  
<tr>  
<td>

3.3 Who will be responsible for data management in your project?

</td> </tr>  
<tr>  
<td>

_BioAssist’s CTO._

</td> </tr>  
<tr>  
<td>

3.4 Are the resources for long term preservation discussed?

</td> </tr>  
<tr>  
<td>

_This has not been discussed yet._

</td> </tr>  
<tr>  
<td>

**4 Data security**

</td> </tr>  
<tr>  
<td>

4.1 What provisions are in place for data security?

</td> </tr>  
<tr>  
<td>

_BioAssist has developed state-of-the-art security, business continuity and
data retention plans which are currently in place._

</td> </tr>  
<tr>  
<td>

4.2 Is the data safely stored in certified repositories for long term
preservation and curation?

</td> </tr>  
<tr>  
<td>

_At the moment, all data are stored only on BioAssist’s database._

</td> </tr>  
<tr>  
<td>

**5 Ethical aspects**

</td> </tr>  
<tr>  
<td>

5.1 Are there any ethical or legal issues that can have an impact on data
sharing?

</td> </tr>  
<tr>  
<td>

_Ethical issues have already been resolved. Permission from the Greek Data
Protection Authority is required before the (anonymised) dataset can be shared
with the partners. Legal restrictions do not permit open access to this
dataset._

</td> </tr>  
<tr>  
<td>

5.2 Is informed consent for data sharing and long term preservation included
in questionnaires dealing with personal data?

</td> </tr>  
<tr>  
<td>

_Yes, all patients that are supplying data to this dataset have signed
informed consent._

</td> </tr>  
<tr>  
<td>

**6 Other issues**

</td> </tr>  
<tr>  
<td>

6.1 Do you make use of other national/funder/sectorial/departmental procedures
for data management? If yes, which ones?

</td> </tr>  
<tr>  
<td>

_Not at the moment._

</td> </tr> </table>

##  3\. 10 DATASET 10: Social Data dataset (BIO)  
  
<table>  
<tr>  
<th>

**DATASET 10**

</th>  
<th>

**NAME: Social Data dataset**

</th> </tr>  
<tr>  
<td>

**1\. Data Summary**

</td> </tr>  
<tr>  
<td>

1.1 Purpose

</td> </tr>  
<tr>  
<td>

_Social data collected from the BioAssist platform provide insights into the
patients’ behaviour, lifestyle and wellbeing. They can be utilised for patient
profiling, as well as assessment of policies targeting patient behaviour._

</td> </tr>  
<tr>  
<td>

1.2 Types and formats of data

</td> </tr>  
<tr>  
<td>

_This dataset includes logs of the interaction of BIO’s pilot users with the
platform’s social features. These logs provide information on contact
management (e.g. number of people in contact list, number of invitations
sent), videocalls (i.e. time, duration, frequency), events (e.g.
notifications) and multimedia content shared (e.g. number of files uploaded by
the patient, number of files uploaded by the patient’s contacts)._

</td> </tr>  
<tr>  
<td>

1.3 Re-use of existing data

</td> </tr>  
<tr>  
<td>

_This dataset includes historical data which are continuously updated. All
currently available data will be use and new data will be periodically
imported to the CrowdHEALTH platform throughout the course of the project._

</td> </tr>  
<tr>  
<td>

1.4 Origin

</td> </tr>  
<tr>  
<td>

_Social data are collected automatically by the BioAssist platform._

</td> </tr>  
<tr>  
<td>

1.5 Expected size

</td> </tr>  
<tr>  
<td>

_The dataset contains hundreds of thousands of records._

</td> </tr>  
<tr>  
<td>

1.6 Data utility

</td> </tr>  
<tr>  
<td>

_Policy makers and caregivers._

</td> </tr>  
<tr>  
<td>

**2 FAIR Data**

</td> </tr>  
<tr>  
<td>

**2.1 Making data findable, including provisions for metadata**

</td> </tr>  
<tr>  
<td>

2.1.1 Are the data produced and/or used in the project discoverable with
metadata, identifiable and locatable by means of a standard identification
mechanism?

</td> </tr>  
<tr>  
<td>

_No._

</td> </tr>  
<tr>  
<td>

2.1.2 What naming conventions do you follow?

</td> </tr>  
<tr>  
<td>

_No naming conventions are followed at the moment._

</td> </tr> </table>  
<table>  
<tr>  
<th>

2.1.3 Will search keywords be provided that optimize possibilities for re-use?

</th> </tr>  
<tr>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

2.1.4 Do you provide clear version numbers?

</td> </tr>  
<tr>  
<td>

_No_

</td> </tr>  
<tr>  
<td>

2.1.5 What metadata will be created?

</td> </tr>  
<tr>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

**2.2 Making data openly accessible**

</td> </tr>  
<tr>  
<td>

2.2.1 Which data produced and/or used in the project will be made openly
available as the default?

</td> </tr>  
<tr>  
<td>

_The dataset shall become available to the consortium after anonymization,
when permission by the Greek Data Protection Authority is obtained. Legal
restrictions do not permit open access to the data._

</td> </tr>  
<tr>  
<td>

2.2.2 How will the data be made accessible?

</td> </tr>  
<tr>  
<td>

_The data will be pushed to the CrowdHEALTH GW._

</td> </tr>  
<tr>  
<td>

2.2.3 What methods or software tools are needed to access the data?

</td> </tr>  
<tr>  
<td>

_All software tools required to access the data will be developed as
components of the CrowdHEALTH platform._

</td> </tr>  
<tr>  
<td>

2.2.4 Is documentation about the software needed to access the data included?

</td> </tr>  
<tr>  
<td>

_Not Required._

</td> </tr>  
<tr>  
<td>

2.2.5 Is it possible to include the relevant software?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.6 Where will the data and associated metadata, documentation and code be
deposited?

</td> </tr>  
<tr>  
<td>

_Legal constraints do not permit us to provide open access to these data. The
data will be deposited on a local deployment of the CrowdHEALTH platform and
will be accessible only within the project._

</td> </tr>  
<tr>  
<td>

2.2.7 Have you explored appropriate arrangements with the identified
repository?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.8 If there are restrictions on use, how will access be provided?

</td> </tr>  
<tr>  
<td>

_The data will only be accessible for use to authorised users of the
platform._

</td> </tr>  
<tr>  
<td>

2.2.9 Is there a need for a data access committee?

</td> </tr>  
<tr>  
<td>

_We do not foresee the need for a data access committee at the moment. This
will be verified when the process for obtaining permission by the Greek Data
Protection Authority is completed._

</td> </tr> </table>  
<table>  
<tr>  
<th>

2.2.10 Are there well described conditions for access?

</th> </tr>  
<tr>  
<td>

_No._

</td> </tr>  
<tr>  
<td>

2.2.11 How will the identity of the person accessing the data be ascertained?

</td> </tr>  
<tr>  
<td>

_This will be handled by the CrowdHEALTH user authentication and access
control components._

</td> </tr>  
<tr>  
<td>

**2.3 Making data interoperable**

</td> </tr>  
<tr>  
<td>

2.3.1 Are the data produced in the project interoperable?

</td> </tr>  
<tr>  
<td>

_Currently the data are structured in a custom format for internal use in our
systems. A new data model for sharing this data with CrowdHEALTH is being
developed._

</td> </tr>  
<tr>  
<td>

2.3.2 What data and metadata vocabularies, standards or methodologies will you
follow to make your data interoperable?

</td> </tr>  
<tr>  
<td>

_At the moment, the dataset does not utilize any standard._

</td> </tr>  
<tr>  
<td>

2.3.3 Will you be using standard vocabularies for all data types present in
your data set, to allow interdisciplinary interoperability?

</td> </tr>  
<tr>  
<td>

_This will be determined at a later stage._

</td> </tr>  
<tr>  
<td>

2.3.4 In case it is unavoidable that you use uncommon or generate project
specific ontologies or vocabularies, will you provide mappings to more
commonly used ontologies?

</td> </tr>  
<tr>  
<td>

_This will be determined at a later stage._

</td> </tr>  
<tr>  
<td>

**2.4 Increase data re-use (through clarifying licenses)**

</td> </tr>  
<tr>  
<td>

2.4.1 How will the data be licensed to permit the widest re-use possible?

</td> </tr>  
<tr>  
<td>

_The data will not be available for re-use._

</td> </tr>  
<tr>  
<td>

2.4.2 When will the data be made available for re-use?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.4.3 Are the data produced and/or used in the project useable by third
parties, in particular after the end of the project?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.4.4 How long is it intended that the data remains re-usable?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.4.5 Are data quality assurance processes described?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

**3 Allocation of resources**

</td> </tr>  
<tr>  
<td>

3.1 What are the costs for making data FAIR in your project?

</td> </tr>  
<tr>  
<td>

_There may be costs related to e.g. legal support, but they cannot be
estimated at the moment. All other known costs are already covered by the
project._

</td> </tr>  
<tr>  
<td>

3.2 How will these be covered?

</td> </tr>  
<tr>  
<td>

_This will depend on the nature of the costs that will arise._

</td> </tr>  
<tr>  
<td>

3.3 Who will be responsible for data management in your project?

</td> </tr>  
<tr>  
<td>

_The company’s CTO._

</td> </tr>  
<tr>  
<td>

3.4 Are the resources for long term preservation discussed?

</td> </tr>  
<tr>  
<td>

_This has not been discussed yet._

</td> </tr>  
<tr>  
<td>

**4 Data security**

</td> </tr>  
<tr>  
<td>

4.1 What provisions are in place for data security?

</td> </tr>  
<tr>  
<td>

_BioAssist has developed state-of-the-art security, business continuity and
data retention plans which are currently in place._

</td> </tr>  
<tr>  
<td>

4.2 Is the data safely stored in certified repositories for long term
preservation and curation?

</td> </tr>  
<tr>  
<td>

_At the moment, all data are stored only on BioAssist’s database._

</td> </tr>  
<tr>  
<td>

**5 Ethical aspects**

</td> </tr>  
<tr>  
<td>

5.1 Are there any ethical or legal issues that can have an impact on data
sharing?

</td> </tr>  
<tr>  
<td>

_Ethical issues have already been resolved. Permission from the Greek Data
Protection Authority is required before the (anonymised) dataset can be shared
with the partners. Legal restrictions do not permit open access to this
dataset._

</td> </tr>  
<tr>  
<td>

5.2 Is informed consent for data sharing and long term preservation included
in questionnaires dealing with personal data?

</td> </tr>  
<tr>  
<td>

_Yes, all patients that are supplying data to this dataset have signed
informed consent._

</td> </tr>  
<tr>  
<td>

**6 Other issues**

</td> </tr>  
<tr>  
<td>

6.1 Do you make use of other national/funder/sectorial/departmental procedures
for data management? If yes, which ones?

</td> </tr>  
<tr>  
<td>

_Not at the moment._

</td> </tr> </table>

##  3\. 11 DATASET 11: CancerPatientData Dataset (CRA)  
  
<table>  
<tr>  
<th>

**DATASET 11**

</th>  
<th>

**CancerPatientData Dataset (CareAcross)**

</th> </tr>  
<tr>  
<td>

**1\. Data Summary**

</td> </tr>  
<tr>  
<td>

1.1 Purpose

</td> </tr>  
<tr>  
<td>

_The data is collected from patients in order to receive personalised coaching
and medical information. These are central themes for our use case, in terms
of coaching adherence & information impact. _

</td> </tr>  
<tr>  
<td>

1.2 Types and formats of data

</td> </tr>  
<tr>  
<td>

_They are structured data about patient’s daily life and information received.
Mostly consisting of numbers of food portions or Boolean flags about specific
diagnoses and treatments._

</td> </tr>  
<tr>  
<td>

1.3 Re-use of existing data

</td> </tr>  
<tr>  
<td>

_No_

</td> </tr>  
<tr>  
<td>

1.4 Origin

</td> </tr>  
<tr>  
<td>

_Patients_

</td> </tr>  
<tr>  
<td>

1.5 Expected size

</td> </tr>  
<tr>  
<td>

_For each patient, we expect to collect about 30 data points. It is expected
that 1,000 patients will have entered data throughout this project._

</td> </tr>  
<tr>  
<td>

1.6 Data utility

</td> </tr>  
<tr>  
<td>

_On an individual level, to the patient. On a research level, to health care
professionals and policy makers._

</td> </tr>  
<tr>  
<td>

**2 FAIR Data**

</td> </tr>  
<tr>  
<td>

**2.1 Making data findable, including provisions for metadata**

</td> </tr>  
<tr>  
<td>

2.1.1 Are the data produced and/or used in the project discoverable with
metadata, identifiable and locatable by means of a standard identification
mechanism?

</td> </tr>  
<tr>  
<td>

_Yes: input is defined as a Question and the possible answers are put down as
Answers._

</td> </tr>  
<tr>  
<td>

2.1.2 What naming conventions do you follow?

</td> </tr>  
<tr>  
<td>

_All Questions and Answers have “value”s._

</td> </tr>  
<tr>  
<td>

2.1.3 Will search keywords be provided that optimize possibilities for re-use?

</td> </tr>  
<tr>  
<td>

_No_

</td> </tr> </table>  
<table>  
<tr>  
<th>

2.1.4 Do you provide clear version numbers?

</th> </tr>  
<tr>  
<td>

_No_

</td> </tr>  
<tr>  
<td>

2.1.5 What metadata will be created?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

**2.2 Making data openly accessible**

</td> </tr>  
<tr>  
<td>

2.2.1 Which data produced and/or used in the project will be made openly
available as the default?

</td> </tr>  
<tr>  
<td>

_The data subjects are patients themselves who have agreed to provide data in
a way that their individual records do not get shared beyond the purposes of
this service, and not beyond the confines of the company._

_Aggregated data will be made available to the CrowdHEALTH platform, but not
open to the public or otherwise beyond the scope of this project._

</td> </tr>  
<tr>  
<td>

2.2.2 How will the data be made accessible?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.3 What methods or software tools are needed to access the data?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.4 Is documentation about the software needed to access the data included?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.5 Is it possible to include the relevant software?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.6 Where will the data and associated metadata, documentation and code be
deposited?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.7 Have you explored appropriate arrangements with the identified
repository?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.8 If there are restrictions on use, how will access be provided?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.9 Is there a need for a data access committee?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr> </table>  
<table>  
<tr>  
<th>

2.2.10 Are there well described conditions for access?

</th> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.11 How will the identity of the person accessing the data be ascertained?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

**2.3 Making data interoperable**

</td> </tr>  
<tr>  
<td>

2.3.1 Are the data produced in the project interoperable?

</td> </tr>  
<tr>  
<td>

_No specific standard exists for the variety and breadth of data we are
collecting. However, the structure is such that the data can be
interoperable._

_On the other hand, as discussed, the individual data will be contained within
the Use Case and only aggregated data will be shared with the central
CrowdHEALTH platform._

_The aggregated data will be amenable to further analysis by the CrowdHEALTH
platform. This data will be exported in a structure which will contain field-
value pairs; the exact structure of that export cannot be determined in
advance, because the level of detail and aggregation depends on the findings
of the analysis performed within the Use Case._

</td> </tr>  
<tr>  
<td>

2.3.2 What data and metadata vocabularies, standards or methodologies will you
follow to make your data interoperable?

</td> </tr>  
<tr>  
<td>

_The extent of such standards followed for the aggregated data structures will
depend on the findings. We expect these to evolve as the data gets richer._

</td> </tr>  
<tr>  
<td>

2.3.3 Will you be using standard vocabularies for all data types present in
your data set, to allow interdisciplinary interoperability?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.3.4 In case it is unavoidable that you use uncommon or generate project
specific ontologies or vocabularies, will you provide mappings to more
commonly used ontologies?

</td> </tr>  
<tr>  
<td>

_The data entered is structured, but it is patient-oriented; therefore,
mappings can be provided where necessary. However, such formal ontologies are
usually created in a system-orientation. For example, “dry mouth” and “mouth
sores” mean completely different things to the patient, but may actually be
reflected onto one single element (as opposed to two elements) within an
ontology._

</td> </tr>  
<tr>  
<td>

**2.4 Increase data re-use (through clarifying licenses)**

</td> </tr>  
<tr>  
<td>

2.4.1 How will the data be licensed to permit the widest re-use possible?

</td> </tr>  
<tr>  
<td>

_Data will not be licensed but will remain property of CareAcross._

</td> </tr>  
<tr>  
<td>

2.4.2 When will the data be made available for re-use?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr> </table>  
<table>  
<tr>  
<th>

2.4.3 Are the data produced and/or used in the project useable by third
parties, in particular after the end of the project?

</th> </tr>  
<tr>  
<td>

_No_

</td> </tr>  
<tr>  
<td>

2.4.4 How long is it intended that the data remains re-usable?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.4.5 Are data quality assurance processes described?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

**3 Allocation of resources**

</td> </tr>  
<tr>  
<td>

3.1 What are the costs for making data FAIR in your project?

</td> </tr>  
<tr>  
<td>

_We can approximate that the costs to construct such datasets will be
moderate, if their provision is as frequent as already discussed with partners
managing the centralised repository (no more frequent than every 6 months)._

</td> </tr>  
<tr>  
<td>

3.2 How will these be covered?

</td> </tr>  
<tr>  
<td>

_The efforts for aggregated data that will be included in an open access
scheme, will be covered as part of the corresponding grant portion. The rest
will be covered by the company._

</td> </tr>  
<tr>  
<td>

3.3 Who will be responsible for data management in your project?

</td> </tr>  
<tr>  
<td>

_The company CEO (Thanos Kosmidis)_

</td> </tr>  
<tr>  
<td>

3.4 Are the resources for long term preservation discussed?

</td> </tr>  
<tr>  
<td>

_Data is preserved indefinitely._

</td> </tr>  
<tr>  
<td>

**4 Data security**

</td> </tr>  
<tr>  
<td>

4.1 What provisions are in place for data security?

</td> </tr>  
<tr>  
<td>

_Best practices are being used for data security, using state-of-the-art
commercial cloud providers. Frequent backups are being scheduled. The current
commercial cloud provider is Heroku (powered by Salesforce)._

</td> </tr>  
<tr>  
<td>

4.2 Is the data safely stored in certified repositories for long term
preservation and curation?

</td> </tr>  
<tr>  
<td>

_Data is safely stored in state of the art cloud-based repositories._

</td> </tr>  
<tr>  
<td>

**5 Ethical aspects**

</td> </tr>  
<tr>  
<td>

5.1 Are there any ethical or legal issues that can have an impact on data
sharing?

</td> </tr>  
<tr>  
<td>

_These data sets consist of sensitive patient data, contributed by the
patients themselves. The Terms of our Service and our Privacy Policy restrict
the level of sharing, only to an aggregate level (as discussed above and
beyond)._

</td> </tr>  
<tr>  
<td>

5.2 Is informed consent for data sharing and long term preservation included
in questionnaires dealing with personal data?

</td> </tr>  
<tr>  
<td>

_Patients agree with the aforementioned Terms of Service and Privacy Policy as
part of the registration process._

</td> </tr>  
<tr>  
<td>

**6 Other issues**

</td> </tr>  
<tr>  
<td>

6.1 Do you make use of other national/funder/sectorial/departmental procedures
for data management? If yes, which ones?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr> </table>

##  3\. 12 DATASET 12: SLOfit Dataset - (ULJ)  
  
<table>  
<tr>  
<th>

**DATASET 12**

</th>  
<th>

**NAME: SLOfit (ULJ)**

</th> </tr>  
<tr>  
<td>

**1\. Data Summary**

</td> </tr>  
<tr>  
<td>

1.1 Purpose

</td> </tr>  
<tr>  
<td>

_Purpose of the SLOfit data collection is:_

  * _to enable children and parents to compare their somatic and physical fitness development with the development of their peers and identify the needs for improvement_

  

  * _to permit teachers to use the analysed data to identify children with special developmental needs, to follow the development of every individual child and adjust the teaching process to the needs and capabilities of children_

  

  * _to equip school physicians and pediatricians with holistic information from multiple sources in order to enable tailoring of custom-made interventions as well as monitoring and evaluating the effects of small scale interventions;_

  

  * _to help policy makers in evaluating their actions by monitoring population trends in physical fitness and obesity on a national level (the SLOfit data serves as scientific backbone for most of the policies, related to improvement of physical activity of children and youth and the policies, related to school physical education)_

  

  * _creation of a collection of data on lifestyle and social economic environment beside already collected records from standard physical fitness testing. Linking the upgraded SLOfit database with the e-health system (eHR) within the CrowdHEALTH (CH) platform will provide an integrated view of the patient. This will allow more accurate forecasting of predictive health risk of children and youth and performing causal analysis and consequently the shaping of an efficient public health policy framework and the provision of integrated healthcare services within educational and health-care system._

  

  * _to aid policy makers in creating and evaluating policies relating to childhood obesity and physical activity by performing big data analysis on collected data. HHRs will provide an opportunity for performing causal analysis and building health risk predictive models. Any intervention such as increasing physical activity, reducing obesity or general morbidity on the level of class, school, municipality, and region or on the national level could be evaluated. Moreover, It will constitute a useful tool to directly evaluate the trends among groups and an optimal means to promptly highlight the impact of the various policies._

  

  * _to provide illustrative visualizations of the collected data on the individual, school, regional and national level. Via the CH platform, every child, his/her parents, school physician and policy makers will be see the status and development of child’s physical fitness, physical activity and linked health risks on individual and aggregated level. The integration of predictive models into this platform would also provide policy makers with a useful tool to forecast trends, simulate effects of intervention and measuring the impact of interventions and relevant policies in the context of physical fitness, physical activity and obesity._

  

</td> </tr> </table>  
<table>  
<tr>  
<th>

1.2 Types and formats of data

</th> </tr>  
<tr>  
<td>

_Data are stored in MS SQL database, but will be exported to Excel._

</td> </tr>  
<tr>  
<td>

1.3 Re-use of existing data

</td> </tr>  
<tr>  
<td>

_Yes, the SLOfit data already exist but data from every year of measurement
are not linked. Therefore, for the purpose of CrowdHEALTH the data will be
linked into cohort data and used in visualizations._

</td> </tr>  
<tr>  
<td>

1.4 Origin

</td> </tr>  
<tr>  
<td>

_SLOfit is a national surveillance system for somatic and physical fitness
development of children and youth in Slovenia, which was formerly known as
Sports Educational Chart. The system was implemented in 1982 on a sample of
Slovenian schools and after 5 years of testing, it was introduced to all
Slovenian primary and secondary schools. Therefore, SLOfit enables annual
monitoring of somatic and physical fitness status of children in all Slovenian
schools from 1987 onwards. Every April, almost the entire Slovenian
population, aged 6 to 19 (220,000 students) is measured by 8 fitness tests and
3 anthropometric measurements (see _www.slofit.org_ )  . _

</td> </tr>  
<tr>  
<td>

1.5 Expected size

</td> </tr>  
<tr>  
<td>

_About 200,000 students with record for every year of measurement (between 1
and 14). Every record will have about 20 values (data columns)._

</td> </tr>  
<tr>  
<td>

1.6 Data utility

</td> </tr>  
<tr>  
<td>

  * _For decision makers, the SLOfit data might enable scientific backbone for most of the policies, related to improvement of physical activity of children and youth as well as policies for conquer child obesity. It might also provide proper data for health risk predictive models, based on physical fitness data, and simulation of physical activity interventions on physical fitness and prevalance of obesity._

  

  * _For researchers, the SLOfit data might provide answers on the patterns of physical and motor development and their interrelatedness, and the relation between physical activity, sedentariness, Socio-Economic Status (SES), parental physical activity and physical fitness. The data analysis might provide answers on how much physical activity is necessary for retaining adequate level of physical fitness, and what ratios of physical activity and sedentariness still provide sufficient physical fitness. It might also provide proper data for designing individual somatic and motor development forecast._

  

  * _For physicians, the SLOfit data on the individual level might provide holistic view on health of individual schoolchild and effects of interventions on physical fitness as important indicator of child’s health._

  

  * _For parents, the SLOfit data on the individual level might provide alerts if the SLOfit data analyzed through the CrowdHEALTH platform suggests that recommendations for physical fitness or activity are not met that currently do not exist._

  

</td> </tr> </table>  
<table>  
<tr>  
<th>

**2 FAIR Data**

</th> </tr>  
<tr>  
<td>

**2.1 Making data findable, including provisions for metadata**

</td> </tr>  
<tr>  
<td>

2.1.1 Are the data produced and/or used in the project discoverable with
metadata, identifiable and locatable by means of a standard identification
mechanism?

</td> </tr>  
<tr>  
<td>

_No._

</td> </tr>  
<tr>  
<td>

2.1.2 What naming conventions do you follow?

</td> </tr>  
<tr>  
<td>

_None._

</td> </tr>  
<tr>  
<td>

2.1.3 Will search keywords be provided that optimize possibilities for re-use?

</td> </tr>  
<tr>  
<td>

_No._

</td> </tr>  
<tr>  
<td>

2.1.4 Do you provide clear version numbers?

</td> </tr>  
<tr>  
<td>

_No._

</td> </tr>  
<tr>  
<td>

2.1.5 What metadata will be created?

</td> </tr>  
<tr>  
<td>

_None._

</td> </tr>  
<tr>  
<td>

**2.2 Making data openly accessible**

</td> </tr>  
<tr>  
<td>

2.2.1 Which data produced and/or used in the project will be made openly
available as the default?

</td> </tr>  
<tr>  
<td>

_The SLOfit dataset will not be openly available due to voluntary
restrictions. Over 30 years, the SLOfit team has invested a lot of resources
into collection of data and dataset management, so open access to data is not
fair way to exploit possibilities of dataset for the SLOfit team. Members of
the SLOfit team want to have an overview of the SLOfit dataset usage and
collaboration in possible analysis._

</td> </tr>  
<tr>  
<td>

2.2.2 How will the data be made accessible?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr> </table>  
<table>  
<tr>  
<th>

2.2.3 What methods or software tools are needed to access the data?

</th> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.4 Is documentation about the software needed to access the data included?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.5 Is it possible to include the relevant software?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.6 Where will the data and associated metadata, documentation and code be
deposited?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.7 Have you explored appropriate arrangements with the identified
repository?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.8 If there are restrictions on use, how will access be provided?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.9 Is there a need for a data access committee?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.10 Are there well described conditions for access?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.11 How will the identity of the person accessing the data be ascertained?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr> </table>  
<table>  
<tr>  
<th>

**2.3 Making data interoperable**

</th> </tr>  
<tr>  
<td>

2.3.1 Are the data produced in the project interoperable?

</td> </tr>  
<tr>  
<td>

_Yes, at least within the consortium_

</td> </tr>  
<tr>  
<td>

2.3.2 What data and metadata vocabularies, standards or methodologies will you
follow to make your data interoperable?

</td> </tr>  
<tr>  
<td>

_No standard data vocabularies will be used_

</td> </tr>  
<tr>  
<td>

2.3.3 Will you be using standard vocabularies for all data types present in
your data set, to allow interdisciplinary interoperability?

</td> </tr>  
<tr>  
<td>

_No, we will create custom codes for our data and share it with the partners
in the consortium._

</td> </tr>  
<tr>  
<td>

2.3.4 In case it is unavoidable that you use uncommon or generate project
specific ontologies or vocabularies, will you provide mappings to more
commonly used ontologies?

</td> </tr>  
<tr>  
<td>

_Yes._

</td> </tr>  
<tr>  
<td>

**2.4 Increase data re-use (through clarifying licenses)**

</td> </tr>  
<tr>  
<td>

2.4.1 How will the data be licensed to permit the widest re-use possible?

</td> </tr>  
<tr>  
<td>

_Copyright will be retained by the University of Ljubljana. No re-use will be
publicly available._

</td> </tr>  
<tr>  
<td>

2.4.2 When will the data be made available for re-use?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.4.3 Are the data produced and/or used in the project useable by third
parties, in particular after the end of the project?

</td> </tr>  
<tr>  
<td>

_No._

</td> </tr>  
<tr>  
<td>

2.4.4 How long is it intended that the data remains re-usable?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr> </table>  
<table>  
<tr>  
<th>

2.4.5 Are data quality assurance processes described?

</th> </tr>  
<tr>  
<td>

_No._

</td> </tr>  
<tr>  
<td>

**3 Allocation of resources**

</td> </tr>  
<tr>  
<td>

3.1 What are the costs for making data FAIR in your project?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

3.2 How will these be covered?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

3.3 Who will be responsible for data management in your project?

</td> </tr>  
<tr>  
<td>

_Gregor Starc, Faculty of Sport, University of Ljubljana._

</td> </tr>  
<tr>  
<td>

3.4 Are the resources for long term preservation discussed?

</td> </tr>  
<tr>  
<td>

_Cost of long term preservation of the SLOfit dataset is approximately EUR
3,000 per year. Decision is upon Faculty of Sport and Ministry of Education.
Currently, the dataset has no time limit in preservation._

</td> </tr>  
<tr>  
<td>

**4 Data security**

</td> </tr>  
<tr>  
<td>

4.1 What provisions are in place for data security?

</td> </tr>  
<tr>  
<td>

_Faculty of Sport, University of Ljubljana has a Data Center with both server
and storage infrastructure, which are accessible only to authorized personnel,
have fire detection system and video surveillance system, and air cooling. The
access to the data is allowed only to authorized staff with an active
directory with user logins and encrypted passwords. The Data Center has also
disk to disk backup systems._

</td> </tr>  
<tr>  
<td>

4.2 Is the data safely stored in certified repositories for long term
preservation and curation?

</td> </tr>  
<tr>  
<td>

_Yes_

</td> </tr>  
<tr>  
<td>

**5 Ethical aspects**

</td> </tr>  
<tr>  
<td>

5.1 Are there any ethical or legal issues that can have an impact on data
sharing?

</td> </tr>  
<tr>  
<td>

_Data are protected by the Personal data protection legislation. However,
individual consents have been acquired that allow for sharing anonymized
data._

</td> </tr>  
<tr>  
<td>

5.2 Is informed consent for data sharing and long term preservation included
in questionnaires dealing with personal data?

</td> </tr>  
<tr>  
<td>

_Yes._

</td> </tr>  
<tr>  
<td>

**6 Other issues**

</td> </tr>  
<tr>  
<td>

6.1 Do you make use of other national/funder/sectorial/departmental procedures
for data management? If yes, which ones?

</td> </tr>  
<tr>  
<td>

_None._

</td> </tr> </table>

###  3.13 DATASET 13: Lifestyle Dataset (ULJ)  
  
<table>  
<tr>  
<th>

**DATASET 13**

</th>  
<th>

**NAME: Lifestyle Dataset (ULJ)**

</th> </tr>  
<tr>  
<td>

**1\. Data Summary**

</td> </tr>  
<tr>  
<td>

1.1 Purpose

</td> </tr>  
<tr>  
<td>

_Purpose of the Lifestyle data collection is:_

  * _to enable children and parents to compare their lifestyle habits (i.e. physical activity, sedentariness, sleep) with the recommendations and identify the needs for improvement;_

  

  * _to equip school physicians and pediatricians with holistic information from multiple sources in order to enable tailoring of custom-made interventions as well as monitoring and evaluating the effects of small scale interventions;_

  

  * _creation of a collection of data on lifestyle and social economic environment beside already collected records from standard physical fitness testing. Linking the upgraded SLOfit database (the SLOfit + Lifestyle database) with the e-health system (eHR) within the CrowdHEALTH (CH) platform will provide an integrated view of the patient. This will allow more accurate forecasting of predictive health risk of children and youth and performing causal analysis and consequently the shaping of an efficient public health policy framework and the provision of integrated healthcare services within educational and health-care system._

  

  * _to aid policy makers in creating and evaluating policies relating to childhood obesity and physical activity by performing big data analysis on collected data. HHRs will provide an opportunity for performing causal analysis and building health risk predictive models. Any intervention such as increasing physical activity, reducing obesity or general morbidity on the level of class, school, municipality, and region or on the national level could be evaluated._

  

  * _to provide illustrative visualizations of the collected data on the individual, school, regional and national level. Via the CH platform, every child, his/her parents, school physician and policy makers will be see the status and development of child’s physical fitness, physical activity and linked health risks on individual and aggregated level. The integration of predictive models into this platform would also provide policy makers with a useful tool to forecast trends, simulate effects of intervention and measuring the impact of interventions and relevant policies in the context of physical fitness, physical activity and obesity._

  

</td> </tr>  
<tr>  
<td>

1.2 Types and formats of data

</td> </tr>  
<tr>  
<td>

_Data will be stored in MS SQL database, but will be exported to Excel._

</td> </tr>  
<tr>  
<td>

1.3 Re-use of existing data

</td> </tr>  
<tr>  
<td>

_No, the Lifestyle data will be collected within CrowdHEALTH pilot
environment, except of physical fitness data which will be a subset of the
SLOfit database._

</td> </tr> </table>  
<table>  
<tr>  
<th>

1.4 Origin

</th> </tr>  
<tr>  
<td>

_The Lifestyle dataset will be implemented on a sample of 2,000 students
within CrowdHEALTH pilot environment in Slovenia (Škofja Loka municipality).
It will include data about physical activity, sedentariness, SES, sleep,
resting heart-rate, peers, academic achievement, height and body mass of
parents, and parental physical activity. The data will be collected and
entered by students and their parents. Beside these data the Lifestyle dataset
will include also physical fitness data which will be extracted from the
SLOfit dataset._

</td> </tr>  
<tr>  
<td>

1.5 Expected size

</td> </tr>  
<tr>  
<td>

_About 2000 students with record for 2 years of measurement in the course of
the CrowdHEALTH project (2018, 2019), Every record will have about 20 values
(data columns)._

</td> </tr>  
<tr>  
<td>

1.6 Data utility

</td> </tr>  
<tr>  
<td>

_For decision makers, the Lifestyle data might enable scientific backbone for
most of the policies, related to improvement of physical activity of children
and youth as well as policies for conquer child obesity. It might also provide
proper data for health risk predictive models, based on physical fitness data,
and simulation of physical activity interventions on physical fitness and
prevalence of obesity._

_For researchers, the Lifestyle data might provide answers on the patterns of
physical and motor development and their interrelatedness, and the relation
between physical activity, sedentariness, SES, parental physical activity and
physical fitness. The data analysis might provide answers on how much physical
activity is necessary for retaining adequate level of physical fitness, and
what ratios of physical activity and sedentariness still provide sufficient
physical fitness. It might also provide proper data for designing individual
somatic and motor development forecast._

_For physicians, the Lifestyle data combined with the SLOfit data on the
individual level might provide holistic view on health of individual
schoolchild and effects of interventions on physical fitness as important
indicator of child’s health._

_For parents, the Lifestyle data on the individual level might provide alerts
if the Lifestyle data analyzed through the CrowdHEALTH platform suggests that
recommendations for physical activity, sleep or sedentary are not met that
currently do not exist._

</td> </tr>  
<tr>  
<td>

**2 FAIR Data**

</td> </tr>  
<tr>  
<td>

**2.1 Making data findable, including provisions for metadata**

</td> </tr>  
<tr>  
<td>

2.1.1 Are the data produced and/or used in the project discoverable with
metadata, identifiable and locatable by means of a standard identification
mechanism?

</td> </tr>  
<tr>  
<td>

_No._

</td> </tr> </table>  
<table>  
<tr>  
<th>

2.1.2 What naming conventions do you follow?

</th> </tr>  
<tr>  
<td>

_None._

</td> </tr>  
<tr>  
<td>

2.1.3 Will search keywords be provided that optimize possibilities for re-use?

</td> </tr>  
<tr>  
<td>

_No._

</td> </tr>  
<tr>  
<td>

2.1.4 Do you provide clear version numbers?

</td> </tr>  
<tr>  
<td>

_No._

</td> </tr>  
<tr>  
<td>

2.1.5 What metadata will be created?

</td> </tr>  
<tr>  
<td>

_None._

</td> </tr>  
<tr>  
<td>

**2.2 Making data openly accessible**

</td> </tr>  
<tr>  
<td>

2.2.1 Which data produced and/or used in the project will be made openly
available as the default?

</td> </tr>  
<tr>  
<td>

_None._

_The Lifestyle dataset will not be openly available due to voluntary
restrictions. The dataset will present an upgrade of the SLOfit database. Over
30 years, the SLOfit team has invested a lot of resources into collection of
data and dataset management, so open access to data is not fair way to exploit
possibilities of dataset for the SLOfit team. Members of the SLOfit team want
to have an overview of the dataset usage and collaboration in possible
analysis._

</td> </tr>  
<tr>  
<td>

2.2.2 How will the data be made accessible?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.3 What methods or software tools are needed to access the data?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.4 Is documentation about the software needed to access the data included?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr> </table>  
<table>  
<tr>  
<th>

2.2.5 Is it possible to include the relevant software?

</th> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.6 Where will the data and associated metadata, documentation and code be
deposited?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.7 Have you explored appropriate arrangements with the identified
repository?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.8 If there are restrictions on use, how will access be provided?

</td> </tr>  
<tr>  
<td>

_Users will be able to access their own data via password. Aggregated data
will be publicly accessible._

</td> </tr>  
<tr>  
<td>

2.2.9 Is there a need for a data access committee?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.10 Are there well described conditions for access?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.2.11 How will the identity of the person accessing the data be ascertained?

</td> </tr>  
<tr>  
<td>

_n/a_

</td> </tr>  
<tr>  
<td>

**2.3 Making data interoperable**

</td> </tr>  
<tr>  
<td>

2.3.1 Are the data produced in the project interoperable?

</td> </tr>  
<tr>  
<td>

_Yes, at least within the consortium._

</td> </tr>  
<tr>  
<td>

2.3.2 What data and metadata vocabularies, standards or methodologies will you
follow to make your data interoperable?

</td> </tr>  
<tr>  
<td>

_No standard data vocabularies will be used._

</td> </tr> </table>  
<table>  
<tr>  
<th>

2.3.3 Will you be using standard vocabularies for all data types present in
your data set, to allow interdisciplinary interoperability?

</th> </tr>  
<tr>  
<td>

_No, we will create custom codes for our data and share it with the partners
in the consortium._

</td> </tr>  
<tr>  
<td>

2.3.4 In case it is unavoidable that you use uncommon or generate project
specific ontologies or vocabularies, will you provide mappings to more
commonly used ontologies?

</td> </tr>  
<tr>  
<td>

_Yes._

</td> </tr>  
<tr>  
<td>

**2.4 Increase data re-use (through clarifying licenses)**

</td> </tr>  
<tr>  
<td>

2.4.1 How will the data be licensed to permit the widest re-use possible?

</td> </tr>  
<tr>  
<td>

_Copyright will be retained by the University of Ljubljana. No re-use will be
publicly available._

</td> </tr>  
<tr>  
<td>

2.4.2 When will the data be made available for re-use?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.4.3 Are the data produced and/or used in the project useable by third
parties, in particular after the end of the project?

</td> </tr>  
<tr>  
<td>

_No_

</td> </tr>  
<tr>  
<td>

2.4.4 How long is it intended that the data remains re-usable?

</td> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

2.4.5 Are data quality assurance processes described?

</td> </tr>  
<tr>  
<td>

_No._

</td> </tr>  
<tr>  
<td>

**3 Allocation of resources**

</td> </tr>  
<tr>  
<td>

3.1 What are the costs for making data FAIR in your project?

</td> </tr>  
<tr>  
<td>

_None_

</td> </tr> </table>  
<table>  
<tr>  
<th>

3.2 How will these be covered?

</th> </tr>  
<tr>  
<td>

_N/A_

</td> </tr>  
<tr>  
<td>

_3.3 Who will be responsible for data management in your project?_

</td> </tr>  
<tr>  
<td>

_Gregor Starc, Faculty of Sport, University of Ljubljana._

</td> </tr>  
<tr>  
<td>

3.4 Are the resources for long term preservation discussed?

</td> </tr>  
<tr>  
<td>

_There will be no additional costs for long term preservation if the Lifestyle
data will be integrated into the SLOfit database. Decision on data keeping is
upon Faculty of Sport and Ministry of Education. Currently, the dataset has no
time limit in preservation._

</td> </tr>  
<tr>  
<td>

**4 Data security**

</td> </tr>  
<tr>  
<td>

4.1 What provisions are in place for data security?

</td> </tr>  
<tr>  
<td>

_Faculty of Sport, University of Ljubljana has a Data Center with both server
and storage infrastructure, which are accessible only to authorized personnel,
have fire detection system and video surveillance system, and air cooling. The
access to the data is allowed only to authorized staff with an active
directory with user logins and encrypted passwords. The Data Center has also
disk to disk backup systems._

</td> </tr>  
<tr>  
<td>

4.2 Is the data safely stored in certified repositories for long term
preservation and curation?

</td> </tr>  
<tr>  
<td>

_Yes._

</td> </tr>  
<tr>  
<td>

**5 Ethical aspects**

</td> </tr>  
<tr>  
<td>

5.1 Are there any ethical or legal issues that can have an impact on data
sharing?

</td> </tr>  
<tr>  
<td>

_Data are protected by the Personal data protection legislation. However,
individual consents have been acquired that allow for sharing anonymised
data._

</td> </tr>  
<tr>  
<td>

5.2 Is informed consent for data sharing and long term preservation included
in questionnaires dealing with personal data?

</td> </tr>  
<tr>  
<td>

_Yes._

</td> </tr>  
<tr>  
<td>

**6 Other issues**

</td> </tr>  
<tr>  
<td>

6.1 Do you make use of other national/funder/sectorial/departmental procedures
for data management? If yes, which ones?

</td> </tr>  
<tr>  
<td>

_No_

</td> </tr> </table>

#  4\. Conclusion remarks

It is important to highlight that using easier questionnaires previous to the
FAIR Data Management Plan template in projects with complex and non-homogenous
datasets could be a best practice; it helps to prevent delays in the starting
of technical work into the project and at the same time helps to the User
Cases groups to reflect about some basic questions about their datasets for
the Open Data Pilot in H2020 previously to complete the DMP template.

This gradual effort took more of time than foreseen in the first months of the
project but it is proving to be mutually beneficial for the work progress of
both the technical and the use cases groups.

In November 2017 already initial datasets (HULAFE and SLOfit) have been made
available within the consortium for research and analysis. Additional datasets
are expected to be available by the end of 2017, while a complete plan has
been developed in order to make all datasets available within 2018.