PharmaLedger Ethical and Legal Inventory

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 853992
Copyright © PharmaLedger Consortium 2020 – 2023 PharmaLedger contact@pharmaledger.eu
D5.1 PharmaLedger Ethical and Legal Inventory
Deliverable No D5.1
Work package No. and Title WP5 Regulatory, Legal & Data Privacy Framework
Version - Status V1.0 – final
Date of Issue 30/09/2020
Dissemination Level PUBLIC
Filename D5.1 PharmaLedger Ethical and Legal Inventory_v1.0_draft
Ref. Ares(2020)5142012 - 30/09/2020

PharmaLedger – 853992 | Deliverable D5.1 v1.0 | PUBLIC 2/98
DOCUMENT INFO
Authors
Author Organization
Nenad GEORGIEV KU Leuven (KUL)
Daphné VAN DER EYCKEN KU Leuven (KUL)
Sofie Inari CASTELLA Novo Nordisk (NOVO)
Henrik Kim NIELSEN Novo Nordisk (NOVO)
Scott ASKIN Novartis Pharma AG (NVS)
Ingrid KLINGMANN European Forum for Good Clinical Practice (EFGCP)
Michael SIMON Boehringer Ingelheim (BI)
Elisabetta BIASIN KU Leuven (KUL)
Anton VEDDER KU Leuven (KUL)
Michael SAMMETH University Hospital Würzburg (UKW)
Document History
Date Version Editor Change Status
27/01/2020 0.1 Nenad Georgiev, Elisabetta Biasin Table of contents Draft
13/04/2020 0.2 Nenad Georgiev Initial content Draft
20/07/2020 0.3
Nenad Georgiev, Daphné Van der
Eycken, Henrik K Nielsen, Ingrid
Klingmann, Scott Askin, Michael
Simon, Michael Sammeth
Continuous input in
sections
Draft
04/09/2020 0.4 Nenad Georgiev Complete draft for review Draft
08/09/2020 0.5 Elisabetta Biasin Internal review Draft
12/09/2020 0.6 Anton Vedder Internal review Draft
25/09/2020 0.7 Jackie Purdie Quality review Draft
30/09/2020 1.0 Nenad Georgiev Final adaptations Final
30/09/2020 1.0 Cecilia Vera/Maria Eugenia Beltran Final review/submission Final

TABLE OF CONTENTS
TABLE OF CONTENTS.....................................................................................................................................3
LIST OF FIGURES............................................................................................................................................6
LIST OF TABLES..............................................................................................................................................6
ACRONYMS ...................................................................................................................................................7
EXECUTIVE SUMMARY..................................................................................................................................9
1. Introduction........................................................................................................................................10
1.1 Purpose and scope......................................................................................................................10
1.2 Structure .....................................................................................................................................10
2. Privacy and Data Protection ..............................................................................................................11
2.1 Legal framework .........................................................................................................................12
2.1.1 European Convention on Human Rights.............................................................................12
2.1.2 Council of Europe Convention 108 .....................................................................................13
2.1.3 Council of Europe Recommendation on the protection of health-related data ................14
2.1.4 Charter of Fundamental Rights...........................................................................................15
2.1.5 OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data..16
2.1.6 Directive 2002/58 on privacy and electronic communications (e-Privacy Directive).........17
2.1.7 General Data Protection Regulation (GDPR) ......................................................................18
2.2 Processing of personal data on a blockchain..............................................................................19
2.2.1 Public keys and hashed content data .................................................................................21
2.2.2 Decentralized Identifiers (DIDs) and Verifiable Credentials ...............................................22
2.2.3 Special categories of data...................................................................................................23
2.3 Determining the controller and processor in a blockchain system............................................24
2.3.1 Controller............................................................................................................................24
2.3.2 Data processor....................................................................................................................26
2.4 Privacy and data protection principles .......................................................................................29
2.4.1 Lawfulness, fairness, and transparency..............................................................................29
2.4.2 Purpose limitation...............................................................................................................30
2.4.3 Data minimisation...............................................................................................................30
2.4.4 Data accuracy......................................................................................................................30
2.4.5 Finality (storage limitation).................................................................................................31
2.4.6 Data security (integrity and confidentiality).......................................................................31
2.4.7 Accountability .....................................................................................................................31
2.5 Lawful grounds for processing personal data.............................................................................32
2.5.1 Consent ...............................................................................................................................32
2.5.2 Contract...............................................................................................................................34

2.5.3 Legal obligation...................................................................................................................34
2.5.4 Vital interests......................................................................................................................35
2.5.5 Public task ...........................................................................................................................35
2.5.6 Legitimate interests ............................................................................................................35
2.5.7 Processing of special categories of data.............................................................................35
2.6 Rights of data subjects................................................................................................................36
2.6.1 Right to be informed...........................................................................................................37
2.6.2 Right to access ....................................................................................................................39
2.6.3 Right to rectification ...........................................................................................................40
2.6.4 Right to erasure...................................................................................................................40
2.6.5 Right to restrict processing.................................................................................................42
2.6.6 Right to object.....................................................................................................................42
2.6.7 Right to withdraw consent..................................................................................................43
2.6.8 Right to data portability......................................................................................................43
2.6.9 Right not to be subject to automated individual decision-making.....................................43
2.6.10 Right to file a complaint with a supervisory authority........................................................43
2.7 Reviewing a data subject’s request ............................................................................................45
2.7.1 Identity check......................................................................................................................45
2.7.2 Refusal to act ......................................................................................................................45
2.7.3 Timing..................................................................................................................................45
2.8 Transfers of personal data outside the EU/EEA..........................................................................46
2.8.1 Transfers on the basis of an adequacy decision .................................................................46
2.8.2 Transfers covered by appropriate safeguards....................................................................47
2.8.3 Transfers covered by an exception.....................................................................................48
2.9 Data protection by design and by default ..................................................................................49
2.9.1 Proposed methodology.......................................................................................................49
3. Clinical Trials.......................................................................................................................................53
3.1 Legal framework .........................................................................................................................54
3.1.1 Declaration of Helsinki........................................................................................................54
3.1.2 Declaration of Taipei...........................................................................................................55
3.1.3 Directive 2001/20 (Clinical Trials Directive)........................................................................56
3.1.4 Directive 2005/28 (Good Clinical Practice Directive)..........................................................57
3.1.5 Regulation 536/2014 (Clinical Trials Regulation)................................................................58
3.1.6 Directive 2011/24 on the application of patients’ rights in cross-border healthcare ........59
3.1.7 Directive 93/42/EEC concerning medical devices (Medical Device Directive) ...................60
3.1.8 ICH Guideline for Good Clinical Practice (E6)......................................................................61

3.1.9 ICH guidelines for safety reporting in clinical trials (E2A and E2B).....................................62
3.2 Key aspects..................................................................................................................................63
3.2.1 Prior authorisation and ethical reviews..............................................................................63
3.2.2 Data access and retention ..................................................................................................64
3.2.3 Transparency rules..............................................................................................................65
3.2.4 Patients’ protection ............................................................................................................66
3.2.5 Informed consent requirements.........................................................................................67
4. Pharmaceutics Supply Chain..............................................................................................................69
4.1 Legal framework .........................................................................................................................71
4.1.1 Directive 2001/83 on the Community code for medicinal products for human use..........71
4.1.2 Directive 2003/94 on the principles and guidelines of good manufacturing practice .......72
4.1.3 Directive 2011/62 on falsified medicines (Falsified Medicines Directive)..........................73
4.1.4 Convention on the counterfeiting of medical products (the MEDICRIME Convention).....74
4.1.5 Regulation 2016/161 on safety features ............................................................................75
4.1.6 Regulation 2020/1056 on electronic freight transport information ..................................76
4.1.7 Regulation 726/2004 on authorisation procedures and establishing EMA........................77
4.2 Key aspects..................................................................................................................................78
4.2.1 Market authorisation procedure ........................................................................................78
4.2.2 Market authorisation requirements...................................................................................79
4.2.3 Good manufacturing practice.............................................................................................79
4.2.4 Good distribution practice..................................................................................................81
4.2.5 Outer and immediate packaging.........................................................................................83
4.2.5.1 Labelling..............................................................................................................................83
4.2.5.2 Package leaflet....................................................................................................................85
4.2.5.3 Key principles for electronic product information (ePI) .....................................................86
4.2.6 Safety features....................................................................................................................88
4.2.6.1 Unique identifiers ...............................................................................................................88
4.2.6.2 Anti-tampering device ........................................................................................................89
4.2.6.3 Verification process ............................................................................................................89
4.2.7 Reporting of falsified medicines .........................................................................................90
4.2.8 Detection and notification of medicine shortages .............................................................91
5. Conclusion ..........................................................................................................................................92
GLOSSARY ...................................................................................................................................................93
BIBLIOGRAPHY ............................................................................................................................................95

