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

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.

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.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,

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:

Dyn _ Policys _ G [ ] = { dp ( g ) 0 , dp ( g ) 1 , . . . , dp ( g ) k } ,

Dyn _ Policys _ D [ ] = { dp ( d ) 0 , dp ( d ) 1 , . . . , dp ( d ) k } ,

Policy [ ] = { Dyn _ Policys _ G [ ] , Dyn _ Policys _ D [ ] } ,

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

Subjects _ Variables [ ] = { su _ var i , su _ var i + 1 , … , su _ var i + n }

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:

Objects _ Variables [ ] = { ob _ var i , ob _ var i + 1 , … , ob _ var i + n }

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:

Subjects _ Role [ k ] = Subjects _ Variables [ k ] → r where r ∈ 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:

su [ k ] = { su ∈ SU | su satisfies all subject attribute constraints specified by Policy [ k ] }

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

ob [ k ] = { ob ∈ OB | ob satisfies all object attribute constraints specified by Policy [ k ] }

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:

op ( g ) k = su [ k ] × ob [ k ] × { grant } ,

op ( d ) k = su [ k ] × ob [ k ] × { deny } ,

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

D y n _ P e r m s ( G ) = ⋃ k = 1 n o p ( g ) k

D y n _ P e r m s ( D ) = ⋃ k = 1 n o p ( d ) k

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

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:

P _ eff ( t ) = G ( t ) \ D ( t )

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)

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

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

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

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.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.

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;

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:

P _ eff ( t ) = G ( t ) \ D ( t )

= ( Dyn _ Perms ( G ) ∪ App _ Perms ) \ Dyn _ Perms ( D )

= ( ⋃ k = 1 n o p ( g ) k ∪ App _ Perms ) \ ⋃ k = 1 n o p ( d ) 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:

Count _ conv = ( pg 0 * pg 1 * … * pg k * papp * pd ) + ( p * p ’ ) + ( p * 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

p = pg = su 0 * 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:

Count _ opt = M * p ′

3.4.4.3 Performance ratio

The performance ratio r = Count_conv/Count_opt is

r = ( p g 0 * p g 1 * … * p g k * p a p p * p d ) + 2 * ( p * p ’ ) M * 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.

OPEN IN VIEWER

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)

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.

OPEN IN VIEWER

Table 2.

Permission change summary.

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

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.

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.

OPEN IN VIEWER

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.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;

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

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).

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.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.

OPEN IN VIEWER

Table 4.

Comparison of role quantities across access control models.

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

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:

PersonResultA = [ A ∪ ( B ∩ E ) ∪ ( B ∩ H ) ∪ ( C ∩ H ) ∪ ( D ∩ H ) ] ∪ I

PersonResultB = [ ( E ∩ F ) ∪ G ∪ J ] ∩ I

Result = PersonResultA ∪ 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.

OPEN IN VIEWER

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.

OPEN IN VIEWER

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

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

OPEN IN VIEWER

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.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.

OPEN IN VIEWER

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.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.

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.

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.