TRILLIUM II

Deliverable 3.6: Catalogue of Security and Privacy Controls and Methods for mitigating the security and privacy risks associated with use cases

1

TRILLIUM II Reinforcing the Bridges and Scaling up EU/US Cooperation on Patient Summary

WP3 D3.6 v2018-03-26

Catalogue of Security and Privacy Controls and Methods for mitigating the security and privacy risks associated with use cases -WP3-Task 3.6-SRDC

Date 26.03.2018

Project title: Grant Agreement: Call identifier:

Trillium Bridge II – Reinforcing the Bridges and Scaling up EU/US Cooperation on Patient Summary 727745 H2020-SC1-2016-CNECT

Dissemination level: Public


2

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 727745

Deliverable description

Number and name of

deliverable:

D3.6 v2018-03-26 Catalogue of Security and Privacy Controls and Methods

for mitigating the security and privacy risks associated with use cases -WP3-

Task 3.6-SRDC

Publishable summary: This document analyses the selected IPS exchange use cases of the project

in order to recommend the required security and privacy measures that can

be implemented. In this respect, it examines the regulatory

challenges/barriers (introduced by EU GDPR, US Health Information

Portability and Accountability Act (HIPAA), the EU/US Privacy Shield);

identifies the information security and privacy risks concerning Personal

Information (PI); identifies the needs for security and privacy controls and

provides a ‘catalogue’ of security and privacy services and methods as a

guidance to implementers of these selected use cases.

Status: Final Version: 1.0 Last update: 21.03.2018

Deadline: 31 March 2018

Actual delivery: 26 March 2018

Lead beneficiary: SRDC

Contact: Gokce Banu Laleci Erturkmen, [email protected]

Contributors: Giorgio Cangioli

Editors: Gokce Banu Laleci Erturkmen

Statement of originality

This deliverable contains original unpublished work except where clearly indicated otherwise.

Acknowledgement of previously published material and of the work of others has been made through

appropriate citation, quotation or both.


3

Change History

Version Date Author Organisation Description

V0.1 20.10.2017 Gokce Banu Laleci Erturkmen

SRDC Template created, Initial SoTA Analysis, Initial methodology description


SRDC Methodology description is completed, Analysis of Unplanned care is initialized


SRDC Draft complete deliverable finalizing the analysis of unplanned care scenario


SRDC First complete version for consortium review


SRDC Final Version


4

Table of Contents Executive summary............................................................................................................................................ 6

1. Introduction ............................................................................................................................................... 7

1.1. The Project ......................................................................................................................................... 7

1.2. Purpose of the document .................................................................................................................. 7

1.3. Brief Introduction to the Methodology and Document Structure .................................................... 7

1.4. Definitions ......................................................................................................................................... 8

1.5. Abbreviations ................................................................................................................................... 11

2. Methodology Description ........................................................................................................................ 12

3. Privacy Principle set selected for Trillium II Project ................................................................................ 15

3.1.1. Lawfulness ............................................................................................................................... 16

3.1.2. Consent .................................................................................................................................... 16

3.1.3. Purpose Binding ....................................................................................................................... 17

3.1.4. Necessity and Data Minimisation ............................................................................................ 17

3.1.5. Transparency and Openness ................................................................................................... 18

3.1.6. Rights of the Individual ............................................................................................................ 19

3.1.7. Information Security ................................................................................................................ 19

3.1.8. Accountability .......................................................................................................................... 20

3.1.9. Data Protection by design and by default ............................................................................... 21

4. Analysis of the selected Trillium Bridge II Use Cases ............................................................................... 21

4.1. Cross-border unplanned care (epSOS/eHDSI) ................................................................................. 21

4.1.1. Use Case Description (Step 1) .................................................................................................. 21

4.1.2. Detailed Security & Privacy Analysis (Step 2) .......................................................................... 23

4.1.3. Recommended Security and Privacy Enhancing Technologies/Services (Step 3) ................... 31

4.2. Exchanging Patient summaries for enabling continuity of care for chronic disease patients ........ 42




4.3. Emergency and Disaster Management – Evacuation camp and Field Hospital .............................. 50




5. Conclusions .............................................................................................................................................. 57

6. Ethical Issues ............................................................................................................................................ 58


5

7. Appendix .................................................................................................................................................. 58

7.1. Reference Methodologies for Security and Privacy Management Analysis.................................... 58

7.1.1. OAISIS Privacy Management Reference Model and Methodology (PMRM) .......................... 58

7.1.2. PRIPARE (PReparing Industry to Privacy-by-design by supporting its Application in Research)

Privacy- and Security-by-Design Methodology Handbook ...................................................................... 63

7.1.3. ENISA Report on “Privacy and Data Protection by Design – from policy to engineering” ...... 66

7.2. Reference Security and Privacy Management Standards ............................................................... 68

7.3. ISO/IEC 29100 Information technology — Security techniques — Privacy framework .................. 70

7.4. EN 14484 - Health informatics - International transfer of personal health data covered by the EU

data protection directive – High-level security policy ................................................................................. 70

7.5. EU General Data Protection Regulation (GDPR) .............................................................................. 73

7.6. US Health Insurance Portability and Accountability Act (HIPAA) .................................................... 74

7.6.1. HIPAA Privacy Rule Principles: ................................................................................................. 74

7.6.2. HIPAA Privacy Rule Principles: ................................................................................................. 76

7.7. EU/US Privacy Shield ....................................................................................................................... 77

8. References ............................................................................................................................................... 79

List of Tables

Table 1 Multi-Level Data Flows Matrix of Unplanned Care Scenario .............................................................. 25

Table 2 Multi-Level Data Flows Matrix of Continuity of Care Scenario ........................................................... 46

Table 3 Multi-Level Data Flows Matrix of Emergency and Disaster Management Scenario .......................... 53

Table 4: Operational Privacy Principles selected by OASIS PMRM ................................................................. 59

Table 5: OASIS PMRM Services ........................................................................................................................ 62

Table 6: ENISA Design Strategies and Patterns ............................................................................................... 67

List of figures

Figure 1 Trillium PMA Methodology ............................................................................................................... 14

Figure 2 Overview of the Data Flow diagram of Unplanned care scenario based on Use case description ... 24

Figure 3 eHealth DSI Trust Zones .................................................................................................................... 37

Figure 4 Overview of the Data Flow diagram for Scenario A for Continuity of Care(Access with a country) . 45

Figure 5Overview of the Data Flow diagram for Scenario B for Continuity of Care (Access from another

country) ........................................................................................................................................................... 45

Figure 6 Overview of the Data Flow diagram for Emergency and Disaster Management Scenario ............... 53

Figure 7 OASIS PMRM Model .......................................................................................................................... 59

Figure 8 OASIS PMRM Methodology ............................................................................................................... 61

Figure 9 PRIPARE's methodology reference model ......................................................................................... 63

Figure 10 Pripare Methodology Steps ............................................................................................................. 64

Figure 11 PRIPARE – Operationalization of Privacy Principles ........................................................................ 64

Figure 12 Privacy Criteria identified for ISO 29100 privacy principle 3 (Collection Limitation) by PRIPARE ... 65


6

Executive summary The document is developed within the scope of European Commission funded H2020 Trillium-II project.

Trillium-II targets activities surrounding the International Patient Summary (IPS) standards in order to

increase digital health innovation, lower trade barriers, and advance patient safety & trust, and bridge the

gap between strategic intent and capability for action by Standards Development Organization (SDOs)

striving for interoperability, quality, and safety through standards adoption. The project specifically responds

to the EU-US interoperability roadmap call (SCI-HCO-14-2016) to further advance global Electronic Health

Record (EHR) interoperability.

Within the scope of data security and privacy, the main objective of this document is to analyse the selected

EU/US and global use cases of the project. In this respect, it examines the regulatory challenges/barriers

(introduced by EU GDPR, US Health Information Portability and Accountability Act (HIPAA), the EU/US Privacy

Shield); identifies the information security and privacy risks concerning Personal Information (PI); identifies

the needs for security and privacy controls and provides a ‘catalogue’ of security and privacy services and

methods as a guidance to implementers of these selected use cases.


7

1. Introduction

1.1. The Project Trillium II is a European Commission funded project under the Horizon2020 framework. The mission of the

project is to support an innovative collaborative community of public-and private-sector entities working

towards developing, deploying, and using eHealth science and technology to empower individuals, support

care, advance clinical outcomes, enhance patient safety and improve the health of populations.

1.2. Purpose of the document The objective of Task 3.6, hence this deliverable is thorough analysis of the selected EU/US and global use

cases to

• understand the legal landscape and regulatory challenges/barriers (introduced by EU GDPR, US

Health Information Portability and Accountability Act (HIPAA), the EU/US Privacy Shield);

• identify the security and privacy risks associated with information management (capture, store,

retain, process, and share/exchange) of sensitive Personal Information (PI);

• identify the needs for security and privacy controls

• provide a ‘catalogue’ of security and privacy services and methods as a guidance to implementers of

the selected use cases pilots

As a result, this deliverable will be report on Privacy Management Analysis (PMA) of the selected use cases,

which will provide traceability from Regulations/Principles/Preferences to the recommended Security &

Privacy Measures that needs to be implemented in pilot implementations.

1.3. Brief Introduction to the Methodology and Document Structure In order to carry out the Privacy Management Analysis (PMA) of the selected Trillium II use cases, we aim to

follow a Privacy by Design (PbD) approach as mandated by The General Data Protection Regulation (GDPR),

by following a standard based methodology exploiting the best practices established in the field. For this

purpose, we have conducted an analysis of a number of key studies in this field providing guidance about

how PbD approach can be successfully employed for analysing a use case at hand to identify the required

security and privacy architecture that meets the expectations of the legal landscape and the security and

privacy principles of all of the affected parties in the selected use case. Examined standards and guidelines

include:

• OASIS Privacy Management Reference Model and Methodology (PMRM)

• PRIPARE (PReparing Industry to Privacy-by-design by supporting its Application in Research) Privacy-

and Security-by-Design Methodology Handbook

• ENISA Report on “Privacy and Data Protection by Design – from policy to engineering”

In the light of the guidelines provided by these references, we have defined our methodology that we will follow for privacy and security management analysis of the selected Trillium II use cases in order to provide implementers guidance about the proposed security and privacy enhancing technologies (PETs) that can be utilized in pilot implementations. The basics outline of our methodology builds heavily upon OASIS PMRM methodology, with slight improvements proposed by PRIPARE Handbook. As OASIS PMRM does not propose concrete catalogue of PETs to select from, we have benefited from ENISA guidelines. In addition to this, we have extensively utilized the eHealth Digital Service Infrastructure (DSI) Security Service Specifications (eHDSI, eHealth DSI Security Services Specification, 2017), as one of the selected Trillium II use cases is “unplanned care” which is aimed to be operationalized enabling cross-border health data exchange under the Connecting Europe Facility (CEF) through the eHDSI architecture. Yet, different from the eHDSI, Trillium


8

II intends to use FHIR resources to reflect the needs of the International Patient Summary. In our analysis we will take in to account these differences and will provide references to security and privacy measures that is also applicable to RESTful FHIR resource exchange paradigm.

Section 2 introduces our methodology, based on the reference standards and guidelines presented in

Appendix 7.1. Then in Section 3, the Privacy Principle Set to be utilized in our methodology during the analysis

of the use cases are presented. The Privacy Principle Set selected is based on the nine main Privacy Principles

identified by ENISA and which have already been mapped to European Data Protection Directive 95/46/EC

(DPD), to Opinions of the Article 29 Data Protection Working Party (based on Art. 29 DPD) and to the

European General Data Protection Regulation (GDPR) as legal basis. On top of this, we have mapped these

principles to the respective clauses of HIPAA Security Rule and HIPAA Privacy Rule which are briefly

summarized in Appendix 7.6.

Section 4 present the analysis of the selected Trillium Bridge II use cases in the light of the established

methodology to provide the Privacy Management Analysis document. The list of use cases includes first of

all the “unplanned care” scenario as defined by Directive 2011/24/EU of 9 March 2011 on the application of

patients’ rights in cross-border healthcare (Directive 2011/24/EU, 2011). As a result of D3.1 (Trillium II

Consortium, 2018), two operational scenarios extending the use of patient summaries beyond cross border

emergency or unplanned care have been selected to be analysed in this deliverable:

• Scenario 1: Emergency and Disaster Management – Evacuation camp and Field Hospital

• Scenario 2: Exchanging patient summaries for enabling continuity of care for chronic disease

patients

These use cases have been analysed following the methodology steps, and necessary security and privacy

enhancing methods and services have been presented.

Section 0 concludes the deliverable by highlighting its major contributions.

1.4. Definitions Breach (privacy or security) Situation where personally identifiable information is processed in violation of one or more relevant privacy and or security safeguarding requirements (ISO/IEC 29100:2011, 2011) Consent Personally identifiable information (PII) principal’s freely given, specific and informed agreement to the processing of their PII (ISO/IEC 29100:2011, 2011) Covered entity (1) health plans, (2) health care clearinghouses, and (3) health care providers who electronically transmit any health information in connection with transactions for which HHS has adopted standards (HHS, 1996) De-Identified Health Information De-identified health information neither identifies nor provides a reasonable basis to identify an individual. There are two ways to de-identify information; either: 1) a formal determination by a qualified statistician; or 2) the removal of specified identifiers of the individual and of the individual’s relatives, household members, and employers is required, and is adequate only if the covered entity has no actual knowledge that the remaining information could be used to identify the individual. (HHS, 1996)


9

EHealth Digital Service Infrasturcture (eHDSI) The eHealth Digital Service Infrastructure (eHDSI or eHealth DSI) is the initial deployment and operation of services for cross-border health data exchange under the Connecting Europe Facility (CEF). eHDSI sets up and starts deploying the core and generic services, as defined in the CEF, for Patient Summary and ePrescription. The generic services are the necessary implementation of data exchange at country level, the core services at EU level. These together enable the provision of Cross Border eHealth Information Services https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/Mission - _ftn2 (CBeHIS). Electronic Protected Health Information (e-PHI) All individually identifiable health information a covered entity creates, receives, maintains or transmits in electronic form. (HHS, 1996) Function Activities or processes within each Service intended to satisfy the Privacy Control (OASIS PMRM TC, 2016)

Individually identifiable health information

Information, including demographic data, that relates to:

• the individual’s past, present or future physical or mental health or condition,

• the provision of health care to the individual, or

• the past, present, or future payment for the provision of health care to the individual,

and that identifies the individual or for which there is a reasonable basis to believe or be used to identify the

individual. (HHS, 1996) Note: The Privacy Rule excludes from protected health information employment records that a covered entity maintains

in its capacity as an employer and education and certain other records subject to, or defined in, the Family Educational

Rights and Privacy Act, 20 U.S.C. §1232g.

Mechanism The packaging and implementation of Services and Functions into manual or automated solutions called

Mechanisms (OASIS PMRM TC, 2016)

Patient Summary A Patient Summary is 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 the unscheduled care”; it can also be defined at a high level as: the minimum set

of information needed to assure Health Care Coordination and the continuity of care. (Directive 2011/24/EU,

2011)

PI Personal Information – any data that describes some attribute of, or that is uniquely associated with, a natural person. (OASIS PMRM TC, 2016) PII Personally Identifiable Information – any (set of) data that can be used to uniquely identify a natural person. (OASIS PMRM TC, 2016) Policy Laws, regulations, contractual terms and conditions, or operational rules or guidance associated with the collection, use, transmission, storage or destruction of personal information or personally identifiable information. (OASIS PMRM TC, 2016)

https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/Mission%20-%20_ftn2


10

Privacy Architecture (PA) An integrated set of policies, Controls, Services and Functions implemented in Mechanisms appropriate not only for a given Use Case resulting from use of the PMRM but applicable more broadly for future Use Cases. (OASIS PMRM TC, 2016) Privacy by Design (PbD) Privacy by Design is an approach to systems engineering which takes privacy into account throughout the whole engineering process. The concept is an example of value sensitive design, i.e., to take human values into account in a well-defined matter throughout the whole process and may have been derived from this. The concept originates in a joint report on “Privacy Enhancing technologies” by a joint team of the Information and Privacy Commissioner of Ontario, Canada, the Dutch Data Protection Authority and the Netherlands Organisation for Applied Scientific Research in 1995. (OASIS PMRM TC, 2016) Privacy Control An administrative, technical or physical safeguard employed within an organization or Domain in order to protect and manage PI. (OASIS PMRM TC, 2016) NOTE: Control is also used as a synonym for safeguard or countermeasure. (ISO/IEC 29100:2011, 2011) Privacy Impact Assessment Overall process of risk identification, risk analysis and risk evaluation with regard to the processing of personally identifiable information (PII) (ISO/IEC 29100:2011, 2011) Privacy Enhancing Technology (PET) A system of ICT measures protecting informational privacy by eliminating or minimising personal data thereby preventing unnecessary or unwanted processing of personal data, without the loss of the functionality of the information system. (ISO/IEC 29100:2011, 2011) Privacy Management The collection of policies, processes and methods used to protect and manage PI. (OASIS PMRM TC, 2016) Privacy Management Analysis (PMA) Documentation resulting from use of the PMRM and that serves multiple Stakeholders, including privacy officers, engineers and managers, general compliance managers, and system developers (OASIS PMRM TC, 2016) Privacy Policy Laws, regulations, contractual terms and conditions, or operational rules or guidance associated with the collection, use, transmission, trans-border flows, storage, retention or destruction of Personal Information or personally identifiable information. (OASIS PMRM TC, 2016) Privacy Principles Foundational terms which represent expectations, or high-level requirements, for protecting personal information and privacy, and which are organized and defined in multiple laws and regulations, and in publications by audit and advocacy organizations, and in the work of standards organizations. (OASIS PMRM TC, 2016)


11

Privacy Preferences Set of shared values governing the privacy protection of personally identifiable information (PII) when processed in information and communication technology systems. (ISO/IEC 29100:2011, 2011) Protected Health Information (PHI) All “individually identifiable health information” held or transmitted by a covered entity or its business associate, in any form or media, whether electronic, paper, or oral. (HHS, 1996) Service A defined collection of related Functions that operate for a specified purpose. For the PMRM, the eight Services and their Functions, when selected, satisfy Privacy Controls. (OASIS PMRM TC, 2016) Touch Point The intersection of data flows with Actors, Systems or Processes within Domains. (OASIS PMRM TC, 2016) Use Case In software and systems engineering, a use case is a list of actions or event steps, typically defining the interactions between a role (known in the Unified Modelling Language as an actor) and a system, to achieve a goal. The actor can be a human, an external system, or time. (OASIS PMRM TC, 2016)

1.5. Abbreviations

ABAC Attribute Based Access Control

AES Advanced Encryption Standard

CBeHIS Cross Border eHealth Information Services

CEF Connecting Europe Facility

CI Contextual Integrity

CNIL Commission nationale de l’informatique et des libertés

CoA Country of Origin

CoT Circle of Trust

DAC Discretionary Access Control

DPD Data Protection Directive 95/46/EC

DSI Digital Service Infrastructure

eHDSI eHealth Digital Service Infrastructure

eIDAS Electronic Identification and Trust Services

ENISA European Union Agency for Network and Information Security

e-PHI electronic protected health information

FDE Full disk encryption

FPE Format-preserving encryption

FSE File system-level encryption

GDPR General Data Protection Regulation

HHS U.S. Department of Health and Human Services

HIPAA Health Insurance Portability and Accountability Act

HP Health Professional

I&A Identification &Authentication

ICP Integrated Care Platform

ISO International Organization for Standardization

ITTF Information Technology Task Force


12

MAC Mandatory Access Control

NCPeH National Contact Point for eHealth

NIST National Institute of Standards and Technology

OASIS Advanced Open Standards for the Information Society

OCR Office for Civil Rights

P3P Platform for Privacy Preferences Project

PA Privacy Architecture

PBAC Policy Based Access Control

PbD Privacy by Design

PEAR Privacy Enhancing Architecture

PEKS Public-key Searchable Encryption

PET Privacy Enhancing Technology

PHI Protected Health Information

PI Personal Information

PII Personally Identifiable Information

PIA Privacy Impact Assessment

PMA Privacy Management Analysis

PoC Point of Care

PRIME Privacy and Identity Management for Europe

PrimeLife Privacy and Identity Management in Europe for Life

PS Patient Summary

RBAC Role Based Access Control

SAML Security Assertion Markup Language

S4P A declarative language for specifying both users' privacy preferences and services' privacy policies

SSE Symmetric Searchable Encryption

SSL Secure Sockets Layer

TLS Transport Layer Security

XACML extensible Access Control Markup Language

2. Methodology Description Having examined the reference standards and handbooks providing guidance about how to conduct privacy

management analysis following PbD approach, namely, OASIS PMRM, PRIPARE handbook, and ENISA

guidelines (presented in detail in Appendix 7.1) , we have decided to follow a hybrid approach by exploiting

the strengths of each of them as presented in Figure 1.

OASIS PMRM model will be the starting point of our methodology, as it directly addresses the objectives of

this task, via its ability to identify the privacy controls initially expressed as requirements or policy

declarations and translate them into privacy-supporting technical measures. The analysis phase (Step 1 & 2)

of PMRM will be followed.

The design phase of OASIS PMRM, and also PRIPARE falls short to propose concrete catalogue of security and

privacy measures (or PETs) to select from. At Step 3, we will exploit the catalogue of privacy design strategies

& PETs provided by ENISA Report on “Privacy and Data Protection by Design” and select among the most

