european security in health data exchange deliverable d1.6 ... · v0.2 12/06/2018 fcsr contribution...

D1.6 – Data Management Report Version 1.0 – Final. Date: 17.07.2018

Project Title: SHIELD Contract No. GA 727301

http://project-shield.eu/

of 38

European Security in Health Data Exchange

Deliverable D1.6

Data Management Report

Editor(s): Xabier Larrucea, Jason Mansell, Alberto Berreteaga

Responsible Partner: TECNALIA

Status-Version: 1.0

Date: 17/07/2018

Distribution level (CO, PU): PU

Ref. Ares(2018)3791908 - 17/07/2018




of 38

Project Number: GA 727301

Project Title: SHiELD

Title of Deliverable: Data Management Report

Due Date of Delivery to the EC: 30/06/2018

Workpackage responsible for the Deliverable:

Tecnalia

Editor(s): Tecnalia

Contributor(s): Xabier Larrucea (Tecnalia), Eleonora Ciceri (FCSR), Borja López, Eunate Arana (OSA), Tony ( Lancs)

Reviewer(s): Brian (IT Innovation)

Approved by: All WP’s

Recommended/mandatory readers:

All WP’s

Abstract: This document specifies what the kind of data generated by the project is and how it will be exploited or made accessible for verification and re-use, and how it will be curated and preserved.

Keyword List: Data Management Plan, OpenAire, metadata

Disclaimer This document reflects only the author’s views and neither Agency nor the Commission are responsible for any use that may be made of the information contained therein




of 38

Document Description

Document Revision History

Version Date Modifications Introduced

Modification Reason Modified by

v0.1 01/06/2018 First draft version Xabier Larrucea, Jason Mansell, Alberto Berreteaga (TECNALIA)

V0.2 12/06/2018 FCSR contribution Eleonora Ciceri (FCSR)

V0.3 13/06/2018 Osakidetza contribution Borja López (Biocruces)

v0.4 22/06/2018 Revisions Xabier Larrucea (TECNALIA)

V0.5 05/07/2018 Review Brian Pickering (ITI)

V1.0 17/07/2018 Final modifications Xabier Larrucea (TECNALIA)




of 38

Table of Contents

Table of Contents .......................................................................................................................... 4

List of Figures ................................................................................................................................ 5

List of Tables .................................................................................................................................. 5

Terms and abbreviations ............................................................................................................... 6

Executive Summary ....................................................................................................................... 7

1 Introduction .......................................................................................................................... 8

1.1 About this deliverable ................................................................................................... 8

1.2 Document structure ...................................................................................................... 8

2 Data Summary ....................................................................................................................... 8

2.1 Purpose of the data collection/generation and its relation to the project’s objectives8

2.2 Types and formats ....................................................................................................... 10

2.3 Re-use of existing data ................................................................................................ 10

2.4 Origin of the data ........................................................................................................ 10

2.4.1 Lancs .................................................................................................................... 11

2.4.2 FCSR ..................................................................................................................... 11

2.4.3 OSA ...................................................................................................................... 12

2.4.3.1 Test environment ............................................................................................ 12

2.4.3.2 Operations within the proof environment ...................................................... 13

2.4.3.3 Format and structure of the clinical data ........................................................ 16

2.5 Expected size of the data ............................................................................................ 17

2.6 To whom might it be useful ('data utility')? ................................................................ 17

3 FAIR DATA............................................................................................................................ 17

3.1 Data findable ............................................................................................................... 17

3.1.1 Data related to the use cases .............................................................................. 17

3.1.2 Metadata ............................................................................................................. 20

3.2 Data openly accessible ................................................................................................ 22

3.3 Data interoperable ...................................................................................................... 22

3.4 Increase data re-use (through clarifying licences) ...................................................... 23

4 Allocation of resources ........................................................................................................ 23

5 Data security ....................................................................................................................... 23

6 Ethical aspects ..................................................................................................................... 23

7 Conclusions ......................................................................................................................... 24

8 References ........................................................................................................................... 24

ANNEX1: Example of XML for the Osakidetza scenarios ............................................................. 27

