Every attempt to develop a novel language requires a verification process to evaluate the final result. The methodology which was deemed appropriate to reach the desired level of verification was the case study approach. According to the literature presented in Chapter 3, data subjects’ privacy expectations are crafted based on power asymmetries which they experience when interacting with data controllers. There exist three different types of power asymmetries. In order to capture all the possible expectations of consent and revocation for systems implemented in different contexts, thus serving different business models with different legacy requirements in place, I applied the logic on three different case studies.
In this Chapter, the first attempt to verify the expressiveness of the logic is illustrated. The case study to provide the specification requirements for the consent and revocation controls was the Employee case study, which was the pilot study where the first primitive form of logic was tested. The aim of the chapter, which was successfully achieved, served a dual purpose. The first aim was to demonstrate that the ambiguities, emerging from the interpretation of the natural logic to machine- readable format and from the complex nature of privacy when the first version was applied, were tackled. The second was to verify that all the effects of consent and revocation preferences in a system offering controls were adequately formalised without any further reconfiguration of the logic.
More specifically, through a number of different use cases, different expectations of consent and revocation were effectively formalised, giving the opportunity to demonstrate examples of various Φ variables and obligations. In addition, with the design of the fictional WorkBook, the power asymmetries of the first kind, between two data subjects were also examined. To conclude, the final version of the logic presented in Chapter 4 was successfully applied to the Employee case study and
all the requirements were unambiguously formalised, without any further issues emerging.
The Biobank case study
Following the formalisation of the pilot case study which verified the effectiveness of the logic in an environment where data subjects disclose personal data to various third parties and share data amongst them, the second case study where the logic is applied on is a Biobank based in the United Kingdom. The purpose of this case study is to formalise the diverse consent and revocation preferences that occur in a context totally different from the pilot case study, in order to test the expressiveness of the logic. The focus is on medical data treated in the Biobank and on the power relations between the patients and the researchers that are in favour of the researchers. Patients have the sense that their hopes for receiving a treatment depends on their participation. More issues emerge from the existence of the legacy system in place, whose requirements need to be cater for in the formalisations.
In the following Section 6.1, I present the details of the Biobank case study and the methodology followed to elicit the requirements for consent and revocation controls in this environment. Section 6.2, describes the use case in italics and illustrates their formalisations followed by explanatory text for each of them. The final Section 6.3, concludes the findings of this Chapter.
6.1
Requirements elicitation
A Biobank is a “resource of tissue and blood samples donated by patients for use in medical research” [199]. As a result, Biobanks collect and store samples in ac- cordance with regulatory requirements and provide access to researchers in order to improve diagnosis and treatment, and ultimately patient care. The Biobank case study offers interesting issues in terms of managing consent and revocation controls in a context where sensitive information is handled, whereas legislation
imposes strict controls and patients’ preferences need to be addressed. The aim is to verify that the logic is rich and expressive enough to allow the formalisation of requirements in a different context without adding new actions and rights.
I analyse a number of use cases that provide an overview of the environment where a system offering consent and revocation controls will be implemented. From these use cases, a list of requirements to explore the implications of invoking consent and revocation controls is elicited. The use cases that are formalised in this chapter are:
• The IT administrator creates consent and revocation options that will be presented to the patient both for the sample and the data.
• The IT administrator creates privacy access control policies. • The IT administrator creates privacy obligation policies.
• The IT administrator sets consent and revocation default choices.
• The data subject (patient) or technician makes consent and revocation choices for specific study/studies.
• The technician is registering a sample and/or personal data in a spreadsheet. The requirements regarding the consent and revocation functionality for the use cases in the Biobank case study were elicited from descriptions of the current legacy system in place and further information provided by the focus groups. The content analysis [154;126;190;81] methodology was adopted to analyse the transcripts from the focus groups. The themes used in the content analysis were generated based on the consent and revocation actions defined in the logic which emerged from the conceptual consent and revocation model and from the application of the logic to the first case study. Both researchers associated with the biobank and patients participated in these focus groups.