relevant PETs that needs to be implemented to support the Privacy Controls selected as a result of Step 2. At

this step, we also aim to guide the implementers about the relevant standards that will guide them in

implementation of these PETs. In this step another important resource we have utilized is the eHealth Digital


13

Service Infrastructure (DSI) Security Service Specifications (eHDSI, eHealth DSI Security Services Specification,

2017). One of the selected Trillium II use cases is “unplanned care” which is aimed to be operationalized

enabling cross-border health data exchange under the Connecting Europe Facility (CEF) through the eHDSI

architecture. Within eHealth DSI Security Services Specification document detailed elaboration of quite a

number of PETs necessary to address the identfied privacy principles is already presented. When possible,

these will be pointed out as candidate PETs that can be implemented to support the Privacy Controls selected

as a result of Step 2.

In the following, the steps of our methodology will be presented briefly.

Step 0: Selecting common Set of Privacy Principles:

All three approaches propose to use a common set of Privacy Principles while analysing the use cases. These

selected set of Privacy Principles are foundational terms which represent expectations, or high-level

requirements of the laws and regulations applicable in the domain of interest for protecting personal

information and privacy. For this reason, as a prerequisite this common set of Privacy Principles needs to be

identified so that the use cases can be analysed in the light of these high-level requirements.

PMRM proposes to use 14 Operational Privacy Principles (see Section 7.1.2), which were derived from a

review of international legislative and regulatory instruments (such as the U.S. Privacy Act of 1974 and the

EU Data Protection Directive) in the ISTPA document. These principles are not directly applicable for our

analysis, as we need to address the requirements of EU General Data Protection Regulation (GDPR) and US

Health Insurance Portability and Accountability Act (HIPAA) requirements as well.

In the initial version of PRIPARE, 14 principles have been identified deriving from the draft EU GDPR (during

that period GDPR was not finalized). Later, PRIPARE decided to adopt the list of privacy principles set by

ISO29100, as it is the international privacy framework standard (See Appendix 7.3 for the full list).

In ENISA guidelines, eight main Privacy Principles from the European legal data protection context are

proposed by providing references to the European Data Protection Directive 95/46/EC (DPD), to Opinions of

the Article 29 Data Protection Working Party (based on Art. 29 DPD) and to the European General Data

Protection Regulation (GDPR). Please note that EN 14484 (Health informatics - International transfer of

personal health data covered by the EU data protection directive - High level security policy) (See Appendix

7.4) has provided Security and Privacy Principles based on the DPD, which now has been superseded by the

GDPR.

In our context, one of our reference set of privacy policies will be based on GDPR, hence we have decided to

start from these eight principles. On top of this, as Trillium II, addresses exchange of patient summaries

between US and EU, our second important policy document is the Health Insurance Portability and

Accountability Act of 1996 (HIPAA). We have reviewed HIPAA Security Rule and HIPAA Privacy Rule (see

Appendix 7.6 for a brief summary) to map the relevant clauses to the eight principles identified by ENISA.

This mapping is presented in Section 3.

Step 1: Define the Scope of Use Case:

In this step, we will briefly define the use case. We will be skipping the optional initial high-level privacy

impact assessment proposed by PMRM as it will be addressed in the second step.

Step 2: Develop Detailed Privacy Analysis


14

Step 2.1: Examine the Use Case: In this step, we will examine the use case description closely to identify the

domains, the systems and participants involved in the use case. Secondly the use case process definition is

closely examined to identify the steps where PIs are collected, stored, used, shared, transmitted, transferred

across borders, retained or disposed within a domain. In this analysis, the objective is to identify the data

flows and touch points involving PI.

Figure 1 Trillium PMA Methodology

Step 2.2: Identify and Categorize PIs: In this step the results of the previous step are examined to clearly

identify the PIs collected, stored, used, shared, transmitted, transferred across borders, retained or disposed.

They are categorized as Incoming, Internally generated and Outgoing PIs.

Step 2.3: Identifying Privacy Controls: This is a critical step, where the initial analysis of the use case is

examined in comparison with the privacy principles (which define the high-level requirements of the


15

applicable laws and policies) and identify the Privacy Controls required as set of selected privacy conformance

criteria. At this step, we will exploit the privacy guidelines and privacy criteria compiled by PRIPARE Project

addressing the needs of privacy principles. Here another useful resource is the epSOS Security Policy

documentation (epSOS Consortium, 2010) incorporating the security and privacy requirements of unplanned

care scenario which are later incorporated in to eHDSI Security Policy definition.

Step 3: In this step, our aim is to identify the technical system level services that are required to be

implemented for the management and compliance of detailed Privacy Policies and Privacy Controls selected

for the Use Case. Here we will exploit the Privacy Enhancing Technology (PET) library published by ENISA and

the eHealth DSI Security Service Specifications (eHDSI, eHealth DSI Security Services Specification, 2017). In

addition to this, where applicable, existing implementations of the selected services will be pointed out such

as OpenNCP security service implementations (epSOS security services).

In the following section the privacy principle set selected for Trillium II Project is described in detail.

3. Privacy Principle set selected for Trillium II Project

In Trillium II project’s selected use cases, the cross-border exchange of patient summaries is discussed

including cross-border exchanges between U.S. and EU countries. Within U.S., the processing and exchange

of health information is subject to compliance to the Health Insurance Portability and Accountability Act

(HIPAA) (HHS, 1996) Security and Privacy Rules, as described briefly in Appendix 7.6. On the other hand, in

EU on April 27, 2016, the new data protection principles, the EU General Data Protection Regulation (GDPR),

have been released as a Regulation of the European Parliament and of the Council (Regulation (EU) 2016/679)

to regulate the protection of natural persons with regard to the processing of personal data and on the free

movement of such data, and repealing Directive 95/46/EC (Directive 95/46/EC, 1995). It enters into

application on 25 May 2018 after a two-year transition period, and unlike a Directive, it does not require any

enabling legislation to be passed by governments (European Parliament & Council, 4/5/2016). As described,

ENISA Report in PbD, has thoroughly examined the new GDPR clauses and mapped these to eight Privacy and

Security Principles, that can be used during Privacy and Security by Design procedures.

Given the differences between these regulations and to provide organizations in the United States with a

reliable mechanism for personal data transfers from the European Union, while ensuring that EU data

subjects continue to benefit from effective safeguards and protection, as required by European legislation,

with respect to the processing of their personal data, when they have been transferred to non-EU countries,

the US Department of Commerce has issued the EU-U.S. and Swiss-U.S. Privacy Shield Frameworks (EU-U.S.

Privacy Shield Principles and Annex I, 2016) (briefly described in Section 7.7). The EU-U.S. Privacy Shield

imposes stronger obligations on U.S. companies to protect Europeans’ personal data. It reflects the

requirements of the European Court of Justice, which ruled the previous Safe Harbour Framework invalid

(European Commission, July 2016).

In Trillium Project, we will carry out our security and privacy management analysis based on the ENISA

principles, which has already been mapped to the EU GDPR clauses. On top of this, we have been carefully

analysed HIPAA Security and Privacy Rules to extract the security and privacy principles to be addressed (see

sections 7.6.1 and 7.6.2), and mapped these to the eight principles identified by ENISA.

In the following section, these nine principles and their mapping to EU DPD, GDPR and HIPAA security and

Privacy rules are presented.


16

3.1.1. Lawfulness According to European data protection law, the processing of personal data is only allowed if (a) the

individual, whose personal data are being processed (in the European legal framework called “data subject”)

has unambiguously given consent, or processing is necessary (b) for the performance of a contract, (c) for

compliance with a legal obligation, (d) in order to protect vital interests of the data subject, (e) for the

performance of a task carried out in the public interest, or (f) for the purposes of legitimate interests pursued

by the data processing entities if such interests are not overridden by the fundamental rights and freedoms

of the data subject. In the EU, processing is usually forbidden unless there is an explicit permission.

Similarly, HIPAA Privacy Rule aims to define and limit the circumstances in which an individual’s protected

health information may be used or disclosed by covered entities. A covered entity may not use or disclose

protected health information, except either: (1) as the Privacy Rule permits or requires; or (2) as the

individual who is the subject of the information (or the individual’s personal representative) authorizes in

writing.

References to European data protection law:

• Art. 7 DPD,

• Art. 29 Data Protection Working Party: “Opinion on the concept of personal data”,

• Art. 29 Data Protection Working Party: “Opinion on the notion of legitimate interests of the data controller”,

• Art. 5(1) point (a) GDPR principles “lawfulness, fairness and transparency”, and

• Art. 6 GDPR “lawfulness of processing”.

References to HIPAA Privacy Rule:

• Basic Principle: No use or disclosure of protected health information, except either: as the Privacy Rule permits or requires; or as the individual who is the subject of the information authorizes in writing - 45 C.F.R. § 164.502(a).

• Required Disclosures - 45 C.F.R. § 164.506(c), 45 C.F.R. § 164.501, 45 C.F.R. § 164.508(a)(2), 45 C.F.R. § 164.506(b), 45 C.F.R. § 164.510(a), 45 C.F.R. § 164.510(b), 45 C.F.R. §§ 164.502(a)(1)(iii), 45 C.F.R. § 164.512, 45 C.F.R. § 164.512, 45 CFR § 164.514(e).

References to HIPAA Security Rule:

• Information access management - 45 C.F.R. § 164.308(a)(4)(i).

3.1.2. Consent The term consent is further specified in EU legal framework as enabling lawful data processing of subjects'

personal data with specific and explicit indication of their intention about processing of their data. Consent

is related to the right to informational self-determination and by this an expression of the individuals'

freedoms in general. A declaration of consent is invalid if not all these requirements are met. Hence,

transparency is a prerequisite for consent. Furthermore, consent can be withdrawn with effect for the future.

In HIPAA Privacy Rule, a covered entity must obtain the individual’s written authorization for any use or

disclosure of protected health information that is not for treatment, payment or health care operations or

otherwise permitted or required by the Privacy Rule.



17

• Art. 2 point (h) DPD,

• Art. 29 Data Protection Working Party “Opinion on the definition of consent”,

• Art. 4(8) GDPR definition of the “data subject’s consent”, and

• Art. 7 GDPR “conditions for consent”.


• Authorization: The individual’s written authorization is required for any use or disclosure of protected health information that is not for treatment, payment or health care operations or otherwise permitted or required by the Privacy Rule. 45 C.F.R. § 164.508

• Optional consent for enabling disclosure for treatment, payment and healthcare operations - 45 C.F.R. § 164.506(b).

3.1.3. Purpose Binding In EU Legal framework, personal data obtained for one purpose must not be processed for other purposes

that are not compatible with the original purpose. The purpose has to be legitimate, and it has to be specified

and made explicit before collecting personal data.

In HIPAA Privacy rule, the individual’s written authorization is required for any use or disclosure of protected

health information that is not for treatment, payment or health care operations or otherwise permitted or

required by the Privacy Rule.


• Art. 6(1) points (b)-(e) DPD,

• Art. 29 Data Protection Working Party: “Opinion on purpose limitation”,

• Art. 29 Data Protection Working Party: “Opinion on personal data”,

• Art. 5(1) point (b) GDPR principle “purpose limitation”, also

• Art. 5(1) points (c)-(e) GDPR, and

• Art. 21(2a) GDPR.


• Authorization: The individual’s written authorization is required for any use or disclosure of protected health information that is not for treatment, payment or health care operations or otherwise permitted or required by the Privacy Rule - 45 C.F.R. § 164.508.



3.1.4. Necessity and Data Minimisation In EU Regulations, only personal data necessary for the respective purpose may be processed. Consequently,

personal data must be erased or effectively anonymised as soon as it is not anymore needed for the given

purpose.

A central aspect of the HIPAA Privacy Rule is the principle of “minimum necessary” use and disclosure. A

covered entity must make reasonable efforts to use, disclose, and request only the minimum amount of


18

protected health information needed to accomplish the intended purpose of the use, disclosure, or request.

Consistent with the Privacy Rule standard limiting uses and disclosures of PHI to the "minimum necessary,"

the Security Rule requires a covered entity to implement policies and procedures for authorizing access to

ePHI only when such access is appropriate based on the user or recipient's role (role-based access).


• Art. 7 DPD,

• Art. 29 Data Protection Working Party: “Opinion on anonymisation techniques”,

• Art. 29 Data Protection Working Party: “Opinion on the application of necessity and proportionality concepts and data protection within the law enforcement sector”,

• Art. 5(1) point (c) GDPR principle “data minimisation”,

• Art. 5(1) point (e) GDPR principle “storage minimisation”, and

• Art. 23 GDPR “data protection by design and by default”.


• Minimum necessary - Reasonable efforts to use, disclose, and request only the minimum amount 45 C.F.R. §§ 164.502(a)(1)(iii)., 45 C.F.R. §§ 164.502(b) and 164.514 (d).

• De-Identified Health Information: No restrictions on the use or disclosure of de-identified health information - 45 C.F.R. §§ 164.502(d)(2), 164.514(a) and (b).



3.1.5. Transparency and Openness Transparency and openness means that the relevant stakeholders get sufficient information about the usage

of their personal data. Furthermore, they need to understand possible risks deriving from the processing of

their data.

In HIPAA Privacy Rule, each covered entity, with certain exceptions, must provide a notice of its privacy

practices. The notice must describe the ways in which the covered entity may use and disclose protected

health information.


• Art. 10 DPD, Art. 11 DPD and Art. 14 DPD (obligations to inform the data subject),

• Art. 12 (a) (“right of access”),

• Art. 29 Data Protection Working Party: “Opinion on more harmonised information provisions”,

• Art. 5(1) point (a) GDPR (principles “lawfulness, fairness and transparency”),

• Art. 10a GDPR (“general principles for data subject rights”),

• Art. 11 GDPR (“concise, transparent, clear and easily accessible policies”),

• Art. 13a GDPR (“standardised information policies”),

• Art. 14 GDPR (“information to the data subject”),

• Art. 15 (“right to access and to obtain data for the data subject”), and

• Art. 12 (for defining the conditions for exercising data subject rights).



19

• Privacy Practices Notice: 45 C.F.R. §§ 164.520(a) and (b).

3.1.6. Rights of the Individual In EU regulations, individuals have the right to access and rectify as well as (constrained) to block and erase

their personal data. Further they have the right to withdraw given consent with effect for the future.

In HIPAA, individuals have the right to review and obtain a copy of their protected health information in a

covered entity’s designated record set; to have covered entities amend their protected health information

in a designated record set when that information is inaccurate or incomplete; to an accounting of the

disclosures of their protected health information by a covered entity or the covered entity’s business

associates; to request that a covered entity restrict use or disclosure of protected health information. In

addition to these, individuals have right to complain about covered entities’ compliance with its privacy

policies and procedures.


• Art. 12 point (b) and (c) DPD (“right of access”, in point (b) in particular: the rectification, erasure or blocking of data if appropriate),

• Art. 14 DPD (“right to object”),

• Art. 5 No. 1 (ea) GDPR (principle “effectiveness”),

• Art. 7(3) GDPR (right to withdraw consent at any time),

• Art. 10a GDPR (“general principles for data subject rights”),

• Art. 13 GDPR (“notification requirement in the event of rectification and erasure”),

• Art. 17 GDPR (“right to erasure”),

• Art. 19 GDPR (“right to object”), and

• Art. 12 (for defining the conditions for exercising data subject rights).


• Privacy Practices Notice: With certain exceptions, a notice of privacy practices must be provided. - 45 C.F.R. §§ 164.520(a) and (b).

Access: Right to review and obtain a copy of protected health information - 45 C.F.R. § 164.524.

Amendment: Right to amend protected health information when inaccurate or incomplete - 45 C.F.R. § 164.526.

Disclosure Accounting: Right to request an accounting of the disclosures of their protected health information by a covered entity or the covered entity’s business associates - 45 C.F.R. § 164.528.

Restriction request: Right to request that a covered entity restrict use or disclosure of protected health information for treatment, payment or health care operations, disclosure to persons involved in the individual’s health care or payment for health care, or disclosure to notify family members or others about the individual’s general condition, location, or death. 45 C.F.R. § 164.522(a).

• Complaints: Individuals have right to complain about privacy policies and procedures. - 45 C.F.R. § 164.530(d).

3.1.7. Information Security Information security addresses the protection goals confidentiality, integrity, availability. All of these goals

are important also from a privacy and data protection perspective that specifically requires that unauthorised

access and processing, manipulation, loss, destruction and damage are prevented. Further, the data must be


20

accurate. This principle addressed in EU regulations calls for appropriate technical and organizational

safeguards.

HIPAA Security Rule requires covered entities to maintain reasonable and appropriate administrative,

technical, and physical safeguards for protecting ePHI including ensuring the confidentiality, integrity, and

availability of all ePHI they create, receive, maintain or transmit.


• Art. 16 DPD “Confidentiality of processing”,

• Art. 17 DPD “Security of processing”,

• Art. 5 No. 1 (d) GDPR (principle “accuracy”),

• Art. 5 No. 1 (ea) GDPR (principle “integrity”),

• Art. 30 GDPR “Security of processing”, and

• Art. 50 GDPR (“Professional secrecy”).


• Business Associate Contract: Specified written safeguards on the individually identifiable health information used or disclosed by business associates - 45 C.F.R. §§ 164.502(e), 164.504(e).

• Data safeguards - 45 C.F.R. § 164.530(c).

• Documentation and Record retention - 45 C.F.R. § 164.530(j).


• General Rule: The Security Rule requires covered entities to maintain reasonable and appropriate administrative, technical, and physical safeguards for protecting ePHI including ensuring the confidentiality, integrity, and availability of all ePHI they create, receive, maintain or transmit- 45 C.F.R. § 164.306, 45 C.F.R. § 164.304.

• Access Control- 45 C.F.R. § 164.312(a).

• Integrity Control- 45 C.F.R. § 164.312(b).

• Transmission Security - 45 C.F.R. § 164.312(e).


3.1.8. Accountability Accountability means to ensure and to demonstrate the compliance with privacy and data protection

principles (or legal requirements). This requires internal and external auditing and controlling of all data

processing. A means for demonstrating compliance can be a data protection impact assessment. On a

national level, accountability is supported by independent Data Protection Authorities for monitoring and

checking as supervisory bodies.

HIPAA necessitates covered entities need to provide records and compliance reports and to cooperate with,

and permit access to information for, investigations and compliance reviews. In addition to this, individuals

have right to request an accounting of the disclosures of their protected health information by a covered

entity or the covered entity’s business associates.



21

• In the DPD, accountability is not directly stated, but aspects of the principle can be seen, among others, in Art. 17 DPD (Security of processing) or by mentioning the possibility of appointing a “personal data protection official” in Art. 18 DPD who should be responsible for ensuring the application of data protection law.

• Art. 29 Data Protection Working Party: “The Future of Privacy”,

• Art. 29 Data Protection Working Party: “Opinion on the principle of accountability”,

• Art. 5(1) point (f) GDPR and Art. 22 GDPR (“Responsibility and accountability of the controller”),

• Art. 33 GDPR (“Data protection impact assessment”), and

• Art. 35 GDPR (“Designation of the data protection officer”).


• Disclosure Accounting: Right to request an accounting of the disclosures of protected health information - 45 C.F.R. § 164.528.

• Compliance- 45 C.F.R.§ 160.304


• Audit controls - 45 C.F.R. § 164.312(b).

• Integrity controls - 45 C.F.R. § 164.312(c).

• Policies and procedures and documentation requirements - 45 C.F.R. § 164.316.

3.1.9. Data Protection by design and by default This principle asserts that privacy features should be built from the beginning instead of adapting a product

or service at a later stage. The involvement in the design process supports the consideration of the full life-

cycle of the data and its usage. The principle “Privacy/data protection by default” means that in the default

setting the user is already protected against privacy risks. In many cases, a privacy-respecting default would

not allow an extended functionality of the product, unless the user explicitly chooses it.


• In the DPD, data protection by design is rather indirectly addressed, e.g. in Art. 17 DPD (Security of processing) where appropriate safeguards are demanded, even if this provision was mainly directed to security instead of privacy guarantees.

• Art. 29 Data Protection Working Party: “The Future of Privacy”, and

• Art. 23 GDPR (“Data protection by design and by default”).

4. Analysis of the selected Trillium Bridge II Use Cases

4.1. Cross-border unplanned care (epSOS/eHDSI)

4.1.1. Use Case Description (Step 1) This Use Case was described by Directive 2011/24/EU of 9 March 2011 on the application of patients’ rights

in cross-border healthcare (Directive 2011/24/EU, 2011). This use case has been defined by epSOS project

and will be operationalized via the eHealth Digital Service Infrastructure (eHDSI or eHealth DSI) enabling

cross-border health data exchange under the Connecting Europe Facility (CEF). In epSOS and in eHDSI, the

technical solution that has been adopted is exchanging Patient summaries represented as CDA documents


22

over the IHE XC* infrastructure. Whereas Trillium II intends to use FHIR resources to reflect the needs of the

International Patient Summary. In our analysis we will take in to account these differences and will provide

references to security and privacy measures that is also applicable to RESTful FHIR resource exchange

paradigm.

Title Patient summary sharing on a cross-border scale

Purpose Sharing information about the medical background and history of a patient from

Country A (the patient’s country of affiliation) with a healthcare professional in

another Country B (the country of treatment)

Relevance Many people request medical help when travelling, working or living abroad.

Medical information from the country of origin should be available to all citizens

(in their native language). The current solutions (if any) for obtaining medical

