Research paper

GDPR impacts and opportunities for computer-aided diagnosis Guidelines and legal perspectives

Micael Pedrosa∗†, Carlos Costa∗ ∗University of Aveiro

Aveiro, Portugal {micaelpedrosa,carlos.costa}@ua.pt

Julián Dorado† †University of A Coruña

Coruña, Spain [email protected]

Abstract—The General Data Protection Regulation (GDPR) is lengthy and it is essential to resume the impacts of it in specific use-cases to diminish the gap between system developers and regulators. Computer-aided diagnosis is one of such use-cases with increased importance on clinical screening programs. The regulation has distinct mentions that affect automated-decision solutions and healthcare records. This work identifies the fundamental legal issues, challenges and opportunities for this scenario and propose architectural guide- lines to tackle them. The result is purely theoretical, however it is based on known architectures such as signaling networks, already applied in the telecommunication sector.

Keywords-GDPR; Computer-Aided Diagnosis; Architectural Guidelines

I. INTRODUCTION

The data explosion crisis is a reality in radiology. This

presents a challenge not only for storage and data flow

[1], but also puts a burden on physicians already in short

supply [2], especially on mass screening programs where the

disease coverage is low. A computer-aided diagnosis (CAD)

system that could rule out the presence of a disease with a

high degree of accuracy and thus relieve radiologists from

reading a significant proportion of images would be highly

desirable. This opens opportunities for third-parties to pro-

vide CAD solutions as a service for healthcare organisations.

However, potential clients of such services are concerned

on the perception of justice in automated-decision making

algorithms [3], as also the possible privacy issues under the

flag of public health interest [4]. CAD solutions can improve

early diagnosis (a key to high rate survival) and lower the

healthcare cost. A good solution should be able to transpose

the best practices of specialists to automated software,

helping the decision of internal physicians. Moreover, the

challenges of CAD systems are migrating from the technical

aspects of performance bottleneck to the realm of security

and legal constraints. The GDPR released some guidelines

for automated decision-making and profiling (art 22).

Technical guidelines, architectures, specifications and

reusable frameworks will be utterly crucial in assuring a

common ground for compliance. This work will identify the

fundamental legal issues and propose architectural guide-

lines to tackle them.

II. BACKGROUND AND LEGAL FRAMING

The GDPR requires that personal data be protected against

illegitimate processing, accidental loss, destruction or dam-

age. IP addresses, device identification, location and cookies

are now considered personal data. The GDPR demands the

use of best practices to minimise the risk of a security

breach (art 32). This changes the way webmasters and

vendors collect, store and use such information. A survey

report conducted by Veritas 1 from 900 business decision

makers around the world indicates that 31% believe that

their enterprise is already GDPR compliant, but the analysis

of the data by experts found that only 2% actually appear

to be compliant. The false perception or even the uncer-

tainty of the results suggests that the regulation is not easy

for interpretation. The regulation is lengthy, and the best

approach for an initial high coverage is to lock down all

data. However, there are many exceptions (i.e. medical emer-

gencies) and implicit consent roads that break the closed

box approach. These exceptions fall into the break-the-glass

security category [5]. Although not utterly important in the

CAD scenario, these exceptions can be managed by the same

access control and consent mechanisms.

A. Lawful basis for processing

The most known legal constraint of the GDPR is related

to consent (art 7), and is distinctively designed for medical

data (art 9) where specific types of consent are required. A

data protection impact assessment (art 35) is also mandatory

for this type of information. Yet, in the healthcare sector, pa-

tient’s data is held under a duty of confidence. Physicians do

not require the subject’s explicit consent; they are protected

by exceptions (art 7) and other bases in the “lawfulness of

processing“ (art 6), such as the public task basis. However,

to invoke this lawfulness, there should be some registry

noticing the service request from the patient, meaning that,

1https://www.veritas.com/content/dam/Veritas/docs/reports/gdpr-report- ch2-en.pdf

616

2019 IEEE 32nd International Symposium on Computer-Based Medical Systems (CBMS)

2372-9198/19/$31.00 ©2019 IEEE DOI 10.1109/CBMS.2019.00128

even implicit consents require some kind of record. Third-

party CAD services are not in this sphere of lawfulness and

also have to concern with other aspects of the regulation.

Any data flow or processing from those entities requires a

subject consent registry that is non-repudiable, unforgeable

and tamper-resistant. 1) Electronic Consent Framework: Electronic consent

has some advantages over paper documents. For instance, in

