Role-Based Access Control (RBAC)

Permissions are not assigned directly to individual users but are bundled into roles that correspond to job functions. A user is assigned one or more roles, and through those role assignments, acquires the permissions to perform specific system operations.

• Clinical Example: A 'Physician' role may have permission to write prescriptions and view full patient histories, while a 'Medical Receptionist' role is limited to viewing appointment schedules and demographic data.
• Mechanism: This decouples user identity from entitlement, drastically simplifying administration when staff change positions or leave the organization.

RBAC models often implement a hierarchical structure where senior roles inherit the permissions of junior roles. This reflects the natural organizational chart and prevents permission duplication.

• Inheritance: A 'Senior Attending Physician' role automatically inherits all permissions of a 'Resident Physician' role, plus additional privileges like signing off on complex procedures.
• Benefit: Reduces administrative overhead and ensures consistency in how escalating privileges are managed across the clinical enterprise.

A critical security principle enforced by RBAC through mutually exclusive roles. SoD ensures that no single individual can complete a high-risk or fraudulent task alone.

• Conflict Prevention: A user assigned the 'Clinical Order Creator' role cannot simultaneously hold the 'Clinical Order Approver' role.
• Compliance: This is a key control for frameworks like SOX and HIPAA, preventing a single actor from both prescribing a controlled substance and approving its dispensation without independent oversight.

RBAC can enforce dynamic constraints that limit the scope of a role's power based on contextual attributes, implementing the principle of least privilege with fine granularity.

• Static Separation of Duty (SSD): Hard-coded rules preventing a user from ever holding two conflicting roles.
• Dynamic Separation of Duty (DSD): Context-aware rules that allow a user to hold two roles but prevent them from activating both in a single session or transaction.
• Healthcare Context: A clinician may have the 'Data Researcher' role for aggregate, de-identified data but is constrained from applying that role to their own direct patient panel.

The analytical process of defining roles that accurately map to business functions without creating role explosion. This involves top-down decomposition of job functions and bottom-up analysis of existing access patterns.

• Top-Down Approach: Starts with business processes and defines roles based on functional needs.
• Bottom-Up Approach: Uses identity mining tools to analyze current user permissions and cluster them into proposed roles.
• Goal: Create a minimal set of orthogonal roles that cover all necessary access rights without granting excessive, unneeded permissions.

While RBAC grants access based on a user's static role, Attribute-Based Access Control (ABAC) evaluates dynamic attributes of the user, resource, and environment to make real-time authorization decisions.

• RBAC: Access is binary based on role membership. Simple to administer but can be coarse-grained.
• ABAC: Access is policy-based, evaluating attributes like 'time of day', 'device posture', or 'patient relationship'. Highly granular but complex to manage.
• Convergence: Modern healthcare systems often use a hybrid model, using RBAC for broad functional access and ABAC to enforce contextual policies like breaking the glass for emergency access to a non-assigned patient's record.

A foundational security concept requiring that users, processes, and systems be granted only the minimum access necessary to perform their authorized tasks. In HIPAA-governed environments, this directly maps to the Minimum Necessary Rule under the Privacy Rule.

Implementation patterns include:

• Default-deny posture: all access is blocked unless explicitly granted
• Just-in-time elevation: temporary privilege grants that expire automatically
• Regular access reviews: quarterly certification of role membership by department heads

Violations of least privilege are the most common finding in OCR breach investigations, making this principle a compliance necessity rather than merely a best practice.

A control policy ensuring that no single individual can execute all steps of a sensitive or high-risk transaction without collusion. In clinical AI workflows, SoD prevents conflicts such as:

• The same person who labels training data cannot approve model validation results
• The developer who deploys a model cannot approve the change management ticket
• The clinician who orders a medication cannot be the sole approver of the prior authorization

SoD is enforced through role conflict matrices that define mutually exclusive role pairs, preventing a single user from being assigned both roles simultaneously within the RBAC system.

A lower-level access control mechanism that specifies which users or system processes are granted access to specific objects and what operations are allowed. Unlike RBAC, which abstracts permissions through roles, ACLs define permissions directly on resources.

In clinical AI infrastructure, ACLs are used for:

• S3 bucket policies: controlling which IAM roles can read PHI-containing datasets
• Kubernetes RBAC: binding service accounts to specific namespace operations
• Database row-level security: restricting query results based on user identity

ACLs complement RBAC by providing the fine-grained enforcement layer beneath the role abstraction, particularly in cloud-native healthcare platforms.