information from another country are often cumbersome, unsafe, incomplete

and non-standard. The treatment of patients without proper medical background

information is hazardous and should be avoided. Benefits can be gained from

increased quality of care (e.g. patient safety) (both medical and economical) and

from a decrease in the effort of gathering/exchanging health information. This

Use Case proposes a way towards solving this problem.

Domain Patient Summary

Scale Cross-border

Context The definition of a Patient Summary was laid down by the epSOS project as a starting point for the development and pilot testing of a Patient Summary for citizens who are travelling abroad and need medical help (unplanned). Challenges are related to the level of data required and the quality of information relevant to support patient treatment effectively across different participating countries. Different countries operate different health care systems, support their own culture for healthcare provision, and may use a different (or several different) language(s). A Patient Summary provides background information on important aspects such as allergies, current medication, previous illnesses and surgeries, etc. These are necessary for the proper treatment of a patient abroad, especially when there is a language barrier between the healthcare professional (HP) and the patient. Two Use Cases are possible with regard to the Patient Summary (PS). The first is

the one in which an occasional visitor needs his/her PS in country B. The second

is the one in which the person is a regular visitor in country B (i.e. someone who

lives in one country but works in another country). The distinguishing

characteristic is that the HP may have some information available from previous

encounters in this type of occasional situation. Both a PS from country A and one

from country B need to be consulted. In this Use Case, the Use Case of the

occasional visitor is described.

Information Patient Summary (in patient’s language and country B language)

Patient Consent

Participants Patient

Health professional in patient’s country of origin/affiliation (country A) Health professional in country of treatment (country B)


23

Functional process

steps

(With the reservation that preconditions are met)

• The patient consults a health professional in country B.

• The patient is identified (identity confirmed by country A)

• The health professional is identified, authenticated and authorized.

• The patient may have given consent before travelling to country B or in country B to the health professional (except for emergency cases).

• In the latter case, the health professional will then register this confirmation.

• The Patient Summary is electronically transferred from the patient’s country of origin to the health professional in the country that s/he is visiting (the “visiting country”) in a secure way. The health professional retrieves the Patient Summary and uses it for the consultation.

• The PS is received in both the language of the patient (PDF of original PS)

and as a translated version for the health professional.

4.1.2. Detailed Security & Privacy Analysis (Step 2)

Step 2.1: Identify Participants and Systems, Domains and Domain Owners, Roles and Responsibilities, Touch

Points and Data Flows

In this section, we will utilize eHDSI descriptions for the overall system description outlining the participants,

systems, domains and responsibilities (eHDSI, eHealth DSI Security Services Specification, 2017).

The core paradigm of this use case is not to directly connect physicians, but to connect the national infrastructures of a patient’s home country and the country where a patient currently receives medical services. Patients’ home country is referred to as country 'A', and the country, where the patient gets medical treatment, is referred to as country 'B':

• Country A is the country of affiliation (CoA), this means that country A is legally the exclusive entity, which is responsible for appropriately storing, archiving and documenting any required health information of a patient within its existing national infrastructure.

• Country B is the country where the point of care (PoC) is located that provides healthcare to a patient from country A. It is assumed that the Health Professional (HP) that treat the patient can only be unequivocally authenticated by the competent authorities of country B.

The PoC could be a hospital, an individual practitioner, a pharmacy or any other point of the health care system of any country, participating in the pilot project. Each country is represented by a “National Contact Point for eHealth (NCPeH)” creating a Circle of Trust” (CoT) that enables inbound and outbound communication cross borders. It is assumed that within each country, through the agreements between PoCs and NCPeH a national Circles of Trust is created, which leads up to building cascaded circles of trust. In the light of these descriptions and OAISIS PMRM guidelines, the Domains identified are Country A and Country B as different policies may apply especially for the interactions between PoCs and NCPeHs (i.e. HIPAA in U.S., EU GDPR within EU countries). Yet as described in section 3, for the interactions between the NCPeHs of Country A and Country B, either EU-US Privacy Shield (when cross border exchange between an EU member state and U.S. is targeted) or directly GDPR (when cross border exchange between an EU member states) would apply. To cover these, we will follow the principles set in Section 3 covering the needs of these. The Systems identified are PoC and NCPeH gateways. The Actors identified (also by eHDSI Glossary) are:


24

• Patient: Any natural person who receives or wishes to receive health care in a country involved in this use case.

• Healthcare Professional (HP): A doctor of medicine, a nurse responsible for general care, a dental practitioner, a midwife or a pharmacist involved in the care of a Patient. Furthermore, a HP must be under national law or rules established by national competent authorities to the obligation of professional secrecy or by another person also subject to an equivalent obligation of secrecy.

• National Contact Point for eHealth (NCPeH): A legal entity representing a country involved in this use case, assuming legal duties towards participating countries and its own network of national gateways: it acts in a bidirectional way transmitting in-outbound messages between national IT infrastructures and NCPeHs from other countries). A NCPeH processes medical data to achieve interoperability.

• Technical Staff: Any person or organization participating in the use case implementation processes not involved in the medical treatment of a patient such as:

o System administrator – in charge of the central organisation that maintain the system o Local system administrator – in charge of the local, national organisation that maintain the

system locally within a participating country o System operators.

• Data Security Officer: The data security officer of the organization, which processes healthcare-related data. For example, he/she can check the log data, if there is a reasonable suspicion and the patient agreed.

Based on the Functional Process Steps presented in the Use Case description, a high-level interaction diagram has been prepared to analyze the data flow, as presented in Figure 2.

Figure 2 Overview of the Data Flow diagram of Unplanned care scenario based on Use case description

In Table 1, the multi-level (domain/system) data flow matrix is presented where the data flow between the

different systems identified in the domains are highlighted for an easy identification of the touchpoints. The

Domains and Systems are represented as Row and Column headings, while the data being exchanged

between these systems is presented within the cells at cross points of these row and column headings. In

this way, the touch points are highlighted.


25

Table 1 Multi-Level Data Flows Matrix of Unplanned Care Scenario

Country A (Domain 1) Country B (Domain 2)

PoC A NCPeH A PoC B NCPeH B

Country A (Domain 1)

PoC A -Patient Consent -Patient Summary

NCPeH A

-Document Metadata -Patient Summary

Country B (Domain 2)

PoC B -Patient Identity Claim -HP Identity Claim -Patient Summary Query

NCPeH B

-Patient Identity Claim -HP Identity Claim -Patient Summary Query


Step 2.2: Identify PIs

The following Personally Identifying (PI) Data have been identified:

• Healthcare-related Data: Healthcare Data of a Patient Summary used for the medical treatment of a patient. Both according to EU regulations and HIPAA, the processing of these medical data has to satisfy higher privacy requirements. Healthcare related data contain also:

o data about the Patient Consent; o log data which provide information about the access to healthcare related data. Please note

that these logs may include personally identifiable information as it may relate to access to personally identifiable health data.

• Critical Meta Data: Data needed to control the exchange of healthcare related data between NCPeHs and between NCPeHs and PoCs, respectively. Critical Meta Data include authentication, identification and administrative data to clearly identify patients, PoCs and HPs (see identity claims data identified in the Data Flow Matrix table above)

Among these, Patient Consent and Identity Claims can be categorized as Incoming PIs, while the log data and

administrative data can be categorized as Internally Generated PIs. Patient Summary can be categorized as

both Incoming and Outgoing PIs.

Step 2.3: Identify Privacy Controls:

In this step, initial analysis of the use cases, where the data flows including PI exchanges, is examined in

comparison with the privacy principles (which define the high-level requirements of the applicable laws), and

the security and privacy conformance criteria are identified (where applicable by deriving from eHDSI

Security Policy requirements):

Lawfulness

C.1. Organisations involving in use case implementation and organisations hosting components of

the system MUST collect, create, use, maintain, and share personal data, only if and to the extent

authorized by a clearly defined legal basis (including user consent or any other legal basis).


26

Consent

C.2. It MUST be ensured to obtain patient consent (direct or derived based on legal basis) allowing

his Patient Summary in Country of Affiliation can be accessed in Country of Treatment for

treatment purposes.

Purpose Binding


the system MUST only use or disclose medical information for purposes consistent with those

for which it was collected, except in the case of Patient consent or if permitted (or required) by

law.

Necessity and Data Minimisation


the system MUST avoid and minimise the use of personal data along its whole lifecycle by

keeping only the strict minimum data necessary for the strictly specific, consented, minimal

purposes.


the system MUST delete or anonymise personal data when PI is no longer needed for the

specified purpose.

C.6. In order to limit the ability of external parties from inferring personal data from sources coming

from different controllers, Organisations hosting pilot implementation components MUST

introduce network controls to segregate information services, Users and information systems

that are not involved in access to or hosting of the systems. Separated management networks

are recommended.

C.7. In order to minimize the traces left by transactions and interactions, when the Users perform a transaction or otherwise interact with the system, NCPeH and PoCs must ensure that

a. any information associated to that event does not disclose the identity of the data subjects, and allows them to remain anonymous

b. no two transactions by the same data subject can be linked with each other c. no other party can ascertain or observe whether the transaction has happened.

C.8. A process MUST be developed by each Country on when and how to destroy all data objects

created for the use case implementation after its conclusion

Transparency and openness

C.9. Organisations involved in use case implementation and organisations hosting components of the

system MUST provide an appropriate, well-documented, public privacy notice to the data

subjects, which

a. describes all the processes, where any personal data is involved, describing the personal

data collected and the purposes for which it is collected,

b. describes all the activities that impact personal data: collection, creation, storage, use,

maintenance, sharing and disposal of personal data

c. describes all the internal uses of personal data

d. describes how the organization processes personal data

e. provides contact information for questions or complaints


27

f. refers users to the applicable legislation

C.10. Organisations participating to Privacy Shield programme, MUST inform data subjects about:

a. its participation in the Privacy Shield by Privacy Shield List,

b. its commitment to the Principles of the Privacy Shield,

c. the types of personal data being processed,

d. the purposes for which it processes personal information about them,

e. how to contact the organization with any complaints,

f. the identity of third parties to which it discloses personal data, and its liability besides

the purposes,

g. the right of individuals to access their personal data,

h. the requirement to disclose personal information to public authorities due to lawful

requests,

i. the independent dispute resolution body, either in the EU or the U.S., where individuals

can bring their cases, and

j. the government agency in the U.S. that is responsible to investigate and enforce the

organization’s obligations under the framework

C.11. Organisations involved in use case implementation MUST inform the data subjects about their

rights and choices in relation to their personal data, and the consequences of exercising them

C.12. Organisations involved in use case implementation MUST describe any disclosure, access to or

transference of personal data presenting information about:

a. all the privacy stakeholders to which the data may be disclosed, and under which

circumstances this may happen

b. the types of external third parties with which personal data may be shared, and the purposes for which it is shared in each case

c. the natural persons that may have access to the data subject’s personal data, and under which circumstances this may happen.

d. the retention and disposal policies applied by the organization, and any legitimate rationale to retain the data beyond its initial purpose or the users consented time spam.

e. the controls the organization will implement in order to protect personal data C.13. Organisations involved in use case implementation MUST provide information about

processed personal data and its purpose by: a. providing the data subjects with an interface to swiftly identify which personal data is

processed and for what purposes it is used. b. informing data subjects whether personal data is processed, and in that case, what

personal data categories are processed, for what purposes, and to which recipients it is disclosed

c. informing the data subject about the disclosure of their personal data to third parties, so as to allow them to object to that.

d. informing the data subjects on their right to object to the processing of their personal data by the organization, and the potential consequences of exercising that right.

C.14. Organisations involving in use case implementation MUST keep the privacy policy updated and the data subjects informed of the latest version

Rights of the Individual

C.15. Organisations involved in use case implementation including NCPeHs MUST allow data subjects to exercise their right of access to their personal data stored


28

C.16. Organisations involved in use case implementation including NCPeHs MUST allow data subjects to exercise their right to object to their data being processed by the organization:

C.17. Organisations involved in use case implementation including NCPeHs MUST allow data subjects to exercise their right to withdraw given consent with effect for the future

C.18. Organisations involved in use case implementation including NCPeHs MUST allow data subjects to exercise their right to object to their data being shared with third parties

C.19. Organisations involved in use case implementation including NCPeHs MUST allow data subjects to exercise their right to correct, amend, erase, and block individual data from the personal data maintained about them in the organization records.

Information Security Identification

C.20. For each Actor (HP, Patient, PoC and NCPeH) a valid and unique electronic identity MUST be

established. The standards to which this is unique/valid MUST be established by agreement.

Authentication

C.21. The identity of Users (before each system access, transaction or message) MUST be validated.

C.22. Each Country MUST robustly grant the authentication of his own Users. The conditions on

which a Country may guarantee the User authentication, may be based on technical and/or

organizational measures. These measures, in any case, SHOULD provide that the authenticated

entity MUST not be repudiated.

C.23. Identification &Authentication (I&A) of each User at NCPeH and PoC systems MUST be

performed before he/she starts processing. The tool/mechanism used (individually or with other

security tools/mechanisms/procedures) for I&A MUST prevent the User’s identity (previously

submitted to I&A) from being repudiated.

C.24. Each NCPeH MUST ensure that all connections to remote servers (both other NCPeHs and local

systems) and applications are authenticated.

Digital Signatures

C.25. If in a Country piloting this use case, Users apply a digital signature, then the corresponding

NCPeH MUST be able to:

a. verify that the digital signature is valid (this implies that the user certificate is also valid)

b. confirm that validity to any other NCPeH, through a digital signature.

C.26. If a Country piloting this use case does not adopt a digital signature, then the corresponding

NCPeH MUST be able in any case to:

a. confirm to any other NCPeHs connecting, the data integrity of the exchanged data

through a digital signature.

Access Control

C.27. The confidentiality and integrity of PIs identified MUST be protected by preventing

unauthorised access and use. (protection from both the technical and organizational point of

view).

C.28. Local PoC systems MUST provide an Access Control tool/mechanism which enables access to

medical information on the basis of the User Identity and the role (and related authorizations)

he/she plays.


29

C.29. The authorization with which an identified and authenticated Health Care Professional can get

access to Patient Summary of a Patient MUST be based on the role assigned to the HP, on the

verification of the parent health-care Organization, on the fact that “that” HP is treating “that”

Patient.

C.30. A NCPeH MUST provide Access Control mechanisms, which provide functionalities that allow

for a given User, the specification of which data and services the User can get access to, and

which privileges the User has with regard to the data and services.

Confidentiality

C.31. The unauthorized disclosure of personal medical information during the transfer, processing

and storage MUST be strongly prevented. The use of cryptographic mechanisms SHOULD be

adopted.

C.32. NCPeH MUST use strong cryptographic mechanisms to prevent the unauthorized disclosure of

personal medical information or security critical system data during the transfer and processing

within the NCPeH itself, if this processing has confidentiality vulnerabilities.

System and Data Integrity

C.33. The integrity of data within the identified PI data (e.g. Patient Summary Document),

transactions or messages MUST be assured for both data rest and transit.

C.34. The source and destination of the message during data transmission between NCPeHs MUST

be protected to maintain its integrity.

C.35. A NCPeH MUST ensure, by strong cryptographic mechanisms, the ability to discover if the

medical information has been altered or destroyed in an unauthorized manner, so that that

medical information may not be further processed.

Availability

C.36. NCPeH best effort MUST ensure the respect of the agreed Service Level Agreements.

Non-Repudiation

C.37. A NCPeH MUST have a strong cryptographic mechanism (i.e. RSA) to ensure the non-

repudiation of each document produced by itself or messages exchanged with other NCPeHs.

Protecting Against Malware

C.38. Each IT-system involved in the use case implementation MUST implement, according to

ISO/IEC 27000, appropriate detection and prevention controls to protect against malicious

software (viruses, worms, etc).

Accountability

Accounting

C.39. It MUST be ensured that each activity of a User is accounted for. In any case accounting

information MUST not include personal health care data.

C.40. NCPeH MUST have a mechanism to record every access request and disclosure of medical

information and clinical data, together with the time and identity of the accessing User. Clinical


30

data MUST NOT be included in accounted data. Accounting records MUST be maintained as long

as the pilot project lasts, unless otherwise legally required.

C.41. Logging on the NCPeH SHOULD be operational at all times. In case of failure, the NCPeH

involved MUST inform all the other NCPeHs.

Auditing

C.42. It MUST be ensured that each action which has an impact on security or privacy must be

audited. In any case auditing information must not include personal health care data.

C.43. It MUST be ensured that each action which has an impact on security is recorded. If data to be

recorded contain both medical and personal data, an anonymization or pseudo-anonymization

process SHOULD be used if possible or reasonable. In any case the recorded data MUST not

contain personal health care data but can contain a unique identifier to a data object. Audit

records MUST be maintained as long as the pilot project lasts, unless otherwise legally required.

C.44. A NCPeH MUST secure the access to audit records to prevent misuse or compromise.

C.45. Secure audit record MUST be created each time a User asks to access medical information of

a Patient or to send an e-prescription dispensation’s notification.

C.46. The logs SHOULD contain:

a. the user ID of the accessing User;

b. the role the User is exercising;

c. the organisation of the accessing User (at least in those cases where an individual

accesses information on behalf of more than one organisation);

d. the unique Patient ID;

e. the function performed by the accessing User;

f. the NCPeH-id of the Originator/Target;

g. a time stamp including time zone used.

C.47. It SHOULD be possible to identify all requests to access to any Patient’s record(s) over a given

period of time according to different parameters (Users, Patients’ records,…).

Traceability

C.48. It MUST be ensured that log data can be connected from different sources in a privacy-

compliant way.

Fraud Detection

C.49. Tools SHOULD be provided to be able to discover possible frauds in the use of medical data.

C.50. NCPeH MUST provide tools to discover possible frauds in the use of medical data

Compliance

C.51. it SHOULD be allowed to submit each NCPeH to a security audit procedure performed by the

other Countries involved in the use case implementation, so that it will be possible to verify the

compliance with the security requirements established by the pilot sites agreement.

Data protection by design and default

C.52. Privacy safeguards MUST be integrated into the new systems to be developed for the

implementation of the use case including NCPeHs since their inception to

a. Safeguard personal data from any intentional or unintentional use or disclosure.


31

b. Safeguard personal data to limit incidental uses or disclosures made pursuant to an otherwise permitted or required use or disclosure.

C.53. Default settings MUST be restricting the data to be processed by default to only

personal data which are necessary for the specific purpose of the processing.

4.1.3. Recommended Security and Privacy Enhancing Technologies/Services (Step 3) In this section, we will present pointers to the recommended security and privacy enhancing technologies in

order to address the needs of the security controls identified in the previous section. In doing so, a brief

overview of these technologies will be provided by guiding the implementers to the respective references

where the full specifications of these technology and services are available.

Recommended Security and Privacy Enhancing Technologies/Services for addressing the needs of Consent

Recommended Security and Privacy Enhancing Technologies/Services for addressing the needs of Purpose

Binding

Privacy Criteria Addressed

Recommended Security and Privacy Enhancing Technologies/Services/Standards

C.2

eHealth DSI Security Service Specification provides the specification of an Access Control Security Service description (eHDSI, eHealth DSI Security Services Specification, 2017). It has been reported that in line with the eHealth DSI philosophy where the system must not require any changes to national health systems, each country must self-rule the policies according to the local legislation and each patient must be able to freely write the consent without any limitation introduced by the ACS technology suggested. However, it has been presented that each country is required to use XML language to describe the access policies. The OASIS extensible Access Control Markup Language (XACML) specification is a means to specify access control policy in a machine-readable XML format (OASIS XACML TC, 2017). XACML defines a policy exchange format, in order for systems to exchange or share authorization policies, even if the policies are translated into a proprietary or native policy language prior to the actual execution of the policy. The XACML specification including the detailed XACML flow has been presented as a reference standard in the eHealth DSI Security Service Specification as well (eHDSI, eHealth DSI Identity Management Specification, 2017).



C.3

eHealth DSI Security Service Specification provides an Access Control Security Service Specification with the aim of enforcing a policy given by the patient to access his Patient Summary within the scope of this use case. Please see below the Recommended Security and Privacy Enhancing Technologies/Services for addressing the needs of “Access Control (C.29-C.32)”.


32

Recommended Security and Privacy Enhancing Technologies/Services for addressing the needs of



Transparency and Openness



C.4-C.8

Within this use case, the minimum necessary information that needs to be included in a Patient summary has already been identified by definition. Here it is assumed that no patient data is being stored in NCPeH’s hence, storage anonymization and pseudonymization has not been covered here. Necessary measures need to be implemented to minimize the traces left by transactions and interactions in the audit logs being kept for ensuring accountability. For these measures please refer to the table presenting the “Recommended Security and Privacy Enhancing Technologies/Services for addressing the needs of Accountability” below. Finally, organizational principles need to be put in place to destroy all data objects created for the use case implementation.



C.9-C.14

C.9-C.12 and C.14 can be easily addressed by providing well-documented, public privacy notice to the data subjects along with the consent procedures existing in the participating organizations. On the other hand, addressing the requirements of C.13 necessitates implementing PETs to enhance transparency and to place users in a better position to understand what data about them are collected and how they are used. Existing eHealth DSI Security Service specifications does not directly address these needs. The ENISA Privacy and Data Protection by Design Report (ENISA, 2015) proposes a number of guidelines that can be taken into account while implementing transparency-enhancing techniques. It is proposed to pay specific attention to usability as well as accessibility and inclusion when designing transparency mechanisms and determining the ways to communicate information, as transparency aims at individuals’ understanding of data processing and related risks to provide a fair basis for informational self-determination. It is reminded that not all users are interested in all details of data processing, others would not be satisfied if they could only get high-level information. To address this, it is recommended to make available the information in multiple levels of detail, as needed by the individual. In addition to these, several existing example transparency enhancing techniques has been discussed in ENISA guidelines such as:

