#  Executive Summary

The objective of this deliverable is to present the second version of the data
management plan for the SHiELD project. According to the Grant Agreement, ”
_this deliverable will include the report on data management in the first
reporting period and an update of project’s data management plan (D1.6) if
needed_ ”.

This document covers a wide set of activities such as data collection,
generation, storage and preservation. In this action, we envision five
different types of data: data related to the use cases, data coming from
publications, public deliverables and open source software.

The document presents, following the EC template [1], how these different
types of data will be collected, who the main beneficiaries are, and how
SHiELD will store them, manage them, and make them accessible, findable and
re-usable. The text continues with the foreseen resources needed for the
openness and data to finalize with security and ethical aspects that will be
taken into consideration in the context of SHiELD.

This plan is the second version of the data management plan, which will be
updated by M36 as part of the Technical Reports, having as input the work
carried out in the use cases (WP6), the social and technical work packages
(WP2 – WP5) and the dissemination activities (WP7).

#  Introduction

##  About this deliverable

This deliverable focuses on the management of the data in SHiELD. In this
context there are two different types of data: those related to the
publications generated as part of research activities, and those related to
the data collected from citizens, users and non-users of digital public
services, as well as from civil servants, that will be used as part of the
implementation of the different key results established in the project. In
this sense, we are not considering real data except for a single subset of
data discussed below in Section 2.4.3.

According to the article “39.2 Processing of personal data by the
beneficiaries” of the SHiELD grant agreement: “The beneficiaries may grant
their personnel access only to data that is strictly necessary for
implementing, managing and monitoring the Agreement. The beneficiaries must
inform the personnel whose personal data are collected and processed by the
Commission.” In this sense, we are not processing directly personal data as it
is described by our “Deliverable D1.8. Ethical protocols and approval”, where
it is stated: “the patient health records data used in our trials are
**simulated, and therefore will not identify any living individual** . In
consequence, they require no specific treatment. However, to ensure that tests
are viable, they must be good exemplars of such real-life data. This is the
responsibility of the respective trial partners. Although there is no legal
requirement to manage or process these data with any special care, in
practical terms and for the purposes of the trials themselves, they will be
treated as if they were real patient data.

##  Document structure

The document follows the established H2020 template for a Data Management Plan
(DMP) [1]. Section 2 presents the data summary of what the purpose of the data
collection and generation is. Section 3 explains how the data will be made
fair, and thus findable, accessible, interoperable and reusable. Section 4
briefly explains how the financial resources for this openness are envisioned
at this stage to be allocated. Section 5 and 6 outline security and ethical
aspects respectively. And finally, Section 7 presents the conclusions and
future work.

#  Data Summary

##  Purpose of the data collection/generation and its relation to the
project’s objectives

