Enhancing Healthcare Security: A Unified RBAC and ABAC Risk-Aware Access Control Approach

Abstract

Healthcare systems are increasingly vulnerable to security threats due to their reliance on digital platforms. Traditional access control models like Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) have limitations in mitigating evolving risks in these systems. Despite their unique features, these models face limitations in mitigating evolving risks in healthcare systems. Traditional models are primarily oriented towards allocating permissions according to predetermined roles or policies, which results in challenges in effectively adapting to the dynamic complexities of modern healthcare ecosystems. Therefore, this paper proposes a novel risk-aware RBAC and ABAC access control model to enhance the flexibility, adaptability and security issues associated with healthcare systems. The proposed model integrates RBAC for role-based categorization, ABAC for fine-grained control based on user attributes and environmental factors, and Risk-Based Access Control (RiBAC) for dynamic risk assessment. The proposed model dynamically adjusts access permissions based on risk values, ensuring accurate and adaptable access control decisions. The experimental results demonstrate the feasibility and effectiveness of the proposed model in granting access to authorized users while denying access to unauthorized users. Through a series of 43 experiments that simulate various scenarios of access control operations in the healthcare system, the proposed model demonstrates significant improvement in the accuracy, precision, and recall of access control decisions compared to traditional models. The proposed model’s ability to dynamically assess risk and adjust access permissions based on contextual factors significantly enhances its ability to mitigate threats and protect sensitive medical data.

1. Introduction

The rapid integration of information technology into the healthcare sector has accompanied unprecedented advancements that revolutionize healthcare services. This digital evolution encompasses the adoption of electronic health records (EHRs), telemedicine, wearable health devices, and advanced data analytics, which have collectively enhanced the efficiency, accuracy, and accessibility of the healthcare system. However, alongside these improvements, the digital transformation has also introduced a variety of security challenges. As healthcare systems increasingly depend on interconnected digital platforms, safeguarding the confidentiality, integrity, and availability of sensitive patient data has become a paramount concern [1]. The proliferation of cyber threats, such as ransomware attacks, data breaches, and unauthorized access, highlights the vulnerability of healthcare data to malicious activities. Protecting this sensitive information is critical not only to comply with regulatory requirements such as the HIPAA (Health Insurance Portability and Accountability Act) but also to maintain patient trust and ensure the safe and effective operation of healthcare services [2,3].

Access control is a crucial solution when it comes to addressing security concerns related to such issues. It enables the denial of unauthorized users and restricts specific operations (e.g., read, write, and delete) performed by authorized users [4,5]. In the digital domain, traditional access control models protect sensitive data and resources in various domains, including healthcare systems. These models refer to methods used to manage access to sensitive data to ensure that only authorized users can interact with the resources. In healthcare systems, these resources include EHRs, patient information, employee information, and other sensitive data [6].

Traditional access control models face limitations in adapting to the dynamic risks of modern digital healthcare systems. These models, including Role-Based Access Control (RBAC), Discretionary Access Control (DAC), and Mandatory Access Control (MAC), each have their unique advantages to ensure security and availability in different contexts [7]. However, the access control models commonly employed in today’s systems are falling short of addressing the dynamic risks associated with health systems in today’s digital environment. Traditional access control models rely on role-based permissions and rarely provide fine-grained access control. These models are hard to adapt to the dynamic nature of modern healthcare environments [8,9].

To address the shortcomings of traditional access control models, this paper proposes a novel composite access control model that integrates three key models: RBAC to provide the system with resource optimization capabilities; Attribute-Based Access Control (ABAC) to offer fine-grained access control; and Risk-Based Access Control (RiBAC) to enable dynamic adjustments to access decisions. The integration of these access control models is utilized to compensate for the limitations that arise from their isolated application. This integrated approach streamlines access management through role-based categorization while considering detailed attribute-based context and dynamic risk assessment. When applied to healthcare systems, this novel model enhances their overall performance, adaptability, and security. To the best of the authors’ knowledge, this is the first paper to discuss integrating these approaches, as highlighted after reviewing the state-of-the-art literature.

The contribution of this paper can be summarized as follows:

• It proposes a novel risk-aware RBAC and ABAC access control model to enhance the flexibility, adaptability, and security issues associated with modern healthcare systems. This addresses the limitations of traditional access control models by providing a more comprehensive and flexible approach to managing access to sensitive healthcare data.
• It proposes an integrated access control model that combines RBAC, ABAC and RiBAC to enhance the performance, adaptability and security issues associated with modern healthcare systems.
• It develops a risk-aware framework that incorporates dynamic risk assessment. This allows the system to adapt to changing threats and vulnerabilities in the healthcare environment.
• It validates and evaluates the proposed risk-aware RBAC and ABAC using 43 healthcare scenarios to assess the effectiveness of the integrated model to grant access to authorized users while denying access to unauthorized users.

The structure of this paper is organized as follows: Section 2 presents a comprehensive analysis of related models discussed in the existing literature. Section 3 introduces the proposed risk-aware RBAC and ABAC model. In Section 4, the implementation of the proposed model within a healthcare context is thoroughly examined and discussed. Section 5 presents the experimental results alongside an in-depth analysis, while Section 6 provides a detailed discussion and evaluation of the findings. Finally, Section 7 concludes the paper, summarizing key insights and implications of the research.

2. Related Work

Building a context-aware access control model that can dynamically adjust access permissions based on the changing context to ensure that users only have the necessary privileges at any given time has become crucial due to the dynamic nature of different systems. Kayes et al. [4] proposed a context-aware access control model utilizing fuzzy logic for cloud-based data resources. Their approach incorporates both fuzzy and contextual conditions into access control policies to address the vague nature of some contextual information. Another context-aware model was proposed by Kayes et al. [5] to address the challenge of context-aware access control in distributed cloud environments by proposing a Fog-Based Context-Aware Access Control (FB-CAAC) model. This model leverages fog computing to reduce latency and processing overheads to move application logic execution closer to the network edge. The authors enhance the access control mechanism by incorporating both fuzzy and precise contextual conditions to facilitate granular and dynamic access decisions.

Risk-based models have attracted significant attention from researchers across diverse disciplines due to their robust applications and potential to improve decision-making processes. These models are designed to identify, assess, and mitigate risks, thereby enhancing effectiveness in access decision operations. Evina et al. [10] explored the concept of risk management in access control systems. The authors provide a comprehensive overview of existing research and classify various approaches into two main categories: access-based and policy-based. They mainly focused on the policy-based approach and analyzed various articles that address risk assessment in access control policy expressions. The authors proposed a system that incorporates risk from correlated anomalies to add a new perspective to risk assessment. Jayabalan [11] also investigated the integration of risk analysis into access control mechanisms to address the limitations of traditional static access control models in dynamic environments. The author presented a taxonomy of risk analysis approaches and categorized them into score-based, rule-based, and hybrid methods. The author analyzed various techniques, including user behavior, fuzzy inference, and context/object-based risk assessment.

Other researchers proposed practical solutions to implement risk-based models in various applications. Atlam et al. [6] introduced a risk-based model for the Internet of Things (IoT). This model considers four risk factors: user/agent context, resource sensitivity, action severity, and risk history. It evaluates the security risk associated with each access request and sets a risk policy using XACML (eXtensible Access Control Markup Language). Additionally, Atlam et al. [12] proposed another Risk-Based Access Control model for the IoT that uses real-time and contextual features to generate dynamic access decisions. The critical aspect of this model involves analyzing the risk associated with each access request to determine whether to permit or deny access, which is performed dynamically according to the estimated risk. The authors considered several risk factors that could affect access decisions, including the time and location of the access request, the identity of the user, and the sensitivity of the requested resource [13]. The authors argued that the traditional access control models do not consider these contextual factors, which may result in over- or under-privilege, leading to security breaches. By incorporating these contextual factors into the risk assessment process, the new model offers more robust and dynamic access control decisions for the evolving IoT environment.

Huang et al. [14] focused on defining an approach that generates customized countermeasures by proposing a new paradigm in access control environments named Risk-Adaptable Access Control (RAdAC). The model consists of three core modules: risk level, operational requirements, and access control policy. The RAdAC engine provides the functionality that compares the calculated risk from the designed risk level module with the acceptable risk level defined by the access control policy for each access request. The proposed estimation technique uses a scoring system to quantify the likelihood and impact of a particular threat and calculates an overall risk score for each asset. This risk score is then used as input to a genetic algorithm to generate a set of countermeasures.

