Enhancing healthcare service efficiency and compliance: A dynamic permission access control method for hospital environments based on I_ABRAC model

Abstract

Background and Objective

Hospital access control systems face unique challenges in environments with high staff mobility and overlapping roles. This study aims to develop and validate an Improved Attribute-Based Role Access Control (I_ABRAC) model to address role explosion, computational inefficiency, and compliance issues in healthcare settings.

Methods

We proposed an I_ABRAC model incorporating three mechanisms: (1) an approval-permission dynamic coupling mechanism, (2) a rule number-driven incremental update algorithm, and (3) a permission-rule traceability framework. The model was validated using real-world de-identified operational data from a large tertiary teaching hospital in China, encompassing 60 access control rules, approximately 20,000 personnel, and over 2,000 access points. Experiments were conducted across 16 test scenarios under 24 configurations (8 personnel scales × 3 rule scales).

Results

The I_ABRAC model achieved a 68% reduction in required system roles compared to traditional models (from 176 to 56 roles) while demonstrating correct functional permission assignment across all 16 test scenarios. The optimized algorithm demonstrated an 83.3% improvement in processing efficiency (from 54.96±1.89s to 9.96±2.78s; p<0.001), with performance gains ranging from 81.9% to 83.9% across all 24 configurations (8 personnel scales * 3 rule scales, all p<0.001), confirming its scalability from departmental to hospital-wide deployments.

Conclusions

The I_ABRAC framework effectively resolves core security and operational bottlenecks in hospital access control, provides technical mechanisms to support compliance with medical regulations, and supporting scalable applications such as IoT-based device access and multi-hospital systems.

1 Introduction

Hospital access control systems play a crucial role in safeguarding clinical safety and patient privacy.^1,2 They directly affect three critical aspects of healthcare delivery: (1) clinical workflow continuity—ensuring that medical staff can promptly access high-risk diagnostic and treatment areas such as operating rooms, pharmacies, and emergency equipment zones; (2) privacy protection—restricting access to sensitive areas such as endoscopy center changing rooms, psychiatric wards, and medical record storage areas; and (3) regulatory compliance—adhering to requirements for infection control, safety isolation, and security of drugs and equipment.^3–5 The effectiveness of access control systems directly influences the prevention of medical errors, protection of patient privacy, and compliance with medication safety regulations.

A critical operational characteristic that fundamentally distinguishes hospital access control systems from conventional online authorization systems (e.g., hospital HIS, cloud IAM) is the “compute-then-download” mode. Unlike online systems that verify permissions in real-time against a central database, physical access control systems require that all permission changes be fully calculated and verified on backend servers before being batch-synchronized to distributed front-end devices (e.g., door controllers, card readers). Once permission calculation is delayed, medical staff cannot obtain timely access to critical areas, directly impacting clinical decision-making and patient safety. This distinctive offline-synchronization architecture introduces unique performance constraints that are not present in online systems, making efficient batch permission computation a critical requirement rather than merely an optimization.

Currently, most hospital access control systems adopt Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), or Attribute-Based Role Access Control (ABRAC) models, ⁶ which enable role deployment and dynamic authorization based on real-time attributes.^7–12 However, in recent years, with the accelerated collectivization and informatization of medical institutions in China,^13,14 hospital environments have become increasingly characterized by large numbers of personnel, high staff mobility,^13,15–17 diversified roles with overlapping clinical and administrative responsibilities,^18–20 complex functional areas spanning multiple campuses,^21–24 varied opening hours of ward access control points,^25,26 and frequent replacement of employee ID cards. These challenges are not unique to individual hospitals but reflect a nationwide trend in the development of China’s healthcare system. As a National Medical Center and one of the largest tertiary hospitals in China, our hospital—the First Affiliated Hospital, (FAHZU)—exemplifies these national trends with even greater prominence. With approximately 20,000 personnel and over 5,000 access control points across six campuses (Yuhang, Qingchun, Zhijiang, Chengzhan, Daxue Road, and Qiantang), the operational environment of our hospital embodies all the complexities described above, making it an ideal representative setting for studying and validating access control solutions in large-scale medical institutions.

This complexity reveals significant limitations when applying current access control models to large-scale medical environments. RBAC simplifies permission management by associating users with predefined roles, but suffers from “role explosion” in large hospitals. As the number of departments, positions, and functional areas increases, cross-departmental collaboration generates redundant roles—leading to exponential growth in the total number of roles. This results in cumbersome permission configuration, increased administrative costs, and prolonged permission waiting times, ultimately hindering clinical workflow coordination.^27–29 ABAC achieves fine-grained control through multi-dimensional attributes (user identity, time, regional function, device status). However, its complex attribute matching logic leads to high computational latency and numerous configuration errors. For example, during the pandemic, rapid redeployment of personnel and regional functions could not meet the demand for fast permission updates in medical emergencies.^30,31 ABRAC attempts to integrate the advantages of RBAC and ABAC by incorporating roles into attribute constraints, but fails to resolve the conflict between flexibility and computational efficiency. Issues such as redundant permission rules,^32,33 high performance overhead, ³⁴ and prolonged decision-making time ³⁵ lead to errors in permission calculations for overlapping roles (e.g., administrative-clinical dual roles) and delays in permission activation. Delays in updating access permissions can result in passive clinical decision-making, including inability to access critical permissions for emergency equipment, medications, and other essential resources.

Based on the management requirements, personnel structure, and regional functional characteristics of our hospital, there is an urgent need to construct a secure and reliable access control model that satisfies the requirements of fine-grained permission management, accuracy, and efficiency. Leveraging our hospital’s personnel system and door access management system, we developed an Improved Attribute-Based Role Access Control (I_ABRAC) model, which organically integrates dynamic role strategies with approval strategies. This model encompasses the entire process of door access permission management, including dynamic role mapping based on personnel attributes, approval workflows for cross-departmental temporary permissions, incremental update calculation of permission rules, and full traceability of permissions and rules. The involved roles include clinical department staff, administrative personnel, the information technology department, and hospital management.

Our objectives are: (1) to achieve online approval and direct activation of temporary permissions through an approval-permission dynamic coupling mechanism, which enables temporary permissions to take effect directly through online approval workflows without creating new roles, thereby effectively avoiding role explosion; (2) to significantly improve permission calculation efficiency through a rule number-driven incremental update algorithm, ensuring that permissions can be rapidly downloaded to front-end devices in emergency situations; (3) to achieve complete auditability of access decisions through a permission-rule traceability framework, which links each permission to its source rule via an “association rule” field, ensuring that permission management complies with medical regulations regarding privacy and medication security, and providing technical support for post-hoc auditing and responsibility tracing. The I_ABRAC model aims to achieve automated permission assignment, online approval processes, real-time permission updates, and traceable permission management, providing a solid technical foundation for hospital clinical safety and patient privacy protection.

Innovation contributions of I_ABRAC. The contributions can be categorized into security model innovations (Dimensions 1-3) and a system-level optimization (Dimension 4). While I_ABRAC builds upon existing RBAC, ABAC, and workflow approval concepts, its contribution is not a simple combination of existing techniques. The novelty is manifested in four complementary dimensions:

1) Scenario innovation (security model). To our knowledge, no prior study has specifically addressed the unique “compute-then-download” constraint of hospital physical access control, where permissions must be fully calculated on backend servers and batch-synchronized to distributed door controllers before any access can be granted. This mode distinguishes physical access control from online authorization systems (e.g., hospital HIS) and introduces distinct challenges that existing models have not been designed to handle.

2) Problem innovation (security model). This study identifies three critical pain points not jointly solved in prior work: (a) role explosion caused by cross-departmental and temporary roles; (b) computational latency in permission updates that delays clinical workflows; (c) lack of permission-rule traceability for compliance auditing (e.g., HIPAA/GDPR).

3) Combination innovation (security model). I_ABRAC organically integrates three mechanisms: an approval-permission dynamic coupling mechanism to prevent role proliferation, a rule number-driven incremental update algorithm to optimize computational performance, and a permission-rule traceability framework to enable precise auditing. This integration is not a mere juxtaposition of independent components but a systematic design where the approval mechanism feeds into the incremental update algorithm (by directly writing permissions without rule modification), and the traceability framework leverages the association rule field generated during updates.

4) Performance innovation (system-level). The proposed rule number-driven incremental update algorithm reduces the number of traversed rows from approximately (pg₀ * pg₁ * …* pg_k * papp * pd + 2 * p * p’) to (M*p’), a theoretical improvement validated on real-world hospital data (20,000 personnel, 2,000 access points), achieving an 83.3% reduction in permission calculation time (from 54.96±1.89s to 9.96±2.78s, p<0.001). A comprehensive stress test across 8 personnel scales and 3 rule scales (24 configurations) further validated the algorithm’s scalability, with consistent improvements ranging from 81.89% to 83.90% (all p<0.001).

Collectively, these four dimensions establish I_ABRAC as a novel solution tailored to the unique requirements of hospital physical access control, rather than a trivial recombination of existing access control paradigms.

2 Related works

2.1 Application of access control models in medical informatics

