RENDIMIENTO DE VAINAS VERDES

In this use case, the Biobank is sharing data about a sample with a researcher in digital form. A researcher requests measurements of data from a sample and the Biobank provides the data in a spreadsheet. This is personal data, so all the controls which a patient may have imposed on the sample, should be passed on.

{bSδ∧bRΦδ∧c∈ ∪Φ.destination∧Φ∗ ≤Φ∧cR†Φ∗δ}

grant(b, c, δ,Φ∗) {cLδ∧cP δ∧cRΦ∗δ∧

⟨bN aδ⟩setnotify(a, b,Φ′, δ)⟨true⟩

∧∀c.⟨bN aδ∧aN†δ∧“shared′′ ∈ ∪Φ.notify-what

∧“email′′ ∈ ∪Φ.notify-how⟩notify(b, a, δ,“shared′′,“email′′)⟨true⟩} where Φ∗ = purpose :u and u={cancer research}.

Note that the use of an action which only allows the researcher to process the data but not to share it is preferred. Also, all the controls which are appropriate for the right to process, are cascaded to the researcher. Furthermore, as the patient had set notification requirements, an email is sent to notify the patient that the data has been shared with the researcher.

The focus groups highlighted the importance of notification in such cases. If notification choices are available, then there is an obligation triggered requiring from the data controller to notify the patient. It is crucial to make a decision which will determine the Biobank’s strategy regarding the notification process. Possible options could be notification by email, using a link on the Biobank’s website pointing to the published papers of the researchers, or requesting the contribution of the patient’s GP.

There will be cases where the consent given by the patient will not be specific enough for the Biobank to determine whether the sample should be shared or not. Therefore, the consent will be implied. The patient could decide whether she/he wishes to be informed if such circumstances occur. Thus, depending on her/his choices she/he might choose to allow sharing of data by default or to be asked for approval. The focus groups conducted with researchers pointed out that any notifi- cation may disturb the patients and their family, while on the other hand enabling

researchers to continue their research by using the same samples for different pur- poses is of significant importance. There are conflicting needs to be catered for and to-date the Biobank has not resolved the issue. Unfortunately, there does not exist any functionality to handle the notification process. The standard procedure requires researchers to get in conduct with the patients. However, it is a time- consuming process and most of the times the patients never reply to researchers’ emails. Instead of annoying patients by allowing researchers to conduct them, the Biobank could incorporate the functionality described in the use cases, to allow them to explicitly specify under which circumstances the Biobank may get in con- duct with them.

6.3

Synopsis of the chapter

Following the successful formalisation of the Employee case study with the applica- tion of the consent and revocation logic, this chapter sought to raise new challenges and novel consent and revocation expectations. A context different from the first case study, since it required the elicitation of different requirements not only for the data subjects but for the legacy system which handled personal data as well, was chosen and the Biobank was considered the ideal case study to question the appli- cability of the logic. The power asymmetries regarding the Biobank are different from the first case study, since the Biobank’s patients believe that they reside their hopes for a treatment on their participation to new trials. Thus, they feel that they are in a disadvantageous position when it comes to give consent to disclose data, a factor that is depicted in their consent revocation expectations and enhanced the decision to choose the specific case study.

The aim of the chapter was to validate the expressiveness of the logic in a differ- ent case study, in a manner that would not raise further ambiguities or require any further refinements. Based on the focus groups conducted by the EnCoRe project that were specifically designed for the Biobank case study, I gained a better under- standing of the environment which the controls should be invoked. The generated data from the focus groups was analysed adopting the same methodology followed for the development of the conceptual model and facilitated the process of elicit- ing requirements. Thus, resulting in more detailed consent and revocation options available to the patients with respect to the requirements elicited from the analysis of the legacy system in place and the demands of the recipients of the medical data

who are the researchers of the Biobank.

The application of the logic to the demanding second case study, enhanced my confidence regarding the richness of the logic and it was the first successful step to demonstrate the capability of the logic to formalise requirements in different con- texts, for different business models and for different data subjects’ expectations. The formalisation was concluded without any ambiguities emerging and all the specifi- cations for the legacy system were effectively captured. It is worth noting that new variables were used to capture the changes in the context, providing evidence that allowing the defining of new variables increases the flexibility and the expressiveness of the logic, while retaining its rigid and correct mathematical form.