The following list of SHiELD‘s project objectives and related key results (KR)
provides a description for each KR specifying the purpose of the data
collection/generation (if any):

  * **(O1) Systematic protection of health data against threats and cyber-attacks** . 

    * **KR01: Knowledge base of generic security issues that may affect a system** . The purpose is to create a knowledge base which captures threats that should be managed by the architecture and regulatory data protection requirements (supporting objective O4). This knowledge base does not capture nor user's health data nor users, and it only manages threats and compliance issues in specific end-to-end applications. For the SHiELD use cases we will use fake data just to prove the benefits of the results. 

  

    * **KR02: Tool that provides an automated analysis of data structures in order to identify sensitive elements that may be vulnerable to specific threats.** Data structure used to have flaws and weaknesses during the storage or exchange of data. The purpose is to analyse/collect the schema of these structures. SHiELD pilots will be used to identify sensitive data, and it will be traced during the pilots to ensure its privacy aspects and that access rights requirements are kept. 

  

    * **KR03: Security requirements identification tool** : this tool will allow models of end-to-end applications to be created, and security threats and compliance issues affecting that application to be automatically identified. We will just list security threats and compliance issues according to ‘security by design’ principles. 

  

  

  * **(O2) Definition of a common architecture for secure exchange of health data across European borders.** o **KR04: SHiELD open architecture and open secure interoperability API:** the purpose is to create a SHiELD architecture which is composed by the results of epSOS project but also with tools brought by SHiELD partners such as the anonymisation mechanisms. Furthermore the health data interchanged is fake, and we do not use real user data  1  . SHiELD pilots will invent users for each scenario. Basically the approach is to allow citizens and healthcare providers the possibility for accessing their health data from other countries. 

    * **KR05: SHiELD (Sec)DevOps tool:** the purpose is twofold. During development time, a set of architectural patterns (mainly in Java) are stored in order to check data protection security mechanisms. During run time a set of tools provide monitoring facilities alerting the operator of the system that a threat is likely to occur. 

  

  

  * **(O3) Assurance of the protection and privacy of the health data exchange.** This objective is addressed mostly in WP5, led by IBM based on their expertise in novel data security mechanisms for securing the exchanged data among the different Member States. This data is protected before, during and after it is exchanged. o **KR06: Data protection mechanisms** : the purpose is to collect a suite of security mechanisms to address data protection threats and regulatory compliance issues in end-to-end heterogeneous systems. This includes (but not limited to) tamper detection for mobile devices, data protection mechanisms, and consent-based access control mechanisms. o **KR07: Privacy protection mechanisms:** these privacy mechanisms address different aspects of privacy protection and regulation of data. These include methods for sensitive information identification. The purpose is to use and develop methods to mask private sensitive information dynamically on the fly as well as methods able to anonymize data while enabling analysis on the data. 

  

  * **(O4) To understand the legal/regulatory requirements in each member state, which are only partly aligned by previous EU directives and regulations and provide recommendations to regulators for the development of new/improved regulations** . o **KR08: Legal recommendations report.** For this KR we are not going to use private data. The purpose is to create a common regulatory framework where the legal requirements regarding security among the state members are aligned. 

  

  * **(O5) Validation of SHiELD in different pilots across three Member States** o **KR09: Pilots:** the purpose is to test implementations which are deployed in three Member States, supporting validation scenarios defined. The collected data will be used to prove that scenarios are working. 

    * **KR10: Best practices:** the purpose of the data used is to describe lessons learned and best practices for protecting health data. 

  

  

  * **(O6) Dissemination of SHiELD results** o **KR11: Publications:** the purpose is to collect the scientific papers, white papers, popular press articles, media and social media we are producing **.**

    * **KR12: Take up opportunities:** its purpose is to identify the main users, standards bodies and regulators. 

  

  

##  Types and formats

During the first half of the project, we are just considering the format
suggested in [2] and we are considering a Patient Summary as an identifiable
“dataset of essential and understandable health information” that is made
available “at the point of care to deliver safe patient care during
unscheduled care [and planned care] with its maximal impact in unscheduled
care”; it can also be defined at a high level as: “the minimum set of
information needed to assure healthcare coordination and the continuity of
care” [2]. From a technical point of view, we will use readable formats such
as CSV, XML or JSON. Examples of the XML format are described in [3] which is
the official Metada Registry. The SHiELD project manages structured and
unstructured _simulated_ data collected..

  * **Structured data** refers to kinds of data with a high level of organization, such as information in a relational database. For example: 

    * SDO (discharge form) that contains 5 .txt files where each field is separated by 

  

  

“;”

  * ED (Emergency Department) dataset. o Prescription forms. 

  

  * Constant collection forms. 

  

  * **Unstructured data** refers to information that either does not have a pre-defined  _data_ _model_ o  r is not organized in a pre-defined manner. Unstructured information is typically  _text_ \-  heavy, but may contain data such as dates, numbers, and facts as well. Examples of are: 

    * Reports of complementary tests (radiology, pathological anatomy, endoscopy, etc.) 

  

    * Monitoring of evolutions in external consultations. o Unstructured data documents are typically uploaded in PDF format. 

  

  

##  Re-use of existing data

We will reuse the existing and available data provided in epSOS  (
_https://ec.europa.eu/digitalsingle-market/en/news/cross-border-health-
project-epsos-what-has-it-achieved_ )  just to check the feasibility of the
solutions provided in SHiELD.

##  Origin of the data