LIST OF FIGURES
Figure 1: Decision tree to determine if a piece of information is personal data.......................................19
Figure 2: Decision tree to identify the controller(s) and processor(s) for a data processing activity ……. 27
Figure 3: Lawfulness of data processing after consent withdrawal ……………………………………………………… 32
Figure 4: Possible outcomes of an alleged GDPR infringement ……………………………………………………………. 43
Figure 5: Key activities to ensure Data Protection by Design and by Default ……………………………………….. 49
Figure 6: Market authorisation procedure ………………………………………………………………………………………….. 78
LIST OF TABLES
Table 1: Information to be provided to data subjects when data are collected directly or indirectly......37
Table 2: Information in a clinical trial application form to regulators and an ethics committee ……………. 62

ACRONYMS
ADR Adverse drug reaction
ATD Anti-tampering device
CFR Charter of Fundamental Rights of the European Union
CJEU Court of Justice of the European Union
CoE Council of Europe
CTIS Clinical Trial Information System
DID Decentralized identifier
DLT Distributed ledger technology
DPA Data Protection Authority
DPbDD Data Protection by Design and by Default
DPD Data Protection Directive
DPIA Data Protection Impact Assessment
DPO Data Protection Officer
DRA Domain reference application
EC European Commission
ECHR European Convention on Human Rights
ECtHR European Court of Human Rights
EDPB European Data Protection Board
EEA European Economic Area
EFPIA European Federation of Pharmaceutical Industries and Associations
EHR Electronic health record
EMA European Medicines Agency
EMVO European Medicines Verification Organization
ePI Electronic product information
EU European Union
GCP Good clinical practice

GDP Good distribution practice
GDPR General Data Protection Regulation
GMP Good Manufacturing Practice
HA Health authority
HCP Healthcare professional
HMA Heads of Medicines Agencies
ICH International Council for Harmonisation
ICMJE International Committee of Medical Journal Editors
ICT Information communication technology
IMI Innovative Medicines Initiative
IMPD Investigational Medicinal Product Dossier
IP Internet Protocol
ISO International Organization for Standardization
ISO International Standards Organization
NMVO National Medicines Verification Organization
NMVS National Medicines Verification System
OECD Organisation for Economic Co-operation and Development
PI Product information
QR Quick Response code
RMP Risk Management Plan
UI Unique identifier
UK United Kingdom
UN United Nations
WHO World Health Organization
WMA World Medical Association
WP Work Package
WP29 Article 29 Working Party

EXECUTIVE SUMMARY
The D5.1 PharmaLedger Ethical and Legal Inventory deliverable sets up the legal framework for the
PharmaLedger project and presents the legal and ethical requirements to be applied in the design and
execution of the platform. This document serves as a background for WP5 to perform the upcoming
detailed ethical and legal study following the terms and conditions from the Grant Agreement.
As the goal of the PharmaLedger project is to provide a widely trusted platform that supports the design
and adoption of blockchain-enabled healthcare solutions while accelerating the delivery of innovation
that benefits the entire ecosystem, from manufacturers to patients, the project is operating in saturated
and highly regulated markets. Therefore, it is critical to identify the legal challenges in the early stage of
designing the platform. To that end, this document serves two purposes: i) setting up the legal and ethical
framework that applies to PharmaLedger and identifying the legal and ethical requirements for which
compliance is mandatory; ii) raising awareness, especially about key standing items on every IT
developer’s risk agenda – privacy and data security.
This document is organised across three key themes: privacy and data protection, clinical trials, and the
pharmaceutical supply chain. It provides high-level guidance on ethics and the laws and regulations on
privacy, data protection, security, confidentiality, clinical trials, drug development, manufacturing, and
distribution. As PharmaLedger is sponsored by the Innovative Medicines Initiative (IMI) and the European
Federation of Pharmaceutical Industries and Associations (EFPIA) under the European Union’s Horizon
2020 programme, the legal framework in this deliverable is limited to the laws, regulations, and other
normative acts applicable on the EU/EEA territory. Compliance issues must always be considered on a
country-by-country basis due to many aspects being regulated only at the national level – an analysis that
requires extensive knowledge of the specific country’s legislative processes and the official language of
that country. Therefore, this document should by no means be interpreted as an exhaustive elaboration
of the applicable regulatory and legal requirements.

1. Introduction
1.1 Purpose and scope
PharmaLedger aims to create an innovative blockchain-based platform that will be validated through a
set of use cases in three domain reference applications (DRAs): health data, supply chain, and clinical
trials. The overall aim of each DRA is to help bring value and trust to unlock the potential of the digital
healthcare ecosystem by building a privacy-enabled foundation using blockchain technology.
As governments and legislators are still increasing their understanding of blockchain technology and
assessing whether certain laws should be amended to address decentralisation, blockchain operators and
participants may be exposed to legal and regulatory uncertainty. Many of the laws were written decades
ago when distributed ledger technologies like blockchain did not exist. This makes compliance with these
laws unpredictable and often challenging.
The purpose of this document is therefore to inform and guide participants of the PharmaLedger platform
of their legal obligations concerning the positive international and EU norms on privacy and data
protection, clinical trials, and pharmaceutics supply chain. Moreover, this legal and ethical inventory is
should guide the architects and developers of the PharmaLedger platform, who are creating the technical
and functional specifications of the use cases, so they take into consideration the moral principles and
legal requirements at the early stages of the platform design. A lot of ethics, especially in the context of
clinical trials, is embodied in the legislative frameworks discussed in this deliverable, and ethics are used
for the interpretation and application of the laws involved to technological innovations and the
transformations they cause in their socio-economic context and human practices. The analysis of the
specific PharmaLedger use cases in the context of the normative acts elaborated in this document relies
on facts and circumstances, including the technical architecture and governance model of the
PharmaLedger platform. As some of these details are still under development, the scope of this analysis
is limited to how the PharmaLedger platform is intended to be designed as of the date of this document.
1.2 Structure
The legal and ethical analysis in this document is performed within three main chapters: Privacy and Data
Protection, Clinical Trials, and Pharmaceutics Supply Chain. Each chapter lays down the legal framework
comprising the principal normative acts relevant to the theme of the chapter and summarises every act,
explaining the subject matter, the material and territorial scope, and its relevance to PharmaLedger. Key
features of the normative acts are then extracted and elaborated in more detail in the subsections
following the legal framework.
Chapter 1 covers the principal theme of privacy and data protection critical to the health data marketplace
domain, but also the clinical trials and supply chain domains. As data is key to generate value and evidence
to the healthcare system, gaining access and storing data on the PharmaLedger platform within the three
reference domains must follow the privacy and data protection principles and standards explained in
detail in this section. Chapter 2 provides an overview of the highly regulated environment of clinical trials
and offers guidance on the transparency rules, informed consent requirements, data access limitations,
and on the legally binding procedure for authorisation and ethical review of a clinical study. Chapter 3
deals with the European regulatory requirements addressed at stakeholders involved in the medical
supply chain such as pharmaceutical manufacturers, distributors and dispensers. The chapter discusses in
detail the rules on market authorisation, good manufacturing and distribution practices, labelling,
package leaflet and electronic product information, as well as the measures the EU has taken to combat
counterfeiting of medicinal products. Chapter 4 presents the concluding remarks.

2. Privacy and Data Protection
Privacy and data protection are two interrelated yet distinct concepts. Privacy is usually defined as the
right of any individual for private and family life, home and correspondence, whereas data protection is a
system of data processing practices for protecting privacy. Another term that is often used
interchangeably with privacy is confidentiality, which should be understood as the legal and ethical duty
to keep information secret.
Data protection and privacy law regulate almost all stages in the processing of specific types of data by
addressing how data is collected, stored, exploited, and disseminated. Governing the processing of
personal data is a relatively young field of regulation that results from an attempt to secure the privacy,
autonomy, and integrity of individuals in the face of the massive growth of personal data gathering and
sharing by organisations.1
Technological and organisational developments in the processing of personal
data are factors behind the emergence of data privacy law, as the growing power of information and
communication technology has resulted in a fear of loss of control over what is done with the personal
data from individuals and who gets to access and exploit these types of data.
Many actors have played a role in developing and shaping privacy and data protection law. In the
legislative sphere, the Council of Europe, the Organisation for Economic Cooperation and Development,
the United Nations, and the EU are the key actors at the international level. Their work in the form of
conventions, regulations, and guidelines, has inspired and pushed for the adoption of particular privacy
legislation at the national level. The EU remains unique because it is the only jurisdiction whose own
constitutional basis obliges the adoption of comprehensive rules for protecting personal data.2
With its
recent reform in data protection and the adoption of the General Data Protection Regulation (GDPR), the
EU became well-known worldwide for its strict data protection rules that are shaping the way new
technologies are designed and built.
Blockchain’s potential as a novel method for secure and decentralised data storage and management
conforms with GDPR’s aim to reduce the power asymmetry between the organisations that process
personal data and the individuals whose data are processed. Yet reducing the influence of centralised
parties does not automatically mean empowering individuals to exert more control over their data.
Therefore, PharmaLedger is working on creating a fair, ethical, and privacy-compliant data platform and
marketplace using blockchain to support the use of data in a way that puts individuals in charge of deciding
who can access their data and tracing data points throughout their journey on the platform.
To ensure the privacy and confidentiality of PharmaLedger data and transactions, this chapter starts by
introducing the applicable legal framework on privacy and data protection. An overview of the relevant
normative acts in this field allows for identifying the main data protection requirements on which special
attention must be placed, irrespective of whether the PharmaLedger platform is tested within the
health data, supply chain, or clinical trials domain. Starting with explaining what data are considered as
personal, the chapter unfolds, in thoughtful and erudite detail, the significance of identifying the various
data processed in a blockchain environment, putting into perspective why this is one of the stress points
noted on the interplay of blockchains and the GDPR. It then moves on to discussing the key actors
responsible for compliance and elaborates on the obligations each of the actors has. Noting the
importance of having a legal basis for every collection and processing of personal data, the chapter
continues with an overview of the available lawful grounds. Elaboration on the rights the data subjects
enjoy concerning their data is then put forward. Finally, this chapter wraps up with proposing a
methodology for data protection by design and by default that will ensure the effective implementation
of the the core data protection principles in the design of the PharmaLedger platform.
1 See Lee A Bygrave, Data Privacy Law: An International Perspective (OUP 2014) 8
2 Article 8 of the Charter of Fundamental Rights and Article 16 of the Treaty on the Functioning of the European Union guarantees the right of
everyone to the protection of personal data concerning them.

