## 2 Background
### Access Control Limitations  
The levels of security policies within healthcare critical infrastructure are sizeable, defined in an ad hoc manner and tend to be revised sporadically. They also have an extensive reliance on the knowledge of domain experts, or observations of external specialists [9], meaning that existing security mechanisms are often laborious and problematic. This is because it is a considerable challenge to impose an access control policy on employees in a setting where dynamic and unpredictable patterns occur due to the nature of the role when providing hospital care [10]. Within this context, access control-based approaches are, therefore, limited due to several factors [11], such as (i) in a hospital setting, it is safer to detect anomalous behaviour than prevent it, as preventing access to patient data could lead to patient harm; (ii) there is a frequent occurrence of unpredictable and dynamic care patterns. This includes scheduled and unscheduled inpatient/outpatient and emergency department visits; (iii) there is a significant level of varied workflows, with providers requiring access in unexpected areas; (iv) the workforce is, by and large, mobile, with access required at unexpected locations and times; (v) the collaborative nature of clinical work and teaching environments is present and (vi) on a foundational level, overly restrictive access control measures can stifle innovation within a healthcare setting. Due to these limitations, access control approaches are insufficient as the sole method of anomaly prevention within EPRs, leading to research within the augmented anomaly detection sector; for example, technologies such as the access matrix model (AMM). AMM is poised as a theoretical model where each user's permissions are specified within the system for each object. The framework caters for a systematic modelling of the access rights, but the application faces scaling challenges, and does not adapt to dynamic changes. This makes it a challenge to apply to EPR data in particular [12]. Another technique, known as role-based access control (RBAC), models the users' roles and matches permissions directly to the specific functions they have. The specific role-based positions (within the enterprise) and the employees' tasks are classified. Privileges are then allocated to these positions, so that the employees are able to fulfil their duties [13]. The challenge with RBAC is that roles are inclined to be both static and inflexible. They are therefore not able to adapt to the dynamic nature of the duties that are required within a healthcare critical infrastructure. Whereas, the Attribute-Based Access Control (ABAC) technique delivers a flexible (and often referred to as context-aware) access control method. This is provided by an evaluation of the attributes of entities, specifically focusing on (1) their subject and object, (2) the operation, and (3) the contextual environment (i.e., time and location of the request) [14]. In addition, a Boolean logic layer is applied to the operational request. This facilitates a calculate process of the access privileges (e.g., _IF, THEN_ statements regarding the request, the resource and the action). The advantage of ABAC, in light of the aforementioned techniques, is that it provides a considerably greater level of discrete inputs. This, in turn, caters for a much more substantial definitive set of rules for the expression of policies compared to similar approaches (such as RBAC). Within the access control domain, the experience-based access management (EBAM) process places a focus on accountability and how audit data are used in order to identify illegitimate access [13]. EBAM-based enterprises often manually review the audit logs of individuals with prominent status (or celebrities) to determine inappropriate accesses [15]. EBAM-based enterprises tend to review the audit logs by hand, whenever a user broke the glass [13] (where _Break The Glass (BTG)_ refers to a policy of allowing users to override access controls in necessary instances [15]).