Accessing electronic health records in critical incidents using context-aware attribute-based access control

2.1Attribute-based access control

ABAC architecture (Fig. 1) comprises: (i) the Policy Enforcement Point (PEP), responsible for securing applications and data; It is responsible for intercepting requests and propagating authorization requests to the Policy Decision Point (PDP); (ii) the Policy Information Point (PIP), which bridges external sources of attributes e.g., LDAP databases; and (iii) the Policy Administration Point (PAP) which managed policies. Policies in ABAC are statements which combine attributes to define acceptable or not actions, therefore permitting or denying access to sensitive data. For example, if a requestor wants to access a specific health record, her request is intercepted by PDP, which evaluates relevant policies managed by PAP and using attribute values fetched from PIP. ABAC has been utilised to control access to Electronic Health Record Systems [4].

In XACML (eXtensible Access Control Markup Language) [5], a context handler is the system entity that converts decision requests in the native request format to the XACML canonical form and converts authorization decisions in the XACML canonical form to the native response format [6]. Independently of whether the XACML standard is used or not, context handlers are used in ABAC in order to convert the attribute representations into means that are relevant to the application environment. Low-level context is useful for inferring higher level context towards identifying critical situations, such as in the case of an emergency medical dispatcher situation. This knowledge is pertinent in deciding whether access to personal healthcare data should be granted or not.

Alternatively to XACML architecture, the Open Policy Agent (OPA) [7] constitutes an open source, general-purpose policy engine which unifies policy enforcement. It provides a high-level declarative language for specifying policy as code and APIs to offload policy decision-making from software. When software needs to make policy decisions, it queries OPA and supplies structured data, e.g., JSON, as input. OPA policies are expressed in the Rego high-level declarative language which is purpose-built for expressing policies over complex hierarchical data structures. According to Siebach [8] OPA system uses its own policy grammar. The difficulty with this system is that it breaks domain boundaries in its approach to obtain attributes, or the policy language used is not simple enough to allow business owners to write the policies. For example with grammar difficulties, Rego, the language for writing policies in OPA is very expressive, but it requires significant technical development skills to develop policies with it.

For example, let us consider a defined access control policy that permits access to a patient’s Electronic Health Records (EHRs) to doctors only if they are currently located in a specific hospital. A simple service that retrieves the latitude and the longitude of a doctor (e.g., based on a mobile device that transmits GPS data) is not sufficient for enabling the authorization system to yield a permit or deny decision. Additional functionality is required in order to consider the semantic level of the information that the access policy requires and then convert the raw data to indicate whether or not the registered GPS position refers to the specific hospital or not. Therefore, context handlers are dedicated software components that are used for processing raw contextual data relevant to an access control decision and semantically uplifting them as instances of a context model. Context handlers are responsible for fusing the context-aware policy enforcement mechanism with contextual information in a usable format that will enable the evaluation of access control policies. We note that the scope of context handlers can be quite broad and this is why their design and development should use as background knowledge an appropriate context model.

We first introduced the need for context handlers capable of processing raw contextual data and inferring knowledge which is useful for access control as part of our previous work [9] in the cloud platform-as-a-service security domain. Specifically, we have developed context handlers that are able: i) to provide real-time measurements with respect to certain contextual attributes and ii) to uplift the registered attribute value(s) to a semantic level that is appropriate for the application domain and the access control policy at hand. In this work, we further enhance our approach so that it can support context-aware access control in the healthcare domain.