Access control models have been widely used in medical informatics to address data security and personnel management issues. RBAC-based models are applied in hospital information systems (HISs) for role-based permission allocation, but their lack of dynamics,^36,37 susceptibility to human intervention errors,^38,39 role explosion,^27–29,40 and lack of fine granularity^36,37 make them unable to adapt to temporary permission adjustments during epidemics. ABAC models are used for fine-grained control of medical data access (e.g., electronic health records (EHRs)),^7,12 but their high policy management costs and performance overhead limit their application in large hospitals.^41,42 ABRAC models integrate roles and attributes for permission control, and are used in medical IoT and cloud service platforms.^9,11 For example, in access control systems, logical expressions such as (A∩B) ∪(C∩D) are used to filter personnel and access points, and the Cartesian product of filtered sets is calculated to obtain permission sets. ⁶ This enables visualized permission configuration, but still suffers from role explosion and redundant rules in complex medical scenarios.^29,32,35

Recent studies have attempted to optimize these models for medical scenarios. Pan et al. ⁴³ proposed a role quality evaluation method to reconfigure permissions, but it cannot handle real-time dynamic changes (e.g., temporary personnel permission allocation during epidemics). Shen et al. ⁴⁴ designed a role discovery model based on attribute exploration to solve multi-department collaboration issues, but the generated “static roles” cannot respond to temporary needs, requiring manual configurations that increase security risks. Alanazi ²⁹ addressed RBAC’s security and efficiency flaws in medical IoT scenarios by developing an ECC-TLAF framework integrating triple-layer authentication (device-network-application) and elliptic curve cryptography, which improved attack detection rates and reduced latency compared to traditional RBAC. However, this framework still relies on pre-defined role boundaries and fails to resolve role explosion in complex clinical environments with overlapping personnel roles across departments. In terms of rule redundancy, researchers have proposed conflict detection, ⁴⁵ rule similarity detection, ⁴⁶ and policy entry reduction methods, ⁴⁷ but these tools have high time costs for large-scale policies and fail to resolve logical-level redundancy. ⁴⁸ Ameer et al. ⁶ proposed a hybrid ABAC-RBAC model based on blockchain for multi-domain permission collaboration, but it does not address role redundancy and real-time performance in medical scenarios. O. D et al. ³² reduced the number of roles through role clustering, but did not optimize dynamic permission calculations. Notably, Aslam et al. ²⁸ introduced blockchain-based trust certificates to streamline multi-entity authentication in IoMT, which reduced authorization burdens but did not extend to physical access control or resolve static role-related delays in emergency scenarios. These researches indicate that completely eliminating redundancy is impractical in real-world scenarios.^49,50 Therefore, policy conflicts in access control permissions within healthcare environments cannot be completely avoided.

Beyond policy conflict resolution, recent years have also seen several system-level frameworks that address scalability, security, and system constraints in a more principled manner. Sarma and Moulik proposed SAMIT ⁵¹ and SMAC, ⁵² which extend Ciphertext-Policy Attribute-Based Encryption (CP-ABE) with multi-authority support, dynamic attribute updates, and attribute unification for fog/cloud-enabled IoT environments. e-SAFE ⁵³ further incorporates attribute convergence, user revocation, and privileged access in a CP-ABE framework for e-health applications. FRESH ⁵⁴ addresses fault-tolerant real-time scheduling on heterogeneous multiprocessor platforms. However, these CP-ABE-based schemes operate under an online real-time authorization model, where each access request triggers attribute verification and decryption operations against a central authority. In contrast, hospital physical access control systems operate in a fundamentally different “compute-then-download” mode. As elaborated in Section 1, this mode requires permissions to be fully calculated on backend servers and batch-synchronized to distributed door controllers before any access can be granted, distinguishing physical access control from online authorization systems such as hospital HIS where real-time verification against a central database is feasible. This architectural difference has three direct implications. First, regarding scalability, CP-ABE’s per-request latency does not translate to batch permission computation. Second, regarding system constraints, CP-ABE assumes continuous network connectivity for real-time verification, whereas door controllers operate offline once permissions are downloaded, making timely permission updates critical for clinical workflow continuity. Third, regarding security, none of these frameworks provide permission-rule traceability for compliance auditing.

In parallel, blockchain technology has emerged as another promising direction for decentralized security in healthcare. Bose et al. ⁵⁵ proposed Quantum-Secure HealthChain, combining Quantum Key Distribution (QKD) with blockchain to secure cloud-based healthcare data, achieving 105 transactions per second with quantum biometric authentication. Saha et al. ⁵⁶ introduced an edge-enabled quantum-safe framework for vaccine supply chain optimization, integrating multi-access edge computing, post-quantum cryptographic protocols (CRYSTALS-Kyber, CRYSTALS-Dilithium, SPHINCS+), and blockchain consensus, demonstrating 68.2% latency reduction and 188.2% throughput improvement. Dutta et al. ⁵⁷ developed QBUILD, a quantum-resistant blockchain architecture for construction supply chains based on Hyperledger Fabric with lattice-based encryption, achieving 50% improved security resilience, 40% latency reduction, and 35% traceability improvement. While these blockchain-based frameworks offer decentralized trust and tamper-proof audit trails, they similarly focus on data sharing and supply chain traceability rather than physical access control. None address the batch permission computation challenge or provide permission-rule traceability for compliance auditing.

2.2 Limitations of existing studies in medical scenarios

The existing studies lack sufficient consideration of the unique characteristics of medical environments:

1) Compliance integration: Few models explicitly integrate medical regulations such as patient privacy protection and drug security into permission design, leading to potential compliance risks;

2) Emergency adaptability: Most optimization algorithms focus on static performance improvement and cannot meet the demand for rapid permission updates in medical emergencies (e.g., isolation ward access during epidemics);

3) Practical verification: Most tests are conducted in simulated environments and lack verification in real large-scale hospital scenarios with complex personnel and role relationships.

4) Data complexity ignorance: Existing access control models rarely consider the inherent complexity of healthcare data. Kujur et al. ⁵⁸ demonstrated that data complexity directly impacts model performance in medical imaging classification. This principle extends to hospital access control systems, where the scale of personnel (20,000 individuals) and access points (2,000 doors) introduces significant data complexity—a factor overlooked by existing frameworks;

5) Privacy preservation deficit: Centralized data processing in conventional access control models raises privacy concerns. Khan et al. ⁵⁹ proposed a federated learning approach for smartphone recommendation systems, achieving 96.68% accuracy while preserving privacy. However, this federated paradigm has not been applied to hospital physical access control, nor does it address the batch permission computation and offline deployment requirements unique to this domain.

Even the latest optimized frameworks have these limitations: Alanazi’s ECC-TLAF framework was validated primarily on resource-constrained IoT devices rather than real multi-campus hospital systems, lacking verification of its adaptability to large-scale personnel collaboration; Aslam et al.'s blockchain-based model, while addressing multi-entity authentication, did not integrate compliance controls for medical privacy regulations (e.g., fine-grained restriction of access to special clinical areas such as the Endoscopy Center) and failed to demonstrate rapid permission adjustment capabilities in epidemic-like emergency scenarios. Frameworks such as SAMIT, e-SAFE, and QBUILD, despite their contributions, operate under different paradigms — they evaluate per-request latency, whereas I_ABRAC evaluates batch computation time — and thus do not support direct quantitative comparison. None of the existing frameworks address data complexity characterization or privacy-preserving decentralized training, which are increasingly critical for large-scale healthcare deployments.

This study addresses these limitations by designing a healthcare-oriented I_ABRAC model, verifying its effectiveness in a real tertiary hospital, and ensuring compliance with medical regulations.

3 Methods

3.1 Overview of the I_ABRAC model

By integrating the advantages and limitations of RBAC, ABAC, and ABRAC, and targeting the unique demands of medical scenarios—including dynamic permission adjustments, strict compliance requirements, and fine-grained control—this study proposes the Improved Attribute-Based Role Access Control (I_ABRAC) model. Built on the foundational framework of ABRAC, I_ABRAC introduces three key innovations to address the limitations of existing approaches.

First, an approval-permission dynamic coupling mechanism enables temporary permissions to take effect directly through online approval workflows without creating new roles, effectively preventing role explosion while ensuring compliance with the principle of least privilege. Second, a rule number-driven incremental update algorithm optimizes the permission calculation process by processing only modified rules or changed personnel attributes (e.g., department, position) and access point attributes (e.g., functional area, security level) within rules, rather than performing full recomputation for all personnel, reducing time complexity from (pg₀ * pg₁ * …* pg_k * papp * pd + 2 * p * p’) to (M*p’). Third, a permission-rule traceability framework links each permission to its source rule via an “association rule” field, enabling precise compliance auditing and backward impact analysis. Figure 1 illustrates the complete workflow integrating these three mechanisms.

Figure 1.

Improved attribute-based role access control (I_ABRAC) model.

3.2 Core mechanisms of I_ABRAC

The I_ABRAC model comprises two complementary mechanisms that work in tandem: rule-based role mapping for routine permission assignment, and an approval strategy for handling exceptions.