The Identity Assurance Programme case

study

Having established the richness of the logic in two different contexts, where no fur- ther ambiguities emerged and no need for a further refinement of the logic presented in Chapter 4 occurred, the next challenge is to apply the logic in an environment where data subjects are requesting to express controls on data disclosed to govern- mental services. The Identity Assurance Programme case study, serves the purpose for that task. As demonstrated in Chapter 3, data subjects respond to the power asymmetries that occur when they interact with the governmental sector, by per- ceiving privacy preferences differently. In addition, the business model followed in the case study differs from the business models of the aforementioned formalised case studies, raising new challenges for consent and revocation controls. The aim of this Chapter is to provide evidence that the logic is expressive enough to adjust to the power asymmetries and formalise the specification of requirements adequately, without any further ambiguities emerging.

The next Section 7.1 provides the description of the Identity Assurance Pro- gramme case study and explains the methodology followed to elicit the requirements for this environment. In Section 7.2, the descriptions of the use cases are presented in italics, followed by the formalisations and their explanation. The final Section 7.3 provides a summary of the results presented in this Chapter.

7.1

Requirements elicitation

The Identity Assurance Programme case study describes an identity ser- vice concept facilitating a government to certify the identity of data sub-

jects. It is based on the development of a consistent, customer-centric approach to digital identity assurance across all public services. This will allow service users to log on safely to digital public services in a way that ensures personal privacy, reduces fraud and facilitates the move to online public services.

Online services have the potential to make life more convenient for ser- vice users as well as delivering cost savings. However, currently cus- tomers have to enter multiple log-in details and passwords to access different public services, sometimes on the same website. This involves significant duplication, is expensive to operate and is highly inconvenient for users. It acts as a deterrent to people switching to digital channels, hampers the vision of digital being the primary channel for accessing Government information and transactions, and provides an opportunity for fraudsters.

The intention is to create a market of accredited identity assurance ser- vices delivered by a range of private sector and mutualised suppliers. A key improvement will be that people will be able to use the service of their choice to prove identity when accessing any public service. Iden- tity assurance services will focus on the key imperative to ensure pri- vacy [252].

To mitigate the risks associated with transacting online, almost all services re- quire the user to go through some form of initial registration and subsequent login procedure. These procedures need to acquire consent from the citizens.

As summarised in the EnCoRe internal report “3rd _{Case Study user’s Require-}

ments Workshops” [184], the principles of the Identity Assurance Programme in- clude the following statements:

• Customer focus: an identity assurance solution must be based around the needs of the individual otherwise it will not be used or valued. People have different and changing needs. No one “big brother” solution will meet the needs of all customers in all contexts.

• Customer control: the use of a customer’s identity and personal data should be fully transparent and controlled by the customer.

These are core principles that must be fully supported by a system when the goal is to enable data subjects (customers, citizens) to express and change their consent

(on their personal data) and organisations to explicitly enforce the management of consent and privacy preferences.

Figure 7.1 below illustrates how a system, and in this case EnCoRe, can be de- ployed within a business model addressing identity assurance issues and how it influ- ences the key players in the environment (Identity Providers, Attribute Providers, Hub, Service Providers) providing the required consent and privacy management functionality [184]:

Figure 7.1: EnCoRe in the Identity Assurance Programme architecture. A picture created by HP laboratories in Bristol [184]

The use cases described in this case study aim to address the problem of han- dling dynamic consent and therefore enable the benefits of public services delivered through digital channels to reach all parts of society, with respect to citizens’ pri- vacy. All the key players of the system are formalised in the use cases. The aim is to verify that the logic can be applied to formalise all the requirements without any additional actions and without any further ambiguities emerging.

Eliciting requirements for the Identity Assurance Programme raises several chal- lenges. The business model is still a matter of debate and the project’s proposition was not definitive at the time when I wrote the thesis. Thus, the requirements were elicited from analysing documents and discussions from the research commu- nity which was assigned to assist those people that initiated the Identity Assurance Programme.