the EU eIDAS2 legal framing can now be used to recognise

a digital signature with the same value as a handwritten

signature. This makes granular consent frameworks (such

as ones based on check-boxes) more tamper-resistant. The

availability of electronic records and consents facilitates

its withdraw (art 7 - 3), personal information rectification

(art 16) and the status change notifications. Yet, consent

requires some security features. Non-repudiation is one

of the most important with some attached dependencies,

mainly, integrity and authenticity of records. The former

is easily achieved with digital signatures, but the latter

requires true Self-Sovereign Identities (SS-IDs) [6]. SS-IDs

is a form of user-centric (and sovereign) digital identity

without relying on a centralised organisation. However this

comes with some drawbacks, full sovereignty will make any

break-the-glass procedure unfeasible and unpractical for any

real-world application, especially in medicine where this is

utterly important. 2) Identification and data linkage: In order to demon-

strate proper consent, it is critical to match the correct

patient to the corresponding data that requires consent

within multiple healthcare providers. This connection can

be included in the consent record if it follows appropriate

security requirements. In 2017, the ECRI Institute presented

the report analysis “Health IT Safe Practices: Toolkit for

the Safe Use of Health IT for Patient Identification“3 of

over 7,600 patient safety events related to patient identifi-

cation. These mismatches create safety issues and can lead

to adverse events [7]. Although the IHE Patient Identifier

Cross-referencing (PIX) profile is defined primarily for this

task, it has no cryptographic features that can deliver digital

signatures. Nowadays, we mainly rely on identity providers (IdPs)

to maintain our digital identity. Google, Facebook, Twitter

and others, although offering integration with data curators

through Single-Sign On (SSO) protocols, users do not have

ownership of their digital identity as it is always “given to

them“. IdPs lack the non-repudiable, anti-impersonation and

tamper-resistant features since there is no technical guar-

antee that staff members cannot control or change identity

registries (only the goodwill of the service provider). The

mere possibility of IdPs cheating gives the opportunity for

a user to deny a consent record and trying to blame the IdP

2https://www.eid.as 3https://www.ecri.org/Resources/HIT/Patient

ID/Patient Identification Toolkit final.pdf

for it. There are novel attempts using cryptographic methods

to remove the strong trust in IdPs such as SlashID [8].

However, this requires a drastic change in the authentication

protocol. There are opportunities for federated architectures

[9] to fill the needs of identification and consent registration.

Yet, a reworking has to be made to circumvent the trust

issues, such as introducing self-sovereign elements, claims

and attestations into the mix.

B. Principles of data management

The GDPR creates incentives and relaxes several require-

ments for controllers who pseudonymize and encrypt data,

such as extending the processing to a different purpose than

the one for which it was initially envisioned (art 6 - 4e). And,

since pseudonymization reduces the personal data exposure,

breach notifications can also be diminished (art 33, 34).

On the alternative approach, anonymous data is not under

the GDPR. However, the threshold for anonymisation is

very high. Subject anonymity is more complex than initially

anticipated, DNA sequences can be linked to real-world

human identities and faces can be reconstructed with 3D

magnetic resonance imaging (MRI) [10]. In general, the

techniques are difficult [11] and not always possible [12],

[13], and thus so, constraining the use of specific datasets

without proper consent. The recommendation is, do not

assume that anonymisation is possible.

In terms of data retention policy, there is no absolute

“right to erasure“ (art 17). A subject can invoke this right

only when there is no compelling reason for its con-

tinued processing. Care providers can always justify the

data safekeeping for the purposes of providing continuous

medical care. For CAD providers, data retention must be

in accordance with “the necessity and proportionality of the

processing operations“ (art 35 - 7b) and the principle of

“data minimisation“ (art 5 - 1c). The recommendation is to

erase the data once the automated diagnosis is completed,

minimising the surface area for subject identification.

C. Automated decision-making

Art 13 demands transparency and “meaningful infor-

mation about the logic involved“ for automated-decisions.

This right has become the subject of substantial academic

attention [14], [15]. Some authors are already including it

in their methodologies, not only important machine learning

(ML) metrics but also paying attention to the interpretability

of the model [16]. Google outlines what they considered

the fundamentals of interpretability [17], by “making sense

of hidden layers“. However, this has always a price in

terms of accuracy. Automation is designed to reduce human

error, however also causes a false perception of the lack

of accountability. Black box methodologies can lead to

unpredictable results (bias and overfitting) and are prone to