3.2.1 Rule-based role mapping

The rule-based role mapping forms the foundation of routine permission assignment in I_ABRAC. Unlike traditional RBAC, which requires administrators to manually define roles and assign users to them, I_ABRAC automatically determines a subject’s role based on rule-defined attribute combinations.

Core Logic. Each access control rule defines subject and object attribute constraints. The system filters subjects and objects according to these constraints, then computes the Cartesian product to generate the permission set for that rule. All rule-specific permission sets are merged to form the complete base permission set.

Comparison with Traditional RBAC. Comparison with Traditional RBAC. Traditional RBAC requires manual role creation for each permission pattern, leading to high administrative overhead and risk of human errors in large hospital environments. In contrast, I_ABRAC’s rule-based role mapping automatically determines roles based on attribute combinations, reducing manual intervention and configuration errors.

Relationship with Approval Strategy. The rule-based role mapping handles routine, predictable permission scenarios. However, certain medical situations—such as a visiting physician requiring temporary access to a restricted area, or a nurse being redeployed to the ICU during an epidemic—fall outside routine role definitions. These exceptions are handled by the approval strategy described below.

3.2.2 Approval strategy for medical scenarios

The approval strategy provides a supplementary mechanism for granting individual object permissions when the rule-based role mapping cannot meet specific medical needs. It involves a point-to-point workflow where a subject initiates a permission application via a mobile terminal or computer client, and the approver reviews and approves it online. ⁶⁰

Approval-Permission Dynamic Coupling Mechanism. Traditional workflow approval operates as an “independent process separated from the model” (e.g., approval in a separate OA system), following a three-stage data flow: “application → approval → manual configuration in the permission system”. This often results in “approval granted but permissions not synchronously configured”, which poses risks in medical scenarios (e.g., delayed access to emergency equipment).

The core innovation of the I_ABRAC approval strategy is the approval-permission dynamic coupling mechanism, which has two key features:

1) Direct permission writing. The approval result directly writes the subject-object permission relationship into the permission table without modifying any rules. For example, if a doctor applies for “temporary access to a restricted area”, the system automatically adds a time-limited permission entry to the doctor’s account and triggers the permission calculation engine.

2) End-to-end online workflow. Both the application and approval processes are completed online, eliminating manual permission reconfiguration. This reduces administrative costs and avoids human errors (e.g., missed configurations) that could violate medical regulations.

Role Explosion Prevention. The approval strategy serves as a “single-point selection mechanism” that allocates fine-grained permissions without creating new roles. For example, a temporary nurse assisting in the ICU can apply for “temporary access to the ICU drug storage area” via the approval process, rather than creating a new “temporary ICU nurse” role. This prevents role explosion by avoiding the proliferation of low-frequency roles and complies with the “minimum necessary permission” principle.

Compliance and Traceability. The approval-permission dynamic coupling mechanism reduces compliance risks through two key design features: (1) authority validity periods — temporary permissions expire automatically, preventing patient privacy breaches or decision-making errors that may result from overlooked revocation; and (2) approval traceability — all approval records serve as auditable evidence for pharmaceutical management decisions (e.g., accessing anesthetic storage areas), ensuring regulatory compliance.

Separation of Duty and Conflict of Interest. In hospital environments, Separation of Duty (SoD) and Conflict of Interest (CoI) constraints are critical. For example, a physician who prescribes a controlled substance should not have unrestricted access to the narcotics storage area without a co-signing nurse. I_ABRAC enforces SoD/CoI in two ways: (1) explicit deny rules that override conflicting grant permissions, enabling static encoding of SoD constraints; (2) approval workflow configuration requiring dual approval for high-sensitivity areas (e.g., narcotics storage).

3.3 Formal definition of the I_ABRAC model

Based on the description of the improved role-based control model, the core components of the I_ABRAC model are formally defined as follows.

3.3.1 Basic entity definitions

Let SU, OB, R, and P denote the sets of subjects, objects, roles, and permissions respectively. Let A and B denote the subject attribute set and object attribute set, containing all possible attribute values. Let OP denote the operation set.

Definition 1 (Subjects). Let SU denote the set of all subjects (e.g., medical staff, temporary personnel) in the access control system.

Definition 2 (Objects). Let OB denote the set of all objects (e.g., access points, doors, restricted areas) in the access control system.

Definition 3 (Operations). Let OP denote the set of operations that can be performed on objects. For physical access control, the primary operation is enter, i.e., OP = {enter, access, …}.

Definition 4 (Roles). Let R denote the set of all roles defined in the system (e.g., physician, nurse, administrator).

Definition 5 (Subject Attributes). Let A denote the set of subject attributes, where each attribute a ∈ A describes a property of a subject (e.g., department, position, employment status).

Definition 6 (Object Attributes). Let B denote the set of object attributes, where each attribute b ∈ B describes a property of an object (e.g., location, functional area, security level).

Definition 7 (Permissions). A permission is defined as a tuple:

p = (su, ob, op, constraints, type, effect).

where:

• su ∈ SU is the subject,

• ob ∈ OB is the object,

• op ∈ OP is the operation,

• constraints is a set of attribute conditions (e.g., time constraints t ∈ [start, end], location constraints),

• type ∈ {static, approval-derived, time-bound} indicates the nature of the permission,

• effect ∈ {grant, deny} indicates whether the permission allows or denies access.

The set of all permissions is denoted as P. A permission p is considered valid if all constraints are satisfied and the permission has not expired.

3.3.2 Dynamic role strategy variables

Definition 8: Let Dyn_Policys_G and Dyn_Policys_D denote the sets of policy identifiers for grant and deny policies, respectively, defined as:

$\text{Dyn}\_\text{Policys}\_\mathrm{G}\left[\right]=\{{\text{dp}\left(\mathrm{g}\right)}_0,{\text{dp}\left(\mathrm{g}\right)}_1,...,{\text{dp}\left(\mathrm{g}\right)}_{\mathrm{k}}\},$

$\text{Dyn}\_\text{Policys}\_\mathrm{D}\left[\right]=\{{\text{dp}\left(\mathrm{d}\right)}_0,{\text{dp}\left(\mathrm{d}\right)}_1,...,{\text{dp}\left(\mathrm{d}\right)}_{\mathrm{k}}\},$

$\text{Policy}\left[\right]=\left\{\hspace{0.17em}\text{Dyn}\_\text{Policys}\_\mathrm{G}\left[\right],\text{Dyn}\_\text{Policys}\_\mathrm{D}\left[\right]\right\},$

where n is the total number of policies, k ∈ N, and Policy [] denotes a container that holds the grant policy array Dyn_Policys_G [] and the deny policy array Dyn_Policys_D []. Each policy identifier corresponds to a specific access control policy with defined subject and object attribute constraints.

Definition 9: Let Subjects_Variables denote the set of attribute value combinations for subject attributes, defined for the a-th combination as:

$\text{Subjects}\_\text{Variables}\left[\right]=\left\{\text{su}\_{\text{var}}_{\mathrm{i}},\text{su}\_{\text{var}}_{\mathrm{i}+1},\dots ,\text{su}\_{\text{var}}_{\mathrm{i}+\mathrm{n}}\right\}$

where su_var_k (k ∈ {i, i+1, …, i+n}), and su_var_k ∈ A.

Definition 10: Let Objects_Variables denote the set of attribute value combinations for object attributes, defined for the b-th combination as:

$\text{Objects}\_\text{Variables}\left[\right]=\left\{\text{ob}\_\text{var}\mathrm{i},\text{ob}\_{\text{var}}_{\mathrm{i}+1},\dots ,\text{ob}\_{\text{var}}_{\mathrm{i}+\mathrm{n}}\right\}$

where ob_var_k (k ∈ {i, i+1, …, i+n}), and ob_var_k ∈ B.

Definition 11: Let Subjects_Role denote the mapping between subject attribute value combinations and roles, which is defined for the k-th subject attribute combination as:

$\text{Subjects}\_\text{Role}\left[\mathrm{k}\right]=\text{Subjects}\_\text{Variables}\left[\mathrm{k}\right]\to \hspace{0.17em}\mathrm{r}\hspace{0.17em}\text{where}\hspace{0.17em}\mathrm{r}\in \mathrm{R}.$

Definition 12: Let Dyn_Subjects denote the set of subjects that satisfy the attribute constraints of the k-th policy, which is defined as:

$\text{su}\left[\mathrm{k}\right]=\{\text{su}\in \hspace{0.17em}\text{SU}\hspace{0.17em}|\hspace{0.17em}\text{su}\hspace{0.17em}\text{satisfies}\hspace{0.17em}\text{all}\hspace{0.17em}\text{subject}\hspace{0.17em}\text{attribute}\hspace{0.17em}\text{constraints}\hspace{0.17em}\text{specified}\hspace{0.17em}\text{by}\hspace{0.17em}\text{Policy}\left[\mathrm{k}\right]\}$

Definition 13: Let Dyn_Objects denote the set of objects that satisfy the attribute constraints of the k-th policy, defined as:

$\text{ob}\left[\mathrm{k}\right]=\{\text{ob}\in \hspace{0.17em}\text{OB}\hspace{0.17em}|\hspace{0.17em}\text{ob}\hspace{0.17em}\text{satisfies}\hspace{0.17em}\text{all}\hspace{0.17em}\text{object}\hspace{0.17em}\text{attribute}\hspace{0.17em}\text{constraints}\hspace{0.17em}\text{specified}\hspace{0.17em}\text{by}\hspace{0.17em}\text{Policy}\left[\mathrm{k}\right]\}$

Definition 14: Let op_k denote the permission set of the k-th policy, defined as the Cartesian product of the dynamic subject set and dynamic object set corresponding to the k-th policy:

${\text{op}\left(\mathrm{g}\right)}_{\mathrm{k}}=\text{su}\left[\mathrm{k}\right]\times \text{ob}\left[\mathrm{k}\right]\times \left\{\text{grant}\right\},$

${\text{op}\left(\mathrm{d}\right)}_{\mathrm{k}}=\text{su}\left[\mathrm{k}\right]\times \text{ob}\left[\mathrm{k}\right]\times \left\{\text{deny}\right\},$

where × denotes the Cartesian product operator, meaning each element (su, ob, grant) ∈ op(g)_k represents that subject su is granted permission to access object ob under the k-th policy, and each element (su, ob, deny) ∈ op(d)_k represents that subject su is denied access to object ob under the k-th policy. (The operation op is implicitly enter for physical access control.)

Definition 15: The grant permission set under the dynamic role strategy is as follows:

$Dyn\_Perms\left(G\right)=\bigcup _{k=1}^n{op\left(g\right)}_k$

$Dyn\_Perms\left(D\right)=\bigcup _{k=1}^n{op\left(d\right)}_k$

where n is the total number of active policies, Dyn_Perms(G) ⊆ P, Dyn_Perms(D) ⊆ P.

3.3.3 Approval strategy variables

Definition 16. Let App_Perms ⊆ P denote the set of all approval-generated permissions. For each App_Perm ∈ App_Perms, it is defined as:

App_Perm = (App_Subject, App_Object, op, constraints_app, approval-derived, grant).

where App_Subject ∈ SU is the requesting subject, App_Object ∈ OB is the requested object, and constraints_app includes an expiration time t_expire.

Definition 17 (Approval Lifecycle): Each approval request transitions through the following states:

• pending: the request has been submitted but not yet reviewed by an approver

• approved: the request has been granted by the approver

• active: the corresponding permission App_Perm [i] is valid and enforceable (from approval time until expiration or revocation)

• expired: the permission has passed its t_expire and is automatically removed from App_Perms

• revoked: the permission has been manually terminated by an authorized administrator prior to expiration

3.3.4 Authorization decision logic

Definition 18 (Effective Permissions). The complete set of effective permissions at time t is defined as the set of grant permissions from the union of Dyn_Perms(G) and App_Perms, excluding any permissions that are denied by deny rules. Formally:

$\mathrm{P}\_\text{eff}\left(\mathrm{t}\right)=\mathrm{G}\left(\mathrm{t}\right)\backslash \mathrm{D}\left(\mathrm{t}\right)$

where:

• • G(t) = {p ∈ (Dyn_Perms(G) ∪ App_Perms) | p is valid at time t and p. effect = grant}

• • D(t) = {p ∈ Dyn_Perms(D) | p is valid at time t and p. effect = deny}

Definition 19 (Authorization Decision). For a subject s requesting access to object o with operation op at time t, the authorization decision Auth(su, ob, op, t) is defined as:

• If ∃ p ∈ D(t) such that p. su = su, p. ob = ob, p. op = op, then Auth = deny (deny overrides all grants)

• Else if ∃ p ∈ P_eff(t) such that p. su = su, p. ob = ob, p. op = op, then Auth = grant

• Else Auth = deny

Definition 20 (Permission Validity). A permission p ∈ P is valid at time t if:

• p. type = static: always valid unless explicitly revoked

• p. type = approval-derived or p. type = time-bound: valid only if t ≤ p. expiration_time

• all attribute constraints in p. constraints are satisfied

• all contextual constraints (e.g., time_of_day, emergency_mode) in p. constraints are satisfied at time t

Definition 21 (Manual Revocation). An active approval permission p ∈ App_Perms may be manually revoked by an authorized administrator at any time prior to its expiration. Upon revocation:

• p is immediately removed from App_Perms

• The revocation event is recorded in an audit log

• Any subsequent access request relying on p is denied

Definition 22 (Traceability Mapping): Let K denote the set of all access control rules in the system. Let Trace: P → 2^K be a function that maps each permission p ∈ P to the set of source rules that generated it. The “association rule” field in the Total Permission Table stores this mapping, enabling forward tracing (from permission to governing rules) and backward impact analysis (from rule changes to affected permissions).

3.3.5 Formal security properties

Based on the defined authorization logic, I_ABRAC satisfies the following properties:

Safety. No subject can obtain a permission that is not explicitly granted after applying deny rules. By Definition 19, Auth = grant requires no applicable deny rule and the existence of a valid grant permission.

Liveness. For any authorization request, a decision is produced within finite time. The decision algorithm checks only finite sets (Dyn_Perms(G) ∪ App_Perms ∪ Dyn_Perms(D)), guaranteeing termination.

Conflict-freedom. Conflicting policies produce a deterministic decision, as Definition 19 implements Deny-override semantics, which is unambiguous by construction. The traceability framework (Definition 22) ensures conflicting sources can be identified for audit.

Least Privilege (approval permissions). Approval permissions are granted only with finite expiration time (t_expire) and specific object-operation pairs (Definition 16), preventing privilege creep.

Auditability (approval permissions). Each approval permission is traceable to its originating request, approver, and timestamp via the association rule field (Definition 22).

Non-proliferation (approval permissions). Approval permissions cannot generate further approvals. They are created exclusively through human-initiated workflows (Section 3.2.1), not from existing App_Perms.

3.4 Optimization of the permission calculation process for medical scenarios

To address inaccuracies in permission calculation and excessive performance overhead induced by redundant rules in medical scenarios, we propose an optimization for the dynamic role-permission calculation process. The optimization specifically focuses on two critical objectives: minimizing latency during emergency permission updates and ensuring compliance with hospital management regulations.

The time consumed for the permission calculation mainly depends on the server performance, data volume, and time complexity of the algorithm. When the physical server performance and data volume cannot be changed, optimizing the algorithm’s time complexity is the primary way to reduce the time consumed for permission calculation. Therefore, optimizing the permission-change-logic algorithm becomes particularly important.

Subsequently, we provide a further detailed explanation of the optimization algorithm for permission change logic, encompassing its formal definition, database design, algorithmic comparison, and permission calculation process.

3.4.1 Supplementary notation for permission calculation

To facilitate the description of the permission calculation process, we define the following notation:

1) Grant Policy permissions. Let pg_k denote the number of permission rows generated by the k-th grant rule, and pgk’ denote the number of permission rows generated by the k-th grant rule in the previous state, and mg_k denote the total sum of the elements that have changed in this rule. Let Mg = mg₀ ∪ mg₁ ∪ … ∪ mg_k be the total number of changed elements across all grant rules, and pg be the total number of permission rows across all grant rules.

2) Deny Policy permissions. Let pd_k denote the number of permission rows generated by the k-th deny rule, pdk’ denote the number of permission rows generated by the k-th deny rule in the previous state, and md_k denote the total sum of the elements that have changed in this rule. Let Md = md₀ ∪ md₁ ∪ … ∪ md_k be the total number of changed elements across all deny rules, and pd be the total number of permission rows across all deny rules.

3) Approval permissions. Let papp denote the total number of permission rows generated by all approved requests.

4) Total permissions. Let N [su][ob] denote the current total permission set with p rows, and N' [su][ob] denote the previous total permission set with p' rows. The total number of changed rows across all rules is M = Mg + Md. The total number of traversed rows for the conventional algorithm is denoted as Count_conv, and for the optimized algorithm as Count_opt.

3.4.2 Database Table Design for healthcare

We establish three interlinked database tables:

1) Total Permission Table, which stores valid permissions with a composite primary key (subject ID, object ID) and includes “association rule”, “creation time”, and “expiration time” fields—the association rule field links each permission to its source rule, enabling traceability;

2) Permission Update Table, which records permission changes with change type, operator, and timestamp;

3) Permission Rule Table, which stores rule configurations including rule type, compliance requirements, and effective scope.

The permission-rule traceability mechanism operates through the association rule field in the Total Permission Table, which links each permission to its source rule. This design enables targeted updates without full table traversal—critical for rapid permission adjustments in medical emergencies—while simultaneously providing complete auditability of permission decisions. The traceability supports both forward tracing (from permission to governing rules) and backward impact analysis (from rule changes to affected permissions), directly addressing healthcare compliance requirements where access decisions must be demonstrably linked to specific authorization policies.

For incremental updates, deny rules are precomputed into a deny_permissions_set; any allow permission whose key appears in this set is filtered out before insertion, ensuring deny-override semantics.