The data is based on the scenarios provided in SHiELD, and more precisely on
the three member states requirements (UK, Italy, Spain (Basque country)). The
data used in the scenarios that are going to be built in UK and Italy are
simulated, and do not relate to nor describe any individual. The clinical data
extracted from the health system of the Basque Country contain real patient
data. These data are partially extracted and combined to build _quasi_ real
clinical records, but at no time can any patient be identified, covering all
ethical and legal requirements. In addition, a clinical protocol will be drawn
up in the Basque Country, which will be approved by the local s committee and
the informed consent of the patients whose data records are used in the
validation of the tools will be collected. (See also ANNEX2: Draft DPIA)The
use of these data will help us to demonstrate the developed technology.

###  Lancs

All data used in this program is ‘test data’ that has been generated using
fake patients with fake ID numbers but with real symptoms and diagnosis linked
into Snomed codes. The diagnosis, drugs and symptoms are not related to any
particular patient i.e. we do not take a ‘real’ patient and then simply change
the names. We use fake patients and simply add in various diagnoses and other
symptoms matching real coding/ drug formulae.

###  FCSR

FCSR has created a synthetic dataset generator, which creates the requested
number of fake patient profiles and related blood tests. Each patient is
identified by his **biographical data** (made of SSN, patient ID, name,
surname, address, nationality, gender, birth date and place, details about the
job, details about the school career) and his **blood test data** (containing
sample measurements of blood test components). Both the biographical data and
the blood test data are generated based on statistics about the Italian
population. As no real data are involved in the creation of the aforementioned
dataset, it neither describes nor belongs to any individual, and thus it can
be used in an ethics-compliant way to test the technology developed.

A sample of fake patient profile generated according to the Italian profile
(biographical data plus a sample blood test) is shown in the following:  
  
<table>  
<tr>  
<th>

{

</th>  
<th>

"address": {

"city": "Reggio Emilia",

"postalCode": 2010,

"road": "TESTI F. (Viale)",

"roadNumber": 10,

"telephoneNumber": 2982

},

"birthPlace": {

"birthCity": "Reggio Emilia",

"nationality": "IT"

},

"career": {

"job": "secondary",

"schoolYears": 15

},

"exams": {

"bloodTests": [{

</th>  
<th>

"antithrombin": {

"normalRange": [85, 117],

"unit": "%",

"value": 100

},

"cholesterol": {

"hdl": {

"normalRange": [0.9,2.0],

"unit": "mmol/L",

"value": 1.20076633391924

},

"ldl": {

"normalRange": [2.0, 3.4],

"unit": "mmol/L",

"value": 3.34000795522381

},

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

</td>  
<td>

</td>  
<td>

</td>  
<td>

"total": {

"normalRange": [3.0,6.5],

"unit": "mmol/L",

"value": 4.80668241996787

},

"tryglicerides": {

"normalRange": [0.9, 1.7],

"unit": "mmol/L",

"value": 1.32954065412412

}

},

"date": "1987-01-10",

"patientId": 1421586624

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

}

</td>  
<td>

</td>  
<td>

}]

},

"familyDoctor": {

"id": "54236bf1-447c-49b8-955f-69b4f46d5671"

},

"identity": {

"birthDate": "1956-07-21",

"gender": "M",

"name": "Gabriele",

"patientId": 1421586624,

"socialId": "ONPSIM10S36V660K",

"surname": "Eupizi"

}

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

###  OSA

Osabide Global (OSAKDIETZA´s System) will access the clinical data of the
patients for the creation of the Patient Summary, consulting multiple
repositories belonging to Osakidetza, among others:

  * Osabide AP 

  

  * Presbide 

  

  * Osanaia 

  

  * eOsabide 

  

Queries to these applications will be made via invocations to **Web**
**Services** . Although containing some elements of real data (see below),
clinical data from fake patients are used preserving the same format as real
ones for the SHiEld project.

####  Test environment

Ibermática is the one who carries out the developments on the Osakidetza
system (Osabide Global) and for this, they have created a test environment
with fake patients (their personal data are fictitious but the clinical data
are real as mentioned in the previous section). These data have the same
structure as real ones used in Osabide Global.

Access this test environment is restricted to Osakidetza and developers of
Ibermática (only those who are working for Osakidetza´s System).

Therefore, these are the test data we use in SHiELD.