• privacy dashboards that presents the type of personal data collected, how they are used, to what parties they are made visible


33

Recommended Security and Privacy Enhancing Technologies/Services for addressing the needs of Rights

of the Individuals


Information Security

• tools that extract by themselves the privacy information rather than depending on the declarations of the service providers, such as browser add-ons that analyses the events occurring when a user visits a website and continuously updates a graph showing the tracking sites and their interactions

• Tools that rely on the effort of communities of peers (or experts) to evaluate privacy policies and track their evolution

ENISA also proposes the use of formal languages such as P3P, Privacy Bird, CI (Contextual Integrity), S4P and SIMPL to make it easier for service providers and users to express their privacy policies and privacy requirements. Declarations in these languages can be automatically translated into a machine-readable format. The privacy policy of a site can then be matched with the privacy requirements of the user and appropriate decisions taken (or information provided to the user) depending on the result of the matching. For details of these suggestions please see ENISA Report.



C.15-C19

In the ENISA Privacy and Data Protection by Design Report (ENISA, 2015) provides measures which enables online access to personal data and possibilities to exercise data subject rights such as withdrawing consent or requesting rectification, blocking and erasure of personal data are named as “Intervenability Enhancing PETS”. It has been reported that such intervenability techniques can often not be implemented solely on a technical level; instead, organizational, societal processes and in particular the juridical systems shall contribute to effective intervenability.

As an example the Data Track tool, which is realized in PRIME and PrimeLife projects and further developed in the project A4Cloud is presented which provides users online functionality for accessing their personal data and helps them with requests concerning rectification and erasure (Simone Fischer-Hübner J. S.-s., 2007) (Simone Fischer-Hübner J. A., 2014).