Additionally, the Capability-based Access Control (CapBAC) mechanism exists, where the concept of capability was originally introduced in [10] as “token, ticket, or key that gives the possessor permission to access an entity or object in a computer system”. In addition, according to Gusmeroli et al. [11] a capability is a communicable, unforgeable token of authority and it refers to a value that uniquely references an object along with an associated set of access rights. Similarly, in comparison of ABAC with CapBAC we view the following differences. On the one hand, ABAC mechanism has the following advantages over CapBAC: First of all, according to the work of Gusmeroli et al. [11] the ABAC approach, specifies access policies by directly using subject’s properties (e.g.: age, location, position etc.), as well as resources and environmental properties, that results in more powerful (and complex) rules and more processing and data availability requirements. In addition, the authors [11], report that the main disadvantage of the capability-based authorization is that it requires issuing capabilities to all subjects, and the selection by the requesting subject of a specific capability when submitting a request. Although capability-based methods have been used as a feature in many access control solutions for the IoT-based applications, applying the original concept of capability-based access control model in IoT network has raised several issues, like capability propagation and revocation [12]. Finally, according to [11], as for other access control mechanisms that have to operate in open, cross domains or cross-enterprise contexts, it is worth mentioning that there is a need to standardize the structure of the capability tokens, the CapBAC supporting services and their access protocols. On the other hand, CapBAC has the following advantages over ABAC: Firstly, Gusmeroli et al. [11] state that a consistent definition of the attributes within a domain is perquisite for ABAC. Additionally, according to the authors [11] ABAC and RBAC systems do not provide flexible delegation rights features.

2.2Emergency access control

Access to sensitive personal information is a very delicate subject and especially in the healthcare domain, where there is a risk for the patient’s private information to be exposed to malicious users. A comparison of diagnostic accuracy with and without access to medical data showed that accessing the EHRs led to an increase in the quality of the clinical decisions [13]. The study concluded that physicians accessing EHRs were more highly informed and thus made more accurate decisions than those who didn’t have access to the medical data.

According to Joint NEMA/COCIR/JIRA Security and Privacy Committee [14], break-glass emergency-access is permitted so as to allow operators emergency access to private information in cases where the normal authentication cannot be successfully completed. Nazerian et al. [15] present an Emergency RBAC, which uses Break-the-Glass policy for managing the system in emergency situation with medical and drug-dispensation scenarios. Maw et al. [16] propose a Break-The-Glass Access Control model to address data availability issues and to detect the security policy violations of medical data in Wireless Sensor Networks. The work of Rabieh et al. [17] focuses on securing the patients’ medical records to preserve their privacy in case of on-road emergencies while providing them with the appropriate medical service. Dumka and Sah [18] propose, in emergency cases, a smart ambulance equipped with information and communications technology to aid the ambulance staff to treat the patient in a more efficient and effective way. Aski et al. [19] proposed a lightweight access control framework that enables the users to access encrypted data and devices in two modes: attribute oriented access and emergency break-glass access.

Padhya and Jinwala [20] propose a mechanism which can handle emergency situations where no authorized user exists to perform or to delegate a time-critical task. Tasali and Vasserman [21] present how to handle Break-the-Glass natively within the ABAC model, maintaining full compatibility with existing access control frameworks, putting Break-the-Glass in the policy domain rather than requiring framework modifications. Rajput et al. [22] propose an emergency access control management system (EACMS) based on permissioned blockchain. This blockchain network provides access to the Personal Health Records data to authorized Emergency Team who has the granular access rights from the database, according the permissions derived from the patient’s rules. According to Ghafghazi et al. [23] effective emergency response requires accurate, relevant, timely, and location-aware information (e.g., environmental information, health records). They propose a location-aware authorization scheme which protects access authorization and privacy, and filters irrelevant data by taking into consideration the time and location of the ongoing emergency.

2.3Contextual attributes for emergency assessment

Context describes a specific situation by capturing the setting or circumstances in which an event occurs. A contextual attribute represents a measurable contextual primitive (e.g., a user’s current location). It is the full set of contextual attributes that comprise the context of a situation (e.g., an access request that is initiated by a user from a specific location, to access a resource, at a particular time of day, on a specified day of the week). Our approach extends ABAC with healthcare-related context handlers that can uplift raw contextual information so as to consider the critically of a patient’s health condition in the access control process.