ANNEX2: Draft DPIA .................................................................................................................... 37




of 38

List of Figures

FIGURE 1: DOCUMENT CONTAINING CLINICAL RECORD NUMBER AND NAME. ............................................. 19 FIGURE 2: SLICE OF A SIMULATED PATIENT ........................................................................................... 20 FIGURE 3: DELIVERABLE FRONT PAGE WHERE VERSION IS SHOWN ............................................................ 21 FIGURE 4: DOCUMENT DESCRIPTION CONTAINS VERSION NUMBER ........................................................... 22 FIGURE 5: PAGE HEADERS CONTAINS VERSION NUMBER ......................................................................... 22

List of Tables

TABLE 1. WEB SERVICE STRUCTURE FOR GETINFORMEHRCDA3 .............................................................. 13 TABLE 2.WEBSERVICE STRUCTURE FOR GETINFORMEHRCDA2................................................................ 14 TABLE 3.WEBSERVICE STRUCTURE FOR GETINFORMEHRCDA3_V2 ......................................................... 15 TABLE 4: INFORMATION FOR DATA PROTECTION IMPACT ASSESSMENT ..................................................... 37




of 38

Terms and abbreviations

CDA Clinical Data Architecture

DMP Data Management Plan

EC European Commission epSOS Smart Open Services for European Patients

FAIR Findable, Accessible, Interoperable and Reusable

GDPR General Data Protection Regulation HL7 Health Level Seven

ICD International Statistical Classification of Diseases and Related Health Problems

KPI Key Performance Indicators

KR Key Results LOINC Logical Observation Identifiers Names and Codes

MRI Magnetic resonance imaging

MTOM Message Transmission Optimization Mechanism

PA Public Administrations PECR Privacy and Electronics Communications Regulation

SDO Service Data Object

SSN Social Security number

WP Work Package




of 38

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).




of 38

1 Introduction

1.1 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.

1.2 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.

2 Data Summary

2.1 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. o 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.

o 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




of 38

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.

o 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 data1. 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.

o 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.

1 Though in the case of OSA some individual medical records (such as individual CT scans) will be used, integrated into a simulated health record.




of 38

o 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. o KR12: Take up opportunities: its purpose is to identify the main users, standards

bodies and regulators.

2.2 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:

o SDO (discharge form) that contains 5 .txt files where each field is separated by “;”

o ED (Emergency Department) dataset. o Prescription forms. o Constant collection forms.

• Unstructured data refers to information that either does not have a pre-defined data model or 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:

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

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

2.3 Re-use of existing data

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

2.4 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

https://en.wikipedia.org/wiki/Data_model

https://en.wikipedia.org/wiki/Data_model

https://en.wikipedia.org/wiki/Plain_text

https://ec.europa.eu/digital-single-market/en/news/cross-border-health-project-epsos-what-has-it-achieved

https://ec.europa.eu/digital-single-market/en/news/cross-border-health-project-epsos-what-has-it-achieved




of 38

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.

2.4.1 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.

2.4.2 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:

{ "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": [{ "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 },




of 38

"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 }] }, "familyDoctor": { "id": "54236bf1-447c-49b8-955f-69b4f46d5671" }, "identity": { "birthDate": "1956-07-21", "gender": "M", "name": "Gabriele", "patientId": 1421586624, "socialId": "ONPSIM10S36V660K", "surname": "Eupizi" } }

2.4.3 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.

2.4.3.1 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.




of 38

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.

2.4.3.2 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

Name of the operation

getInformeHCRCDA3

Access by B66-HCDSNS

Access to B40-OsabideGlobal

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

Input parameters [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

Output parameters 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).




of 38

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

Number of output records

1

Errors OG002 - ERROR MISSING VALUE REQUIRED

OG004 - WRONG PARAMETER ERROR ERROR

OG005 - ERROR DB NOT CONFIGURED

Messaging XML

Interface SOAP 1.1

Specific characteristics of the service for the interface

- 24X7

Security Authentication - No: No authentication is required.

Transport - HTTP

- HTTPS

Table 2.Webservice structure for getInformeHRCDA2


getInformeHCRCDA2



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



• Spanish: 1

• Basque: 2

Output parameters PatientCDA2WS:




of 38

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.



1




Messaging XML

Interface SOAP 1.1


- 24X7


Transport - HTTP

- HTTPS

Table 3.Webservice structure for getInformeHRCDA3_V2


getInformeHCRCDA3_V2



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



• Spanish: 1




of 38

• Basque: 2

Output parameters 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.



1




Messaging XML

Interface SOAP 1.1


- 24X7


Transport - HTTP

- HTTPS

2.4.3.3 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.




of 38

2.5 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.

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

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

3 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.

3.1 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

3.1.1 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




of 38

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

https://en.wikipedia.org/wiki/Medical_terms

https://en.wikipedia.org/wiki/Electronic_health_record




of 38

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;




of 38

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 Regulation2.

3.1.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

2 https://ico.org.uk/for-organisations/guide-to-pecr/

https://ico.org.uk/for-organisations/guide-to-pecr/




of 38

• 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




of 38

Figure 4: Document description contains version number

Figure 5: Page headers contains version number

3.2 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.

3.3 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

http://www.project-shield.eu/




of 38

engineering artefacts descriptions, and for the eHealth domain we are using the HL7 [9] which specifications do not have a cost.

3.4 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.

4 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.

5 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

6 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




of 38

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 pseudo-anonymized 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.

7 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.

8 References

[1] European Commission;, "Data Management," July 2016. [Online]. Available: http://ec.europa.eu/research/participants/docs/h2020-funding-guide/cross-cutting-issues/open-access-data-management/data-management_en.htm#A1-template. [Accessed 10 May 2017].

[2] e. Network, "European Commission," eHealth Network, 19 November 2013. [Online]. Available: http://ec.europa.eu/health//sites/health/files/ehealth/docs/guidelines_patient_summary_en.pdf. [Accessed 2017].

[3] M. Registry, "dataset type NAL," 04 10 2016. [Online]. Available: http://publications.europa.eu/mdr/authority/dataset-type/index.html. [Accessed 18 05 2017].

[4] European Commission;, Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016, 2016.




of 38

[5] epSOS, "OpenNCP Community Home," 27 10 2016. [Online]. Available: https://ec.europa.eu/cefdigital/wiki/display/EHNCP/OpenNCP+Community+Home. [Accessed 18 05 2017].

[6] OpenAire, "OpenAire," [Online]. Available: https://www.openaire.eu/. [Accessed 15 05 2017].

[7] Zendo, “Zenodo,” [Online]. Available: www.zenodo.org. [Accessed 2016].

[8] e. DSI, "eHealth DSI Interoperability Specifications," 11 05 2017. [Online]. Available: https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/Specifications. [Accessed 18 05 2017].

[9] H. L. Seven, "Health Level Seven," [Online]. Available: http://www.hl7.org/implement/standards/index.cfm?ref=nav. [Accessed 18 05 2017].

[10] Information Commission Office;, "Data protection impact assessments," May 2018.

[Online]. Available: https://ico.org.uk/media/about-the-ico/consultations/2258461/dpia-template-v04-post-comms-review-20180308.pdf. [Accessed 15 June 2018].

[11] S. G. Stage Gate, "Stage Gate," 2016. [Online]. Available: www.stage-gate.com. [Accessed

26 January 2016].

[12] AENOR;, “UNE-CEN / TS 16555-1 EX Innovation Management Part 1: Innovation

Management System,” Madrid, 2013.

[13] J. Finch, "The Vignette Technique in Survey Research," Sociology, vol. 21, pp. 105-14, 1987.

[14] European Commission;, "Guidelines on Open Access to Scientific Publications and Research

Data," July 2016. [Online]. Available: http://ec.europa.eu/research/participants/data/ref/h2020/grants_manual/hi/oa_pilot/h2020-hi-oa-pilot-guide_en.pdf. [Accessed December 2016].

[15] DIGIT, “DCAT application profile implementation guidelines,” [Online]. Available:

https://ec.europa.eu/isa2/solutions/dcat-application-profile-data-portals-europe_en. [Accessed March 2016].

[16] C. Richardson, “Microservice architecture patterns and best practices,” 2017. [Online].

Available: https://microservices.io/. [Accessed March 2017].

[17] European Commission;, “ISA2: Interoperability solutions for public administrations,

businesses and citizens,” [Online]. Available: https://ec.europa.eu/isa2/home_en. [Accessed January 2017].

[18] SHIELD Consortium, "SHIELD Annex 1 - Research and Innovation Action - Number 727301,"

2017.

[19] SHIELD Consortium, "SHIELD Annex 1 - Research and Innovation Action - Number 727301,"

2017.

[20] SHIELD Consortium, "SHIELD Consortium Agreement v1.0," 2017.

[21] European Commission;, "Data Management," July 2016. [Online]. Available:

http://ec.europa.eu/research/participants/docs/h2020-funding-guide/cross-cutting-issues/open-access-data-management/data-management_en.htm#A1-template. [Accessed 9 January 2017].

[22] CITADEL Consortium, "CITADEL Annex 1 - Research and Innovation Action - Number

726755," 2016.




of 38




of 38

ANNEX1: Example of XML for the Osakidetza scenarios

78554<s:Envelope

xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">

<s:Body>

<getInformeHCRCDA3Response xmlns="http://tempuri.org/">

<getInformeHCRCDA3Result

xmlns:a="http://schemas.datacontract.org/2004/07/B40_Ibermatica.

Humancare.External.Entities"

xmlns:i="http://www.w3.org/2001/XMLSchema-instance">

<a:CIC>78554</a:CIC>

<a:HCR><![CDATA[<?xml version="1.0" encoding="utf-

8"?>

<?xml-stylesheet type="text/xsl" href="CDA_Profesional.xsl"?>

<ClinicalDocument xmlns:xsi="http://www.w3.org/2001/XMLSchema-

instance" xsi:schemaLocation="urn:hl7-org:v3 CDASchema/CDA.xsd"

xmlns:voc="urn:hl7-org:v3/voc" xmlns="urn:hl7-org:v3">

<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"

/>

<templateId root="2.16.724.4.50.1" />

<id root="2.16.724.4.16.1.100.3.1"

extension="1000000000042623" />

<code code="11488-4" codeSystem="2.16.840.1.113883.6.1"

codeSystemName="LOINC" displayName="Consultation note" />

<title>Historia Clínica Resumida</title>

<effectiveTime value="20171109131008" />

<confidentialityCode code="N"

codeSystem="2.16.840.1.113883.5.25" />

<languageCode code="es-ES" />

<setId root="2.16.724.4.16.1.100.3.1.1"

extension="2000000000006934" />

<versionNumber value="23" />

<recordTarget>

<patientRole>

<id root="2.16.724.4.16.1.100.2.1" extension="78554" />

<id root="2.16.724.4.40" extension="BBBBBBBBBZ326141" />

<id root="1.3.6.1.4.1.19126.3" extension="99446633S" />

<id root="1.3.6.1.4.1.19126.4" extension="291041193977" />

<id root="2.16.724.4.41" extension="20242" />

<id nullFlavor="UNK" />

<addr use="HP">

<state>Araba/Álava</state>

<city>Vitoria-Gasteiz</city>

<postalCode>1008</postalCode>

<streetNameType>Calle/Kalea</streetNameType>

<streetName>Adriano VI</streetName>

<houseNumber>1</houseNumber>

<additionalLocator>02</additionalLocator>

<additionalLocator>C</additionalLocator>

</addr>

<telecom value="tel:000000000" />

<patient>

<name>

<family>KORTAS</family>

<family>GARRIDO</family>




of 38

<given>ANE</given>

</name>

<administrativeGenderCode code="F"

codeSystem="2.16.840.1.113883.5.1" />

<birthTime value="19780319" />

</patient>

<providerOrganization>

<name>OSAKIDETZA-Servicio Vasco de Salud</name>

</providerOrganization>

</patientRole>

</recordTarget>

<author>

<time value="201711091310" />

<assignedAuthor>

<id root="2.16.724.4.16" />

<assignedAuthoringDevice>

<code code="B40" codeSystem="2.16.724.4.16.1.100.6.2"

codeSystemName="Clasificación sistema" displayName="OSABIDE

GLOBAL" />

<softwareName>B40-OSABIDE GLOBAL</softwareName>

</assignedAuthoringDevice>

</assignedAuthor>

</author>

<informant nullFlavor="UNK" />

<custodian>

<assignedCustodian classCode="ASSIGNED">

<representedCustodianOrganization classCode="ORG"

determinerCode="INSTANCE">

<id root="2.16.724.4.16" />

<name>OSAKIDETZA-Servicio Vasco de Salud</name>

</representedCustodianOrganization>

</assignedCustodian>

</custodian>

<legalAuthenticator>

<time value="20171109131009" />

<signatureCode code="N" />

<assignedEntity>

<id nullFlavor="UNK" />

</assignedEntity>

</legalAuthenticator>

<documentationOf>

<serviceEvent>

<effectiveTime>

<high value="20171108" />

</effectiveTime>

</serviceEvent>

</documentationOf>

<relatedDocument typeCode="RPLC">

<parentDocument>

<id root="2.16.724.4.16.1.100.3.1"

extension="1000000000042146" />

<setId root="2.16.724.4.16.1.100.3.1.1"

extension="2000000000006934" />

<versionNumber value="22" />

</parentDocument>




of 38

</relatedDocument>

<component>

<structuredBody>

<component>

<templateId root="2.16.724.4.50.1.1" />

<section>

<title>Existe información reservada por decisión del

paciente:</title>

<text>NO</text>

</section>

</component>

<component>

<templateId root="2.16.724.4.50.1.2" />

<section>

<title>Existe documento de instrucciones previas

(DVA):</title>

<text>NO</text>

</section>

</component>

<component>

<templateId root="2.16.724.4.50.1.4" />

<section>

<code code="8658-7" codeSystem="2.16.840.1.113883.6.1"

codeSystemName="LOINC" displayName="Alergias, reacciones

adversas, alertas" />

<title>Alergias</title>

<text>?<list><item>Aines</item></list></text>

</section>

</component>

<component>

<templateId root="2.16.724.4.50.1.5" />

<section>

<code code="11369-6"

codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"

displayName="Historial de vacunaciones" />

<title>Vacunaciones</title>

<text>?<list><item>Vacuna Td (Tétanos-difteria adutos)

1ª dosis 08/11/2017</item><item>Vacuna Virus Papiloma Humano

Tetravalent Se niega 08/11/2017</item><item>Vacuna Gripe Puesta

08/11/2017</item></list></text>

</section>

</component>

<component>

<templateId root="2.16.724.4.50.1.6" />

<section>



displayName="Historial de enfermedades" />

<title>Problemas Resueltos, Cerrados o

Inactivos</title>

<text>?<list><item>No disponible<content

styleCode="BOLD">Fecha: 17/09/2017</content></item><item>No

disponible<content styleCode="BOLD">Fecha:

04/09/2017</content></item><item>ESTADO DE EMBARAZO

INCIDENTAL<content styleCode="BOLD">Fecha:




of 38

04/09/2017</content></item><item>EMBARAZO<content

styleCode="BOLD">Fecha: 04/09/2017</content></item><item>DISNEA

NO ESPECIFICADA<content styleCode="BOLD">Fecha:

04/09/2017</content></item><item>DIFICULTAD RESPIRATORIA<content

styleCode="BOLD">Fecha:

04/09/2017</content></item><item>INSOMNIO, NO

ESPECIFICADO<content styleCode="BOLD">Fecha:

29/03/2017</content></item><item>INSOMNIO<content

styleCode="BOLD">Fecha:

29/03/2017</content></item><item>DIARREA, NO

ESPECIFICADA<content styleCode="BOLD">Fecha:

29/03/2017</content></item><item>DIARREAS Y PERDIDA DE

PESO<content styleCode="BOLD">Fecha:

29/03/2017</content></item><item>PRURITO ANOGENITAL, NO


29/03/2017</content></item><item>PRURITO VULVAR CRÓNICO<content

styleCode="BOLD">Fecha: 29/03/2017</content></item><item>DOLOR

TORÁCICO, NO ESPECIFICADO<content styleCode="BOLD">Fecha:

29/03/2017</content></item><item>DOLOR TORÁCICO NO

FILIADO<content styleCode="BOLD">Fecha:

29/03/2017</content></item><item>No disponible<content













styleCode="BOLD">Fecha: 09/10/2009</content></item><item>NEO MAL

CABEZA PANCREAS<content styleCode="BOLD">Fecha:

01/10/2009</content></item><item>NEO MAL CABEZA PANCREAS<content

styleCode="BOLD">Fecha: 01/10/2009</content></item><item>NEO MAL

CABEZA PANCREAS<content styleCode="BOLD">Fecha:

01/10/2009</content></item><item>SINTOMAS GENERALES -OTROS NO

CODIFICADOS<content styleCode="BOLD">Fecha:

11/09/2009</content></item><item>SINTOMAS GENERALES -OTROS NO

CODIFICADOS<content styleCode="BOLD">Fecha:













31/10/2006</content></item><item>OBSERV-SOSPECHA ENF NO




of 38








12/07/1994</content></item></list></text>

</section>

</component>

<component>

<templateId root="2.16.724.4.50.1.7" />

<section>



displayName="Lista de problemas" />

<title>Problemas y Episodios Activos</title>

<text>?<list><item ID="pr1">FIEBRE<content

styleCode="BOLD">Fecha: 08/11/2017</content></item><item

ID="pr2">LUMBALGIA<content styleCode="BOLD">Fecha:

08/11/2017</content></item><item ID="pr3">No disponible<content

styleCode="BOLD">Fecha: 13/10/2017</content></item><item

ID="pr4">No disponible<content styleCode="BOLD">Fecha:

23/11/2009</content></item></list></text>

<entry>

<observation classCode="OBS" moodCode="EVN">



displayName="MEDICAL PROBLEM" />


<value xsi:type="CD" code="780.60"

codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9-CM"

displayName="FIEBRE">

<originalText>

<reference value="#pr1" />

</originalText>

</value>

</observation>

</entry>

<entry>






<value xsi:type="CD" code="724.2"


displayName="LUMBALGIA">

<originalText>


</originalText>

</value>

</observation>

</entry>

<entry>




of 38






<value xsi:type="CD"


displayName="No disponible">

<originalText>


</originalText>

</value>

</observation>

</entry>

<entry>






<value xsi:type="CD"


displayName="No disponible">

<originalText>


</originalText>

</value>

</observation>

</entry>

</section>

</component>

<component>

<templateId root="2.16.724.4.50.1.8" />

<section>



displayName="Recomendaciones" />

<title>Recomendaciones</title>

<text>Recomendaciones no conocidas</text>

</section>

</component>

<component>

<templateId root="2.16.724.4.50.1.9" />

<section>


codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" />

<title>Fármacos</title>

<text>?<table><thead><tr><th>Medicamento</th><th>Posología</th><

th>Vía Administración</th><th /><th>Periodo</th><th

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

/><th>Desde</th><th>Hasta</th><th>Duración

</th></tr></thead><tbody><tr><td><list><item>EZETIMIBA 10MG 28

COMPRIMIDOS</item></list></td><td>1 COMPRIMIDO cada 8

horas</td><td>ORAL</td><td>08/11/2017</td><td>03/09/2018</td><td




of 38

>299 días</td></tr><tr><td><list><item>IBUPROFENO 400MG 30

COMPRIMIDOS</item></list></td><td>1 COMPRIMIDO en desayuno,

comida y

cena</td><td>ORAL</td><td>08/11/2017</td><td>02/11/2018</td><td>

359 días</td></tr><tr><td><list><item>SINTROM 1MG 60

COMPRIMIDOS</item></list></td><td>0 No

disponible</td><td>ORAL</td><td>08/11/2017</td><td>02/11/2018</t

d><td>359 días</td></tr></tbody></table></text>

<entry typeCode="COMP" contextConductionInd="true">

<substanceAdministration classCode="SBADM"

moodCode="EVN">

<templateId root="2.16.840.1.113883.10.20.1.24" />

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7"

/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.1"

/>

<id root="2.16.724.4.16.1.100.6.3"

extension="20173120083672" />

<text nullFlavor="UNK" />

<effectiveTime xsi:type="IVL_TS">

<low value="20171108" />

<high value="20180903" />

</effectiveTime>

<effectiveTime xsi:type="PIVL_TS" operator="A">

<period unit="cada_8_horas" />

</effectiveTime>

<routeCode code="26643006"

codeSystem="2.16.724.4.21.5.8.23" codeSystemName="SNOMED CT/ES"

displayName="ORAL" />

<doseQuantity unit="COMPRIMIDO" value="1" />

<consumable>

<manufacturedProduct classCode="MANU">

<manufacturedMaterial classCode="MMAT"

determinerCode="KIND">

<code codeSystem="2.16.724.4.21.5.15"

codeSystemName="Nomenclator de prescripción AEMPS"

displayName="EZETIMIBA 10MG 28 COMPRIMIDOS" />

</manufacturedMaterial>

</manufacturedProduct>

</consumable>

</substanceAdministration>

</entry>



moodCode="EVN">

<templateId root="2.16.840.1.113883.10.20.1.24" />

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7"

/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.1"

/>

<id root="2.16.724.4.16.1.100.6.3"

extension="20173120083671" />



<low value="20171108" />




of 38

<high value="20181102" />

</effectiveTime>


<period unit="en_desayuno,_comida_y_cena" />

</effectiveTime>




<doseQuantity unit="COMPRIMIDO" value="1" />

<consumable>




<code codeSystem="2.16.724.4.21.5.15"

codeSystemName="Nomenclator de prescripción AEMPS"

displayName="IBUPROFENO 400MG 30 COMPRIMIDOS" />



</consumable>


</entry>



moodCode="EVN">

<templateId root="2.16.840.1.113883.10.20.1.24" />

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7"

/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.1"

/>

<id root="2.16.724.4.16.1.100.6.3"

extension="20173120083670" />



<low value="20171108" />

<high value="20181102" />

</effectiveTime>


<period nullFlavor="UNK" />

</effectiveTime>




<doseQuantity value="0" />

<consumable>




<code code="654177"

codeSystem="2.16.724.4.21.5.15" codeSystemName="Nomenclator de

prescripción AEMPS" displayName="SINTROM 1MG 60 COMPRIMIDOS" />



</consumable>


</entry>




of 38

</section>

</component>

<component>

<templateId root="2.16.724.4.50.1.10" />

<section>



displayName="Diagnosticos enfermeros activos" />

<title>Diagnósticos Enfermeros Activos</title>

<text>?<list><item ID="diag1">Deterioro de la

integridad cutánea</item><item ID="diag2">Riesgo de disminución

de la perfusión tisular cardíaca</item></list></text>

<entry>


<code code="DISDX"

codeSystem="2.16.840.1.113883.3.7.1.16" codeSystemName="LOINC"

displayName="Diagnostico" />

<value xsi:type="CD" code="00046"

codeSystem="2.16.840.1.113883.6.204" codeSystemName="NANDA"

displayName="Deterioro de la integridad cutánea">

<originalText>

<reference value="#diag1" />

</originalText>

</value>

</observation>

</entry>

<entry>


<code code="DISDX"

codeSystem="2.16.840.1.113883.3.7.1.16" codeSystemName="LOINC"

displayName="Diagnostico" />


codeSystem="2.16.840.1.113883.6.204" codeSystemName="NANDA"

displayName="Riesgo de disminución de la perfusión tisular

cardíaca">

<originalText>

<reference value="#diag2" />

</originalText>

</value>

</observation>

</entry>

</section>

</component>

<component>

<templateId root="2.16.724.4.50.1.11" />

<section>



displayName="Resultados de enfermeria" />

<title>Resultados de Enfermería</title>

<text>?<list><item ID="res1">Curación de las

quemaduras</item><item ID="res2">Perfusión tisular:

cardíaca</item></list></text>

<entry>





of 38

<code nullFlavor="NA" />


codeSystem="2.16.840.1.113883.6.16" codeSystemName="NOC"

displayName="Curación de las quemaduras">

<originalText>

<reference value="#res1" />

</originalText>

</value>

</observation>

</entry>

<entry>




codeSystem="2.16.840.1.113883.6.16" codeSystemName="NOC"

displayName="Perfusión tisular: cardíaca">

<originalText>

<reference value="#res2" />

</originalText>

</value>

</observation>

</entry>

</section>

</component>

<component>

<templateId root="2.16.724.4.50.1.12" />

<section>



displayName="Intervenciones de enfermeria" />

<title>Intervenciones de Enfermería</title>

<text>?<list><item ID="inter1">Cuidados

cardíacos</item><item ID="inter2">Cuidados de las heridas:

quemaduras</item></list></text>

<entry>




codeSystem="2.16.840.1.113883.6.15" codeSystemName="NIC"

displayName="Cuidados cardíacos">

<originalText>

<reference value="#inter1" />

</originalText>

</value>

</observation>

</entry>

<entry>




codeSystem="2.16.840.1.113883.6.15" codeSystemName="NIC"

displayName="Cuidados de las heridas: quemaduras">

<originalText>

<reference value="#inter2" />

</originalText>




of 38

</value>

</observation>

</entry>

</section>

</component>

<component>

<templateId root="2.16.724.4.50.1.13" />

<section>



displayName="Alergias, reacciones adversas, alertas" />

<title>Alertas</title>

<text>?<list><item>Alertas no

conocidas</item></list></text>

</section>

</component>

</structuredBody>

</component>

</ClinicalDocument>]]></a:HCR>

</getInformeHCRCDA3Result>

</getInformeHCRCDA3Response>

</s:Body>

</s:Envelope>

ANNEX2: Draft DPIA

Although the majority of data for the trials is simulated, the use of some clinical data in the OSA trial needs some additional consideration. The GDPR [4] outlines a process to be assess and manage risks especially in regard to:

“…a type of processing in particular using new technologies” [4] Art 35(1)

and

“…processing on a large scale of special categories of data referred to in Article 9(1)” [4] Art 35 (3)(b).

Since the current plan for OSA includes special category data, the Consortium are now reviewing the need for those data, and have prepared the following data protection impact assessment (DPIA) in preparation for any subsequent discussion with the relevant data protection authority.

The following is based on the DPIA template published by the UK ICO [10], the following table summarises the draft impact assessment.

Table 4: Information for Data protection impact assessment

NEED FOR DPIA The technology under development in SHiELD is new (albeit extensions of existing capabilities)

The real (as opposed to simulated data) include medical images, classified as “special category” data according to the GDPR Art 9(1) [4].




of 38

This is a precautionary measure to be agreed in the first instance with the relevant hospital authorities in the Basque Country. If they believe that the matter should be taken further, then this will be agreed within the Consortium and taken forward to the Spanish DPA.

PROPOSED PROCESSING Clinical records related to actual patients, including medical images (CT scans), will be used but embedded within simulated data sets. Thus, there will be no direct link between the patient to which the medical images refer and the simulated patient used in the trial.

RISK LIKELIHOOD OF HARM SEVERITY OF HARM OVERALL RISK

Re-identification of the original data subject (the patient referred to by the image(s))

Low: identification would require expert knowledge (such as specialist consultant), plus existing knowledge of the specific case (such as a member of the team involved in treating the data subject / patient)

Low: any specific condition would already be known within the treatment environment

LOW

Consequent loss of privacy if data subject being treated for a specific condition.

Low: any re-identification would then have to be made public. Procedures are already in place at the hospital to deal with such issues

Low / Medium: the severity would depend on the nature of the condition; and individual data subject’s expectations in regard to their privacy

LOW

Identification of condition not previously identified by the hospital

Low (Negligible): project partners with access to any such images would not have the medical expertise to outperform the hospital itself

N/A N/A

At this time, there will only be discussion with OSA about the likelihood of these risks. Any further action is dependent on the outcome of such discussion.