2.1 Legal framework
2.1.1 European Convention on Human Rights
What is it?
The European Convention on Human Rights (ECHR) is an international instrument
adopted by the Council of Europe to protect human rights and political freedoms in
Europe. The ECHR entered into force on 3 September 1953. Since its adoption, it was
amended with 16 protocols that introduced additional rights to those set forth by the
original text. This Convention was the first instrument to give effect to several rights
from the United Nations (UN) Universal Declaration of Human Rights and make them
binding. The European Court of Human Rights (ECtHR) in Strasbourg has jurisdiction to
hear and rule on individual or State applications alleging violations of the rights set out
in the ECHR.
What does it regulate?
The ECHR guarantees the protection of the right to life, the right to a fair hearing, the
right to respect for private and family life, freedom of expression, freedom of thought,
conscience and religion and the protection of property. It also prohibits torture and
inhuman or degrading treatment or punishment, slavery and forced labour, the death
penalty, arbitrary and unlawful detention, and discrimination in the enjoyment of the
rights and freedoms set out in the ECHR.
Where does it apply?
The ECHR is ratified by the 47 Member States of the Council of Europe.3
Governments
that signed up to the ECHR made a legal commitment to abide by certain standards of
behaviour and to protect the basic rights and freedoms of their people. The ECHR is an
instrument that allows the Member States to protect and guarantee the human rights
of every person under their jurisdiction. The European Court of Human Rights (ECtHR)
in Strasbourg has the power to rule upon appealing, stemming from every person under
the jurisdiction of a Member State who complains that her or his rights have been
violated by a Member State who signed the ECHR. The ECHR and the ruling of the ECtHR
are legally binding and every Member State must respect its decisions.
How is it relevant to PharmaLedger?
The ECHR guarantees the right to respect for one’s private and family life, home, and
correspondence. As such, it creates obligations to protect against arbitrary interferences
with private and family life, home, and correspondence. Transfers of medical data by
hospitals to a public authority, or collecting biometric data by authorities are two
examples of interferences.4
PharmaLedger shall therefore fully comply with the ECHR.
3 Member states of the Council of Europe: Albania, Andorra, Armenia, Austria, Azerbaijan, Belgium, Bosnia and Herzegovina, Bulgaria, Croatia,
Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Georgia, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Liechtenstein,
Lithuania, Luxembourg, Malta, Monaco, Montenegro, Netherlands, North Macedonia, Norway, Poland, Portugal, Moldova, Romania, Russian
Federation, San Marino, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey, Ukraine, and the United Kingdom
4
L.H. v Latvia App no.52019/07 (ECtHR 29 July 2014); S.and Marper v UK App no 30562/04 (ECtHR 4 December 2008)

2.1.2 Council of Europe Convention 108
What is it about?
The Convention for the protection of individuals concerning the automatic processing
of personal data (Convention 108) was opened for signature by the Council of Europe in
Strasbourg on 28 January 1981 and entered into force in 1985. It was the first legally
binding international instrument that deals with data protection. In 2001, an Additional
Protocol to Convention 108 was adopted. It introduced provisions on data flows to third
countries and on the mandatory establishment of independent national data protection
supervisory authorities. In 2018, the Convention 108 underwent a modernisation
process that culminated in the adoption of Protocol CETS No. 223. This modernisation
process had two main objectives: to deal with the challenges from the use of
information and communication technologies (ICT) and to make the implementation of
Convention 108 more effective.
Convention 108 has a broad scope. It applies to data processing activities carried out in
the public and private sectors, but it does not apply to purely personal data processing
or processing in the course of household activities. It contributes to the respect of
individuals’ respect for human rights and fundamental freedoms concerning the
processing of their data.
Convention 108 introduces basic principles for the protection of personal data (e.g.
legitimacy, transparency, security, proportionality) and prohibits the processing of
sensitive data (e.g. genetic data, biometric data, or data revealing one person’s race,
politics, health, religion, sexual life or criminal record) whenever appropriate safeguards
cannot be guaranteed.
To date, 55 countries are party to the Convention 108. The Modernised Convention 108
applies in all 47 Member States of the Council of Europe, as well as Uruguay, Mauritius,
Senegal, Tunisia, Cabo Verde, Mexico, Argentina and Morocco.
Convention 108 is only binding for the Member States that have ratified it and not
subject to the supervision of the European Court of Human Rights (ECtHR), it does serve
as inspiration in the case-law of the ECtHR. Convention 108 introduces obligations for
its Contracting States. The ECtHR has increasingly widened the applicability of the ECHR,
and thus of the Convention 108 as an interpretative tool, to impact the private sector
by imposing the positive obligation on the Contracting States to enforce effective data
protection.
As under this Convention, the Contracting States are required to take the necessary
steps in their domestic legislation to apply the principles it lays down, the Convention
provides a benchmark for PharmaLedger to understand the fundamental rights that all
individuals from the Contracting States enjoy with regard to the processing of personal
data.

2.1.3 Council of Europe Recommendation on the protection of health-related data
What is it about?
With the development of new technological tools in the health sector, the volume of
health-related data processed has grown exponentially showing the need for guidance
for health administrations and professionals. To protect health-related data, the Council
of Europe’s Committee of Ministers in 2019 issued a Recommendation on the protection
of health-related data. This Recommendation contains a set of guidelines to the 47
Member States of the Council of Europe urging them to ensure, in law and practice, that
the processing of health-related data is done in full respect of human rights, with
emphasis on the right to privacy and data protection. This Recommendation should be
read in conjunction with the latest version of the Council of Europe Convention 108.
This Recommendation provides a set of principles applicable to the processing of
personal data relating to health in the public and private sectors. It therefore also
applies to the exchange and sharing of health-related data through digital tools. Some
of these principles include:
− where health-related data are shared by different professionals for purposes of
providing and administering health care to them, the data subject shall be
informed beforehand;
− in the exchange and sharing of health-related data, physical, technical and
administrative security measures should be adopted, as well as those necessary
to guarantee the confidentiality, integrity and availability of health-related data;
− health-related data may be communicated to recipients who are authorised by
law to have access to the data;
− health-related data should not be stored in a form which permits identification
of the data subjects for longer than is necessary for the purposes for which they
are processed unless they are used for archiving purposes in the public interest
or for scientific or historical research or statistics and where appropriate
measures are in place to safeguard the rights and fundamental freedoms of the
data subject;
− where a data subject withdraws from a scientific research project, their health-
related data processed in the context of that research should be destroyed or
anonymised in a manner which does not compromise the scientific validity of
the research and the data subject should be informed accordingly.
This Recommendation is addressed at the 47 Member States of the Council of Europe,
calling on their governments to transmit these guidelines to health-care systems and
actors processing health-related data, in particular health-care professionals and data
protection officers.
The principles included in the Recommendation are fully applicable to PharmaLedger as
the platform facilitates the exchange of data, some of which are health data. Therefore,
adherence to these principles affirms the commitment to build a trusted platform with
a high level of protection of the collected data.

2.1.4 Charter of Fundamental Rights
What is it about?
The Charter of Fundamental Rights of the European Union brings together the
fundamental rights of everyone living in the European Union. It was introduced by the
European Union to bring consistency and clarity to the rights established at different
times and in different ways in the individual EU Member States. The Charter entered
into force on 1 December 2009.
The Charter brings together in a single document fundamental rights, freedoms and
principles protected and promoted in the EU. The rights included in the text have three
different sources of inspiration: the rights recognised in the EC and EU Treaties and
along with them the ruling of the European Court of Justice (ECJ), the rights recognized
in the constitutions and the constitutional traditions of the Member States, the
international human rights treaties signed by the EU Member States, especially the
ECHR.
The Charter contains rights divided into six titles: Dignity, Freedoms, Equality, Solidarity,
Citizens' Rights, and Justice. As such, it combines a wide range of rights and freedoms,
far beyond just civil, political, economic and social rights. The Charter includes the
protection of cultural and ecological interests, data protection, guarantees on bioethics
and transparent administration.
The Charter is legally binding on the 27 EU Member States and the EU institutions when
implementing European Union law. All proposals for EU legislation have to respect the
Charter and EU institutions, bodies, offices and agencies have to respect the principle of
subsidiarity, i.e. decisions have to be taken as closely as possible to the citizen and
actions at Union level are only justified in light of the possibilities available at a national,
regional or local level.
The design and deployment of the PharmaLedger platform have to take into
consideration the rights and freedoms guaranteed by the Charter, specifically the
protection of personal data.
The Charter specifies that personal data must be processed fairly for specified purposes
and on the basis of the consent of the person concerned or some other legitimate basis
laid down by law. Everyone has the right of access to data which has been collected
concerning him or her, and the right to have it rectified.