Investigating further into the Risk-Based Access Control models, Kandala et al. [15] suggested integrating attribute-based and risk-based models. Their approach defines the use of ABAC to enforce policies based on user attributes. At the same time, the risk-based layer evaluates contextual factors such as user behaviors and locations to adjust the decision generated by ABAC. Similarly, E. Nakamura and S. Ribeiro [16] proposed another access control model that integrates the ABAC and RiBAC models. The proposed structure dynamically adjusts ABAC policies based on risk assessments, ensuring flexible access control decisions. More Risk-Based Access Control models were presented. Shaikh et al. [17] and Shaikh et al. [18] introduced a dynamic Risk-Based Access Control model wherein the user’s past behaviors and risk history were utilized to estimate the security risk associated with each access request. Furthermore, this method involved assigning reward and penalty points to subjects/users upon transaction completion, dependent upon the assessed risk value associated with the transaction. Building upon the groundwork presented in [17], the research outlined in [18] expanded upon the implementation process of risk estimation to differentiate between users exhibiting good and malicious behavior patterns based on their past behavior. In the same way, Arias-Cabarcos et al. [19] integrated the Risk-Based Access Control model into the federated identity management framework within cloud computing. This integration leveraged security risk assessments to guide access decisions and mitigate vulnerabilities and risks inherent in collaborative endeavors. Additionally, their study introduced a hierarchical risk aggregation system tailored for cloud federation scenarios.

Liu et al. [20] proposed RASA, a risk-aware access control model that leverages unsupervised machine learning to automatically infer context-sensitive authorization decisions. RASA addresses the challenges of managing authorization contexts in dynamic environments by analyzing historical access logs and identifying patterns of access. The model utilizes coupling mechanisms to track the coexistence of objects within a context, clustering these couplings based on frequency and the duration of coexistence. By associating risk levels with these clusters, RASA dynamically defines authorization boundaries to ensure that access is granted only when appropriate. The study evaluates RASA in a simulated healthcare environment to demonstrate its effectiveness in protecting sensitive patient information. Abomhara et al. [21] proposed a risk-aware access control model for healthcare information sharing, extending the Work-Based Access Control (WBAC) model by incorporating risk assessment. The model calculates the risk associated with each access request based on the user’s trust level and the object’s security level to weight it against the organization’s risk threshold. Access is granted if the risk threshold outweighs the risk of granting access; otherwise, it is denied. The model dynamically calculates user trust based on their past behavior to assign different weights to recent and older events.

Researchers have proposed integrating the RBAC with the risk model (RiBAC) to provide a more fine-grained and flexible access control model. For example, Chen and Crampton [22] integrated security risk into RBAC, forming a risk-aware RBAC model. Their work investigated the challenges surrounding the devised risk-aware model and outlined the steps involved in its implementation. Similarly, Bijon et al. [23] introduced a model that merges RBAC with RiBAC to determine access decisions. Their work introduced the concept of RBAC-based risk-awareness and provided a formal depiction of an adaptive risk-aware RBAC model. Also, Badar et al. [24] introduced the utilization of classification for evaluating the risk associated with each access request. Their study explained two distinct approaches: firstly, employing an access control matrix to gauge the risk associated with access grants based on user–permission assignments; secondly, identifying the optimal contextual role that minimizes risk while maximizing accessibility by integrating security risk considerations with RBAC. In the same way, Baracaldo and Joshi [25] introduced a model that extends the traditional RBAC model by integrating trust alongside risk to inform access decisions. They argued that their model offers adaptability to variations in user behavior by employing a threshold value derived from a risk assessment procedure.

On the other hand, an approach that integrates ABAC and RBAC to address the limitations of implementing these models independently was proposed by Aftab et al. [7]. This approach offers the benefits of both approaches and emphasizes automatic permission creation and role assignment based on object attributes. The authors argue that the dynamic nature of their model eliminates the need for manual updates. They then explain the process of automatically assigning permissions to user roles using object properties. Such a process eliminates the need to assign permissions in traditional RBAC manually and simplifies the authorization assignment process by assigning permissions to roles by matching attribute expressions. Huang et al. [26] also solved the challenges associated with implementing two access control models independently by integrating ABAC’s policy evaluation component based on RBAC. It merges the straightforward structure of the RBAC model with the awareness offered by the contextual attributes from ABAC. Unlike traditional access control approaches, this framework automatically assigns roles based on attributes of objects rather than setting permissions individually by specific root users. The authors highlight the potential capability of their proposed model in dynamic environments, particularly within critical domains like industrial control systems.

Furthermore, Wu et al. [27] developed a context-aware RBAC model that integrates traditional Chinese and Western medicine practices. They enhance the system’s access control decisions by incorporating contextual awareness into the traditional RBAC basis. While highlighting the advantages of the proposed model in managing the combination of traditional Chinese and Western medicine in the medical system, the authors also mention potential challenges, including implementation complexity and the absence of comprehensive guidelines for similar system implementations. Also, Afshar et al. [28] proposed an ABAC model for healthcare systems to replace the traditional RBAC approach. The authors argued that their proposed ABAC model delivers enhanced flexibility and finer granularity in access control of the healthcare system.

Akhuseyinoglu and Joshi [29] proposed a constraint and risk-aware approach to ABAC. Their model is composed of a Cyber-0Physical Access Control (CPAC) model and a Generalized Action Generation Model (GAGM) to enhance traditional ABAC by incorporating cyber–physical components and interactions. The CPAC model integrates Separation of Duty (SoD) constraints to support security, while the GAGM helps in enforcing access policies. Also, Rath and Colin [30] proposed an adaptive risk-aware access control model for the IoT to address security and privacy concerns in data sharing. The authors argue that traditional access control models like ACL, RBAC, and ABAC are insufficient for IoT scenarios due to their inability to dynamically assess risk based on user profiles and behavior. They introduced a risk model that assigns a risk threshold and evaluation function to each risk to allow the system to adaptively enforce access permissions based on the estimated risk. The proposed model is integrated into existing access control models, specifically ABAC and P-RBAC, to enhance their security and privacy capabilities. Aluvalu and Muddana [31] also proposed a dynamic attribute-based risk-aware access control model (DA-RAAC) for cloud computing. The model addresses the limitations of existing static attribute-based encryption (ABE) models by incorporating risk computation into access control decisions. DA-RAAC allows data owners to define access policies based on user attributes and dynamically adjust access based on a calculated risk threshold.

Table 1. Categorization and summary of access control models.

Citation	Access Model	Contribution	Limitation
Kayes et al. [4]	RBAC	Proposed a fuzzy-based context-aware model enhancing flexibility.	Relies on accurate context info; lacks scalability and security evaluation.
Kayes et al. [5]	RBAC	Created a FB-CAAC model to reduce admin overhead.	Does not optimize performance in fog computing.
Evina et al. [10]	RiBAC	Proposed a risk-based model based on policy-based approach.	No practical implementation or algorithm design.
Jayabalan [11]	RiBAC	Developed a taxonomy to assess risk-based techniques.	Purely theoretical with no application validation.
Atlam et al. [6]	ABAC, RiBAC	Proposed a risk-based model that integrates XACML for IoT.	Conceptual only and lacks real-world tests.
Atlam et al. [12]	ABAC, RiBAC	Developed a Neuro-fuzzy risk model for IoT.	Single-dataset evaluation; generalizability unknown.
Huang et al. [14]	RBAC, RiBAC	Proposed a RRAAC based on environmental and user risk.	No evaluation in real-world scenarios.
Kandala et al. [15]	ABAC, RiBAC	Integrates ABAC and RiBAC via heuristics.	Risk calculation method is unclear.
Nakamura and Ribeiro [16]	ABAC, Developed a RiBAC	Proposed a risk-based ABAC for privacy and trust in healthcare.	No implementation or trust quantification provided.
Shaikh et al. [17,18]	RiBAC	Developed a Trust-based dynamic risk-aware access.	Obligation service remains unimplemented.
Arias-Cabarcos et al. [19]	RiBAC	Developed risk metrics taxonomy for federated identity.	Needs real-world validation of metrics.
Liu et al. [20]	RiBAC	Proposed RASA to use machine learning for access decisions.	Relies on historical data availability.
Abomhara et al. [21]	RiBAC	Proposed trust and object security risk evaluation.	Accuracy of trust/security values assumed.
Chen and Crampton [22]	RBAC, RiBAC	Developed trust-based RBAC using perceived appropriateness.	Unfeasible trust/competence measurement functions.
Bijon et al. [23]	RBAC, RiBAC	Developed a quantified risk approach in RBAC constraint violation	Ignores role-user and permission-role constraints.
Badar et al. [24]	RBAC, RiBAC	Proposed two models based on permission-role risk analysis.	Lacks detailed risk computation logic.
Baracaldo and Joshi [25]	RBAC, RiBAC	Proposed a risk-trust RBAC to prevent insider threats.	Tailored only for insider-specific threats.
Aftab et al. [7]	RBAC, ABAC	Proposed a hybrid RBAC-ABAC for automatic role assignment.	Central attribute DB is security bottleneck.
Huang et al. [26]	RBAC, ABAC	Proposed a hybrid model with RBAC and ABAC layers.	Lacks real-world validation and scalability tests.
Wu et al. [27]	RBAC, ABAC	Developed a contextual RBAC in integrative medicine.	Needs evaluation of scalability/platform deployment.
Afshar et al. [28]	RBAC, ABAC	Developed dynamic permissions in hybrid RBAC-ABAC.	Real-world ABAC challenges not addressed.
Akhuseyinoglu and Joshi [29]	ABAC, RiBAC	Proposed a CPS-aware risk model with granularity.	No real deployment; context limited to medical CPS.
Rath and Colin [30]	RiBAC	Proposed a dynamic risk thresholds for IoT access.	Depends on timely and accurate risk data.
Aluvalu and Muddana [31]	ABAC, RiBAC	Developed a DA-RAAC model for adaptive cloud access	Heavily reliant on tuned risk engine.