attacks. Moreover, when the results of automation extend

to the level of experts, the output is viewed as reliable

617

leading to automation complacency [18] and consequently

to the paradoxical effect of increasing errors rather than

eliminating them [19]. The complacency issue was originally

identified in aviation, but from then it has also spread into

the medical field [20]. The purpose of art 22 is to protect the

data subject against such consequences, by ensuring human

control regarding the automated decisions.

III. ARCHITECTURAL GUIDELINES

The fundamental components and relations were identified

and are depicted in Figure 1. Our goal is not to present a

detailed architecture, but to identify targets and opportunities

for future researches. One should identify three affinity

domains. Besides all external services providing a common

infrastructure, there is the radiology centre from a hospital

(the GDPR controller of patient’s data) and, the third-party

(T-P), a processing entity providing the CAD service. The

objective of the use-case scenario is for medical images to

be analyzed by the CAD service. For this, the CAD-Proxy

(CAD-P) is monitoring recently added images from a picture

archiving and communication system (PACS) 4 server a). The patient can manage his consent records on the Consent

Registry Platform (CRP) remotely from the Authorization

Point (AP) b). From those records the CAD-P is able to filter the eligible studies and send them to the third-party CAD

service c). The image modality is then processed by the respective CAD module d), with the outcome registered in a database e). Those results can be presented to physicians f) in priority order, but none should be automatically discarded.

Although physicians are in a different domain, authentication

and SSO integration can be provided by the IdP. Selecting a

case from the list will open g) a detailed view of the study in a certified workstation h). These usually have direct access to PACS and could be integrated with CAD-P to collect

additional information i) from the CAD result.

A. Network Connectivity

All services can be interconnected in an overlay network

[21] or other message broker system. These type of ar-

chitectures are being widely deployed [22] to interconnect

micro-services and suits perfectly as a message signalling

network. This layer is represented by the blue dotted lines,

capable of controlling other data transfer channels (dark

dotted lines). This architecture is especially important for

the following features: maintaining a scalable service of per-

manent connectivity, delivering breach notifications, tracing

data transmissions and managing erasure requests. These

network signals can be recorded in external services for

accountability management.

4https://searchhealthit.techtarget.com/definition/picture-archiving-and- communication-system-PACS

B. Unique Digital Identity

In order for the pipeline to work a Unique Digital Identity

(UDI) (strongly related to the subject cryptographic secret

key) must exist, glueing all records from different services,

and should serve as a network address. The UDI may be

supported via public key infrastructure (PKI) or eIDAS5

solutions. The CAD-P is the only service capable of trans-

lating from a Patient IDs (PIDs) to UDIs and vice versa.

The UDIs represents a sovereign digital identity supported

by the IdP infrastructure, maintaining features such as:

key-management, pseudonymity, break-the-glass procedures,

integrity and construction of non-repudiable records. This

should fullfill the initial requirements of a proper electronic

consent framework, where all consents should be traced to

a unified identity.

C. Authorization Point

The Authorization Point should refer to a device where

the subject’s cryptographic secret key is secured. This is

the only device capable of generating digital signatures for

the respective UDI. It is the access point for the patient to

interact with other system components. The user interface

should provide features to: manage the identity life cycle

and consents, trace personal data movements and, receive

important notifications (breach notifications, diagnostic re-

sults). Cell phones, smart cards and USB keys should be in

the range of possible options.

D. Consent Registry Platform

One important feature of the CRP is related to non-

repudiation. The CRP is a self-sovereign database of cryp-

tographically signed consents, with the respective secret key

under the UDI jurisdiction. This means that consent can only

be changed by the one controlling the secret key. The CRP

should be authoritative regarding consent management, not

the IdP. Consent records should contain the respective data

references, the purpose of the request, the limited timeline

span (if necessary) and to who is given.

E. Security Breach Isolation

Data minimisation is an important concept that can isolate

privacy breaches. For instance, a security breach on a

financial profile should not spread to healthcare records. This

is implemented in some countries, having an identification

number for each government provided service (social secu-

rity, tax services). There are opportunities to extend the same

method to other services in a way that it is controlled by

the data-subject. Yet, it would be desirable to have a unique

point controlling all existing profiles for a single identity.

The already mentioned AP software should be able to switch

between those profiles. In Figure 2 it is presented a possible

approach where profiles have a hidden relation with the main

5https://www.cryptomathic.com/news-events/blog/understanding-eidas

618