Attributes in ABAC fall into four different categories [24]: (i) Subject attributes which define the user requesting the access e.g., age, department. (ii) Action attributes which define the requested action e.g., read, delete. (iii) Resource (or object) attributes which define the object of access e.g., the object type (medical record). (iv) Contextual (environment) attributes associated with dynamic aspects of the access control scenario, e.g. time.

To identify contextual attributes that can serve in the assessment of health emergencies, we reviewed several existing works. Yunda et al. [25] consider Age, Body Mass Index (BMI), Gender, Systolic Blood Pressure, and Medication intake as inputs, so as to estimate the Cardiovascular disease risk. Likewise, Kalaivani and Sivakumar [26] evaluate as inputs the Systolic Blood Pressure, Heart Rate, and Blood Sugar so as to estimate the patient’s Risk Level. Guzman et al. [27] propose the attributes of Systolic and Diastolic Blood Pressure in their neuro-fuzzy hybrid model which is proposed as a new artificial intelligence method to classify blood pressure. A novel fuzzy expert system for detection of Coronary Artery Disease, using cuckoo search algorithm, is described by Moameri and Samadinai [28] by considering the attributes: Age, Chest pain type, Resting blood pressure, Electrocardiographic Results, Maximum Heart Rate, and Cholesterol level.

A number of researchers take into account personal characteristics of a user when evaluating access policies. For example, elevated heart rate can be considered critical for a certain patient only if the age, the current activity or even his medical conditions are considered. Leyla and MacCaull [29] focus on Personalized Access Control where the patient decides who can access his health records. Zerkouk et al. [30] propose an access control model, based on the user capabilities and behavior, in order to assist automatically the dependent people according to the occurred situation.

3.1A fuzzy-logic based approach for context handling

We propose and develop advanced context handlers that are able to cope with the inherent ambiguity that exists in interpreting contextual information for detecting potentially critical health-related situations. In such situations the ambiguity exists in the frame of personalisation aspects; e.g., elevated heart rate can be considered critical for a certain patient only if the age, the current activity or even his medical conditions are considered.

As healthcare information can be considered subjective or fuzzy, healthcare applications have been improved by leveraging fuzzy logic-based approaches. Computer-aided diagnosis in medicine is considered one of the most applicable sectors of fuzzy logic [31]. Fuzzy logic has been used in this context to support medical image or biomedical signal analysis, segmentation, and feature extraction/selection. Our approach utilizes fuzzy logic to realize inferencing in relation to context handlers.

Fuzzy logic is intended to model logical reasoning with vague or imprecise statements and emerged in the context of the theory of fuzzy sets, introduced by Zadeh [32, 33]. It is based on the observation that people make decisions based on imprecise and non-numerical information. Fuzzy models or sets are mathematical means of representing vagueness and imprecise information. These models have the capability of making inferences by utilising information that is vague and lack certainty. In healthcare, it is often the case that there exists ambiguity in the definition as well as in the evaluation of attributes. Fuzzy logic provides the opportunity for modelling attributes and dependencies that are inherently imprecisely defined. Moreover, fuzzy logic models imprecise dependencies based on natural language. This simplifies the decision knowledge elicitation process since it is possible to interview medical experts in their own terms, i.e., they can take the rules that they already use in the decision process and model them as fuzzy rules to work within an inference system.

3.2Criticality assessment using fuzzy context handlers

Contextual attributes are used for the definition of access control policy rules. We interviewed experts from the healthcare domain, including information technology officers and medical personnel from healthcare institutions (public agencies, hospitals, emergency services, etc.). Experts were asked to create access control policy rules in a structured way that allowed us to consolidate important contextual attributes that should be considered in our ABAC approach. Table 1 provides an example of an access policy provided by respondents.

The template uses the ‘IF (Requestor Action Resource) AND (context conditions) THEN permit/deny’ rule pattern. For instance, we can define the rule: ‘If a doctor attempts to modify examination results, while his location is in premises (of the hospital), then access is permitted’. Context conditions can be Boolean expressions of simple conditions or other composite conditions. In several cases the simple conditions are constraints on context attributes (e.g., Location IN premises). Simple context conditions can be combined in order to form complex context conditions, using the standard AND, OR, NOT operators. A complete list of the contextual attributes, represented in a context model, is described in the work of Psarra et al. [34].