categorizes and summarizes various access control models used in relevant studies, detailing their contributions and limitations.

In summary, the studies reviewed from the literature have explored various aspects of access control models with different compositions and emphasized the benefits of each model. However, providing a secure, effective, and dynamic access control model that overcomes issues of traditional and existing models is still one of the big challenges that need to be resolved. The current access control approaches lack flexibility in adapting to dynamic changes in user roles, permissions, and organizational structures. In addition, they lack interoperability between different access control systems. Hence, this paper addresses these challenges by providing a novel integrated access control model that integrates RBAC, ABAC, and RiBAC to provide an effective access control approach for the healthcare domain. The proposed model not only provides the theory of integration but also provides practical insights into the integration process, thereby offering a deeper understanding of the interaction between RBAC, ABAC, and RiBAC models.

3. Risk-Aware RBAC and ABAC Model: Proposed Approach

The limitations of traditional access control systems have become increasingly apparent, which often struggle to cope with the dynamic and complex nature of modern healthcare environments. The complex relationship of diverse roles, varying levels of sensitivity in patient data, and the need for timely access for healthcare professionals pose substantial challenges for these models [32]. Additionally, traditional access control mechanisms lack the granularity required to differentiate between users based on their specific attributes, leading to potential security vulnerabilities and privacy concerns. As healthcare systems become more interconnected and data-driven, a more adaptive and comprehensive approach to access control becomes imperative.

RBAC offers a structured approach to permission management by assigning predefined roles to users based on their responsibilities to simplify access control administration in healthcare environments. This model aligns well with organizational structures, ensuring individuals have the necessary access rights for their specific tasks [33]. Similarly, ABAC introduces flexibility by considering various attributes like user characteristics and environmental conditions, enabling fine-grained control over access permissions. In healthcare, where dynamic access requirements prevail, ABAC proves invaluable in adapting to changing circumstances and ensuring precise access control. In the same way, RiBAC adds a layer of sophistication by dynamically adjusting access permissions in response to perceived risk factors [34]. This is particularly crucial in healthcare, where the sensitivity of patient data requires real-time adjustments to access privileges, proactively mitigating potential risks and enhancing overall information security in healthcare systems. While each of these elements possesses distinct advantages, their standalone application in modern healthcare applications holds inherent limitations.

Therefore, this paper proposes a novel risk-aware RBAC and ABAC access control model by integrating RiBAC, RBAC, and ABAC approaches, as shown in Figure 1, to provide a dynamic and fine-grained model for healthcare systems. The proposed model uses not only users’ roles within their organizations and their dynamic attributes but also the estimated risk value associated with each access request to determine the access decision. The conceptualization of an integrated model incorporating RiBAC, RBAC, and ABAC represents a novel contribution to the scholarly landscape. This novel approach holds significant promise, particularly for healthcare systems. By combining these distinct approaches, our proposed model offers several advantages. Firstly, it enhances the granularity of access control mechanisms to enable finer-grained control over sensitive healthcare data. Secondly, it facilitates more dynamic risk assessment and mitigation strategies, which is vital for safeguarding patient confidentiality and ensuring regulatory compliance. Lastly, the integration of RiBAC, RBAC, and ABAC modules fosters a more adaptive and context-aware access control model that is better suited to the dynamic and multifaceted nature of modern healthcare systems.

The structure of the proposed risk-aware RBAC and ABAC model can be divided into three main layers, as depicted in Figure 2. These layers work together in a sequential and complementary manner to deliver robust, efficient, and context-aware access control. The layers are as follows:

• Layer 1: Role-Based Access Control (RBAC) Layer: This is the outermost layer, where initial access decisions are made based on the user’s assigned role. It is implemented at the Policy Enforcement Point (PEP), acting as a gatekeeper that intercepts access requests at the Application Programming Interface (API) or service interface. In practical deployments, APIs serve as the main gateway through which external users and systems interact with the healthcare platform. These APIs are not openly accessible; instead, they are typically protected by the PEP, which acts as the initial access checkpoint within the system. The PEP intercepts all incoming requests and evaluates them against pre-defined access control rules before forwarding them to internal services. This enforcement mechanism ensures that unauthorized access attempts are blocked at the earliest possible stage. In our proposed model, this behavior is implicitly represented through the inclusion of the PEP at the interface between the user and the internal system components. While the API itself is not visually presented in the diagram, its function is inherently embedded within the PEP layer, which reflects how API access is managed and secured in real-world healthcare systems. If a user attempts to access a resource or API without possessing the appropriate role privileges, the request is denied immediately, and it does not proceed to the subsequent layers. Although there is no distinct branch showing the early blocking of unauthorized requests at the RBAC layer in the diagram, this behavior is implicitly enforced through the PEP. Requests that do not meet the required role privileges are terminated at this stage and do not proceed to the subsequent risk and attribute evaluation layers. This early rejection mechanism helps reduce system load, improves resource utilization, and enhances performance by preventing unnecessary evaluations of invalid requests at deeper layers.
• Layer 2: Risk-Based Access Control (RiBAC) Layer: The second layer incorporates a Risk Engine, which enables real-time contextual awareness and dynamic decision-making. This layer does not enforce access decisions on its own but plays a critical supporting role by evaluating contextual and behavioral factors, including user activity history and behavioral patterns, the sensitivity of the requested resource, access time, location, device, and environmental factors. These elements are used to calculate a dynamic risk score, which represents the trustworthiness of a specific access request in the given context. This risk score is then passed as an enriched attribute to the next layer (ABAC), allowing for adaptive and fine-grained policy enforcement that reflects the dynamic security posture of the system.
• Layer 3: Attribute-Based Access Control (ABAC) Layer: At the core of the proposed model lies the ABAC layer, which is responsible for making the final access control decision. This layer is anchored by the Policy Decision Point (PDP), which evaluates policies based on a combination of static attributes (e.g., user role, resource type, action) and dynamic risk values received from the RiBAC layer. The ABAC engine retrieves relevant policies from a policy repository, often managed by the Authzforce PDP engine, and collects additional attribute data from the Policy Information Point (PIP). The policy evaluation process considers both static and dynamic inputs, enabling context-sensitive, fine-grained access control decisions that reflect the system’s current risk environment.

Together, these three layers establish a comprehensive and hierarchical access control model. The RBAC layer enforces baseline access eligibility, the RiBAC layer introduces dynamic risk intelligence, and the ABAC layer applies granular, adaptive policies to determine the final authorization outcome. This layered architecture enhances both security and system efficiency by combining the strengths of traditional access control models with modern context- and risk-aware mechanisms.

The flow of access requests through RBAC, RiBAC, and ABAC involves a structured process aimed at ensuring secure and appropriate access within a system. Initially, RBAC defines access based on predefined roles to determine whether a user’s role aligns with the requested target (API). Subsequently, RiBAC evaluates the potential risks associated with the request, considering factors like environmental factors (e.g., time, location), resource factors (e.g., data sensitivity) and subject factors (e.g., user history) before forwarding it to the ABAC layer for further evaluation. In the final stage, ABAC dynamically evaluates access requests based on an array of collected attributes, including user privileges, environmental conditions, and risk levels, allowing for fine-grained control. Integrating these methods significantly enhances access control effectiveness, with continuous refinement based on feedback and adaptive adjustments to evolving security threats and user roles. This design enables the proposed model to exhibit enhanced adaptability in responding to diverse emergency scenarios, thereby mitigating the inherent instability of healthcare systems during accidents while concurrently maintaining an exceptionally high level of security.

To contextualize the proposed model within existing research, it is important to highlight its novel integration of RBAC, ABAC, and RiBAC models. While previous models discussed in the literature have implemented individual or partial combinations of these approaches, the proposed model uniquely blends them to provide a layered, dynamic, and context-aware access control solution tailored to the complex and evolving requirements of healthcare systems. This integration enables enhanced features such as dynamic risk assessment, simplified administration, and scalability—characteristics that are not addressed in existing models.

4. Implementation of Proposed Model in Healthcare Scenario