Figure 1. The overall architecture of a third-party CAD integration with a radiology centre for medical imaging analysis. Blue dotted lines identify a signalling network that manages and logs the activities of data transmissions on other channels (dark dotted lines). These data transmissions are under the control of the data-subject (identified by the UDI) via the Authorization Point (AP).

UDI, and that, should only be disclosed under the control

of the data-subject. In this approach, isolation is provided

in two steps: 1) disclosing all the data references and locations for a respective profile and 2) providing consent to access those records. The advantage of such methodology

is that the disclosure process can be provided by different

infrastructure services and, if the AP software only has

the required information (access keys/secrets/passwords) to

access a single profile at an instant of time, any security

breach would be isolated to that profile. At the same time,

actions in our daily life are defined by context and consent

should be given in that context.

Figure 2. Overview of the integration of the identity and associated profiles with existing infrastructure. The structure may have two levels of isolation: the disclosure reveals the pseudonymous profile related to the patient UDI and, consent provides access to the profile files stored in organisations.

F. Accountability Manager

The Accountability Manager (AM) is similar to the CRP,

a database of cryptographically signed records. But these

are system records, not user records. Those records will

contain: certifications of UDIs from deployed services,

service level agreements (SLAs) and statistics from CAD

modules, reports of data transmissions collected by the

network, or any other relevant information that may help

to decide the accountability of any decisions made. It would

be important to gather feedback from physicians and build

adequate machine learning metrics (precision, recall, AUC,

etc). This should be the control point of the network, and

the fundamental component governed by the GDPR Data

Protection Officer (if needed). The authenticity of the AM

records is essential when used in legal disputes, providing

research opportunities on how to construct and assure this

requirement.

G. CAD Subsystem

All the identified CAD sub-components should work

together in order to move data from the respective data

controller to interested third-parties. These data movements

(dark dotted lines) should rely on secure channels and

pseudonymization to secure personal data. All activities

would be monitored, registered and controlled by the sig-

nalling network (blue dotted lines). There are opportunities

for seamless integration with existing PACS and medical

workstations to collect exams and present results. As also

opportunities to apply novel pseudonymization methodolo-

gies in the CAD-P component or, data life cycle management

619

on the third-party CAD component.

H. Other security considerations

CAD-P is an internal service of the hospital domain. The

PID or any other information capable of identifying the

patient never leaves the hospital network. The CAD-P does

not get contacted by any other service, so firewall incoming

TCP rules should filter it. Every CAD-P to CAD data session

should be secured. These are certified deployed services with

the respective UDI and cryptographic keys, which means

that the DiffieHellman key exchange can be used to initiate

encrypted channels. However, all message signals initiating

a data transmission session should go through the signalling

network and recorded in the AM with clear distinction of

the source, target and patient UDIs, as also a cryptographic

fingerprint (the hash of transmitted data blocks) of the

transmitted data. This will enable for the AM service to

track all possible data locations.

IV. RELATED WORK

Since the GDPR is a relatively new legal framework, it is

difficult to find good solutions or any existing architectures

to compare our analysis. However, one important identified

necessity of our use-case is the improvement of current

identity and access management systems. Although there

are many solutions from existing identity providers using

Single-Sign On protocols, i.e., OpenID Connect6, the GDPR

has created some new requirements such as non-repudiation

and consequently self-sovereignty. Some projects from the

Decentralized Identity Foundation7 are already dealing with

this, leveraging SS-ID concepts under Distributed Ledger

Technology (DLT). In this regard DLT has many desirable

features to build a proper consent framework, for instance:

integrity/immutability of records for non-repudiation, avail-

ability for consent reads and withdraws, network routing

mechanisms and the necessary number of nodes for a high

available signalling network or, collusion-resistance that

may be used to backup secrets in order to improve key-

management.

Regarding existing CRPs, the IAB Europe’s Transparency

and Consent Framework 8 has been created to tackle the

difficulties of tracing and managing consent by providing

technical specifications. This has resulted in third-party

services named Consent Management Providers (CMP).

However, those are primarily designed for advertising and

marketing purposes and do not always have the required fea-

tures to deal with sensitive data. Some IHE profiles9 already

address part of the GDPR, i.e. mechanisms to record the

patient privacy consent using Basic Patient Privacy Consents

(BPPC) and Advanced Patient Privacy Consents (APPC),

6https://openid.net/connect 7http://identity.foundation 8https://www.iabeurope.eu 9https://www.ihe.net/resources/profiles

