Abstract
In emergency situations, different actors involved in first aid services should be authorized to retrieve information from the patient’s Electronic Health Records (EHRs). The research objectives of this work involve the development and implementation of methods to characterise emergency situations requiring extraordinary access to healthcare data. The aim is to implement such methods based on contextual information pertaining to specific patients and emergency situations and also leveraging personalisation aspects which enable the efficient access control on sensitive data during emergencies. The Attribute Based Access Control paradigm is used in order to grant access to EHRs based on contextual information. We introduce an ABAC approach using personalized context handlers, in which raw contextual information can be uplifted in order to recognize critical situations and grant access to healthcare data. Results indicate that context-aware ABAC is a very effective method for detecting critical situations that require emergency access to personal health records. In comparison to RBAC implementations of emergency access control to EHRs, the proposed ABAC implementation leverages contextual information pertaining to the specific patient and emergency situations. Contextual information increases the capability of ABAC to recognize critical situations and grant access to healthcare data.
Keywords
Introduction
Controlling access to healthcare data is of great importance because the preservation of the privacy of the patient’s information, such as his medical history, is a legal and societal requirement. Access control models deal with the rights a subject has upon performing some operations (such as read, write, etc.) on specific data objects. Prominent access control models that are based on the identity of a user include the Mandatory Access Control (MAC), the Discretionary Access Control (DAC) or the Role-Based Access Control (RBAC) [1]. Apart from these models which are static, a dynamic model has been introduced, the Attribute-Based Access Control (ABAC) [2]. In ABAC, there are no static lists of permissions that associate subjects with objects, but instead there are ‘snapshots’ of such associations that can be generated and dynamically change based on the current context.
ABAC architecture.
In healthcare, contextual information, such as information indicating an emergency or criticality in patient’s medical condition, should be taken into account when granting access to her medical data in order to ensure the best possible medical response. Hence, there is a need to apply access control protocols with capabilities that incorporate the notion of context, i.e., the consideration of dynamically-changing contextual attributes that may characterize a situation. Context can be perceived as any information that can be used to characterize the situation of an entity (person, place, or object) that is considered relevant to the interaction between a user and an application, including the user and applications themselves [3]. In fact, the use of contextual information makes it possible to apply access control policies by considering the circumstances under which access requests should be evaluated. For example, in acute care cases, an emergency doctor wants to access parts of the patient’s healthcare and medical information to cope best with an acute care situation. Contextual attributes values can be acquired for example from IoT sensors. Consider, for example, a smartwatch with blood pressure measurement capabilities. Still, contextual attributes are often too low-level and cannot be used to characterise a situation of used in isolation. Contrary, by processing contextual attributes, context can be uplifted: low-level contextual attributes can be used to detect higher-level context that characterises a situation.
We argue that context handlers can be valuable for enforcing dynamic authorization processes that take into the criticality of a certain health emergency before yielding an access control decision. This is quite important, since in emergency situations paramedics and first response teams should have immediate access to patients’ health records although they could not have been considered in the defined policies at design time.
The research objectives of our work are threefold: First, to develop a method that can be used by medical experts to characterise critical, emergency situations requiring extraordinary access to healthcare data based on dynamically changing contextual attributes. Second, to apply the ABAC paradigm and its context-handling capabilities in order to implement the proposed context-uplifting method for characterising situations. Third, to enable personalisation in the way contextual attributes are used to characterise situations for different users.
Attribute-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.
Emergency 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.
Contextual 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.
Access control policy example
Access control policy example
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.
A 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.
Criticality 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:
Fuzzification of variables. For each variable appearing in the policy rules which is evaluated by experts using linguistic terms, such as blood pressure and heart rate, the fuzzy sets are defined. Calculation of Implication function. Each fuzzy ‘if-then’ rule is a fuzzy relation
where
Composition of fuzzy Relations. The Generalised Modus Ponens (GMP) method ( ) is applied in every rule “if
Composition of Results. Using the Sum method, the partial results obtained in step 3 are composed. Defuzzification of result. Composite results obtained in step 4 are defuzzyfied using the Cendroid defuzzification method in order to produce a crisp value.
Note that alternative fuzzy operators may be used in the various steps of the fuzzy inferencing process. For example, the Mandani Min operator (
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 (
K1
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.
Systolic and diastolic blood pressure ranges
Systolic and diastolic blood pressure ranges
Heart rate ranges
We quantify criticality in the form of the fuzzy sets uC/C shown next:
We calculate max (criticality (
Distribution of 
Let us assume that a particular patient has the following health status metrics, which are gauged by the emergency dispatch personnel:
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’.
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).
Systolic blood pressure ranges
Systolic blood pressure ranges
Diastolic blood pressure ranges
Heart rate ranges
According to the AHA [35], the Systolic Blood Pressure ranges in the following categories: 1) Normal (
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 u
Distribution of criticality (
Distribution of criticality (
According to AHA [35], the Diastolic Blood Pressure ranges in the following categories: 1) Normal (
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 u
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 (
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:
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:
We validated our approach by implementing it and integrating it within EHRServer. EHRServer [42] is an open source clinical information management and sharing platform based on the openEHR standard [43]. We used our approach to handle access control to data stored in EHRServer. We examined the following three test cases.
In the first case, we used the baseline ABAC method to control access. Specifically, if the data requestor is an ER (Emergency Room) doctor and the patients’ metrics are in conjunction above the recommended limit, then the doctor has access to patient EHRs. The policy rule is shown next:
In the second case, we used ABAC with non-personalized context handlers and the following rule:
In the third case, we used ABAC with personalized context handlers. We developed a web application (Fig. 5) so as to implement and validate the three types of ABAC methods.
Finally, we compared the performance of each ABAC method (baseline, non-personalised and personalised context handlers) for each one of the three test cases (Fig. 6). The ABAC method with personalised context handlers does have a performance penalty of approximately a factor of two. The performance penalty does not warrant its application in all but the most demanding applications in terms of performance.
Performance of each ABAC method integrated within EHRServer.
Access control results, baseline ABAC.
To evaluate our approach, we used the PPG-BP (Photoplethysmograph – Blood Pressure) dataset [44], which contains 219 patient healthcare records. The patients’ age varies from 20 to 89 years, with an average age of 58 years. The fields of each record are the following: ID, Gender, Age, Height, Weight, Systolic blood pressure, Diastolic blood pressure, Heart rate, BMI, Diseases (hypertension, diabetes, cerebral infarction, cerebrovascular disease). Three different emergency scenarios have been considered, based on the health metrics of systolic blood pressure, diastolic blood pressure, and heart rate. Comparisons between baseline ABAC, ABAC with context handlers and ABAC with personalized context handlers are shown.
Access control results
To evaluate the capability of our approach to characterise critical situations and to permit or deny access to data using the ABAC paradigm, we assessed the distribution of permit and deny results as presented next.
Permit 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.
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.
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.
False positives and negatives per age group, baseline ABAC.
False positives and negatives per age group, ABAC with context handlers.
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.
Discussion
Employing personalized context handlers for emergency access control has the following advantages. First, access control is based on both objective patients’ metrics and subjective expert knowledge. The latter in particular is easy to elicit and represent using a fuzzy logic approach, in which rules connect the fuzzy variables of each health metric with the criticality, which states the level of patient’s health risk. Second, except from the patient’s health metrics, additional personal information are taken under consideration such as the patient’s age. Third, access control is evaluated based on a fuzzy rule-based inference process, which inferences the criticality risk of patients based on the fuzzy rules.
The limitations of our approach include the fact that only the age and a limited set of health metrics are taken into consideration in the fuzzy rules. The corresponding rules are reported as sound by medical experts; nevertheless, the incorporation of additional metrics would improve the completeness of the rules. Additional metrics include gender, BMI, education level, existence of chronic diseases, even lifestyle contextual information such as smoking or drinking habits.
In comparison to RBAC implementations of Break-the-Glass access control, in which the healthcare emergency medical team has predefined access in emergency situations because of their role, the proposed ABAC implementation leverages personalized context which takes into account patient’s characteristics and current health metrics. It is worth highlighting that in our scenario, the break-the-glass access decision is made by ER medical personnel. Specifically, the personalized context handler’s result (permit or deny) is sent to the ER team along with the patient’s current health metrics and age. By having at their disposal both the system’s access result and the patient’s contextual information, the ER team can make an informed final decision.
Additionally, it is worth mentioning that the context handlers implemented in this work, where access policies are specified by directly using contextual information (e.g. the patient’s age), manage adequately the dynamic attribute values. On the contrary, CapBAC lacks dynamicity as the capability token is composed by the permissions that a subject has upon an object.
Conclusions
In an emergency situation, the criticality of a patient’s medical condition should be taken into account when granting access to her EHR. Such emergency access controls are necessary so that healthcare professionals make informed decisions in life threatening situations. In this work, we introduced contextual attributes that serve in the criticality assessment of situations where access to patients’ data is requested. We extended ABAC with healthcare-related context handlers, capable of inferring access policies by dynamically evaluating contextual attributes when granting access to healthcare data. We also created personalized context handlers so as to take into account the specificities of each patient when inferring access policies. ABAC with personalized context handlers is more capable than baseline ABAC and ABAC with non-personalised context handlers in detecting critical situations, especially in the oldest age group that is the most important.
Footnotes
Acknowledgments
This research has received funding from the EU, project H2020 826093, Asclepios (https://www.asclepi os-project.eu/).