The proposed model is a synergistic integration of RBAC, ABAC, and a sophisticated risk engine (RiBAC), organized into a three-layered structure. Through the combination of these access control approaches, the proposed model utilizes the strengths of the individual models while mitigating their inherent limitations. This integration ensures adaptability to changing circumstances and conditions, granting precise access control decisions, and fostering enhanced information security in modern healthcare systems.

This section discusses the implementation of the proposed model. It starts by presenting the real-world scenario that will be used in the implementation to identify various parameters and values needed for the implementation. Then, the implementation of the proposed model will be presented by discussing the implementation steps of each one of the models and their integration to provide an effective and accurate access control decision for the healthcare access control scenario.

4.1. Healthcare Scenario: MC Children’s Hospital

To implement the proposed risk-aware RBAC and ABAC model, several attributes and values of the risk factors need to be quantitatively identified. Hence, a closed-world scenario is used in the implementation process and the scenario is used to check the applicability of the proposed model in real-world scenarios in the healthcare system.

Implementing the proposed model using real-world scenarios offers several key advantages. It provides a rich context for thorough testing within complex healthcare systems, enhancing understanding and decision-making. This approach validates design assumptions, ensuring the model accurately reflects the dynamic and evolving nature of healthcare environments. It also helps identify unexpected challenges, improving the model’s robustness and adaptability, especially in emergency situations. Furthermore, real-world testing ensures compliance with stringent regulations like HIPAA and GDPR, ensuring the model meets necessary legal and ethical standards.

4.1.1. Scenario Description

A closed-world scenario involving a healthcare provider, namely Mount Cedar (MC) Children’s Hospital [12,35], was utilized to implement the proposed risk-aware RBAC and ABAC model. In hospital environments, patient information is commonly managed and stored as structured datasets, each uniquely identified by an object identifier (OID). These datasets can be grouped into classes, allowing for collective reference under a common designation. Each class is associated with an object profile, which is a metadata structure that encapsulates descriptive and contextual information about the dataset, thereby supporting more granular access control and data management decisions. While the core structure of the scenario, such as the hospital setting, roles (e.g., doctors, nurses, administrative staff), and types of access requests, remains consistent with [12,35], we have made specific modifications to align the scenario with the requirements of our proposed model. For instance, we extended the contextual and behavioral parameters associated with each access decision, refined the assignment of risk scores based on cumulative risk analysis, and incorporated more nuanced access patterns to reflect hybrid access control conditions.

Suppose the MC hospital has now received a four-year-old child called Harry, who was brought into the MC’s first aid clinic by his mother, Eva, late Wednesday evening. The admitting staff observed that Harry suffered from several bruises all over his body, a fractured rib, and a distorted shoulder [12,35]. Let us walk through the events that would occur in this situation. Initially, Harry’s doctor in the first aid clinic, Dr. Chris, made an access request to the system to view or read Harry’s history file in the Electronic Patient Record (EPR). He also assigned Harry to a care team involving a set of nurses and ordered a series of examinations. The leader nurse of the care team made an access request to the system to read Harry’s file in the patient’s EPR.

When the examination results were returned, Dr. Chris wrote the diagnosis and the required medication for Harry and called social workers and policemen to investigate the incident, as he suspected child abuse had occurred. Therefore, one of the social workers who was responsible for helping the children in the case of abuse and a police officer requested to access Harry’s medical information for investigation purposes.

4.1.2. Scenario Actors

The MC is a children’s hospital, and the actors involved in this scenario include

• The child who needs treatment;
• Doctors who are responsible for providing care to the child;
• Nurses who are responsible for helping the doctors;
• Admin who represents the IT security administrator in the hospital;
• Social workers who are responsible for helping the children in case of trauma or abuse;
• Police officers who are responsible for investigating and establishing possible criminal charges and responsibilities in cases of trauma or abuse.

Building upon the healthcare scenario previously explored in the literature [12,35], the next sections will present the implementation of each access control model, RBAC, RiBAC, and ABAC, and their integration within this specific context.

4.2. Role-Based Access Control Implementation

RBAC provides a coarse-grained approach to control user identities, where access decisions are based on predefined user roles [36]. The RBAC is adopted as the foundational layer of the proposed model, which is mainly designed to authenticate user identities and pre-emptively filter out unauthorized resource requests, thereby improving system efficiency and performance. The most common way to implement RBAC is by manually integrating access control checks directly into the application code, adding condition-checking logic at various points. While suitable for small projects with limited user roles, this approach becomes difficult to maintain and scale as the application grows, leading to code duplication and decreased maintainability. To address these challenges and ensure better integration with other dynamic access control components, Aspect-Oriented Programming (AOP) was adopted as the preferred development paradigm. A sequence diagram illustrating the AOP of the RBAC is shown in Figure 3.

AOP offers a unique advantage in developing a risk-aware RBAC system, making it the best fit for this research. It allows us to modularize cross-cutting concerns, such as logging, error handling, and security, and separate them from the central business logic. This decoupling of access control policies from the application code results in better code maintainability and extensibility. To maintain security in a risk-aware RBAC system, access control decisions need to consider real-time contextual data and risk factors. AOP’s dynamic nature enables us to adjust access control policies during runtime, depending on the changing conditions. This dynamic policy enforcement ensures that access decisions are tailored to the current risk environment, thereby improving the system’s security. AOP also served as the Policy Enforcement Point (PEP) in our integrated approach for the later ABAC model. The predefined AOP for the RBAC enables seamless integration with the rest of the ABAC components (PDP and PIP), which means once the request passes the role-based authentication/verification, it will redirect to the PDP instead of directly visiting the API.

To implement user role verification/authentication with RBAC, a container class called a token pool was created to manage user roles. The class holds a HashMap objective, which will store user IDs and their tokens. The primary function of this class is to put the user ID and a unique UUID into the token pool, indicating that the user has logged in and providing the necessary user identity for future access control measures. For the authentication process, the system sends the token back to the user’s browser once the user passes the login checks. The browser will store the token in the session storage for a limited time. When the user attempts to send a request to the back end, the system asks the user to send the token to identify the user’s identity based on the received token. The user will receive a JSON object that includes their login status and token. There are four possible scenarios in which a user request may be rejected by the AOP layer. The request will be processed to further access controls once it passes all four checks:

1.

Absent Token: The token was not presented, and the user may not login yet.

2.

Invalid Token: An invalid token was presented; the user may be signed out.

3.

Expired Token: The token has expired; the user may need to login again.

4.

Invalid Privilege: A valid token was presented.

Once the RBAC layer in the proposed integrated model is designed, the next step is to determine the user roles and their corresponding permissions. The user’s identity determines the operations they can perform (e.g., read, write, and delete) and the type of data they can access (e.g., medical records) in the system. From the MC Children’s Hospital scenario that we discussed earlier, we recognize five primary identities: doctors, nurses, administrators, social workers, and police officers [12,35]. The admin will be able to access all the file types, while other actors will only be allowed to access medical records.

To simplify the implementation process regarding data types in the healthcare scenario, a singular data type called medical records was assumed to grant simultaneous access to all users across roles.

Table 2. User roles and their operational permissions in the scenario.

User Roles	Operational Permissions
Nurse	Read, Write
Doctor	Read, Write
Admin	Read, Write, and Delete
Social Worker	Read
Police Officer	Read

demonstrates the data type permissions corresponding to different user roles.

4.3. Risk-Based Access Control Implementation

The risk-based model serves as a bridge between the precise ABAC model and the changing risk-awareness demands of healthcare systems. It is integrated into the proposed model as a supporting element, thereby empowering the system to collect contextual and risk factors in real time to enable access control decisions to be generated dynamically [36]. By assessing and responding to risks in such a way, the healthcare system becomes more resilient against potential threats. The real-time collection and analysis of contextual information empower the healthcare system to make well-informed access decisions to adapt swiftly to changing circumstances. The development of the risk engine to quantify the security risk associated with each access request will significantly enhance the proposed approach’s overall adaptability and responsiveness. This heightened flexibility allows the healthcare system to adjust access permissions based on the evolving risk landscape, ensuring the secure handling of sensitive data in various scenarios.

The proposed risk engine collects contextual and risk information according to four risk categories to generate quantitative risk values, which include the following.

1.

Resource Sensitivity Risk: This risk is determined by comparing user role and resource sensitivity to detect suspicious behavior; for example, it is unusual for a nurse to be granted access to restricted resources.

2.

Contextual Risk: This risk is determined based on whether the user is on duty, accessing resources in their registered office, or accessing resources elsewhere with a similar office type (e.g., office, reception).

3.

User History Risk: This risk is determined based on the user’s past behavior; for example, it is uncommon to grant access to a user who has performed high-risk operations a few times.

4.

Operational Risk: This risk is determined based on the user’s operation type.

To quantify the relevant risk attributes from the above categories, a sub-risk score is calculated for each category. Using predefined weights for each category, the following formula is employed to obtain the final risk result:

Final Risk = (Resource Sensitivity Risk * 0.4 [Proportion]) + (Contextual Risk * 0.4 [Proportion]) + (Operational Risk * 0.2 [Proportion]) + (User History Risk)