and methods of exchanging claims about an identity across

enterprise boundaries using Cross-Enterprise User Assertion

(XUA). However, profiles such as Audit Trail and Node

Authentication (ATNA), only offer perimeter protection and

mutual node authentication, not empowering the patient with

control over their data. In general, security measures on

the healthcare sector are oriented to control the access of

personal [23], [24] (operations and physicians) and do not

always extend to patient consent.

In terms of data management concerns, the clear separa-

tion of signals [25] and data networks is usually found in

the telecommunication sector and voice over IP (VOIP) ter-

minals. This technique may also be applied here to enhance

control of data movement and provide better auditing. On the

“right of erasure“ (art 17) there are complete dissertations

on the subject [26], exposing the disconnection between

the law and current enterprise realities. It also states that

the enforcement of this article will be difficult and does

not provide any enhancements on privacy, raising only the

possibilities of censorship. Erasure is a concept hard to

prove, and there seems to be no good available solution,

only the correct behaviour expectation from the processor

entity.

Common isolation methodologies are enabled by soft-

ware virtualisation, sandboxing, OS processes, separated

databases, etc. Although we did not find any published

method to manage and switch between different profiles,

this can probably be constructed adopting cryptography, i.e.

using one-way trapdoor functions [27].

V. CONCLUSION AND DISCUSSION

We conducted an assessment of the impacts of GDPR for

CAD systems and identified possible components. Several

open challenges are not mentioned here and should be en-

gaged in future work. For instance, the possibility of service

providers to repudiate existing records, adulterating consent.

In this regard, there is a potential to include distributed

ledger technology or P2P network overlays to avoid DoS

and repudiation of records. Other difficulties are also present

on identity management, how to recover from a lost or

compromised key or how to initially link between PIDs and

UDIs. Existing medical imaging systems and networks were

not designed with privacy in mind and are possible escape

routes for data leakage.

These guidelines and challenges are open doors for other

contributions. The initial design will impact future develop-

ments of CAD systems.

ACKNOWLEDGMENT

This work is financed by the ERDF European Regional

Development Fund through the Operational Programme

for Competitiveness and Internationalization - COMPETE

2020 Programme, and by National Funds through the FCT

620

Fundação para a Ciência e a Tecnologia within project

CMUP-ERI/TIC/0028/2014.

REFERENCES

[1] K. H. Lee, H. J. Lee, J. H. Kim, H. S. Kang, K. W. Lee, H. Hong, H. J. Chin, and K. S. Ha, “Managing the ct data explosion: initial experiences of archiving volumetric datasets in a mini-pacs,” Journal of digital imaging, vol. 18, no. 3, pp. 188–195, 2005.

[2] D. C. Goodman and E. S. Fisher, “Physician workforce crisis? wrong diagnosis, wrong prescription,” New England Journal of Medicine, vol. 358, no. 16, pp. 1658–1661, 2008.

[3] R. Binns, M. Van Kleek, M. Veale, U. Lyngs, J. Zhao, and N. Shadbolt, “’it’s reducing a human being to a percentage’: Perceptions of justice in algorithmic decisions,” in Proceed- ings of the 2018 CHI Conference on Human Factors in Computing Systems. ACM, 2018, p. 377.

[4] J. G. Hodge, “Ethical issues concerning genetic testing and screening in public health,” in American Journal of Medical Genetics Part C: Seminars in Medical Genetics, vol. 125, no. 1. Wiley Online Library, 2004, pp. 66–70.

[5] A. Ferreira, R. Cruz-Correia, L. Antunes, P. Farinha, E. Oliveira-Palhares, D. W. Chadwick, and A. Costa-Pereira, “How to break access control in a controlled manner,” in Computer-Based Medical Systems, 2006. CBMS 2006. 19th IEEE International Symposium on. IEEE, 2006, pp. 847– 854.

[6] A. Tobin and D. Reed, “The inevitable rise of self-sovereign identity,” The Sovrin Foundation, 2016.

[7] P. N. Valenstein, S. S. Raab, and M. K. Walsh, “Identification errors involving clinical laboratories: a college of american pathologists q-probes study of patient and specimen identi- fication errors at 120 institutions,” Archives of pathology & laboratory medicine, vol. 130, no. 8, pp. 1106–1113, 2006.

[8] G. Elahi, Z. Lieber, and E. Yu, “Trade-off analysis of identity management systems with an untrusted identity provider,” in Computer Software and Applications, 2008. COMPSAC’08. 32nd Annual IEEE International. IEEE, 2008, pp. 661–666.