Identification (C.20) & Authentication (C.21, C.22, C.23, C24

Based on eHDSI Identity Management Service Specification description (eHDSI, eHealth DSI Identity Management Specification, 2017), in the operationalization of the unplanned care scenario, the identity of a patient will always have to be proven (validated) in his country of affiliation, even if this process is initiated abroad in Country B. The identification of the Healthcare Professional will always happen in the country of his registration, most likely by referring to a HP-Registry/Repository (Database). The authentication is the process of establishing an acceptable level of assurance that a claimed identity of an entity is genuine. Various services and components of the eHealth DSI environment aiming to operationalize this use case requires univocal,


34

unambiguous identification and/or reliable authentication of patients and HPs; however, the identification/authentication needs to be initiated in systems belonging to the national e-health infrastructures, which are not under direct control of the eHealth DSI environment. Since the results of identification/authentication are crucial for operationalization of this use case, the eHDSI Identity management service specification has (1) identified the cases, where identification and authentication are required on both, the national (local or national systems in the national e-Health domain) and the international (in the eHealth DSI environment) levels (2) assembled the information on identification/authentication solutions used in different country and (3) identified the restrictions, legal requirements and other relevant factors influencing the use of identification/authentication solutions in country. Implementers of this use case should carefully examine this analysis (eHDSI, eHealth DSI Identity Management Specification, 2017). According to architecture defined in eHDSI, an Identity Provider is grouped with each NCPeH and issues a profiled Identity Assertion. The OpenNCP implementation of epSOS architecture, includes an Identification Service which provides integration points for obtaining the patient identity information provided by the National Infrastructures (eHDSI, eHealth DSI OpenNCP Implementation, 2017). Apart from HP and Patients I&A, there are two more classes of active entities to be identified and to be authenticated: NCPeH and NCPeH users (Technical Staff and Data Security Officer). The former, NCPeH I&A in an NCPeH to NCPeH communication (see Figure 2), is a common matter of a chosen secure protocol (TLS or SSL), the latter (NCPeH users I&A), is a common utility usually provided by an operating system or data base (eHDSI, eHealth DSI Security Services Specification, 2017). In parallel with this, the CEF eID building block has at its core the eIDAS Regulation (EU 910/2014, 2014), one of the key foundations in the area of cross-border electronic identification. The eIDAS Regulation provides the legal framework for the cross-border recognition of eID means and trust services, ensuring their interoperability and legal certainty. With eIDAS, the European Union has laid the foundations for citizens, businesses (in particular SMEs) and public administrations to access and use on-line services in a more reliable, responsible and convenient manner. The eIDAS Regulation establishes the principle of mutual recognition, whereby any public service provided online that makes use of electronic identification for users to access the service must recognise national eID schemes from other Member States to provide foreign EU citizens access to the service with their own national eID. Given that practically in all Member States there are online public services that require the use of an eID, it is expected that all Member States would make their national eID schemes interoperable across borders as this will be mandatory by September 2018. To enable such mutual recognition the Member States, in coordination with the Commission, have defined an interoperability framework for the implementation of the cross-border authentication including common eIDAS Technical Specifications (eIDAS eID Profile Technical Specification, 2016). The CEF eID building block DSI also provides the sample software that Member States can reuse in order to establish the interconnection of their national eID schemes and providers of online services (public and/or private) through the setup of a national eIDAS Node (eIDAS-Node integration package).


35

Commission issued a draft report by Deloitte on assessing potential use and suitability and sustainability of the CEF eID building block solution for cross-border authentication, in line with the eIDAS Regulation, in the context of the two eHealth DSI use cases for Patient Summary and ePrescription/eDispensation (Deloitte, 2016). As a conclusion it is presented that:

• The use of eID under eIDAS implies that the relevant information required for the identification of patients can be provided through the eIDAS Network and that for the eHealth use cases one can rely on the authenticity of the information provided (at a minimum the information provided through the minimal dataset);

• The use of cross-border authentication through the eIDAS Network based on the national implementation of eIDAS Node in line with the CEF eID building block therefore provides a reliable, responsible and convenient manner for online-services to identify their users.

The study looked at the overall eHealth solution architecture, going in more depth for six Member States (Austria, Finland, Italy, Luxembourg, Portugal and Sweden), limiting to ePrescription and Patient Summary use case, and three scenarios have been identified for the practical implementation of the use of eID under eIDAS for eHealth:

• Scenario 1: Use of national eID scheme, notified under eIDAS, with unique identifier as part of the eIDAS minimal dataset that is used as the patient identification number for eHealth use cases;

• Scenario 2: Use of national eID scheme, notified under eIDAS, with unique identifier as part of the eIDAS minimal dataset that is not used as the patient identification number for eHealth use cases and using the extended sector specific dataset to include the patient identifier;

• Scenario 3: Use of national sector specific eHealth eID scheme, notified under eIDAS, with sector specific patient identification number for eHealth use cases.

The identified scenarios aim to help Member States to define their approach to the implementation of the use eID in eHealth, by understanding their specific situation. The scenarios also aim to help Member States to identify the next steps they would need to take in order to deploy the relevant scenario. Based on this assessment, the following recommendations have been made (eHealth Member State Expert Group (eHMSEG), 2017):

• For Member States: o Assess their specific national situation with regard to the

implementation of the eHealth use cases as well as notification of national eID schemes under eIDAS

o Identify the relevant scenario that applies to the specific situation o Identify next steps required to deploy the use of eID in eHealth o Assess their legal conditions to share the patient unique identifiers

across borders

• For the eHealth Network: o Assess and foster an agreement between MS on the use of a sector-

specific dataset under eIDAS (incl. information and its format) to enable the exchange of relevant patient identity attributes across borders


36

o Assess the need for a common agreement between MS on the required levels of security/assurance in relation to the identification of patients

The study currently continues as Phase II, as an extension of the analysis to the 22 other MS, including deeper analysis of 10 MS. Finally, as a part of FHIR security guidelines (HL7 FHIR Release 3, 2017), OAuth and

OpenID Connect is recommended to be used to authenticate and/or authorize the users. The Smart-On-FHIR profile on OAuth (SMART Health IT 2017) is tightly integrated with FHIR and is the recommended by FHIR specifications. In addition to these, FHIR specifications points out the HEART Working Group (HEART WG, 2017), which has developed a set of privacy and security specifications that enable an individual to control the authorization of access to RESTful health-related data sharing APIs, and to facilitate the development of interoperable implementations of these specifications by others.

Digital Signatures (C.25, C.26)

eHealth DSI Security Service Specification provides a Public Key Infrastructure (PKI) Security Service to supply certificates and validation services that will be used to ensure the confidentiality and the integrity of the services of Patient Summary use case (eHDSI, eHealth DSI Security Services Specification, 2017).

Access Control (C.28-C.30)

eHealth DSI Security Service Specification provides an Access Control Security Service Specification with the aim of enforcing a policy given by the patient to access his Patient Summary within the scope of this use case. This specification assesses the pros and cons of several different Access Control formalisms including Discretionary Access Control (DAC), Mandatory Access Control (MAC), Role Based Access Control (RBAC), Attribute Based Access Control (ABAC) and Policy Based Access Control (PBAC), and Context aware Access Control, and proposes to use a Policy-Based Access Control (PBAC) mechanism for the decisions which are not only based on the roles, but also on attributes (e.g. “Purpose of use”, “Locality”) and additional modified restrictions following from patient consent. The OASIS extensible Access Control Markup Language (XACML) is proposed as a policy exchange format (policy format, a request format and a policy decision format), and an XACML based access control flow to exchange access control requests and response messages. Both messages SHALL contain the identity of the HP and the identity of the Patient, according to the SAML Profile provided by eHDSI (eHDSI, eHealth DSI SAML Profile, 2017). Such an identity is encoded as SAML authentication assertion containing all the attributes defined by the SAML Profile. Details of the flow can be found in (eHDSI, eHealth DSI Security Services Specification, 2017). The existing OpenNCP implementation of the eHealth DSI Policy manager compliant with the eHealth DSI specifications regarding the use of SAML but does not implement the full XACML data flow described in eHealth DSI Security Services Specification (eHDSI, eHealth DSI OpenNCP Implementation, 2017). However, it provides an integration point in the form of a standard Java interface that the participating countries can implement. FHIR Security guidelines presents recommendations about how Role-Based Access Control (RBAC), and Attribute-Based Access Control (ABAC) mechanisms can be implemented in FHIR RESTful interactions (HL7 FHIR Release 3, 2017).


37

SMART App Authorization Guide (SMART Health IT 2017), provides guidelines to be used by developers of applications that need to access FHIR resources by requesting access tokens from OAuth 2.0 compliant authorization servers, which might be utilized by the implementers of Trillium II pilots accessing International Patient Summaries as FHIR resources.

Confidentiality (C.31-C.32)

Confidentiality is one of the foundational concepts of information security. The meaning of confidentiality is defined in the ISO-27002 specification as "ensuring that information is accessible only to those authorized to have access". Confidentiality can be achieved using different mechanisms, such as access control techniques, encryption and anonymization. Regarding the confidentiality of data being exchanged, the eHealth DSI Security Service Specification presents a detailed analysis of the trust zones within eHealth DSI architecture and assesses different options to enable end-to-end security based on the requirements of different trust zones. Please see eHDSI Security Service Specification for the detailed descriptions of these Trust Zones (eHDSI, eHealth DSI Security Services Specification, 2017).

Figure 3 eHealth DSI Trust Zones

In summary, the following widely adopted mechanisms have been analysed and compared based on the requirements of exchanging Patient Summaries within eHDSI architecture:

- IPsec (Layer 3) - Transport Layer Security (SSL/TLS) (Layer 4+) - SOAP Message Security / Web Service Security (Layer 7) - Application Based Security (Layer 7)

Taking into account that end-to-end node communication at country level, due to public network interfaces, must in every case be protected by TLS/SSL protocol, and under the constraints that in each country domain communication between Trust Zone I and Trust Zone II should be protected by dedicated VPN, two possible solutions are analyzed also considering operational and economic factors.

• Option A: WS-*enc/sig +TLs

• Option B: WS-*sig +TLS+VPN As a result, it has been concluded that both options “A” and “B” guarantee an adequate level of protection and recommended to use TLS 1.0 using SHA-1 algorithm. For the details, please see eHDSI Security Service Specification (eHDSI, eHealth DSI Security Services Specification, 2017).


38

Yet, these guidelines provided by eHDSI for ensuring the confidentiality of data being exchanged is valid for a WS based protocol (SOAP) to exchange patient summaries. In the case of International patient summaries represented as FHIR resources being exchanged via RESTful APIs, FHIR specifications recommends following HTTP security rules (W3C Hypertext Transfer Protocol -- HTTP/1.1, 2016). It is recommended to use TLS/SSL for all production data exchange. The TLS/SSL communications are established prior to any HTTP command/response, so the whole FHIR interaction is protected by the SSL/TLS communications (HL7 FHIR Release 3, 2017). In ENISA Privacy and Data Protection by Design Report (ENISA, 2015), additional measures on top of TLS are proposed in order to minimise the potential for keys to be compromised. It is highlighted that it is important to rotate keys regularly, therefore minimising the exposure of private data in case of a key compromise. Modern cryptographic systems, including some configurations of TLS (using the DH or ECDH cipher suites) provide forward secrecy, a property that guarantees the use of fresh keys for each communication session and discarding of key upon session termination. Forward secrecy guarantees that after a communication session is over, the secret key material cannot be recovered, and therefore no amount of coercion can render the encrypted material intelligible. The provision of such automatic key rotation schemes should be considered.

System and Data Integrity (C.33-C.34)

The eHealth DSI Security Service Specification provides a Data Integrity Security Service specification to provide eHealth DSI-NCPeH with a method that can find out if any unauthorized change to health data was applied. Specification (eHDSI, eHealth DSI Security Services Specification, 2017). By carrying out a high level risk analysis, and assessing the possible implementable measures for integrity (namely Use of digital signatures, signed checksum via PKI, signed checksum via a symmetric key), the eHealth DSI Security Service Specification proposes to use digital signatures for ensuring integrity. As digital signatures are used to implement non-repudiation aspects of communication between NCPeHs, these signatures can also facilitate data integrity of the messages. It is proposed to use a hash function to compute the unique small digest value, before the signature is actually computed. This digest value can provide an automatic way to protect the integrity of the message. To calculate the message digest, it is proposed to use SHA-1 or SHA-2, and the key length should be no less than 1024 bit. FHIR Security specifications (HL7 FHIR Release 3, 2017) recommends the use of W3C Digital Signatures for signatures. FHIR Resources can be signed using the Provenance resource to carry a detached digital signature.

Availability (C.36)

In eHealth DSI Security Service Specification, it is presented that in the eHealth DSI wave 1, a real threat due to a voluntary attack is not foreseen, moreover it is considered that:

• Health data availability must have no impact on Patients health treatment. (Health data availability makes the treatment based on a better foundation).

• Denial of Service (DoS) on communication is a common matter of secure protocol and networking architecture.

For these reasons the security services do not detail any Disaster Recovery Plan nor


39


Accountability

describes any fault tolerance platform. (eHDSI, eHealth DSI Security Services Specification, 2017).

Non-Repudiation (C.37)

The eHealth DSI Security Service Specification provides a Non-Repudiation Security Service specification to provide a mechanism for the countries to be able to prevent parties from claiming not to have requested certain information. Different options to implement the non-repudiation service have been analysed including the use of digital signatures, message authentication codes, and use of a eHealth DSI notary. As a result of the analysis it has been concluded that option 1 (digital signatures via existing PKIs) is the best option to implement non-repudiation of origin. As the implementation mechanism XML signature standard is proposed. For the details, please see eHDSI Security Service Specification (eHDSI, eHealth DSI Security Services Specification, 2017). FHIR Security specifications (HL7 FHIR Release 3, 2017) recommends the use of W3C Digital Signatures for signatures. FHIR Resources can be signed using the Provenance resource to carry a detached digital signature. The Signature datatype is available to support various signature types including non-repudiation purposes.

Protecting Against Malware (C.38)

Protection of information systems against malicious code can be achieved by means of dedicated software often referred to as “anti-virus software” (also "anti-malware" or "virus protection software").



Accounting (C.39-C.41) & Auditing (C.42-C.47) Traceability (C.48) Fraud Detection (C.49-C.50)

The eHealth DSI Security Service Specification provides an Audit and Accounting security service to provide a history of transactions and to ensure that it is possible to trace who has performed any action involving a eHealth DSI- NCPeH transaction. After a detailed analysis of the risks, the following requirements have been set:

- the audit systems (Log data server) must be segregated from the audited system (eHealth DSI-NCPeH) itself;

- the eHealth DSI-NCPeH has to be provided with an agent which sends audit data in real time to a secured Log data server;

- Log data format will follow indications in RFC3881 (Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications);

- the secured Log data server may store received data and relative hash or digital signature on a worm (Write Once Read Many) device, or equivalent method, to prevent offline tampering and deleting;

- the system administrators and the HPs must be distinct people with no hierarchical relationship between them;

- On the Log data server, a statistical analysis via business intelligence or data mining products, of the Logged data has to be provided in order to allow early discovery of any misused or fraudulent use of eHealth DSI. (Using commercially available products, to be customized, such as Oracle Data Mining or Business Objects).

The data to be logged for are listed as HP Authentication, Patient Identification /


40

Authentication and consent, HP Authorization transactions. For this, it is recommended to follow the eHDSI Identity Management Service Specification (eHDSI, eHealth DSI Identity Management Specification, 2017). The transactions to be logged for are listed as Medical data Query and Retrieve transactions. The data to be logged for System and network infrastructure events are listed as: NCPeH / Security Service start-up/shut down; Usage of secure Audit log (other than audit log record creation); Access policy change (i.e. Network, file system); User account event (i.e. Create account); Configuration changes; Partial failure; PKI event; Timing synchronization; Authentication (NCPeH, Technical Staff) failure and success. Every data Logged Must in every case be compliant with the following requirements:

- For every transaction, stored information may include information contained both in the request and in the response.

- For every record created by the Audit system, a timestamp of date and time must be recorded from time services, which ensures synchronization between different countries.

- HP and Patient IDs are not immediately associable with the personal information of their owners because this kind of information is not stored on the secure audit system. Should any information stored in the audit system lead to patient identification, such information MUST be kept in separated tables from the ones containing the IDs identifying transactions and operations.

- The purpose of the audit system is not to store healthcare-related data within the transactions, which is why this type of data should not be stored in any way on the systems.

- However, since the system may be able to provide evidence that a transaction has been requested or not, a cryptographic function (i.e. hash or the encryption in a way that the decrypting key should not be under the direct control of the NCPeH) of the health/health-related transmitted data may be stored.

- The data Log MUST NOT be used for different purposes than: o to analyse or to prevent a breach of security; o to respond to the right request of the data subject (patient) or to

“National entities” legally authorized, with the aim of providing the evidence necessary to the case.

- Finally, to ensure that logs would not be tampered with, a sign mechanism to sign every log record may be adopted. On top of this a sign mechanism of the whole daily list of log entries can be put in place in order to ensure integrity of the entire dataset.

The system devoted to audit collection must guarantee a high degree of security itself, both from the data transmission and data storing point of view. In other words, a tamper-proof system has to be designed. In order to design such a system, the specifications must satisfy the following technical requirements.

1. the PHYSICAL system(s) hosting the audit collection processes and the audit data (logs) must be physically protected (closed environment, access control);

2. the MACHINE(s) hosting the audit collection processes and the audit data (logs) must be UNACCESSIBLE by Technical staff users;

3. users allowed/entitled to access the audit system will ONLY have the right to access in READING the logs, without having access to other system functions;


41

Recommended Security and Privacy Enhancing Technologies/Services for addressing the needs of Data

Protection by design and by default

4. audit data (logs) must be stored on non-modifiable supports (WORM) or equivalent method;

5. communication between eHealth DSI-NCPeH and the Audit trails secure storage should be secured and both systems should also authenticate each other's.

It is recommended to implement the IHE ATNA (Audit Trail and Node Authentication contained in IHE IT Infrastructure (ITI) Technical Framework Volume 1 (ITI TF-1) Integration Profiles Revision 5.0 and RFC3881 (Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications). ATNA proposes two possible solutions as Audit record transportation between eHealth DSI NCPeH and the data Log server: -Transmission of syslog message (Log record) over TLS (RFC5425) with the syslog protocol (RFC5424). -Transmission of syslog message (Log record) over UDP (RFC5426) with the syslog protocol (RFC5424). eHDSI Security Service Specification suggests the adoption of UDP protocol by implementing a read after write strategy and adopting a dedicated point to point connection between eHealth DSI-NCPeH and the data Log server. For the details, please see eHDSI Security Service Specification (eHDSI, eHealth DSI Security Services Specification, 2017). FHIR provides an AuditEvent resource suitable for use by FHIR clients and servers to record when a security or privacy relevant event has occurred (HL7 FHIR Release 3, 2017). The AuditEvent Resource specifications have already been defined based on IHE ATNA specifications, and hence ATNA log events can be automatically converted to AuditEvent resources.

Compliance (C.51)

In compliance with the provisions of the eHealth DSI Security Policy, an eHealth DSI security audit procedure is required to be implemented by each national NCPeH the provisions of which is defined in eHealth DSI Audit Framework (eHealth DSI, 2018). The eHealth DSI security audit policy and procedure have the following major characteristics:

• It is based on eHealth DSI Security Policy and the ISO27002 standard requirements.

• The eHealth DSI security audit policy underlines confidentiality and integrity needs more than availability needs.

• The audit needs to include an assessment of compliance to national legislation.

• The eHealth DSI security audit procedure is conducted by national auditors, using ISO based procedures.



C.52-C.53

These requirements listed in C.52 and C.53 can be addressed by implementing the “Minimize”, “Hide”, “Separate”, “Enforce” and “Demonstrate” design strategies

pointed out by ENISA Privacy and Data Protection by Design Report (ENISA, 2015). Design Patterns (mapping to PETs) that can be utilized to implement these strategies


42

4.2. Exchanging Patient summaries for enabling continuity of care for chronic disease patients

4.2.1. Use Case Description (Step 1) This use case is described in C3-Cloud (A Federated Collaborative Care Cure Cloud Architecture for Addressing

the Needs of Multi-morbidity and Managing Poly-pharmacy) H2020 Research and Innovation project. It is

about a patient with a chronic disease being followed by an integrated care platform which is used by

multidisciplinary care providers. The integrated care platform accesses patient summary of the patient from

a central entity in the Country of affiliation. The access to patient summary from this integrated care platform

is both within the country of origin, by different care providers to have access to the most recent medical

context of the patient, and also from another country while the patient is being cared for an acute problem

while visiting his child living abroad.

Title Patient summaries Continuity of care per chronic patients

Purpose Accessing and presenting the Patient Summary of the patient in Country A (the

patient’s country of affiliation) to all care providers (GPs, specialists, social care

givers) having an encounter with the patient in Country A, and also to a physician

in Country B for the management of his existing chronic condition or acute

conditions during a visit to Country B.

Relevance All of the healthcare and social care providers involved in the management of the

chronic conditions of the patient have the same most recent medical context of

the patient in Country A. This is also valid for the healthcare providers in Country

B, who needs to manage acute conditions of the patients suffering with chronic

conditions. This is very valuable and essential to detect and avoid drug-drug, drug-

disease, disease-drug interactions, polypharmacy problems, and also duplicate

and clashing treatment options for chronic disease patients.


Scale Cross-border

Context An elderly patient suffering from diabetes visits his GP, and the specialists such as

nephrologists, dietitian, ophthalmologist regularly for yearly control visits or upon

referral by his GP as a part of his care plan. At these visits, all parties involved in

the care of the patient will have the same view of patient summary. When the

patient is being supported by social care workers visiting elderly, they will also

have the chance to access his most recent treatment plan including his active

medications and allergies via his patient summary.

When the patient suffers from a severe cold during his visit to his son and

grandchildren in abroad, he must be hospitalized for risk of pneumonia. His

existing treatments, including treatment goals and medications are seen by the

healthcare professionals treating his acute conditions, and his mediations have

been adjusted accordingly.

Information - Patient Summary: Problems, medications, allergies, procedures, lab results,

and if available care plans. Existence of care plans for the management of

(see Section 7.1.3) have already been covered in the above tables such as “minimization of personal data being collected”, “ encryption of data (when in transit)”, “access control, log and auditing” mechanisms.


43

chronic conditions in the patient summary may give an idea about the current

ongoing treatment goals set for the chronic patients and the related activities

to all healthcare providers involved in the treatment of patients.

- Patient Consent


Health professionals in patient’s country of origin (country A) Health professionals in country visited (country B)

Functional process

steps

Scenario A (Access with a country):

• The patient consults a health professional (e.g. a Neurologist) in country A for the management of the complications related with his diabetes conditions such as neuropathy.



• The patient may have given consent to all of the health professionals in his care team to access his patient summary. (This might be handled while his GP refers him to a Neurologist).

• The Patient Summary is electronically accessed by the Integrated Care Platform (Point of Care system) from the National Contact Point of Health (NCPeH) in a secure way

• The health professional visualized the Patient Summary together with the existing care plan and uses it for the consultation.

• The integrated Care Platform uses this Patient Summary to process it and to suggest personalized goals and interventions (such as medications, life style advices) semi-automatically to the health professional, by avoiding clashes with his existing medications, and interactions with his existing co-morbid conditions.

Scenario B (Access from another country):

• The patient being treated for Diabetes in Country A, visits a health professional in country B for an acute problem.



• The patient may have given consent before travelling to country B or in country B to the health professional (except for emergency cases)

• In the latter case, the health professional will then register this confirmation

• The Patient Summary is electronically transferred from the NCPeH of the patient’s country of origin to the health professional in the country that s/he is visiting (the “visiting country”) in a secure way.

• The health professional visualized the Patient Summary together with the existing care plan and uses it for the consultation.

• The health professional decides on the treatment plan for the acute condition by avoiding clashes with his existing medications, and interactions with his existing co-morbid conditions.


44




In this section, we will outline the participants, systems, domains and responsibilities.

In this use case, patient’s home country is referred to as country 'A', and the country, where the patient gets

medical treatment during his visit, is referred to as country 'B':

• Country A is the country of affiliation (CoA), this means that Country A is legally the exclusive entity, which is responsible for appropriately storing, archiving and documenting any required health information of a patient within its existing national infrastructure. The patient is being cured by a number of multidisciplinary Health Professionals (HPs) using the Integrated Care Platform (ICP) in Country A related with his chronic condition.

• Country B is the country where the point of care (PoC) is located that provides healthcare to a patient from country A. It is assumed that the Health Professional (HP) that treat the patient can only be unequivocally authenticated by the competent authorities of country B.

The PoC could be a hospital, an individual practitioner or any other point of the health care system of any country. Each country is represented by a “National Contact Point (NCPeH)” creating a Circle of Trust” (CoT) that enables inbound and outbound communication cross borders. It is assumed that within each country, through the agreements between PoCs and NCPeH a national Circles of Trust is created, which leads up to building cascaded circles of trust. In the light of these descriptions and OAISIS PMRM guidelines, the Domains identified are Country A and Country B as different policies may apply especially for the interactions between PoCs, ICP and NCPeHs (i.e. HIPAA in U.S., EU GDPR within EU countries). Yet as described in section 3, for the interactions between the NCPeHs of Country A and Country B, either EU-US Privacy Shield (when cross border exchange between an EU member state and U.S. is targeted) or directly GDPR (when cross border exchange between an EU member states) would apply. To cover these, we will follow the principles set in Section 3 covering the needs of these. The Systems identified are PoC, ICP and NCPeH gateways. The Actors identified (also by eHDSI Glossary) are:


• Healthcare Professional (HP): A doctor of medicine involved in the care of a Patient. Furthermore, a HP must be under national law or rules established by national competent authorities to the obligation of professional secrecy or by another person also subject to an equivalent obligation of secrecy.

• National Contact Point (NCPeH): A legal entity representing a country involved in this use case, assuming legal duties towards participating countries and its own network of national gateways: it acts in a bidirectional way transmitting in-outbound messages between national IT infrastructures and NCPeHs from other countries). A NCPeH processes medical data to achieve interoperability.



system locally within a participating country


45

o System operators.


Based on the Functional Process Steps presented in the Use Case description, two high-level interaction diagram have been prepared to analyze the data flow, as presented in Figure 4 and Figure 5.

Figure 4 Overview of the Data Flow diagram for Scenario A for Continuity of Care(Access with a country)

Figure 5Overview of the Data Flow diagram for Scenario B for Continuity of Care (Access from another country)


different systems identified in the domains are highlighted for an easy identification of the touchpoints.


46

Table 2 Multi-Level Data Flows Matrix of Continuity of Care Scenario


PoC A NCPeH A ICP PoC B NCPeH B


PoC A -Patient Consent -Patient Summary

NCPeH A

-Patient Summary (including care plan)

-Document Metadata -Patient Summary (including care plan)

ICP -Patient Identity Claim -HP Identity Claim -Patient Summary Query


PoC B -Patient Identity Claim -HP Identity Claim - CP Identity Claim -Patient Summary Query

NCPeH B

-Patient Identity Claim -HP Identity Claim - CP Identity Claim -Patient Summary Query

-Document Metadata -Patient Summary (including care plan)



• Healthcare-related Data: Healthcare Data of a Patient Summary (including care plan) used for the medical treatment of a patient. Both according to EU regulations and HIPAA, the processing of these medical data has to satisfy higher privacy requirements. Healthcare related data contain also:

o data about the Patient Consent; o log data which provide information about the access to healthcare related data

• Critical Meta Data: Data needed to control the exchange of healthcare related data between NCPeHs and between NCPeHs and PoCs, respectively. Critical Meta Data include authentication, identification and administrative data to clearly identify patients, PoCs, HPs and CPs.





47


When we compare the data flow matrix identified at step 2.1 with the data flow matrix of the unplanned

care scenario presented in section 4.1, it is apparent that, all the data flows covered in unplanned care

scenario already repeats here. As a result, the privacy controls identified in Step 2.3 of the analysis of

unplanned care scenario are also valid for this use case. In order to avoid redundancy, these will not be

repeated here in this section.

The differences are due to the newly added Integrated Care Platform (ICP) system added to the scenario.

Scenario B is almost identical with the data flow analysed for unplanned care, apart from the fact that, the

Patient summary being shared may include additional Care Plan related data. In Scenario A, Healthcare

Professionals involved in the chronic disease management care team accesses patient summary data created

by the PoC’s within Country A over the ICP. In addition to this, in the end of the episode with the patient the

care plan is updated, and this is also registered to the NCPeH as an additional source for Patient Summary.

ICP processes the patient summary received to provide semi-automatic clinical decision support services to

Healthcare Professionals. In this scenario setup, two additional requirements emerge: (1) ICP may need to

store the patient summary in its own repository which may create additional security and privacy risks (2) a

single sign-on mechanism between the routine PoC systems used by the Healthcare Professionals and the

new ICP systems needs to be ensured. These are highlighted in the additional requirements listed below.

Consent

C.54. It MUST be ensured to obtain patient consent (direct or derived based on legal basis) in

country A allowing his Patient Summary in Country A can be accessed by different Health Care

Professionals in Country A who are involved in his care team for treatment purposes.


C.55. If storage is performed, the systems involved MUST minimise the data to be stored and keep

that are strictly required for the selected and consented purposes, protect medical information

or security critical system data it contains. The use of pseudoanonymization mechanisms

SHOULD be used if possible or reasonable.

C.56. If data is to be stored in ICP, ICP MUST reliably separate personal data on the same device which belongs to different issuers or owners.

Information Security Authentication

C.57. Identification &Authentication (I&A) of each User at NCPeH, ICP and PoC systems MUST be

performed before he/she starts processing. The tool/mechanism used (individually or with other

security tools/mechanisms/procedures) for I&A MUST prevent the User’s identity (previously

submitted to I&A) from being repudiated.

Access Control

C.58. ICP MUST provide an Access Control tool/mechanism which enables access to medical

information on the basis of the User Identity and the role (and related authorizations) he/she

plays.


48

Confidentiality

C.59. ICP MUST use strong cryptographic mechanisms to prevent the unauthorized disclosure of

personal medical information or security critical system data during the transfer and processing

within the ICP itself, if this processing has confidentiality vulnerabilities.

C.60. If storage is performed, ICP MUST protect medical information or security critical system data

it contains. The use of pseudonymization mechanisms SHOULD be used if possible or reasonable.

4.2.3. Recommended Security and Privacy Enhancing Technologies/Services (Step 3) In this section, we will present pointers to the recommended security and privacy enhancing technologies in

order to address the needs of the security controls identified in the previous section. As the privacy controls

identified for unplanned care are also valid for this use case, the required security and privacy enhancing

technologies to address the needs of these controls are not being repeated here in this section. Interested

readers should first of all carefully examine Section 4.1.3. In this section, only the additional PETs that can be

employed to address the needs of the additional criteria identified in the previous section will be presented.

Recommended Security and Privacy Enhancing Technologies/Services for addressing the needs of Consent





C.54

In this scenario, only the scope of the consent will be broader than the consent being discussed in ‘unplanned care’ scenario, to also cover the access of multidisciplinary care team members to the patient summary over the ICP during chronic disease management. Please see the PETs related with Access Control which have already discussed in Section 4.1.3.



C.55, C.55

As defined in the “Recommended Security and Privacy Enhancing Technologies/Services for addressing the needs of Confidentiality” section below, if patient data is stored in ICP, the ICP MUST protect medical information via the necessary encryption means. Where possible pseudoanonymization mechanisms shall be utilized as described. Finally, organizational principles need to be put in place to destroy all data objects created for the use case implementation.


49




Authentication C.57

In addition to the PETs related with Identification and Authentication which have already discussed in Section 4.1.3, within the scope of this scenario, Single Sign-On mechanism can be used to authenticate the HPs in ICP who have been already authenticated in their routinely used PoC systems. For implementing the mechanism, (Open ID Connect, 2018) and (OAuth 2.0, 2018) technologies can be utilized. gle Sign-On mechanism can be used to authenticate the HPs and Care Providers. For implementing the mechanism, (Open ID Connect, 2018) and (OAuth 2.0, 2018) technologies can be utilized. Single Sign-On mechanism can be used to authenticate the HPs and Care Providers. For implementing the mechanism, (Open ID Connect, 2018) and (OAuth 2.0, 2018) technologies can be utilized.

Access Control (C.58)

Please see the PETs related with Access Control which have already discussed in Section 4.1.3.

Confidentiality (C.59-C.60)

Confidentiality is one of the foundational concepts of information security. The meaning of confidentiality is defined in the ISO-27002 specification as "ensuring that information is accessible only to those authorized to have access". Confidentiality can be achieved using different mechanisms, such as access control techniques, encryption and anonymization. The eHealth DSI Security Service Specification provides a Confidentiality Security service which aims to provide confidentiality for data stored in persistent memory (e.g. hard-disks, tapes) for a (un)limited amount of time. eHDSI Security Servicer specification suggests alternative encryption mechanisms such as symmetric encryption, asymmetric encryption and as a result of the risk assessment study it proposes the AES algorithm with a key of 128/192/256 bits which is strong enough to provide sufficient security, unless a key is being compromised (i.e. discovered). Use of XML encryption is also suggested as an alternative means to achieve strong encryption and low computational cost: it is recommended to forge a new AES key for each file and use it to encrypt. Then use the private key of the eHealth DSI-NCP provided by the eHealth DSI PKI security service to encrypt the AES generated key, in an XML structure defined as the XML-ENC W3C recommendation. Yet, this alternative is discouraged because the method it is not yet wider adopted. For the details, please see eHDSI Security Service Specification (eHDSI, eHealth DSI Security Services Specification, 2017). Use of pseudonymization is recommended in case the involved systems has the role and mandate to store the clinical data (either temporarily or permanently). Separation of clinical data from personal (or other) data for storing purposes and their recoupling at the moment of need / authorised request is recommended. For the details, please see eHDSI Security Service Specification (eHDSI, eHealth DSI Security Services Specification, 2017). The ENISA Privacy and Data Protection by Design Report (ENISA, 2015) proposes a number of alternative PETs for ensuring privacy in databases, including several statistical disclosure control methods such as k-Anonymity, generalisation and microaggregation, Non-perturbative masking, l-Diversity and t-Closeness. In addition


50

4.3. Emergency and Disaster Management – Evacuation camp and Field Hospital

4.3.1. Use Case Description (Step 1) This use case is about to capture the summary information of a disaster patient (who may be a tourist badly

injured in a disaster that happed in another country he visited). The patient summary data stored in national

systems will be accessed by the Healthcare Providers in European Civil Protection modules of Field Hospital

and evacuation camps.

Title Emergency and Disaster Management – Evacuation camp and Field Hospital

Purpose Accessing and presenting the Patient Summary of the patient in Country A (the

patient’s country of affiliation) to the healthcare providers (Healthcare providers

in European Civil Protection modules of Field Hospital and evacuation camps) in

Country B (country of treatment) where a disaster happened.

Relevance Consider a large-scale disaster – like an earthquake, a flood or a CBRN disaster.

People are injured, misplaced, confused and in pain. Among them vulnerable

groups like children or elderly. Some of the patients can be tourists or foreigners.

The most recent medical context of these patients in Country A should be

available to the care providers in Country B. This is very valuable and essential to

detect and avoid drug-drug, drug-disease, disease-drug interactions and

polypharmacy problems for the patients during their treatment in the field

hospitals and evacuation camps.


Scale Cross-border

Context After a disaster in Country B, in the evacuation camp, a young patient is admitted

with moderate haemorrhage in his leg and with extreme shortness of breath;

therefore, the patient can only provide limited information to the care providers.

The care providers can reach the passport (or identity card) of the patient and

retrieve the Patient Summary (Problem List, Active Medication Allergy List and

to these anonymization options, ENISA also proposes other more straightforward local encypted stotage options such as full disk encryption (FDE) or file system-level encryption (FSE). Other more complex PETs such as Format-preserving encryption (FPE) and Steganographic storage options are also discussed, by emphasizing their strengths but also indicating their inefficiencies as well. Finally, possible PETS enabling searching on encrypted data are also pointed by ENISA listing Symmetric Searchable Encryption (SSE) and Public-key Searchable Encryption (PEKS) as options. The ISO 25237:2017 -Pseudonymization Standard (ISO/TC 215 Health informatics, 2017) provides the principles and requirements for privacy protection using pseudonymization services for the protection of personal health information. Another useful guidance is provided by IHE, the ITI Healthcare De-Identification Handbook (IHE IT Infrastructure Technical Committee, 2014) explains the process for removing individually identifiable information from healthcare data. This includes de-identification, pseudonymization, re-linking, design considerations, techniques, and risks.


51

Active Medication List) from patient’s Country A. The Care Providers see that the

patient has a long history of acute exacerbation of asthma. Appropriate

medication and therapeutics are given based on the patient summary, by also

checking drug-drug interactions and drug-allergy.

Information - Patient Summary (in patient’s language and country B language): All

components of the patient summary are applicable to this scenario of use

along with additional ones specific to the reporting needs of the

emergency response team.

- Patient Consent: Please note that the patient may not be conscious at the

time of the disaster. Here there are two options, the patient may have

already given his consent while he is in Country A, or in case of emergency

(like a disaster as in the case of this use case), break the glass procedures

can be followed to access


Healthcare professional in patient’s country of origin/affiliation (country A) Healthcare Providers in European Civil Protection modules of Field Hospital and evacuation camps (country B)

Functional process

steps

(With the reservation that preconditions are met)

• The Healthcare Provider needs to treat the patient in country B in the case of a disaster situation.

• The patient is identified (In case of failure of identification and authentication mechanisms fail due to the limited conditions and/or failures due to the disaster, alternate authentication mechanism may be employed)

• The Care Provider is identified, authenticated and authorized. (In case of failure of identification and authentication mechanisms fail due to the limited conditions and/or failures due to the disaster, alternate authentication mechanism may be employed).

• The patient may have given consent before travelling to country B. If not, without requiring an explicit consent from the patient, break the glass procedures are employed for authorization of access.

• The Patient Summary is electronically transferred from the patient’s country of origin to the health professional in Country B in a secure way. The Care Provider retrieves the Patient Summary and uses it for the consultation.

• The Patient Summary is received in both the language of the patient (PDF

of original PS) and as a translated version for the Care Provider.

Note: Here it is assumed that the technological mechanism to communicate

between NCPeHs of Country a and B are intact. If this is not the case, an

alternative solution could be the case where the patient carries a printed patient

summary with him. We will not discuss the analysis of this alternative use case

here in this document, as very little (if any) electronic PETs can be employed to

safeguard security and privacy of the exported patient summaries within the

scope of this use case.


52




In this section, we will outline the participants, systems, domains and responsibilities.

The core paradigm of this use case is not to directly connect physicians, but to connect the national infrastructures of a patient’s home country and the country where a patient currently receives medical services in disaster situations. Patients’ home country is referred to as country 'A', and the country, where the patient gets medical treatment, is referred to as country 'B':

• Country A is the country of affiliation (CoA), this means that country A is legally the exclusive entity, which is responsible for appropriately storing, archiving and documenting any required health information of a patient within its existing national infrastructure.

• Country B is the country where the point of care (PoC) is located that provides healthcare to a patient from country A.

The Emergency Care Systems (ECS) are the systems used by the European Civil Protection modules of Field Hospital and evacuation camps at Country B, while PoCs could be a hospital, an individual practitioner, a pharmacy or any other point of the health care system Country A. Each country is represented by a “National Contact Point (NCPeH)” creating a Circle of Trust” (CoT) that enables inbound and outbound communication cross borders. It is assumed that within each country, through the agreements between PoCs and NCPeH a national Circles of Trust is created, which leads up to building cascaded circles of trust. In the light of these descriptions and OAISIS PMRM guidelines, the Domains identified are Country A and Country B as different policies may apply especially for the interactions between PoCs and NCPeHs (i.e. HIPAA in U.S., EU GDPR within EU countries). Yet as described in section 3, for the interactions between the NCPeHs of Country A and Country B, either EU-US Privacy Shield (when cross border exchange between an EU member state and U.S. is targeted) or directly GDPR (when cross border exchange between an EU member states) would apply. To cover these, we will follow the principles set in Section 3 covering the needs of these. The Systems identified are ECS, PoC and NCPeH gateways. The Actors identified (also by eHDSI Glossary) are:


• Healthcare Provider (CP): A doctor of medicine, a nurse responsible for general care, a dental practitioner, a midwife or a pharmacist involved in the care of a Patient. Furthermore, a HP must be under national law or rules established by national competent authorities to the obligation of professional secrecy or by another person also subject to an equivalent obligation of secrecy.

• National Contact Point (NCPeH): A legal entity representing a country involved in this use case, assuming legal duties towards participating countries and its own network of national gateways: it acts in a bidirectional way transmitting in-outbound messages between national IT infrastructures and NCPeHs from other countries). A NCPeH processes medical data to achieve interoperability.



