RBAC ANSI standard (ANSI INCITS 359-2004) originally proposed by the US National Institute of Standards & Technology (NIST) describes RBAC features that have achieved acceptance in the commercial marketplace. It includes a reference model and functional specifications for the RBAC features defined in the reference model. It is intended for software engineers and product development managers who design products incorporating access control features; and managers and procurement officials who seek to acquire computer security products with features that provide access control capabilities in accordance with commonly known and understood terminology and functional specifications.
HL7 Security Technical Committee adopted engineering and role definition content models compliant with those of the ANSI RBAC standard (HL7 Role-Based Access Control Role Engineering Process, Version 1.3, September 2007). Figure 1 represents role structure in healthcare.
Figure 1: Role Structure (Adapted from ANSI RBAC Core RBAC Model)
The effort of identifying work tasks and profiles for all healthcare personnel (licensed, non-licensed, and non-caregiver) is daunting. To scope and manage the effort, the development of a spreadsheet called the “Healthcare Scenario Roadmap” provides a useful tool.
Figure 2 illustrates an example of a Healthcare Scenario Roadmap that contains a list of high level scenarios mapped to [ASTM 1986] structural healthcare roles. Licensed and non-licensed structural healthcare roles are derived from [ASTM 1986], the Standard Guide for Information Access Privileges to Health Information. The list of healthcare system work tasks is derived from documentation, system access patterns, user interaction, and input from healthcare professionals and domain experts.
In a healthcare environment, flexibility in RBAC is needed as the duties and functions of identified structural roles such as a physician, nurse or pharmacist in relation to accessing an information system can vary on the time of day, their location (i.e., clinic, ward) and assignment of additional temporary duties (i.e., supervisory or administrative). These conditional changes or constraints modify the level of access control an individual user may have. One possibility to deal with this dynamically changing context is to rapidly modify permission assignment relations according to the changes in the healthcare environment. This central idea supports constraints on almost all parts of an RBAC model (e.g., permissions, roles, or assignment relations) to achieve a high flexibility.
For example, permission constraints could include:
- Head Nurse permission functions can be accessed only by one Registered Nurse per 12-hour shift on a hospital floor at any given time (cardinality of 1, time-dependency),
- Only one Physician may have access to the Chief of Staff permissions (cardinality of 1),
- A laboratory user can co-sign another Lab Technician’s results, but cannot co-sign their own even if logged on as the Lab Technician Supervisor (separation of duties),
- Provider’s access to a remote hospital that is not his/her primary workplace (location),
- A physician working scheduled clinic hours (time-dependency) vs. physician working in a 24 hour Emergency Room (no time-dependency), and
- Provider access to only a portion of a patient’s sensitive data (as indicated in a patient’s consent directive).
Questions have also been raised as the suitability of RBAC for other relationships. For example, a 2008 discussion of the RBAC standard includes the following concern (https://blogs.oracle.com/talkingidentity/entry/my_next_attempt_at_controversy):
“However, in order for that doctor, Dr. X, to view the medical charts (electronically) of a particular patient, Patient Y, the good doctor not only needs to have a “Doctor” role, but also needs to have the “Attending Doctor” role WITH RESPECT TO Patient Y. In other words, the Access Control around the medical charts is based on a specific relationship established between Dr. X and Patient Y, that could be expressed as a relationship-based role.”
This type of situation was explicitly addressed in the 1992 RBAC model, which grants access ‘only if’, not ‘if’ or ‘if and only if’ the role requirements are met (an extremely important distinction). This was done to allow additional constraints to be added at access time. No implementation details were specified for how to handle the additional constraints, since these would vary widely with the application and type of constraint.