Finally, for the simulation of sending clinical data between OpenNCP, we have
taken the clinical data of a real patient from Osabide Global system with
stroke (for use case breaking glass) and then, Ibermática has taken personal
data from a patient of the test environment and mixed with the clinical data
of the actual patient with stroke. Thus, creating a fake patient with useful
clinical data for the use case, with its correct structure (XML HL7 CDA Level
3).

In summary: the data

  * Are simulated, using the same structure as a live patient system 

  

  * Use simulated (non-real) patient details and identifiers 

  

  * Use some clinical data extracted from real patients with the target condition(s) 

  

**The real clinical data do not refer to the fake IDs of the simulated patient
records, therefore** .

####  Operations within the proof environment

As stated before, the data is obtained through Web Services, and these are
made through these three operations **getInformeHCRCDA3, getInformeHCRCDA2 y
getInformeHCRCDA3_V2.**

**Table 1. Web service structure for getInformeHRCDA3**  
  
<table>  
<tr>  
<th>

**Name of the operation**

</th>  
<th>

**getInformeHCRCDA3**

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

Access by

</td>  
<td>

B66-HCDSNS

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

Access to

</td>  
<td>

B40-OsabideGlobal

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

Description

</td>  
<td>

This method returns a patient's summary history report in HL7 CDA level 3
format.

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

Input parameters

</td>  
<td>

**[MANDATORY]** **Int cic** : Identifying Cic in Osakidetza of the patient to
be consulted.

**[MANDATORY] Int language** : Code identifying the language in which the
report will be displayed:

  * Spanish: 1 

  

  * Basque: 2 

  

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

Output parameters

</td>  
<td>

**Patient CDA3WS:**

**Int cic** : Cic that requested the report.

**String hcr:** XML message with the result of the query(CIC of the Patient
Summary Report in HL7 CDA Level 3).

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

Output size

</td>  
<td>

</td>  
<td>

Approximately 30kb, although it is variable depending on the volume of
information obtained from the different systems.

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

Number of

records

</td>  
<td>

output

</td>  
<td>

1

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

Errors

</td>  
<td>

</td>  
<td>

_OG002 - ERROR MISSING VALUE REQUIRED_

_OG004 - WRONG PARAMETER ERROR ERROR_

_OG005 - ERROR DB NOT CONFIGURED_

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

Messaging

</td>  
<td>

</td>  
<td>

XML

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

Interface

</td>  
<td>

</td>  
<td>

SOAP 1.1

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

Specific characteristics of the service for the

interface

</td>  
<td>

\- 24X7

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

Security

</td>  
<td>

</td>  
<td>

Authentication

</td>  
<td>

\- No: No authentication is required.

</td>  
<td>

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

Transport

</td>  
<td>

  * HTTP 

  

  * HTTPS 

  

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

**Table 2.Webservice structure for getInformeHRCDA2**  
  
<table>  
<tr>  
<th>

**Name of the operation**

</th>  
<th>

**getInformeHCRCDA2**

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

Access by

</td>  
<td>

B66-HCDSNS

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

Access to

</td>  
<td>

B40-OsabideGlobal

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

Description

</td>  
<td>

This method returns the report of a patient's summary history in PDF format
and the report header in CDA level 2.

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

Input parameters

</td>  
<td>

**[MANDATORY]** **Int cic** : Identifying Cic in Osakidetza of the patient to
be consulted.

**[MANDATORY] Int language** : Code identifying the language in which the
report will be displayed:

  * Spanish: 1 

  

  * Basque: 2 

  

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

Output parameters

</td>  
<td>

**PatientCDA2WS:**

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

</td>  
<td>

**Int cic** : Cic the report has been requested.

**String cabecera_HCR** : XML message with the result of the header of the
query (header of CIC Clinical History Report in HL7 CDA Level 2.)

**Byte[] hcr** : Document sent from clinical history summarized in PDF format.

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

Output size

</td>  
<td>

Approximately 120kb, although it is variable depending on the volume of
information obtained from the different systems.

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

Number of output

records

</td>  
<td>

1

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

Errors

</td>  
<td>

_OG002 - ERROR MISSING VALUE REQUIRED_

_OG004 - WRONG PARAMETER ERROR ERROR_

_OG005 - ERROR DB NOT CONFIGURED_

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

Messaging

</td>  
<td>

XML

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

Interface

</td>  
<td>

SOAP 1.1

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