system locally within a participating country


53

o System operators.


Based on the Functional Process Steps presented in the Use Case description, a high-level interaction diagram has been prepared to analyze the data flow, as presented in Figure 6.

Figure 6 Overview of the Data Flow diagram for Emergency and Disaster Management Scenario


different systems identified in the domains are highlighted for an easy identification of the touchpoints.

Table 3 Multi-Level Data Flows Matrix of Emergency and Disaster Management Scenario


PoC A NCPeH A ECS NCPeH B


PoC A -Patient Consent (Optional) -Patient Summary

NCPeH A



ECS -Patient Identity Claim -CP Identity Claim -Patient Summary Query

NCPeH B

-Patient Identity Claim -CP Identity Claim -Patient Summary Query





54

• Healthcare-related Data: Healthcare Data of a Patient Summary used for the medical treatment of a patient. Both according to EU regulations and HIPAA, the processing of these medical data has to satisfy higher privacy requirements. Healthcare related data contain also:

o data about the Patient Consent (If available in the case of emergency); o log data which provide information about the access to healthcare related data

• Critical Meta Data: Data needed to control the exchange of healthcare related data between NCPeHs and between NCPeHs and PoCs, respectively. Critical Meta Data include authentication, identification and administrative data to clearly identify patients, PoCs and HPs





The data flow diagram and data flow matrix for the “Unplanned Care Scenario” discussed in section 4.1, and

the ones presented in the previous section for “Emergency and Disaster Management” scenario are quite

similar to each other: only the PoC B in Country B has been replaced with ECS in Country B. Yet, the context

of patient summary access and processing can be quite different in these scenarios. Considering that there

is clearly an emergency situation, the patient might be unconscious to provide explicit consent to the

healthcare professionals in field hospitals to access their patient summaries, and the normal

authentication/authorization processes might not be successfully completed or not working properly. In such

situations, “break the glass” procedures need to be executed to enable emergency access to patient

summaries.

In this section, we will not repeat the security and privacy controls that needs to be employed where there

is no need to employ such break the glass procedures even though the access happens in a disaster and

emergency environment. For those criteria readers are invited to carefully check section 4.1. Here we will

focus on the additional constraints/exemptions necessary to address the needs of break the glass processes.

For these criteria definitions we have utilized the “Break-Glass – An Approach to Granting Emergency Access

to Healthcare Systems” White Paper developed by the Joint NEMA/COCIR/JIRA Security and Privacy

Committee (SPC) (Joint NEMA/COCIR/JIRA Security and Privacy Committee (SPC), 2004).

Consent

C.61. In emergency situations, “break the glass” solutions should be possible as a contingency plan

that assure patient care is not impaired in the absence of explicit patient consent.


C.62. Emergency Account Permissions should be set to least necessary privilege to grant access by emergency users to the minimum data and functionality needed to perform their task.

Transparency and openness

C.63. In emergency situations, “break the glass” should be possible but the patient should ALWAYS be notified afterwards.

Rights of the Individual

C.64. Organisations involved in use case implementation MUST allow data subjects to exercise their right to deny the possibility of break the glass accesses.


55

Information Security Identification and Authentication

C.65. In case of emergency situations, authentication shall be based on pre-staged emergency user

accounts, managed and distributed in a way that can make them available without unreasonable

administrative delay.

C.66. Identification &Authentication (I&A) of each User at NCPeH and PoC systems MUST support

break the glass policies, by supporting emergency accounts.

Access Control

C.67. Local PoC systems, NCPeh and ECP MUST provide a break the glass contingency plan that can

be used in case of emergency situations to enable access to medical information without

unreasonable administrative delay.

8. Accountability

Auditing

C.68. It MUST be ensured that each action taken via emergency accounts must be audited in a

detailed manner. It might be considered to increase the audit levels in case of emergency account

usage cases.

Fraud Detection

C.69. The use of emergency accounts needs to be carefully monitored.

C.70. The audit procedures shall define a clear strategy to examine the security audit trails on a

regular basis to identify any use of the emergency accounts.

4.3.3. Recommended Security and Privacy Enhancing Technologies/Services (Step 3) In this section, we will present the guidance provided by the “Break-Glass – An Approach to Granting

Emergency Access to Healthcare Systems” White Paper developed by the Joint NEMA/COCIR/JIRA Security

and Privacy Committee (SPC) (Joint NEMA/COCIR/JIRA Security and Privacy Committee (SPC), 2004).




Transparency and Openness



C.62

The SPC guidelines recommends that the emergency account permissions should be set to least necessary privilege to grant access by emergency users to the minimum data and functionality needed to perform their task. This could potentially include view-only capability, prohibiting access from outside the local console or network, limiting to data acquisition only.




56

Recommended Security and Privacy Enhancing Technologies/Services for addressing the needs of Rights

of the Individuals




Accountability

C.63

In addition to the recommendations presented in Section 4.1.3, it should be made sure that the patient is ALWAYS be notified in detail after his/her patient summary has been accesses in the case of an emergency situation via the break the glass processes. ed to the user) depending on the result of the matching. For details of these suggestions please see ENISA Report.



C.64

The Intervenability Enhancing PETS as described in Section 4.1.3, should provide clear options for the patient to opt-out of the ‘break the glass’ access procedures.



Identification & Authentication C.65, C.66

Emergency Accounts should be created in advance to allow careful thought to go into the access controls and audit trails associated with them. When creating the pre-staged emergency accounts, the site administrative privacy and security policy must be consulted. The following factors should be considered (Joint NEMA/COCIR/JIRA Security and Privacy Committee (SPC), 2004): A. Username should be obvious and meaningful, e.g. emergency001 so the account will be obviously inappropriate for normal operations and will stand out in audit trails. B. Passwords should be hard to guess or crack. It is important, they not be so difficult that the user, in an emergency, would have trouble entering it.

Access Control C.67

It should be possible to manage the access control mechanisms in case of absence of explicit patient consent. The Break the Glass white paper provided by (Joint NEMA/COCIR/JIRA Security and Privacy Committee (SPC), 2004) provides the following guidelines about access control management: “Account Permissions should be set to least necessary privilege based on the results of a risk assessment, e.g. grant access by emergency users to the minimum data and functionality needed to perform their task. This could potentially include view-only capability, prohibiting access from outside the local console or network, limiting to data acquisition only, or prohibiting access to previously acquired data. Due to the difficulty of anticipating emergency needs, sites may choose to allow full access to emergency accounts.” Finally, standard access controls mechanism described in section 4.1.3 should be established with sufficient rules to minimize the number of times break–the–glass needs to occur.




57

5. Conclusions This deliverable defines a methodology to provide a detailed privacy management analysis of the selected

Trillium II use cases to provide traceability from Regulations/Principles/ Preferences to the recommended

Security & Privacy Measures that needs to be implemented in pilot implementations. The methodology is

primarily based on OASIS Privacy Management Reference Model and Methodology (PMRM) with extensions

derived from PRIPARE Privacy - and Security-by-Design Methodology Handbook and ENISA Report on “Privacy

and Data Protection by Design – from policy to engineering”.

Following this methodology, in this deliverable, we first of all identified the Privacy Principles that will be

taken as the legal basis of the privacy and security management analysis study that will be carried out. In line

with the scope of Trillium II project, the legal requirements to be addressed need to be derived from the EU

General Data Protection Regulation (GDPR), Health Insurance Portability and Accountability Act (HIPAA) and

EU-U.S. Privacy Shield Principles. To address these needs, we have built upon the security and privacy

principles identified by ENISA which have already been mapped to the EU Data Protection Laws including

GDPR clauses. On top of this, we have been analysed HIPAA Security and Privacy Rules to extract the security

and privacy principles to be addressed and mapped these to the eight principles identified by ENISA.

Finally, we have analysed the following selected Trillium II use cases following our methodology and provided

guidance about the Security and Privacy Enhancing Technologies that needs to be implemented by the

implementers of the use cases:

• The unplanned care” scenario as defined by Directive 2011/24/EU of 9 March 2011 on the application

of patients’ rights in cross-border healthcare

• Exchanging patient summaries for enabling continuity of care for chronic disease patients

• Emergency and Disaster Management – Evacuation camp and Field Hospital

Auditing (C.68) Fraud Detection (C.69-C.70)

SPC guidelines recommends that the emergency access usage cases should be clearly logged, when possible by increased auditing levels. In addition to this, as a part of compliance monitoring audit procedures, the security audit trails should be examined on a regular basis to identify any use of the emergency accounts. Each use of an emergency account should be reviewed. The use of an emergency account may be valid, or it might indicate a malicious act. Unacceptable use needs to be recorded and acted upon. Frequent use may indicate problems with the normal user authentication mechanism. This regular monitoring of pre-staged emergency accounts should also include exercising some of them to ensure that they do work, and that their use can be detected.

In addition, systems can alert the security administrator in the event an emergency account is activated. Site policy should describe the intended use of such accounts and the consequences of their inappropriate use. Details should be clearly documented and then communicated to the relevant workforce. It should be clear that all use of emergency accounts is closely monitored. A periodic review and retraining of staff should be done to make sure the break-glass procedure continues to be relevant.


58

In this analysis we have greatly benefited from the eHealth Digital Service Infrastructure (DSI) Security Service

Specifications (eHDSI, eHealth DSI Security Services Specification, 2017) as one of the analysed use cases is

cross border “unplanned care”. The eHDSI Security Policy specifications, and the accompanying Security

Services Specifications very well addresses the requirements of Information Security principle (including

identification, authentication, digital signatures, access control, confidentiality, system and data integrity,

non-repudiation) and Accountability principle. On the other hand, the new requirements introduced by GDPR

such as Transparency and Openness, and Rights of Individuals (online access to personal data and possibilities

to exercise data subject rights such as withdrawing consent or requesting rectification, blocking and erasure

of personal data) are not directly addressed eHealth DSI Security Services Specifications. Here we have

utilized the guidance provided by ENISA report to point the implementers to the possible PETS suggested by

ENISA. In addition to these, different from the eHDSI, Trillium II intends to use FHIR resources to reflect the

needs of the International Patient Summary. In our analysis we have take in to account these differences

and provided references to security and privacy measures that is also applicable to RESTful FHIR resource

exchange paradigm. Finally, in the analysis of the Emergency and Disaster Management use case, we have

benefited form the guidance provided by the “Break-Glass – An Approach to Granting Emergency Access to

Healthcare Systems” White Paper developed by the Joint NEMA/COCIR/JIRA Security and Privacy Committee

(SPC) (Joint NEMA/COCIR/JIRA Security and Privacy Committee (SPC), 2004).

6. Ethical Issues This document mainly presents a methodology to analyze the security and privacy risks of use cases exchanging IPS and refers to possible privacy enhancing technologies and solutions to address possible risks. The actual implementation of these use cases is beyond the scope of this deliverable. Hence no specific assessment on ethical issues was carried out. However, since all the use cases related to the adoption of the IPS refer to the treatment of clinical sensitive

information, it is recommended that ethical aspects are thoroughly assessed when real services

implementation and operation are undertaken.

7. Appendix

7.1. Reference Methodologies for Security and Privacy Management Analysis

7.1.1. OAISIS Privacy Management Reference Model and Methodology (PMRM)

The Privacy Management Reference Model and Methodology (PMRM, pronounced “pimrim”) (OASIS PMRM

TC, 2016) provides a model and a methodology to understand and analyse privacy policies and their privacy

management requirements in defined Use Cases; and select the technical Services, Functions and

Mechanisms that must be implemented to support requisite Privacy Controls. It is particularly valuable for

Use Cases in which Personal Information (PI) flows across regulatory, policy, jurisdictional, and system

boundaries. The PMRM creates an audit trail from Policy to Privacy Controls to Services and Functions to

Mechanisms.

The PMRM supports this by producing a Privacy Management Analysis (PMA) document, mapping Policy to Privacy Controls to Services and Functions, which in turn are implemented via Mechanisms, both technical and procedural. In this respect, PMRM perfectly suits to the needs of Trillium II Task 3.6, which aims to analyse the selected use cases, identify the security and privacy risks in accessing and processing PI and


59

provide a catalogue of security and privacy measures that can be utilized to address these risks. In this section, the basic principles of PMRM will be presented as it is one of the foundations of the methodology that we will follow in Task 3.6. PMRM defines a model where it aims to represent the core concepts of privacy and protection management

(as presented in Figure 7). Based on this model, in each Domain, the Stakeholders (including data subjects,

policy makers, solution providers, etc.) drive policies (which both reflect and influence actual regulation and

law-making). By examining these policies, Privacy Principles are extracted, which are foundational terms

which represent expectations, or high-level requirements, for protecting personal information and privacy.

In OASIS PMRM, 14 Operational Privacy Principles are being defined (see Table 4), which were derived from

a review of international legislative and regulatory instruments (such as the U.S. Privacy Act of 1974 and the

EU Data Protection Directive) in the ISTPA document (Sabo, 2007). These principles are not directly applicable

for our analysis, as we need to address the requirements of EU General Data Protection Regulation (GDPR)

and US Health Insurance Portability and Accountability Act (HIPAA) requirements as well.

In PMRM model, the Use Cases which are developed to expose and document specific requirements to

achieve a selected goal, are analysed in the light of the Privacy Principles derived from Privacy Policies, and

a list of Privacy Control requirements are extracted for each use case. Privacy Controls are administrative,

technical or physical safeguards which are employed within an organization or Domain in order to protect

and manage PI. The final objective is to document a Privacy Architecture which lists the Services and

Functions necessary to implement the selected Privacy Controls in Mechanisms. In PMRM, Functions are

defined as Activities or processes within each Service intended to satisfy the Privacy Control, while

Mechanisms are defined as the packaging and implementation of Services and Functions into manual or

automated solutions.

Figure 7 OASIS PMRM Model

Table 4: Operational Privacy Principles selected by OASIS PMRM


60

PRIVACY PRINCIPLE DEFINITION

ACCOUNTABILITY Functionality enabling the ability to ensure and demonstrate compliance with privacy policies to the various Domain Owners, Stakeholders, regulators and data subjects by the privacy program, business processes and technical systems.

NOTICE Functionality providing Information, in the context of a specified use and in an open and transparent manner, regarding policies and practices exercised within a Domain including: definition of the Personal Information collected; its use (purpose specification); its disclosure to parties within or external to the Domain; practices associated with the maintenance and protection of the information; options available to the data subject regarding the processor’s privacy practices; retention and deletion; changes made to policies or practices; and other information provided to the data subject at designated times and under designated circumstances.

CONSENT AND CHOICE Functionality enabling data subjects to agree to the collection and/or specific uses of some or all of their PI either through an opt-in affirmative process, opt-out, or implied (not choosing to opt-out when this option is provided). Such functionality may include the capability to support sensitive Information, informed consent, choices and options, change of use consent, and consequences of consent denial.

COLLECTION LIMITATION AND INFORMATION MINIMIZATION

Functionality, exercised by the information processor, that limits the personal information collected, processed, communicated and stored to the minimum necessary to achieve a stated purpose and, when required, demonstrably collected by fair and lawful means.

USE LIMITATION Functionality, exercised by the information processor, that ensures that Personal Information will not be used for purposes other than those specified and accepted by the data subject or provided by law, and not maintained longer than necessary for the stated purposes.

DISCLOSURE Functionality that enables the transfer, provision of access to, use for new purposes, or release in any manner, of Personal Information managed within a Domain in accordance with notice and consent permissions and/or applicable laws and functionality making known the information processor’s policies to external parties receiving the information

ACCESS, CORRECTION AND DELETION

Functionality that allows an adequately identified data subject to discover, correct or delete, Personal Information managed within a Privacy Domain; functionality providing notice of denial of access; options for challenging denial when specified; and “right to be forgotten” implementation.

SECURITY/SAFEGUARDS Functionality that ensures the confidentiality, availability and integrity of Personal Information collected, used, communicated, maintained, and stored; and that ensures specified Personal Information will be deidentified and/or destroyed as required.

INFORMATION QUALITY Functionality that ensures that information collected and used is adequate for purpose, relevant for purpose, accurate at time of use, and, where specified, kept up to date, corrected or destroyed.

ENFORCEMENT Functionality that ensures compliance with privacy policies, agreements and legal requirements and to give data subjects a means of filing complaints of compliance violations and having them addressed, including recourse for violations of law, agreements and policies, with optional linkages to redress and sanctions. Such Functionality includes alerts, audits and security breach management.

OPENNESS Functionality, available to data subjects, that allows access to an information processor’s notice and practices relating to the management of their Personal Information and that establishes the existence, nature, and purpose of use of Personal Information held about the data subject.

ANONIMITY Functionality that prevents data being collected or used in a manner that can identify a specific natural person.

INFORMATION FLOW Functionality that enables the communication of personal information across geopolitical jurisdictions by private or public entities involved in governmental, economic, social or other activities in accordance with privacy policies, agreements and legal requirements.

SENSITIVTY Functionality that provides special handling, processing, security treatment or other treatment of specified information, as defined by law, regulation or policy.

The PMRM proposes a methodology that starts from Use Case definitions and Privacy Policies, and finishes

when the Privacy Services, Functions and Mechanisms that would constitute a Privacy Architecture

documentation. The steps to be followed are briefly described here:

• Step 1: Develop Use Case Description and High Level Privacy Analysis: The first phase in applying

the PMRM methodology requires the scoping of the Use Case in which PI is associated in effect,

identifying the complete description in which the environment, application or capabilities where

privacy and data protection requirements are applicable. This includes definition of the use case;


61

identification of the business environment, capabilities, applications and policy environment

applicable in the use case definition; identifying the privacy policy conformance criteria as a set of

applicable privacy principles and required privacy controls; and an optional initial high-level Privacy

Impact Assessment.

Figure 8 OASIS PMRM Methodology

• Step 2: Develop Detailed Privacy Analysis:

A. The first step is to identify business domains and understanding the roles played by all

participants and systems within the Domains in relation to privacy policies. Then Systems

and Business Processes where PI is collected, stored, used, shared, transmitted, transferred

across borders, retained or disposed within a Domain are identified. The next action is to

identify the data flows and Touch Points for all personal information within a Domain or

Domains.

B. The second step is to specify the PI collected, stored, used, shared, transmitted, transferred

across borders, retained or disposed within Domains or Systems or Business Processes

within the Use Case. They are categorized as Incoming, Internally Generated and Outgoing

PI.

C. The third step is to specify the Privacy Controls required to enforce the privacy policy

associated with each of the Incoming, Internally Generated and Outgoing PI. Privacy

Controls are in fact set of selected privacy conformance criteria (defined by Privacy

Principles) that are applicable to the data flow being analysed.

• Step 3: Identify Services and Functions Necessary to Support Privacy Controls: Privacy Controls are usually stated in the form of a policy declaration or requirement and not in a way that is immediately actionable or implementable. Till this step, PMRM focused on the requirements of the real world, i.e. human side of privacy. In this step, the attention is turned on to the procedures, business processes and technical system level, components that enable privacy. PMRM aims to identify a set of Services and Functions deemed necessary to implement the management and compliance of detailed Privacy Policies and Privacy Controls within a Use Case. The Services are sets of Functions,


62

which form an organizing foundation to facilitate the application of the model and to support the identification of the specific Mechanisms (e.g. code, applications, or specific business processes), which will implement them. The final objective of PMRM is to identify the set of Mechanisms that transforms the Privacy Controls identified in the previous step into an high level operational system definition. (a.k.a high-level Privacy Architecture description). They may optionally be incorporated in a broader Privacy Architecture later. PMRM identifies eight Privacy Services as depicted in Table 5, necessary to support any set of privacy policies and Controls, at a functional level.

Table 5: OASIS PMRM Services

SERVICE FUNCTIONALITY PURPOSE

AGREEMENT Defines and documents permissions and rules for the handling of PI based on applicable policies, data subject preferences, and other relevant factors; provides relevant Actors with a mechanism to negotiate, change or establish new permissions and rules; expresses the agreements such that they can be used by other Services

Manage and negotiate permissions and rules

USAGE Ensures that the use of PI complies with the terms of permissions, policies, laws, and regulations, including PI subjected to information minimization, linking, integration, inference, transfer, derivation, aggregation, anonymization and disposal over the lifecycle of the PI

Control PI use

VALIDATION Evaluates and ensures the information quality of PI in terms of accuracy, completeness, relevance, timeliness, provenance, appropriateness for use and other relevant qualitative factors

Ensure PI quality

CERTIFICATION Ensures that the credentials of any Actor, Domain, System, or system component are compatible with their assigned roles in processing PI and verifies their capability to support required Privacy Controls in compliance with defined policies and assigned roles.

Ensure appropriate privacy management credentials

ENFORCEMENT Initiates monitoring capabilities to ensure the effective operation of all Services. Initiates response actions, policy execution, and recourse when audit controls and monitoring indicate operational faults and failures. Records and reports evidence of compliance to Stakeholders and/or regulators. Provides evidence necessary for Accountability.

Monitor proper operation, respond to exception conditions and report on demand evidence of compliance where required for accountability

SECURITY Provides the procedural and technical mechanisms necessary to ensure the confidentiality, integrity, and availability of PI; makes possible the trustworthy processing, communication, storage and disposition of PI; safeguards privacy operations

