Embed Size (px)
Citation preview
1
Acronym: vINCI
Name: Clinically-validated INtegrated Support for Assistive Care and Lifestyle Improvement: the Human Link
Call: AAL 2017 “AAL Packages / Integrated Solutions”
Contract nr: AAL-2017-
Start date: 01 June 2018
Duration: 36 months
D3.1. Data Privacy Regulations and Security Requirements
Nature1: R
Dissemination level 2: CO
Due date: Month: Month 12
Date of delivery: Month 15
Partners involved (leader in bold): ICI, UNRF, NIT, CTR, NIGG
Project Co-Funded by:
Project Partners:
[1] L = legal agreement, O = other, P = plan, PR = prototype, R = report, U = user scenario [2] PU = Public, PP = Restricted to other programme participants (including the Commission Services), RE = Restricted to a group specified by
the consortium (including the Commission Services), CO = Confidential, only for members of the consortium (including the Commission
Services)
2
Partner list:
No. Partner name Short name Org. type Country
1 National Institute for Research and Development in Informatics
ICI R&D Romania
2 Marche Polytechnic University MPU R&D Italy
3 University of Nicosia Research Foundation UNRF R&D Cyprus
4 National Institute of Telecommunications NIT R&D Poland
5 Connected Medical Devices CMD SME Romania
6 Automa Srl AUT SME Italy
7 Optima Molliter (f. Salvatelli) Srl SAL SME Italy
8 National Institute of Gerontology and
Geriatrics “Ana Aslan” NIGG R&D Romania
9 Comtrade Digital Services CTR Large enterprise Slovenia
Revision History
Rev. Date Partner Description Name
1 08.05.2019 NIT Created the template, added the sections and draft content
Piotr Krawiec, Jordi Mongay Batalla,
Waldemar Latoszek
2 20.05.2019 UNRF
NIT
Content added in sections Costas Constantinou, Piotr Krawiec, Waldemar
Latoszek
3 22.05.2019 ICI Content added in sections 3.3, 4.1 and 4.3 Ciprian Dobre, Lidia Bajenaru, Mihaela
Tomescu
4 10.06.2019 NCI Content added to section 4.3 Horacio González-Vélez
5 24.07.2019 CTR Health data protection regulation at Slovenia Gregor Molan
6 30.07.2019 NIGG
NIT
Content added in sections 4.2, 4.3 and Annex Anna Marie Herghelegiu, Costas Constantinou,
Piotr Krawiec, Waldemar Latoszek
Disclaimer:
The information in this document is subject to change without notice. Company or product names mentioned in this document may be
trademarks or registered trademarks of their respective companies.
All rights reserved
The document is proprietary of the vINCI consortium members. No copying or distributing, in any form or by any means, is allowed without
the prior written agreement of the owner of the property rights.
This document reflects only the authors’ view. The European Community is not liable for any use that may be made of the information
contained herein.
3
Contents 1. Introduction .................................................................................................................................... 4
2. EU health data protection regulations ............................................................................................ 5
3. Health data protection regulations at national level ........................................................................ 6
3.1 Cyprus ...................................................................................................................................................... 6
3.2 Poland ....................................................................................................................................................... 7
3.3 Romania .................................................................................................................................................... 9
3.4 Slovenia .................................................................................................................................................. 12
4. Security and privacy requirements for data protection in vINCI system ........................................ 13
4.1 eHealth standardization ........................................................................................................................ 13
4.2 Security and privacy requirements for vINCI ..................................................................................... 20
4.3 Security and privacy mechanisms considered for vINCI system ..................................................... 24
List of figures ....................................................................................................................................... 36
Bibliography ........................................................................................................................................ 36
Annex I ................................................................................................................................................ 39
vINCI Informed Consent Form Template (in English) .................................................................................... 40
Patient Information Sheet and Informed Consent Form (in Greek) .............................................................. 44
4
1. Introduction One of the fundamental rights of the European Union (EU) is the right to private life and the protection
of personal data, which is stated above all by articles 7 and 8 of the Charter of Fundamental Rights of
the European Union, article 16 of the Treaty on the Functioning of the European Union and article 8 of
the European Convention for the Protection of Human Rights and Fundamental Freedoms.
These rights must be guaranteed in each and every case, especially where sensitive data relating to
person health is involved. This is particularly relevant nowadays, where more and more medical devices
are connected to the network, and the number of various e-health applications is growing rapidly. There
is no doubt that collecting and then analysing a large amount of digital health data significantly improve
the efficiency and increase the range of health care services. On the other hand, most e-health
applications involve processing sensitive data, which may significantly affect the privacy of a person.
For this reason, many regulatory activities have been carried out in recent years to ensure the highest
possible level of privacy and security during the collection and processing of health data. The best-known
data protection laws at international level are HIPPA (Health Insurance Portability and Accountability
Act) [1.1] in US and GDPR (General Data Protection Regulation) [1.2] in EU. In fact, almost each country
nowadays has implemented its own regulation in this domain. The main principles of GDPR are
presented in Section 2 of this report, whereas national regulations applicable in countries involved in the
vINCI project are discussed in Section 3.
Considering the fact that more and more data are available in electronic form, and the ease (from
a technical point of view) with which they can be exchanged regardless of geographical distance, it is
essential to establish common rules for the exchange of electronic health data, also in terms of data
security. In this context, standards of medical informatics are essential.
Slow implementation of interoperable digital healthcare solutions in European countries remains a barrier
to make healthcare services more accessible at European and global level. At the same time, the rapid
adoption of smart technologies (such as Internet of Things, IoT) by health and social systems, more and
more open access to medical information, increasing citizens' accountability to their own health that gives
them a more active role in management their own health, bring new challenges for open interoperability
and for an improved and continuous integration of the health information in the provision of appropriate
medical services.
The maximum potential for supporting medical services with the help of digital solutions, can only be
achieved by practical and uniform implementation of e-health standards that:
• facilitate the interoperability of systems and devices,
• ensure the confidentiality and security of the data,
• facilitate the capture, exchange and use of data, information and knowledge about health.
As a result, the standards allow deploying all functional and logistical aspects of e-health systems in
a coherent way, and reducing costs. Therefore, developing international standards worldwide, involving
key players (such as governments, non-governmental organizations, healthcare professionals, or
professionals), is considered as a key factor in e-health domain. An overview of existing e-health
standards is presented in Section 4, together with a set of recommendations for the vINCI project based
on these standards.
5
2. EU health data protection regulations The EU General Data Protection Regulation (GDPR) no. 679/2016 on the protection of individuals with
regard to the processing of personal data and the free movement of such data and the repealing of
Directive 95/46 / EC [1.2], was passed in 2016 and enforced in May 2018. The rationale for having this
new law was twofold. First, to expand on the previous EU directive from 1995 ([2.1]) and to empower
people in order to have more control over their personal data in an era of technological development
when personal data has become more vulnerable. Second, to ensure that there is consistency between
the EU member states and a specific procedure is followed for the processing and protection of personal
data.
The law clarifies the following terms:
• Personal data: information about a person, which can potentially lead to identifying this person.
• Data concerning health ([2.2]): this is about data related to physical or mental health of an
individual.
• Data protection: Data protection has been recognised as a fundamental right included in the
The Charter of the Fundamental Rights of the European Union. Data protection refer to
individuals’ right to protect their data and that any processing of this data should be fair, serve a
specific and predetermined purpose and implemented on the basis of provided consent by the
individual.
• Data processing: This refers to any actions on personal data, including collection, recording,
organisation, structuring, storage, coding use, retrieve, erasure etc.
• Data controller: any entities (persons or organisations) which process personal data.
Data concerning health, and thus all data disclosing information on the past, present or future physical
or mental health of the data subject (including lifestyle-related information), belong to the category of
sensitive data. As a general principle, GDPR prohibits the processing of sensitive data, i.e. health-related
information as well as data revealing ethnic or racial origin, political views, religious beliefs etc. However,
the processing of sensitive data for health protection purposes is permitted.
The GDPR law is based on a number of principles ([1.2][2.2]) that must be taken into account when
processing personal health data:
• Transparency: Individuals have to be clearly informed about how their personal data will be
used, processed, for how long, erased and so forth. Such processing has to accord with
European Union and Member State laws.
• Processing has to be limited to the purpose of being processed in the first place. The purpose
has to be specific, clearly described and legitimate. The data cannot be used for other
purposes. However, for research purposes data can be re-used.
• The amount of data to be collected should reflect the purpose of the data being collected in the
first place. Data controllers should not ask for information which does not serve the purpose of
collecting and processing the data.
6
• Procedures should be in place to ensure that the collected data is accurate. Data controllers
should take relevant actions to correct any inaccurate data.
• The duration of storing the data should be specified and it should be for a limited period.
However, data for scientific research is exempted.
• Confidentiality should be ensured while there should be procedures in place with regard to the
safety of the data. Data should be pseudonymised.
• Individuals have the right to access and correct the personal data. Therefore, organizations
should have ways to ensure that individuals can exercise these rights.
• Individuals should provide informed and clear consent. For sensitive data, such as health-
related information, individual must provide clear consent by actively opting in, or taking
“affirmative action” such as ticking a box, for example. The absence of any form of action to
give consent, such as silence or inactivity, is not consent. Data controllers must be able to show
evidence that the individuals have provided consent. Because, consent has to be informed,
information should be provided in simple language. Before giving consent, individuals must be
informed about how to withdraw their consent.
• Any incidents of data breaching should be reported within 72 hours to the supervisory authority.
• Organizations must have a data protection officer.
On 25 April 2018, the European Commission adopted an Action Plan to enable the digital transformation
of health and healthcare in the Digital Single Market, which aims to place European citizens at the heart
of healthcare systems. The provisions of this plan include:
• Establish interoperable standards that reduce barriers to the cross-border transfer of health
information and data within the EU, identify incentives for adopting the common format and
address practices hampering interoperability.
• Support the development of common technical standards for the exchange of information for
research and public health purposes [2.3].
3. Health data protection regulations at
national level This chapter presents national regulations and requirements related with health data processing and
storage, which apply in the countries of Project partners directly involved in the vINCI pilot studies.
3.1 Cyprus
Data protection in Cyprus is monitored by the Office of Commissioner for Personal Data Protection [3.1]
and strictly reflects the EU General Data Protection regulation (GDPR) enforced in May 2018.
In order to abide by the GDPR regulations, the following actions will be taken in Cyprus with regard to
the implementation of WP4 for vINCI project:
7
• All participants will be clearly informed about the purpose of the pilot study, the reasons why they
have been selected, how they will split into two groups, the duration of the study, the exact
information they will need to provide, for how long their data will be kept and how the data will be
erased. Participants will be informed orally and in writing.
• Processing of participants’ data will be limited to the purpose of the pilot study. That is, to evaluate
participants’ acceptability of vINCI technology. Within the context of WP4, participants’ data will
not be used for any other purposes.
• Participants will be informed about which information they will be asked to provide and give
consent for collecting data. The amount of data will reflect the purpose of the pilot study under
WP4. No information that is not relevant to the objectives of the pilot study will be collected.
• Data will be collected through validated technology. On this note, the collected data will be
accurate.
• Data will be kept until the completion of project and publication of pilot study.
• Confidentiality will be ensured through-out the pilot study in Cyprus. The following procedures
will be in place: (1) Data will be pseudonymised and questionnaires or data sets will be coded.
(2) Access to the tablet for completing the questionnaires and to the software will be password
protected. Only the researchers from the University of Nicosia Research Foundation (UNRF) will
know the passwords and thus have access.
• Participants will be granted rights to access and correct their data obtained through
questionnaires. Participants will be informed, via the informed consent form, that they inform the
UNRF researchers should they need to review their personal data.
• Participants will be invited to provide informed and clear consent. Because researchers will be
collecting sensitive data, the informed consent form will include clear information in simple
language about all aspects of the pilot study including participants’ rights. In addition, the form
will include statements which participants can take affirmative action (i.e. tick a box) to answer
and sign. Participants will be informed that their participation is entirely voluntary and that they
can withdraw their consent any time they wish, by notifying the researchers, without and adverse
consequences.
• The Commissioner for Personal Data Protection in Cyprus will be notified within 72 hours in case
of incidents of data breaching. The data protection procedure will be monitored by the University
of Nicosia Data Protection Officer who will review any complaints by the participants.
• An application will be submitted to the Cyprus National Bioethics Committee (CNBC) for review
and approval before WP4 pilot study starts in Cyprus.
3.2 Poland
In Poland, the main act that regulates the rules on the processing of personal data is Act of 10 May 2018
on the Protection of Personal Data [3.2]. The purpose of this Act is to ensure the application of the EU
General Data Protection Regulation in Poland. The Personal Data Protection Act established a new
supervisory authority: President of the Office of Personal Data Protection (UODO – Urząd Ochrony
Danych Osobowych) [3.3], that replaced the former Inspector General for Personal Data Protection.
At the end of 2018 two codes of conduct for health industry have been submitted to the UODO Office.
The purpose of these codes is to clarify the provisions of the GDPR and to make it easier for personal
8
data controllers to interpret them. At present, both codes are still being processed by the UODO and
have not yet been accepted and published.
So, in general, in case of Poland the data protection rules imposed by GDPR apply. Moreover, in addition
to UODO and GDPR regulations, the obligation to secure medical data is imposed by the regulation of
the Council of Ministers regarding the minimum requirements for public registers, exchange of
information in electronic form and minimum requirements for ICT systems [3.4].
On the other hand, the obligations and time limits for keeping patients’ medical records are specified by
another act: the Act on Patients’ Right and the Commissioner for Patients’ Rights [3.5]. This act imposes
that in certain cases (for example in case of the entity performing the medical activity) health data must
be kept for at least 20 years. Consequently, the right to erasure (“right to be forgotten”) provided by
GDPR applies only if the time limits indicated in the Act on Patients’ Right expires. However, these
restrictions do not cover medical data stored for scientific research.
The entity responsible for monitoring and supervising the national e-health systems is National Centre
for Health Information Systems CSIOZ (in Polish: Centrum Systemów Informacyjnych Ochrony Zdrowia),
which is a division of the Polish Ministry of Health. CSIOZ has implemented and manages the System
P1: Electronic Platform for handling digital information about medical events (in Polish: "P1:
Elektroniczna Platforma Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach
Medycznych"), which is an electronic platform dedicated for public health services. System P1 enables
public authorities, including municipal administrations as well as business entities and private individuals,
to collect, analyze and share digital resources related to different medical issues.
To ensure seamless cooperation with System P1, as well as compliance with applicable regulations,
CSIOZ published a set of recommendations which should be used by entities involved in the processing
of health data in Poland [3.6] (the recommendations are mandatory for health data processing systems
developed by public entities). In summary, the main recommendations are as follows:
• Personal data should be processed according to GDPR (see Section 2).
• The security and privacy of patient health data needs to be ensured; it can be achieved by
different mechanisms and procedures such as:
o Monitoring execution time to avoid replay attacks;
o Ensuring that communication over the Internet relies on an encrypted channel;
o The peer communicating systems mutually authenticate each other;
o Saving security events logs for forensic analysis;
o User authentication jointly with her/his security privileges, to provide input data to
access control mechanisms;
o Taking into account the patient privacy consent permissions when accessing patient
health data;
o Storage of health data in encrypted form;
o Effective cryptographic keys management procedures, including methods of secure key
release as well as recovery of encrypted data in case of loss or damage to keys;
9
o Ensuring the integrity of the content of medical records, based on mechanisms that
prevent changes of health data, except for changes made as part of established and
documented procedures;
o Ensuring physical security solutions, such as access control systems, anti-intrusion
systems or video monitoring, to deny unauthorized access to facilities, equipment and
resources in the areas where health data are processed;
• Exchanging health data between systems needs to be performed using HL7 2 messaging
standard and HL7 3 CDA (Clinical Document Architecture) specification for the structure and
semantics of medical documents, and DICOM standard in case of medical imaging information;
• Polish platforms dedicated for the collection and exchange of medical data need to use IHE
profiles. Taking into account security and privacy requirements mentioned above, the
recommended IHE profiles are, among others:
o Consistent Time (CT);
o Audit trail and node Authentication (ATNA);
o Cross-Enterprise User Assertions (XUA);
o Basic Patient Privacy Consent (BPPC);
o Advanced Patient privacy Consent (APPC);
• Formalised rules for managing IT security incidents should be introduced. The rules cover
recognition of incidents, their logging, analysis, prioritization, searching for correlations, taking
corrective actions and removing the causes.
In March 2019, an electronic ID card (eID) was implemented in Poland, which provides the citizen with
an individual certificate for digital signature. Nevertheless, at the moment there is no obligation for
patients to digitally sign electronic documents that contain her/his health data. However, the digital
signature is allowed and recommended to ensure a strong non-repudiation of medical documents.
3.3 Romania
Legislation on the collection of personal data and security requirements
In Romania, the National Authority for Personal Data Processing Supervision (ANSPDCP - Autoritatea
Naţională de Supraveghere a Prelucrării Datelor cu Caracter Personal) [3.7], as an autonomous central
public authority with general competence in the field of personal data protection, is the guarantor of
observance of the fundamental rights to private life and the protection of personal data. ANSPDCP aims
at protecting the right to intimate, family and private life with regard to the personal data processing.
Principles of personal data processing, legality of personal data processing, security of personal data
processing and other information extracted from EU General Data Protection Regulation (GDPR) are
provided by the Ministry of Health website [3.8]. They are as follows:
1. Principles of personal data processing
The personal data are:
• Processed legally, fairly and transparently to the data subject (legality, fairness and
transparency);
10
• Collected for determined, explicit and legitimate purposes and not subsequently processed in
a way incompatible with these purposes; further processing for purposes of archiving in the
public interest, for purposes of scientific or historical research or for statistical purposes is not
considered incompatible with the original purposes (purpose limitations);
• Adequate, relevant and limited to what is required in relation to the purposes for which they are
processed (minimization of data);
• Accurate and, if necessary, up-to-date; all necessary steps must be taken to ensure that
personal data which are inaccurate, given the purposes for which they are processed, are
erased or rectified without delay (accuracy);
• Kept in a form that allows the identification of the data subjects for a period not exceeding the
time required for the purposes for which the data are processed; personal data may be stored
for longer periods to the extent that they will be processed solely for purposes of archiving in
the public interest, for purposes of scientific or historical research or for statistical purposes;
• Processed in a way that ensures the proper security of personal data, including protection
against unauthorized or illegal processing, and loss, destruction or accidental damage by
taking appropriate technical or organizational measures (integrity and confidentiality).
2. Legality of personal data processing
Processing is legal only if and to the extent that at least one of the following conditions applies:
• The data subject has given her/his consent to the processing of her/his personal data for one
or more specific purposes;
• Processing is required to execute a contract to which the data subject is a party or to take
action at the request of the data subject prior to the conclusion of a contract;
• Processing is necessary to fulfill a legal obligation on the operator;
• Processing is necessary to protect the vital interests of the data subject or other individual;
• Processing is necessary for the legitimate interests pursued by the operator or a third party,
unless the interests or fundamental rights and freedoms of the data subject are prevalent.
3. Security of personal data processing
In view of the current state of development, the costs of implementation and the nature, the scope, the
context and the purposes of the processing, and the risk with different degrees of likelihood and severity
for the individual's rights and freedoms, the operator and the person empowered by it implement
technical and organizational measures appropriate to ensure a level of security appropriate to that risk,
including, where appropriate, the following:
• Pseudonymisation and encryption of personal data;
• The ability to ensure the continuous confidentiality, integrity, availability and resilience of
processing systems and services;
• The ability to restore the availability of personal data and the access to them in a timely manner
if a physical or technical incident occurs;
11
• A process for periodically testing and evaluating of the effectiveness of technical and
organizational measures to guarantee the security of processing.
National eHealth standardization
In Romania, the regulatory body for standardization is ASRO - the "Romanian Standardization
Association", a Romanian legal entity of private law, of public interest, non-profit, non-governmental
and apolitical, constituted as a national standardization body based on the provisions of GO 39 / 98 and
Law No. 355/2002, recognized as a national standardization body by GD 985/2004 and operating under
Law 163/2015 on national standardization.
ASRO represents Romania in the process of European and international standardization and
coordinates the national standardization activity so that the standardization system contributes to the
achievement of the strategic objectives of the national economy, especially in the field of industrial policy,
services, innovation and technological development.
ASRO is a full member of CEN and CENELEC - European Committee for Electrotechnical
Standardization; is an observer member of ETSI - European Telecommunications Standards Institute
and member of ISO - International Organization for Standardization and IEC - International
Electrotechnical Commission. The TC 319 technical committee for standardization in medical informatics
was set up within ASRO.
The HL7 Association of Romania [3.9] aims to establish an information health infrastructure compatible
with similar European structures based on a partnership between the governmental sector, public
education and the private sector.
The main objectives of the HL7 Romania Association consist in:
• Educating all those working in the healthcare system in Romania, including the medical
informatics system developers, regarding the HL7 standards and their promotion in order to
apply them efficiently and consistently on the Romanian territory;
• Identifying and analyzing the business requirements of the Romanian healthcare system
regarding the electronic communication of medical information;
• Adaptation (localization) of HL7 standards to national requirements and, if necessary,
identification of specific elements for Romania, implementation profiles and guides.
The HL7 Romania Association provides its members with:
• Information on HL7 standards in an accessible and intelligible manner to those active in
healthcare in Romania through the http://www.hl7romania.ro/ website: relevant documents,
links, tutorials, publications and occasional studies books;
• Courses and specializations for IT application developers, medical organizations and health
professionals, with the release of graduation certificates at the end;
• Preferential access to educational activities and standard information, with substantial
reductions.
12
3.4 Slovenia
Health data protection in Slovenia is regulated with the Law about the patient rights (ZPacP-A – Zakona
o pacientovih pravicah). The last update of this law was on October 4th, 2017 (valid 3 months after this
date).
Relevant regulations from the ZPacP-A for the vINCI project are articles 31a and 48.
Article 31a, item (8)
Healthcare providers shall keep a record containing the following information for the purpose of
monitoring the application of the special safeguard measure:
• the name of the healthcare provider,
• the personal name and the Social Security Number (EMŠO) of the patient, in which a special
precautionary measure was applied,
• the reason for the introduction of a special safeguard measure,
• the duration of the special safeguard measure (date and time of introduction and cessation of
implementation of the measure),
• the personal name and code of the healthcare professional who has introduced a special
safeguard measure,
• the personal name of the immediate family member or person close to him and his relationship
with the patient and the personal name of the patient's representative, who was informed of the
introduction of a special safeguard measure.
Article 48, item (7)
The ministry responsible for health, with the purpose of identifying, preventing and eliminating possible
professional errors or systemic deficiencies and monitoring of court proceedings initiated due to death
or serious bodily injury sustained by a patient during medical treatment, from a healthcare provider or
other participants in the judicial process obtain information and keep a record containing the following
information:
• the name of the healthcare provider against whom the procedure is initiated,
• the personal name of the applicant who initiated the proceedings,
• the date of commencement of the procedure,
• the reason for initiating the procedure (legal basis) and the alleged infringement, including the
lawsuit or criminal charge,
• the registration number of the procedure,
• the date and method of resolving the case and the judgment.
13
4. Security and privacy requirements for
data protection in vINCI system
From the point of view of the EU General Data Protection Regulation, medical data is considered to be
sensitive data. Medical information is one of the most targeted cybercrime targets due to the
concentration of confidential personal information such as identity, contact details, billing data, medical
history etc.
In this chapter we presents the requirements for ensuring the security and privacy of medical information.
The first section contains a review of the standardization concerning the proper processing of medical
data. The next section presents a set of requirements for the secure processing of medical data, with
privacy protection, that are related to the vINCI system. The last section describes some of security and
privacy mechanisms considered for vINCI system.
4.1 eHealth standardization
According to the International Standards Organization (ISO), a standard is a document approved by
consensus by a recognized organization. It provides rules, protocols, and features that can be commonly
used by entities in the same domain to achieve maximum optimization in a particular context.
The standardization of medical informatics refers to the principles of information processing,
management and governance by providing solutions to related health and care issues.
Entities interested in the development and large scale implementation of standards in the field of medical
informatics are [4.1]:
• Academic and research institutes in the field of health informatics;
• Public / governmental agencies with eHealth-based programs or responsible for developing
and / or implementing healthcare policy;
• Authorities regulating and certifying products and systems for the provision of health services;
• Health service providers and clinical practitioners (as users);
• Health information managers;
• Health service sponsors - including health insurers, non-governmental organizations etc.;
• Clinical and pharmaceutical researchers;
• Developers, providers and integrators of Health Information Systems (HIS), applications and
services.
The main organizations involved in the standardization of health informatics are (see Figure 4.1):
• ISO - International Organization for Standardization; Technical Committee TC 215 - Health
Informatics. ISO/TC 215 includes the following working groups:
• CEN - European Committee for Standardization, TC251;
14
• HL7 - Health Level 7;
Other institutions active in this area are:
• EHTO - European Health Telematics Observatory;
• ETSI - European Telecommunication Standards Institute;
• ASTM - American Society for Testing and Materials, Committee E-31;
• OpenEHR - Open Electronic Health Record Foundation;
• IEC - International Electrotechnical Commission;
• IMIA - International Medical Informatics Association;
• UN/EDIFACT - United Nations directories for Electronic Data Interchange for Administration,
Commerce and Transport.
Figure 4.1 Bodies involved in standardizing the medical field [4.2]
a. ISO/TC215
At the global level, the most important organization involved in standardization is ISO, the medical field
being the responsibility of TC 215 technical committee. It includes the following working groups:
o ISO/TC 215/WG1 - Health Records and Information Modelling Coordination;
o ISO/TC 215/WG2 - Messaging and Communications;
o ISO/TC 215/WG3 - Health Concept Representation;
o ISO/TC 215/WG4 - Security;
o ISO/TC 215/WG5 - Health cards;
15
o ISO/TC 215/WG6 - Pharmacy and medication business.
ISO 27799
ISO 27799 (Health informatics - Information security management in health using ISO/IEC 27002) [4.3]
is an international standard that guides health industry organizations on how to protect personal health
information on the basis of ISO/IEC 27002 standard [4.4]. ISO 27799 provides information dedicated to
healthcare sector on how to protect the confidentiality, integrity and availability of personal health data.
ISO 27799 is a part of the ISO/IEC 27000-series that consists of information security standards published
jointly by the International Organization for Standardization (ISO) and the International Electrotechnical
Commission (IEC). ISO 27799 applies ISO/IEC 27002 specifically to the healthcare industry with special
attention to the challenges of this sector. As a consequence, ISO 27799 doesn’t substitute ISO/IEC
27000, but it is the complement to this more generic standard. ISO/IEC 27002 provides guidelines for
information security controls for initiating, implementing or maintaining information security management
systems.
Personal health information is considered to be among the most confidential of all types of personal
information. Consequently, assuring privacy of this information is the matter of great importance for
patients. Moreover, the protection of the integrity of health information is critical to ensure patients safety.
Additionally, the effective healthcare requires availability of health information to be sustained. Thus ISO
27799 aims to facilitate maintaining confidentiality, availability, and integrity (including authenticity,
accountability and auditability) of personal health information.
ISO 27799 standard offers guidance on the 14 security control clauses, 35 main security categories and
114 controls specified in ISO/IEC 27002. This standard provides Control descriptions containing the
following parts:
• Health-specific control - statement that satisfies control objective (as stated in ISO/IEC 27002)
• Health-specific implementation guidance - detailed information that help to deploy control in a
healthcare environment to protect the confidentiality, integrity and availability of personal health
information.
• Other health-specific information – further information (health-specific) that should be
considered.
ISO 27799 standard covers the following control clauses:
• Information security policies
• Organization of information security
• Human resource security
• Asset management
• Access control
• Cryptography
• Physical and environmental security
• Operations security
• Communications security
• System acquisition, development and maintenance
• Supplier relationships
• Information security incident management
• Information security aspects of business continuity management
16
• Compliance
Moreover ISO 27799 standard contains the following 3 informative annexes:
• Threats to health information security
• Practical action plan for implementing ISO/IEC 27002 in healthcare
• Checklist for conformance to ISO 27799
In the Communications security control clauses the standard covers two main security categories:
Network security management and Information transfer. The aim of the Network security management
is to “ensure the protection of information in networks and its supporting information processing facilities”
and it consist of the following: Network Controls, Security of network services, Segregation in networks.
The guidance applies appropriate parts of ISO/IEC 27002 with the “health-specific implementation
guidance” for Control saying that impact of the loss of network availability on the clinical practise should
be care be carefully considered. The aim of the Information transfer is to “maintain the security of
information transferred within an organization and with any external entity” and it consist of the following:
Information transfer policies and procedures, Agreements on information transfer, Electronic messaging,
Confidentiality or non-disclosure agreements. The guidance applies appropriate parts of ISO/IEC 27002
with the following “health-specific implementation guidance” (and additionally some “other health-specific
information”):
• For Information transfer policies and procedures saying that
o the security of information exchanges (1) are the subject of policy development and
compliance audit and (2) can be assisted by the use of information exchange
agreements specifying the set of controls to be implemented;
o attention should be given to the usability of cryptographic tools.
• For Electronic messaging saying that:
o personal transmitting health information by electronic messaging should take steps to
ensure its confidentiality and integrity;
o E-mail message containing personal health information should be encrypted.
• For Confidentiality or non-disclosure agreements saying that organizations processing
personal health information must have a confidentiality agreement.
Notice that ISO 27799 together with ISO/IEC 27002 are technology-neutral, that is the standards specify
only what is need in terms of information security in healthcare, but they don’t say how it is to be
accomplished. This is done to enable the standard to stay valid while the technologies can rapidly
change.
ISO/DTR 20514 “Integrated Care EHR”
It refers to electronic information collection on a patient's health, stored and transmitted safely and
accessible to any authorized user. It has implemented a logical model of information organization,
universally recognized and independent of the system. It has as main purpose the continuous, efficient
and quality assurance of integrated health services and contains retrospective, concurrent and
prospective information.
ISO / TR 14639: 2014
It provides a guide to the requirements and business principles of best practices for countries and
subordinate health authorities that plan and implement the use of information and communication
17
technology (ICT) to support the delivery and development of healthcare. A business reference
architecture is described in terms of components and capabilities that health authorities can use as a
framework for building their own eHealth architectures and also for measuring the degree of maturity of
use by their systems health of ICT to support the delivery and development of healthcare.
ISO / TR 14639: 2014 also proposes a model of maturity and methodology that organizations can take
into account in developing and evolving their eHealth capabilities in specific areas of operational capacity
from low to medium levels. The proposed business benchmarking architecture identifies the components
and capacities needed to support the various health services, along with the governance infrastructure
and ICT needed for efficient and effective use of information in the delivery and development of health
services [4.5].
ISO / TS 14265: 2011
ISO / TS 14265: 2011 Health Informatics - The classification of the purposes for which personal health-
related information is processed defines a range of high-level categories of purposes in which personal
health information can be processed.
The ISO 14265: 2011 Standard provides a framework for the classification of various specific purposes
that can be defined and used by some distinct domains (health organizations, regional health authorities,
jurisdictional bodies) as help in systematically managing information when providing health services and
for communicating electronic health records between different organizations and jurisdictions [4.6].
b. CEN/TC 251
In Europe, standardization is being carried out within the CEN (Comité Européen de Normalization),
which has been operating since 1991 as TC251 Technical Committee for Medical Informatics.
CEN/TC 251 provides and maintains standards in the field of medical informatics for Europe, preferably
by developing them in collaboration with other standards-setting organizations globally and by adopting
standards of other such organizations.
In the context of wanting to adopt a smaller number of standards of medical informatics but more
universally, CEN/TC 251 is still trying to get more involved with other standards, consortia and fora have
similar objectives.
The trend is to reach a consensus between CEN/TC 251, which develops standards at European level
and HL7, headquartered in the US but with many subsidiaries in Europe.
The standards relevant to eHealth are:
• CEN TS Data Types;
• CEN/TC 251 EN EHR Communications.
CEN ISO / IEEE 11073 Healthcare Informatics - Healthcare communication technologies / health
technologies standards allow the communication between medical, healthcare and health-care
devices used to achieve a healthy lifestyle and external information systems. They provide automatic
and detailed collection of electronic data, customer information, vital signs and operational device data.
18
c. HL7
Founded in 1987, Health Level Seven International (HL7) is a non-profit organization accredited by
American National Standards Institute (ANSI). Its purpose is to develop a comprehensive framework
and related standards for the exchange, integration, sharing and recovery of health electronic information
that support medical practice, as well as the management, provision and assessment of health services.
HL7 is supported by over 1,600 members from over 50 countries [4.7].
“Seven Level” refers to the fact that these standards are at level 7 of the network communication
protocols hierarchy, called “application level”. The application level directly interfaces application
processes and provides common services for them.
The HL7 standard aims to create unique ways of transmitting medical information in a common format
by defining structure of information that is transmitted. It contains data sharing and security exchange
functions that are involved in the flow of activities that make up patient relationship management.
The HL7 provides EHR Functional Specification, templates specification, and standard for Clinical
Document Architecture (CDA). Generally, we assume that the HL7 CDA compliant medical document
has the following properties that affect the system security requirements:
• persistence - a medical document cannot be changed after its issuance, it can at most be used
as an attachment to other documents, as a result of which, it does not lose the other features
listed below;
• possibility of management - the custodian takes care over the document, which is the institution
storing the document. The custodian cares for the correct versioning of the document and its
sharing;
• potential for authentication - the standard does not specify the rules of electronic signing of a
medical document, only the flag in the document is used to inform about the existence of an
external signature. Despite this, it is acceptable signing documents compliant with HL7 CDA
using one of the standards of electronic signatures.
d. DICOM
DICOM - the acronym for Digital Imaging and Communication in Medicine - is the industry standard for
transferring medical images and for communicating between electronic medical devices. The standard
was developed in collaboration with the American College of Radiology (ACR) - responsible for technical
and medical supervision - and the National Electrical Manufacturers Association (NEMA) - responsible
for supervising legal issues and publishing the standard.
All medical imaging storage and transmission systems (PACS) must comply with the DICOM standard,
which at present remains only a desideratum due to the high costs involved [4.8].
e. HIPAA
The US Health Insurance Portability and Accountability Act (HIPAA) aims to ensure the confidentiality
and security of data for the protection of medical information. All physicians and healthcare providers
19
(pharmacies, hospitals, insurance institutions) are identified by unique numbers, and in 2013 business
associations providing medical services or healthcare are also included. From the American perspective,
standards applied to health information systems are very important for ensuring information security, but
also for ensuring the interoperability of systems that use them.
These standards refer to:
• Encrypting medical data and storing it;
• Architecture of clinical documents;
• Authentication and authorization of the user of medical data;
• Distribution of clinical information within the same medical unit as well as financial and
administrative information;
• Communication between a medical unit and other systems [4.9].
f. HITRUST Alliance
HISTRUS is an organization focused on developing the Common Security Framework (CSF) platform,
which can be used as a platform for the exchange of medical data by entities from various industries
(e.g. health care). The CSF standard [4.10] defines a number of controls in the field of medical data
security. For example, the Control Reference: Network Connection Control, presented in CSF,
recommends that network access rights of users shall be maintained and updated as required by the
access control policy. The connection capability of users shall be restricted through network gateways
and traffic shall be filtered by means of pre-defined tables or rules. The organization shall limit the number
of access points to the information system, to allow for more comprehensive monitoring of inbound and
onbound communications and network traffic. The organization shall:
• implement a management interface for each external communication service;
• establish a traffic flow policy for each management interface;
• employ security controls as needed to protect the confidentiality and integrity of the information
being transmitted.
Moreover, the organization shall use strong cryptography and security protocols, such as SSL/TLS or
IPSEC to protect information during transmission over open, public networks (Internet, wireless
technology, GSM).
The Control Reference: Information Exchange Policies and Procedures defines the rules for secure data
transfer. The cryptography shall be used to protect the confidentiality and integrity of remote access
sessions to the internal network and external systems.
g. NIST
The National Institute of Standards and Technology (NIST) is a non-regulatory U.S. agency that
developed set of approved cybersecurity recommendations called NIST Cybersecurity Framework. In
the area of data protection (including sensitive data), NIST Cybersecurity Framework provides the
Recommendation for Key Management - Part 3: Application-Specific Key Management Guidance [4.11],
which presents recommendations on ensuring security for IT system developers, administrators and
20
users. The recommendations are given for selected set of applications, namely: Public Key
Infrastructures (PKI), Internet Protocol Security (IPsec), Transport Layer Security (TLS),
Secure/Multipurpose Internet Mail Extensions (S/MIME), Kerberos, Over-the-Air Rekeying of Digital
Radios (OTAR), Domain Name System Security Extensions (DNSSEC), Encrypted File Systems (EFS),
and Secure Shell (SSH).
4.2 Security and privacy requirements for vINCI
This section presents security and privacy requirements that need to be implemented in vINCI system,
to comply with regulations and standards regarding the collection and processing of medical data.
In general, electronic medical data is properly secured if the following conditions are met in a continuous
manner:
• the data accessibility is guaranteed only to authorized persons,
• the data is protected against accidental or unauthorized destruction.
In such a case, the concept of secure processing of electronic medical records should be identified with
the concept of 'information security' used in the field of ICT security. According to ISO/IEC 27001
standard [4.12], information security should be understood as maintaining confidentiality, integrity,
availability, accountability, authenticity, non-repudiation and reliability. These terms are explained below:
• confidentiality – ensuring that the data is not shared or disclosed to unauthorized persons,
entities or processes;
• integrity – ensuring that the data has not been altered or destroyed in an unauthorized manner;
• accessibility – ensuring that the data is accessible and usable on demand, at the assumed
time, by an authorized entity;
• accountability – ensuring that the entity's activities can be unambiguously assigned only to that
entity;
• authenticity – ensuring that the identity of the entity or resource is as declared (authenticity
applies to users, processes, systems and information);
• non-repudiation – the inability to deny its participation in all or part of the data exchange by one
of the entities participating in this exchange;
• reliability – ensuring consistency and intended behaviour and effects.
It should be noted that ensuring and then demonstrating certain properties often requires the use of
specific means and simultaneous fulfilment of many conditions.
Taking into account the state of technical knowledge, the cost of implementation as well as the nature,
scope and purposes of data processing, and also the risk of violation of the rights of patients with different
probability and severity of threats resulting from data processing, the project should implement
appropriate technical and organizational measures, such as pseudonymisation and encryption
(Req#1). These measures should be designed to effectively implement data protection principles, such
as data minimization, and to give processing the necessary safeguards to meet the requirements of the
GDPR and protect the rights of data subjects.
21
As defined in the GDPR, "pseudonymisation" means the processing of personal data in such a way that
it can no longer be attributed to a specific data subject without the use of additional information. Such
additional information is stored separately and subject to technical measures and organizational
preventing them from being assigned to an identified or identifiable natural person. It should be noted
that pseudonymisation is not synonymous with anonymisation because anonymisation is, in principle,
an irreversible process.
Taking into account technical measures, as well as the scope and purpose of medical data processing,
the recommended pseudonymisation method is tokenization: all attributes enabling identification of a
person (e.g. name, address, date of birth) will be replaced with a random identifier (token). More
information about the pseudonymization process is provided in subsection 4.3.
The GDPR also lists data encryption as appropriate security in addition to pseudonymisation. Encryption
is the process of transforming data into an incomprehensible string to keep it secret. Depending on
whether we use, in the decryption process, the same or other key that was involved in the encryption
process, we can distinguish a cryptographic system with a secret key (symmetric encryption) and a
cryptographic system with a public key (asymmetric encryption).
For the needs of the pseudonymization process, as well as security of access to data, it is necessary to
provide an appropriate way to manage cryptographic keys (Req#2), including methods for secure key
sharing, recovery of encrypted information in the event of loss and breach of security or damage to keys.
Thanks to cryptographic technology enabling the division of user's private keys, there are mechanisms
that prevent access to data by unauthorized persons even if the credentials are taken over.
It is recommended to choose the encryption algorithms, key lengths and application practices
according to best practices (Req#3). Proper key management requires secure processes for
generating, storing, archiving, recovering, distributing, withdrawing and destroying cryptographic keys.
An important feature is ensuring physical security (Req#4). Therefore, in the field of physical
protection, consideration should be given to designating safe areas with restricted and controlled
personnel access. Considering the nature, scope and purposes of medical data processing, it is
necessary to ensure at least that the area in which medical data is processed, should be protected
against access by unauthorized persons during the absence of persons authorized to process the data
(closed doors, windows secured using grilles, blinds or anti-burglar film etc.).
In the case of vINCI project, a critical area of security is a server room, where IT equipment for data
processing and storage is located. The minimum requirements associated with this secured area are:
1. The area must be equipped with an access control system to prevent access by unauthorized
persons (e.g. doors that meet certain security requirements) (Req#4.1).
2. The area must have an air conditioning system ensuring the required temperature and humidity
(Req#4.2).
3. The area must have a fire protection system with an alarm system (Req#4.3).
4. The area must have protection against power loss (Req#4.4).
5. The area should be placed in a place with minimal risk of flooding (Req#4.5).
22
6. The area should be placed at a safe distance from flammable materials that are potentially explosive
(Req#4.6).
7. The area must be equipped with a lightning protection system (Req#4.7).
Another important factor is the security of network infrastructure and network services that guarantee
protection against unauthorized access. To this end, the network architecture of the vINCI platform
should ensure the separation of appropriate zones (Req#5) adapted to applications and services
running in a given zone. The zones should be separated using firewalls and routers. It is recommended
that at least the following zones should be separated:
• DMZ (Demilitarized Zone) – this is a limited trust zone in which servers providing services to
external users (e.g. WWW servers) are located. The servers in this zone do not have direct
access to the internal network in which the vINCI system is running (Req#5.1);
• Secured Zone – this is a zone that is highly protected, among others, by the use of appropriate
firewall configurations. It is not possible to directly access the servers/applications located in
this zone from the Internet. Access is possible only for defined hosts and services. The vINCI
system under which medical data are processed, should work in this zone (Req#5.2).
The network architecture should consider implementing mechanisms of comprehensive network
protection against intrusion. It is recommended to use at least the following protection mechanisms
(Req#6):
• IPS (Intrusion Prevention System),
• the firewall,
• network antivirus filter.
In addition, devices on which the software for processing and storing data within the vINCI system will
be run, should be provided with physical and logical protection of remote diagnostic and devices’
configuration ports (Req#7).
Taking into account security of the logical layer of the network, it is necessary to separate subnets (in
layers 2 and 3 of the ISO/OSI model), and apply appropriate filtration and traffic management
mechanisms (Req#8). The vINCI system should be placed in a secure area (Secured Zone) excluding
the necessary communication modules located in the DMZ, enabling data exchange with vINCI Kits. In
the case of communication via an external network, strong mechanisms are required to guarantee the
protection of transmitted data, their integrity, confidentiality and non-repudiation (using, for example, the
SSL 3.0 / TLS 1.2 protocols) (Req#9).
In the case of securing network services, authorization procedures should be implemented specifying
who is authorized to access the network and network services - access to services should be
possible only for authorized users/devices by providing authentication and authorization mechanisms
(Req#10).
With regard to the security of applications that constitute the vINCI system, access to individual
applications must require a user ID and authentication (password, authentication certificate)
(Req#11). The application functionality available to individual users should be limited by the user's
23
rights (Req#12). Sessions of system users should be blocked after a configured period of inactivity
(Req#13). The system architecture should include solutions that eliminate or significantly reduce the
system's vulnerability to attacks, as recommended in the Open Web Application Security Project -
OWASP Top 10. Some of them can be implemented at the application level by using secure tools,
libraries and algorithms (Req#14).
When a client-server application is used, it is required to provide communication security, e.g. by
using the SSL (HTTPS) protocol (Req#15).
In addition, it is recommended to conduct security tests of the vINCI system in accordance with current
guidelines, e.g. OWASP for web applications (Req#16). These tests should be carried out at least before
implementing the viNCI platform. Moreover, the environment in which the platform will be installed should
have the latest security updates (Req#17) - this applies to operating systems, web / application
servers, databases, etc.
Ensuring the security and confidentiality of data in the vINCI system requires the implementation of
appropriate mechanisms to manage permissions and access control to data and/or functions
(Req#18). Access control should in particular fulfill the following tasks and have the following
functionalities:
• access to applications or data is only possible after the authentication process (Req#18.1);
• user rights should be granted to the minimum possible extent (Req#18.2);
• the system administrator grants rights, based on the application approved by the person
representing the Project Partner (Req#18.3);
• access passwords must be strong enough (at least 8 characters, contain uppercase and
lowercase letters and numbers or special characters) (Req#18.4);
• the password can’t be sent in plain text (Req#18.5).
Informed Consent Form
As it is described in Chapter 2, collecting and processing personal data, according to the GDPR, requires
prior consent from a patient (Req#19). This consent applies to participation in clinical trials (when the
patient is monitored using the entire vINCI system), as well as to the testing of a single component
(SmartWatch, Smart Insoles, Depth Cameras etc.), to ensure that patients’ data processing is legal and
that the service is properly regulated. Templates of the consent forms prepared for vINCI studies are
presented in Annex I.
Personal Data Processing Activities Register
According to the Article 30 of GDPR, we need to keep an internal record with the information of all
personal data processing activities carried out within the project (Req#20). Because the vINCI platform
is established using NIT R&D infrastructure (PL-LAB), the record will be stored in NIT’s data processing
activities register.
The following information will be included in the record:
24
• the administrator's name and contact details (NIT employee involved in the vINCI project) as
well as NIT’s Data Protection Officer.
• The purposes of processing (conducting research for the needs of the vINCI project).
• Description of the categories of data subjects and the category of personal data (the data
related to physical and mental health of monitored persons - older adult; personal information
which includes both medical and administrative data);
• categories of recipients to whom personal data will be disclosed (members of the project
international consortium: research institutes, universities and companies involved in the
implementation of the vINCI system);
• planned dates for the deletion of personal data (the data will be removed after the end of the
project, unless the consortium undertakes new activities to continue the research);
• a general description of the technical and organizational security measures of the vINCI
platform.
4.3 Security and privacy mechanisms considered for vINCI system
Solutions for anonymity, data integrity, and security for transfer and data access in order to
address the issues related to personal data collection
Among the arsenal of IT security techniques available, pseudonymisation or anonymisation is highly
recommended by the GDPR regulation. Such techniques reduce risk and assist “data processors” in
fulfilling their data compliance regulations. If it can be proven that the true identity of the individual cannot
be derived from anonymised data, then this data is exempt from other methods ensuring the strict
confidentiality of the actual data. The two techniques differ and in face of the GDPR the choice will
depend on the degree of risk and how the data will be processed.
Pseudonymisation
Pseudonymisation is a data management and de-identification procedure by which personally
identifiable information fields within a data record are replaced by one or more artificial identifiers, or
pseudonyms. A single pseudonym for each replaced field or collection of replaced fields makes the data
record less identifiable while remaining suitable for data analysis and data processing.
The personal data is any information that can be used to directly or indirectly identify a person. For
example: name, home address, photo, email address, bank details, posts on social networking websites,
medical information, or a computer or mobile IP address.
According to GDPR personal data should be pseudonymised in a way that it can no longer be linked (or
“attributed”) to a single data subject (user) without the use of additional data.
This additional data should be kept separate from the pseudonymised data and subject to technical and
organizational measures to make it hard to link a piece of data to someone’s identity (non-attribution).
The full data is broken to identifiable information and non-identifiable information in the
25
pseudonymisation process. The identifiable information is subjected to stricter access control and audits
(Figure 4.2).
Figure 4.2 Pseudonymisation process
De-identification is the process used to prevent a person's identity from being connected with information.
For example, data produced during human subject research might be de-identified to preserve research
participants' privacy.
When applied to metadata or general data about identification, the process is also known as data
anonymization. Common strategies include deleting or masking personal identifiers, such as name and
social security number, and suppressing or generalizing quasi-identifiers, such as date of birth and zip
code. The reverse process of using de-identified data to identify individuals is known as re-identification.
Successful re-identifications cast doubt on de-identification's effectiveness.
Data Re-Identification is the practice of matching anonymous data (also known as de-identified data)
with publicly available information, or auxiliary data, in order to discover the individual to which the data
belongs to. This is a concern because companies with privacy policies, health care providers, and
financial institutions may release the data they collect after the data has gone through the de-
identification process [4.13].
Figure 4.3 Re-identifications of pseudonymous data
The de-identification process involves masking, generalizing or deleting both direct and indirect
identifiers; the definition of this process is not universal, however [4.14]. Information in the public domain,
even seemingly anonymized, may thus be re-identified in combination with other pieces of available data
26
and basic computer science techniques [4.15]. However, others have claimed that de-identification is a
safe and effective data liberation tool and do not view re-identification as a concern [4.16].
Pseudonymous data can still go through re-identification to link (attribute) it to an individual again
(Figure 4.3).
Pseudonymisation techniques
There are many ways to pseudonymise the data, which depends on the privacy impact assessment:
• Scrambling techniques involve a mixing or obfuscation of letters. The process can sometimes
be reversible. For example: “Popescu” could become “Escupop”.
• Encryption, which renders the original data unintelligible and the process, cannot be reversed
without access to the correct decryption key. The GDPR requires for the additional information
(such as the decryption key) to be kept separately from the pseudonymised data.
• A masking technique allows an important/unique part of the data to be hidden with random
characters or other data. For example: “5500 0000 0000 0004” credit card number can be
stored as “XXXX XXXX XXXX 0004”. The advantage of masking is the ability to identify data
without manipulating actual identities.
• Tokenization is a non-mathematical approach to protecting data at rest that replaces sensitive
data with non-sensitive substitutes, referred to as tokens. The tokens have no extrinsic or
exploitable meaning or value. Tokenization does not alter the type or length of data, which
means it can be processed by legacy systems such as databases that may be sensitive to data
length and type. That is achieved by keeping specific data fully or partially visible for processing
and analytics while sensitive information is kept hidden.
• Data blurring uses an approximation of data values to render their meaning obsolete and/or
make it impossible to identify individuals. A good example is a typical blurred face in an image
(though it’s not a very good idea).
Pseudonymisation risks
Considering the current state of technology, three risk factors should be considered when choosing a
pseudonymisation technique:
• extraction, which allows separation of records identifying a specific natural person in the
set;
• the ability to create relationships, e.g. based on data correlation analysis;
• inference with considerable probability of the value of a given attribute based on other
attributes of the set.
Common mistakes when using pseudonymization that should be kept in mind when designing the vINCI
platform, are as follows:
• using the same key in different databases: eliminating the possibility of linking different
data sets relies heavily on the use of a key algorithm and the fact that one person will
correspond to different pseudonymous attributes in different contexts. Therefore, to limit
27
the possibilities of linking, it is important to avoid using the same key in different
databases;
• key retention: if the secret key is stored with the nickname data and the data is
compromised, the attacker may be able to easily associate the pseudonymous data with
its original attributes. The same principle applies when the key is stored separately from
the data, but not securely.
Anonymisation
“Anonymisation” of data means processing it with the aim of irreversibly preventing the identification of
the individual to whom it relates. Data can be considered anonymised when it does not allow identification
of the individuals to whom it relates, and it is not possible that any individual could be identified from the
data by any further processing of that data or by processing it together with other information which is
available or likely to be available.
Anonymization is not a single technique, but rather a collection of approaches, tools, and algorithms that
can be applied to different kinds of data with differing levels of effectiveness.
In the case of anonymisation, by 'identification' we mean the possibility of retrieving a person's name
and/or address, but also the potential identifiability by singling out, linkability and inference.
Anonymisation techniques
The following techniques can be used to anonymize records of information:
• Noise Addition: The personal identifiers are expressed imprecisely (example, weight is
expressed inaccurately +/- 10 lb).
• Substitution/Permutation: The personal identifiers are shuffled within a table or replaced with
random values (example, a zip code of 80629 is replaced with “Magenta”).
• Differential Privacy: The personal identifiers of one data set are compared against an
anonymized data set held by a third party with instructions of the noise function and acceptable
amount of data leakage.
• Aggregation/K-Anonymity: The personal identifiers are generalized into a range or group
(example, a salary of $42,000 is generalized to $35,000 - $45,000).
• L-Diversity: The personal identifiers are first generalized, then each attribute within an
equivalence class is made to occur at least “l” times. (example, properties are assigned to
personal identifiers, and each property is made to occur with a dataset, or partition, a minimum
number of times).
• Hash Functions: The personal identifiers of any size are replaced with artificial codes of a fixed
size (example, Paris is replaced with “01”, London is replaced with “02”, and Rome is replaced
with “03”).
• Tokenization: The personal identifiers are replaced with a non-sensitive identifier that traces
back to the original data, but are not mathematically derived from the original data (ie, a credit
card number is exchanged in a token vault with a randomly generated token “958392038”).
28
Security for transfer and data access
Ensuring the security of the vINCI platform concerns the implementation of secure medical data
transmission, ensuring security for the data access and introducing security at the level of recording
medical data. A number of documents are available containing recommendations in the field of IT system
security and guidelines in the field of medical data security, such as: NIST Cybersecurity Framework,
HL7 security and privacy standards, ISO 27001 and ISO 27799, HITRUST CSF.
Analysis of the above documents has shown that in order to ensure security, at least user authentication
based on passwords or certificates, data encryption, and the use of a firewall are recommended.
The recommendations described in the documents published by HITRUST Alliance indicate that valid
encryption process includes:
• Transport Layer Security (TLS) 1.0;
• Secure Sockets Layer (SSL) 3.1;
• IPSec VPNs:
o Gateway-To-Gateway Architecture;
o Host-To-Gateway Architecture;
o Host-To-Host Architecture;
• SSL VPN:
o SSL portal VPN,
o SSL Tunnel VPN.
On the other hand, taking into account the NIST Recommendation for Key Management (see Section
4.1), from the security perspective of the vINCI platform the most important elements are: PKI, IPSEC
and SSH.
PKI
Public Key Infrastructure (PKI) is a collection of people, policies, procedures and computer systems
necessary to provide authentication, encryption, integrity and non-repudiation services through public
and private key cryptography and electronic certificates. The following types and lengths of keys are
recommended in the NIST document:
• Digital Signature keys used for authentication (for Users or Devices) – RSA: 2048 bits, ECDSA:
Curve P-256;
• Digital Signature keys used for non-repudiation (for Users or Devices) – RSA: 2048 bits,
ECDSA: Curves P-256 or P-384;
• CA and OCSP Responder Signing Keys – RSA: 2048 or 3072bits, ECDSA: Curves P-256 or
P-384;
• Key Establishment keys (for Users or Devices) – RSA: 2048 bits, Diffie-Hellman: 2048 bits,
ECDH: Curves P-256 or P-384.
IPSEC
The NIST document determines specifications and requirements for ESP, AH, IKEv1 and IKEv2
protocols and gives recommendations for use within IPsec.
29
The preferred automated keying method is IKE, the Internet Key Exchange protocol that was designed
specifically for use with IPsec. IKE generates the necessary keying material for IPsec via an
authenticated secure channel between the two IKE peers. There are two versions of IKE in use: IKEv1
([4.17], [4.18] and [4.19]) and IKEv2 ([4.20]); both versions perform mutual authentication, and establish
and maintain security associations.
SSH
The NIST document specifies issues related to SSH - a protocol between clients and servers for secure
remote login and other secure network services over an insecure network.
The main recommendation for system developer are: (1) configuration sessions only based on approved
cryptographic algorithms; (2) configuration of preferences in negotiating cryptographic-algorithm lists
according to the organization’s security guidelines for the client. The administrator should: (1) configure
the client to verify the server’s public-key certificate in the key exchange protocol in TLP (Transport Layer
Protocol) and discontinue the protocol if the verification fails; (2) configure the server to authenticate the
client by verifying the client’s certificate, if provided, when a public-key algorithm for authentication is
used in UAP (UniFi Access Point).
In the designed vINCI solution, medical data will be transferred using the REST API. To secure data
transmission, it is recommended to use the HTTPS protocol using the TLS protocol to encrypt data. This
approach gives the opportunity to use three levels of data access security. The system can be available
to users based on:
• level 1 - Basic Access Authentication - based on login / password;
• level 2 - Digest access authentication - it applies a hash function to the username
and password before sending them over the network;
• level 3 - Authentication using HTTPS client certificates.
Level 3 is the most secure and recommended for securing access to medical data.
Security of an access to medical data can be also achieved based on the use of a firewall with
appropriate security rules and involvement of an HTTP proxy server (e.g. Apache Server, Nginx server
or Squid). For example, the security capabilities of the Nginx server are following:
• NGINX SSL Termination;
• Restricting Access with HTTP Basic Authentication;
• Authentication Based on Subrequest Result;
• Limiting Access to Proxied HTTP Resources;
• Restricting Access to Proxied TCP Resources;
• Securing HTTP Traffic to Upstream Servers;
• Securing TCP Traffic to Upstream Servers;
• Dynamic Blacklisting of IP Addresses.
The last issue is the secure of storage for the medical data. The system for storing data considered in
the project is the PostgreSQL database. PostgreSQL gives the option of encryption at several levels,
and provides flexibility in protecting data from disclosure due to database server theft, unscrupulous
administrators, and insecure networks. The following levels of encryption usage are available:
30
• Password Storage Encryption - database user passwords are stored as MD5 hashes;
• Encryption For Specific Columns - the library pgcrypto allows certain fields to be stored
encrypted; this is useful if only some of the data is sensitive: the client supplies the decryption
key and the data is decrypted on the server and then sent to the client;
• Data Partition Encryption - on Linux system an entire file system partition can be encrypted
on disk, and decrypted by the operating system;
• Encrypting Passwords Across a Network - the MD5 authentication method double-encrypts
the password on the client before sending it to the server; it first MD5 encrypts the password
based on the user name, and then encrypts it based on a random salt received from the server
when the database connection was made;
• Encrypting Data Across A Network - SSL connections encrypt all data sent across the
network: the password, the queries, and the data returned;
• SSL Host Authentication - it is possible for both the client and server to provide SSL keys or
certificates to each other.
Security and privacy through blockchain
The security and privacy requirements are met through the use of blockchain technology, which is a
relatively new technology whose potential is compared with Internet. This technology has been proposed
to develop applications for smart city, smart government, internet of things, and more. In the medical
field, data sharing, privacy and interoperability must be major concerns.
Widely considered immutable time-stamped data structures, blockchains implement peer-to-peer
networks where participants can verify interactions concurrently using decentralized peer-to-peer
consensus protocols. As an emerging technology trend, different research and industrial perspectives
are being assembled to document its potential disruptive impact.
Blockchains have five unique characteristics, namely:
1. Peer-to-peer communication without a central authority.
2. Transparent transaction processing with optionally-disclosed ownership.
3. Decentralized transaction history verifiable by all participants.
4. Immutability of records assuring chronological sequence and accessibility.
5. Logic-based processing to trigger algorithms and events.
The aforementioned characteristics have made blockchain particularly suitable to manage
cryptocurrencies: Electronic cash systems administered via peer-to-peer consensus. Indeed, the most
widely known for cryptocurrency, the Bitcoin, remains something like the gold Standard for financial
blockchain applications. Nonetheless, while blockchains have been used extensively in financial entities,
their decentralized immutability characteristics have made them particularly suitable for applications in
other domains including healthcare [4.21]. In fact, some countries are already using to secure health
records and prescribe medicine, e.g. Estonia [4.22].
A major problem in healthcare is the fact that medical applications are not interconnected, and medical
data is fragmented into various databases and the medical institutions are responsible for data
preservation and authenticity. Vinci architecture takes into account all the aspects mentioned,
focused on privacy preserving. In the Vinci platform, the blockchain manages access and permissions
31
to collecting health information and using the personal data stored in the platform. For this purpose, the
blockchain collaborates with the vINCI platform, the edge nodes and the Digital Caregiver application.
The entities, with granted proper permissions, can deliver data to the platform or access health records
only when their identities and cryptographic keys have been verified by blockchain.
Users are recognized as owners of their own data and have full control over it. They can apply various
security policies, such as sharing data with specific clinics, doctors or institutions, and can contribute
anonymously to certain statistics. The blockchain uses public key cryptography to create an immutable,
append-only, timestamped chain of content. Each participating node in the network has a copy of the
blockchain. Due to a large amount of data generated by all the participating institutions and devices, the
content of the nodes is formed only by a set of links to information, permissions and other auxiliary
information. The data itself is stored either by the institutions that generated it or in the cloud.
The entities involved in this system are patients, formal and informal caregivers, doctors, medical
institutions, other entities who want to access medical data. They interact with the system through
different software applications (e.g. Digital Caregiver application). The nodes within the network have
the role to store a copy of the blockchain. Those are divided into trusted nodes (approved medical
institutions) - validate transactions and take decision if they add a new transaction within the blockchain
- and untrusted nodes - entities who wants to access medical data (research institutes, assurance
companies, employers etc.) (Figure 4.4). The peer-to-peer network interconnects all the nodes.
Figure 4.4 Peer to peer network
Within the system, there are two types of transactions: storage transaction created when medical results
are appended and policy transaction created when the user wants to share his data with other entities.
By default, access to these data is only permitted to the patient, the owner of the information (Figure
4.5).
32
Figure 4.5 Mainchain
In addition, within the system are defined two types of blockchains: a mainchain where are stored the
storage transactions and policy transactions, and a sidechain, where is stored the correspondence
between the patient temporary ID and patient’s real identity. The mainchain can be accessed by all the
nodes, while the sidechain can be accessed only by the trusted nodes.
The storage transactions are created by medical institutions after a patient is consulted. This type of
transaction contains the following characteristics: temporary user ID (unique for each analysis), user’s
signature - it is checked by blockchain, doctor ID, doctor’s signature - it is checked by patient and by the
blockchain, doctor’s public key, medical institution’s ID (who created the transaction), medical
institution’s signature (who created the transaction) - is checked by blockchain and by patient, timestamp,
data hash, data type, data link and hash of previous block. After a patient is consulted within a medical
institution, some medical data is generated and his identity is authenticated by clinic. When the doctor
prepares the medical analyzes, he queries the sidechain for a temporary patient ID and put it into the
transaction. The medical institution creates a set of analyses and sends them to the patient with its
signature (data hash signature) and doctor’s signature (data hash signature). The medical institution is
required by the application to use a standard data format. The patient reads them if he/she agrees, then
signs the storage transaction and returns it to the medical institution. The patient’s temporary ID is unique
for each analyze. In the first stage, the correspondence between the patient temporary ID and patient’s
real identity is known only by him and the trusted nodes within the white list - through a sidechain
transaction (Figure 4.6).
Figure 4.6 Sidechain
This prevents other untrusted nodes (research institutes, health insurance companies, employers, etc.)
to discover personal information stored within the blockchain. The medical institution who created this
transaction is also responsible to create a new transaction within a sidechain. This type of transaction
records the correspondence between the temporary patient ID and real identity. This sidechain is
accessed and maintained only by the trusted nodes. The medical institution then broadcast the
transaction to all other nodes. The trusted nodes check the transaction, more exactly all the signatures:
medical institution who created it, doctors signature and patient signature.
33
The consensus algorithm in this case is Proof of Identity / Proof of Authority. If the transaction passes
this requirement, the new transaction is appended to the mainchain and the medical institution broadcast
it. Medical analyzes are stored in an external database to the mainchain, but internal to the medical
institution. Medical institution is responsible for the data preservation and data authenticity. Although it
is not possible to guarantee this, mainchain can be used to verify if the data has been modified using the
hash stored in each storage transaction.
The policy transactions are created when the patient applies a certain security policy regarding his
medical data. This type of transaction contains the following characteristics: patient’s signature (unique
for each transaction), patient’s temporary ID (from the storage transaction) / list of patient’s temporary
IDs (if there are more than one), ID of the granted institution (research institutes, assurance companies,
employers etc.), the signature of the granted institution, a timestamp and the hash of previous block. The
entity who wants to access the medical analyzes is responsible to create this transaction when the patient
requests it. After the patient contacts the institution who wants to access the data, it creates a policy
transaction signed by patient and broadcasts it into the entire network. All the nodes within the white list
verify the transaction’s validity. If the transaction passes this requirement, the new transaction is
appended to the mainchain.
All the trusted nodes participate in the mining process. The role of this process is to check the
transaction’s validity. The trusted node who created the transaction is responsible for adding a new block
to the mainchain.
Regarding privacy, within the mainchain the users are identified by a temporary ID for each transaction.
The correspondence between the temporary ID for each transaction and patient’s real identification is
maintained in a sidechain accessed only by trusted nodes. Patient’s public key is also stored in the
sidechain.
Through the audit process, we want store all the information regarding the data access. This task could
be done through multiple ways. The first one considers storing this information within the medical
institutions’ internal database. The problem is that the medical institution could modify the audit
information without anyone knowing this. The second solution is through smart contracts (by putting a
new filed – access counter – in the policy transaction). The third one is through a new type of transaction
that should be stored within the mainchain. This new transaction is created by the medical institution
which is a trusted node, when another institution send a request to access the data. This transaction is
signed by the medical institution and the second institution.
Vinci architecture takes account the approved legislation, for example GDPR: to access one’s own
personal data, right to data portability/to transfer your data from one data controller to another, right to
object to the processing of your data, right to rectification or erasure of data, rights in case of breach,
right to lodge a complaint and to effective judicial remedy, right to compensation, right to be
informed/transparency, etc. Considering the implementation, all those rights are implemented through
the blockchain technology.
34
Security Incident Management Procedure for vINCI
The Security Incident Management Procedure (SIMP) should be carried out in the event of any incident
affecting the security of patients’ data handled in the vINCI platform. The general flow of the SIMP is
presented in Figure 4.7.
The main vINCI platform is established using NIT’s PL-LAB experimental infrastructure. Consequently,
SIMP procedure for vINCI is, in general, compliant with internal NIT’s SIMP. It is extended to include
notification of Project partners in case when personal data breach reaches the level of high risks. This is
particularly applicable to the partners who recruit patients and next conduct trials with them. The project
partner who carried out the recruitment, will also carry out the process of informing the patients about
their personal data breach incident.
Moreover, during incident evaluation phase, NIT’s Data Protection Officer may ask the Project
Coordinator to call a meeting of the Project’s General Assembly, in order to jointly evaluate the impact
of the incident on the Project and engaged patients.
Figure 4.7 vINCI Security Incident Management Procedure
Taking into account that the Project involves partners from several EU countries, and that the main vINCI
platform infrastructure is localized in Poland, by default Polish supervisory authority (UODO) will act as
the main supervisory authority to which the notification should be made in case of vINCI-related personal
Data Protection Officer
Communicate the incident to the
NIT’s Privacy Manager
Incident evaluation
High risk
related?
Notification of local regulator
Notification of Project Partners and
the data subjects
Project Partner employee
Incident
Communicate the incident
to the privacy responsible
(NIT’s Data Protection
Officer)
via e-mail
35
data breaches. However, in case security breach will affect patients of one pilot only (located in one
country), NIT’s Data Protection Officer will make an assessment of which supervisory authority should
be consider as the main authority: local or from the country in which the pilot is being conducted.
36
List of figures Figure 4.1 Bodies involved in standardizing the medical field [3.3.5]
Figure 4.2 Pseudonymisation process
Figure 4.3 Re-identifications of pseudonymous data
Figure 4.4 Peer to peer network
Figure 4.5 Mainchain
Figure 4.6 Sidechain
Figure 4.7 vINCI Security Incident Management Procedure
Bibliography [1.1] The Health Insurance Portability and Accountability Act of 1996. Available at:
https://www.hhs.gov/hipaa/index.html
[1.2] Regulation (EU) 2016/679 of the European Parliament and the Council of 27 April 2016, on the
protection or natural personals with regard to the processing of personal data and on the free movement
of such data, and repealing Directive 95/46/EC (General Data Protection Regulation). Available at:
http://www.dataprotection.gov.cy/dataprotection/dataprotection.nsf/DB87F8669B782F68C2258263003
5BFF1/$file/Regulation%202016-679_ENG.pdf
[2.1] Directive 95/46/EC of the European Parliament and the Council of 24 October 1995, on the
protection of individuals with regard to the processing of personal data and on the free movement of
such data. Available at: https://eur-lex.europa.eu/legal-
content/EN/TXT/PDF/?uri=CELEX:31995L0046&from=en
[2.2] The new EU regulation on the protection of personal data: what does it mean for patients? A guide
for patient and patients’ organisation. European Patients Forum. European Union Health Programme
(2014-2020). Available at: http://www.eu-patient.eu/globalassets/policy/data-protection/data-protection-
guide-for-patients-organisations.pdf
[2.3] Daniel Pavin, Jonathan Benjamin: Summary of the European Commission’s eHealth Strategy,
Posted in EHR/EMR, Health Data, Medical Apps, Personalized Medicine, May 2, 2018.
[3.1] Office of the Commissioner for Personal Data Protection, Cyprus. Webpage:
http://www.dataprotection.gov.cy/dataprotection/dataprotection.nsf/home_el/home_el?opendocument
[3.2] Act of 10 May 2018 on the Protection of Personal Data, Journal Of Laws Of The Republic Of Poland,
Item 1000, Warsaw, 24 May 2018
[3.3] Personal Data Protection Office, Poland. Webpage: https://uodo.gov.pl
[3.4] Regulation of the Council of Ministers regarding the National Interoperability Framework, minimum
requirements for public registers and exchange of information in electronic form and minimum
requirements for ICT systems. 5 December 2017. (in Polish).
[3.5] Act of 6th November 2008 Patients’ Right and the Commissioner for Patients’ Rights, Journal Of
Laws Of The Republic Of Poland, no 52 Item 417, Warsaw, 2009
37
[3.6] Recommendations of the National Centre for Health Information Systems in the field of safety and
technological solutions applied in the processing of medical documentation in electronic form. CSIOZ,
Warsaw, September 2017 (in Polish). Available at CSIOZ webpage: https://www.csioz.gov.pl/
[3.7] Autoritatea Naţională de Supraveghere a Prelucrării Datelor cu Caracter Personal.
https://www.dataprotection.ro/.
[3.8] Ministerul Sănătăţii. Protecția Datelor cu Caracter Personal – GDPR. http://www.ms.ro/protectia-
datelor-cu-caracter-personal-gdpr/
[3.9] HL7 Romania. Webpage: www.hl7romania.ro/
[4.1] ASRO / CT 319 - Medical Informatics, Oct 2018, https://www.asro.ro/?p=6244 .
[4.2] Freriks G., EHR: European International, National standards and normalization CEN/TC 251, 2006.
[4.3] ISO 27799:2016 Health informatics – Information security management in health using ISO/IEC
27002
[4.4] ISO/IEC 27002:2013 Information technology — Security techniques — Code of practice for
information security controls
[4.5] ISO/TR 14639-2:2014, Health informatics — Capacity-based eHealth architecture roadmap — Part
2: Architectural components and maturity model
[4.6] ISO 14265 Health Informatics - Personal Information.
[4.7] Health Level Seven International. Webpage: http://www.hl7.org/about/index.cfm?ref=common
[4.8] DICOM. Webpage: https://www.dicomstandard.org/
[4.9] IT & C Club, Medical Records, Attractive Target for IT Attacks, November 2017.
[4.10] “HISTRUS Common Security Framework”, Health Information Trust Alliance, 2014 version 6.0
[4.11] E. B. Barker, Q. H. Dang “Recommendation for Key Management Part 3: Application-Specific Key
Management Guidance”, NIST Cybersecurity Framework , 800-57 Pt3 Rev 1, January 22, 2015
[4.12] ISO/IEC 27001:2013 Information technology — Security techniques — Information security
management systems — Requirements
[4.13] C. Porter. 2008. “Constitutional and regulatory: De-Identified Data and Third Party Data Mining:
The Risk of Re-Identification of Personal Information”. University of Washington Shidler Journal of Law,
Commerce & Technology. Retrieved in 2019.
[4.14] Y. Lagos. “Symposium: taking the personal out of data: making sense of de-identification”. Indiana
Law Review. Retrieved in 2019.
[4.15] W. McGeveran. “Privacy, democracy, and elections: mrs. Mcintyre's persona: bringing privacy
theory to election law”. William & Mary Bill of Rights Journal. Retrieved in 2019.
[4.16] V. Richardson, S. Milam, and D. Chrylser. “Is Sharing De-identined Data Legal? The State of
Public Health Confidentiality Laws and Their Interplay with Statistical Disclosure Limitation Techniques”.
Journal of Law, Medicine & Ethics. Retrieved in 2019.
38
[4.17] IETF RFC 2407 - “The Internet IP Security Domain of Interpretation for ISAKMP,” https://www.rfc-
editor.org/rfc/rfc2407.txt
[4.18] IETF RFC 2408 – “Internet Security Association and Key Management Protocol (ISAKMP),”
https://tools.ietf.org/html/rfc2408
[4.19] IETF RFC 2409 – The Internet Key Exchange (IKE) - https://tools.ietf.org/html/rfc2409
[4.20] IETF RFC 5996 – Internet Key Exchange Protocol Version 2 (IKEv2) https://www.rfc-
editor.org/rfc/rfc5996.txt
[4.21] T-T Kuo, H-E Kim, and L. Ohno-Machado. “Blockchain distributed ledger technologies for
biomedical and health care applications”, Journal of the American Medical Informatics Association,
Volume 24, Issue 6, November 2017, Pages 1211–1220, https://doi.org/10.1093/jamia/ocx068
[4.22] e-estonia “Blockchain and healthcare: the Estonian experience” February 2018 https://e-
estonia.com/blockchain-healthcare-estonian-experience/ (Last accessed: 10/Jun/2019)
39
Annex I This section presents an Informed Consent Form (ICF) template for vINCI project. It is based on template
provided by WHO.
In addition, in the second part of the Annex we present the Patient Information Sheet (PIS) and ICF that
were prepared according to the guidelines by the Cyprus National Bioethics Committee and will be used
for the acceptability study in Cyprus.
40
vINCI Informed Consent Form Template (in English)
41
42
43
44
Patient Information Sheet and Informed Consent Form (in Greek)
45
46