Specific characteristics of the service for the

interface

</td>  
<td>

\- 24X7

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

Security

</td>  
<td>

</td>  
<td>

Authentication

</td>  
<td>

\- No: No authentication is required.

</td>  
<td>

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

Transport

</td>  
<td>

  * HTTP 

  

  * HTTPS 

  

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

**Table 3.Webservice structure for getInformeHRCDA3_V2**  
  
<table>  
<tr>  
<th>

**Name of the operation**

</th>  
<th>

**getInformeHCRCDA3_V2**

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

Access by

</td>  
<td>

B66-HCDSNS

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

Access to

</td>  
<td>

B40-OsabideGlobal

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

Description

</td>  
<td>

This method returns the report of a patient's summary history in HL7 CDA level
3 format and also in PDF format.

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

Input parameters

</td>  
<td>

**[MANDATORY]** **Int cic** : Identifying Cic in Osakidetza of the patient to
be consulted.

**[MANDATORY] Int language** : Code identifying the language in which the
report will be displayed:

• Spanish: 1

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

</td>  
<td>

• Basque: 2

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

Output parameters

</td>  
<td>

**PacienteCDA3WS_V2** :

**Int cic** : Cic who has requested the report.

**String hcr_cda** : XML message from HL7 with the result of the query (CIC
Summary Clinical History Report in HL7 CDA Level 3).

**Byte[] hcr_pdf** : Document sent from clinical history summarized in PDF
format.

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

Output size

</td>  
<td>

Approximately 170kb, although it is variable depending on the volume of
information obtained from the different systems.

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

Number of output

records

</td>  
<td>

1

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

Errors

</td>  
<td>

_OG002 - ERROR MISSING VALUE REQUIRED_

_OG004 - WRONG PARAMETER ERROR ERROR_

_OG005 - ERROR DB NOT CONFIGURED_

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

Messaging

</td>  
<td>

XML

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

Interface

</td>  
<td>

SOAP 1.1

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

Specific characteristics of the service for the

interface

</td>  
<td>

\- 24X7

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

Security

</td>  
<td>

</td>  
<td>

Authentication

</td>  
<td>

\- No: No authentication is required.

</td>  
<td>

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

Transport

</td>  
<td>

  * HTTP 

  

  * HTTPS 

  

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

####  Format and structure of the clinical data

The format of the Patient Summary must be HL7, CDA Level 3: in the case of
Osabide Global and unlike other reports, CDA level 3 (HL7) will be required,
which indicates that both the header and the body will be properly structured.
That is, just as other reports will be sent embedded in PDF (based on the
weight MTOM could be applied for the optimization of binary delivery), in the
case of Osabide Global, the XML should be sent properly structured according
to the standard HL7 CDA level 3 of coding (LOINC). An example of the code has
been added as Annex1.

##  Expected size of the data

At this stage of the project it still hard to define precisely the data size
and ingestion rate. However, it can be useful to go into details regarding the
dimension of the most important data involved in the use cases:

  * **Medical images** : include all the bio-images such as ultrasound scan, MRI (magnetic resonance imaging) or CT (computer tomography) scan. Considering that the **Computerized Tomography** uses 3D x-rays to make detailed pictures of structures inside of the body, it takes **pictures in slices** , like a loaf of bread. This means that each slice is a picture, the number of pictures can be from 30 for simple examinations to 1000+ for sophisticated examinations. This scan can be repeated several times (2-6) to reduce noise and to ensure high quality of the examination. In conclusion we will have from 30 to 1000 images each one of 5 MB times 2-6 series; we can say that a single CT examination for a patient will be between 300 MBand 30 GB depending on the kind of investigation; 

  

  * **SDO and ED dataset** : is around 1 Kb per patient since no images are included and since the information is codified (.txt format). 

  

  * **Blood tests:** for Italian patients, these are created synthetically using the synthetic dataset generator, which can produce as many entries as required. 

  

  * **Patients’ profiles:** for Italian patients, these are created synthetically using the synthetic dataset generator, which can produce as many entries as required. 

  

##  To whom might it be useful ('data utility')?

The results of SHiELD will be useful for healthcare providers, governments,
and patients.

#  FAIR DATA