2.1.5 OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data
What is it about?
In 1980, the Organisation for Economic Co-operation and Development (OECD) adopted
the Guidelines Governing the Protection of Privacy and Transborder Flows of Personal
Data to address concerns arising from the increased use of personal data and the risk to
global economies resulting from restrictions to the flow of information across borders.
These guidelines, which contained the first internationally agreed-upon set of privacy
principles, have influenced legislation and policy in OECD member countries and
beyond.
The OECD considered it necessary to develop guidelines to help harmonise its member
countries’ national privacy legislation. At the same time, such guidelines would uphold
human rights while preventing interruptions in international flows of data. The
Guidelines on the Protection of Privacy and Transborder Flows of Personal Data
represent a consensus on basic principles which can be built into existing national
legislation or serve as a basis for legislation in those countries that do not yet have it.
The Guidelines were adopted and became applicable on 23 September 1980, and were
last revised and updated on 11 July 2013.
These Guidelines apply to personal data, whether in the public or private sectors, which,
because of how they are processed, or because of their nature or the context in which
they are used, pose a risk to privacy and individual liberties.
The Guidelines instruct OECD member countries to refrain from restricting transborder
flows of personal data between themselves where the other country substantially
observes these Guidelines or sufficient safeguards exist, including effective enforcement
mechanisms and appropriate measures put in place by the data controller, to ensure a
continuing level of protection consistent with these Guidelines.
The Guidelines are directed at the OECD member countries and should be regarded as
minimum standards which can be supplemented by additional measures for the
protection of privacy and individual liberties in their national laws. As such, they are not
binding but represent a consensus on basic principles that can be built into existing
national legislation.
The following 37 countries are OECD members: Australia, Austria, Belgium, Canada,
Chile, Colombia, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece,
Hungary, Iceland, Ireland, Israel, Italy, Japan, Korea, Latvia, Lithuania, Luxembourg,
Mexico, Netherlands, New Zealand, Norway, Poland, Portugal, Slovakia, Slovenia, Spain,
Sweden, Switzerland, Turkey, United Kingdom, United States.
Although not binding, the OECD Guidelines play an important role in promoting respect
for privacy as a fundamental value and a condition for the free flow of personal data
across borders. Demonstrating compliance with the OECD privacy principles is therefore
necessary to promote PharmaLedger as a privacy-preserving platform.

2.1.6 Directive 2002/58 on privacy and electronic communications (e-Privacy Directive)
What is it about?
The Directive 2002/58 concerning the processing of personal data and the protection of
privacy in the electronic communications sector, or better known as the e-Privacy
Directive, is an EU directive that deals with the regulation of several important aspects
of privacy in the digital age, such as confidentiality of information, treatment of internet
traffic data, use of cookies, spam etc.
The e-Privacy Directive was adopted to supplement the then Data Protection Directive
(later replaced by the GDPR) addressing in detail the confidentiality of electronic
communications, and the tracking of internet users more broadly. With the GDPR’s
entry into force, reforms on privacy and electronic communications were also proposed.
In 2017, the European Commission drafted a proposal for the e-Privacy Regulation,
which is intended to repeal the e-Privacy Directive. But the scope of the e-Privacy
Regulation is still under discussion and therefore its date of entry into force is still
uncertain. Until then, the rules from the e-Privacy Directive remain applicable.
The broad subject matter of the e-Privacy Directive is the right to privacy in the
electronic communication sector and free movement of data, communication
equipment and services. The Directive harmonises the rules of the EU Member States
required to ensure equivalent protection of the right to privacy within the European
Union.
The Directive obliges all providers of electronic communication services, such as
telecommunications or broadcasting networks, to inform the subscribers whenever
there is a particular risk of the security of the network (e.g. a virus or other malware
attack). It also obliges all EU countries to prohibit the listening, tapping, storage or other
kinds of interception or surveillance of communication and related traffic, unless the
users have given their consent or other legal conditions have been fulfilled.
Rules on the use of e-mail addresses for marketing purposes are also included in the e-
Privacy Directive. Sending unsolicited emails for direct marketing purposes is prohibited
unless the recipient has agreed to this. Additionally, users must be given an opt-in option
for the use of cookies (not applicable to those cookies that are strictly necessary for the
delivery of a service requested by the user).
The e-Privacy Directive applies in every EU Member State. This Directive has also been
incorporated in the EEA Agreement and is therefore applicable to Norway, Iceland, and
Liechtenstein too.
The rules on security, confidentiality of communications, location and traffic data, and
unsolicited communications are fully applicable to PharmaLedger. If the use of cookies
is envisaged on the platform, compliance with the e-Privacy Directive is required.

2.1.7 General Data Protection Regulation (GDPR)
What is it about?
The General Data Protection Regulation (GDPR) adopted by the European Union in May
2016, is a landmark in the EU’s data protection law as it exercised influence around the
world and set the global standard for data protection legislation. The GDPR entered into
force on 25 May 2018 and replaced the Data Protection Directive (Directive 95/46/EC)
as the principal EU legal instrument regulating data protection at EU level until then.
The difference between the two types of legal instruments is that the rules contained in
the Data Protection Directive (DPD) had to be transposed into the national laws of each
EU Member State, whereas the GDPR rules are directly applicable in every EU Member
State.
The GDPR lays down rules relating to the protection of natural persons concerning the
processing of their personal data and rules relating to the free movement of personal
data. The rules cover the processing of personal data wholly or partly by automated
means and the manual processing of personal data if that data form part or are intended
to form part of a filing system. These rules cover both the public and private sectors but
do not cover the processing of personal data by EU institutions, bodies, offices and
agencies. Processing of personal data for purely personal and household activities are
also exempted from the scope of the GDPR. When the processing of personal data is
carried out for national security reasons or prevention, investigation, detection or
prosecution of criminal offences, including the safeguarding of public security, the GDPR
rules do not apply.
The GDPR applies to the European Economic Area (EEA), which includes all EU countries
and also, Lichtenstein, Iceland, and Norway. The GDPR applies to the processing of
personal data in the context of activities of a controller or a processor based in the EU,
regardless of where the actual processing takes place.
The GDPR also applies to a controller or a processor based outside of the EU if they
process personal data of individuals who are in the EU and they offer goods or services
to, or monitor the behaviour of, individuals within the EU.
When there is a processing of personal data of an individual using the PharmaLedger
platform, the GDPR applies and regulatory compliance is required. There are numerous
GDPR obligations imposed on the controllers and processors, and it is, therefore, key to
correctly identify the controller(s) and processor(s) in the PharmaLedger blockchain
ecosystem.
Anonymised data fall out of the GDPR’s scope, but the data protection rules still apply
to pseudonymised data.
The GDPR requirements will require adaptations to how the PharmaLedger platform is
designed and governed.

2.2 Processing of personal data on a blockchain
The GDPR lays down rules relating to the protection of individuals concerning the processing of their
personal data, as well as rules relating to the free movement of personal data. When participants on the
PharmaLedger platform interact with personal data of a data subject in the EU, they may be subject to
the GDPR. If no personal data is transacted via the PharmaLedger platform, participants are likely not
subject to the GDPR.
There are several stress points between blockchain solutions and the GDPR. When and under which
circumstances blockchain data qualifies as personal data is one of these points of tension that has been
discussed in the academic literature over the past few years.5
This issue is far from straightforward and it
has not yet been fully settled, neither by law nor by regulators. Finding an answer will depend on the
actual circumstance and the technical and functional configuration of the use case at hand.
The definitions of personal data and processing in the GDPR remain mostly unchanged from those in the
DPD, continuing to reflect their broad protective purpose and the technical environments in which the
processing may take place.
Processing should be understood broadly, covering any treatment of data such as collecting, recording,
organising, structuring, storing, using and erasing data, regardless of whether any of these is done by
automated means or manually.6
Any handling of data on each layer of the PharmaLedger platform will likely constitute processing
within the meaning of the GDPR. For instance:
− initial addition of personal data to the distributed ledger,
− continued storage of personal data on the ledger,
− any further usage (for data analysis or reaching consensus on the current state of the
network or for any other purpose),
− loading of personal data on a webpage or an app’s user interface,
− encrypting, hashing or any other operation performed on personal data.
Personal data is more ambiguous as a concept because it often requires a comprehensive assessment in
practice to determine if a piece of information is personal. The GDPR embraces a broad definition of
personal data that covers ‘any information relating to an identified or identifiable natural person’.7
An
identifiable person is one who can be identified, directly or indirectly, in particular by reference to an
identifier such as a name, an identification number, location data, an online identifier or to one or more
factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that
natural person.8
The obvious examples of data such as full name, home address, e-mail address, personal photos
and videos, location data, are all personal data. Some less obvious examples of personal data
may include IP address, cookie identifiers, unique device identifiers. Other data may qualify as
personal data if they allow for identifiability of an individual. The decision tree in Figure 1 can
help determine if a piece of information is personal data. It is critical to undertake this analysis
for each layer of the PharmaLedger platform because the GDPR won’t apply to aspects of the
PharmaLedger platform that do not include the processing of personal data.
5 See e.g. Michèle Finck, Blockchain Regulation and Governance in Europe (Cambridge University Press 2019)
6 GDPR, Article 4(2)
7 ibid, Article 2(1)
8
ibid