3.4.3 Conventional permission calculation method

The conventional algorithm generates permission sets by computing the Cartesian product of all rule sets and merging the results. Based on the formal definitions in Section 3.3, the total permission set is expressed as:

$\mathrm{P}\_\text{eff}\left(\mathrm{t}\right)=\mathrm{G}\left(\mathrm{t}\right)\backslash \hspace{0.5em}\mathrm{D}\left(\mathrm{t}\right)$

$=(\hspace{0.17em}\text{Dyn}\_\text{Perms}\left(\mathrm{G}\right)\cup \text{App}\_\text{Perms})\backslash \hspace{0.5em}\text{Dyn}\_\text{Perms}\left(\mathrm{D}\right)$

$=({\displaystyle \bigcup }_{k=1}^n{op\left(g\right)}_k\cup \text{App}\_\text{Perms}\hspace{0.17em})\backslash \hspace{0.17em}{\displaystyle \bigcup }_{k=1}^n{op\left(d\right)}_k)$

3.4.3 1 Single changed rule (k = 0)

The total number of traversed rows is

Count = p * p’. (i.e., a full comparison between the current and original permission sets).

3.4.3 2 Multiple changed rules (k ≥ 1)

Owing to the existence of permission overlap and redundancy, it is necessary to superimpose the results after calculating the multiple rules to obtain the final number of previous changes. The number of traversed rows in the process of integrating the total permission sets is pg₀*pg₁*…*pg_k*papp*pd.

Data that exist in N [su][ob] but not in N’ [su][ob] are new data, and data that do not exist in N [su][ob] but exist in N’ [su][ob] are deleted. This process is divided into two steps: first, traverse and compare N [su][ob] and N’ [su][ob], record the new and to-be-modified data, and insert them into N’ [su][ob], where the number of traversed rows is p*p’. Then, a left join is performed on N [su][ob] and N’ [su][ob] to get the rows to be deleted, which requires the traversal of p*p’ rows.

Therefore, the total number of traversed rows is as follows:

$\text{Count}\_\text{conv}=({\text{pg}}_0*{\text{pg}}_1*\dots *{\text{pg}}_{\mathrm{k}}*\text{papp}*\text{pd})+(\mathrm{p}*\mathrm{p}’)+(\mathrm{p}*\mathrm{p}’).$

Using this algorithm to calculate permissions will result in the need to traverse (pg₀*pg₁*…*pg_k) +2* (p*p’) rows every time permissions are issued, regardless of whether there are changes in permissions. This leads to excessively long waiting times, and even situations where the previous permission calculation task has not yet been completed yet another one starts, causing the system to crash and fail to operate normally.

3.4.4 Permission calculation optimization algorithm

Considering that the number of permission rules remains relatively small and stable, the optimization solution shifts from the original individual user-based polling method to a policy rule-based polling approach. Specifically, each row of data in the total permission table includes an additional “association rule” field that records which rules have generated this permission.

The optimized algorithm processes only changed rules. The pseudocode is as follows:

3.4.4.1 Single changed rule (k = 0)

When there is only one grant rule (k = 0), the current total number of permission rows is

$\mathrm{p}=\text{pg}={\text{su}}_0\hspace{0.17em}*\hspace{0.17em}{\text{ob}}_0,$

The number of permission change rows is mg₀, and the total number of traversed rows is as follows:

Count = p’ * mg₀. (i.e., comparing the mg₀ changed rows against each of the p' original permission rows).

3.4.4.2 Multiple changed rules (k ≥ 1)

When multiple rules change, the optimized algorithm processes only the changed rules, subject, object. The total number of changed rows across all changed rules is M = Mg + Md.

All modification operations on the previous global permission set N' [su][ob] are performed by matching these M changed rows against the existing p' historical permission rows. Consequently, the total number of traversed rows is:

$\text{Count}\_\text{opt}=\mathrm{M}\hspace{0.17em}*\hspace{0.17em}{\mathrm{p}}^{\prime }$

3.4.4.3 Performance ratio

The performance ratio r = Count_conv/Count_opt is

$r=\frac{\hspace{0.17em}\left({pg}_0*{pg}_1*\dots *{pg}_k*papp*pd\right)+2*\left(\mathrm{p}*\mathrm{p}’\right)}{\mathrm{M}*\mathrm{p}’}$

3.4.5 Algorithm advantages

The conventional algorithm traverses all rules regardless of whether they have changed, with complexity proportional to the Cartesian product of all rule sets. In contrast, the optimized algorithm only processes rules that have actually changed. Let M be the total number of changed elements across all changed rules, and p' be the size of the previous permission set. The optimized algorithm traverses M × p' rows, compared to the conventional algorithm which traverses approximately (pg₀*pg₁*…*pg_k*papp*pd) + (p*p’) + (p*p’) rows. The key insight is that the performance advantage grows with the number of unchanged rules. When most rules remain unchanged, M is small and the optimized algorithm runs much faster than the conventional algorithm. This advantage is most pronounced in hospital environments where routine updates (e.g., a few personnel changes) are far more frequent than full-scale rule reconstructions.

3.4.6 Detailed description of the permission calculation process

In conjunction with diagrammatic illustrations, the I_ABRAC model was employed to present a detailed elucidation of the permission calculation process utilizing table structures.

Assuming the existence of the following two permission rules, two sets of initial permissions will be generated. These initial permissions are then written into the corresponding permission table, where “person” and “access control point” serve as the composite primary key, with additional annotations for permission status, associated rule numbers, and modification status, as presented in Table 1.

Table 1.

Permission summary list.

Personnel	Door	Permission Status	Association Rules
Personnel1	Door1	Valid	Rule1, Rule2
Personnel2	Door1	Valid	Rule1, Rule2
Personnel3	Door1	Valid	Rule1, Rule2 (new Rule2)
Personnel4	Door1	Valid	Rule1(new Rule1)
Personnel1	Door2	Valid	Rule1, Rule2
Personnel2	Door2	Valid	Rule1 (delete Rule2)
Personnel3	Door2	Invalid	(delete Rule1)
Personnel3	Door3	Valid	Rule2(new rule2)

Note: Bold entries indicate permission changes relative to the previous state. Personnel4→Door1 and Personnel3→Door3 are newly added permissions (generated by updated rules), while Personnel3→Door2 is a revoked permission (marked as Invalid). Moreover, entries with actual permission changes are obtained, as shown in Table 2.

When the initial rules are modified or there are changes in the personnel information or access control point information within the rules, the permission change process is obtained, with the updated total permission table presented in Table 1 and the permission change summary in Table 2.

Table 2.

Permission change summary.

Personnel	Door	Permission Status	Association Rules
Personnel4	Door1	Valid	Rule1
Personnel3	Door2	Invalid	​
Personnel3	Door3	Valid	Rule2

As seen from the above tables, only three updated permissions actually need to be issued: adding the permissions between Person 4 and door1, between Person 3 and door4, and deleting the permission between Person 3 and door2.

The following characteristics can be observed from the permission change process:

1) The permission relationship corresponding to personnel2 and door2 falls within the overlapping area of rule1 and rule2. However, only after rule2 is modified is the permission relationship between personnel2 and door2 deleted. Ultimately, the permission changes do not involve the corresponding permission relationship between personnel2 and door2.

2) The initial final permission relationship between personnel3 and door1 is governed by rule1. After rule2 is modified, the permission relationship between personnel3 and door1 is added. Finally, the permission changes do not involve the corresponding permission relationship between personnel3 and door1.

Therefore, the calculation of the number of permission changes will significantly affect the permission update speed.

After the permission calculation and subsequent aggregation, a schematic diagram of the updated total permission table is obtained, as presented in Table 1.

As shown in Table 3, the change status follows an XOR relationship with the Boolean value of the “association rule” field. Only entries with a change status of 1 need to be issued, significantly reducing the computational load.

Table 3.

Change status relationship table.

Bool Value (initial)	Bool Value (change)	Status
0	0	0
0	1	1
1	0	1
1	1	0

4 Experiment and results

4.1 Experimental setup

4.1.1 Experimental assumptions

The experiments in this study were conducted under the following conditions, which reflect the dedicated network infrastructure of the participating hospital:

1)The network connection between the central permission server and distributed door controllers was reliable and available throughout the permission update cycles;

2)Permission synchronization latency was negligible compared to the permission calculation time;

3)All door controllers were assumed to receive consistent permission updates within a bounded time window.

These conditions represent the typical deployment scenario of the hospital’s access control system, which operates on a dedicated intranet.

4.1.2 Test environment and scenarios

To validate the applicability of the I_ABRAC model in real-world medical environments without interfering with hospital operations, we exported operational data from the access control systems of three of FAHZU’s six campuses: Qingchun, Chengzhan, and Daxue Road. After complete de-identification, all experiments were conducted on a standalone desktop machine to ensure no impact on the hospital’s live systems. The extracted dataset is characterized by:

1) Approximately 20,000 personnel with high mobility

2) Over 2,000 access control points

3) Diverse and frequently overlapping staff roles

4) Dynamic functional area adjustments