This data management plan follows the FAIR (Findable Accessible Interoperable
Reusable) principles. It should be noted that no real patient data (e.g.,
scans relating to living data subjects in the OSA trial) will be published in
project deliverables or other publications.

##  Data findable

There are different types of data:

  * Data related to the use cases 

  

  * Data coming from publications 

  

  * Data coming from public deliverables 

  

  * Open source software 

  

###  Data related to the use cases

During the lifetime of the project and especially during the execution of
trials, SHiELD partners expect several types of data to be generated, mainly
health data, location data, personal data (“fake” names, addresses, contact
information, IP addresses, etc.), pseudonymised data (user names, device
identifiers, etc.), traffic data, as well as others.

The first step in development of the use case studies will be to produce a
high level outline of the scenario to be used in the project. Starting from
epSOS data exchange gateway, a set up for subsequent validation experiments
will be deployed. Since these experiments will involve some novel security
mechanisms whose value is not yet proven, current patient data will not be
used directly in the use cases. Instead, an equivalent test system will be
implemented by using synthetic patient data to verify that security is
effective without compromising the data exchange interoperability requirements
and that SHiELD solutions are compliant to European General Data Protection
Regulation 2016/679 [4].

The second step of the project will see the creation of synthetic data sets
which may be sampled or combined randomly and associated with
fictitiouspatients.

This synthetic set of medical information will include the minimum patient
summary dataset for electronic exchange developed in the epSOS project [5]
defined according to the clinical point of view keeping in mind the medical
perspective of the final users (medical doctors and patients).

SHiELD WP6 deliverable 6.1 describes a set of scenarios, and all digitalized
data included in Electronic Health Records (EHR), which includes as example:

  * Patient’s personal data 

  

  * Medical histories & Progress notes 

  

  * Diagnoses 

  

  * Acute and chronic medications 

  

  * Allergies 

  

  * Vaccinations 

  

  * Radiology images 

  

  * Lab and test results (e.g., blood tests) 

  

  * Clinical parameters (blood pressure, heart rate, capillary glucose, …) 

  

For each scenario it is going to be necessary to establish which are the
minimum clinical data needed to manage the patient in the most efficient way.
On the one hand, it will be necessary to establish the sensitivity and
security of the data, but on the other hand it is essential to provide the
health professionals with the minimum imprescriptible data in order to perform
an efficient management and also provide security in the management of the
patient. One of the aims of SHiELD is to establish the minimum data necessary
for each scenario just to improve the clinical management of foreign patients
while traveling along Europe.

In this way we need to:

  * Identify the fields to include, their format and range of values they can adopt. 

  

  * The classification of the field as part of the minimum set or if its inclusion is recommended, corresponding to each Health Service the final decision to include it or not. 

  

  * Include the field and its value as part of the attributes of the document as a "tag" to identify the essential elements of its content without having to open (decrypt) the document. 

  

To codify different fields of the minimum dataset that will be exchange we
have:

  * **SNOMED CT** or **SNOMED Clinical Terms:** is a systematically organized computer processable collection of  medical terms  providing codes, terms, synonyms and definitions used in clinical documentation and reporting. SNOMED CT is considered to be the most comprehensive, multilingual clinical healthcare terminology in the world. The primary purpose of SNOMED CT is to encode the meanings that are used in health information and to support the effective clinical recording of data with the aim of improving patient care. SNOMED CT provides the core general terminology for  electronic health records.  SNOMED CT comprehensive coverage includes: clinical findings, symptoms, diagnoses, procedures, body structures, organisms and other aetiologies, substances, pharmaceuticals, devices and specimens. between different Health Systems we have: 

  

  * **ICD-10** is the 10th revision of the International Statistical Classification of Diseases and Related Health Problems, a medical classification list by the World Health Organization. It contains codes for diseases, signs and symptoms, abnormal findings, complaints, social circumstances, and external causes of injury or diseases. The code set allows more than 14,400 different codes and permits the tracking of many new diagnoses. The codes can be expanded to over 16,000 codes by using optional sub-classifications. 

  

This is just a brief list of medical data; indeed, it represents only a subset
of the whole set of medical information that could be involved in SHiELD
project.