[9] U. Fragoso-Rodriguez, M. Laurent-Maknavicius, and J. Incera-Dieguez, “Federated identity architectures,” in Proc. 1st Mexican Conference on Informatics Security 2006 (MCIS2006), 2006.

[10] A. Kermi, S. Marniche-Kermi, and M. T. Laskri, “3d- computerized facial reconstructions from 3d-mri of human heads using deformable model approach,” in Machine and Web Intelligence (ICMWI), 2010 International Conference on. IEEE, 2010, pp. 276–282.

[11] J. M. Silva, E. Pinho, E. Monteiro, J. F. Silva, and C. Costa, “Controlled searching in reversibly de-identified medical imaging archives,” Journal of biomedical informatics, vol. 77, pp. 81–90, 2018.

[12] L. Sweeney, A. Abu, and J. Winn, “Identifying participants in the personal genome project by name (a re-identification experiment),” arXiv preprint arXiv:1304.7605, 2013.

[13] A. Narayanan and V. Shmatikov, “Robust de-anonymization of large sparse datasets,” in Security and Privacy, 2008. SP 2008. IEEE Symposium on. IEEE, 2008, pp. 111–125.

[14] M. Veale and L. Edwards, “Clarity, surprises, and further questions in the article 29 working party draft guidance on automated decision-making and profiling,” Computer Law & Security Review, vol. 34, no. 2, pp. 398–404, 2018.

[15] G. Malgieri and G. Comandé, “Why a right to legibility of automated decision-making exists in the general data protection regulation,” International Data Privacy Law, 2017.

[16] P. Costa, A. Galdran, A. Smailagic, and A. Campilho, “A weakly-supervised framework for interpretable diabetic retinopathy detection on retinal images,” IEEE Access, vol. 6, pp. 18 747–18 758, 2018.

[17] C. Olah, A. Satyanarayan, I. Johnson, S. Carter, L. Schubert, K. Ye, and A. Mordvintsev, “The building blocks of inter- pretability,” Distill, vol. 3, no. 3, p. e10, 2018.

[18] R. Parasuraman and D. H. Manzey, “Complacency and bias in human use of automation: An attentional integration,” Human factors, vol. 52, no. 3, pp. 381–410, 2010.

[19] C. D. Wickens, B. A. Clegg, A. Z. Vieane, and A. L. Sebok, “Complacency and automation bias in the use of imperfect automation,” Human factors, vol. 57, no. 5, pp. 728–739, 2015.

[20] D. Lyell, F. Magrabi, M. Z. Raban, L. Pont, M. T. Baysari, R. O. Day, and E. Coiera, “Automation bias in electronic prescribing,” BMC medical informatics and decision making, vol. 17, no. 1, p. 28, 2017.

[21] E. K. Lua, J. Crowcroft, M. Pias, R. Sharma, and S. Lim, “A survey and comparison of peer-to-peer overlay network schemes,” IEEE Communications Surveys & Tutorials, vol. 7, no. 2, pp. 72–93, 2005.

[22] Z. Wang, W. Dai, F. Wang, H. Deng, S. Wei, X. Zhang, and B. Liang, “Kafka and its using in high-throughput and reliable message distribution,” in Intelligent Networks and Intelligent Systems (ICINIS), 2015 8th International Conference on. IEEE, 2015, pp. 117–120.

[23] C. Santos-Pereira, A. B. Augusto, R. Cruz-Correia, and M. E. Correia, “A secure rbac mobile agent access control model for healthcare institutions,” in Computer-Based Medical Sys- tems (CBMS), 2013 IEEE 26th International Symposium on. IEEE, 2013, pp. 349–354.

[24] L. Fuchs, G. Pernul, and R. Sandhu, “Roles in information security–a survey and classification of the research area,” computers & security, vol. 30, no. 8, pp. 748–769, 2011.

[25] J. G. Van Bosse and F. U. Devetak, Signaling in telecommu- nication networks. John Wiley & Sons, 2006, vol. 87.

[26] J. Levesque, “The right to be forgotten: no solution to the challenges of the digital environment,” Ph.D. dissertation, University of British Columbia, 2016.

[27] A. Lysyanskaya, R. L. Rivest, A. Sahai, and S. Wolf, “Pseudonym systems,” in International Workshop on Selected Areas in Cryptography. Springer, 1999, pp. 184–199.

621