5) Strict compliance requirements for personal privacy and medication security

These characteristics align perfectly with the core challenges our model aims to address: role complexity, attribute dynamics, permission conflicts, and regulatory compliance.

4.1.3 Data source and preprocessing

The experimental data were exported from the operational access control systems of FAHZU. Following de-identification, all experiments and analyses were performed on a standalone desktop machine, with no direct connection to or impact on the hospital’s live systems. The dataset comprises operational data from FAHZU’s access control systems up to the cutoff date of 30 September 2025. The dataset captured the status of personnel attributes, departmental affiliations, and access control rule configurations as of this date. It included 57 active access control rules, covering approximately 20,000 personnel and over 2,000 access points across three campuses. The extracted fields included department, position, duty, employment nature, attached department, and access point functional descriptions.

All identifiable information was systematically de-identified prior to analysis. Department names, position titles, duty names, employment nature, and attached department names were replaced with standardized alphanumeric codes (e.g., Dept_01, PT01, Duty_01, NAT01, AT_01) according to a pre-defined de-identification mapping table. Access points were labeled by functional category only, and personnel were represented by anonymized unique identifiers.

For performance and functional correctness testing, synthetic test user profiles were created. These profiles contained modifiable attributes (Department, Position, Employment Status, Gender, etc.), enabling the simulation of a wide range of real-world scenarios—including cross-departmental roles, temporary assignments, and emergency redeployments—without interacting with actual patient or staff data. This approach ensured controlled, reproducible testing while adhering to ethical data use standards.

4.1.4 Experimental platform configuration

1)Hardware

The experiments were conducted on a desktop system running Windows 10 Professional. The hardware specifications were as follows:

● Processor: Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz (4 cores).

● Memory: 20 GB DDR3 RAM.

● System Disk: 447 GB Solid State Drive (SSD).

This configuration provided the necessary computational power and storage efficiency to handle large-scale permission calculations while maintaining the integrity of audit trails—a critical requirement for compliance in healthcare settings.

2)Software

Python 3.9.2 was used exclusively for the entire experimental workflow. This included: (1) implementing the I_ABRAC model and the conventional comparative algorithm; (2) loading and processing the permission rules and attribute data from flat files (CSV format); (3) executing all permission calculation and update operations; and (4) measuring and logging performance metrics. No external database system was used during computation to eliminate potential performance interference; data persistence and audit logging were handled through Python’s native file I/O operations.

4.2 Experimental results

Through comparative experiments between the I_ABRAC model and a conventional permission calculation algorithm under the simulated hospital scenarios described in Section 4.1, we obtained the following key findings across three performance dimensions:

1)Role Quantity (RQ): The total number of unique roles required to model the hospital’s access policies.

2)Functional Correctness (FC): The proportion of test cases where the permission output generated by I_ABRAC matches the manually verified expected result. This reflects the model’s ability to correctly resolve permission redundancies and enforce the defined access logic.

3)Execution Time (ET): The latency for completing a permission update cycle.

4.2.1 Role Quantity reduction

All models were tested on the same experimental platform, and we compared the number of roles required across four access control models under these identical operational scenarios. As shown in Table 4, traditional models (RBAC, ABAC, ABRAC) required 176 roles to cover the hospital’s diverse operational needs, while the I_ABRAC model reduced this to only 56 roles - representing a 68% reduction.

Table 4.

Comparison of role quantities across access control models.

​	RBAC	ABAC	ABRAC	I_ABRAC
Number of Roles	176	176	176	56

Note. The “Number of Roles” for RBAC, ABAC, and ABRAC represents the total policy entities required to achieve equivalent access control coverage in the hospital environment. This includes both baseline roles/attribute-templates and additional entities generated through individual authorization assignments (e.g., ad-hoc approvals, special permissions). I_ABRAC significantly reduces this count by integrating individual approvals directly into its dynamic coupling mechanism without creating separate policy entities.

This significant reduction is primarily attributed to the “approval-permission dynamic coupling mechanism,” which handles temporary and cross-departmental permissions through workflow approvals rather than creating dedicated roles.

4.2.2 Functional correctness testing

To evaluate the model’s functional correctness in handling complex and redundant permission scenarios, we designed a controlled test based on the hospital’s existing access control policies.

1) Test Data and Scenario:

The test leveraged 57 real-world access control rules from the hospital’s access control system. To simulate a high-redundancy environment without artificial replication, all 57 grant rules were utilized directly, comprising the complete set of real-world rules and inherently containing natural redundancy. In addition, 3 deny rules were configured specifically for the test area to enforce privacy restrictions, bringing the total rule count to 60. The access point for the female changing room in the Endoscopy Center was selected as the test object. This area represents a typical scenario with strict patient privacy compliance requirements and a known potential for permission conflicts due to overlapping access rights among multiple clinical departments.

To avoid any interaction with or alteration of real patient or staff data, a synthetic test user profile was created exclusively for this evaluation. This profile, identified as “Test_Person,” was designed with modifiable attribute fields—including Employee ID, Position, Department, Duty, and Employment Status—allowing for the simulation of various real-world roles and scenarios without compromising data security or privacy.

2) Permission Policy and Logic:

The access policy for the test area was formally defined to include personnel from Dept_04, physicians from Dept_02, Dept_01, and Dept_03, as well as regular employees of administrative departments (e.g., Dept_07–Dept_10) and Dept_13.

This policy was implemented using the ABRAC model, which translates the access logic into the following formal expressions:

$\text{PersonResultA}=[\mathrm{A}\cup (\mathrm{B}\cap \mathrm{E})\cup (\mathrm{B}\cap \mathrm{H})\cup (\mathrm{C}\cap \mathrm{H})\cup (\mathrm{D}\cap \mathrm{H})]\cup \mathrm{I}$

$\text{PersonResultB}=\left[\left(\mathrm{E}\cap \mathrm{F}\right)\cup \mathrm{G}\cup \mathrm{J}\right]\cap \mathrm{I}$

$\text{Result}=\text{PersonResultA}\cup \text{PersonResultB}$

where the attributes A–J correspond to personnel attributes such as primary department, position, attached department, duty, and context-specific factors. The complete attribute mapping is provided in the supplementary materials.

3) Testing Protocol and Results:

We systematically configured the “Test_Person” profile into 16 distinct attribute combinations, covering critical cases such as cross-departmental roles and temporary assignments, and deny-rule enforcement (rows with Permission = False). For each configuration, the permission output generated by the I_ABRAC model was compared against the manually verified expected result.

As summarized in Table 5, the model achieved 100% functional correctness across all 16 test cases, meaning that for every attribute combination tested, the permission output generated by I_ABRAC matched the manually verified expected result derived from the hospital’s access control policies. This demonstrates the model’s ability to correctly resolve permission redundancies and enforce the defined access logic. We note that this correctness rate reflects functional validation against a constructed ground truth, not predictive accuracy against an independent benchmark dataset.

Table 5.

Personnel attributes and permissions correspondence.

Serial No.	Position	Department	Attached_Department	Duty	Permission in Effect	Changed
1	PT01	Dept_02	AT_01	Duty_01	True	True
2	PT01	Dept_02	AT_01	Null	True	False
3	PT01	Dept_02	Null	Duty_01	True	False
4	PT01	Dept_02	Null	Null	False	True
5	PT01	Null	AT_01	Duty_01	True	True
6	PT01	Null	AT_01	Null	False	True
7	PT01	Null	Null	Duty_01	False	False
8	PT01	Null	Null	Null	False	False
9	Null	Dept_02	AT_01	Duty_01	True	True
10	Null	Dept_02	AT_01	Null	True	False
11	Null	Dept_02	Null	Duty_01	False	True
12	Null	Dept_02	Null	Null	False	False
13	Null	Null	AT_01	Duty_01	True	True
14	Null	Null	AT_01	Null	False	True
15	Null	Null	Null	Duty_01	False	False
16	Null	Null	Null	Null	False	False

4.2.3 Computational performance

We evaluated the computational efficiency of I_ABRAC through a comprehensive stress test spanning 8 personnel scales (2,500 to 20,000 personnel) and 3 rule scales (20, 40, and 60 rules). The 8 personnel scales were constructed by equidistant sampling from the full dataset of 20,000 personnel (sorted by unique identifiers). As detailed in the functional correctness testing section, the complete rule set comprised 57 real-world grant rules plus 3 deny rules added for testing (total 60 rules). The 20- and 40-rule configurations were created by equidistant sampling from this complete 60-rule set, ensuring that the proportion of deny rules was consistently maintained across all configurations. For each combination, we ran 16 test scenarios, totaling 384 test points (8 × 3 × 16).

Overall Performance. Under the full hospital configuration (20,000 personnel, 60 rules), the I_ABRAC algorithm achieved a mean execution time of 9.96 ± 2.78 seconds compared to 54.96 ± 1.89 seconds for the conventional algorithm, representing an 83.3% improvement (p<0.001). The performance improvement across individual test scenarios ranged from 79.8% to 88.9%.