The determination of proportions within the formula is predicated upon a comprehensive understanding of each category’s systemic contribution. The user history risk explains that a user’s engagement with data under secure conditions and a bad history will still lead to caution and not full trust in that user while accessing systems resources. The next section presents risk values assigned to each risk category based on this formula.

4.3.1. Resource Sensitivity Risk

As clarified earlier, user identities solely govern the permissible operations and data types accessible to them. To effectively manage resource sensitivity and enhance system flexibility, access-level attributes will be assigned to the system’s users to allow for the proper control of sensitive resources they can access.

Table 3. Resource sensitivity category and associated risk score.

User Role	Resource Sensitivity	Risk Score
Nurse	Confidential	0.4
Nurse	Restricted	0.7
Doctor	Confidential	0.2
Doctor	Restricted	0.7
Social Worker	Confidential	0.6
Social Worker	Restricted	0.8
Police Officer	Confidential	0.6
Police Officer	Restricted	0.6

shows the risk scores allocated when comparing user roles and resource sensitivities considering various roles in the MC children’s hospital scenario. Since EPR medical records are highly sensitive, the resource sensitivity was classified as either confidential or restricted.

Nurses and doctors commonly receive an advanced access level to access confidential data. When nurses attempt to access confidential data, their risk score is set to 0.4. This measure makes it more challenging for nurses to write data (as nurses also can perform write operations), necessitating lower or no risk from other categories. However, when accessing restricted data, both nurses and doctors are assigned a risk score of 0.7, as it is normal for them to obtain such access levels. Similarly, to access restricted data, they must possess significantly low or no risk from other categories. Social workers should not have any access to confidential and restricted data. However, in some extreme cases where a social worker is granted access to such data, they must schedule an appointment specifying when and where they would access the data (otherwise, the PIP would ot be able to extract their working hours and assigned office as they are not internal users of the system). By doing so, their overall risk score will be low, allowing them limited access to confidential and restricted data.

Police officers occupy a distinct role in the MC Children’s Hospital environment, where they may occasionally require access to highly sensitive medical records as part of legal or investigative procedures. While Table 3 assigns a uniform risk score of 0.6 to both confidential and restricted resource sensitivities for police officers, this numerical equivalence does not imply equal operational access in practice. In reality, access to restricted data by police officers is subject to stricter procedural controls than access to confidential data. For instance, officers must submit an access request specifying the purpose, timing, and location of the access in advance. This ensures that access to restricted data is granted only when absolutely necessary and under clearly defined conditions. These operational safeguards, although not fully reflected in the quantitative score, serve to minimize unauthorized access and maintain patient privacy. The enforcement of such conditional access mirrors the protocol applied to social workers, highlighting a consistent access governance model for external or auxiliary roles.

4.3.2. Contextual Risk

In dynamic Risk-Based Access Control models, contextual and real-time attributes play a critical role in evaluating access decisions. Among these attributes, time and location were leveraged to assess contextual risk at the time of the access request. The time attribute corresponds to the predefined duty schedule of hospital personnel, such as doctors and nurses, where access requests made during an individual’s assigned shift are associated with a lower contextual risk. Conversely, requests made outside of scheduled hours are flagged as higher risk. Similarly, the location attribute evaluates whether the access request originates from within the hospital premises. Requests from inside the hospital are considered low-risk, whereas those from external locations trigger a higher risk score. This contextual evaluation allows the system to dynamically adapt access decisions based on situational awareness and potential threat indicators. The values of the same scenario proposed in [12] were utilized, as shown in

Table 4. Contextual factors and associated risk score [12,37].

Role	On Duty (Time)	Location (In Hospital)	User Context Risk	Risk Score
	Yes	Yes	Low	0.2
Doctor	No	Yes	Moderate	0.4
	No	No	High	0.7
	Yes	Yes	Low	0.2
Nurse	No	Yes	Moderate	0.4
	No	No	High	0.7
	Yes	Yes	Low	0.2
Social Worker	No	Yes	Moderate	0.4
	No	No	High	0.7
	Yes	Yes	Low	0.2
Policeman	No	Yes	Moderate	0.4
	No	No	High	0.7

.

4.3.3. User History Risk

In this scenario, all actors including doctors, nurses, social workers, and law enforcement personnel are formally employed by the hospital and are therefore considered trusted users. As a result, their historical risk profiles are assumed to be low based on institutional trust. Accordingly, the initial risk history value for these users is set to 0.2, reflecting a baseline level of trust derived from their organizational affiliation and absence of prior access anomalies.

4.3.4. Operational Risk

To define the value of the operational risk, which mainly depends on the resource sensitivity, Sharma et al.’s [37] formula was utilized. This formula was used to estimate the risk score of action severity in terms of various actions, risk probability, and cost regarding data availability, integrity, and confidentiality [21]. The formula is represented as

$$Risk=\left(C\times P\right)+\left(I\times P\right)+\left(A\times P\right)$$

where C, I, and A represent confidentiality, integrity, and availability, respectively, and P represents the probability. In addition, Sharma et al. [37] have suggested some actions and corresponding values of the CIA. Therefore, values of action severity of the proposed model are estimated using

Table 5. Risk values associated with action and data sensitivity [12,37].

Action	Sensitivity	C	I	A
Create	Sensitive/Not-Sensitive	0	1	1
View	Sensitive	1	0	0
View	Not-Sensitive	0	0	1
Modify	Sensitive/Not-Sensitive	0	1	1
Delete	Sensitive/Not-Sensitive	0	1	1

.

4.3.5. Risk Estimation

The final risk value associated with each access request is calculated based on the values of resource sensitivity risk, contextual risk, user risk history and operational risk using Equation/Formula (1). The final calculated risk value is then categorized into a specific risk level from the five levels, Negligible, Low, Medium, High and Extreme, as shown in

Table 6. Risk category with the corresponding score.

Output Risk Value	Risk Category
0.0–0.1	Negligible
0.1–0.3	Low
0.3–0.5	Medium
0.5–0.7	High
>=0.7	Extreme

.

4.3.6. Legal Compliance and GDPR Alignment

In alignment with privacy and security regulations such as the General Data Protection Regulation (GDPR) and the UK Data Protection Act (2018), the proposed model integrates both technical and organizational safeguards to ensure lawful and ethical handling of sensitive medical data. From a technical perspective, the following safeguards are embedded into the proposed risk-based system:

• Data Minimization: Access decisions are based on the principle of least privilege, ensuring that only the minimum necessary data required to perform a task is accessible to the user.
• Context-Aware Restrictions: Real-time evaluation of user context (time, location, and duty status) enforces restrictions on access to sensitive resources, reducing the risk of unauthorized or accidental disclosures, as mandated by GDPR Articles 5(1)(c) and 32.
• Risk Quantification and Categorization: The calculated final risk score is categorized into five risk levels (Negligible to Extreme) to guide automated or administrative interventions, including blocking, flagging, or logging of high-risk access attempts as part of incident response protocols.
• Auditability and Accountability: All access decisions and calculated risk scores are logged for audit purposes, facilitating accountability and post-incident investigation, satisfying GDPR Article 30’s requirements for records of processing activities.

• From an organizational perspective, the proposed model assumes the following.

• Policy Enforcement: Healthcare institutions must define clear policies outlining which roles (e.g., doctors, nurses, police officers) are authorized to access specific data categories under defined contextual conditions.
• Training and Awareness: Users are trained regularly on appropriate data handling, the risks associated with unauthorized access, and GDPR requirements to promote a security-conscious culture.
• Incident Handling Procedures: High or extreme risk levels automatically trigger incident response measures, such as real-time alerts to security officers or automated access denials, ensuring prompt organizational reaction to potential data breaches.
• Data Protection Impact Assessments (DPIAs): The risk engine’s outputs can feed into DPIAs required under GDPR Article 35 for processing operations that are likely to result in high risk to individuals’ rights and freedoms.

These safeguards ensure that the system’s dynamic risk evaluation mechanism not only enhances security but also meets GDPR and similar legal obligations concerning personal health data protection.

4.4. Attribute-Based Access Control Implementation

The ABAC model constitutes a pivotal element within the integrated system of the proposed risk-aware RBAC and ABAC model to provide a critical role in governing access decisions. It collects attributes related to users, resources, and environments, along with the evaluated risk score from the risk engine. These attributes are then incorporated into the access control process, allowing for more granular and adaptable access control decisions.

The ABAC model is implemented based on the eXtensible Access Control Markup Language (XACML) architecture, incorporating three key components: Policy Enforcement Point (PEP), Policy Decision Point (PDP), and Policy Information Point (PIP). XACML is an XML-based access control language standardized by the OASIS Alliance Technical Committee [27,38]. Its architecture outlines a framework for deploying necessary software modules within the infrastructure to allow effective policy enforcement. Figure 4 shows the interaction in the designed architecture through the ABAC sequence diagram. Using XACML allows for flexibility and enables highly fine-grained control and context awareness in the proposed model. This reflects the healthcare system, which can handle complex environments and adapt to changing conditions in healthcare domains, providing enhanced protection of sensitive resources through a dynamic access control approach.

