WPAC Resource Security RBAC

IHE White Paper on Access Control

Resource Security through Role Based Access Control

Needs-to-Know Principle

• the objective of access control is to enable every medical staff member to perform all data processing operations that he needs to do in order to fill his role within the medical treatment process - but no more!
• the organization of labor and separation of duty within a medical organization or a healthcare network determines who is allowed to perform what (medical) activities within which contexts (e. g. for what purposes)
• Permissions for the processing of medical data are derived from the permitted activities of a role within a certain context. Following the needs-to-know principle these permissions reflect the operations on medical data which are part of the activity.
• Access control should always follow the needs-to-know principle. Therefore the objective is that the set of permitted operations of a user always contains the permissions that are required to fill the current job role.
• The needs-to-know principle couples permissions with the organization of labor. Therefore the permissions granted by an access control system that follows the needs-to-know principle are always as compliant with legal regulations and privacy restrictions as the underlying organization of work. If the organization of work within a medical organization or within a medical network violates legal regulations or a patient's consent, the access control system will implicitly do so as well.
• The needs-to-know principle has impact on the design of an access control system, because it differentiates between restrictions on the assignment of people to activities and restrictions on the accessability of medical data within certain activities. In an ideal access control system a patient consent should always focus on the first (e. g. by opting-in or -out certain people, job roles, or organizations from performing a medical activity) while resource protection should focus on the second (e. g. by stating clear rules which activities require which permissions).

Authors Note: We will come back to this during the discussion of the various access control paradigms, because this statement implies a strong relationship between patient consents and discretionary access control

HL7 role engineering

Role-based access control systems are very common in the health care sector. The mostly proprietary implementations of medical management information systems were consolidated over the past years concerning their fundamental access control mechanisms. The overall direction is clearly leading towards a gradual alignment and adaption to the RBAC standard.

Leading organisations coordinating, applying, and advancing RBAC in the health care sector are the US Department of Veterans Affairs [VHA RBAC] and Health Level Seven (HL7). Those established scenario-driven processes in order to identify and specify the roles and their concrete permissions that are required to fulfil the specific tasks in the medical environment.

'Note: Image from HL7. A new figure is provided for the final release of the WP.

The starting point for the analysis of roles and rights are the so-called scenarios, in which typical procedures excerpts of medical actors are illustrated and described narratively. The scenarios itself consist of individual steps (action or event within a scenario) that incorporate the concrete operations that are executed onto the medcial or administrative objects. The required permissions on order to successfully perform those operations are combined into catalogues and assigned to profiles (roles). Inversely, scenarios are combined to tasks on a higher, conceptional level.

Currently, there are five scenario collections (tasks) specified by HL7:

• Order Entry
• Review Documentation
• Perform Documentation
• Scheduling
• Administration

The outcome is a structured catalogue that illustrates, what permissions (operations onto resources) are addresses within the particular scenarios [HL7 HPC-3.34]. In a second step, the identified actors are integrated, creating a matrix manifesting the roles and permissions. This matrix presents in what scenarios which permissions are required in order to perform the scenarios operations.

---

Discussion

place issues to be discussed among the editorial team here...

Change Requests

place your change requests here...