Scalability Analysis. Table 6 presents the detailed performance comparison across all 24 configurations. The I_ABRAC algorithm consistently outperformed the conventional algorithm across all configurations, achieving speedup factors ranging from 5.52× to 6.21×, with mean improvements ranging from 81.89% to 83.90% (all p<0.001). As personnel scale increased from 2,500 to 20,000, the conventional algorithm’s execution time grew substantially (from 4.26s to 54.96s at 60 rules, a 1,190% increase), while the I_ABRAC algorithm maintained much lower execution times (from 0.70s to 9.96s at 60 rules), with improvement rates remaining consistently above 81% across all personnel scales.

Table 6.

Performance comparison between conventional and I_ABRAC algorithms across personnel and rule scales.

Personnel	Rules	ConventionalMean ExecutionTime (s)	I_ABRACMean ExecutionTime (s)	Improvement (%)	Speedup Factor (×)	p-value
2.5K	20	4.26 ± 0.22	0.70 ± 0.07	83.7	6.12	P < 0.001
2.5K	40	4.73 ± 0.02	0.79 ± 0.07	83.3	6	P < 0.001
2.5K	60	6.00 ± 0.03	1.04 ± 0.04	82.7	5.78	P < 0.001
5K	20	8.69 ± 0.05	1.48 ± 0.11	83	5.87	P < 0.001
5K	40	9.80 ± 0.31	1.65 ± 0.19	83.1	5.92	P < 0.001
5K	60	12.45 ± 0.10	2.12 ± 0.27	83	5.88	P < 0.001
7.5K	20	13.52 ± 0.06	2.28 ± 0.28	83.1	5.93	P < 0.001
7.5K	40	15.20 ± 0.09	2.55 ± 0.31	83.2	5.96	P < 0.001
7.5K	60	19.04 ± 0.18	3.13 ± 0.20	83.6	6.08	P < 0.001
10K	20	18.23 ± 0.15	3.01 ± 0.20	83.5	6.07	P < 0.001
10K	40	20.76 ± 0.15	3.46 ± 0.45	83.3	5.99	P < 0.001
10K	60	26.59 ± 0.19	4.28 ± 0.32	83.9	6.21	P < 0.001
12.5K	20	23.57 ± 0.43	3.83 ± 0.34	83.7	6.15	P < 0.001
12.5K	40	26.55 ± 0.18	4.39 ± 0.61	83.5	6.04	P < 0.001
12.5K	60	32.63 ± 0.32	5.45 ± 0.73	83.3	5.99	P < 0.001
15K	20	28.49 ± 0.17	4.72 ± 0.46	83.4	6.04	P < 0.001
15K	40	31.74 ± 0.42	5.20 ± 0.38	83.6	6.1	P < 0.001
15K	60	39.48 ± 0.63	6.58 ± 0.95	83.3	6	P < 0.001
17.5K	20	32.66 ± 0.40	5.53 ± 0.78	83.1	5.91	P < 0.001
17.5K	40	36.70 ± 0.38	6.16 ± 0.59	83.2	5.96	P < 0.001
17.5K	60	47.42 ± 1.93	7.70 ± 0.93	83.8	6.16	P < 0.001
20K	20	38.38 ± 1.80	6.45 ± 0.94	83.2	5.95	P < 0.001
20K	40	42.84 ± 0.66	7.21 ± 0.71	83.2	5.94	P < 0.001
20K	60	54.96 ± 1.89	9.96 ± 2.78	81.9	5.52	P < 0.001

*Note. Mean Execution Time values are presented as mean ± standard deviation. Speedup Factor = Conventional Mean Time/I_ABRAC Mean Time.

Figure 2 compares the execution time between the two algorithms, Figure 3 shows the improvement ratio distribution.

Figure 2.

Execution time comparison between the conventional full-traversal algorithm and the proposed I_ABRAC algorithm across personnel and rule scales.

Figure 3.

Quantitative distribution of execution time improvement ratio of I_ABRAC under all test configurations.

Impact of Rule Count. At 20,000 personnel, the conventional algorithm’s execution time increased from 38.38s at 20 rules to 54.96s at 60 rules, while I_ABRAC increased from 6.45s to 9.96s, confirming that the incremental update algorithm mitigates complexity growth.

Impact of Personnel Scale. I_ABRAC maintained consistent improvements across personnel scales (81.89% to 83.90%), demonstrating scalability from departmental to hospital-wide deployments.*

Adversarial Test Robustness. Across the 16 adversarial test scenarios, the I_ABRAC algorithm maintained stable performance with low standard deviations across all configurations, demonstrating robustness under challenging attribute combinations including cross-epartmental role transitions, temporary assignments, attribute extremes, and overlapping permissions.

5 Discussion

5.1 Comparative performance analysis

The experimental findings provide compelling evidence for the superior performance of the I_ABRAC model in addressing the complex access control requirements of large-scale healthcare institutions. Our comparative analysis against conventional models (RBAC, ABAC, ABRAC) reveals significant advancements across three key dimensions: role management efficiency, computational performance, and functional correctness, with an additional critical innovation in permission traceability.

5.1.1 Role management efficiency

Table 4 demonstrates a 68% reduction in system roles, with I_ABRAC requiring only 56 roles compared to 176 in traditional models. This substantial improvement addresses a critical limitation in large-scale healthcare environments where operational complexity spans multiple specialized campuses, over 20,000 personnel, and intricate cross-departmental collaborations. I_ABRAC’s innovative “approval-permission dynamic coupling mechanism” enables this reduction by decoupling fine-grained temporary access from permanent role creation, providing necessary agility for managing temporary assignments, visiting specialists, and rapid team formations while maintaining strict adherence to the principle of least privilege.

5.1.2 Computational performance and statistical validation

The data presented in Table 6 demonstrates an 83.3% improvement in permission calculation efficiency, with average processing time reduced from 54.96 ± 1.89 seconds to 9.96 ± 2.78 seconds—a 5.52× speedup. Statistical analysis via paired t-test across 16 test scenarios confirms the significance of this improvement (p < 0.001).

This performance gain is achieved through I_ABRAC’s “rule number-driven incremental update algorithm,” which processes only modified rules rather than performing full-table traversals as in conventional ABAC/ABRAC models. The result is particularly critical for emergency medical scenarios where rapid permission updates (achieving 9.96-second average calculation time) are essential for clinical workflow continuity during epidemic responses and large-scale departmental reorganizations.

5.1.3 Functional correctness and traceability assurance

As evidenced by the correct functional permission assignment across 16 complex test scenarios in Tables 5 and I_ABRAC demonstrates exceptional capability in handling permission redundancies and conflicts. This performance level is essential in healthcare institutions where regulatory requirements demand absolute precision in access control for sensitive areas including narcotic storage facilities, ICU wards, and research laboratories.

The model’s explicit ‘association rule’ field implementation provides a deterministic and auditable mechanism essential for healthcare compliance. Unlike conventional models where permission origins are obscured, I_ABRAC enables direct traceability from any permission entry back to its governing rules, ensuring that access decisions can be precisely audited against medical regulations (e.g., patient privacy protocols, narcotics access policies).

Table 7 systematically compares I_ABRAC’s traceability capabilities with conventional models across five critical dimensions of healthcare access control, highlighting its clinical and compliance value.

Table 7.

Comparative analysis of permission traceability capabilities.

Comparison Dimension	Conventional Access Control Models	I_ABRAC Model	Clinical Value and Impact
Compliance Auditing	Permission origins unclear, requiring extensive log analysis	Each permission linked to specific rule numbers, providing complete audit trail	Meets regulatory requirements (HIPAA/GDPR), simplifies accreditation processes
Fault Diagnosis	Permission anomalies require manual rule examination	Direct identification of problematic rules (83.3% time reduction)	Rapid clinical system recovery, minimizes service disruption
Security Management	Permission changes have unclear impact, often cause over-authorization	Precise knowledge of affected rules prevents permission diffusion	Adheres to least privilege principle, reduces data breach risks
Responsibility Traceability	Permission allocation responsibilities dispersed and hard to trace	Clear rule-permission mapping establishes unambiguous accountability	Supports quality management and incident investigation protocols
Dynamic Access Control	Temporary permissions difficult to track and revoke	Temporary permissions auto-linked to rules with expiration dates	Ensures safe temporary access (consultations, emergency responses)

5.1.4 Integrated advantages and comparative positioning

The collective data from Tables 4–6, and 7 establish I_ABRAC’s comprehensive superiority in balancing flexibility, efficiency, and accuracy—three often competing demands in healthcare access control. As demonstrated in Tables 7 and I_ABRAC’s permission-rule traceability represents a paradigm shift in healthcare access control auditability and management precision.

Compared with related work: (1) Aslam et al. focused on blockchain-based IoMT authentication but did not address the granular traceability of permission-rule relationships essential for healthcare compliance audits; (2) Alanazi’s ECC-TLAF framework optimized IoT sensor latency but lacked the rule-level auditing capabilities required for regulatory compliance in medical environments; (3) While RBAC provides structural simplicity, it lacks the dynamic rule-permission mapping that enables precise permission management in complex hospital environments where audit trails are legally mandated.