The criticality assessment of a patient’s condition is made using a rule-based approach. Note, that since many of the contextual variables appearing in [34] are evaluated by experts using linguistic terms, such as ‘if blood pressure is high’, our approach adopts the following fuzzy inferencing process:

Note that alternative fuzzy operators may be used in the various steps of the fuzzy inferencing process. For example, the Mandani Min operator (φc:uA(x)∧uB(y)) may be used in step 2, the Max method in step 4, and the average-of-maxima in step 5.

3.3Example

Let us consider an example in which our approach is applied to estimate the overall critical situation of a patient, so as to decide about granting emergency access to an EHR system. A fuzzy context handler was developed based on the following fuzzy rules which map the fuzzy variables Systolic Blood Pressure (m1) and Diastolic Blood Pressure (m2) with fuzzy values ‘Low’, ‘Normal’, ‘Elevated’, and ‘High’, and the fuzzy variable Heart Rate (m3) with fuzzy values ‘Low’, ‘Medium’, and ‘High’, with the output fuzzy variable Criticality, with values ‘Low’, ‘Medium’, and ‘High’:

The corresponding fuzzy sets of each fuzzy variable appearing in the rules are defined according to the American Heart Association (AHA) for blood pressure [35] and for heart rate [36], see Tables 2 and 3.

We quantify criticality in the form of the fuzzy sets uC/C shown next:

We calculate max (criticality (mi)), which is the maximum value of criticality (mi) of health metric mi and for all values of mi in the dataset. For systolic blood pressure for example, the distribution of criticality (m1) is depicted in Fig. 2. Notice that max (criticality (m1)) = 67. Similarly, we infer that max (criticality (m2)) = 67 and max (criticality (m3)) = 67.

Figure 2.

Distribution of 𝑐𝑟𝑖𝑡𝑖𝑐𝑎𝑙𝑖𝑡𝑦⁢(m1), systolic blood pressure.

Let us assume that a particular patient has the following health status metrics, which are gauged by the emergency dispatch personnel: 𝑆𝐵𝑃1= 110 mmHg, 𝐷𝐵𝑃2= 72 mmHg, HR3= 63 bpm. Using the inference process described in section B, we calculate the corresponding criticalities, that are: 𝑐𝑟𝑖𝑡𝑖𝑐𝑎𝑙𝑖𝑡𝑦(𝑆𝐵𝑃=110)=33, 𝑐𝑟𝑖𝑡𝑖𝑐𝑎𝑙𝑖𝑡𝑦(𝐷𝐵𝑃=72)=33, and 𝑐𝑟𝑖𝑡𝑖𝑐𝑎𝑙𝑖𝑡𝑦(𝐻𝑅=63)=33. If 𝑐𝑟𝑖𝑡𝑖𝑐𝑎𝑙𝑖𝑡𝑦⁢(mi) reaches max⁡(𝑐𝑟𝑖𝑡𝑖𝑐𝑎𝑙𝑖𝑡𝑦⁢(mi)) then the situation is critical, as far as metric mi is concerned Eq. (3.3).

By having calculated the three individual patient’s criticalities per health metric, the overall patient’s criticality is derived according to Eq. (3.3).

So in our example, all individual criticalities give the output ‘NON-CRITICAL’. According to the disjunctive relation Eq. (3.3), given that there isn’t at least one partial result which provides the result ‘CRITICAL’, we conclude that the overall result about the patient’s health condition is ‘NON-CRITICAL’.

3.4Personalization of context handling

We approach the challenge of personalization of context handling by adjusting the fuzzy sets of each fuzzy variable appearing in the rules based on the patient’s profile, by taking into consideration for example her age. The fuzzy sets of each fuzzy variable appearing in the rules are now defined according to the respective ranges per age group of patients (Tables 4–6).

