. 2020 Oct 31;26(4):265–273. doi: 10.4258/hir.2020.26.4.265

Table 1.

Consent model and its rules

Consent model	Rules
Each consent consists of four main tuples expressed as follows: <Role; AdmitteeIds; Action; Intended-Purpose> - Role: Job title or job function of requestor who has their specific eID (it is id of Enrolment certificate and explained in section 5). Examples are Cardiologist, Physician, etc. - DoctorID: Patient can add some designated doctors or healthcare professionals such as family doctor or medical specialist etc., who are allowed to access to the patient data. Their eIDs are listed here, or this element may remain blank. - Action: The activity on the data. Examples are Copy, Read, etc. Actions can have access privilege levels, so that the privilege of Copy includes that of Read, and the opposite is not allowed, i.e., Copy ⊃ Read. - Intended-Purpose: This element consists of two tuples as follows: <AIP; PDP> where AIP is Allowed Intended Purpose and PDP is Prohibited Descendant Purpose. AIP contains PDP, as the former is the ancestor of the latter.	Role and DoctorID are basic qualifiers necessary to specify requestor’s legitimacy. One of these two and the other two tuples should be simultaneously complied by the requestor, i.e., (Role ⋁ DoctorID) ⋀ Action ⋀ IntendedPurpose A data access is allowed only for the AIP that are explicitly written in a patient consent for the data, making all the other purposes implicitly prohibited one. Multiple AIPs constitutes a whitelist, for which data access is allowed. If an AIP has descendant purposes in the purpose-tree, then all of the descendants are also allowed purposes, belonging to the whitelist except some specific ones. Some of descendants of an AIP can be as PDP, for which data access is not allowed, such that, ∃ PDP ∈ AIP. Multiple PDPs under an AIP constitutes a blacklist (BlackList), consisting of a subset of the ancestor AIP, such that, ∀ PDP ∈ BlackList ⊂ AIP. If a PDP has descendant purposes, then all of the descendants are also prohibited purposes without any exception, belonging to the BlackList, equally saying that there is no AIP that is a descendant of PDP, such that, ∀ AIP ∉ PDP ⊂ AIP. This rule brings about simplicity in our model.

Consent model

Rules

Each consent consists of four main tuples expressed as follows:
<Role; AdmitteeIds; Action; Intended-Purpose>

- Role: Job title or job function of requestor who has their specific eID (it is id of Enrolment certificate and explained in section 5). Examples are Cardiologist, Physician, etc.
- DoctorID: Patient can add some designated doctors or healthcare professionals such as family doctor or medical specialist etc., who are allowed to access to the patient data. Their eIDs are listed here, or this element may remain blank.
- Action: The activity on the data. Examples are Copy, Read, etc. Actions can have access privilege levels, so that the privilege of Copy includes that of Read, and the opposite is not allowed, i.e., Copy ⊃ Read.
- Intended-Purpose: This element consists of two tuples as follows: <AIP; PDP> where AIP is Allowed Intended Purpose and PDP is Prohibited Descendant Purpose. AIP contains PDP, as the former is the ancestor of the latter.

Role and DoctorID are basic qualifiers necessary to specify requestor’s legitimacy. One of these two and the other two tuples should be simultaneously complied by the requestor, i.e., (Role ⋁ DoctorID) ⋀ Action ⋀ IntendedPurpose
A data access is allowed only for the AIP that are explicitly written in a patient consent for the data, making all the other purposes implicitly prohibited one.
Multiple AIPs constitutes a whitelist, for which data access is allowed.
If an AIP has descendant purposes in the purpose-tree, then all of the descendants are also allowed purposes, belonging to the whitelist except some specific ones.
Some of descendants of an AIP can be as PDP, for which data access is not allowed, such that, ∃ PDP ∈ AIP.
Multiple PDPs under an AIP constitutes a blacklist (BlackList), consisting of a subset of the ancestor AIP, such that, ∀ PDP ∈ BlackList ⊂ AIP.
If a PDP has descendant purposes, then all of the descendants are also prohibited purposes without any exception, belonging to the BlackList, equally saying that there is no AIP that is a descendant of PDP, such that, ∀ AIP ∉ PDP ⊂ AIP. This rule brings about simplicity in our model.