I_ABRAC’s unique rule-permission mapping provides unprecedented transparency in access control management, particularly valuable in compliance audits, security incident investigations, and permission revocation scenarios. As shown in Table 7, this capability directly addresses five critical challenges in healthcare access control, from compliance auditing to dynamic access management. This balanced approach effectively eliminates role explosion problems, computational bottlenecks, and accuracy issues that plague conventional models in large-scale healthcare environments

5.2 Implications for healthcare informatics

The demonstrated capabilities of I_ABRAC have significant implications for access control management in complex healthcare settings, particularly for institutions functioning as national referral centers with extensive research and teaching responsibilities.

5.2.1 Operational efficiency enhancement

The 83.3% reduction in permission calculation time directly supports enhanced clinical workflow efficiency. In both emergency situations and routine operations, the system’s responsiveness ensures healthcare professionals can access required resources without administrative delays, thereby supporting timely clinical decision-making and patient care delivery. The 9.96-second average processing time enables real-time permission adjustments that are critical for dynamic healthcare environments characterized by staff mobility, temporary assignments, and emergency response scenarios.

5.2.2 Security and compliance foundation

The model’s precision in permission management provides a robust foundation for meeting stringent healthcare regulations. By eliminating residual permissions and ensuring accurate access revocation—supported by the ability to trace permissions back to specific rules—I_ABRAC supports compliance with data protection standards and clinical safety requirements. As highlighted in Table 7, this traceability is particularly critical in environments handling sensitive patient information and controlled substances, where audit trails must demonstrate exactly why each permission was granted and through which authorization pathway. The correct functional permission assignment across complex scenarios ensures that access control decisions align precisely with institutional policies and regulatory mandates.

Problem scope. The I_ABRAC model addresses three operational risks specific to hospital physical access control:

1) Patient safety risk: Delayed permission calculation prevents timely access to critical areas (e.g., ICUs, pharmacies, emergency zones), directly impacting clinical decision-making.

2) Privacy leakage risk: Role explosion creates permanent roles for temporary access, leading to permission creep where terminated employees retain unnecessary access to sensitive areas (e.g., endoscopy changing rooms).

3) Compliance audit risk: Non-traceable permissions make it impossible to demonstrate regulatory compliance (e.g., HIPAA, GDPR) during audits.

Traditional security threats (e.g., insider misuse, network attacks, unauthorized rule changes) are outside this paper’s scope and require complementary mechanisms. A comprehensive security analysis is identified as future work.

Compliance note. Achieving regulatory compliance (e.g., HIPAA, GDPR) requires organizational policies, training, and regular audits in addition to technical controls. I_ABRAC provides technical mechanisms that can support compliance efforts (e.g., access control, audit logs, minimum necessary, permission-rule traceability), but does not automatically guarantee compliance. The mapping in Table 7 illustrates how I_ABRAC features can be leveraged to meet specific regulatory requirements.

5.2.3 Scalability for growing institutions

The architectural innovations in I_ABRAC offer a scalable solution for expanding healthcare institutions. The model’s efficient handling of increasing numbers of roles, rules, and permissions—coupled with its 68% role reduction and 83.3% computational improvement—positions it as a sustainable access control solution for growing medical centers and healthcare networks. The hybrid architecture supports both the structural clarity needed for routine operations and the dynamic adaptability required for exceptional circumstances, making it suitable for institutions ranging from single-campus hospitals to multi-hospital health systems with diverse operational requirements.

5.2.4 Limitations and future directions

While the I_ABRAC model demonstrates significant advantages for physical access control in large hospitals, several limitations merit consideration, alongside opportunities for future research and development.

1)Representativeness of the experimental setting.

The model was validated at a large tertiary teaching hospital in China, a leading national medical center with over 20,000 staff, more than 2,000 access points, and multi-campus operations. This environment reflects the complexity, scale, and role diversity commonly encountered in top-tier hospitals in China and internationally. As such, the findings are likely generalizable to other large, multi-departmental institutions with similar operational profiles, including teaching hospitals, regional medical centers, and integrated healthcare systems. However, the model’s applicability to smaller community hospitals, specialized clinics, or facilities with distinctly different workflow patterns (e.g., outpatient-only centers) remains to be validated. Variations in staff structure, regulatory frameworks, and technical infrastructure may influence the model’s performance and configuration. Therefore, future studies should incorporate multi-center trials across diverse healthcare settings to further assess the model’s generalizability and adaptability.

2) Time overhead in initial global permission calculation.

It should be noted that the performance advantage of I_ABRAC is most evident in incremental permission updates. During the initial global permission calculation—such as system initialization, platform deployment, or extensive rule reconstruction—its time overhead may approximate or even exceed that of conventional algorithms. This occurs because each permission record must be annotated with an “association rule” field to establish a complete permission–rule mapping, a process essential for traceability but which incurs substantial database write operations. Notably, this overhead is typically a one-time cost incurred during system setup and does not diminish the model’s efficiency in daily incremental updates, which are far more frequent in operational healthcare environments. Thus, this computational cost represents a necessary and justified trade-off to achieve full permission traceability, a critical requirement for compliance and auditability in healthcare.

3) Current implementation scope and scalability.

The present version of I_ABRAC focuses primarily on physical access control. Significant opportunities exist for its integration with electronic health record (EHR) systems and other digital platforms, particularly where the permission traceability feature could enhance data access auditing—an increasingly critical need amid stricter healthcare data privacy regulations. Additionally, while the model effectively handles institutions with up to 20,000 personnel, ultra-large rule sets (beyond the scales tested in this study) may benefit from distributed computing approaches to maintain performance without compromising the integrity of the rule-permission mapping. Additionally, while adversarial scenarios were tested, independent security audits would be necessary for high-security deployments.

4)Emergency access formalization.

The current I_ABRAC model implements a strict Deny-override principle (Definition 19), where any applicable deny permission overrides all grant permissions. While this design ensures safety for routine operations, it does not support emergency scenarios that may require overriding existing deny rules (e.g., allowing a staff member to enter a normally restricted area during a cardiac arrest or epidemic outbreak). A complete formalization of emergency override semantics—including its interaction with the Deny-override principle and the conditions under which overrides are permitted—remains beyond the scope of this paper and is identified as an important direction for future work.

5) Future research directions.

To address these limitations and expand the model’s applicability, several promising research directions emerge. Future work should focus on the following areas:

● Exploring distributed and concurrent processing strategies to enhance scalability. The current implementation processes permission change requests sequentially, which eliminates race conditions and is sufficient for typical hospital workloads. For ultra-large-scale or multi-hospital deployments, future work could explore: (i) sharding by rule groups to enable parallel rule processing; (ii) distributed computing architectures that preserve permission-rule traceability across multiple nodes.

● Developing integration frameworks for comprehensive security management across both physical and digital domains, leveraging the traceability feature.

● Investigating blockchain-based solutions to provide immutable audit trails in compliance-sensitive scenarios, which could complement I_ABRAC’s rule-permission mapping.

● Conducting further validation across diverse healthcare settings to strengthen the model’s generalizability and robustness.

● Extending the model to support predictive permission assignment based on staff schedules, department workflows, and historical access patterns, which could further enhance operational efficiency while maintaining traceability

● Formalizing emergency override semantics that can safely interact with the Deny-override principle while maintaining compliance with healthcare regulations.

● Exploring adaptation of I_ABRAC to enable meaningful comparison with online policy engines (e.g., OpenFGA, OPA). Direct quantitative comparison is currently not feasible due to architectural differences (online per-request vs. batch pre-computation), but hybrid approaches that combine both paradigms remain an open research direction.

● Developing automatic static detection methods for Separation of Duty and Conflict of Interest conflicts at rule configuration time, extending the current runtime enforcement mechanisms.

5.2.5 Conclusion

I_ABRAC represents a significant advancement in healthcare access control systems, successfully addressing the unique challenges of large-scale medical institutions through its innovative integration of role-based and attribute-based approaches. The model’s demonstrated performance improvements—68% role reduction, 83.3% computational efficiency gain with statistical significance (p < 0.001), and correct functional permission assignment—are complemented by its groundbreaking permission-rule traceability capability as detailed in Table 7. This comprehensive feature set positions I_ABRAC as a valuable solution for addressing the security and efficiency challenges of modern healthcare delivery, while providing technical mechanisms that can be leveraged to meet regulatory compliance requirements. By providing both the structural clarity of role-based management and the dynamic adaptability of attribute-based control, while maintaining precise rule-permission traceability, I_ABRAC establishes a new benchmark for access control systems in complex healthcare environments.

Ethical considerations

This study was approved by the Clinical Research Ethics Committee of the FAHZU (Approval Number: [2026B] IIT Ethics Approval No.0180). The data used in this study are pre-existing, fully de-identified operational data from the hospital’s routine access control system, with a cutoff date of 30 September 2025. As these data were generated as part of routine hospital operations prior to the initiation of this research, the ethics committee reviewed the study protocol and granted a waiver of informed consent due to the retrospective nature of the study and the use of de-identified data. The authors did not have access to any information that could identify individual participants during or after data collection.