According to the AHA [35], the Systolic Blood Pressure ranges in the following categories: 1) Normal (< 120 mmHg), 2) Elevated (120–129 mmHg), 3) High (hypertension) stage_1 (130–139 mmHg), 4) High (hypertension) stage_2 (140–180 mmHg), 5) Hypertensive crisis (> 180 mmHg). In addition, the normal Systolic blood Pressure per adult age groups ranges in the following categories [37]: 1) 19–40 years (95–135 mmHg), 41–60 years (110–145 mmHg), 61 years or older (95–145 mmHg). The National Health Service (NHS) [38] defines blood pressure ranges of low blood pressure (hypotension) lower than 90 mmHg.

We consider the following ranges of Systolic Blood Pressure of people who belong in the respective age groups 1) 19–40 years, 2) 41–60 years, and 3) older than 60 years, given in the form uS/S. The fuzzy sets of Systolic Blood Pressure for the age group 41–60 are the following: SLOW41-60= {1/60, 1/105, 0.5/110, 0/115, 0/200}, SNORMAL41-60= {0/60, 0/105, 0.5/110, 1/120, 1/ 130, 1/140, 0.5/145, 0/150, 0/200}, SELEVATED41-60= {0/60, 0/140, 0.5/145, 1/150, 1/160, 0.5/165, 0/170, 0/200}, SHIGH41-60= {0/60, 0/160, 0.5/165, 1/170, 1/200}.

Figure 3.

Distribution of criticality (m1, age), systolic blood pressure for the age group 19–40.

Figure 4.

Distribution of criticality (m1, age), systolic blood pressure for the age group 41–60.

According to AHA [35], the Diastolic Blood Pressure ranges in the following categories: 1) Normal (< 80 mmHg), 2) Elevated (< 80 mmHg), 3) High Diastolic Blood Pressure (hypertension) stage_1 (80–89 mmHg), 4) High (hypertension) stage_2 (90–120 mmHg), 5) Hypertensive crisis (> 120 mmHg). In addition, the normal Diastolic Blood Pressure per age group is divided in the following categories [37]: 1) 19–40 years (95–135 mmHg), 41–60 years (110–145 mmHg), 61 years or older (95–145 mmHg). The NHS [38] defines the blood pressure ranges of low blood pressure (hypotension) as lower than 60 mmHg.

We consider the following ranges of diastolic blood pressure of people who belong in the respective age groups 1) 19–40 years, 2) 41–60 years, and 3) older than 60 years, given in the form uD/D. The fuzzy sets of Diastolic Blood Pressure for the age group 41–60 are the following: DLOW41-60= {1/50, 1/63, 1/67, 0.5 /70, 0/73, 0/130}, DNORMAL41-60= {0/50, 0/67, 0.5/70, 1/73, 1/ 87, 0.5/90, 0/93, 0 /130}, DELEVATED41-60= {0/50, 0/87, 0.5/90, 1/93, 1/97, 0.5/100, 0/103, 0/130}, DHIGH41-60= {0/50, 0/97, 0.5/100, 1 /103, 1/130}.

According to Abdullah et al. [39], the fuzzy variable Heart Rate ranges in the following categories: Low, Medium, and High. According to Al-Dmour et al. [40], the following “warning scores” categories are provided: 1) score_3 (> 130 bpm), 2) score_2 (< 40 bpm or 111–130 bpm), 3) score_1 (41–50 bpm or 101–110 bpm), score_0 (51–100 bpm). According to the Centers for Disease Control [41] the heart rate during exercise and the maximum heart rate per age are demonstrated. This particular source informs that the maximum heart rate per age is calculated by the mathematical formula: max heart rate = 220 – age. In our approach, we consider as upper-medium limit the range of 50–85% of heart rate usage [41].