4.4.1. Policy Enforcement Point (PEP)

The PEP acts as the entry point of the entire evaluation process to intercept the incoming request and forward it to the PDP [38]. The system is enhanced by adding extra logic to the AOP layer from the RBAC to replace the PEP, as they both serve a common purpose. Once the user successfully completes the identity validation process, the AOP will forward the request to the PDP to await a final decision instead of immediately granting access.

To implement the PEP, we integrate additional logic into the AOP layer from the RBAC to substitute the PEP to intercept and forward user requests to the PDP. This was achieved by invoking the PDP to forward the request and await a conclusive decision (true or false).

4.4.2. Policy Information Point (PIP)

The PIP supports the ABAC evaluation process by conveying attributes to crucial components like the PDP and risk engine. It collects contextual and risk factors according to the four categories, which include environment, resource, user and risk attributes, to support the PDP and the risk engine. The PIP was implemented based on a set of JPA repositories from various databases into one class. This allows the seamless retrieval of attributes required for access control decisions.

4.4.3. Policy Decision Point (PDP)

ABAC is central to our integrated risk-aware RBAC and ABAC model, with the PDP as the core component. Upon receiving a request from the PEP, the PDP gathers relevant attributes from the PIP and calculates a risk score. The PDP then approves or denies the request based on these inputs. Selecting an appropriate PDP engine was crucial, and after extensive research, we narrowed the options to authzforce-ce-core-pdp-engine and wso2-balana [39]. We chose authzforce-ce-core-pdp-engine for its accessibility and high customizability, making it the ideal solution for implementing custom access control policies [39,40].

The “authzforce-ce-core-pdp-engine” is a robust and stable PDP engine known for its efficient policy evaluation capabilities. Compliant with the XACML standard, it ensures compatibility with XACML-based applications and systems [41]. The engine reads the fixed PDP.xml to locate all policy sets and allows users to set a fixed root policy set, aiding in the customization of XACML access control policies. This approach enhances clarity and is ideal for applications with increasing access requests, efficiently handling complex access control scenarios.

4.4.4. XACML Policies

Once the PDP engine was implemented, the last thing needed was to define our XACML policies. XACML articulates access control policies, defining permissible actions and their conditions (who can do what and when). Access policies were created considering the roles of the main actors in the MC Children’s Hospital to specify the privileges each actor can perform at a certain time considering the level of the risk.

The access policies were developed and implemented to ensure the appropriate handling and protection of medical records in the MC Children’s Hospital scenario. These access policies are designed to strike a balance between maintaining data security, ensuring appropriate access to medical records based on professional roles and responsibilities, and safeguarding patient privacy. They aim to support the delivery of quality healthcare while adhering to legal and ethical standards. The complete access policies for each role based on the operation type and risk level are shown in

Table 7. Access policies are defined for each role based on the operation type.

Role	Operation	Policy Rules
Admin	Delete	Admin can delete any medical records if the risk is negligible.
	Write	Admin can write any medical records if the risk is negligible, low or medium.
	Read	Admin can read any medical records if the risk is negligible, low or medium.
Doctor	Delete	Doctors cannot delete medical records.
	Write	Doctors with normal, advanced, or premium privileges can write internal medical records if the risk level is negligible.
	Write	Doctors with advanced, or premium privileges can write confidential medical records if the risk level is negligible.
	Read	Doctors with normal, advanced, or premium privileges can read internal medical records if the risk level is negligible, low or medium.
	Read	Doctors with advanced, or premium privileges can read confidential medical records if the risk level is negligible, low or medium.
	Read	Doctors with premium privileges can read restricted medical records if the risk level is negligible or low.
Nurse	Delete	Nurses cannot delete medical records.
	Write	Nurses with normal, advanced, or premium privileges can write internal medical records if the risk level is negligible.
	Read	Nurses with normal, advanced, or premium privileges can read internal medical records if the risk level is negligible, low or medium.
	Read	Nurses with advanced, or premium privileges can read confidential medical records if the risk level is negligible, low or medium.
	Read	Nurses with premium privileges can read restricted medical records if the risk level is negligible or low.
Social Worker	Delete	Social workers cannot delete medical records.
	Write	Social workers cannot write medical records.
	Read	Social workers with normal, advanced, or premium privileges can read internal medical records if the risk level is negligible, low or medium.
Police Officer	Delete	Police officers cannot delete medical records.
	Write	Policeofficers cannot write medical records.
	Read	Police officers with normal, advanced, or premium privileges can read internal medical records if the risk level is negligible, low or medium.
	Read	Police officers with advanced, or premium privileges can read confidential medical records if the risk level is negligible, low or medium.
	Read	Police officers with premium privileges can read restricted medical records if the risk level is negligible or low.

.

For admins’ access, they are granted the ability to delete medical records if the risk is negligible. This access allows them to remove irrelevant or outdated information to maintain data integrity and minimize clutter in the system. Admins can also write any medical records if the risk is negligible, low, or medium. This access enables them to update patient records or add necessary information in cases where the risk level is within acceptable limits. Similarly, admins can read any medical records if the risk is negligible, low, or medium. This access allows them to review and access patient information for administrative purposes, such as verifying data accuracy or fulfilling legal requirements.

For doctors’ access, they are not granted the ability to delete medical records. This restriction ensures data integrity and prevents the accidental or malicious deletion of patient information. Doctors with normal, advanced, or premium privileges can write internal medical records if the risk level is negligible. This access enables doctors to document their observations, diagnoses, and treatment plans for patients. In the same way, doctors with normal, advanced, or premium privileges can read internal medical records if the risk level is negligible, low, or medium. This access allows doctors to review patient histories, lab results, and other relevant information to provide appropriate care and make informed medical decisions. Also, doctors with advanced or premium privileges can access confidential and restricted medical records if the risk level is negligible, low, or medium. This access is granted to authorized personnel who require access to sensitive information for specialized treatments or research purposes.

As far as nurses’ access, they are not granted the ability to delete medical records. This restriction ensures data integrity and prevents accidental or unauthorized removal of patient information. Also, nurses with normal, advanced, or premium privileges can write internal medical records if the risk level is negligible. This access allows nurses to document patient care activities, observations, and medication administration. Similarly, nurses with normal, advanced, or premium privileges can read internal medical records if the risk level is negligible, low, or medium. This access enables nurses to access patient information for providing appropriate care, monitoring vital signs, and administering medications.

As for social workers’ access, they cannot delete medical records. This restriction ensures data integrity and prevents the unauthorized alteration or removal of patient information. They also cannot write medical records. This limitation is in place because social workers primarily focus on providing support and assistance to patients and their families, rather than documenting medical information. Also, social workers with normal, advanced, or premium privileges can read internal medical records if the risk level is negligible, low, or medium. This access allows social workers to access relevant patient information to assess the situation, provide appropriate support, and help in cases involving abuse or neglect.

As for police officers’ access, they cannot delete medical records. This restriction ensures data integrity and prevents unauthorized alteration or removal of patient information. They also cannot write medical records. This limitation is in place as their role primarily involves investigation and law enforcement rather than medical documentation. Also, police officers with normal, advanced, or premium privileges can read internal medical records if the risk level is negligible, low, or medium. This access allows them to access patient information for investigation purposes, such as gathering evidence or understanding the medical context related to a case of suspected child abuse.

5. Results and Analysis

It is difficult for an access control system to present the results directly in the form of data, as there are no real-world datasets available that provide the baseline of granting or denying access for various roles based on their access requests. Hence, a series of experiments that simulate real risk scenarios that may occur within the MC Children’s Hospital will be conducted to evaluate the effectiveness of the proposed risk-aware RBAC and ABAC model. The following procedure was followed to carry out the experiments:

• Define potential identities of attackers in the database, both internal and external.
• Initialize the simulated risk scenario in the IntelliJ IDEA environment.
• Manipulate independent variables (environmental factors, operational factors, background factors, etc.).
• Monitor access control decisions and record results in real time.
• Calculate decision accuracy, precision, and recall based on the obtained data.
• Repeat the process for multiple iterations to ensure reliable results.

5.1. Experiment Setting

Experiments are set to take place in a controlled (closed) environment to mitigate external impacts. The experiments were conducted using IntelliJ IDEA [41], a widely used integrated development environment. IntelliJ IDEA version 2022.3.1 was applied, and common system environments (Windows 10, etc.) will be configured to maintain consistency between experimental runs. The software and framework versions that were used are as follows:

• Java JDK 14
• authzforce-ce-core-pdp-engine 20.2.0
• spring-boot-starter-parent 2.2.13.RELEASE
• MySQL 8.0.28