Documents that may include sensitive information and that can be used to test
the technologies developed during the project will be synthetically generated.
For example, Figure 1 represents a dismissal letter in which personal
information can be found (e.g., name and surname). A fake dismissal letter
using the very same format will be generated, so as to avoid the usage of real
patients’ data.

Figure 1: Document containing clinical record number and name.

Regarding medical images, Figure 2 represents a slice of a simulated patient.
Within this figure some sensitive information are circled in blue:

  * **FANTOCCIO** is the space dedicated to the patient name and surname; 

  

  * **PID** is the internal patient ID, it means that the code identifies the patient within hospital internal system; 

  

  * **Acc.num** is a progressive number in the hospital internal system; 

  

Figure 2: Slice of a simulated patient

Additional to synthetic data regarding to patient past hospitalization, SHiELD
project can include mobile data that can be useful for diagnostic purposes.
Data could come from both mobile and wearable devices; some examples of
datasets are provided:

  * GPS tracks ( _e.g._ localization); - Posts ( _e.g._ social registrations); - Last known activities: 

    * SMS sent at time XX.XX; 

  

    * Weather data; 

  

    * Activity tracker - Chronic patient monitoring; 

  

  

  * Drug therapy. 

  

This data coming from wearable devices are not directly health-related,
although they allow to get to health-related conclusions after processing.
They will be collected and processed in accordance with the provisions of the
Privacy and Electronic Communications Regulation  2  .

###  Metadata

All publications will be indexed by using Digital Object Identifiers or
similar mechanisms to be discovered and identified. All papers in journals and
magazines will use this identifier.

Concerning the naming convention, we will use the following: <<Dx.y
Deliverable name _ date in which the deliverable was submitted.pdf>>.

Each paper or deliverable contains a keywords section that can be used to
optimize possibilities for re-use.

Each deliverable is tagged with a clear version number as indicated on Figure
3, Figure 4 and

Figure 5. This is part of the metadata that each deliverable contains.
Additionally

  * Editor(s): who is/are the main leaders of this document 

  

  * Responsible Partner: who is/are the main responsible partner of this document 

  

  * Status-Version: draft, released, final 

  

  * Date: submission date 

  

  * Distribution level (CO, PU): confidential or public access according to SHiELD proposal 

  

  * Project Number: SHiELD project number 

  

  * Project Title: SHiELD title 

  

  * Title of Deliverable 

  

  * Due Date of Delivery to the EC: date to be sent to the European Commission (EC) 

  

  * Work package responsible for the Deliverable 

  

  * Editor(s):Who edit this deliverable 

  

  * Contributor(s): who have contributed 

  

  * Reviewer(s): reviewers 

  

  * Approved by: people who internally approved it to be submitted to EC 

  

  * Recommended/mandatory readers 

  

  * Abstract: it summarises this document 

  

  * Keyword List: a set of words which can provide an overview of the topic of this deliverable 

  

  * Disclaimer: copyrights if any 

  

Each document registers its revision history: version number, data, reason for
the modification, and by whom it is modified.

Figure 3: Deliverable front page where version is shown

Figure 4: Document description contains version number

Figure 5: Page headers contains version number

##  Data openly accessible

Data related to the use cases are going to be accessible through the SHiELD
deliverables which will be published on the website (  _http://www.project-
shield.eu/_ )  . All deliverables include a set of keywords and a brief
description that are aimed to facilitate the indexing and search of the
deliverables in search engines. Scientific publications are going to be
published as Open Data, we will use Open Aire [6] – compliant repositories.
For example, TECNALIA use its own repository, already indexed by Open Aire.
There are other repositories such as Zenodo [7] that can be used. The
deliverables will be stored at AIME’s hosting provider, and for three years
beyond the duration time frame of the project

All data produced will be made available through the use of deliverables,
papers in journals/magazines/conferences, or repositories. Where data used for
proving functionalities are not real, they are going to be distributed using
open source repositories, which will be easily accessible by using a browser.

According to the SHiELD Grant Agreement (GA) page 15 “The SHiELD DevOps and
solution will be as open source as possible (taking into account exploitation
plans and the IPR issues that might arise from the usage of proprietary
background)”. But basically all tools are following a freemium licensing
schema, where there is a public version that can be released as open source
and a commercial edition. All these software will be released at the end of
the project, by which time they will be mature enough.