Safeguard privacy information and operations

INTERACTION Provides generalized interfaces necessary for presentation, communication, and interaction of PI and relevant information associated with PI, encompassing functionality such as user interfaces, system to system information exchanges, and agents

Information presentation and communication

ACCESS Enables Data Subjects, as required and/or allowed by permission, policy, or regulation, to review their PI that is held within a Domain and propose changes, corrections or deletion for their PI

View and propose changes to PI

In this step, the Privacy Controls identified for each data flow are mapped to the respective PMRM Services.

• Step 4: Define Technical and Procedural Mechanisms Supporting Selected Services and Functions: Finally, for the elaborated services, the Mechanisms, specific procedures, applications, technical and vendor solutions, code and other concrete tools that will actually make possible the delivery of required Privacy Controls are identified.

• Step 5: Perform Risk Assessment: Once the requirements in the Use Case have been converted into operational Services, Functions and Mechanisms, an overall risk assessment is performed. As a result, additional controls might be added to mitigate the risks in an iterative manner.

OASIS PMRM methodology is concluded by documenting the PMA by detailing the results of these steps to potentially inform a Privacy Architecture.


63

7.1.2. PRIPARE (PReparing Industry to Privacy-by-design by supporting its Application in

Research) Privacy- and Security-by-Design Methodology Handbook PRIPARE (PReparing Industry to Privacy-by-design by supporting its Application in Research, Contract No: 610613) was a Support Action Project funded by the European Union’s Seventh Framework Programme (October 2013-December 2015) (PRIPARE Consortium, 2015) which aims to facilitate the application of a privacy- and security-by-design methodology, support its practice by the ICT research community to prepare for industry practice; and foster risk management culture through educational material targeted to a diversity of stakeholders. In line with these objectives, it delivered a handbook on its privacy- and security-by-design methodology, as a guidance to future engineers who wish to build their privacy engineering practices (PRIPARE Privacy- and Security-by-design Methodology Handbook, 2016).

Figure 9 PRIPARE's methodology reference model

In Figure 9, the PRIPARE methodology reference model is presented. When examined in comparison with

Figure 7, it will be noticed that it builds upon OASIS PMRM, and it extends PMRM by including a more

elaborate discussion of Privacy Risk Assessment processes as a guide for the selection of Privacy Controls. In

addition to this difference, while OASIS PMRM focuses basically on the Privacy Management Analysis,

PRIPARE goes one step further, and covers security and privacy management during the full classical system

engineering steps, i.e. Analysis, Design, Implementation, Verification, Release, Maintenance and

Decommission as depicted in Figure 10.

As Trillium Bridge II Project is not a deployment project that will end up operational deployment in real life

settings (although it will pilot implementations in WP6), the latter steps of PRIPARE methodology starting

with the Implementation, are not directly linked with our scope in the project. In this section, we will examine

the Analysis and Design Steps proposed by PRIPARE. While doing so, as it builds upon PMRM already, the

extensions will be highlighted.


64

Figure 10 Pripare Methodology Steps

PRIPARE proposes to follow Step 1 and Step 2 of PMRM methodology almost as it is. One of the extended sub-step is operationalization of privacy principles to identify the specific privacy requirements the system should meet as Privacy Controls, by mapping high-level, legal and user concerns onto engineering requirements. In OASIS PMRM, a clear path to follow to extract Privacy Controls from the Privacy Policies and Principles have not been identified. PRIPARE proposes a process to first identify the privacy principle set to be applied, then to define categorized privacy requirements for each privacy principle as a catalogue of privacy requirements as conformance criteria (as shown in Figure 11).

Figure 11 PRIPARE – Operationalization of Privacy Principles

In an initial version of the methodology, PRIPARE identified 14 principles: (1) data quality, (2) data minimization and proportionality, (3) purpose specification and limitation (finality or legitimacy), (4) purpose specification and limitation for sensitive data, (5) transparency and openness, (6) right of access,


65

(7) right to object, (8) confidentiality and security, (9) compliance with notification requirements, (10) limited conservation and retention, (11) accountability, (12) right to erasure, (13) privacy and data protection-by-design, (14) privacy and data protection-by-default. This initial set of privacy principles were directly extracted from the study of the GDPR. Later, PRIPARE decided to adopt the list of privacy principles set by ISO29100 (ISO/IEC Information Technology Task Force (ITTF), 2011) (see Appendix 7.3), as it is the international privacy framework standard and it is a reference document that can be used by privacy engineers. In the Annex of PRIPARE methodology a detailed catalog of privacy conformance criteria for each ISO29100 privacy principle is listed. As an example, in Figure 12, the criteria identified for ISO29100 privacy principle 3 – Collection Limitation are presented.

Figure 12 Privacy Criteria identified for ISO 29100 privacy principle 3 (Collection Limitation) by PRIPARE

Another extension proposed by PRIPARE is proposing to use risk management methods, such as Privacy Impact Assessment (PIA) methods, to analyze high-level system definition to identify the privacy risks associated with the system and to suggest treatments to address these risks. This process is instrumental in establishing a link between the high-level functional description and actual operational requirements of the system. Identifying these risks can highlight areas where PbD principles can be applied and embedded. In summary, the final set of Privacy Controls to be applied, from the catalogue of privacy requirements are decided as a result of PIA process proposed by CNIL guidelines (CNIL, 2015). The next step in PRIPARE Methodology is “Design”, where the operational requirements on privacy controls are mapped to Privacy Enhancing Techniques (PETs) that will implement them and Privacy Enhancing Architecture (PEAR) design is delivered. This step is similar to PMRM Step 3. PMRM lacks a comprehensive list of privacy controls and technical mechanisms or business processes that could guide system engineers. PRIPARE promised to collect and organize a number of privacy patterns, linked to PETs, in order to support engineers in the design of secure and privacy-supporting systems. Yet the final PRIPARE methodology provides only an overview of the classifications that have been proposed to categorize PETs from the literature. No complete catalogue of privacy enhancing techniques is provided. It rather summarizes different formal approaches to develop PEARs.


66

7.1.3. ENISA Report on “Privacy and Data Protection by Design – from policy to engineering” ENISA has published a report (ENISA, 2015) as a guidance to describe how Privacy by Design (PbD) approach

that can be implemented with the help of engineering methods; bridging the gap between the legal

framework and the available technological implementation measures by providing an inventory of existing

approaches, privacy design strategies, and technical building blocks of various degrees of maturity from

research and development. Similar to OASIS PMRM and PRIPARE, it starts by identifying the privacy principles

of the respective legislation and sketches a method to map legal obligations to design strategies, which allow

the system designer to select appropriate techniques for implementing the identified privacy requirements.

ENISA proposes nine main Privacy Principles from the European legal data protection context by providing

references to the European Data Protection Directive 95/46/EC (DPD) (Directive 95/46/EC, 1995), to Opinions

of the Article 29 Data Protection Working Party (based on Art. 29 DPD) (Article 29 Working Party, 2016) and

to the European General Data Protection Regulation (GDPR) (European Parliament & Council, 4/5/2016). In

this context, this set is valuable, as one of the legal framework that we should be addressing is EU GDPR. The

list of these principles are as follows:

1. Lawfulness

2. Consent

3. Purpose binding

4. Necessity and Data minimization

5. Transparency and Openness

6. Rights of the individual

7. Information Security

8. Accountability

9. Data Protection by design and by default

As a next step, ENISA also proposed to conduct a preliminary Privacy Impact Assessment (PIA) or a privacy

risk analysis to define concrete objectives of the systems in terms of privacy. It is also highlighted that PIAs

are required in certain situations by the GDPR which stipulates that its results should be considered in the

privacy by design process1.

Another important contribution of this ENISA report is that it provides a catalogue of privacy design strategies

and PETs to help the designers to choose from while designing the Privacy Architecture. ENISA defines eight

privacy design strategies based on the classification provided by Hoepman (Hoepman, 2014):

1 cf. GDPR, Paragraph 1 of Article 23; “Data protection by design shall have particular regard to the entire lifecycle management of personal data from collection to processing to deletion, systematically focusing on comprehensive procedural safeguards regarding the accuracy, confidentiality, integrity, physical security and deletion of personal data. Where the controller has carried out a data protection impact assessment pursuant to Article 33, the results shall be taken into account when developing those measures and procedures.”


67

Table 6: ENISA Design Strategies and Patterns

Design Strategy Brief Description Design Patterns

Minimize The amount of personal data that is processed should be restricted to the minimal amount possible

- Select before you collect - Anonymization - Pseudonymisation

Hide Any personal data, and their interrelationships, should be hidden from plain view

- Encryption of data (when stored, or when in transit) - Mix networks - Hide traffic patterns - Attribute based credentials - Anonymization - Pseudonymisation

Separate Personal data should be processed in a distributed fashion, in separate compartments whenever possible

Not known

Aggregate Personal data should be processed at the highest level of aggregation and with the least possible detail in which it is (still) useful

- Aggregation over time (used in smart metering) - Dynamic location granularity (used in location based services) - k-anonymity - Differential privacy - Other anonymization techniques

Inform Transparency and openness: Data subjects should be adequately informed whenever personal data is processed

- Data breach notifications - Transparency-enhancing techniques

Control Data subjects should be provided agency over the processing of their personal data

- User centric identity management - End-to-end encryption support control

Enforce A privacy policy compatible with legal requirements should be in place and should be enforced

- Access control - Sticky policies - Privacy rights management

Demonstrate Demonstrate compliance with the privacy policy and any applicable legal requirements

- Logging and auditing

Finally, ENISA report provides, a catalogue of privacy techniques covering the design patterns identified in Table 6: ENISA Design Strategies and Patterns including the following:

• Authentication (including the end-to-end authentication methods, federated identity management and single-sign-on)

• Attribute based credentials

• Secure private communications (including basic encryption, key rotation, forward secrecy and coercion resistance)

• Communications anonymity and pseudonymity

• Privacy in databases

• Technologies for respondent privacy: statistical disclosure control (including Tabular data protection, Queryable database protection and Microdata protection)

• Privacy preserving data mining

• Technologies for user privacy: Private information retrieval

• Storage privacy (including Operating system controls, Local encrypted storage, Steganographic storage and Secure remote storage)

• Privacy preserving computations (including Homomorphic encryption, Secure multi-party computation)

• Transparency-enhancing techniques

• Intervenability-enhancing techniques


68

7.2. Reference Security and Privacy Management Standards

2 Parts 1-3 have been withdrawn.

ISO/TC 215 Health Informatics Privacy and Security Standards

ISO/TS 13606-4:2009 Electronic health record communication -- Part 4: Security

ISO/TR 11636:2009 Dynamic on-demand virtual private network for health information

infrastructure

ISO 22857:2013 Guidelines on data protection to facilitate trans-border flows of personal health

data

ISO/TS 21547:2010 Security requirements for archiving of electronic health records -- Principles

ISO/TR 21548:2010 Security requirements for archiving of electronic health records -- Guidelines

ISO/TS 14441:2013 Security and privacy requirements of EHR systems for use in conformity

assessment

ISO/TR 11633-1:2009 Information security management for remote maintenance of medical devices

and medical information systems -- Part 1: Requirements and risk analysis

ISO/TR 11633-2:2009

Information security management for remote maintenance of medical devices

and medical information systems -- Part 2: Implementation of an information

security management system (ISMS)

ISO 17090-1:2013 Public key infrastructure -- Part 1: Overview of digital certificate services

ISO 17090-2:2015 Public key infrastructure -- Part 2: Certificate profile

ISO 17090-3:2008 Public key infrastructure -- Part 3: Policy management of certification authority

ISO 17090-4:2014 Public key infrastructure -- Part 4: Digital Signatures for healthcare documents2

ISO 22600-1:2014 Privilege management and access control -- Part 1: Overview and policy

management

ISO 22600-2:2014 Privilege management and access control -- Part 2: Formal models

ISO 22600-3:2014 Privilege management and access control -- Part 3: Implementations

ISO 27799:2016 Information security management in health using ISO/IEC 27002

ISO 25237:2017 Pseudonymization

ISO/TR 18638:2017 Guidance on health information privacy education in healthcare organizations

ISO/IEC 29134:2017 Information technology -- Security techniques -- Guidelines for privacy impact

assessment


69

CEN Privacy and Security Standards

EN/ISO 27799:2016 Health informatics -- Information security management in health using

ISO/IEC 27002

CEN ISO/TS

14265:2013

Health Informatics - Classification of purposes for processing personal health

information (ISO/TS 14265:2011)

CEN/TR 15300:2006 Health informatics - Framework for formal modelling of healthcare security

policies

CR 13694:1999 Health Informatics - Safety and Security Related Software Quality Standards

for Healthcare (SSQS)

CR 14301:2002 Health informatics - Framework for security protection of healthcare

communication

EN 12251:2004 Health informatics - Secure User Identification for Health Care -Management

and Security of Authentication by Passwords

EN 13606-4:2007 Health informatics - Electronic health record communication -Part 4:

Security

EN ISO 25237:2017 Health informatics - Pseudonymization

EN ISO 27789:2013 Health informatics - Audit trails for electronic health records

IHE Profiles & Handbooks

ATNA Audit Trail and Node Authentication

BPPC Basic Patient Privacy Consents

De-Identification

Handbok IHE IT Infrastructure Handbook – De-identification

DEN Document Encryption

EUA Enterprise User Authentication

XUA Cross-Enterprise User Assertion

Other National Privacy and Security Standards

CNIL PRIVACY IMPACT ASSESSMENT (PIA) Methodology

NIST 800-53 Security and Privacy Controls for Federal Information Systems and

Organizations


70

7.3. ISO/IEC 29100 Information technology — Security techniques — Privacy framework In 2011, the “Privacy framework” (ISO/IEC 29100) (ISO/IEC Information Technology Task Force (ITTF), 2011)from the International Organisation for Standardization (ISO) and the International Electrotechnical Commission (IEC) was published as an international standard. It targets organisations and intends to support them in defining their privacy safe-guarding requirements. Where legal privacy and data protection requirements exist, the standard is to be seen as complementary. It aims at enhancing today’s security standards by the privacy perspective whenever personally identifiable information is processed. The target audience of the framework are mainly organisations as being responsible entities for data processing; in addition, ICT system designers and developers are addressed. Although it was developed within the subcommittee “IT Security techniques” (SC 27), the standard goes

beyond IT security by explicitly linking to ISO/IEC 27000 concepts and demonstrating their correspondences

to each other. The privacy framework comprises a brief description of a common privacy terminology, the

actors and their roles in processing personally identifiable information, privacy safeguarding requirements

and controls, and finally provides references to eleven privacy principles for information technology, which

are:

1. Consent and choice

2. Purpose legitimacy and specification

3. Collection limitation

4. Data minimization

5. Use retention and disclosure limitation

6. Accuracy and quality

7. Openness, transparency and notice

8. Individual participation and access

9. Accountability

10. Information Security

11. Privacy compliance

7.4. EN 14484 - Health informatics - International transfer of personal health data covered by

the EU data protection directive – High-level security policy This standard provides guidance on the High Level Security Policy which should be adopted by third country organisations involved in international informatics applications which entail transmission of person health data from an EU Member State to a non-EU Member State whose data protection is inadequate in the context of the EU Data Protection Directive (Directive 95/46/EC, 1995). Its purpose is to assist in the application of the EU Directive. 13 privacy principles have been identified as a part of this High-Level Security Policy, which are: Its purpose is to assist in the application of the EU Directive. 13 privacy principles have been identified as a part of this High Level Security Policy, which are:

1. Overriding generic principle


71

The HLSP shall make clear, as an overriding generic principle, that the personal health data to which the HLSP applies derives from the EU and that the security to be afforded to that data shall be in accord with that which would apply in the EU. Guidelines:

• fundamental rights and freedoms

• information about doubts

2. Chief executive support The HLSP shall be endorsed by the chief executive of the organization and shall be available on request and free of charge to any data subject or other legitimate enquirer. Guidelines:

• alignment with local practice

• organizational arrangements

• regular HLSP review

3. Documentation of Measures and review The HLSP shall be backed by documented Measures to ensure compliance with the Principles and Guidelines and these shall be reviewed at regular intervals which shall not exceed one year. The documented Measures may usefully take the form of Codes of Practice. Guidelines:

• staff information

4. Data Protection Security Officer A Data Protection Security Officer shall be appointed to ensure, in an independent manner, compliance with the HLSP and the Measures that support it. This principle shall have clear terms of reference and his authority to audit and investigate compliance shall be made clear in Measures. Guidelines:

• Data Protection Security Officer and organization as a processor

• Data Protection Security Officer and organization as a controller

• Data Protection Security Officer qualification for office

5. Permission to process No processing shall be undertaken without assurance that the data subject has consented and only in compliance with such consent. Data concerning different subjects shall be treated independently. Guidelines:

• unambiguous consent to transfer

• explicit consent to processing

• limitation to the purposes consented

• conditional consents

• review of information concerning consent

6. Information about processing Data subjects’ rights to information about processing, to safeguards concerning data quality, to access their data and to object to processing shall be assured in accord with the EU Directive (Articles 6, 10, 11, 12 and 14). Guidelines:

• documentation about consented processing

• quality of data collected and processed

• accuracy of data processed


72

• Data Retention and Destruction Policy

• data subjects’ access to their data

• objection to processing

• rectification, erasure and blocking

• identification of transferred data

• action on notification of the death of a data subject

• direct marketing

• re-personalisation of de-personalised data

7. Information for the data subject The data subject shall be informed of the identity of the third country controller or processor whichever is applicable; the purposes of the processing; the recipients of the data, including any other organization to which his personal health data may, or will be, transferred; his rights to object to processing; the complaints procedure; third party arbitration and investigation arrangements; rights to redress and how to pursue them; any information which may affect a data subject’s consent which might not otherwise be obvious to him. Information provided shall be documented and stored.

8. Prohibition of onward data transfer without consent Transfer of personal health data from the third country organization to another party shall not take place without the EU Controller’s consent and the data subject’s consent unless it is necessary in order to protect the vital interests of the data subject or another person where, and only for so long as, the data subject cannot physically or legally consent. Guidelines:

• assuring protection for onward transfers

• HLSP for onward transfers

• Disclosure Register

9. Remedies and compensation A data subject shall have the right to judicial or other equivalent remedy for any breach of his rights and to compensation for any damage resulting. Guidelines:

• investigation of complaints

• independent arbitration

10. Security of processing Personal health data shall be protected against accidental or unlawful distribution or accidental loss, alteration, and unauthorized disclosure or access. Guidelines:

• risk analysis

• encryption during transmission

• proof of data integrity and authentication of origin

• access control and user authentication

• Physical and Environmental Security

• application management

• network management

• virus controls

• reporting breaches of security

• Business Continuity Plans


73

• audit trails

• handling particularly sensitive data

11. Responsibilities of staff and other contractors All staff and other contractors working for the third country organization and expected to be involved in processing of personal health data transferred from the EU shall be informed of their responsibilities and be capable of exercising them. Guidelines:

• informing staff and other contractors

• instruction and training

• staff and contractor contractual obligations

12. Adequacy of third country data protection Any Measures necessary to ensure adequacy of data protection in the third country in accord with the EU Directive shall be documented and implemented. The grounds for ensuring adequacy of data protection shall be analyzed and appropriate measure put in place.

13. Additional EU Member State particular requirements Measures shall be implemented to take account of any particular requirements of the EU Member State relating to the protection of the personal health data. The third country organization shall enquire of the EU Controller whether any such particular requirements exist and implement Measures accordingly.

7.5. EU General Data Protection Regulation (GDPR) On April 27, 2016, the new data protection principles have been released as a Regulation of the European Parliament and of the Council (Regulation (EU) 2016/679) to regulate the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (Directive 95/46/EC, 1995). It enters into application 25 May 2018 after a two-year transition period and, unlike a Directive it does not require any enabling legislation to be passed by governments (European Parliament & Council, 4/5/2016). The Regulation updates and modernises the principles enshrined in the 1995 Data Protection Directive to guarantee privacy rights. It focuses on: reinforcing individuals' rights, strengthening the EU internal market, ensuring stronger enforcement of the rules, streamlining international transfers of personal data and setting global data protection standards. The reform provides tools for gaining control of one's personal data, the protection of which is a fundamental right in the European Union, by introducing new for the European data protection law principles and ensuring the following (European Commission, 2017):

• A "right to be forgotten": When an individual no longer wants her/his data to be processed, and provided that there are no legitimate grounds for retaining it, the data will be deleted.

• Easier access to one's data: Individuals will have more information on how their data is processed and this information should be available in a clear and understandable way. A right to data portability will make it easier for individuals to transmit personal data between service providers.

• Breach notification: Companies and organisations must notify the national supervisory authority of data breaches which put individuals at risk and communicate to the data subject all high risk breaches as soon as possible so that users can take appropriate measures.

• Data protection by design and by default: ‘Data protection by design’ and ‘Data protection by default’ are now essential elements in EU data protection rules. Data protection safeguards will


74

be built into products and services from the earliest stage of development, and privacy-friendly default settings will be the norm – for example on social networks or mobile apps.

• Stronger enforcement of the rules: data protection authorities will be able to fine companies who do not comply with EU rules up to 4% of their global annual turnover.

7.6. US Health Insurance Portability and Accountability Act (HIPAA) The Health Insurance Portability and Accountability Act of 1996 (HIPAA) required the Secretary of the U.S.

Department of Health and Human Services (HHS) to develop regulations protecting the privacy and security