5.2. Evaluation Metrics

Determining the effectiveness of the proposed risk-aware RBAC and ABAC model is significant to verify the applicability of the proposed model in real-world scenarios in the healthcare environment. Three evaluation metrics, accuracy, precision, and recall, which are mainly based on True Positive (TP), True Negative (TN), False Positive (FP), and False Negative (FN), are used to evaluate the effectiveness of the proposed model [42,43].

Accuracy measures the overall correctness of the proposed model decisions. It is calculated as the ratio of the number of correctly predicted access decisions (both positive and negative) to the total number of access decisions made. In other words, it represents the average number of successful access decisions that are matched with the access policies using the following formula:

$$Accuracy=(TP+TN)/\left(TotalAccessDecisions\right)$$

Precision measures the accuracy of positive predictions made by the proposed model. It focuses on the proportion of correctly predicted positive access decisions out of all the access decisions that the model predicted as positive. Precision is particularly relevant when the cost of false positives (incorrectly granting access) is high. Precision is mathematically estimated using this formula:

$$Precision=TP/(TP+FP)$$

Recall measures the ability of the proposed model to correctly identify all positive instances (access decisions) out of all actual positive instances. It focuses on the proportion of correctly predicted positive access decisions out of all the actual positive access decisions. Recall is especially important when the cost of false negatives (incorrectly denying access) is high. Recall is mathematically estimated using this formula:

$$Recall=TP/(TP+FN)$$

5.3. Experimental Results

A total of 43 simulations were performed across diverse scenarios. The simulations were selected based on the matching results obtained from 27 designed users, in conjunction with four dynamic attributes: (1) current time, (2) user location, (3) user action, and (4) accessed resource.

The user data that are used to build simulations consists of various profiles within a healthcare system, each identified by a unique User ID and assigned specific roles, access levels, working periods, risky operations, registered offices, and office types. For User IDs 1 to 9, the roles include doctors with normal, advanced, or premium access levels. These users work typically from 9:00 to 18:00, and they have no risky operations recorded for most cases, though a few have histories of three or five risky operations. They are registered in Office 1 and work in standard office environments. User IDs 10 to 18 are nurses with normal, advanced, or premium access levels. Their working hours are from 10:00 to 19:00, with similar patterns of risky operations as the doctors. They are assigned to Reception 1 and work in reception areas.

User IDs 19 to 21 are admins with premium access, working all day in Office 2, with similar patterns of risky operations as the doctors and nurses. This profile is unique as it combines high-level access with an office-type setting. The inclusion of multiple administrator users in this simulation reflects realistic operational practices in large healthcare institutions, where administrative roles are often distributed across shifts, departments, or responsibility areas. From a Risk-Based Access Control perspective, modeling multiple admins enables a thorough evaluation of the system’s ability to adapt to varying access requests from users with similar privileges but different contextual conditions. This enhances the robustness and generalizability of the model under diverse real-world scenarios. User IDs 22 to 27 represent external roles such as police officers and social workers. Although the number of these users may seem relatively high compared to nurses and doctors, this was intentional to enable the simulation of a wide range of contextual scenarios and exception-handling cases involving auxiliary roles. These users help evaluate the system’s response to diverse and potentially high-risk access patterns, ensuring that the model effectively manages users with conditional access requirements and varied operational contexts.

Based on this data,

Table 8. Scenario details with access decisions and a confusion matrix.

Scenario No#	User ID	Current Time	Current Location	Current Action	Resource Sensitivity	Access Decision	Confusion Matrix
1	1	11:00	Office 1	Read	Internal	Permit	TP
2	1	19:00	Reception 2	Read	Internal	Permit	TP
3	1	10:00	Office 1	Write	Confidential	Deny	TN
4	2	10:00	Reception 2	Read	Internal	Permit	TP
5	2	10:00	Office 1	Write	Internal	Permit	TP
6	3	10:00	Office 1	Read	Internal	Deny	TN
7	4	12:00	Office 2	Read	Confidential	Permit	TP
8	4	12:00	Office 1	Read	Restricted	Deny	TN
9	5	21:00	Office 2	Read	Confidential	Permit	TP
10	5	11:00	Office 1	Write	Confidential	Deny	TN
11	7	11:00	Office 1	Write	Restricted	Permit	TP
12	7	11:00	Reception 1	Read	Restricted	Permit	TP
13	8	15:00	Office 1	Write	Internal	Deny	TN
14	8	15:00	Reception 1	Read	Confidential	Permit	TP
15	9	15:00	Office 1	Read	Restricted	Deny	TN
16	10	10:00	Reception 1	Read	Internal	Permit	TP
17	10	19:00	Office 2	Read	Internal	Permit	TP
18	10	10:00	Reception 1	Write	Confidential	Deny	TN
19	11	10:00	Office 2	Read	Internal	Permit	TP
20	11	10:00	Reception 1	Write	Internal	Deny	FN
21	11	10:00	Reception 2	Write	Internal	Deny	TN
22	12	10:00	Reception 1	Read	Internal	Deny	TN
23	13	12:00	Reception 2	Read	Confidential	Permit	TP
24	13	12:00	Reception 1	Read	Internal	Permit	TP
25	14	21:00	Reception 2	Read	Confidential	Deny	TN
26	14	11:00	Reception 1	Write	Confidential	Deny	TN
27	15	10:00	Reception 1	Read	Confidential	Deny	TN
28	16	11:00	Reception 1	Write	Restricted	Permit	TP
29	16	11:00	Office 1	Read	Restricted	Permit	TP
30	17	15:00	Reception 1	Write	Internal	Deny	TN
31	17	15:00	Office 2	Read	Confidential	Deny	FN
32	18	15:00	Reception 1	Read	Restricted	Deny	TN
33	19	11:00	Office 2	Delete	Restricted	Permit	TP
34	19	11:00	Office 1	Delete	Restricted	Deny	FN
35	20	11:00	Office 2	Delete	Restricted	Deny	TN
36	20	11:00	Reception 2	Read	Restricted	Permit	TP
37	21	11:00	Office 2	Delete	Restricted	Deny	TN
38	22	10:00	Reception 3	Read	Internal	Permit	FP
39	23	10:00	Reception 2	Read	Confidential	Permit	TP
40	24	10:00	Reception 2	Read	Restricted	Deny	TN
41	25	10:00	Reception 2	Read	Internal	Permit	FP
42	26	10:00	Reception 3	Read	Internal	Permit	TP
43	27	10:00	Reception 3	Read	Internal	Deny	TN

displays all simulations conducted to verify the effectiveness of the implemented model, incorporating previously mentioned designed users’ data with dynamic attributes and corresponding detailed descriptions. Each final access decision is color-coded. Red signifies FP, orange signifies FN, green denotes TP, and blue denotes TN outcomes.

The scenarios presented in Table 8 simulate various real-world situations, considering factors like user role, access level, time of access, location, action, and resource sensitivity. The model’s decision for each scenario is then compared to the expected outcome, as reflected in the confusion matrix. The scenarios presented showcase the model’s ability to dynamically assess user access requests based on a combination of RBAC, ABAC, and risk-aware elements. The confusion matrix provides a quantitative measure of the model’s accuracy in granting or denying access to highlight its strengths and potential areas for improvement.

To compute the TP, FP, FN, and TN values, we utilized the defined XACML access control policies defined in Table 7 as the ground truth against which the decisions of the PDP were evaluated. Each access request—generated for different roles (admin, doctor, nurse, social worker, police officer) under various risk levels and operation types (read, write, delete)—was checked for compliance with the corresponding access policy. A request correctly permitted by the PDP in accordance with the policy was counted as a TP, whereas a request wrongly permitted when it should have been denied was considered an FP. Similarly, a request correctly denied (matching a policy restriction) was classified as a TN, while an incorrectly denied request that should have been allowed under the policy was considered an FN. For example, if a doctor with ’normal’ privilege requested to read internal medical records at a negligible risk level and the PDP permitted this action (which aligns with the policy), this counted as a TP. Conversely, if the PDP allowed a nurse to delete records—an action explicitly forbidden by policy—this was marked as an FP. Every operation, role, and risk-level combination generated a decision that contributed to the final TP, FP, FN, or TN tally, providing an accurate assessment of the PDP’s policy enforcement effectiveness.

The performance metrics were calculated based on the obtained values of TP, FP, FN, and TN derived from the policy decision evaluations, as shown in

Table 9. Performance metrics of the proposed model.

Metric	True Positive (TP)	False Positive (FP)	False Negative (FN)	True Negative (TN)
Value	20	2	3	18
Performance Metrics
Accuracy	88.37%
Precision	90.90%
Recall	86.96%