We consider the following ranges of heart rate of people who belong in the respective age groups 1) 19–40 years, 2) 41–60 years, and 3) older than 60 years, given in the form uHR/HR. The fuzzy sets of Heart Rate for the age group 41–60 are the following: HRLOW41-60= {1/40, 1/50, 0.5/55, 0/60}, HRMEDIUM41-60= {0/50, 0.5/55, 1/60, 1/85, 0.5/90, 0/95}, HRHIGH41-60= {0/85, 0.5/90, 1/95, 1/170}.

Figure 5.

ABAC integration within EHRServer.

The distribution of criticality (mi, age) depends on the age group in which the patient belongs to. For systolic blood pressure for example, two distributions of different age groups are depicted in Figs 3 and 4.

The calculation of individual criticality in Eq. (3.3) is modified as follows:

Then, by having calculated the three individual patient’s criticalities per health metric by Eq. (3.4), the overall patient’s criticality is derived according to Eq. (3.3).

To illustrate the effect of personalisation, consider another patient with the following health status metrics, which are gauged by the emergency dispatch personnel: 𝑆𝐵𝑃1= 160 mmHg, 𝐷𝐵𝑃2= 85 mmHg, 𝐻𝑅3= 78 bpm. If the patient’s age group is 19–40, the criticalities are as follows: 𝑐𝑟𝑖𝑡𝑖𝑐𝑎𝑙𝑖𝑡𝑦(𝑆𝐵𝑃=160,𝑎𝑔𝑒=35)=67, 𝑐𝑟𝑖𝑡𝑖𝑐𝑎𝑙𝑖𝑡𝑦(𝐷𝐵𝑃=85,𝑎𝑔𝑒=35)=50, and 𝑐𝑟𝑖𝑡𝑖𝑐𝑎𝑙𝑖𝑡𝑦(𝐻𝑅=78,𝑎𝑔𝑒=35)=33 and the assessment of the overall situation is ‘CRITICAL’. If however, the patient belongs to the age group 41–60, the corresponding value of criticalities are: 𝑐𝑟𝑖𝑡𝑖𝑐𝑎𝑙𝑖𝑡𝑦(𝑆𝐵𝑃=160,𝑎𝑔𝑒=54)=50, 𝑐𝑟𝑖𝑡𝑖𝑐𝑎𝑙𝑖𝑡𝑦(𝐷𝐵𝑃=85,𝑎𝑔𝑒=54)=33, and 𝑐𝑟𝑖𝑡𝑖𝑐𝑎𝑙𝑖𝑡𝑦(𝐻𝑅=78,𝑎𝑔𝑒=54)=33 and the assessment of the overall situation is ‘NON-CRITICAL’. Hence, we derive two different assessment of the situation criticality depending on the patient’s age group.

6.1Permit and deny results for each ABAC method peerage group

The distribution of Permit and Deny results of the access control mechanism using the baseline ABAC method per age group is presented in Fig. 7.

The distribution of Permit and Deny results of the access control mechanism using our non-personalized fuzzy context handler per age group, is presented in Fig. 8.

Figure 8.

Access control results, ABAC with context handlers.

The distribution of Permit and Deny results of the access control mechanism using personalized context handlers per age group is presented as follows in Fig. 9.

Figure 9.

Access control results, ABAC with personalized context handlers.

Notice that ABAC with personalized context handlers achieves the highest number of permits in critical situations, especially on the two older age groups.

Figure 10.

False positives and negatives per age group, baseline ABAC.

Figure 11.

False positives and negatives per age group, ABAC with context handlers.

6.2False positives and negatives for each ABAC method per age group

We also compared ABAC with personalised context handlers vs non-personalised as well as vs baseline ABAC in terms of false positives and false negatives. The former comparison is shown Fig. 11, while the latter is shown in Fig. 10.

Notice that baseline ABAC produces an increasing number of false negatives and positives as patients’ age increases. False negative in particular are high and especially hazardous for the patient’s life.

Similarly, we note that ABAC with non-personalised context handlers is not as capable as ABAC with personalized context handlers in detecting critical situations, especially in the oldest age group that is the most important.