At this moment, there are no specific arrangements, restrictions of use (apart
from GA), there is no data access committee, and licenses depend on each tool
used in SHiELD.

##  Data interoperable

Basically SHiELD project will produce a platform based on OpenNCP [5] which is
interoperable with other software. The structures used for data exchange
follow the eHealth DSI Interoperability Specifications [8]. Most of the
vocabularies used follow the traditional software engineering artefacts
descriptions, and for the eHealth domain we are using the HL7 [9] which
specifications do not have a cost.

##  Increase data re-use (through clarifying licences)

Data stemming from the use cases will be delivered through the appropriate
deliverables. Our approach is to extend a branch of the OpenNCP, and to add
SHiELD functionalities. Once we have finalised the project we integrate these
functionalities to the OpenNCP community, and this community will maintain
this platform. At the time of writing, we do not envision any embargo on data.

#  Allocation of resources

SHiELD does not envision additional resources for handling data management.
SHiELD will use open access repositories as much as possible for the following
data:

  * data related to the use cases 

  

  * data related to the meta-analysis 

  

  * data coming from publications 

  

  * data coming from public deliverables 

  

  * open source software 

  

Obviously there is an indirect cost for making data FAIR in our project. But
we consider as part of the activities of the SHiELD project. All partners in
the SHiELD project are responsible for data management.

#  Data security

SHiELD will ensure that the General Data Protection Regulation (GDPR) [4],
which came into force in May 2018, is ensured, especially in regards to
protection of private data. In addition, the SHiELD project provides the
following key results dealing with data security:

  * [KR03] Security requirements identification tool 

  

  * [KR04] SHiELD open architecture and open secure interoperability API 

  

  * [KR06] Data protection mechanisms: a suite of security mechanisms that address data protection threats and regulatory compliance issues in end-to-end heterogeneous systems 

  

  * [KR07] Privacy tool: it monitors the data access attempts to ensure that only valid requests are accepted and only the data that is really needed is provided 

  

#  Ethical aspects

The basis of ethical research is the principle of informed consent as stated
in our proposal. A clinical protocol will be developed and sent for approval
to the ethics committee associated with a given trial and all the necessary
competent authorities. All participants in SHiELD use cases will be informed
of all aspects of the research that might reasonably be expected to influence
willingness to participate. Project researchers will clarify questions and
obtain permission from participants before and after each practical exercise
(e.g. interview, co-creation session, etc.) to maintain on-going consent.
Participants will be recruited by each organization leading the use cases
(Osakidetza, FCSR, Lancs) and other supporting organizations (e.g. Ibermática,
Aimes) and will cover more than one type of citizens. If participants wish to
withdraw from the participation in the use cases at any time, they will be
able to do it, and their data, even the pseudoanonymized data, will be
destroyed. Each individual partner (Osakidetza, FCSR, Lancs) will act as Data
controller for their trial; data subjects will therefore know who to contact
with any questions or personal data access requests.

In WP1 there is a task entitled as “Task 1.3 Ethical trials management” where
we ensure that ethical principles are used throughout the use cases, which are
clustered together for management purposes in the work package related to the
use cases. Further explanations on ethical matters will be gathered in
deliverable D1.8 Ethical protocols and approvals.

#  Conclusions

The document is based on our SHiELD data management plan according to the
established H2020 template for a Data Management Plan (DMP) [1]. This document
is a report and reflects the use of data along this first half of the project.
It is a living document, and it will be updated on a regular basis. The Data
Summary section indicates the purpose of the data collection and generation.
SHiELD’s purpose is not to process data and to create a knowledge base from
this processing. We use “fake” data in the sense that the patient’s records
are not identifying real patients with their real health records. In practical
terms, though, we are building up test cases which may include individual
items (typically MRI or CT scans) associated with real patients, because the
SHiELD’s purpose is to test the technology developed. FCSR, Osakidetza and
LANCS have their own process for generating these test cases, which are either
be more or less complex.

From a more general overview, each data will be made FAIR (findable,
accessible, interoperable and reusable). SHiELD project’s key results are
briefly explains how the financial resources for this openness are envisioned
at this stage to be allocated. Section 5 and 6 outline security and ethical
aspects respectively, and finally Section 7 summarises this document.