of certain health information. To fulfil this requirement, HHS published what are commonly known as the

HIPAA Privacy Rule and the HIPAA Security Rule. The Privacy Rule, or Standards for Privacy of Individually

Identifiable Health Information, establishes national standards for the protection of certain health

information. The Security Standards for the Protection of Electronic Protected Health Information (the

Security Rule) establish a national set of security standards for protecting certain health information that is

held or transferred in electronic form.

Prior to HIPAA, no generally accepted set of security standards or general requirements for protecting health

information existed in the health care industry. At the same time, new technologies were evolving, and the

health care industry began to move away from paper processes and rely more heavily on the use of electronic

information systems to pay claims, answer eligibility questions, provide health information and conduct a

host of other administrative and clinically based functions. Today, providers are using clinical applications,

health plans are providing access to claims and care management, as well as member self-service

applications. While this means that the medical workforce can be more mobile and efficient, the rise in the

adoption rate of these technologies increases the potential security risks.

A major goal of the Security Rule is to protect the privacy of individuals’ health information while allowing

covered entities to adopt new technologies to improve the quality and efficiency of patient care. Given that

the health care marketplace is diverse, the Security Rule is designed to be flexible and scalable, so a covered

entity can implement policies, procedures, and technologies that are appropriate for the entity’s particular

size, organizational structure, and risks to consumers’ electronic protected health information.

The Privacy Rule standards address the use and disclosure of individuals’ health information —called

“protected health information” by organizations subject to the Privacy Rule —called “covered entities,” as

well as standards for individuals' privacy rights to understand and control how their health information is

used. Within HHS, the Office for Civil Rights (“OCR”) has responsibility for implementing and enforcing the

Privacy Rule with respect to voluntary compliance activities and civil money penalties.

A major goal of the Privacy Rule is to assure that individuals’ health information is properly protected while

allowing the flow of health information needed to provide and promote high quality health care and to

protect the public's health and well-being. The Rule strikes a balance that permits important uses of

information, while protecting the privacy of people who seek care and healing. Given that the health care

marketplace is diverse, the Rule is designed to be flexible and comprehensive to cover the variety of uses and

disclosures that need to be addressed.

7.6.1. HIPAA Privacy Rule Principles:

• Basic Principle: A covered entity may not use or disclose protected health information, except either:

(1) as the Privacy Rule permits or requires; or (2) as the individual who is the subject of the

information (or the individual’s personal representative) authorizes in writing.

• Required Disclosures. A covered entity must disclose protected health information in only two

situations: (a) to individuals (or their personal representatives) specifically when they request access


75

to, or an accounting of disclosures of, their protected health information; and (b) to HHS when it is

undertaking a compliance investigation or review or enforcement action.

• Permitted Uses and Disclosures: A covered entity is permitted, but not required, to use and disclose

protected health information, without an individual’s authorization, for the following purposes or

situations: (1) To the Individual (unless required for access or accounting of disclosures); (2)

Treatment, Payment, and Health Care Operations; (3) Opportunity to Agree or Object; (4) Incident to

an otherwise permitted use and disclosure; (5) Public Interest and Benefit Activities; and (6) Limited

Data Set for the purposes of research, public health or health care operations. Covered entities may

rely on professional ethics and best judgments in deciding which of these permissive uses and

disclosures to make.

o To the Individual. A covered entity may disclose protected health information to the

individual who is the subject of the information

o Treatment, Payment, Health Care Operations. A covered entity may use and disclose

protected health information for its own treatment, payment, and health care operations

activities. Obtaining “consent” (written permission from individuals to use and disclose their

protected health information for treatment, payment, and health care operations) is

optional under the Privacy Rule for all covered entities.

o Uses and Disclosures with Opportunity to Agree or Object. Informal permission may be

obtained by asking the individual outright, or by circumstances that clearly give the individual

the opportunity to agree, acquiesce, or object. Where the individual is incapacitated, in an

emergency situation, or not available, covered entities generally may make such uses and

disclosures, if in the exercise of their professional judgment, the use or disclosure is

determined to be in the best interests of the individual.

o Incidental Use and Disclosure. The Privacy Rule does not require that every risk of an

incidental use or disclosure of protected health information be eliminated. A use or

disclosure of this information that occurs as a result of, or as “incident to,” an otherwise

permitted use or disclosure is permitted as long as the covered entity has adopted

reasonable safeguards as required by the Privacy Rule, and the information being shared was

limited to the “minimum necessary,” as required by the Privacy Rule.

o Public Interest and Benefit Activities. The Privacy Rule permits use and disclosure of

protected health information, without an individual’s authorization or permission, for 12

national priority purposes:

As required by law (including by statute, regulation, or court orders)

Public Health Activities

To support inquires regarding victims of abuse, neglect, or domestic violence

Health oversight activities, such as audits and investigations necessary for oversight

of the health care system and government benefit programs

To support Judicial and Administrative Proceedings

Law Enforcement Purposes

to identify a deceased person, determine the cause of death, and perform other functions authorized by law

to facilitate the donation and transplantation of cadaveric organs, eyes, and tissue research purposes when approved by Privacy Board, and necessary documentation

from the researchers have been collected. A covered entity also may use or disclose, without an individuals’ authorization, a limited data set of protected health information for research purposes


76

to prevent or lessen a serious and imminent threat to a person or the public to enable essential government functions identified in Privacy Rule to comply with, workers’ compensation laws and other similar programs providing

benefits for work-related injuries or illnesses o Limited Data Set: A limited data set is protected health information from which certain

specified direct identifiers of individuals and their relatives, household members, and employers have been removed. A limited data set may be used and disclosed for research, health care operations, and public health purposes, provided the recipient enters into a data use agreement promising specified safeguards for the protected health information within the limited data set

• Authorization: A covered entity must obtain the individual’s written authorization for any use or disclosure of protected health information that is not for treatment, payment or health care operations or otherwise permitted or required by the Privacy Rule.

• Minimum Necessary: A central aspect of the Privacy Rule is the principle of “minimum necessary” use and disclosure. A covered entity must make reasonable efforts to use, disclose, and request only the minimum amount of protected health information needed to accomplish the intended purpose of the use, disclosure, or request.

• Privacy Practices Notice: Each covered entity, with certain exceptions, must provide a notice of its

privacy practices. The notice must describe the ways in which the covered entity may use and disclose

protected health information. Individuals have the right to review and obtain a copy of their

protected health information in a covered entity’s designated record set; to have covered entities

amend their protected health information in a designated record set when that information is

inaccurate or incomplete, to an accounting of the disclosures of their protected health information

by a covered entity or the covered entity’s business associates, to request that a covered entity

restrict use or disclosure of protected health information for treatment, payment or health care

operations, disclosure to persons involved in the individual’s health care or payment for health care,

or disclosure to notify family members or others about the individual’s general condition, location,

or death.

• Mitigation: A covered entity must mitigate, to the extent practicable, any harmful effect it learns was caused by use or disclosure of protected health information by its workforce or its business associates in violation of its privacy policies and procedures or the Privacy Rule

• Data Safeguards: A covered entity must maintain reasonable and appropriate administrative, technical, and physical safeguards to prevent intentional or unintentional use or disclosure of protected health information in violation of the Privacy Rule and to limit its incidental use and disclosure pursuant to otherwise permitted or required use or disclosure.

• Complaints: A covered entity must have procedures for individuals to complain about its compliance with its privacy policies and procedures and the Privacy Rule.

• Documentation and Record Retention: A covered entity must maintain, until six years after the later of the date of their creation or last effective date, its privacy policies and procedures, its privacy practices notices, disposition of complaints, and other actions, activities, and designations that the Privacy Rule requires to be documented.

• Compliance: Covered entities need to provide records and compliance reports and to cooperate with, and permit access to information for, investigations and compliance reviews.

7.6.2. HIPAA Privacy Rule Principles:

• General Rule: Covered entities must: Ensure the confidentiality, integrity, and availability of all ePHI they create, receive, maintain or transmit; Identify and protect against reasonably anticipated


77

threats to the security or integrity of the information; Protect against reasonably anticipated, impermissible uses or disclosures; and ensure compliance by their workforce.

• Risk Analysis and Management: Security Rule require covered entities to perform risk analysis as part of their security management processes. A risk analysis process includes, but is not limited to, the following activities: Evaluate the likelihood and impact of potential risks to ePHI; Implement appropriate security measures to address the risks identified in the risk analysis; Document the chosen security measures and, where required, the rationale for adopting those measures; and Maintain continuous, reasonable, and appropriate security protections.

• Information Access Management (Administrative Safeguards). Consistent with the Privacy Rule standard limiting uses and disclosures of PHI to the "minimum necessary," the Security Rule requires a covered entity to implement policies and procedures for authorizing access to ePHI only when such access is appropriate based on the user or recipient's role (role based access).

• Facility Access and Control (Physical Safeguards): A covered entity must limit physical access to its facilities while ensuring that authorized access is allowed

• Workstation and Device Security (Physical Safeguards): A covered entity must implement policies and procedures to specify proper use of and access to workstations and electronic media.

• Access Control (Technical Safeguards): A covered entity must implement technical policies and procedures that allow only authorized persons to access electronic protected health information (ePHI).

• Audit Controls (Technical Safeguards): A covered entity must implement hardware, software, and/or procedural mechanisms to record and examine access and other activity in information systems that contain or use ePHI.

• Integrity Controls (Technical Safeguards): A covered entity must implement policies and procedures to ensure that ePHI is not improperly altered or destroyed. Electronic measures must be put in place to confirm that ePHI has not been improperly altered or destroyed.

• Transmission Security (Technical Safeguards):A covered entity must implement technical security measures that guard against unauthorized access to ePHI that is being transmitted over an electronic network

7.7. EU/US Privacy Shield The European Union (EU) and the United States (U.S.) have strong commercial ties. Moreover, they both aim

to improve privacy protection while transferring personal data but with different approaches. For such

transactions from EU to U.S., ensuring that EU data subjects continue to benefit from effective safeguards

and protection as required by European legislation with respect to the processing of their personal data when

they have been transferred to non-EU countries is a must. For this reason, the EU-U.S. Privacy Shield came

to existence. It processes personal data according to a strong set of data protection rules and safeguards.

The protection applies regardless of whether subjects are EU citizen or not.

The Privacy Shield is particularly formed for only the use by organizations in the U.S. receiving personal data

from the EU. Such organizations can rely on the Privacy Shield by self-certification. They are obligated to

apply some principles to all personal data transferred in reliance on the Privacy Shield. Privacy Shield's

principles were developed in consultation with the European Commission to facilitate trade and commerce

between the U.S. and EU. Those principles are explained briefly in the following section.

Principles

1. Notice

A Privacy Shield organization must inform individuals about:


78

• its participation in the Privacy Shield by Privacy Shield List,

• its commitment to the Principles of the Privacy Shield,

• the types of personal data being processed,

• the purposes for which it processes personal information about them,

• how to contact the organization with any complaints,

• the identity of third parties to which it discloses personal data, and its liability besides the purposes,

• the right of individuals to access their personal data,

• the requirement to disclose personal information to public authorities due to lawful requests,

• the independent dispute resolution body, either in the EU or the U.S., where individuals can bring their cases, and

• the government agency in the U.S. that is responsible to investigate and enforce the organization’s obligations under the framework.

Moreover, this notice must be provided in clear language when individuals are first asked to provide personal

information to the organization.

2. Choice

An organization must offer individuals the opportunity to choose whether their personal information is to be

disclosed to a third party. Also, if an organization wants to use individuals' personal data for purposes that

are different from purposes when such data is originally acquired; individuals must be provided with clear

and readily available mechanisms to make choice.

Organizations should also treat as sensitive to any personal data coming from a third party that is declared

as sensitive. For any sensitive information, organizations must obtain consent from individuals as

aforementioned.

3. Accountability for Onward Transfer

To transfer personal information to a third party acting as a controller, organizations must comply with the

Notice and Choice Principles and must enter into a contract with the third-party controller. The contract must

ensure that transferred data may only be processed for purposes consistent with the consent provided by

the individual. On the other hand, the recipient must obey the Principles as well. Also, if recipient determines

that it can no longer meet the obligation to provide the same level of protection, it should notify the

organization.

4. Security

Organizations creating, maintaining, using or disseminating personal information must ensure that such data

are kept in a safe environment and secured against loss, misuse, unauthorized access, disclosure, alteration

or destruction. They should take the risks involved in the processing and the nature of the personal data into

account.

5. Data Integrity and Purpose Limitation

Depending on the circumstances, personal information may be transferred to a third party providing

consistency with the Principles. In this case, data must be limited to the information that is relevant for the

purposes of processing. To the extent necessary for those purposes, an organization must take reasonable

steps to ensure that personal data is reliable for its intended use, accurate, complete, and current.

Information may be hold in a form identifying the individual only for as long as it serves a purpose of

processing as mentioned.


79

6. Access

Individuals must have access to their personal information that an organization has. They have a right to get

information about the purpose for which the data are processed, the categories of personal data concerned

and the recipients to whom the data are disclosed. Moreover, they should be able to correct, change, or

delete that information where it is inaccurate, or has been processed in violation of the Principles.

An organization has to respond to individual's access request within a reasonable time frame. However,

sometimes it may be able to limit access rights, but only in specific situations such as when providing access

would undermine confidentiality, breach professional privilege or conflict with legal obligations.

7. Recourse, Enforcement and Liability

If the organization does not follow the rules of the Privacy Shield and violates its obligation to protect

personal information, individuals have the right to complain and obtain a remedy, free of any cost.

Organizations under the Privacy Shield are obliged to provide a readily available independent recourse

mechanism to investigate unresolved complaints. Inquiries and requests made by the Department for

information relating to the Privacy Shield must be responded promptly. Organizations must also respond

directly to authorities with regard to the investigation and resolution of complaints.

In the context of an onward transfer, a Privacy Shield organization has responsibility for the processing of

personal information it receives under the Privacy Shield and subsequently transfers to a third party acting

as an agent on its behalf. The Privacy Shield organization shall remain liable under the Principles if its agent

processes such personal information in a manner inconsistent with the Principles, unless the organization

proves that it is not responsible for the event giving rise to the damage.

8. References (n.d.). Retrieved from eIDAS-Node integration package:

https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eIDAS+Node+integration+package

(2016, December 16). Retrieved from eIDAS eID Profile Technical Specification:

https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eIDAS+Profile

Article 29 Working Party. (2016, November 22). Retrieved from http://ec.europa.eu/newsroom/just/item-

detail.cfm?item_id=50083

CNIL. (2015, June). Privacy Impact Assesment Methodology. Retrieved from

http://www.cnil.fr/fileadmin/documents/en/CNIL-PIA-1-Methodology.pdf

Deloitte. (2016, December). Retrieved from The use of CEF eID in the CEF eHealth DSI.

Directive 2011/24/EU. (2011, March 09). Directive 2011/24/EU of the European Parliament and of the

Council of 9 March 2011 on the application of patients’ rights in cross-border healthcare. Retrieved

from https://publications.europa.eu/en/publication-detail/-/publication/377ab800-836b-4fde-85ff-

2e4aac7dee94/language-en

Directive 95/46/EC. (1995, November 23). Directive 95/46/EC of the European Parliament and of the Council

of 24 October 1995 on the protection of individuals with regard to the processing of personal data

and on the free movement of such data. Retrieved from http://eur-

lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:en:HTML


80

eHDSI. (2017, June 01). Retrieved from eHealth DSI OpenNCP Implementation:

https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/openNCP+Implementation

eHDSI. (2017, June 01). Retrieved from eHealth DSI SAML Profile:

https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/SAML+Profile

eHDSI. (2017, June 01). eHealth DSI Identity Management Specification. Retrieved from

https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/Identity+Management+Specification

eHDSI. (2017, June 01). eHealth DSI Security Services Specification. Retrieved from

https://ec.europa.eu/cefdigital/wiki/download/attachments/37752830/Security%20Services%20Sp

ecification_v2.1.0.doc?version=1&modificationDate=1496299722709&api=v2

eHealth DSI. (2018, January 26). eHealth DSI Audit Framework. Retrieved from

https://ec.europa.eu/cefdigital/wiki/x/vxlAAg

eHealth Member State Expert Group (eHMSEG). (2017, March 6). Retrieved from CEF eID SMO- The use of

eID in eHealth:

https://ec.europa.eu/cefdigital/wiki/download/attachments/40047694/DG%20DIGIT%20-

%20CEF%20eID%20SMO%20-%20The%20use%20of%20eID%20in%20eHealth%20%20020317.pptx

ENISA. (2015, January 12). Privacy and Data Protection by Design- from Policy to Engineering. Retrieved

from https://www.enisa.europa.eu/publications/privacy-and-data-protection-by-

design/at_download/fullReport

epSOS Consortium. (2010). D.3.7.2. FINAL SECURITY SERVICES SPECIFICATION DEFINITION.

EU 910/2014. (2014, July 23). Retrieved from Regulation (EU) No 910/2014 of the European Parliament and

of the Council of 23 July 2014 on electronic identification and trust services for electronic

transactions in the internal market and repealing Directive 1999/93/EC: http://eur-

lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2014.257.01.0073.01.ENG

European Commission. (2017, May 24). Fact Sheet. Questions and Answers - Data protection reform.

Retrieved from ec.europa.eu/justice/data-protection/

European Commission. (July 2016). EU-US Privacy Shield Factsheet.

European Parliament & Council. (4/5/2016). Regulation on the protection of natural persons with regard to

the processing of personal data and on the free movement of such data, and repealing Directive

95/46/EC (General Data Protection Regulation). L119, 1-88.

EU-U.S. Privacy Shield Principles and Annex I. (2016, May). Retrieved from Privacy Shield Framework:

https://www.privacyshield.gov/Privacy-Shield-Principles-Full-Text

HEART WG. (2017). Health Relationship Trust (HEART) Working Group. Retrieved from

https://openid.net/wg/heart/

HHS. (1996). Health Insurance Portability and Accountability Act of 1996. Retrieved from Health

Information Privacy.

HL7 FHIR Release 3. (2017). FHIR Security. Retrieved from https://www.hl7.org/fhir/security.html


81

Hoepman, J.-H. ( 2014). Privacy design strategies – (extended abstract). In ICT Systems Security and Privacy

Protection - 29th IFIP TC 11 International Conference, SEC 2014, (pp. 446–459). Marrakech,

Morocco.

IHE IT Infrastructure Technical Committee. (2014, June 6). IHE IT Infrastructure De-Identification. Retrieved

from https://wiki.ihe.net/index.php/Healthcare_De-Identification_Handbook

ISO/IEC 29100:2011. (2011). ISO/IEC 29100:2011 Information technology - Security techniques - Privacy

framework. Retrieved from https://www.iso.org/standard/45123.html

ISO/IEC Information Technology Task Force (ITTF). (2011, 12). ISO/IEC 29100:2011 Information technology --

Security techniques -- Privacy framework. Retrieved from

https://www.iso.org/standard/45123.html

ISO/TC 215 Health informatics. (2017, January). ISO 25237:2017 Health informatics -- Pseudonymization.

Joint NEMA/COCIR/JIRA Security and Privacy Committee (SPC). (2004). Break-Glass – An Approach to

Granting Emergency Access to Healthcare Systems.

OASIS PMRM TC. (2016, May 17). OASIS Privacy Management Reference Model (PMRM) Version 1.0.

Retrieved from OASIS Privacy Management Reference Model (PMRM): http://docs.oasis-

open.org/pmrm/PMRM/v1.0/cs02/PMRM-v1.0-cs02.html

OASIS XACML TC. (2017, July 12). OASIS extensible Access Control Markup Language (XACML) . Retrieved

from https://www.oasis-open.org/committees/xacml/

OAuth 2.0. (2018). Retrieved from https://oauth.net/2/

Open ID Connect. (2018). Retrieved from http://openid.net/connect/

PRIPARE Consortium. (2015, September 30). PReparing Industry to Privacy-by-design by supporting its

Application in REsearch. Retrieved from PReparing Industry to Privacy-by-design by supporting its

Application in REsearch: http://pripareproject.eu

PRIPARE Privacy- and Security-by-design Methodology Handbook. (2016, February 24). Retrieved from

PRIPARE: http://pripareproject.eu/wp-content/uploads/2013/11/PRIPARE-Methodology-

Handbook-Final-Feb-24-2016.pdf

Sabo, J. T. (2007). ISTPA Operational Analysis of International Privacy Requirements. ISSE/SECURE 2007

Securing Electronic Business Processes , (pp. 18-25).

Simone Fischer-Hübner, J. A. (2014). How can Cloud Users be Supported in Deciding on, Tracking and

Controlling How their Data are Used? Privacy and Identity Manage-ment for Emerging Services and

Technologies, 77-92.

Simone Fischer-Hübner, J. S.-s. (2007). Digital Privacy: Theory, Technologies and Practices, . HCI Designs for

Privacy-enhancing Identity Management, 230–252.

SMART Health IT 2017. (n.d.). SMART App Authorization Guide. Retrieved from

http://docs.smarthealthit.org/authorization/

Trillium II Consortium. (2018). Deliverable 3.1: Use case selection and analysis of patient summary use cases

beyond emergency or unplanned care. 31: January .


82

W3C Hypertext Transfer Protocol -- HTTP/1.1. (2016). HTTP Security Considerations, Hypertext Transfer

Protocol -- HTTP/1.1. Retrieved from https://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html

TRILLIUM II

Documents

Transcript of TRILLIUM II