Figure 1: Decision tree to determine if a piece of information is personal data
While identification is achieved at the moment someone gets singled out from the rest of the group,
identifiability presupposes the possibility for this to happen.9
Where one piece of information does not
directly individuate someone, relevance is usually established by combining that information with
secondary information held separately either by the controller or another person. Because of this data
linking, a distinctive profile of an individual may be created. Usually, the costs, the time required for
identification, and the available technology at the time are factors to consider when determining if the
9
WP29, ‘Opinion 4/2007 on the concept of personal data’ (2007) 01248/07/EN

person is identifiable.10
When identification is practically impossible because it requires a
disproportionate effort in terms of time, cost and man-power, so that the risk of identification appears to
be insignificant, then that data is less likely to be treated as personal data.11
Storing personal data in plain text or raw form on any blockchain will trigger GDPR applicability. But most
blockchains integrate encryption methods that would likely prevent direct identification of its users. This
means that the GDPR will only apply if indirect identification is possible. Even though hashing and
encryption methods are used to de-identify data, a data subject can still be identified with reasonable
effort and the use of additional information that is publicly available or kept separate by the data
controller or a third party. This is why hash functions and encryption are considered by the regulators as
pseudonymisation techniques.12
Although pseudonymisation is incentivised by the GDPR as it is viewed
as a safeguard for the privacy of the data subjects, pseudonymous data are still considered as personal
data.13
In contrast, anonymous data are exempt from the GDPR’s scope of application and the data protection
principles do not apply to such data. But the threshold to reach anonymisation is set high.14
For data to
be considered anonymous, the anonymisation process needs not only to guarantee resistance against
singling out, linkage, and inference, but it must also assure irreversibility.15
Reversibility refers to the
possibility that the ‘anonymised’ data can be reversed to reveal the underlying data with the available
technology at the moment or the expected forthcoming technology. With technological advances like
quantum computing, even the strongest cryptography available today will probably become obsolete in
the future.
As the PharmaLedger platform’s architecture is still under development, the categories of data
processed on the platform cannot be fully identified. The platform is intended to be blockchain-
agnostic supporting multi-blockchain technologies and allowing the integration of several layers
that will allow interoperability. It is expected that only anchoring data is written directly on the
ledger and every other data to be transacted off-chain. The use of public keys, hashed data,
Decentralized Identifiers (DIDs) and Verifiable Credentials will likely trigger GDPR applicability in
certain cases.
2.2.1 Public keys and hashed content data
Participants on a blockchain network have unique personal addresses that are shared on the blockchain.
These addresses comprise a series of random-looking alphanumeric characters that make up the public
key to the participant’s account. The public key is linked to a private key known solely by the participant.
Data encrypted with the public key can only be decrypted with the private key, and vice versa – data
encrypted with the private key can only be decrypted with the public key. The public-private key pair is
randomly generated by a participant in his or her digital wallet, which is an app that runs on a smartphone,
tablet, desktop, or another local device.
Blockchain’s architecture requires that public keys are always made visible because they are essential for
the functioning of the technology. Because public keys are long strings of quasi-random digits and letters,
direct identification based only on the public key is practically impossible. From the perspective of other
participants on the blockchain, and the public in the case of a public blockchain, this means that a
particular participant is unknown to the rest until her or his public key is linked to additional information
that can reveal the identity behind the key. When associated with a natural person, the public key will
10 GDPR, Recital 26
11 Case C-582/14 Patrick Breyer v Bundesrepublik Deutschland [2016] ECLI:EU:C:2016:779
12 WP29, ‘Opinion 05/2014 on Anonymisation Techniques’ (2014) 0829/14/EN
13 GDPR, Recitals 26, 28
14 See WP29 (n 8)
15
ibid

likely qualify as personal data. Once someone can link a public key to a natural person, then all previous
transactions made by that person with that public key can be identified with little effort.
As an example, linking public keys on cryptocurrency blockchains with other pieces of information has
proven to be possible and reasonably achievable in the past.16
Blockchain participants may voluntarily
release additional information when they exchange cryptocurrencies with fiat money – a process that
requires disclosing of credit card details; or when they visit a store and make a purchase using
cryptocurrencies – in which case the cashier can connect a public key with a physical identity.
Identification has also been performed by tracing back a public key to the IP address17
used to connect to
the network transmitting the blockchain transaction.18
2.2.2 Decentralized Identifiers (DIDs) and Verifiable Credentials
Participants on the PharmaLedger platform are likely to be represented by Decentralized Identifiers (DIDs)
that will serve as identifiers of their accounts on the platform. Every manufacturer, product re-packager,
patient, regulatory body, or any other stakeholder taking part on the platform will be assigned a unique
DID to guarantee the authenticity of the transactions they generate.
DIDs are globally unique persistent identifiers that do not require a centralized registration authority
because they are generated and registered cryptographically using distributed ledger technology (DLT).19
When DIDs are generated to represent a particular legal entity using the PharmaLedger platform, they are
not personal data within the meaning of the GDPR. But when a natural person establishes a connection
with another participant on the platform and thereby gets assigned a DID, the DID itself will likely be
considered as personal data. This is so because the DID is an identifier that resolves to a DID document
containing the metadata needed to prove ownership, as well as a service endpoint, which is usually the
user’s IP address or a URL. The CJEU has confirmed that IP addresses of internet users are protected
personal data within the meaning of the GDPR.20
Even dynamic IP addresses are personal data because of
the possibility to link the IP address to additional data relevant to identify the individual behind the
computing device connected to the network.21
Therefore, identifying an individual based on a DID and
additional available information will probably be possible. That a third party may hold the additional data
necessary to identify the data subject does not bear much weight.22
As long as obtaining the additional
data is lawful and it does not require a disproportionate effort in terms of time, cost, and effort, the data
will fall within the scope of personal data.
A verifiable claim is a qualification, achievement, quality, or piece of information about an entity's
background such as a name, government ID, payment provider, home address, or university degree.23
The
attestations or identity claims a user makes are acquired from a trusted party (e.g. government, university,
hospital, insurance company, etc.) and are attached to her or his DID. As many of these claims could reveal
the identity of a person, they will qualify as personal data. In this case, compliance with the GDPR is
necessary.
16 Michèle Finck, ‘Blockchains and Data Protection in the European Union’ (2018) Max Plank Institute for Innovation and Competition Research
Paper No. 18-01
17 IP addresses, both static and dynamic, were found to fall within the scope of the definition of ‘personal data’. See Case C-70/10 Scarlet
Extended v SABAM [2011] ECLI:EU:C:2011:771; Case C-582/14 Patrick Breyer v Bundesrepublik Deutschland [2016] ECLI:EU:C:2016:779
18 Alex Biryukov et al, ‘Deanonymisation of Clients in Bitcoin P2P Network’ (2014), https://orbilu.uni.lu/bitstream/10993/18679/1/Ccsfp614s-
biryukovATS.pdf, accessed 13 July 2020
19 W3C, ‘Decentralized Identifiers (DIDs) v1.0: Core architecture, data model, and representations’ (2020), https://www.w3.org/TR/did-core/
accessed 14 July 2020
20 See Case C-70/10 Scarlet Extended v SABAM [2011] ECLI:EU:C:2011:771
21 See Case C-582/14 Patrick Breyer v Bundesrepublik Deutschland [2016] ECLI:EU:C:2016:779
22 ibid
23
W3C, ‘Verifiable Credentials Use Cases’ (2019) https://www.w3.org/TR/vc-use-cases/ accessed 27 August 2020