. The results demonstrate the robustness of the proposed integrated system with 88.37% accuracy, 90.90% precision, and 86.96% recall. These quantitative figures directly validate the overall viability and practicality of the proposed integrated system. The results demonstrate that the proposed model demonstrates a high level of accuracy, precision, and recall. The high accuracy demonstrates that the proposed model generally makes correct predictions about whether access should be granted or denied. The high value of the precision shows that the model is good at avoiding granting access when it should not. This is significant for security, as it helps prevent unauthorized access to sensitive information. The high value of the recall demonstrates that the model is good at identifying all scenarios where access should be granted. This is significant for usability, as it helps ensure that authorized users can access the resources they need.

The high performance metrics demonstrate the effectiveness of the proposed integrated RBAC and ABAC risk-aware model. This approach combines the strengths of traditional access control models with risk-aware elements. The proposed model can accurately deny access to unauthorized users and minimize false positives, contributing to a more secure healthcare system. The proposed model also can dynamically adjust access control decisions based on user behavior and context providing greater flexibility and adaptability to evolving security needs. The model can also accurately identify all valid access requests to help ensure that authorized users can access the resources they need, improving system usability.

6. Discussion and Evaluation

Traditional access control models often rely on static and predefined roles, making them inflexible and unable to adapt to the dynamic nature of healthcare environments. These models struggle to keep pace with evolving threats and the complexity of modern healthcare operations. This inflexibility can lead to vulnerabilities that expose sensitive patient information to unauthorized access and potential breaches. To address these limitations, this paper proposes a novel integrated access control model that combines the strengths of RBAC, ABAC, and RiBAC. This model leverages the fine-grained control of RBAC to define user roles and permissions, the context-aware policy definition capabilities of ABAC, and the dynamic risk assessment features of RiBAC. The integration of these three access control mechanisms creates a more flexible and adaptable system that can better mitigate emerging threats and ensure the security of sensitive medical information. The paper presents a detailed design and implementation of this model, showcasing its potential to enhance the security of healthcare systems.

The results demonstrate the feasibility and effectiveness of the proposed model. Through a series of 43 experiments that simulate various scenarios of access control operations in a healthcare system, the model demonstrates significant improvement in the accuracy, precision, and recall of access control decisions compared to traditional models. The proposed integrated approach demonstrated more responsiveness to dynamic changes in risk profiles and user attributes, providing a more robust and adaptable security solution for healthcare systems. The model’s ability to dynamically assess risk and adjust access permissions based on contextual factors significantly enhances its ability to mitigate threats and protect sensitive medical data. The proposed model provides a valuable framework for future research and development in access control for healthcare systems.

The proposed model was evaluated against state-of-the-art studies and relevant models from the literature as shown in

Table 10. Comparison of criteria across different models.

Criteria	Aftab et al. [7]	Afshar et al. [28]	Atlam et al. [6]	Atlam et al. [12]	Ashutosh et al. [39]	Alharbe et al. [43]	Proposed Model
Fine-grained access control	✓	✓	✓	✓	✓	✓	✓
Layered security	✓	X	X	X	X	X	✓
Contextual awareness	✓	✓	✓	✓	✓	✓	✓
Dynamic risk assessment	X	X	X	✓	X	✓	✓
Simplified administration	X	X	X	X	X	X	✓
Standardization	X	✓	✓	X	✓	✓	✓
Usability	X	X	X	X	X	X	✓
Scalability	✓	X	X	X	X	X	✓
Merge of RBAC, ABAC and RiBAC	X	X	X	X	X	X	✓

. The proposed model provides a layered security approach that incorporates a dedicated layer for security, which does not exist in most of the other models from the literature. This layered approach allows for more granular control and better isolation of sensitive data to enhance overall security. The proposed model includes dynamic risk assessment, a feature that is only partially addressed by Atlam et al. [6] and Alharbe et al. [43]. This dynamic approach allows for more context-aware access decisions, considering factors like time, location, and frequency of requests, leading to more robust security. In addition, the proposed model emphasizes simplified administration, a feature missing in all other models. This likely means it utilizes a user-friendly interface or tools for policy management, making it easier to configure and maintain the access control system. The proposed model also leverages standardization, a feature shared with most of other models from the literature. This means it utilizes a widely recognized standard (XACML), allowing for greater interoperability and easier integration with existing systems. The proposed model prioritizes usability, a feature that does not exist in the other models from the literature. This suggests it focuses on user-friendly interfaces and tools, making it easier for users to interact with the access control system. The proposed model also emphasizes scalability, a feature shared with only Aftab et al. [7]. This indicates it is designed to handle large-scale deployments and manage data from a large number of users, making it suitable for various applications. Finally, this paper provides a novel approach that combines RBAC, ABAC, and a risk engine to enhance security in healthcare systems, which was not explored or developed previously.

The proposed model stands out by incorporating features that address key challenges in traditional access control models in the healthcare domain, including layered security, dynamic risk assessment, simplified administration, standardization, usability, and scalability. This makes it a more comprehensive and robust access control solution compared to the other models discussed in the literature.

Table 11. Contribution of the proposed model regarding each comparison criteria.

Criteria	Contribution of the Proposed Model
Fine-grained Access control	The combination of RBAC and ABAC enables fine-grained access control based on user roles and attributes. The risk engine also can be customized to account for specific healthcare system risks and vulnerabilities.
Layered security	The proposed model integrates RBAC, ABAC, and risk assessment providing a layered security approach, making it more difficult for attackers to bypass security measures. RBAC acts as the foundational layer, authenticating user identities and filtering unauthorized requests. Risk Engine collects contextual and risk factors in real-time, dynamically adjusting access decisions based on the assessed risk, while ABAC serves as the core, evaluating policies based on attributes and risk scores to determine authorization.
Contextual awareness	ABAC and the risk engine of the proposed model enable the system to consider context-sensitive information, such as user location, device type, and time of access, to make more informed access control decisions. The risk engine is responsible for collecting contextual information, such as user location, time of access, and user history. This information is used to dynamically adjust access decisions, making the proposed model context-aware.
Dynamic risk assessment	The risk engine continuously evaluates the risk associated with each access request, adapting access control policies based on real-time threat intelligence and user behavior. This dynamic risk assessment allows for real-time adjustments to access permissions.
Simplified administration	The proposed model utilizes AOP for RBAC implementation, allowing for modularizing access control logic, separating it from the core application code, leading to improved maintainability and extensibility.
Standardization	The proposed model leverages XACML for policy definition and evaluation, a widely adopted standard for access control, promoting interoperability and standardization, and allowing for easier integration with existing systems.
Usability	The proposed model leverages RBAC for user role management, making it easier for administrators to assign permissions. The model can be implemented with a user-friendly interface, simplifying the process of configuring policies and managing access control.
Scalability	The proposed model’s layered structure and use of AOP for RBAC implementation contribute to its scalability. The modular design allows for easy expansion and adaptation to accommodate growing user bases and complex healthcare environments.
Integration of RBAC, ABAC and RiBAC	The proposed model integrates RBAC for role-based categorization, ABAC for fine-grained control based on user attributes and environmental factors, and RiBAC for dynamic risk assessment. The model dynamically adjusts access permissions based on risk values, ensuring accurate and adaptable access control decisions.

summarizes the contribution of the proposed model against the criteria discussed earlier and compares it against studies from the literature.

7. Conclusions

This paper addresses the critical challenge of enhancing healthcare security in the face of evolving threats and vulnerabilities. Traditional access control models struggle to adapt to the dynamic and complex nature of modern healthcare environments. To overcome these limitations, this paper proposes a novel risk-aware access control model that integrates the RBAC, ABAC, and RiBAC models. This integrated approach leverages the strengths of each model, providing a more comprehensive and flexible solution for managing access to sensitive healthcare data. The proposed model dynamically adjusts access permissions based on real-time risk assessments, ensuring accurate and adaptable control decisions. Through a series of 43 experiments simulating various access control scenarios in a healthcare context, the experimental results demonstrate that the proposed model effectively grants access to authorized users while denying access to unauthorized ones, achieving high recall and precision metrics 86.96% and 90.90%, respectively. This enhanced security is achieved by dynamically adapting access permissions based on risk scores, which are calculated by considering various factors such as user attributes, environmental conditions, and past behavior. The proposed model’s ability to adapt to changing circumstances and mitigate evolving threats makes it particularly valuable in healthcare settings, where the sensitivity of patient data requires a robust and adaptable security solution. Compared to existing studies from the literature, the proposed model offers a more robust and adaptable approach to managing access in healthcare systems, addressing the limitations of traditional access control models. However, the research also acknowledges limitations, such as the need for more extensive case studies to further validate the model’s effectiveness in diverse real-world scenarios. For future work, we will focus on refining the risk assessment mechanism by incorporating more sophisticated machine learning algorithms and exploring the integration of other security technologies, such as blockchain and federated learning, to further enhance the model’s resilience and adaptability. Additionally, we will investigate the model’s scalability and performance in large-scale healthcare systems and explore its applicability in diverse real-world scenarios.