Privacy and data protection must feature highly when deciding on the use of DIDs and Verifiable
Credentials on the PharmaLedger platform. Some privacy-preserving recommendations include:
− Instead of using the same DID for multiple or all interactions recorded on a blockchain,
pairwise unique DIDs could be established for every relationship between two parties;
− Where a public blockchain is used as a DID registry, no personal data should be stored
on publicly available DID documents. Rather, personal data should be kept off-chain
under the control of the individual and only exchanged through private peer-to-peer
encrypted channels.
− Credentials should be as abstract as possible. An example would be issuing an age-over
credential instead of an actual birthdate.
− Attributes in credentials should be limited to the absolute minimum necessary –
preferably a single attribute per credential.
− Verifiers should only request information that is necessary for the particular transaction
to happen.
2.2.3 Special categories of data
Personal data that are, by their nature, particularly sensitive to fundamental rights and freedoms merit
specific protection. These data are referred to as special categories of personal data,24
(previously known
as sensitive data) and enjoy a separate regime in the GDPR because they are revealing:
• racial or ethnic origin,
• political opinions, religious and other beliefs, including philosophical beliefs,
• trade union membership,
• genetic data and biometric data processed to identify a person,
• health-related information,
• sexual life or sexual orientation.
Data concerning health are personal data related to the physical or mental health of a natural person
which reveal information about his or her past, current, or future health status.25
This includes:
− any information that may be collected in the course of the registration for, or the provision of,
health care services;
− any number, symbol or particular assigned to a natural person to uniquely identify the natural
person for health purposes;
− any information derived from the testing or examination of a body part or bodily substance,
including from genetic data and biological samples; and
− any information on a disease, disability, disease risk, medical history, clinical treatment, or the
physiological or biomedical state of the data subject, independent of its source (e.g. from a
physician or other health professional, a hospital, a medical device, or an in vitro diagnostic test).
When special categories of personal data like data concerning health are processed, an extra layer of
complexity arises as the GDPR prohibits the processing of these types of data.26
Processing may be
considered lawful if it meets the conditions outlined in Section 2.5.7.
25 ibid, Article 4(15), Recital 35
26
ibid, Article 9(1)

2.3 Determining the controller and processor in a blockchain system
Understanding the attribution of roles under the GDPR is a decisive step in applying the GDPR rules as
they are driven by the principle of accountability. There are three key roles in the processing of personal
data under the GDPR: data controller, data processor, and data subject. Generally, the category into
which a participant falls is determined by answering the why, the how, and the who questions concerning
the data processing operation:
• the person who decides why and how data are processed, i.e. determines the purpose and means
for the processing is a data controller;
• the person who processes the data on behalf of the controller is a data processor;
• the natural person whose data are processed, i.e. to whom the data relate is a data subject.
2.3.1 Controller
The GDPR places the primary responsibility for protecting personal data and ensuring compliance with
the rules on the entity that exercises control over the data processing – the data controller. Thus, it is
key for data subjects to be able to easily identify the controller so they can seek enforcement of their
rights. At the same time, data protection authorities should also know who the controller is as non-
compliance with the GDPR results with administrative fines imposed on the responsible entity.
This suggests that the GDPR was written with the assumption that there will always be a data controller
behind any processing operation.27
As such, it presumes centralised environments where the distribution
of roles is apparent. But decentralised and distributed information systems like blockchains are
environments where the data protection legal doctrine reflects a limited technological understanding,
especially in the case of public blockchains.28
Indeed, the EU Blockchain Observatory and Forum
recognised that public permissionless blockchains represent the greatest challenge in terms of GDPR
compliance whereas compliance is easier for private permissioned blockchains.29
As the PharmaLedger
platform is intended to fall somewhere in between, pinpointing the data controller(s) requires a
comprehensive analysis accounting for all relevant technical and contextual factors.
The concept of a controller shall be given a wide interpretation to ensure effective and complete
protection of the data subjects.30
As the definition suggests, the data controller can be a natural or legal
person, public authority, agency or other body, so long as that entity determines the purposes and means
of the processing of personal data, either alone or jointly with others.
Determining the means includes both technical and organisational questions.31
Where an entity decides
to use blockchain as opposed to another form of database, it has likely decided on the means of personal
data processing, indicating that it qualifies as a controller if it also decides on the purpose of the data
processing.32
Accordingly, the entity that decides to use the software, hardware and data centres that
operate a specific blockchain can be considered to be determining the means of processing.33
27 EU Blockchain Observatory and Forum, ‘Blockchain and the GDPR’ (2018)
https://www.eublockchainforum.eu/sites/default/files/reports/20181016_report_gdpr.pdf, accessed 10 July 2020
28
Nenad Georgiev, ‘Privacy and Blockchain: The legal implications of the GDPR’s right to erasure’, University of Oslo, (2018),
http://hdl.handle.net/10852/67233
29 EU Blockchain Observatory and Forum (n 25)
30 See Case C-131/12 Google Spain [2014] EU:C:2014:317, para 34; Case C-210/16 Wirtschaftsakademie [2018] ECLI:EU:C:2018:388; Case C-
40/17 Fashion ID [2019] ECLI:EU:C:2019:629
31 WP29, ‘Opinion 1/2010 on the concepts of "controller" and "processor"’ (2010) 00264/10/EN
32 EPRS STOA, ‘Blockchain and the General Data Protection Legislation: Can distributed ledgers be squared with European data protection law?’
(2019) https://doi.org/10.2861/535, accessed 20 July 2020
33
ibid

Depending on the chosen governance set-up of the PharmaLedger platform, different actors
could be influencing the determination of the means of processing:
− in a private ledger scenario, it will be the legal entity or association of entities
(consortium) that determine the means;
− in a public ledger scenario, there will likely be no single legal entity deciding which
software, hardware or data centres to use. Several actors (e.g. miners, nodes, users) will
play a role in determining the means. Identifying the data controller in these cases is
challenging, and the decisive factor will be to determine which of the actors exerts control
over the purpose of processing.
Determining the purpose of processing implies deciding on the reason and objective for the processing of
personal data. While the GDPR assigns equal weight on the two factors for identifying the controller, the
case law and regulatory guidance underline the primacy of the purpose over the means criterion,
especially because some aspects of the latter may be delegated to others (particularly processors).34
Thus,
exerting influence over why data processing happens implies having a decisive role in the overall
processing of that data.
When users directly interact with the blockchain (as with Bitcoin), controllership should be determined at
the infrastructure level.35
But identifying the party that exerts control over the purpose of data processing
in public permissionless blockchains is neither simple nor definite. As an illustration, in a public
permissionless environment, software developers have a limited role in determining the means, but rarely
influence the purposes of a specific data processing operation.36
Neither do miners, who exercise
significant control over the means in choosing which protocol to run but have little say over why the data
is being processed.37
Nodes could be joint controllers because they have equal influence and freedom to choose a certain
blockchain network, and by doing so they pursue their own purpose to take part in that network.38
Users
too could be considered as joint controllers because they submit and sign transactions directly to the
blockchain and thus determine the purpose of the specific data processing activity.39
But such attribution
of responsibility to users is inadequate and controversial in some instances. For example, where a user is
a natural person, he or she may transact on the blockchain for purely personal reasons unrelated to
professional or commercial activity. In that case, the household exemption applies and such processing
falls out of the GDRP’s scope.40
Moreover, the user has no influence over how long the data is stored for,
who has access to the data, and when data is deleted.41
These are essential elements reserved for the
determination of the controller and they reflect the overarching spirit of the EU data protection
legislation.
The emergence of multi-layered blockchain ecosystems suggests that many entities potentially qualify as
joint controllers as they influence various elements of the overall data processing. For instance, where an
application layer exists, the entity determining the purposes of personal data processing at the application
34
See WP29, ‘Opinion 1/2010 on the concepts of “Controller” and “Processor”’ (2010) 00264/10/EN, 14; Case C-25/17 Jehovan todistajat
[2018] EU:C:2018:551, para 68
35 EPRS STOA (n 30)
36 Note that in relation to smart contracts, the French CNIL found that the developer of a software is usually a simple external provider, but if it
actively participates in the data processing it can be found as a processor or joint controller. See Commission Nationale Informatique et Libertés
(CNIL), ‘Blockchain: Solutions for a responsible use of the blockchain in the context of personal data’ (2018)
37 ibid
38 See Christian Wirth and Michael Kolain, ‘Privacy by BlockChain Design: A Blockchain-enabled GDPR-compliant Approach for Handling Personal
Data’ in Wolfgang Prinz and Peter Hoscka (eds), Proceedings of the 1st ERCIM Blockchain Workshop 2018, Reports of the European Society for
Socially Embedded Technologies Privacy by BlockChain Design (2018) 5
39 See EPRS STOA (n 30) and CNIL (n 34)
40 See GDPR, Article 2(2)(c)
41
Thomas Buocz et al, ‘Bitcoin and the GDPR: Allocating Responsibility in Distributed Networks’ (2019) Computer Law & Security Review 1, 24

layer qualifies as a data controller.42
Moreover, when a data subject relies on intermediaries (e.g.
credential issuers, wallet providers, etc.) then that intermediary is likely a controller too. According to the
French DPA, when a group of entities decides to carry out the processing for a common purpose on a
blockchain, all entities shall be considered as joint controllers unless they have explicitly determined
which entity will act as a controller and which as a processor.43
Joint controllers need not participate equally in determining the means and purposes of the processing.44
But they must have an arrangement in place that divides roles and responsibilities between them clearly
and transparently.45
Though there is no explicit obligation to have this arrangement in writing, the
requirement to have the essence of the arrangement available to data subjects implies that at least a
written summary of the arrangement exists.46
Based on their current roles as the principal architects and custodians of the PharmaLedger
platform, members of the PharmaLedger Consortium who exercise control over the overall
determination of the purposes and means of the data processing activities for each use case
under development are in the best position to fulfil the controllership role. They could either
agree to be joint controllers or agree to assign the role of a controller to one entity.
Once the PharmaLedger platform becomes fully operational and the participants of the platform
are known, the possibility for other (joint) controllers should be explored according to the
decision tree in Figure 2.
As the PharmaLedger platform is intended to be an open and sustainable blockchain platform
beyond the project’s life, a clear and transparent distribution of roles is necessary to ensure the
high standards for data protection are maintained.
2.3.2 Data processor
The role of a data processor is linked to that of the controller as the processor is the entity that processes
personal data on behalf of the controller. A processor can be a natural or legal person, public authority,
agency, or other body so long as the processor is an entity that is legally separate from the controller.47
Hence, employees processing personal data following their job duties towards their employer should not
be regarded as processors.48
It is not necessary for every data processing to involve a processor because in many instances controllers
can carry out the processing operations themselves. But when they do decide to outsource the processing
to another entity, then there shall be a contract between the controller and the processor or other legal
act that will govern their relationship and delineate the obligations of the processor for the processing
activities.49
Thus, the processor can only act within the remit set by the controller. When a processor
carries out processing outside of what the controller had dictated, it ceases to be a processor and assumes
the role of a controller if it also determines the purposes and means of that processing.50
By doing so, the
processor is also liable for infringing the GDPR.
42 EPRS STOA (n 30)
43 CNIL (n 34)
44
See WP29 (n 32) 19
45 GDPR, Article 26
46 Christopher Millard and Dimitra Kamarinou, ‘Article 26. Joint controllers’ in Christopher Kuner, Lee A Bygrave, and Christopher Docksey (eds),
The EU General Data Protection Regulation (GDPR): A Commentary (OUP 2020), 587
47 WP29 (n 32) 25
48 Explanatory Report to the Modernised Convention 108, para 49
50 Lee A Bygrave and Luca Tosoni, ‘Article 4(8). Processor’ in Christopher Kuner, Lee A Bygrave, and Christopher Docksey (eds), The EU General
Data Protection Regulation (GDPR): A Commentary (OUP 2020), 160

Processors have a limited number of obligations under the GDPR. Their primary responsibility is to
provide sufficient guarantees to implement appropriate technical and organisational measures so that
the processing meets the GDPR requirements while ensuring the protection of data subject’s rights.51
Also, processors are required to maintain a written record of all categories of processing activities carried
out on behalf of the controller.52
Such records should include a summary of the technical and
organisational security measures, the contact details of the processor and the controller, as well as details
on the categories of processing and any transfers to third countries or international organisations.53
In
certain cases, processors must also designate a data protection officer (DPO).54
To identify the data processor in a blockchain system, a case-by-case assessment is again necessary. Often,
processors are unaware that they qualify as such. The absence of a contract between a controller and a
processor is not decisive for the existence of a controller-processor relationship because a contract can
also be concluded upon the actual observation of the factual elements of the relations between different
subjects and the way the processing purposes and means are determined.55
When a company or a public authority uses an external service provider’s blockchain infrastructure, the
external provider is merely a data processor if the infrastructure is used according to the buyer’s wishes.56
Other examples of data processors include data warehouses of out-sourcing agencies, cloud providers, or
those providing software, platform, or infrastructure as a service.57
Smart contract developers who
process data on behalf of the data controller could also be considered as data processors, as well as miners
because they follow the data controllers’ instructions when checking whether the transaction meets the
technical criteria.58
To the extent personal data is written on the blockchain layer of the PharmaLedger platform,
miners and nodes are likely to be processors acting on behalf of the controller from the
PharmaLedger Consortium. For the other layers of the PharmaLedger platform, the designation
of processors will depend on the relationship each party has with respect to the designated
controller (see Figure 2 for guidance).
It is best for the controller of the PharmaLedger platform to execute data processing agreements
with each processor to meet the GDPR requirements. This agreement shall specify the respective
roles and responsibilities of the PharmaLedger platform concerning the processing of personal
data on the platform.
52 ibid, Article 30(2)
53 ibid
54 ibid, Article 37
55 WP29 (n 32) 27
56 EPRS STOA (n 30) 57
57 Lilian Edwards, ‘Data Protection I: Enter the GDPR’ in Lilian Edwards (ed), Law, Policy and the Internet (OUP 2018)
58
CNIL (n 34) 7

Figure 2: Decision tree to identify the controller(s) and processor(s) for a data processing activity 59
59 Flowchart based on guidance issued by the European Data Protection Supervisor.
See https://edps.europa.eu/sites/edp/files/publication/19-11-19_flowchart_controllership_en.pdf

2.4 Privacy and data protection principles
European data protection law recognises several key data protection principles. These principles are
either explicitly enumerated in the relevant legislation (e.g. the GDPR and the Convention 108) or have
been established in the case-law (e.g. decisions of the ECtHR and the Court of Justice of the European
Union - CJEU).
The data protection principles cover:
• lawfulness, fairness, and transparency;
• purpose limitation;
• data minimisation;
• data accuracy;
• finality (storage limitation);
• integrity and confidentiality;
• accountability.
These principles serve as the starting point for the more detailed provisions that establish obligations for
data protection compliance. Restrictions to these principles are only allowed to the extent that they
correspond to the fundamental rights and freedoms. Such restrictions and exemptions must be provided
by EU or national law and be necessary and proportionate measures in a democratic society.60
This means
that any processing of personal data on the PharmaLedger platform shall be guided by these data
protection principles. Compliance with these principles will also have to be demonstrated as part of the
data protection by design and by default requirement as discussed in Section 2.8.
2.4.1 Lawfulness, fairness, and transparency
One of the basic principles concerning data protection is that personal data be processed lawfully, fairly,
and in a transparent manner in relation to the data subject.61
The requirement that data processing is lawful means that all applicable legal requirements are respected,
i.e. the processing is based on legitimate grounds provided in data protection legislation.62
Under the
GDPR, there are six lawful grounds for processing personal data that are discussed in detail in Section 2.5.
For data to be processed fairly, the respective data must not be collected or otherwise processed using
unfair means, deception, or without the data subject’s knowledge.63
This aspect primarily governs the
relationship between the controller and the data subject. Controllers shall not perform the processing
operations in secret and they shall be able to demonstrate compliance with the GDPR.
Processing data in a transparent manner presupposes that data subjects are informed about what data
are being collected and how their data are being used, consulted or otherwise processed.64
Data subjects
should also be informed of the risks involved in processing.65
Transparency also requires that clear and
plain language be used when communicating the relevant aspects of the processing operations to the
data subject. Several rights arise out of the transparency obligations, and these are discussed in detail in
Section 2.6.
60 GDPR, Article 23(1); Convention 108, Article 11(1)
61 GDPR, Article 5(1)(a); Convention 108, Article 5(3), Article 5(4)(a)
62 Charter of Fundamental Rights of the European Union, Art. 8 (2); GDPR, Recital 40 and Articles 6, 7, 8, and 9; Convention 108, Article 5(2)
63 See example of unfair processing: K.H. and Others v Slovakia App no 32881/04 (ECtHR, 28 April 2009)
64 GDPR, Recital 39
65
ibid

2.4.2 Purpose limitation
The principle of purpose limitation is considered as the cornerstone of data protection from which many
fundamental requirements derive.66
This principle requires data to be collected for a specific, well-
defined purpose and not processed for additional purposes that are incompatible with the original
purpose.67
The purposes for processing personal data shall be defined before the data collection begins. Any
processing for undefined purposes is unlawful. Collecting personal data for unspecified purposes, with
the consideration in mind that it may be useful sometime in the future, is illegitimate. The purposes must
also be unambiguous and clearly expressed instead of being kept hidden.68
For controllers using
blockchain technology, this also means that they would have to communicate to data subjects that they
are using this technology and that the processing is not limited to the original transaction but some of
their data are necessary for ledger integrity purposes.
New purposes for processing previously acquired data must be compatible with the original purpose –
otherwise, any further processing must have its own legal basis and cannot rely on the fact that the data
were initially collected for a legitimate purpose. Compatibility is assessed by considering several factors,
including any link between the purposes, the reasonable expectations of data subjects for further use of
their data, the nature of the personal data, the consequences of the intended further processing, and the
implemented safeguards for the original and intended further processing operations.69
Further processing for archiving purposes in the public interest, scientific or historical research purposes
or statistical purposes is considered compatible with the initial purpose if appropriate safeguards (e.g.
anonymisation, encryption or pseudonymisation) are in place.70
2.4.3 Data minimisation
The data minimisation principle requires that the data collected be relevant and limited to what is strictly
necessary for the purposes for which they are processed.71
Personal data must be adequate for achieving the purpose of the processing that cannot be otherwise
reasonably fulfilled by other means.72
The processing operations may not disproportionately interfere
with the interests, rights, and freedoms of the data subject.
2.4.4 Data accuracy
Under the accuracy principle, data shall be accurate, and where necessary, kept up to date.73
Data controllers are obliged to take every reasonable step to ensure that inaccurate personal data are
erased or rectified without delay. In some cases, updating stored data may be legally prohibited because
the purpose of storing the data is to document historical changes. In others, it is an absolute necessity to
update and regularly check the accuracy of data because of the potential damage to the data subject that
may be caused if data were to remain inaccurate. Therefore, the obligation to keep data updated and
accurate must be interpreted taking into consideration the purpose of the data processing itself.
66
Cécile de Terwangne, ‘Article 5. Principles relating to processing of personal data’ in Christopher Kuner, Lee A Bygrave, and Christopher
Docksey (eds), The EU General Data Protection Regulation (GDPR): A Commentary (OUP 2020), 315
67 GDPR, Article 5(1)(b)
68 WP29, ‘Opinion 03/2013 on Purpose Limitation’ (2013) 00569/13/EN
69 GDPR, Recital 50; Explanatory Report to the Modernised Convention 108, para 49
70 GDPR, Article 5(1)(b)
71 GDPR, Article 5(1)(c); Convention 108, Article 5(4)(c)
72 GDPR, Recital 39
73
ibid, Article 5(1)(d)

2.4.5 Finality (storage limitation)
The finality or storage limitation principle requires that data be kept for no longer than it is necessary for
the purposes for which they are processed.74
To ensure that personal data are not kept longer than necessary, data controllers are invited to establish
time limits for retention and or either erase or anonymise data when that period has passed and the
purposes have been served.75
This time limitation applies only for data kept in a form that permits
identification of data subjects.
Archiving data for the public interest, scientific or historical purposes, or for statistical use, may be stored
for longer periods if appropriate technical and organisational measures are in place to safeguard the rights
and freedoms of the data subjects.76
2.4.6 Data security (integrity and confidentiality)
The principle of data security requires that data be processed in a way that ensures appropriate security
of the personal data and that appropriate technical or organisational measures are in place to protect
the data against accidental, unauthorised or unlawful access, use, modification, disclosure, loss,
destruction or damage.77
Based on this principle, controllers are obliged to safeguard the integrity and confidentiality of data by
implementing measures such as pseudonymising and encrypting personal data and regularly testing and
evaluating the effectiveness of these measures. When implementing such measures, controllers and
processors shall take into account the state of the art, the cost of implementation, as well as the risk and
severity for the rights and freedoms of the data subjects.78
More details on the technical and
organisational measures are provided in Section 2.8.
2.4.7 Accountability
Accountability requires that controllers be responsible for, and be able to demonstrate compliance with,
the data protection principles.79
Under this requirement, controllers are not only obliged to ensure GDPR compliance, but they must also
be able to demonstrate such compliance. This principle represents a fundamental shift in data protection
legislation as it requires a proactive role of whoever is in control of the processing of personal data to
make sure that measures are in place to guarantee the data protection rules and to document these
measures to demonstrate compliance to both data subjects and supervisory authorities.
While processors are covered by specific accountability-based mechanisms, such as maintaining records
of their processing activities and implementing appropriate measure to ensure security, the GDPR places
the responsibility solely on the controller to comply with the GDPR obligations from start to end.
74 GDPR, Article 5(1)(e)
75 ibid, Recital 39
76 GDPR, Article 5(1)(e); Convention 108, Articles 5(4)(b) and 11(2)
77 GDPR, Article 5(1)(f); Convention 108, Article 7; OECD Privacy Guidelines, §11
79
GDPR, Article 5(2); Convention 108, Article 10(1)

2.5 Lawful grounds for processing personal data
Based on the principle of lawfulness, the processing of personal data can only be lawful when the
processing activities rely on a legal basis. There is an exhaustive list of legal bases in the GDPR and each
of them is discussed in the following subsections. Depending on the circumstances, one legal basis may
be more suitable than another and, therefore, data controllers must carefully assess which lawful ground
is most appropriate for their processing activities.
2.5.1 Consent
Processing of personal data is lawful when the data subject has given consent.80
Consent is defined as
‘any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he
or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal
data relating to him or her’.81
Consent presupposes that the data subject is given control and is offered a
genuine choice about the terms of the intended processing activity, or declining them without
detriment.82
There are no formal requirements for obtaining valid consent.83
Consent can be given in writing (on paper
or by electronic means) or through an oral statement.84
It can also be given by ticking a box to confirm the
agreement. Silence, pre-ticked boxes or inactivity are not acceptable. If consent is given electronically,
the request for consent must be clear, concise and not unnecessarily disruptive to the use of the service
for which consent is given.85
If consent is given in writing on a document that covers other matters too,
the request for consent shall be distinguishable and presented in an intelligible and easily accessible form,
using clear and plain language.86
Consent should cover all processing activities carried out for the same
purpose(s).87
If there is more than one purpose, consent should be given for all of them.88
Controllers are required to put in place safeguards to ensure that the data subject’s consent meets all
elements of validity:89
Consent must be freely given. To be freely given, data subjects must have a genuine choice. They
should be able to refuse or withdraw consent without any loss.90
Clear power imbalance will likely
invalidate consent.91
An example of clear power imbalance is the case of an employer-employee
relationship.
Consent must be specific. To be specific, consent must not be requested in bulk for all different
processing operations, creating an all-or-nothing situation.92
Hence, data subjects should be allowed
to give separate consent for every different operation.93
80 GDPR, Article 6(1)(a)
81
ibid, Article 4(11), Recital 32
82 WP29, ‘Guidelines on consent under Regulation 2016/679’ (2017) 17/EN WP259
83 GDPR, Article 7(1), Recital 42
84 ibid, Recital 32
85
ibid
86
ibid, Article 7(2)
87 ibid, Recital 32
88 ibid
89 In 2019, the French DPA imposed a financial penalty of €50 million against Google for lack of valid consent, lack of transparency and
inadequate information. The DPA considered the consent to be not validly obtained because it was not sufficiently informed (the information
was diluted in several documents and did not enable the users to be fully aware of what they precisely consented to), it was not specific (the
consent encompassed all the processing operations carried out by Google instead of given distinctly for each purpose), and it was not
unambiguous (pre-ticked boxes were used). See https://www.cnil.fr/en/cnils-restricted-committee-imposes-financial-penalty-50-million-euros-
against-google-llc, accessed 19 August 2020
90 GDPR, Recital 42
91 ibid, Recital 43
92 GDPR, Recital 43
93
ibid

Consent must be informed. To be informed, data subjects must be aware of the fact that they are
giving consent and of the scope of that consent.94
Controllers using pre-formulated consent forms
should make sure they are written in an intelligible and easily accessible form, using clear and plain
language, and without unfair terms.95
Data subjects should be at least aware of the identity of the
controller and the processing purposes.
Consent must be unambiguous. To be unambiguous, data subjects must give their consent by a clear
affirmative act establishing unambiguous indication of their agreement to the processing operation.
Silence, inactivity, or a blanket acceptance of general terms and conditions cannot be considered valid
consent.96
Consent must be explicit. When data controllers intend to process special categories of personal data,
consent must also be explicit. To be explicit, data subjects are required to give an express statement
of consent. There are several ways to obtain explicit consent, for example, i) express confirmation in
a written statement signed by the data subject, ii) filling in an electronic form, iii) sending an email,
iv) uploading a scanned document containing the data subject’s signature, and v) the use of an
electronic signature. Although it is possible to obtain valid explicit consent through an oral statement,
it may be more difficult for the controller to prove that all conditions for valid explicit consent were
met.97
As one of blockchain’s most valuable features, immutability builds trust by preventing changes of data
once they have been added to the ledger. However, the GDPR requires that consent is a reversible
decision, allowing data subjects to withdraw consent at any time (Section 2.6.7).98
Confronted with
consent withdrawal, data controllers would have to rely on another legal basis to continue the processing
activities. Although withdrawing consent does not affect the lawfulness of the processing that happened
before the withdrawal, any further processing must stop. Figure 3 visualises this principle.
Figure 3: Lawfulness of data processing after consent withdrawal
Such strict separation between prior processing and further processing proves to be defective in a
blockchain scenario. When personal data are processed on a blockchain, these personal data will be
stored on the chain – and indirectly processed – for as long as the ledger exists.99
It could be practically
impossible to stop processing personal data on-chain if there is no other legal ground that would legitimise
further processing. Such conclusion suggests that consent is an unsuitable or at least unsustainable legal
94 ibid, Recital 42
95 ibid
96 WP29 (n 80), 15-16.
97 EDPB, ‘Guidelines 05/2020 on consent under Regulation 2016/679’ (2020) 20
99
EPRS STOA (n 30)

PharmaLedger Ethical and Legal Inventory

PharmaLedger Ethical and Legal Inventory

Recommended

Recommended

More Related Content

What's hot

What's hot (14)

Similar to PharmaLedger Ethical and Legal Inventory

Similar to PharmaLedger Ethical and Legal Inventory (20)

More from PharmaLedger

More from PharmaLedger (12)

Recently uploaded

Recently uploaded (20)

PharmaLedger Ethical and Legal Inventory